Backends - development was: 120.1.2 release crash on Win 10

[DrSuperGood]

I never have remember having that much problems with 16-bit, but I might not have had much to do with fullscreen games that only support 16-bit.

Does not happen since Windows 8 as it no longer changes to 16-bit (only tells the application it did, or refuses to change at all as was the case recently). In Windows 7 it messed up the desktop and other windows open while Simutrans was running when minimized (alt+tab). The reason it looks so messed up is 16-bit colour probably does not have transparency data which the windows and desktop composition system uses to blend images (so icon boarders were white). It also slows the speed at which Simutrans loads and exits as changing display settings usually black the screen out for ~0.5-1 second. Games used to get around this by responding to alt+tab events and changing the display settings appropriately which fixed colour gitches and such at the cost of considerably slower alt+tab speed.

Split from http://forum.simutrans.com/index.php?topic=15118.0 ~TurfIt

[Ters]

Does not happen since Windows 8 as it no longer changes to 16-bit

I've only had such a new OS for six months, so that's not why I haven't seen it.

The reason it looks so messed up is 16-bit colour probably does not have transparency data which the windows and desktop composition system uses to blend images (so icon boarders were white).

That doesn't sound as bad as the acid trip the desktop turns into when alt+tabbing from an 8-bit game. It gets even "better" if the game crashes, leaving the display in 640x480. Before Windows got better at cleaning up after such games, I had a self-made program in the upper-left corner of the desktop which called ChangeDisplaySettings(NULL, 0).

[prissi]

Ok, the reason why we did not release release build was that we needed the log for bug reports. Given that these are more and more seldomly read, release release build may be worthwhile.

Am I right to conclude: Making SDL default is a no go, since the prevents any far eastern user from using an IME, i.e. they can only enter Unicode by copy and paste. SDL2 as default would be possible, but is aparently also not so stable?

[sdog]

Out of general interest:

When I recall moving to SDL2 was discussed a bit over 1 year ago. It was found that some bugs (or features sdl devs were obstuse about) were game breaking. And that stability lacked overall. There is quite a lot of power behind SDL2 development, do those issues still exist?

I also had the impression there was some sympathy for moving to SDL2 only, but unavailability for Haiku/Be would still require SDL(1) in the long run. Likewise legacy MS windows versions. Is that half-correct, and still the case?

[Ters]

I also had the impression there was some sympathy for moving to SDL2 only, but unavailability for Haiku/Be would still require SDL(1) in the long run. Likewise legacy MS windows versions. Is that half-correct, and still the case?

I don't think there was ever a proposition to drop SDL1 support, just which SDL should be in the official releases for the different platforms. In the short term, there is no problem keeping the SDL1 code for those platforms with no other options. But so far, SDL2 has only been tried out successfully on MacOS. Just in the last few weeks, someone reported serious problems with both pure SDL1 and SDL2 on Linux, and actually preferred the SDL1+"OpenGL" hack (despite its bugs, although it was requested that they be fixed), which makes no sense.

[sdog]

I don't think there was ever a proposition to drop SDL1 support, just which SDL should be in the official releases for the different platforms. In the short term, there is no problem keeping the SDL1 code for those platforms with no other options.

But so far, SDL2 has only been tried out successfully on MacOS.

... where it fixes the game, which would otherwise be unplayable. It'd be interesting to try sdl2 ...

Just in the last few weeks, someone reported serious problems with both pure SDL1 and SDL2 on Linux, and actually preferred the SDL1+"OpenGL" hack (despite its bugs, although it was requested that they be fixed), which makes no sense.

I've read that thread with great interest.* I've started to build it myself. But didn't even get to compiling as I ran out of time before working through all options.

*I can understand that users point very well, 32bit has such a long tail of dependencies. Especially when it comes to the point where one has to replace essential libraries with multilib; lets you think twice before risking a working system simply to run a game.

Admin request Would you mind to split the thread at #37? I think this is perhaps going too far astray, yet I think rather interesting.

[TurfIt]

