Starduino Turbo - Star Fox inspired 3D rail shooter, better faster stronger

New Turbo version with 50% higher frame rate.

And I found a way to free up enough ROM space to add support for [hold the UP key and turn on to enter the bootloader] in both versions.

StarduinoTurbo

While working on the Uzebox port with the ATmega644’s larger RAM I added a vertex cache to the 3D renderer and that sped up the rendering so much I had to find a way to fit this feature on the Arduboy.

I needed to find extra RAM for the vertex cache and the only thing left to borrow from was the frame buffer so there are black bars on both sides.

I’ve updated the classic version in case someone prefers fullscreen … at the loss of 33% FPS in comparison.
Both include the bootloader UP key fix.

Download the .arduboy file (98KB Turbo version) to flash the game on your Arduboy using the Arduboy Game Loader from Team A.R.G. (external link)

Or the full .zip file with the printable PDF instruction booklet (600KB) and contains the .hex file to upload using avrdude or your method of choice.

Direct link to the .hex file (Turbo Version with 50% higher FPS)

Or if you need only the instruction booklet (516KB).

Cheers!

14 Likes

What an amazing job! To think it could even be better!

If you think it should be it’s own thread, then sure! I can tell you spent a lot of time on this!

How fast does it run:
Starduino Turbo 2019-07-09.arduboy

It actually seems to crash the emulator when you fire your weapon. :frowning: Hey @FManga check this out if you’ve got a moment!

UPDATE: It only seems to do this if you fire the weapon immediately within the embedded emulator. If you load it up on the full screen page I haven’t been able to make it crash.

The emulator speed is erratic especially through the arches at the beginning.

But just comparing the title screen, looking at the rotating ship you can see a big speed difference:

And also the rightmost vertical scanline shows on the left side.

I’m sorry for being a bother :stuck_out_tongue:

It may have something to do with partial screen updates.

There has been some kind of performance “bug” that has been in the thing forever that hasn’t been able to be traced down. Bone shakers runs way too slow for some reason too.

Nice work! Is the Uzebox port complete too? I would be interested to give that a go too

This work is amazing. I get so impressed how it possible to achive this kind of performance!

Congratulations!

1 Like

Soon. I got some timing/jitter issue with the video sync on Uzebox.
Just received some CPLD to capture the exact cycles count and debug this.
Will be posting it on the uzebox forum when it’s released.

Aw, I just realised I accidentally put the Turbo screenshot on the Classic version on Erwin’s Arduboy Collection. :tired_face:
It’s what happens when you do these things at 2am… Will fix ASAP.

1 Like

@eried This is weird. I just made a new screenshot (I don’t even have the old one on this computer), deleted the old on GitHub, reuploaded the new screenshot I just made.

and the wrong screenshot PNG still shows up on github in my repo fork

Cleared my browser cache and nope: still the old (wrong) screenshot if I refresh the github page.
I’m starting to think I uploaded the correct image the first time this morning but github got some bug on their site…

EDIT: nevermind, I refreshed once more and it finally updated. Their server farm have a delay updating their cache.

@eried Sent the pull request with the fix. Thank you for your collection website and all the work you put into it.

1 Like

Thanks for the submit! awesome game :smiley:

It would be nice to mix the 2 versions maybe, like Starduino Allstars version

I wish.
Enabling/disabling the vertex cache with two code paths, changing the screen area, and the extra menu entry + menu code to do this would bust the 28K ROM limit.

And I’d need some ugly code hack to partially overlap the vertex cache RAM with the framebuffer RAM to enable the switch between both modes as what I cut off the framebuffer isn’t quite enough to fit the entire vertex cache.

So in total the Turbo version takes a wee bit more RAM than the Classic version, making the stack come real close to smashing into the global variables. :stuck_out_tongue:

Any change to a C++ function that would cause the compiler to push a few more registers onto the stack would make everything come crashing down.

It’s like an end-game Jenga tower at this point. I don’t dare touch anything.

The Uzebox emulator has a RAM display/profiler and it shows less than 16 bytes between the stack and variables, I dunno exactly how close the Arduboy version comes but enabling the profiler (about 10 bytes of RAM + a bit of extra compiler stack pushes) was enough to trigger the stack smash detection/assert I built into the game.

1 Like

A different writer accidentally put up another article on Starduino on HackADay

I’m not complaining :smiley:

7 Likes

This is like the third Arduboy repost in a row what is going on over there.

3 Likes

Free advertisement?

2 Likes

Creator of Starfox plays Starduino

6 Likes