Grog tech demo -- By Alban

GROG - Tech Demo

Author :  Alban

G.R.O.G.: Graphics Renderer Optimized for Gamebuino

I've had this project going on since the release of my previous game, Project88. This is a proof of concept for a Virtua Racing-like engine. 

Although I am very proud of the performance level I have reached, I don't feel like I will build a game on this. What eats up CPU cycles is mostly the rasterization part, which I've tried to optimize to the bone, but not leaving many cycles left. On the memory side, my implementation is fairly light. I believe one could do a game like a space shooter, where triangles don't cover the screen, but this feels limited.

I've documented as much as I estimated relevant: specifics to the implementation, API usage, tricks etc. For 3D rendering 101, which is a huge domain, I suggest you have a look on the web at how transformation and projection matrices work, and how vertex buffers are usually used. You'll find all these notions put to good use in my code.

The link to the documentation is here:

See more
Author :  jicehel

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

Author :  Alban

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).

Author :  jicehel

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

Author :  Steph

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!

Author :  Alban

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

Author :  jicehel

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.

Author :  Alban

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

Author :  alxm

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

Author :  alxm

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.

Author :  bfx

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:

Author :  Alban

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...

Author :  Alban

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.

Author :  alxm

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
Author :  Alban

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

Author :  Alban

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!

Author :  Sorunome

Holy crap this is looking amazing

Author :  Alban

Thanks :-)

Awesome demo, very interesting and a very nice documentation! :slight_smile: Comparing this to my demo, I think you can make this run super smoothly when keeping the triangles flat. I have a few questions and notes:

  1. Does the source have any license? I haven’t noticed any at GitHub. If there’s a license, other people can make games with it :slight_smile:
  2. You have probably done it, but just asking to be sure: did you compile it with -O3 optimization? That skyrockets the performance.
  3. I think I am seeing small holes between the triangles on the road – did you use the top-left rasterization algorithm? It guarantees that there will be no holes and overlaps of adjacent triangles.
  4. Depth-buffer is possible if you quantize the values to e.g. a byte (or even a half-byte) – I am using it in my demo. From my testing it does pretty okay visually. Not sure if it’s faster than sorting and how much RAM it will leave for the actual game though.
  1. I forgot to add a license indeed. It should have been MIT
  2. Yes I have! And I also compiled with gcc 8.2.1, which provided a huge performance improvement compared to the gcc version attached to the Arduino IDE.
  3. No, I didn’t. I believe I could add this quite cheaply. I’ve relied on this algorithm:, which actually deals with the “top-left” part, but I overlooked it.
  4. I had in mind to be able to render full scenes, not just a rotating object, so having depth quantized only on 4 or 8 bits seemed a little risky quality-wise, and heavy memory-wise. I haven’t tried, so it may be a wrong preconceived idea. Sorting triangles is cheap, and, for the sake of the anecdote, I’ve had a look at games like Virtua Fighter 32X, which were very limited memory-wise, and I am pretty sure they work similarly.