News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

Cygwin compilation fix

Started by kagari, January 07, 2015, 10:42:12 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

kagari

Hello! I've been trying to compile Simutrans on Windows, and in process of it I found Cygwin port haven't been able to compile for quite some time. Here's a patch to fix it for GDI and SDL2. I have no success in getting SDL 1.2 working on Cygwin, so no SDL1 for now.

1. -mno-cygwin option apparently removed in GCC 4.7
2. Cygwin has no <direct.h>; Replaced with <sys/unistd.h>
3. Add __argc, __argv declarations for Cygwin, which doesn't have these in headers even though the runtime provides it.

Ters

Cygwin is meant for emulating POSIX on Windows. Since Simutrans is a native Windows application, it is not the ideal choice. Some of your changes seem straight out wrong, such as using main instead of WinMain. Cygwin support will likely also be very frail, as probably no one else uses it and may easily write Cygwin incompatible code.

Mingw and Microsoft Visual Studio are more obvious choices for compiling true Windows applications. Both are free. Mingw is also more lightweight than Cygwin by avoiding most of the POSIX emulation system, or at least was last time I touched Cygwin, which is many years ago now. I don't know if Cygwin is more or less up to date with the Windows API than Mingw. Mingw64 is more up to date than Mingw, but I figuring out how to install it was troublesome last I tried, with no truly official binary releases.

DrSuperGood

From my experience SDL1 is very buggy on Windows. I would recommend people stick to GDI for Windows as the performance of a proper compile will still be better than the SDL1 you can download from this site.

MSVC builds all but the POSIX server version perfectly. There is some threading issue with POSIX I am looking into.

Ters

I've never had problems with SDL1.

prissi

Unfourtunately your patch is incompatible with MSVC (unexpected line feed in network.h) in the line with
#if defined(_WIN32) and !defined(__CYGWIN__)
???

DrSuperGood

SDL1 often bugs up Aero and sound when it is connected in full screen. If alt+tabbing a lot SDL1 can eventually crash the desktop driver completely in full screen leaving you with a login style background screen for all eternity until you forcefully cycle power. SDL2 works more compatibly but something about the update routine causes progress bars to be very slow (but also very smooth!) so loading a map takes several times longer than normal.

The performance of GDI in a self-made build is such that it will beat the standard SDL1 build anyway. I am not sure about SDL1 self-made however but SDL2 appears to perform on par to GDI in game so I am guessing SDL1 is not a major bottleneck.

Since 120 alt+F4 is broken in both but I am not sure if that was due to stupid design decisions or that it never was meant to work in the first place. It worked in 112.3. In any case it should automatically quit the game when pressed on windows (if auto quit is not desired then add a "do you want to exit" popup).

Ters

I've always assumed GDI to be old-fashioned and not optimal for high-performance graphics output. Why else did Microsoft have to make DirectDraw? I have also never trusted that fullscreen games handle alt-tabbing well, and so have never run Simutrans in fullscreen either. (Several games also have problems when running in fullscreen on a dual-monitor setup.)

kagari

Quote from: prissi on January 07, 2015, 10:03:03 PM
Unfourtunately your patch is incompatible with MSVC (unexpected line feed in network.h) in the line with
#if defined(_WIN32) and !defined(__CYGWIN__)
???

I should have caught it before posting the patch... It does happens on my VC++ 2010 too. I'm sorry for wasting your time.

Quote from: Ters on January 07, 2015, 05:07:10 PM
Cygwin is meant for emulating POSIX on Windows. Since Simutrans is a native Windows application, it is not the ideal choice. Some of your changes seem straight out wrong, such as using main instead of WinMain. Cygwin support will likely also be very frail, as probably no one else uses it and may easily write Cygwin incompatible code.

I agree with you. I'm working on Cygwin port solely because I still haven't been able to set up a MinGW/MSYS environment that can compile Simutrans. I want GCC in order to make sure I don't break something specific to it (I broke MSVC one though).

Patch V2
- Fixed: network/network.h (embarrassing)
- Fixed: main vs WinMain (I forgot to add newer simsys_s2.cc to the commit :( )

As far as I can see, I can't think of anything more I'm missing on it. Maybe socket thing?

Ters

Not using Winsock suggests using Cygwin's POSIX socket emulation. Makes me wonder what else is passed through the emulation layer.

kagari

After skimming through the CVS snapshot, it seems to me they're well aware of some of the incompatibility that get ifdef'd in Simutrans. Even so, I admittedly haven't tested network games at all.