I’m new to the Arduboy, and I’m learning to develop for the thing. I made a simple tiled display, and noticed the blank area in my top row is a brighter white than the rest of my display. What might cause this? It seems to happen either if I draw a blank tile on blank areas, or if I just skip drawing blank tiles. Thanks in advance for any thoughts.
The brightness of an OLED pixel depends on how much current is provided to it. The display is limited in the total amount of current it can drive, and the display drives one row at a time. So when most of the pixels of a row are on, each pixel tends to receive less current. The result is that rows with fewer white pixels tend to be brighter than rows with lots of white pixels.
You can reduce the brightness disparity by increasing the number of precharge cycles with a display command, but the general recommendation is to design your game around a white-on-black art style rather than black-on-white.
5 Likes
Doing this will also extend the battery life somewhat, since white (lit) pixels draw power but black (unlit) pixels don’t.
3 Likes
As mentioned, this is an “artifact” or a result of the physical operation of the display.
Due to this, it’s not recommended to design games that draw full white rows. The effect starts to be pretty visible once you’ve got more than about 50% of a row illuminated.
All of these kind of OLED do it unfortunately, but some have said it adds some character to the device so, hopefully you feel the same way 
2 Likes
Thanks! That is a bit of a bummer though, since I found it much easier to discern my objects when I inverted the display. I noticed some other games do this, too, like Ardynia. I may have to play around with the art to see if I can figure out something I’m happy with.
Maybe its just me but I’m not noticing any brightness difference on games like Ardynia and my own Shattered Lands that use black on white. Might be one of those subtle variations due to the nature of how the OLED display works. Could also just be that I’m not seeing it even if it is there.
I’d recommend just making the artwork in the style you like that looks good on a consistent display (how it looks in the emulator) and chalk the rest off to one of the minor quirks of the device.
Experiments with modeling this behavior in Ardens – the segment driver current (with Iref resistor, should be 195uA at max contrast) and display driver limit (15mA) from the datasheet. It looks pretty close to the actual device in my opinion.
5 Likes
Haha oh my gosh wow, it does give it that “on hardware” feel. Please only make this optional though lol.
Wondering, if you could go even further and draw the actual “pixels” in the sense, like, I don’t know how well that would work in practice but like, drawing 4 white pixels in a square and then having a column and row of 1 pixel black? I don’t think that’s quite the right ratio of “negative space” on the oleds.
I think the datasheet actually does describe the pixel size so you could calculate this…
Then you’d need a little bit of a blueish hue and some shader to add a tiny bit of glow…
It will be optional.
The grid can be done currently with the “pixel grid” setting:
This is not supported in PNG/GIF output however.
3 Likes
Wow Incredible
Now next time I do a render I can give it the best “screen images simulated” possible
Really useful addition for developers! Combined with low contrast we can design for worst case, to better optimize graphics. Small request: could we have a drop-down/ slider to increase the effect? (I observe the banding even with modest amounts of lit pixels on real HW). Also not sure whether it is a device or display setting…? 
1 Like
Sure, that makes sense. I did err on the side of being less obvious when I tweaked it.
I put it under “device” settings as it’s part of the device emulation (it’s not a postprocessing effect like the rest of the display settings). I plan to add more to the “device” tab eventually, such as flash CS port, display type (SSD1309 / SH1106), maybe CPU type (328?).
EDIT
v0.20.38
“Off”
“Subtle” (same as initial tweak)
“Normal”
“Exaggerated”
2 Likes
Looking good! The presets are nice. I imagined (if you are actually simulating electrical behaviour), a slider for the max current (µA/row)… but the presets are going to cover all use cases. Normal is perfect for me. 
BTW, on real HW does the banding ‘shimmer’ (have a time component)… or is that just my eyes?! 
Fair enough. As an end user, I’d consider the pixel grid-lines and the banding to all be ‘hardware’ limitations… but would think of them both as ‘display’ related… regardless of how or when they’re simulated… 
Oh, and to say again, a massive thank you! This is a huge aid in developing for Arduboy and it makes games joyful to play in the browser. Thanks.
1 Like
Definitely open to continue tweaking how the setting works. Currently it maintains the same 195uA per segment at 0xff contrast and 15mA row limit, but the different options differ in how the segment currents are adjusted when the limit is reached. In “exaggerated” there is a hard cutoff at 15mA. In the other two, the row current is allowed to increase beyond 15mA but at a lower rate. I’d guess that’s closer to what actually happens as analog limits aren’t usually hard cutoffs.
It shouldn’t do this… but in the case of Mystic Balloon, moving around can cause the row pixel densities to shift as stuff goes in and out of view. Do you have a specific game you’re experiencing this with?
Good point. Maybe this effect would be better implemented as a postprocessing effect, anyway.
1 Like
The effect looks great as is- so wouldn’t suggest any changes.
Will you implement for grayscale simulation too? I think this might be important for testing latest developments.
I think it may be as per your example. If I find another good case, I will be sure to share it.
1 Like
It combines normally with the grayscale filtering (“exaggerated”):
1 Like