Skip to content

**** ****

Arcade stand up setup @ the trailer

September 5, 2014


As anyone who has read my blog must have noticed by now I post a lot of Raspberry Pi articles and a lot of Arcade emulation articles. My current arcade console has provided me with hours of education and entertainment in both areas. I usually play sitting down in front of the TV at home or at my trailer but at the trailer I have the issue where the TV is mounted up high. At the wrong angles it can be difficult to see what is going on.

So last weekend I was playing and I had my chair out as I usually do and somehow I suddenly got this idea of putting the Arcade controller where the DVD’s are and pushing back the TV.

I moved the Playstation 2, DVD’s and games out of the way and sure enough the controller fit easily in the spot. I hooked up the HDMI and power and gave it a whirl.

Perfect

Now while camping I have a poor mans stand up cabinet!

Share your thoughts

Model railroading updates

August 14, 2014


I haven’t posted a train update on the blog in a bit so I figured I would give a quick summary

N Scale

I sort of stalled here for a bit but I have returned to it. Finished laying roadbed on the board and I have track held in place with nails currently until I glue it in place and ballast it.

I took a video of a test run here

The equipment is old and only has one set of powered wheels so it stalls on the turnouts sometimes.

HO Scale

Still no home layout and it will probably continue that way as I have the club in Fenwick to get my train fix every week. I took a pair of new videos one featuring CP Rail and of course it wouldn’t be me if I didn’t also do a Chessie System!

CP Rail video here

Chessie video here

I have also taken a lot of photos of the trains on the layout which I will show off at the end of this post. The best way to follow my train escapades now is probably YouTube or Twitter so follow me there!

Share your thoughts

Raspberry Pi gaming information.

August 5, 2014


The Raspberry Pi makes a great gaming choice for those who are interested in classic gaming such as Emulation or even some older FPS action such as Quake 1,2 or 3.

However, there are a few tweaks and caveats one should be aware of with the Pi before diving in.

SDL 1.2 vs SDL2

SDL 1.2:
SDL 1.2 is tried and true and has 1000’s of applications for it. It also has a specially modified release for the Pi to work on console allowing you to save resources by staying out of that cumbersome X windows environment but there are some limits.

Every SDL 1.2 application I’ve used on the Pi seems to scale to 640×480 max on the console, regardless of your video connection. It can go lower (if you’re using sdtv) but not higher it seems. If this is incorrect I have yet to see a way around it. It does scale to the size of your display though so impact is minimal and the low resolution is actually better for your Pi’s performance.

SDL2.0

SDL 2 had Linux console usage built in so in SDL 2’s natural state from source you can achieve X-less running. That being said however SDL2.0 unlike 1.2 will use your displays natural resolution for output, anything smaller (forced by the application) becomes a smaller screen inside that natural resolution and does not scale (yet, I hope this gets fixed). The problem with that is if you try and run a game at 1920x1080p there’s a good chance it could perform poorly. SDL2 also only feeds its resolution calls that one resolution you are set at so you can not change it from within the game (once again, hope they fix that).

However, you can force the issue with your /boot/config.txt

If you set an HDMI or DVI mode of a lower resolution (that your display supports) SDL2 will use that instead for your game. I don’t mean change the framebuffer size, that ** will not help in this case ** you have to actually set your hdmi mode itself.

For example 720p instead of 1080p:

hdmi_drive=2
hdmi_mode=85 #720p

If you just wanted a smaller X and linux console for example you could just do:

framebuffer_width=720
framebuffer_hieght=480

You will get an apparent resolution change but in reality your Pi is still operating at the displays full resolution and only the framebuffer is displayed in that resolution. Since SDL2 actually utilizes the Pi’s video driver it will ignore this and initialize the program you start at the full resolution so if you want to control SDL2 resolution use the hdmi_ config options in config.txt.

GPIO uinput gaming devices:

SDL2 breaks them at first. The issue was explained here. If you make a udev rule or alter the file I talk about there you can re enable those devices for SDL2 applications without affecting SDL1.2 usage either.

Raspberry Pi CPU

The default clock is 700mhz. If you plan to play games you have to overclock. I personally use the high setting in raspi-config which sets it to 950mhz. I have tried 1ghz but I found I would get a hard system lock from time to time. Results may vary.

Go have fun

It’s easy to turn the Pi into a retro gaming powerhouse and there are endless community resources at your disposal. Just keep in mind the limitations above and you will be up and running in no time.

 

Share your thoughts

SDL2 and retrogame

July 18, 2014


It doesn’t work!

Or does it…

Anyways as usual in my quest for using my Arcade controls to do just about everything I ran into a snag with OpenParsec yesterday…. Turns out it wasn’t accepting my arcade controls.

In a convenient sort of way the main retrogame git had a user pop in complaining of the same problem. Well this just won’t do at all I thought and I jumped into the problem!

I spent a lot of the day in udev and evdev docs and I did evtest and udevadm tests and EVERYTHING says retrogame works with evdev but it wasn’t with SDL2.

After my brains felt melted I took the day off to think about it and went back into it about an hour ago. This time combing through SDL2’s code as my tests earlier proved retrogame was working with evdev as far as Linux itself was concerned.

SDL_udev.c

val = _this->udev_device_get_property_value(dev, "ID_INPUT_KEYBOARD");
if (val != NULL && SDL_strcmp(val, "1") == 0 ) {
   devclass |= SDL_UDEV_DEVICE_KEYBOARD;
}

I was reading through this file and came through a case block where it identifies devices. It bases this on whether the udev has the property ID_INPUT_JOYSTICK, ID_INPUT_MOUSE or ID_INPUT_KEYBOARD. Boom there it was. retrogame only identifies as ID_INPUT_KEY but to me it didn’t seem to make sense why they would be so specific when in some cases other devices may identify as ID_INPUT_KEY or ID_INPUT_REL/ABS instead of the obvious KEYBOARD or MOUSE. So anyways I posted my changed file on github and I am going to ask SDL why and see if it was an oversight or had a proper purpose.

If you use retrogame just rebuild your SDL2 with the file I provided and your arcade controls should be working again. Might also fix python and other gpio input scripts with SDL2, let me know!

Share your thoughts

OpenParsec on Raspberry Pi

July 16, 2014


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.

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:

Share your thoughts