Rasperoids!
Community Forums/Showcase/Rasperoids!
| ||
| Here's the very first ever build of Digesteroids for the Raspberry Pi. For those that don't know, Digesteroids is a sample game that comes with BlitzMax. It's like a tasty-looking asteroids clone. You will need : 1) A Raspberry Pi 2) Reasonable expectations Download it here : digesteroids_rpi.tar.gz 3.7 meg To run it. Unzip the zip, and on the console type something like : ./digesteroids If all goes well, the screen should show the menu and music will happen. (I've got sound coming out of my monitor via the hdmi cable - which was a bit of a surprise, as I've never had the Pi make any sound until now!) Notes ----- * There have been no optimizations - the Max2D code is basically a OpenGL ES 2 friendly port without optimizations. * Sound is crackly. (but hey, we have sound - which worked first time. Skid Rocks!!) * Screen resolution is fixed to whatever you have set your Pi up for. The nature of graphics driver means that is the resolution your game will run at. At the moment, the game is not scaling the graphics up to fit larger resolutions (so it may just render in the top-left corner of your screen). * Only works from the "console" - i.e. don't run it from X11, run it from the command-line without X11 having been started yet. It seems to be another thing with the way the graphics driver works. * It uses the new SDL-based backend modules to drive both graphics and user input. As I say, don't expect too much. Just think along the lines of - "Cool, BlitzMax can do games on ARM-based computers! How exciting!" |
| ||
| It's like a tasty-looking asteroids clone. Crumbs, that description takes the biscuit... |
| ||
| One of the best feelings in the world when you tinker and tinker on in code, hit the build and run button and it works! Well done and keep it up! :) Dabz |
| ||
| Next to the odd feeling when coding and coding / tinkering and tinkering ... and then pressing "compile" and... it compiles. I think everyone of us knows that "press compile, see what fails, fix this, press compile ... fix next... " is the common usage - isnt it ? Think it's time for the Queen to close her MaxIDE and appoint Brucey to be Sir Brucey :D. Enough of brown-nosing. bye Ron |
| ||
| Nice work! :) |
| ||
| Awesome Brucey ! if you have networking commands within i steal your ssd ;) anyway , any chance for network sockets also ? |
| ||
| couldnt you just use TProcess and then ftp/ssh/ ... most of the Raspis will have ssh[-server] installed for remote access. (I mean: such things like networking will surely come ... first bruce had to make the debugger working ... to debug things there the error happens :D). bye Ron |
| ||
| Networking is already working - one of the first demos I did on the Pi was a websocket server demo - the Pi acting as a server that you connect your browser to :-) |
| ||
| great ! id like to read your progress with Rpi /Arm. |
| ||
| Brucey, which audio driver are you using? An increase in buffer or fragment size should fix the crackle. |
| ||
| which audio driver are you using? I'll say "probably" pulseaudio, although it's meant to fallback to ALSA if it can't start pulse. Would that be making LINUXFRAG larger? Any side effects if I change this? |
| ||
| isn't this just the buffersize? if yes, no side-effects than "more latency" (when filling dynamically) and an increased ram-usage. According to the source, "LINUXFRAG" is exactly the one defining the buffer size. So yes, LINUXFRAG. EDIT: "fragment count" is defined in the files too: alsdevice.cpp: fragment_size=LINUXFRAG; //overall buffer size fragment_count=2; //2 - 16 fragment count - 2 minimum, the lower it is potentially the lower the latency Means, the buffer size does not directoy adjust the latency. bye Ron |
| ||
| The idea is to add more latency so the audio hardware always has enough samples to avoid the overrun that causes crackle. |
| ||
| any news on this Brucey ? |
   |