Dimming the Screen

Another quick update. I’ve added in “drawPixel()” and associated clipping methods to the GraphicsPort class. The signatures were there, but the functions were missing. Oops.

I’ve also added a new “DimmedScreen” class to the “bonus” folder rather than the Woopsi folder as it’s a hack job - look at the source for some nasty direct framebuffer access. It’s not particularly fast, either. However, it might come in useful. It follows the pattern of the now-defunct “ModalScreen” class, with one difference. Instead of just erasing itself, it dims the display behind it. Any gadgets within the screen don’t get dimmed. If you’ve seen Ubuntu asking for your password before you delete a file called “kernel-something-or-other”, you know what I mean.

Here’s a screenshot:

Ubuntu-Style Dimmed Screen


Jeff on 2008-05-02 at 01:36 said:

Speaking of frame buffer access, one of the other things on my ideas-list was a function to create a screen snap from within your app. The code to write a .BMP format file is relatively trivial.

It should be an extra, since it mandates libfat which you don’t want baseline Woopsi to need.

Jeff on 2008-05-02 at 08:33 said:

I’ve had a chance to look at it closer now. Nice hack, you could be using pointers a lot better to avoid all that multiplying. And there’s no need to shift green down by 5 - just mask it, then compare with 10<<5 and subtract 10<<5. Ditto blue with 10<<10

And since you are inside the clip rectangle, you shouldn’t need to write back through drawPixel(), should you? Surely its just as safe to write back to the screen directly if you are allowed to read it?

Also, can you get the base pointer of the screen memory out of the GraphicsPort somehow? Rather than assuming you are on screen[0]

(Its a really neat hack, I’d like to use it behind all modal windows)

ant on 2008-05-02 at 09:26 said:

I updated the version in SVN earlier. It doesn’t use the GraphicsPort any more but writes directly to the frame buffer instead. You’re right - the gadget already knows the correct drawing region as it’s passed in as the clip rect. Sending the draw back through the intensive clipping routines doesn’t make any sense. Much faster now.

It gets the physical screen number using the - ahem - getPhysicalScreenNumber() function. Lets us get straight to the right framebuffer.

Heh, like the intensity-halving function. I’ll use it!

Jeff on 2008-05-02 at 09:45 said:

Actually, why “subtract 10” when you can just “half-intensity”. Something like:

rgb = get-pixel(); rgb = ((rgb >> 1) & (15|(15<<5)|(15<<10)) ; put_pixel(rgb |0x8000);

while that looks complicated, most of the math should constant out by the compiler.