Split as requested (well actually a little before #37...)
I was going to anyways as there's a number of things that need discussing after this release mess. I'll start new threads in the programming section as It's not really of general interest.

Backends of the future will need discussing. The SDL2 effort was really focused on solving the OSX performance issues, hence the testing was there. At the time, I could also use it on Windows with MinGW; That is no longer the case due to a Windows update breaking SDL2, the SDL2 fix to that occurring after they dropped support for 'old' MinGW, and the 'new' MinGW not agreeing with Simutrans and one of it's required libraries. Stalemate.

As far as I know, SDL2 now is working quite well. Further testing on Linux and Windows would be good. Nice if the nightly server could be configured to spit them out...

I posted before that I expect we'll likely end up with SDL2 being the only backend. GDI relies on extremely deprecated API calls in Windows. Each new Windows version seems to add a new glitch. The fact it works at all is a testament to Windows backwards comparability, but it's not absolute; We're basically using a Windows 3.x era API here.

SDL1 is now listed as "historic" and is no longer maintained. We can keep using it for a while, but eventually some OS update will become incompatible, and then we're done.

The reference to the thread where a user is preferring the OpenGL 'hack' is due to a unrelated to backend bug. The use of the GL backend just masks the issue. I was working towards a fix for that, but rather distracted by the release.

32 vs 64 shouldn't be an issue, the 32 libraries should coexist with the 64, if not just static link the thing... Ideally we'd move to the x32 ABI if only such were available for Windows...


Edit: missed:

Am I right to conclude: Making SDL default is a no go, since the prevents any far eastern user from using an IME, i.e. they can only enter Unicode by copy and paste. SDL2 as default would be possible, but is aparently also not so stable?

SDL2 should be working with the IMEs now too, but I can't really test with those languages...
The user reporting a crash on maximizing the window is using an old SDL2, might be fixed in the new 2.0.4 release from a short while ago. Also possibly a problem in video drivers, or perhaps in the way Simutrans is using it too. I had a similar problem on Windows where changing the window size would crash when SDL2 was using the autodetected Direct3d driver. Forcing it to OpenGL worked, and since OSX used that anyway, it was done. The renderer selection could be made a simuconf.tab selection, or command line parameter.
More wide spread deployment of SDL2 Simutrans versions would surely spur some bug reports if it is not stable...

[sdog]

Thanks for the detailed reply (and the split).

More wide spread deployment of SDL2 Simutrans versions would surely spur some bug reports if it is not stable...

Doesn't MacOS Simutrans already take care of a relatively wide spread of a SDL2 version?

Otherwise, moving the linux/win nightlies to SDL2 might be a good first step? Nightly users cannot complain if things get broken, that's the purpose of a nightly after all.

This would also be interesting for Steam. I expect that there is a (when not recent) reliable SDL2 in the steam runtime environment. Afterall that is more or less the basis of most cross-platform games today. Thus, there oughtn't be any problem with users having outdated SDL2, plus it the greater the commonality between the different platform versions is there the better.

[DrSuperGood]

My previous tests with a MSVC built SDL2 Simutrans over a year ago showed terrible loading performance. Load bars that took seconds to fill in GDI/SDL took near minutes. Actual game performance appeared fine and I could not find any other faults. I am guessing it updated the window every time the load bar progressed as it looked very smooth to watch.

I have not made any recent tests, I might try one in response to this.

[TurfIt]

I'm not sure how 'widespread' mac usage is. If they're out their, either a silent bunch, or satisfied at least...

SDL2 is currently not possible with Windows due to MinGW issues. Discussion underway.

Steam does not provide any lowlevel graphics/sound engine like SDL, all those games rely on other libraries. Steam also appears not to provide their API library for Windows/GCC, hence we'll not be able to use it either should Simutrans finally end up there.

My previous tests with a MSVC built SDL2 Simutrans over a year ago showed terrible loading performance. Load bars that took seconds to fill in GDI/SDL took near minutes. Actual game performance appeared fine and I could not find any other faults. I am guessing it updated the window every time the load bar progressed as it looked very smooth to watch.

I thought r6470 had fixed that.

[DrSuperGood]

SDL2 is currently not possible with Windows due to MinGW issues. Discussion underway.

It is possible with MSVC builds though. The problem is how convenient are they to make since it means the use of a Windows computer with MSVC to build the release.

I thought r6470 had fixed that.

Will need to check again then.

[sdog]

I'm not sure how 'widespread' mac usage is. If they're out their, either a silent bunch, or satisfied at least...

Simutrans is perhaps not so much a game for notebooks. I think unlike notebooks, when it comes to desktops, there are still much more win than mac machines out there.

SDL2 is currently not possible with Windows due to MinGW issues. Discussion underway.

It is possible with MSVC builds though. The problem is how convenient are they to make since it means the use of a Windows computer with MSVC to build the release.

You have me at a loss here. I thought MinGW is also windows only, hence 'min. GNU for windows'? For automatic build wouldn't cross-compiling with gcc be needed? I.e, the MSVC wouldn't be more inconvenient than MinGW.

The fact that you wrote what is above means, that either my conclusions are wrong, or I misunderstood you entirely.

Steam does not provide any lowlevel graphics/sound engine like SDL, all those games rely on other libraries. Steam also appears not to provide their API library for Windows/GCC, hence we'll not be able to use it either should Simutrans finally end up there.

Oh, that is rather surprising. I thought Steam relies on an extensive run-time for all that stuff. Does that mean one has still to rely on the users installing SDL? I suppose SDL2 isn't something one could just link statically?

... time passes ...

It appears SDL2 is in the runtime, here's the package list:
https://github.com/ValveSoftware/steam-runtime/blob/master/packages.txt

While it says nothing about this being Linux only, it appears so. I've not found the equivalents for Mac and Win. It would be strange to have major packages missing from that one?

[HaydenRead]

The fact that you wrote what is above means, that either my conclusions are wrong, or I misunderstood you entirely.
Oh, that is rather surprising. I thought Steam relies on an extensive run-time for all that stuff. Does that mean one has still to rely on the users installing SDL? I suppose SDL2 isn't something one could just link statically?

It is a simple matter of including the SDL2.dll file with the exe distribution. (SDL2 doesn't normally install as such).

I currently run an SDL2 build of Simutrans on Windows (and have been doing my Patch development with the SDL2 version - using Microsoft Visual Studio Express).

[Ters]

You have me at a loss here. I thought MinGW is also windows only, hence 'min. GNU for windows'? For automatic build wouldn't cross-compiling with gcc be needed? I.e, the MSVC wouldn't be more inconvenient than MinGW.

The fact that you wrote what is above means, that either my conclusions are wrong, or I misunderstood you entirely.

I'm not sure what confuses you. Mingw is modifications to GCC that enables GCC to produce native Windows executables (derived from Cygwin, which lets you build and run Posix programs on Windows by emulating Posix). Mingw itself can run on any OS GCC can run on, but the result runs on Windows only. Our nightlies are likely built on Linux using mingw (they require pthreadgc2.dll, not pthreadvc2.dll). Installing MSVC on Linux+Wine might not be possible, and the Windows SDK is no longer available separately (and might have been just as impossible to install even if it had).