**** Philtopia ****

On my never ending quest for as much gaming as possible on my little Raspberry Pi I was remembering a time where the laws of physics were mostly irrelevant and the frags were plentiful.

Quake

The original quake, no bloody 2, no bloody 3 and no bloody 4! Just pure fast paced carnage. So I pulled up the latest Quakeforge repository and decided to see where it would get me.

The long quest for Quake

The first problem I ran into was fairly minor but it seemed Rasbian defaulted at bison 2.5 and QF required 2.6 for some bloody reason. This was no big deal I just downloaded the source, compiled it and away it went. The process griped about a few more libraries along the way but they were all available from apt-get from that point on.

Once I had all the dependencies and ./configure ran its course I had a nice status menu of what it was building when I did the make.

The make process took a long time, walk away, go to the store, do something. This is a low powered single processor machine and it takes a while. Make sure you have everything configured the way you want as well as any changes makes it start it all over again.

So after growing a beard and starting a small garden in the back yard my first attempt at QF was compiled. Excited I typed nq-sdl to be presented with an error “libGL.so not found. QF defaults to the GL version it seems.

nq-sdl +set vid_render “sw”

Tada! we have Quake! the screen was a small window in the center of my console to correct this I had to revise my startup command

nq-sdl +set vid_render “sw +set vid_width “640” +set vid_height “480”

Now we have full screen Quake! Almost immediately though I noticed something was wrong. First the sound was popping. Eventually the client would become unbearably slow and fill the console with errors stating it was out of channels.

Secondly any time the player hits an item or is damaged the screen flickers for about a second. Very distracting, very annoying.

Sound problem

I reconfigured and disabled ALSA and OSS drivers with –disable-alsa and –disable-oss as I was trying for an SDL only build. This fixed the sound issue 100% No popping, no eventual slow down and channel problems.

Flickering problem

This issue took me a day or so of on and off investigating to isolate as I have never dealt with the Quake source directly before.

Eventually I came across a file called cl_view.c which had 2 functions as plain as day for handling damage and bonus collections with a palette change “flash”. What I did just to see if I had the right idea was block out the cshift variable changing with an #ifdef block and recompiled.

Sure enough no more flicker. Not sure why it’s broken on software rendering but I filed a ticket to the project and hopefully someone properly fixes it someday. For now it works for me time to move on!

Arcade controls

Come on, you knew that was coming… heh. Yes I got Quake working with my arcade controls. At first I tried handling it through the quake menu system under controls -> bindings but this wasn’t actually setting the functions I wanted to the buttons I wanted.

I eventually had to manually edit ~/.quakeforge/id1/config.cfg and set the bindings manually to match the keys my retrogame was sending to the actions I wanted. It was a bit tedious and manual BUT I got the results I wanted.

Retrogame changes

With the existing setup I had I could pull up the menu with the KEY_ESC vulcan nerve pinch that the code already had but to select items I needed a KEY_ENTER. What I did was added multiple key combinations to the code so I can send KEY_ESC, KEY_ENTER and a specific system halt combination. This allows me to navigate MAME, Super Mario war and now Quake with ease. I have uploaded all my retrogame changes to github you can view them here.

Not done yet

Now what about multiplayer? Don’t worry, I am going to do something special with qw-client-sdl in this regard. I’m sure there will be a post in the future about it.

4 Comments

Ever play Super Mario War? If you haven’t it is essentially Super Mario death match in the setting of SMB1,2,3 and Mario World graphics.

It’s you and 3 other marios trying to stomp, hammer, shell, b-bomb each other to death until you have no lives left. There are other game modes like chicken, ctf and king of the hill to keep it interesting but to put it plainly it is a great multiplayer game.

I decided to see if I could get this running on my Pi and not only just running but also working with my arcade controls.

I downloaded the source yesterday and at first ran into a few basic issues, Installed LibSDL, SDLMixer, SDLImage ,  blah blah blah packages. Long story short I got it working but the backgrounds were garbled, maybe 1 or 2 maps were playable. Refreshing the maps list caused a crash after about 6 maps as well.

Still a success, it was working in some manner at least I thought

Today I was investigating how to correct that issue when I came across a Raspberry Pi Forum post outlining a better and simpler method to get it running and it had a patch. A patch that I had hoped resolved my garbled maps issue.

Script:

wget --no-check-certificate https://aur.archlinux.org/packages/sm/smw-svn/smw-svn.tar.gz
tar -xf smw-svn.tar.gz
cd smw-svn
svn co http://supermariowar.googlecode.com/svn/trunk smw
cd smw
dos2unix configure
chmod +x configure
patch -Np0 < ../gcc.patch
./configure
make

I modified the script slightly to add –no-check-certificate to the wget (as mine failed by default with it not present) and it was off to the races. After about 20 minutes the script had done its job. The SVN was downloaded, patched, configured and compiled.  Once you have run sudo make install you should be able to execute the game with “smw”

Problems

Unfortunately the background issue and map crash was still present. I had noticed however some maps now appeared to work so I started going through the list pruning the unplayable maps and the ones that caused the game to fault.

It’s also occasionally crashy it was a beta after all and despite my efforts I can’t seem to find a copy of the older more stable 1.7 source. Despite the problems it is well worth the effort to install.

Controls

The controls for SMW are 100% customizable for game and menu input. This means anything SDL can detect as an input you can set up. You may need a keyboard at first for menu enter/cancel until you set up a primary controller for that but once that’s covered keyboards can be put away!

The first controller I obviously set up is my arcade controls. Works 100%

Second was a semi busted ps3 controller I have that doesn’t work over bluetooth anymore but still works as usb. The PS3 controller I tried to plug in through my keyboard first but the bus power was too low so I plugged it in directly to the Pi. After that I started SMW and it was detected automatically.

You can have upto 4 players so technically with a good powered hub or 4 bluetooth gamepads you could have a lot of fun with this game

Share your thoughts