Add support for more targets instead hardcoded amiga defs

[approxit]

Right now source code have hardcoded amiga functions, or hardcoded #ifdefs to handling amiga code. This should be reworked to a flexible handling more possible targets (like SDL). Targets should be a whole file replacements with correct including in compile time. Same target pattern should be followed by games. Compile error should be rised when no target was specified.

[tehKaiN]

Okay, let's assume we're talking about Ami & SDL targets. Look at keyboard processing.

Most functions are multiplatform, 'cuz whole logic is done by ACE. There is only one function which is platform dependent - processing. So we could implement both versions in one file using ifdef (having huge mess from ifdefed includes I guess), or create separate files for this one function - one for Ami, one for SDL.

If having such small and multiple files is not a problem then let's think about file structure. Where should platform-depenedent implementation be stored?

• src/ace/managers/key_platformName.c
• src/ace/managers/platformName/key.c
• src/ace/platformName/managers/key.c

I guess third option is best with addition of "common" platform.

Including .h should be done without platform dir, so they will look the same as right now. However, headers may differ between platforms, so there is a need to store them in platform-dependent way too. So here appears this mess, which doesn't really look good but it would work:

• include/ace/[baseIncludeFiles]
• include/ace/amiga/[amiIncludeFiles] - included by baseIncludeFiles with platform ifdef
• include/ace/sdl/[sdlIncludeFiles] - ditto.

[tehKaiN]

I'll write it down so it won't be omitted during dev. For coding game servers, there is need for headless target, which doesn't have any of gfx/audio/input stuff - I guess it will only use common stuff.

[SamuraiCrow]

All the low-level stuff is hardware specific anyway. To make it cross-platform or even support RTG would need a higher level engine on top of it.

[tehKaiN]

I'm rather thinking that other platforms should work on a subset of ACE, e.g. no copper, no sprites. So having a multiplatform code would require to write chipset-heavy ACE code and portable one (simple buffer, blitter and nothing else).

[SamuraiCrow]

Many platforms have no support for palette graphics at all. They have to be implemented with shaders or slow emulation code.

[tehKaiN]

I don't know how to exactly solve palette problem on other platforms yet. I think it'll become clearer when time comes to do first game port. I'm a bit of a shader guy, so I'm not afraid of writing it that way. Perhaps most games could get away with conditionally-enabled code which wouldn't use palette stuff at all, just plain blits. That's also what I meant when specifying that ports would have to use subset of ACE - I just don't know where the line will be drawn.

[tehKaiN]

Regarding paths, the most feasible option is src/ace/platformName/managers/key.c since it allows for easily wildcarding .c files for building:

• for Amiga it will be src/ace/amiga/managers/key.c and src/ace/common/managers/key.c GLOBbed by common and amiga
• for sdl it will be src/ace/sdl/managers/key.c and src/ace/common/managers/key.c. GLOBbed by common and sdl

Also I'm assigning it higher priority since Project R3D is about to release their Bridge Strike on other platforms and I don't like to fall behind in competition. ;)

[tehKaiN]

There is a work-in-progress SDL port, which aims to be a second-class citizen in ACE's codebase. It's experimental, very incomplete, and the first working merged part will completely lack copper emulation as well as other hardware emulation-related features. It's aimed to port https://github.com/Last-Minute-Creations/chaosArena without drastic changes, since that's most probably the simplest complete ACE game. Then ports of more complex stuff will follow: https://github.com/approxit/impsbru, https://github.com/Last-Minute-Creations/germz, https://github.com/Last-Minute-Creations/AMIner .