News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

Patch for Steam

Started by HaydenRead, June 07, 2016, 09:14:02 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

HaydenRead

The Steam Overlay works with OpenGL & Direct3D rendering. SDL2 is set to default to an OpenGL rendering context which will work with Steam.

The attached Patch contains 2 small alterations to make the application work better with Steam.

  • Remove 'WinMain' from simsys_s2.cc (SDL2 already sorts loading to main rather than WinMain. With WinMain it was not compiling under MinGW.)
  • Stop the 'F12' key from loading keyboard help (default Steam Screenshot Key) (Currently any non mapped key loads keyboard help).

TurfIt

There's a long history with Simutrans, SDL2, and MinGW updates... I'd hesitate to change the entry point call as it's caused grief in the past. However the patch is currently behaving for me so... (and I'm probably the only sucker using MinGW and SDL2!)  [or more specifically, the MSYS2 distribution of MinGW as it's the only one I could finally get to work).

If the current trunk isn't compiling for you, I'd suggest you check your installation... And I'd recommend you use MSYS2 instead of any of the other MinGW variants.

What happens if you just map F12 to the Simutrans screenshot key? Seems to work for me, although you do end up with both the Steam screenshot and the Simutrans one.
Can Steam just be told where Simutrans stores the screenshots? or does it insist on taking its own?


Ters

I vote against making the F12 unusable in Simutrans, just because Steam happens to use it for something. If TurfIt's suggestion will not do, perhaps we could make some dummy tool that Steam users can bind that key to? Or at least add some compile time switch.

As for WinMain vs. main, that MinGW messed up __argc and __argv has been bothering me for years. My solution has been to use _argc and _argv, but that doesn't work with Microsoft's compiler/SDK. With MSYS2, the MinGW64 fork is looking like a mature alternative to the original (although the question of copyright on an API which brought about the fork is still unresolved as far as I know), but both's dependency on the ancient msvcrt.dll is becoming increasingly questionable.

DrSuperGood

The solution is that unmapped keys should not open help, or at least an option to turn that off exists. That way pakset authors can un-map F12 for steam computability but non-steam users can manually map F12 to something if they so desire.

Frankly the entire auto load help thing has been annoying me for years as often I accidently hit the wrong key or fail to select chat properly resulting in help loading as I type. Often when help loads the game freezes for me because I set my HDDs to idle after 15 minutes of use (and I guess something about help is not already loaded into the file cache).

It is not like help is that useful anyway. The English version is most un-helpful at times... If people want it, it is still mapped to a single hotkey and it still has a UI button to call it.

The current behaviour is not complaint with other games as well. In most games you expect unmapped keys to do nothing rather than load help.

Ters

Quote from: DrSuperGood on June 07, 2016, 06:18:20 PM
If people want it, it is still mapped to a single hotkey and it still has a UI button.

The problem is that people who need the help, doesn't know what is mapped to what. I think that help thing was what thought me the few keyboard shortcuts I actually use, but that's a long time ago now.

HaydenRead

Quote from: Ters on June 07, 2016, 06:02:19 PM
I vote against making the F12 unusable in Simutrans, just because Steam happens to use it for something. If TurfIt's suggestion will not do, perhaps we could make some dummy tool that Steam users can bind that key to? Or at least add some compile time switch.
The patch does not make F12 unusable in Simutrans, it just makes that 1 button not load up keyboard help if it is unmapped.
As others have stated, another fix would be to remove the "All Unmapped Keys"->"Keyboard Help" (Which is the next couple of lines down in the code).

In regards to the entry point, I have compiled with the altered code under both Microsoft Visual C++ and MinGW with the patch in place and it has worked. Under MinGW there was an issue of _argv _argc being NULL, causing a crash latter when attempting to run the game (it compiled fine).

Tjoeker

Quote from: Ters on June 07, 2016, 06:23:09 PM
The problem is that people who need the help, doesn't know what is mapped to what. I think that help thing was what thought me the few keyboard shortcuts I actually use, but that's a long time ago now.

The answer is easy: include help under the save icon and use F1 as a shortcut to help (like in most programs?).

TurfIt

Quote from: HaydenRead on June 07, 2016, 06:48:38 PM
As others have stated, another fix would be to remove the "All Unmapped Keys"->"Keyboard Help" (Which is the next couple of lines down in the code).
Or map F12 to screenshot.... in case that was missed in my original post.


Quote from: HaydenRead on June 07, 2016, 06:48:38 PM
In regards to the entry point, I have compiled with the altered code under both Microsoft Visual C++ and MinGW with the patch in place and it has worked. Under MinGW there was an issue of _argv _argc being NULL, causing a crash latter when attempting to run the game (it compiled fine).
Yeah, don't use the v4 w32api releases. You'll find many other nasty surprises eventually too - console failure, random linker errors with GDI and Bzip2, and on and on. But, SDL2.02 changed something making it incompatible with older MinGW, and MS changed sometime making Windows incompatible with SDL2.01. Lucky MSYS2 MinGW sticks with the working v3 w32api, and also works with current SDL2.  v4 w32api is a steaming pile of...

HaydenRead

#8
Quote from: TurfIt on June 07, 2016, 07:07:37 PM
Or map F12 to screenshot.... in case that was missed in my original post.
Yes, that is another option, the only problem I can see with that is it involves going into each PakSet each time an update is made, and updating menuconf.tab.

Quote from: TurfIt on June 07, 2016, 07:07:37 PM
Yeah, don't use the v4 w32api releases. You'll find many other nasty surprises eventually too - console failure, random linker errors with GDI and Bzip2, and on and on. But, SDL2.02 changed something making it incompatible with older MinGW, and MS changed sometime making Windows incompatible with SDL2.01. Lucky MSYS2 MinGW sticks with the working v3 w32api, and also works with current SDL2.  v4 w32api is a steaming pile of...
Thanks for the info, I will take a look at what version of MinGW & SDL2 I am using (I think I was using SDL 2.00 simply beacuse I already had the MinGW version downloaded on my computer).
-- UPDATE: Tried using MSYS2, and ended up with a couple of additional dll dependencies, compared to MSYS - (libwinpthread-1.dll, libbz2-1.dll) --
Quote from: Tjoeker on June 07, 2016, 06:51:39 PM
The answer is easy: include help under the save icon and use F1 as a shortcut to help (like in most programs?).
F1 is already mapped to the general Help system, "Unmapped Keys" are linked specifically to Keyboard Help.

For the time being I will manually patch and build the SDL2 version for Steam, until a decision has been made on this (or a similar patch).

prissi

Just discovered this now. The solution would be to call the Steam screenshot from the screenshot tool instead saving a jpg file.