4 ms·

Actually, SDL is generally most of the parts that makes a Windows port work (having done that myself...); at least for older 2D titles and assuming you're not u

Actually, SDL is generally most of the parts that makes a Windows port work (having done that myself...); at least for older 2D titles and assuming you're not using any "middleware". SDL provides input, graphics, sound, and even some OS-level abstractions. That's quite a bit of the effort involved in porting a game typically. 3D titles that were using DirectX or C#, of course, can be significantly more involved.

dietrichepp 11y ago
Hm, that doesn't match my experience with porting. You end up making a lot of changes to code for simple things like "list the files in a directory" or more intricate changes for complicated things like networking code or threading. Then you end up making a bunch of changes because the compiler you use on Windows is vastly different from GCC. Anything involving IPC will probably end up getting rewritten from scratch, along with any UIs that appear outside the game. Paths will have to be made case-sensitive for Linux ports. Endian issues had to be worked out on OS X ports (this was pre-2010). Maybe we are porting different kinds of games?
- rikkus 11y ago
  At least Qt would be a good candidate to help with all of this. I've written many C++ apps which were entirely Qt and not at all platform dependent
- Mathnerd314 11y ago
  SuperTux also uses a filesystem abstraction library: https://icculus.org/physfs/ https://icculus.org/physfs/ Fortunately it doesn't need to do networking, threading, or IPC; those are definitely a pain. Boost provides an abstraction layer, but it's a big dependency.
- binarycrusader 11y ago
  Yes, I think that's likely. The titles I've contributed to or worked on generally don't have networking, threading, or muck about with the filesystem. They usually are single-threaded, have a single file archive or open files from a single directory (without any searching or the like). Surprised you've run into IPC use at all really. I have had to deal with the file case-sensitivity issue, but that's usually not the most difficult issue to resolve. SDL_physfs and SDL itself provides solutions for a lot of the usual hackery in dealing with file I/O though. Never had to deal with Endian issues as I've only been involved with ports that ran on x86. Still, I'd say that the parts that SDL provides abstractions for are the parts that I least want to deal with -- especially when it comes to input handling or dealing with screen resolution changes. Years of knowledge there.

dietrichepp 11y ago

Hm, that doesn't match my experience with porting. You end up making a lot of changes to code for simple things like "list the files in a directory" or more intricate changes for complicated things like networking code or threading. Then you end up making a bunch of changes because the compiler you use on Windows is vastly different from GCC. Anything involving IPC will probably end up getting rewritten from scratch, along with any UIs that appear outside the game. Paths will have to be made case-sensitive for Linux ports. Endian issues had to be worked out on OS X ports (this was pre-2010). Maybe we are porting different kinds of games?

rikkus 11y ago
At least Qt would be a good candidate to help with all of this. I've written many C++ apps which were entirely Qt and not at all platform dependent
Mathnerd314 11y ago
SuperTux also uses a filesystem abstraction library: https://icculus.org/physfs/ https://icculus.org/physfs/ Fortunately it doesn't need to do networking, threading, or IPC; those are definitely a pain. Boost provides an abstraction layer, but it's a big dependency.
binarycrusader 11y ago
Yes, I think that's likely. The titles I've contributed to or worked on generally don't have networking, threading, or muck about with the filesystem. They usually are single-threaded, have a single file archive or open files from a single directory (without any searching or the like). Surprised you've run into IPC use at all really. I have had to deal with the file case-sensitivity issue, but that's usually not the most difficult issue to resolve. SDL_physfs and SDL itself provides solutions for a lot of the usual hackery in dealing with file I/O though. Never had to deal with Endian issues as I've only been involved with ports that ran on x86. Still, I'd say that the parts that SDL provides abstractions for are the parts that I least want to deal with -- especially when it comes to input handling or dealing with screen resolution changes. Years of knowledge there.