> on 3.5 you have BmpGetBits() - so, on pre 3.5, you still use the old
system :(
Yep. The thing is, you want the old devices to continue using what you had
already developed there while incorporating support for color without having
to create separate application.
> however, i believe, you should do fine with certification if you
> do not directly access the screen :) in the event that you do
> directly access screen buffers, its ok, as long as you use an
> API to copy it to the display.
That's exactly what we wanted to do. We actually don't access the video
directly, as it turned out we don't have to - it's fast enough even when you
copy. Besides, we've been using SSA register on the BW devices to perform
the double-buffering in the fastest possible way by directly changing the
address of the video buffer. In IIIc SSA is hardcoded (mapped at 0x1f000000,
I think), so it didn't make any sense to write directly to it. That's why we
wanted to get as much compatible as possible at least.
The reason I needed those direct bits was only to keep the faster
DrawBitmap() we already had developed for 2bpp.
The bottom line is, Karate Master become color enabled with less than 40
lines of additional code and within few hours.
> which raises another question, what are the restrictions on
> certification, if you verify your hardware (CPU, screensize)
> before doing direct access?
I can't answer that, but tend to believe it should pass. My logic is, as
long as you take the precaution steps to inform users on unrecognized
systems or even (more rude) just refuse to run on a system you can't
recognize, it must be OK.
It is not about being absolutely compatible (???), it is about being clearly
defined within certain scope. And therefore secure.
- bobby
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
