I see you're still pretty active on these forums, so I thought I'd post here about a problem I have.

I'm not sure if you remember me, but I was active here about 3 years ago... Then I got sucked into something else, and now after all those years I'm finally back trying to make a come back hehe... Just trying to figure out the stuff I've done back then. I was the guy who helped you find a bug in v7.5.3 with BmpInfo() pointers.

Anyway, I looked over all the posts/threads I've made here and more or less successfully restored all my work on the PDA I had. It's a Sony one with a high res screen and Palm OS 4.1.

The one thing I can't seem to figure out is how to get the high res to work along with buffer operation. In your latest documentation, I see the following warning under the Sony() function:

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">WARNING: A number of PToolbox drawing features will behave strangely in pre-OS5 Sony high resolution mode (320x320), though many will draw as if in 160x160 mode. The functions which behave oddly or badly in high-resolution mode are:

All the screen buffer functions, with the exception of ClearBuf(). Full sized scratch buffers actually work in low screen depths, but any graphics drawn in them using the standard drawing functions will use a 320x320 coordinate scheme. Higher screen depths will likely cause the heap to overflow, especially when more than one buffer is in play.
...<hr height="1" noshade id="quote"></font id="quote"></blockquote id="quote">
So it seems like that's nothing unusual - the buffer operations (like drawing to an offscreen buffer, and then copying its contents to the display buffer) will reset the high resolution back to low res with 160x160 coordinates. However, I'm pretty certain this used to work fine before. At least judging by my 2nd reply (3rd post from top) at http://www.orbworks.com/forum2/viewtopic.php?t=2691 - I had high res graphics and buffers working together properly.

This code, doesn't work in the 320x320 res anymore with the latest version of PToolboxLib (v7.6.1) and PocketC (v7.1.3). If I comment out the offscreen buffer lines (ie. SetDrawBuffer(1) and CopyBuf(0, 1)), the sony high res mode works fine now. But not with the offscreen buffer code still in there.

So basically all you can see is the top left quarter of the screen with all the pixels doubled (ie. 160x160 res). I'm pretty sure it used to work properly before. Of course all this was 3 years ago, so I might be wrong... =/ But I do have a lot of code snippets and a part of my game written that uses code along the lines of what I posted above, so I'm assuming it did work back then...

My guess is it used to work with an older version of PToolBoxLib... I've tried searching for where I could get one, but without any success ( you've sent me an older version by email when you fixed that BmpInfo() pointer bug, but I don't have that email anymore =[ ). Do you have any older versions that I could try to see if it fixes the problem... I'm thinking version 7.5.3 or maybe v7.5.2 was the one I used back then. Thanks a lot. You can send it to my username at hotmail dot com if you don't mind please.

Thanks in advance for your help. I know using a Sony PDA with a high res screen and Palm OS 4.1 is pretty outdated these days, but I'd really like it for my game (or at least the part of it I've finished back then) to display correctly on my PDA hehe, if it's not too much trouble.

I was just randomly surfing when I thought I got sooo lucky. I accidentally found a program that uses PToolboxLib and had the version I was looking for - v7.5.3 - included in the zip file (it was artBMP v4.0). Then I looked inside the folder where I extracted the latest version of PToolboxLib and I was just shocked... There it was, v7.5.3 that I so needed sitting right in the most obvious place. How I missed it, I still don't know.

Anyhow, I deleted v7.6.1 off my Clie and threw v7.5.3 on, and viola, the little test snippet I have above worked like a charm in 320x320 high resolution on my Sony Clie with PalmOS 4.1. Of course, I tried my (half-finished) game that wouldn't work in high res before and it also appeared the way it was meant to - in high res.

So it seems that the v7.6.1 ruins the compatability of Sony high res support and buffer operations, when v7.5.3 had it working right. I'm guessing it has to do with the optimizations you've done in CopyBuf() as noted in the history: "CopyBuf() speed up (now a hair faster then PocketC's bucopy() function)."

My question is would it be possible to restore this functionality and make it work along with all the new features and bug-fixes of v7.6.1, or is this something that'll have to be left the way it is (I'm guessing you must be busy now, since there haven't been any updates to PToolboxLib in so long)?

If you're interested in that, I'll try to help you out if I can. I can figure out exactly which buffer functions it is that reset the resolution to low-res on Sony/POS4.1 devices.

Yeah... Unfortunately, you can't use PocketC Architect on PalmOS 4.x so I'm left out on that one. =/

I've tried the beta version 7.6.2b9 of PToolboxLib and it doesn't produce results any different from v7.6.1. However, I've done some further testing using v7.5.3 and while it does seem to have some limited support for buffers under Sony hi-res 320x320 mode, it's not without it's problems.

I've ran into the problems since my newer Sony Clie (PEG-SJ33) is a colour device (although still based on Palm OS 4.1, not 5.0+), and I was able to set the colour depth to 8 instead of 4, and that's when the problems surface. When trying to CopyBuf() from an off-creen buffer onto the display (buffer 0), it doesn't copy the entire buffer but only a part of it (about half). If I set the colour depth to even higher (16), it copies an even smaller portion, about 1/8th of the screen, while leaving the rest of the display screen untouched. Under depths 5 (16 colours, I think, but with some colours - it doesn't look pretty though) and 4 (16 grayscales), however, it does copy the entire 320x320 offscreen buffer fully onto the screen.

At first I thought I had run out of the heap memory when creating those off-screen buffers, which seemed unlikely. After all, it was a decent device, and I only had 2 off-screen buffers (a 320x320 one and a smaller 310x240~ish one). Still, with 8 bit colours I thought it was a plausible cause. So I did some tests with the HeapSize() function as noted in your docs, to determine if there was indeed enough space. Turns out, there was more than enough. I was able to create around 10 off-screen buffers with sizes of over 600x600 in 8 bit colour depths before completely running out heap space (which caused a fatal error in an allocating memory .c file, btw, requiring a soft reset, unlike it was stated in the docs that you would "get a 'Failed to create draw buffer' system error if this is the case", but that's not important I guess).

I forgot to mention when I tried to replace the CopyBuf(0, 1) call with an equivalent CopyRect() call, not only did it slow down the program by far, but also reset the graphics mode back to 160x160 (under PToolboxLib v7.5.3 that is, which allowed the Sony hi-res mode to work while using buffer operations). CopyRect() does work fine, as long as you copy from an off-screen buffer to another off-screen buffer without ruining the hi-res mode.

So that caused me to kinda give up on getting this whole 320x320 colour graphics with full support for off-screen buffers on an outdated Palm OS 4.1 Sony device thing to work. It seems the software these days (at least the regular PocketC and PToolboxLib) is more centered around Palm OS 5.0+. At least not the Sony hi-res devices with Palm OS 4.1. So I'd probably have to work with pure C++ code instead, and that's way more trouble than I'd want. I'd lose my ability to code on the device (which is very important to me), and I'd have to get all the software for coding for Palm devices on a PC. x.x Besides, I just learned that my dad's Dell Axim x51v has an Intel 2700G media accelererator supporting OpenGL|ES, so I decided to check that out hehe. After trying some demos of 3D games I'd have to say it's pretty damn impressive.