>     void *ptr = BmpGetBits(WinGetBitmap(WinGetDisplayWindow()));

That's what I'm using now.


>     void *ptr = WinScreenLock(...); // (experiment with it)

If I read it correctly this will make a *copy* of the current screen, and
switch the "screen" context to that, but the real screen remains the same.
Then after you're finished drawing on the copy, WinScreenUnlock copies it
back to the real screen. That seems way slow... Especially considering that
I'm really doing the same thing only without the first copy and with a
highly tuned BLIT routine to copy the off screen buffer to the scree... :)


>     void *ptr = (void *)WinGetDisplayWindow()->displayAddrV20;

I played with this too.  It still worked for me for 3.5 (on a IIIc).


>   a little word of warning though.. while at PalmSource, testing on the
>   prototype board in the lab sessions - doing any form of direct screen
>   writing will *definately* fail in future devices (that dont use the
>   motorolla CPU). if you are going to use direct screen access, check
>   a) version of os, b) what processor is being used.
>
>   the ARM implementation may have a different endian implementation :)

Oh fun. ;)

Another question: Is the address returned by
BmpGetBits(WinGetBitmap(WinGetDisplayWindow())) the *REAL* address of the
LCD memory or is it just a buffer? Does the OS waste my CPU time by copying
the buffer to the real LCD address many times a second? Or is that handled
by separate display hardware? If so, can we talk directly to that hardware
and give it a new address for the "screen"? I'd really like to do TRUE
double buffering where you draw to an off-screen buffer and then tell the
display hardware to used that buffer for the display instead of the other
buffer. Then you write to the first buffer, etc... No copying of buffers.

I'm picky, I know! I'm getting 13 frames per second now on this arcade game
I'm writing, and that's with full screen animation. I would really like to
be up around 20 FPS though. If I could do true double buffering that would
help.

Tim Hoffman



-- 
For information on using the Palm Developer Forums, or to unsubscribe, please see 
http://www.palmos.com/dev/tech/support/forums/

Reply via email to