Here what I have done...
WinGetDisplayExtent(&DepthWidth, &DepthHeight);
theBitmap = BmpCreate(DepthWidth, DepthHeight, bitColourDepth, NULL, &err);
if (theDepthBitmap)
{
DepthWindow = WinCreateBitmapWindow(theDepthBitmap, &err);
//the display screen
theDepthBitmap = WinGetBitmap(WinGetDisplayWindow());
screenH = WinSetDrawWindow(DepthWindow);
//drawing the screen over to the offscreen bitmap??
WinDrawBitmap(theDepthBitmap, 0, 0);
WinSetDrawWindow(WinGetDisplayWindow());
WinDeleteWindow(DepthWindow, false);
}
Should theBitmap be 8bit and of the screen that I took??
Landon
On 6/8/05, Logan Shaw <[EMAIL PROTECTED]> wrote:
> Landon Cunningham wrote:
> > What I am trying to do is take a 16bit color screen and send it over
> > bluetooth to a base computer. I have already done it for 8 bit and
> > below through converting to a gif and then sending. But for 16bit I
> > need to convert to 8bit and then create the gif. Which is where I am
> > stumped. I have tried changing the screen to 8 bit and then converting
> > to gif and then returning to 16 bit but for some reason the palm
> > crashes with a fatal error.
>
> What about creating an 8-bit bitmap, wrapping an offscreen window around
> it, and then doing WinCopyRectangle() from the draw window (screen) to
> your offscreen window? If I'm right, that will cause the OS to do the
> 8-bit conversion for you. You're going to wind up with a huge bitmap
> (more than 64K) on 320x320 devices, though, which is tough to allocate
> because of memory limitations. But it can be done if you have the memory
> available and you use the BitmapRsrc sample code available on the
> developers' site.
>
> > I would like to be able to create
> > screenshots in every application ...which I have handled through a
> > custom launch. I have thought about just sending the bitmap with maybe
> > rle compression with the bitmap compress function. But would that do?
> > or would it be too big and and too slow?
>
> In theory you could just get raw pixel data (or maybe a simple format
> like PPM) and then compress that with zlib. It shouldn't be too much
> worse than GIF because, although GIF is 8-bit pixels, zlib is a
> better compression algorithm than what GIF uses (LZW).
>
> Or, if you want to do something really ugly (but perhaps expedient),
> consider the upper byte of each 16-bit pixel's value, and make a GIF
> out of all of those. Then repeat with the lower byte. Then you
> have two GIF files which together can be used to reconstruct the
> original 16-bit image. This only works well if you have control
> over the receiving end, so that the ugliness doesn't have to be
> exposed to the rest of the world. :-)
>
> - Logan
>
> --
> For information on using the PalmSource Developer Forums, or to unsubscribe,
> please see http://www.palmos.com/dev/support/forums/
>
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
