> > 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... :)
call it twice :) with the IIIc and Prism.. it swaps between two
offscreen buffers.. you'll find.. on these devices.. the memory
is actually on the VRAM of the graphics controller.. on other
devices, it creates a memory chunk on the dynamic heap :)
[check the sources] :P
> > void *ptr = (void *)WinGetDisplayWindow()->displayAddrV20;
>
> I played with this too. It still worked for me for 3.5 (on a IIIc).
yes.. but.. try it on a debug rom :) we were using this for a while
> > 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. ;)
its ok.. use API's when unsure, and assembler/assumptions when you know.
after PalmSource, i updated the cube3D/burning sources to handle this
type of thing.. they run fine on the prototype board now :)) yet, when
there is a m68k CPU - the optimized assembler routines are used.
its probably safe to assume that the non-m68k CPU will be faster :)
> 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 believe it does.. liberty runs the same :)) it would be darn slow
if it didn't access the LCD screen directly :P it runs ok with this
new API call :P
> 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.
good luck :))
a higher frame rate on the LCD displays = not worth it, really :))
for example, the cube 3D/burning demo runs at 15 frames per second.
looks smooth enough.
you can do true double buffering using the WinScreenLock() API's.
you could re-write them for non 3.5 devices by setting the LCD
display address register when appropriate,�and do all the
buffer management yourself.
PS: shouldn't you be working on something else *hint* :)
cheers
// az
[EMAIL PROTECTED]
http://www.ardiri.com/ <--- free games!
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
