This site is no longer active and is available for archival purposes only. Registration and login is disabled.

The future of PocketFrog


The future of PocketFrog

Postby fzammetti » Jun 12, 2003 @ 6:10am

Well, 0.7.0 is out the door now (baring any major problems), and nearly everything I personally wanted to see implemented is now in the library. A few minor things remain (built-in frame rate limiting, floodfill, filled circle, some further consistency changes, a complete SuperSample of course, etc.), but for the most part I don't have much else to add to it.

There are however two things that I personally feel are keeping PF from really competing with the other libraries out there. Yes, I know other libraries perform better, have better support and are generally accepted as better, but I think PF is still certainly sufficient for many projects, and in some ways better (source code availability and simplicity chief among them).

The two things I refer to are a custom image loader and a switchover to DirectX on the desktop.

The first is actually a pretty major problem. As I understand it from reading the GapiDraw documentation, imgdecmp.dll is very inefficient in its memory usage. I totally believe this is the case based on the fact that my Invasion: Trivia game requires about 14M to run, and that's about twice as much as I calculate it should!

GapiDraw uses a custom image loader, and I believe PF has to do the same to continue to be useful. The problem is, I'm not sure I can do this (firstly because I don't have the time to put into research, and secondly because I may just not be capable of it).

Secondly, the fact that PF uses GDI was an excellent design decision on Thierry's part since it allowed it to work on a wide variety of devices, but now with DirectX being ubiquitous on the desktop, I think it has to switch over to that. GDI performance is obviously not good enough for anything but relatively simple games, so PF remains relegated to a strictly PocketPC usage, which it really doesn't have to.

I personally am now considering using GapiDraw for my next project, in fact I've started down that path already. For a variety of reasons though I'd prefer to stick with PF. Unfortunately, these two things are the main reasons I probably won't.

The point to all this? Simply put, is there anyone out there that has the time, skill and desire to make these two things happen? Even if it was just the image loader thing I think that would be a major improvement. I know there are open-source image loaders out there that might be useable, but I think there are others more qualified than me to tackle that job. Any takers?

If not, I would expect one more PF revision at some point in the future from me to address the relatively minor things left that I want to address, and then that may wind up being it, aside from bug fixes. Don't take this to mean I'm dropping PF support right now, that's not the case, but I frankly think the writing is on the wall if I myself am starting to use GapiDraw :)
...and so I said to Mr. Gates: "$640 billion should be enough for anyone!"
User avatar
fzammetti
pm Insider
 
Posts: 1496
Joined: Jun 4, 2002 @ 6:21pm
Location: Omnytex Technologies


Postby warmi » Jun 12, 2003 @ 7:27am

warmi
pm Insider
 
Posts: 518
Joined: Aug 24, 2002 @ 8:07am
Location: Chicago USA


Postby Johan » Jun 12, 2003 @ 9:42am

FYI: GapiDraw uses a slightly modified version of the CE port of libpng and zlib. It took a bit of time to minimize the memory overhead even from libpng, but it's definitely doable and does not have to take that long to implement. If anyone is interested and want to give it a go I can give directions, unfortunately not the source code since it's owned by my company.

While I definitely think that it's possible to implement DirectX acceleration in PocketFrog, it's not clear as to what API to choose - DirectDraw or DirectGraphics (Direct3D). GapiDraw uses DirectDraw mainly for one reason - surfaces can be of any size. While DirectGraphics would be a nice implementation, the architecture restricts the size of the surfaces to the power of 2 (i.e. 2, 4, 8, 16, ...). This is usually not a restriction on stationary PCs with large displays and accelerated graphics. For cross-platform code however, using a 320x240 surface on a PDA takes much less memory than a 512x512 surface (320x240 is not an allowed size but commonly used).
User avatar
Johan
pm Member
 
Posts: 1843
Joined: Jan 12, 2002 @ 12:38pm
Location: Sweden


Postby fzammetti » Jun 12, 2003 @ 4:05pm

I admit I'm only familiar with the DirectX API's at a surface level, but I would suspect DirectDraw would be the way to go. From what little I've seen, I suspect the changes could be put it without tearing everything apart. I don't know much about DirectGraphics (yes, less than I do about DirectDraw even!) so I can't comment on that possibility at all.

Thanks for the info on the loader... I'm hoping someone more capable than I picks up that ball, but it not I just may be contacting you at some point for those directions :)
...and so I said to Mr. Gates: "$640 billion should be enough for anyone!"
User avatar
fzammetti
pm Insider
 
Posts: 1496
Joined: Jun 4, 2002 @ 6:21pm
Location: Omnytex Technologies


Return to PocketFrog & PocketHAL


Sort


Forum Description

SDKs for fast and robust device-independent access to Pocket PC display hardware.

Moderators:

sponge, Kzinti

Forum permissions

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

cron