GROG - Tech Demo

Nice potential, the render of the car is not perfect but enough good to try to make a game with it.

You could draw it on a 3D track to try interactivity. It's could be nice to try this type of game. If it's works fine, you could complete the creation of the game as it seems to be the project that you have in mind

I already have a version with a more detailed track, but it shows the current limitations, which is what I actually have to rework. I have to change the way the geometry stage works to better take into account clipping in the normalized device space (clip the triangles that are part in the screen, and part outside the view).

OK, good luck and thanks for your works in this domain. When you'll complete it i hope you'll do again a tuto to explain us how it's works

Hi Alban,

Great little demo!

It's cool that you're starting to clear this area for the META... and as jicehel says, think about giving us a tutorial so we can get to GROG easily.

Come on, stay motivated! It's going to interest a lot of people around here :-)

We want to be able to code a Wipeout game soon!

This time, the design has been thought before coding, it should be easier to document ;-)

Yes for a good game it's should always be like that (thought the design before starting to code) it 's good then you developp but it's a necessity when you make a team works on it to avoid the time lost.

Well, I work as a software architect for a living, so I couldn't agree more :-)

Awesome work, looking forward to checking out future updates! I love low-res 3D.

Nice speed boost in the 1.0 update!

By the way, I get a Hard Fault Error 2 when I flash the game, turn the Gamebuino off and then on, then press A at the title screen to start the game.

Well Done!

By the way as you published it on the 1st of April, I first thought it is an April fool!

The performance is incredible. It is another good example of huge performance gain with fixed-point arithmetic and pre-computed trigonometry functions.

You write that the rasterization is the most computing-intensive part. Here there is maybe something to do with DMA. I have absolutely no experience with DMA, but this may be a good starting point:

 https://github.com/adafruit/Adafruit_ZeroDMA/blob/master/examples/zerodma_memcpy/zerodma_memcpy.ino

This is weird. When you say you flash the game, do you mean that you compile it by yourself?

For what it's worth, I haven't tried it with the standard arduino compiler but with gcc 7.3.1 + O3 compiler flag. This may explain a difference in behaviour. But this shouldn't crash anyway...

This DMA stuff looks interesting, thanks!

Update: I'm not sure this would be really usable in the triangle rasterization case. If I understand correctly, I'd rasterize one line, transfer it through DMA, while I rasterize the next one etc. As triangle lines are only a few pixels bytes wide (40 at most, but usually 1 -> 4 ), I don't think the overhead would be worth it.

But there are lots of areas where I could use this. I might have used this at some point in my game Project88, to draw the background.

Sorry for the confusion, by flash I meant launch from the menu. Here are the repro steps, it happens every time on my unit:

• Launch Grog from the menu, it runs fine
• Turn the Gamebuino off, then back on
• Grog is currently installed, so you get its title screen
• Press A on the title screen to start the game
• Hard Fault Error 2

Hmmm... Thanks for the feedback, I have this issue too :-)

Fixed. I've tagged the version as 1.1, even though the rendering library itself is unchanged. The issue was in the demo code.

Thanks for the feedback!