Decide (if not done yet) witch plaforms to support

[ChrisCF]

As long as we don't have to use memcpy() manually, we'll probably manage then

[mispunt]

If anything, the main problem I see is going to be endian-ness

Well, if we're going to use SDL (and there's a 95% chance that we will ), that should not be a really big problem. SDL provides macro's to ensure the correct endian-ness of pieces of memory.

Aren we going to use an excisting 3D environment? SDL is just a set of libraries and you have to program a lot to make a good 3D environment and there are a lot of good environments which are multiplatform.

[Conditional Zenith]

I think TE should support GNU/Linux and be able to be complied on other *nixes. I honestly don't care if it doesn't support MS Windows or Mac OS.

[Arathorn]

Since 95% of all desktop pc's run on Windows I think Windows support would be quite nice, if only because not all programming people use Unix, and we lack programmers.

[mispunt]

So there is support for at least:
Windows
*nix

Are there people who could program on the mac, or other platforms? if so, they could be included to.

[eis_os]

Still, IMO our target platforms should be "anything it'll build on". With the exception of Windows, and ancient versions of Mac OS, we should require a minimum of porting between different systems. If anything, the main problem I see is going to be endian-ness - making sure that the code does not depend too heavily on byte order (lots of defines and alternate functions ...). More often than not, if it will build on one Linux distribution, it'll probably build on another. If it builds and works on lots of different distributions with different software configurations, it'll likely work on other *nix flavours too. Windows is likely to pose a major problem, due to the fact that it's comlpetely different to almost everything else.

Why is windows so different?
If you don't make to many hacks and rely on os dependend functions, (then it wouldn't work on mac too) you should be able to cross compile.

I made two wrapper function for zugspiel, and I can compile it under window. However the Zugspiel GUI System use the fact that on linux the gl window is behind fltk, thats not true on windows.
If you don't build to clever workarounds most stuff should work.

[Bjarni]

if there are no endian problems, it can be ported to macOSX pretty fast
if #include SDL.h is not used in the file with main, it needs

Code: Select all

#if defined(__APPLE__)
#include SDL.h
#endif

this is needed to allow macs to open a window with SDL. I have yet to find a good reason for that. I just know it's like that

This port will only work from CLI. I can make it work from GUI by adding some lines to makefile
NOTE: it's not just copy phase of what I wrote in the OpenTTD makefile. It have to be lightly modified to suit the app it's made for

[Conditional Zenith]

Since 95% of all desktop pc's run on Windows I think Windows support would be quite nice, if only because not all programming people use Unix, and we lack programmers.

Then 95% of all desktop users need to be re-educated

[Hyronymus]

We're going OT, not to say running away from making a decision.

[mispunt]

That is why I posted the following message:

So there is support for at least:
Windows
*nix

This is from what I read in the few usefull posts. The question that is still open is:

Are there people who could program on the mac, or other platforms? if so, they could be included to.

I think this is crusial to know. Or are we just planning to support Mac in the future? We need to know this for the game engine. some game engines are only for win/*nix and other for mac to.

[Arathorn]

Even though I'm no big fan of Mac, I think it should be supported too.
If we don't have Mac programmers yet, I think we should at least use an engine that works on Mac too.

Topic locked, please read the FAQ topic (14112006).