Aaron Ardiri wrote:
> when at palmsource europe 2001, i discussed briefly these types of
> issues with David Fedor. it is something i am sure needs to be looked
> into from the operating system level.. however, it could become very
> troublesome in the event that a licensee does not implement the API
> call correctly..
>
> recent discussions over WinScreenLock() are a classic example.
>
Well, as I mentioned, if Palm was VERY concerned about the potential for error, they
could add the somewhat limiting but at least
more robust technique of a function like CreateScreenBitmap() -> this would assure
that what the suer was passing the function would
be correct.
Also, I fully realize that you'll never satisfy every gamer's needs. For example, I
need a function which at high speed copies an
8-bit buffer to a 4-bit screen, keeping the low nibbles. (BTW, movep.l works
awesomely for this!) But I don't expect that enough
gamers need this function to justify an official PalmOS routine.
But just like WinScreelLock(), every official call Palm gives us helps. I actually
started hacking the Dragonball to do
WinScreenLock before Palm implemented it. :)
Ironically though, when Palm gave us WinScreenLock, Palm actually PROMOTED direct
access, since if our main buffer is in screen ram
then we need screen access for every type of custom draw routine in our entire game!
And Palm can't cover all that! Which is why I
suggested the buffer to screen model - if you're going to implement something
officially you need the most use, benefits, and bang
for the buck possible. :)
Cheers, Gamers!
- Jeff
P.S. -> Do you guys realize that the bandwidth requirement for 32-bit / 320 pixel
screens is as much above the current 16-bit Visor
Prism as the current Visor Prism is above the original 2-bit screens? (!!! need
bandwidth !!!)
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
