MSVC POSIX build and Graph0 fixes.

[DrSuperGood]

Finally managed to get a POSIX Simutrans server built using MSVC Community 2013.

The timing method used by the POSIX build does not exist in Windows apparently so a workaround was used (a function adapter). This might or might not be the appropriate solution.

Additionally during the major graphic identifier size code revision in December the 0 colour graphics could no longer build (used by servers). The function declarations no longer matched between the two files.

[prissi]

Thank you, most welcome.

May I suggest that the opening brace of a function is on the next line, since it is done in the rest of the code in this way ...

[DrSuperGood]

May I suggest that the opening brace of a function is on the next line, since it is done in the rest of the code in this way ...

Might have been auto formatted. Had to adjust that a bit to be more consistent with the code.

[TurfIt]

gettimeofday() is already present on MinGW via #include <sys/time.h>.  ->> don't add MSVC specific stuff based on _WIN32 define.
alpha_flags are a mess, flipping from uint8 to unsigned and back a couple times through the call chain. uint8 is all that's needed (and all non number of bit specifying declarations should be purged... use only the simtypes.h types. Especially use of long is problematic with 64bit builds).

[DrSuperGood]

gettimeofday() is already present on MinGW via #include <sys/time.h>.  ->> don't add MSVC specific stuff based on _WIN32 define.

You are probably right, might need to be...

Code Select Expand


#if defined(_WIN32) && !defined(__CYGWIN__)

Which is what the net code uses.

MSVC used to support "gettimeofday()" as well (probably why there never was a work around), however it appears that some time last decade support for it was dropped (many complaints on the internet about how code stopped compiling). The solution I used was the recommended solution from what I could tell however I do agree it might now be applied when it should not.

alpha_flags are a mess, flipping from uint8 to unsigned and back a couple times through the call chain. uint8 is all that's needed (and all non number of bit specifying declarations should be purged... use only the simtypes.h types. Especially use of long is problematic with 64bit builds).

Someone more experienced with that code needs to fix that. This patch solved an inconsistency between the 0 and 16 files that prevented compilation of a POSIX 0 colour depth build. The declarations in both files have to be the same.

In theory having them as virtual methods on a singleton would be better as that way a simple macro statement could choose which implementation to use (both get compiled so are syntax checked preventing such inconsistencies as occurred) and it should still optimize to the same code (since virtual methods on a compile time constant singleton are known at compile time). However reading about compiler optimization of virtual functions gives me doubts that will occur so maybe link based selection is still better.

EDIT:
This version of the patch should hopefully be better. I also tried to improve the accuracy of the adapter. It should now only build the adapter when MSVC is used and additionally it will use a more accurate timing function if built targeting Windows8 (otherwise it defaults to something ~Windows 2000 compatible).

[prissi]

Thank you, sumbitted into r7517

[TurfIt]

editing stikes again - IMHO better to double post than edit and not have the post flagged as unread...

The GDI backend simply uses timeGetTime(). Surely that's sufficient here too?

