**** Philtopia ****

I know there hasn’t been an OpenParsec update in some time so I decided to make it a good one. Over the last couple months I have made it my business to see how far the Pi can be stretched as far as gaming goes.

• I have a full blown arcade emulator with GPIO arcade controls
• I have Super Mario War
• I got Quakeforge to compile and run
• I also followed the Quake 3 tutorial just for the heck of it
• I also got all of the above to work with my fancy Arcade controls

But… I wanted some space combat to go with this. As my Tag cloud shows Parsec has been talked about a lot on my blog as myself and several others brought it back to life and completed some of the Internet client/server parts of the game the original developers abandoned.

Currently for our next release we are getting the last few pieces to work, teleporters, proper afterburner and invulnerability FX and networking fixes.

However, wouldn’t it also be cool if it worked on the Pi…. Yes, yes it would

Firstly, it will compile without any problems as it was. Once you run it that is where the problems start. Parsec is a GL game, and I use the term GL loosely. It was a 3DFX game that changed to GL at the turn of the century so it did all sorts of whacky things that drove our GL guy (slime) bonkers but also being GL means it isn’t hardware accelerated in the Pi.

Changing it to GLES would be a challenge. slime slowly adopted the challenge and I would follow along with tests and complaints as slime didn’t actually have a Pi to test with. He did most of his GLES testing with an iOS simulator on his mac. At one point he stalled and I did a whole bunch of crazy hacks to prove it could be done and to be honest I got pretty far, so far in fact I got to the point a screen with “precaching” would come up that locked up the Pi…..

There was also a point before that where it went to menu but no textures or fonts were loaded:

That of course made slime need to prove he could best an amateur who was only flying on blind luck so he did a proper GLES port and stated it worked in the iOS simulator. Still for me it froze at precaching.

GDB proved useless as it would not actually load the GLES context from console (bug with SDL console on rpi  maybe?)

I remember slime saying he disabled the compression routines for texturing so I went through all the .con files for loading objects. I found that in _telep, f6_2, _f7_2 and _f8_2 there was “flags compress” tagged onto the texture loading so on a long shot hunch I removed the flags.

Boom goes the dynamite.

I was staring at a Parsec menu screen with the teleporter animations on my Pi. I went through the Spacecraft menu and noticed some of the objects had no textures. It was different objects each time depending on which one was first when I opened the menu.

Maybe it was RAM related I thought. I went into options dropped the textures to 16bit and low quality and all but 2 of the ships rendered now. The first ship I had left “flags” in the texture loading line. The second stated the texture files didn’t exist.

As it turns out because I was working with extracted packs the textures for that one ship were in UPPERCASE renaming them to lower solved it. The pack manager must not care about case.

So there we have it, OpenParsec runs on the Pi, and pretty decently too. The only problem I have is the arcade controls do not work for some reason….I will have to look into that

My Rpi branch of the OpenParsec source is available here: https://github.com/OpenParsec/openparsec/tree/crazyspence

Modified Data files which do not cause crash here: https://github.com/CrazySpence/openparsec-assets-extracted

Game footage if you’ve never heard of Parsec before:

Tagged with: Game | Parsec | Raspberry Pi | Review

Categorized as: What's up