You da man!
Could be a great submission to the FX game jam! Should be starting in a few weeks with more details soon.
Great job on the game! Really impressive for something running on such hardware. Am i the only one who thought we could easily have a Monkey Ball game using this?
The d-pad to tilt the playfield in all direction and A/B for rotate the view left and right.
Ha! Nope! That was one of my first thoughts as well
EDIT: Other potentially cool ideas I had were:
- Shuffle Board
- Colony Wars-style space shooter
Update with those tweaks to holes 3 and 11. Hole-in-one possible on 3. Also possible on 11 but extremely hard.
The aiming behavior is slightly changed: the angle adjust starts out much slower but accelerates when you keep holding down left/right. This both allows better fine-tuned aim adjustments and turning around faster as the max turn speed is greater than before.
Oh whoah yeah this could be like an engine that powers other similar type games, incredible.
How about that balance maze puzzle game I don’t know what it’s called where you tilt the x and y axis?
Well, Monkey Ball is like, the premium version of that. The original, wooden game you’re probably thinking of is Labyrinth.
For info, I raised an issue on ProjectABE’s repo.
Initial FX version done. Currently it functions identically to the non-FX version but it has 9KB prog freed up! Plans are to use this prog for:
- interface for browsing/selecting between multiple courses
- two-player mode
- best score / best hole saving (which is better: save to flash chip or to EEPROM?)
Doing this was nontrivial but worth it. With the old rendering pipeline, working with indexed mesh involved a fair bit of random access, which performs alright if the mesh data sits in prog, but seeking all over the flash chip slows things down too much.
Instead, the rendering pipeline was overhauled to operate on the entire level data (mesh+physics) starting in buffer RAM, with careful management to repurpose data as soon as it was no longer needed at different pipeline stages. The level data then needs to be reloaded every frame before physics/rendering. Thanks to Mr.Blinky’s fine work (writing a method to have the SPI simultaneously read from the flash chip while writing to the display), this becomes zero cost compared to reading from prog!
Just quickly played the updated hex’s in your first post (using the emulator).
The OG version seems to have garbled graphics after completing the 1st hole.
The FX version seems to have the ball in an odd starting position, possibly on hole 2 (although it’s quite fun having it in the corner!), but certainly hole 3 (it’s floating in space).
Hope that helps
I also get the garbled graphics with the FX build on my device (and ball placement issues, identical to emulator)
For now I’m just running the latest non-FX build with the sounds added
EDIT: Can disregard below: Only the FX build in the emulator is faster. The non-FX version is the same as I get on device.
Question about the emulator experience. In Chrome, at least (haven’t tried other browsers), this running much faster than on my (DIY) arduboy.
I can do a full 360 rotation in the emulator in less time than it takes me to turn 180 deg on my device.
Makes me wonder if my build is underperforming (perhaps due to the way SH1106 renders).
Anyone have any thoughts as to why this is? Or, is everyone getting slower camera movement on the device?
Thanks, fixed those issues! Should have given some more testing…
Yeah, the emulator behaves differently for me on different browsers as well. I’ve gotten the fast speed you mentioned in the FX build as well, and sometimes the camera is all wobbly as if there are some fixed point math issues.
I’ve found that the most consistent performance is from using the offline version.
It’s great you are maintaining an FX and ‘OG’ version. Thanks!
PS ~ You’ve earned a new badge
Definitely planning on continuing to support the non-FX build! I now have both types of hardware, and I also like being able to play with RetroArch which lacks FX emulation.
Finally landed below par on both the top and bottom 9 for the first time.
I did get hosed on the 18th hole though, and wonder if I found a bug, or if it was intended functionality.
I made a ‘perfect’ approach shot, and wanted to do a fly-over overview before finishing out the round.
When I did that, after the fly-over, I was returned to the starting position with a 1 stroke penalty (i.e. I was now on shot 2).
Of course, I was not able to replicate my first shot, and landed myself in a bit of a disaster which blew my score, but that’s just Murphy’s law at play ¯\ (ツ)/¯
Just wondering whether or not the hole restart with the stroke penalty was the intended functionality.
Oh dear! Definitely not the intended behavior. Sorry about that, looks like I regressed the logic for the overview to reset the ball at some point. Updated with fixed versions.
FX::displayPrefetch work on SH1106 displays, or will it need a version specifically written for that, similar to the
paintScreen scenario for the Arduboy libraries?
I’m trying to get the FX version of ArduGolf working on mine, but so far, no dice.
As an alternative you could try replacing the call to
FX::enableOLED(); sh1106_display(); // <- normal display routine FX::disableOLED(); FX::readDataBytes(get_hole_fx_addr(leveli), &fxlevel, sizeof(fx_level_info));
I think this will increase frame time by about 1 ms or so which might not be that noticeable.
unfortunaly not. atm FX::displayPrefetch works for Arduboy FX only