Cruiser - a 3D shooter for the Gamebuino

Hey there, here's a small update of my work-in-progress 3D shooter:



You can find the code on my GitHub site and it's still under heavy development: https://github.com/specht/cruiser.

I'm planning to add keys and enemies, but RAM is tight. The demo you're seeing in the GIF uses 1739 bytes of RAM already so there's only 16% left... ;-)

If you'd like to try it out for yourself, try this: https://nhcham.org/cruiser.hex. Feedback is much appreciated!

No words :O
Bring it on.

This is looking awesome! Did you re-use anything of myndales 3D demo?

No, it's written from scratch and it's quite different, because it's not raycasting with texture mapping like in Myndale's demo, but it's a polygon-based portal engine, without texture mapping.

If you're interested in how it works, you can also find a lot of detailed notes about the program on the GitHub page: https://github.com/specht/cruiser

Wow! Real 3D! I'm looking forward to see something from this :D

Zvoc47 wrote:Wow! Real 3D! I'm looking forward to see something from this :D

not exactly real 3D more 3D realms, joke aside its sorta a step up, its how doom is doing it
any plans for floor and ceiling height?

Yeah, it looks like 2.5D but it's actually real 3D with arbitrary camera position and orientation, but it doesn't become apparent from the video much because the ship doesn't roll when it's turning left and right. I'll have that fixed. :-)

Actually floor and ceiling height is already working, there's currently just one room employing it, it's the big one and it's visible in the video! Gotta have a word with the level design department, I wonder what they think they're getting paid for...

How come this takes up a lot of RAM? I'm a bit confused about that. If RAM is a problem, you could load the whole level into a serial 512kB RAM chip and then stream byte by byte into the internal RAM as you need it.

The level doesn't use any RAM at all, it's all stored in flash memory and it doesn't even take up that much space (518 bytes as of now). What fills the RAM is the local and global variables like frustum planes (portal engines are rendered recursively), the shots, the camera, and the stack frames resulting from function calls. Also for clipping you usually have an input and an output polygon and polygons use a lot of RAM, so I implemented a version that works in place, requiring only one polygon structure instead of two.

I'd like this game to work with a vanilla Gamebuino / Makerbuino without any extra hardware required, and unless I'm missing something, we only have 2k of RAM and 32k of flash (plus 1k of EEPROM). I have never heard of the RAM chip, could you provide a link so I could learn about it?

In order to load new levels, I would read them from the SD card, so levels are not the problem, it's more the state that takes up space.

Very cool. How are you generating your portals? BSP trees? Manually? Or are they inherent in your level structure?

Thanks! I have a Ruby script (map.rb on Github) which I use to declare convex segments, via relative "line to" statements, similar to how turtle graphics works.

The script then finds aligned segment walls and turns them into portals. It writes a header file, map.h and a visualization of the level so that I can see that everything's where it's supposed to be.

http://playground.arduino.cc/Main/SpiRAM Here you go. You might be able to use the I2C pins to drive the chipselect and reset pin of the serial RAM while using the ICSP header for MISO, MOSI and SCK. I think that MAKERbuino contains all of these pins on a header so if you can make a good PCB, you might make a serial RAM expansion module.

Now, if this rendering and the recursions take up a lot of RAM, could you possibly remove the framebuffer and render the frame by sending data onto the display dynamically? That way you could get more memory. If not, how are you going to have the in-game score, lives, NPC data, SD-card library footprint and more?

In Atmel Studio, I saw that there's a neat feature where you can set up where your CPU stack pointer is initially. If you can be sure that you won't cause a stack overflow and if you can set up the stack pointer as low as possible such as at 0x700 and then have 256bytes for everything else, that might work well. Also, you can put the rendering engine's global variables into a union with some variables that are only used while you're not rendering the game such as when you're in the main menu of the game or the pause menu or something like that. That way while you're not rendering, that memory region is used for something else. Just be sure to re-initialize the rendering engine's variables after using their memory region for something else.

You can have every function check if the stack pointer has come too low before entering a new function. That way you can prevent a stack overflow.

If you'll have NPCs and as you say you don't have much RAM, you can have every NPC have a variable that says what it should do next such as move forward, shoot, turn, run, die, etc. and have all the behaviors pre-programmed as a script in the Flash memory.

if its full 3D can you have stacked rooms?

It seems to be by the demo.
Better release a newer demo showing that off already just to make sure... ;)

nhcham wrote:The level doesn't use any RAM at all, it's all stored in flash memory and it doesn't even take up that much space (518 bytes as of now). What fills the RAM is the local and global variables like frustum planes (portal engines are rendered recursively), the shots, the camera, and the stack frames resulting from function calls. Also for clipping you usually have an input and an output polygon and polygons use a lot of RAM, so I implemented a version that works in place, requiring only one polygon structure instead of two.
[...]

You could make it dynamically re-flash a level if the level-data is alligned, i did something similar for the somehow-dead community rpg with sound data (yes it would run on the vanilla gamebuino) ^.^

AMAZING GAME!
You are the Code Master! :o