Question for the gamers

[redtyphoon]

The OpenSSN project is coming along nicely. I'm happy to report it's working well on FreeBSD, PC-BSD and it's in the process of being included in Debian and Ubuntu Linux.

As happy as I am about this, I realize a lot of gamers are on Windows. So, my question to you is, is there any interest in seeing OpenSSN ported to Windows? I may be able to get a Windows developer on board, but before I do that I'd like to make sure there's an interest in the game from Windows players.

http://openssn.sourceforge.net/

[magicstix]

If you're using only SDL for the graphics it should be a pretty straightforward port...

[redtyphoon]

The SDL library is the only external dependency. So, yes, porting should be fairly straight forward. However, I don't have a Windows box to compile/test with, which gets in the way.

[magicstix]

Hmm... I took a look through main.cpp and didn't see anything that would cause trouble under windows. I'll run it through visual studio and see what breaks.

[redtyphoon]

Most of the code should be fine, I've done my best to keep it to standards. The only place where I think there may be trouble is in files.cpp

The files.cpp module tries to find OpenSSN's data files and checks a couple of different places, including the current working directory. Since files are organized differently on Windows than Linux/BSD this function might bomb. I think it will still compile, but it might not return the correct location. Everything else is pretty vanilla.

[magicstix]

Which version of SDL are you using? The latest doesnt have the SDL subdirectory tree nor does it have SDL_image.h

[magicstix]

Nevermind... I didn't know it was a second library.

[magicstix]

OK thus far the biggest problems in getting openSSN to compile under MSVC are its use of non-standard C functions.

The biggest offenders are strcasestr and snprintf. They're not in the C89 standard (which MSVC uses). I'm working around them at the moment with macros.

The other offender is "unistd.h" which is a unix-only header file. I've gotten around this with #ifndef WIN32..#endif preventing the compiler from attempting to include the header. MSVC supports the types defined in it natively.

[redtyphoon]

I checked and the unistad.h include is an old dependency and is no longer needed. It can be removed entirely. For the next release of OpenSSN I'll put in checks so strcasecmp and snprintf are avoided if WIN32 is defined.

[magicstix]

I was hoping to get it to compile under MSVC without tearing up too much code, but it looks like the use of getopt() will be the show stopper on that. The other functions were trivial and could be worked around, but MSVC has no implementation of getopt whatsoever and to use it one would have to fish it out of the gnu standard library and include it with the source tree (probably not a good idea).

For portability, openSSN would probably benefit highly from replacing all of the old C-style calls and datastructures with their C++ STL equivalents (for example all of the snprintfs, strcmps, char* pointers with std::string and its operators). The C++ STL stuff tends to be safer and easier to use.

Replacing getopt() with something else for the options parsing would be a good idea too. I'd recommend using the boost library's program options, but this would add another dependency. However, boost comes with a lot of fancy tools like shared pointers, so you don't have to worry about memory leaks. Plus, when the time comes to add multiplayer support to openSSN, boost.asio is *really* good for doing network code.

[redtyphoon]

Since OpenSSN is almost never run with options, you can put a big #ifndef WIN32 around the entire getopts section.

As for moving to C++ STL, it's not going to happen. That code is far to cumbersome and heavy to work with for a project like this. I had to tear a whole bunch of it out earlier to get things to run properly.

[magicstix]

Success!




Hmm, it looks like the BTH isn't drawing properly under windows... Might be my version of SDL (1.2.11).





Phew! That was a bit of a pain.

OK so basically here's what I had to do:

- Commented out the options parsing section, so only defaults are available if you compile with MSVC (until the getops() while loop is rewritten with something portable).

- In files.cpp defined DATADIR to be char* DATADIR = "data" This will make the game look in its binary path for the datafiles it needs.

- Changed fabs to abs in radar.cpp since the arguments are all signed ints (MSVC gets pissy about this because it can't determine from the argument types whether you want a double or float version of fabs).

- Got rid of all the weird double includes (i.e. #include "SDL/SDL.h" followed by #include <SDL/SDL.h>)

- Removed SDL/ from the beginning of all SDL-related includes.

- Defined snprintf as _snprintf for MSVC compiles

- Defined strcasestr as strstr for MSVC compiles (This is technically inaccurate as the two functions have slightly different behavior)

- Defined strncasecmp as _strnicmp for MSVC compiles (the former does not exist under MSVC as it's nonstandard C).

- Grabbed and compiled all the dependencies in addition to SDL (this part was a pain because the new versions of MSVC require you to specify your lib/include directories for each project individually).

In addition to SDL, openSSN needs the following deps:
- SDL_image
- SDL_gfx
- SDL_mixer

[redtyphoon]

Congrats on getting OpenSSN to compile.

One suggestion though regarding DATADIR. The DATADIR value is supposed to point to the top level of the OpenSSN directory tree. So, for example, if you had

C:\Program Files\OpenSSN\data
C:\Program Files\OpenSSN\sounds
C:\Program Files\OpenSSN\ships
C:\Program Files\OpenSSN\images

Then DATADIR should be "C:\Program Files\OpenSSN". If it's working as-is right now, it's probably because the files.cpp module also checks the current working directory if it doesn't find what it's looking for in DATADIR.

I'll make a note of your other changes so the next version of OpenSSN will be easier to work with. Thanks!


PS. If you'd like to e-mail me a ZIP file with your binary and data files, I'll upload it to the project's website so everyone has easy access to it.
jessefrgsmith@yahoo.ca

[magicstix]

Unfortunately gmail doesn't allow one to send .zips with exe files. I'll figure something out and post it somewhere I guess.

[redtyphoon]

If you have a SourceForge account I could just give you upload rights to the OpenSSN project.

Update:
Since the strncasestr and strncasecmp functions don't work in MSVC compiler and the _stricmp probably won't work on any other compiler besides MSVC I've decided to write my own versions of these functions. Having a local version of these functions should help. The getopt section I'll re-write to be more vanilla.