> Tilo -
> Here is what we (Red Mercury) know about WinScreenUnlock:
to fit the trend.. this is what we (ardiri.com) have investigated :)
> If WinScreenUnlock is not supported, it will return NULL.
> Devices known to do this:
> Non-color Sony Clie
> Handspring Visor Prism
>
> If WinScreenUnlock returns NULL, that means it did not switch the screen, so
> subsequently calling WinScreenUnlock will throw the "unlock out of sync" as
> you have found.
you mean to say ... if WinScreenLock returns NULL - but anyhow :P
if you check the 3.5 sources, you will see why it may return NULL.
(of course, i have not seen 4.0 sources yet - maybe its different)
i am basing this on memory, so some errata may exist:
PRISM:
-----
the prism, like the IIIc has VRAM on the SED1376 display controller
(IIIc has SED1375) it is around 80Kb in size (from memory). the
devices with VRAM support must be able to hold two screens in the
vram area in order for it to return a non-NULL result.
if you run in 16bpp, this would explain your problem :)
160x160 @ 16bpp = 51200 bytes in my books
have you tried changing into 1bpp, 2bpp, 4bpp or 8bpp and trying it?
now.. Astraware have written Zap2016!, which i assume they have got
around this limitation by allocating a chunk on the heap to do this.
why dont you ask them for some advice on this issue :)) remember,
it was their app that did fast 16bpp graphics :P
SONY:
-----
when a device doesn't have VRAM, it must be possible to allocate the
offscreen window in the heap. upon failure, it will return NULL.
upon investigation.. on non VRAM devices.. this occurs - which is
not that well implemented :)
WinScreenLock()
- allocate memory on heap if no VRAM
WinScreenUnlock()
- free memory on heap if no VRAM
that means, for each set of calls.. you have a malloc/free :) it
would have been much better to have a WinInitialize() and WinTerminate()
call to set up these buffers - but us programmers always forget to call
these types of routines, so i understand why it is there
on the SONY, the memory allocation fails. :)
> Various Palm OS licencees will continue to have reasons not to support
> WinScreenLock. For example, at a particular bit depth with a particular
> video controller, there may not be enough video RAM to double buffer. If the
> frame buffers are in core memory, there might not be enough RAM for the OS
> to allocate a second frame buffer. And if a licensee is having any problems
> implementing or testing WinScreenLock, it is legal for them to just return
> NULL according to the documentation. In other words you can't depend on it
> right now.
i believe you may be wrong here :)
i doubt each licencee are writing their own WinScreenLock/Unlock() calls.
maybe someone at Palm can verify this? i just installed "bufferoo" on my
SONY Clie S300 - works fine. no crash..
is my SONY not in the norm?
if anything, when a licensee makes some modifications its probably at
the HAL layer.. not the API's that use developers
i am sure Palm are aware of the needs for double buffering - thats why
they implemented the WinScreenLock/Unlock() API's. if they dont work
on specific devices, then it is due to hardware / memory limitations.
its our job as a programmer to work around these problems..
// 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/