Your first patch had changes to simgraph0.cc. Are they necessary to make MSVC happy?  The alpha flags needs fixing (I'll change them all to uint8), but doesn't prevent compiling as is in MinGW...
clip_rect shouldn't need init as it's not actually used

[DrSuperGood]

Your first patch had changes to simgraph0.cc. Are they necessary to make MSVC happy?

No, they should be needed to make every proper compiler happy when building POSIX 0 colour. The changes to simgraph0.cc were to fix inconsistencies in function declarations. That file is only compiled for builds aimed at servers which is why no one probably detected it (not many nightly servers recently).

It is also possible GCC assumes const unsigned as const uint8 (or is smart enough to make the connection between them) in which case it will build however I thought the correct assumption in such a case would be uint32 as that is the word size used. In any case the function declarations in both the simgraph16.cc and simgraph0.cc should be the same for consistency as they are substituted depending on which build you want (16 is normal, 0 is server).

The GDI backend simply uses timeGetTime(). Surely that's sufficient here too?

No idea, I did not want to alter the mechanics of what was happening so I wrote an adapter to mirror the functionality used with what was available. If it is only used for measuring delta time (the passing of time, not what time it currently is) then it should use some performance counter instead as those are more accurate and probably avoid extra conversions.

[Ters]

No idea, I did not want to alter the mechanics of what was happening so I wrote an adapter to mirror the functionality used with what was available. If it is only used for measuring delta time (the passing of time, not what time it currently is) then it should use some performance counter instead as those are more accurate and probably avoid extra conversions.

timeGetTime gives you time that has passed since boot, not the current time. It's precision is in the millisecond range, but that should be enough for game time.

[prissi]

The performance counters are extremely unreliable on multicore processors or with sleep states (i.e. almost any processor). When the process get transfereed between core, it can even return in zero time differences of several ms.

[jamespetts]

May I ask - what was the purpose of the Posix changes? My Windows build of a console server (in Experimental) does not use simsys_posix, and a Mac or Linux build would not require Windows adaptations. Am I missing something...?

[DrSuperGood]

The performance counters are extremely unreliable on multicore processors or with sleep states (i.e. almost any processor). When the process get transfereed between core, it can even return in zero time differences of several ms.

There are other timers available that are not performance counters that also just measure time differentials. For example the time since system startup.

Not knowing exactly what was needed for timing I wrote an adapter to mimic what was currently used. From some internal tests it appears to be working fine (my client build connects to my POSIX server build and remains in sync) so I have confidence my solution is sufficient for basic operation. I am not confident if the solution is optimal however that should only be looked at if it is truly a performance or requirement problem with it.

May I ask - what was the purpose of the Posix changes?

So I could build a POSIX 0 colour server build. I was planning to demo JIT2 to people like 50, moblet etc using a nightly however that plan is on hold until nightly builds are more readily available (links updated, solutions worked out etc).

My Windows build of a console server (in Experimental) does not use simsys_posix

What does it use then? As far as I could tell the POSIX build was entirely intended for server use since it is incapable of graphics (why it needs 0 colour as well). The theory behind it is that it should be faster and lighter I imagine since it does not use as much as a standard build.

Maybe I am missing something however. I could not find clear instructions how to build a "server" build, especially using MSVC.

and a Mac or Linux build would not require Windows adaptations

Linux will certainly not since it uses Linux standard libraries (why it did not work on Windows). Not sure about mac however since it is Linux based chances are it would also work as I doubt they needed an alternative to that standard library. Windows needs it because the Windows SDK defines completely different interfaces for retrieving time although it shares the same structures for compatibility purposes (all the methods used to set them do not exist however, one has to manually set them instead).

Am I missing something...?

Maybe I am missing something. From what I could tell, 0 colour POSIX is meant for servers.

The Graph0 fixes also included a fix for an uninitialized local structure which is now applied to standard. It probably makes no noticeable difference (the structure is probably never used anyway) however it does reduce exposure to undefined behaviour. Just in case people were wondering why that changed.

[jamespetts]

I did apply the compile and initialisation fix to simgraph0.cc, which works fine. However, my server build on Windows uses the same simsys_w.cc (GDI) as does the build with the graphics - it just uses simgraph0.cc instead of simgraph16.cc. Is this not the right way of doing things?

A reason that it is not entirely straightforward for me to adapt these changes into Experimental (especially those in symsys_posix.cc) is that, somewhere along the line, there have been significant changes to things that connect with symsys_XX.cc files that have never been imported into Experimental that means that Experimental will not compile with Standard's version of these files, even though there have been, so far as I am aware, no or no significant Experimental specific changes to these files. I think that it may well be the GUI themes that have never been merged into Experimental that may be responsible for this, although it might also be other things. I do not know whether the posix from Standard would work for Experimental, and I note that the changes appear to be to parts of the file that are not in the current Experimental version.

[Ters]

I did apply the compile and initialisation fix to simgraph0.cc, which works fine. However, my server build on Windows uses the same simsys_w.cc (GDI) as does the build with the graphics - it just uses simgraph0.cc instead of simgraph16.cc. Is this not the right way of doing things?

When compiling with MSVC, simsys_w.cc can be used to create a Windows console application as well (although with something of a hack). I'm not sure if mingw accepts WinMain for console applications. If not, the same or a similiar hack should be possible, but hasn't been done. The combination of simsys_w.cc and simgraph0.cc does however mean that much of what is compiled in simsys_w.cc won't be used (possibly cut when linking).

[prissi]

Most work on these files was for multithreaded drawing, which is the most substancial speedup sumitrans can get on a multi-processor system. I strongly suggest to implement that.

[jamespetts]

Ahh, thank you for that - I will have to look into that in more detail and try to implement it. I may well ask some detailed questions to help me to merge it in properly in another thread when I get around to this, if that's all right.