Surprised to see this on HN! I played this when I was young and it was a great, charming substitute for the Nintendo games my parents refused to buy me, haha.
Just by looking at the screenshots, I can feel the nostalgia... I remember I've tried to create a clone of SuperTux with SDL when I started coding. I might still have it somewhere... I'm going to download it again and play for a while !
This game is actually really fun and stable for an open source game. I can't believe I haven't tried it before now. It even mapped out the buttons for my Afterglow controller without any adjustment required. That's a refreshing surprise since most of my Linux games on Steam don't even recognize the controller.
I'm not sure what you mean? I have seen plenty of stable and fun open source games (esp. while HappyPenguin.org website was still live). I have also seen a lot of shitty games, both open and closed source (take a look at Google Play). I'd say that ratio is probably the same.
Never played this on my Linux desktop, though on my Nokia N900 this was the only game that I had installed. Great times, will play it again now it has been released again!
Hard to tell from the video, and it has been ages since i tried Supertux, but all too often when i try SMB clones they have this slippery feel to them. That when i let go of a directional button the character do not stop instantly, but "slides" for a block or two before coming to a halt.
Isn't that part of the later SMBs? It's not in Super Mario 1 + 2 for the GB, but sure is in SMB3 (although I only played the latter on emulators only).
Possibly, but i don't think it is as pronounced as in the various clones. Or at least i never found it annoying in the SMBs, but kept noticing it in the clones.
I'm pretty sure it's part of all of them. At least, I just tried it in an emulator and SMB definitely seems to have something like inertia built into the walk speed, and definitely running.
Supertux definitely does have that effect (I hate it ;). I only played the original Mario in emulators, so I can't tell you whether it's copied from original.
SMB3 has some sliding, more if you are on ice surface. Supertux has a wee bit less than SMB3 on ice surface, but all the time. I guess that´s intended as, well, you are a penguin on an icy world! :)
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.
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).
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.
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.
