Ard-Drivin - Fast Paced Racing Sim

The display uses a simple RC oscillator to generate its internal clock. It will vary with voltage, temperature and from unit to unit.

Using an oscilloscope, I’m able to pick up radiated EMI pulses from the display that are emitted once per row refresh. From this, the screen refresh rate can be determined.

I have 3 different displays. Measuring their refresh rates under the same circumstances, I got 134.7Hz, 135.9Hz and 138.3Hz

I have 3 different displays. Measuring their refresh rates under the same circumstances, I got 134.7Hz, 135.9Hz and 138.3Hz

Very interesting, since I picked 67 fps by “feeling” when testing what refresh rate worked best, and it matches exactly with half 134Hz. This means that my grayscale technique probably flickers on some Arduboys more than others.

It would have been very useful if the display unit provided with a sync signal, so a game could “wait for vsync” or similar techniques.

The SSD1306 chip used by the display has a sync signal but it’s not brought out. Quoting @bateske:

Is it possible to read any voltage difference on the arduboy itself? to any of the connected pins show a variance that we can use to calculate the vsync?

No. The ADC wouldn’t be fast enough even in the unlikely case that it could pick up the EMI signal.

On a new device, you might be able to add circuitry that picked up the signal and locked on to it to provide sync.

Yes, and this functionality is even in the library currently (though there exists a PR to remove it):


Note this is a RAW value. If you want to convert it to millivolts you need to use a magic constant that I don’t have handy right now… as I said in the greyscale thread though I’m not sure this is precise enough to keep it “steady” but you could definitely detect the drop over time and compensate at each detectable level.

No, I think this is what mlxxp was answering when he said no.

I just added a raw voltage reading to my greyscale demo:

It’s definitely not precise enough to keep the vsync static… but does seem like you could use it as a “ballpark” with a lookup table. The issue them becomes the actual differences from one OLED screen to another that was mentioned earlier.

This is friggin sweet!! LMK if there is room to put music and SFX in this project =D

Bah. I don’t think we could get tones like that out of ATLib2. :frowning:

Yes, we can! :stuck_out_tongue_closed_eyes: all voices can be temporarily taken over and volume, frequency and square wave duty cycle can be changed programatically.


I forked the repo and already added base music to it from Evade 2 as a quick test. I still have to compose music, but the test is successful. :slight_smile:

I suggest using ATMLib2 (we’ll publish it this week) over ATMLib because there are several key advantages.

Questions for you @remz:

  • In “Rad Racer”, there was a concept of a radio where players could choose their favorite tracks. Any thoughts on this or will there be different “tracks”?
  • The sprites are rather huge and given the size of the screen and seem to be off scale a bit. Have you considered reducing the size at all? You could afford more lanes of traffic with this approach.

Quick demo on my test:


Hey @JayGarcia: Nice work :slight_smile: I would love to have some “outrun” style music
(or anything that you like :)) in the game, that would be amazing. There
was plenty of storage and ram left so that should be ok.
However on the CPU side of things I am not so sure about how much we can
afford on music processing without disturbing the rendering. But your quick
demo seems to do fine!
About your questions:
Rad Racer: Tracks, you mean “road track” or “music track”? The road is
procedurally generated while you play at the moment, so there is no concept
of tracks per se. It would be possible however.
Sprite size: Yes I went a bit crazy of the sprite size just to show off the
power of the arduboy. So with some work it would be possible to reduce the
size and adjust the game parameters (speed, collision size, etc).


How close is this to being done?

1 Like

Instead of dithering, what prevents you from switching between black and white at different intervals?
If the game is running at ~60FPS, you can have 3 modes of switching instead of 2, increasing color display at while it’s still perceived as fluid motion. I mean,

3 Mode at 20FPS:
0 0 0 : Black
0 1 0 : dark grey
0 1 0 - 1 0 1 : Intermittently switching between dark and light grey = grey (10FPS)
1 0 1 : light grey
1 1 1 : white

2 Mode at 30FPS:
0 0 : Black
0 1 : Grey
1 1 : White

Our eyes perceive motion at 20+ FPS, but color gradients are much harder to catch for the eyes.

On the other hand, you could also double 2 mode at 15FPS, adding colors:
00 - 10 Dark grey
10 - 11 Light grey

If you do use dithering, can the pattern be coded to vibrate 1 pixel across the screen? If so, one could use the dithering pattern to switch on and off a whole block of pixels.


I want to publicly apologize to @ for not being able to help. :frowning: my attention and focus was demanded by work and family events.

Who is ‘@’?

(Unrelated: the 20 char minimum is silly.)


What? :smirk:​​​​​​​​​

1 Like