Needless to say I went for the source ball. Through my famous slackbuild script of course!
That went fine, until configure barfed about some CEGUI thing.
What’s a CEGUI thing?
Apparently it’s some kind of windowing/widget library. Yeah, another one.
So I ram it through slackbuild, which went fine as usual after I did a make distclean in the source dir. Some how the first build fucked up, don’t ask me why.
Anyhow, I installed the CEGUI package and ran back to the smc source dir.
Slackbuild had no other issues this time so out rolled a package. After installation I tried to run it.

Here’s what it said after my screen went black for about a second and came back:

Yeah, that’s what I get for trusting yet another crap library with widgets. *sigh*

However, I had just enough energy left to try one detour into bug/issue fixing land.
Google came up with basically only 1 thing, so after trying my best to read some italian forum I trashed it back through google’s own translation service.
Now that it was in dutch it was a bit more readable, it hinted about using the freeimage library instead of the default TGA codec (which obviously failed).

Installing the freeimage library was pretty trivial, although they don’t use autoconf so I had to go through their Makefiles manually.
The first hint of trouble is usually when source packages come delivered in the famous .zip format. Oh, sorry, I meant .ZIP-EVERYTHING_IS_CAPS format. Seriously, don’t get me started on how many times those kankerthings exploded in my /usr/src dir so far, completely splattering up everything there.
Good thing I’m good with rm. Anyhow, this zip package was decent and created a dir (without version number though).
After fiddling with the makefiles and building freeimage, I also build freeimage plus and stashed it into a package with makepkg.
Phew, sweat on my forehead. Hopefully slackbuild will be able to handle this some day….. (dream on)

Back to CEGUI — compiling it with the freeimage library went without problems, and after upgrading my previous CEGUI package it was finally time to retry SMC.
By the way, did I note that all these packages compiled on x86_64? Good job on that one guys

This time the screen actually came up with some mario^H^Hyo like stuff! Just like the good old days with the SNES!
It looked a bit like this:

On the background the theme music played that reminded me quite a bit of the original snes game.

Messing around with it a bit I quickly got myself killed a few times and had some fun.

I soon realized that the SNES version had better controls, but then again… playing on a keyboard is kinda cramped for platform games.
So I reconnected my Logitech Rumblepad 2 to see if it would work. Well, if works great
Not a snes pad (the thing is a lot like the original playstation controller), but it played a hell of a lot better.

Conclusion: if you’re feeling bored, give it a shot. Good for a bit of fun, and it has a level editor as well!
(which can be seen in this impressive edit I made here

Keep up the good work, guys from SMC!

Not just the DOS stuff from back then was great, but also the console games.  We had a NES and later a SNES and games like Zelda, Mario, Mega Man and Double Dragon gave us a lot of education

Somehow we missed the Final Fantasy series though, but one of the things I often play these days is one of the RPG genre.  In fact, I played Final Fantasy 2 on my laptop just a week ago

“But how, my stupid x86 machine doesn’t accept these cardridges!“.

Well, you need a bigger hammer obviously. Try stuffing them into the PCMCIA slot if you have one, I hear they are twice as fast. Or if you strip the plastic casing you can maybe insert them into an ISA slot if you still have one. You might need an adapter for the PCI slots though.

…

Oh, you’re still here? Well, ok, try an emulator if your slot smashing skills aren’t up to par.

<rant alert>

So someone explain to me:

If you’re writing an emulator…. you know, a thing that has to waste tons of CPU cycles in order to play dress-up and imitate a console with a different architecture…

Why the # wouldn’t you make it as cross platform as possible? Yeah, sure, I understand that you want to make it fast and hack in some assembly code. In fact, I love assembly code

However,  that concept is getting more obsolete every day. So if you write an emulator, MAKE SURE IT COMPILES ON BenV’s MACHINE!

That means it should run on at least x86 AND x86_64. Why write an emulator that’s obsolete even before you finish it? I’m looking at you pcsx2 -.-

Applaud to DOSBox for that matter, they get it right.

</rant>

So anyway, for the NES games I suggest using FCEUX these days. It runs on both x86 and x86_64, and it runs my games on my new slackware 64 installation… which makes me happy

For SNES I always used ZSNES, but they’re still stuck in the DOS era… trying to upgrade their obsolete assembly code to more generic stuff like the QT toolkit. It works great if you have an x86 installation, but it refuses my new slackware 64…. and I refuse to chroot back to my old slackware32 for an emulator like this. Puh, I’d sooner start it in dosbox :p. “But BenV, how do you play A Link to the Past then these days?”. Ahh, a good question, but it’s easy: I simply use bsnes. Runs all my snes games so far

Then there’s the matter of the prutsstation, or PSX. Yeah, that’s another disaster area… let me know if you have a decent emulator. Guess I’m stuck to using epsxe in a chroot environment for now.  Other than that it works pretty well once you get the plugins etc sorted, but I haven’t touched it lately. (guess why).

For N64 we have another good emulator these days, called Mupen64plus. To my surprise a simple recompile worked on slack64, so no issues there (good coder ). And it runs zelda, what more do you want?

Then there’s the new PSX, or PSX2. Yeah…. that’s in the same (sinking) boat as the PSX. Only 1 reason to play: final fantasy. Only 1 somewhat decent emulator for this: pcsx2. Unfortunately it feels like they don’t give a damn about linux, and certainly not 64 bit linux. They “dropped the 64 bit build”…. idiots. So if you feel like it you can get it running on 32 bits, which I’ve done, and it runs ok. But you need a fast pc (multicore) and a decent graphics card and then it still runs like a garbagecan on wheels. (the wheels come off every 3 meters and you have to open the lid, shuffle the garbage around and close it again before it continues). Of course they are quite active, so that’s good, there’s still hope. For kicks lotjuh tried running this thing on windows, and it runs a bit better there, but they still have a lot of work to do. Let’s hope they consider dropping the 32 bitch port and switching to 64 before they’re even obsolete in windows land.

That’s all the emulators I can think of at the moment… or at least, that I want to talk about, this page is getting long enough. Yeah, there’s plenty more, like mame,  ccs64, stella and whatnot, but you can handle google yourself if you want to play those things.

Oh yeah, one more important thing: Gamepads
If you want to play these console games, you want… I’d almost say -need- a gamepad. Final Fantasy and Zelda can be played with the keyboard just fine, but you’ll be crying me plenty of rivers if you attempt to complete Mega Man or Double Dragon with the keyboard. A little while ago I got myself a Logitech Rumblepad 2 which I’m quite happy with. Yeah, it’s not a rectangular box that’ll give you hernia and makes your skin come off after playing a few hours of mario like in the old days, so you’ll have to miss out on that nostalgia….

but like I say, I’m quite happy with it. It even vibrates if you push the right button . Needless to say it works under linux…. although you will want to enable the kernel option for it. My kernel config has CONFIG_LOGITECH_FF=y, CONFIG_LOGIRUMBLEPAD2_FF=y, and CONFIG_HID_LOGITECH=y, and so far all decent emulators play with it without much hassle.

So if you’re bored, go get one of these emulators, a gamepad, and give it a shot!