Keith, I appreciate your feedback. Here is my impression of using WinScreenLock :
(And I'm used to issues with the Epson driver,
but I think the Dragonball is similar...)
WinScreenLock only works until you exceed the memory capacity of the graphics
controller memory - so in the case of 16-bit color,
you have a 50K screen and ~80K of graphics buffer, so you can't allocate the second
screen for page flipping and WinScreenLock
fails.
But even if I do use WinScreenLock, this doesn't answer the question, i.e., how do I
draw fast to the screen? In theory, this
saved me one screen BLiT, because I can now composite my frame right on the graphics
RAM and then just flip to it.
But, since the graphics bus is SOOOooo much slower than memory (about 1
megabyte/second max on the Epson), you really want to
minimize the amount of data you send to the screen. Since in most game situations you
are actually redrawing more than one screen's
worth (and the elements aren't aligned, and you may need to read back pixels for
masking/alpha, etc), making the graphics hardware
your primary buffer usually isn't a good idea for speed - even though the penalty is
an entire screen BLiT extra. Currently, I
still use WinScreenLock when possible -> but in addition to my RAM buffer.
Have I missed something about the way WinScreenLock works? If there's a high speed
solution out there I need to know.
- Jeff
P.S. We all know that if Palm made my "copy buffer to screen function", they'd love it
SO much that they'd put it in the PalmOSGlue
library going back to OS 2.0. ;)
[EMAIL PROTECTED] wrote:
> Why do you use WinCopyRectangle? Why not use WinScreenLock and WinScreenUnlock?
> Granted, those calls aren't in pre-3.5 systems, but then, neither will your
> "copy buffer to screen function".
>
> -- Keith Rollin
> -- Palm OS Emulator engineer
>
> DIAMOND JEFF <[EMAIL PROTECTED]> on 02/02/2001 12:00:16 PM
>
> Please respond to "Palm Developer Forum" <[EMAIL PROTECTED]>
>
> Sent by: DIAMOND JEFF <[EMAIL PROTECTED]>
>
> To: "Palm Developer Forum" <[EMAIL PROTECTED]>
> cc: (Keith Rollin/US/PALM)
> Subject: Consider providing higher speed legal screen access...
>
> It has been my experience that the single greatest cause of slow speed
> in a function is GENERALITY. Many OSes, for example, Windows and BeOS,
> have seen fit to give developers a set of non-general performance
> operations for graphics, because even a one gigahertz desktop can't
> compensate for the generality required of formal OS calls.
>
> For example, Palm could offer a performance "copy buffer to screen
> function" that ASSUMES:
>
> -> An entire screen copy (or at least a screen-WIDE rect copy)
> -> suitable memory alignment for maximum transfer speed
> -> * Buffer is in EXACTLY the same format as the screen, including pitch
> (rowbytes)
>
> I see no reason why such a function should be any slower than my illegal
> code.
>
> Then, if Palm is further worried about potential errors if the user's
> buffer really doesn't match, Palm could add robyustness and control with
> a function like CreateScreenBufferBitmap, which would ensure that the
> screen matches. If the screen changes, a single compare would then
> suffice to head off the BLiT.
>
> It wouldn't take very many non-general, performance functions to give a
> lot of legal power to game developers. Currently, I've found that my
> unoptimized C code is eight times faster than WinCopyRectangle, and I
> can only assume that's because my function is not general, but designed
> with the above assumptions.
>
> --
> For information on using the Palm Developer Forums, or to unsubscribe, please
> see http://www.palmos.com/dev/tech/support/forums/
>
> --
> For information on using the Palm Developer Forums, or to unsubscribe, please see
>http://www.palmos.com/dev/tech/support/forums/
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
