Main Site Documentation

Always Double-Buffer!


#1

I’ve been doing a lot of graphic intensive work; moving a mouse pointer in real time, game engine, etc.

I always knew doing a full flush chewed up more time than flushing only the affected regions but let’s really break it down.

Moving the mouse cursor around it’s so slow doing a full flush you can’t even really use it. So I double-buffered it and oh is it snappy.

Next the game engine; that was always double-buffered to assist in scrolling. However, I opted for full flushes every time; figuring w/ the number of objects affected it would be best. NOOO.

Break down of a render loop:
Reset variables, Check Pause Button, Auto Scroll: 0.0006sec
Check Joystick (intensive): 0.0009sec
Move, Animate and 6point collision detect character: 0.002sec
Copy buffer to front: 0.1176sec
Manage 14 enemy animations & movement: 0.0043sec
Calc & Display FPS: 0.0080sec
Full Flush: 0.1088sec

So just doing copy/flush takes 0.2264sec
Everything else combined takes 0.0158sec!

I spend about 20x more cycles just copying and flushing. I’ll let you know what the new numbers are after I’ve had 14 enemies and 1 character copy and flush out only their affected regions.


#2

And the results are in after changing from full to partial flushes the new totals are:

Reset variables, Check Pause Button, Auto Scroll: 0.0006sec
Check Joystick (intensive): 0.0009sec
Move, Animate and 6point collision detect character + Partial Flush: 0.0067sec
Manage 14 enemy animations & movement + Partial Flush: 0.0056sec
Calc & Display FPS: 0.0080sec
Full Flush: 0.1088sec

This has taken me from a High/Low of 30/24FPS to 54/70!!


#3

Yes and it is even a lot worse on larger displays


#4

@ Skewworks: In the datasheet of the LPC controller, I read somewhere that “Cursor support” is built in in hardware. The controller does the overlay for you without removing the underlying pixeldata. You might want to check this out.


#5

Oh yes, you can do cursor in hardware. I do not even think you need RLP, just use register access.


#6

Nice! 8)

I’m going to keep the existing code for now, but I’ll look into the hardware cursor. I’m mostly concerned about supporting other LCDs :wink: