PocketMatrix

I have just put my hands on an Audiovox Maestro for a good price. I intend on resuming work on that "next graphic library" I was thinking about.

PocketFrog as it is was a nice experiment but I feel it is too limited in both flexibility and ease of use for newcomers to the world of C++.

You can expect a major rework of the functionality set and a speed increase over previously existing graphics toolkits.

The current plan is to have a low-level hardware abstraction layer (HAL) which will be optimized for each device. On top of that, a framework similar to PocketFrog 0.x will be built.

Source code for the HAL won't be available for obvious reasons. But complete source code to the framework will be.

I don't have a time estimate yet as I have to spend some time doing research and developement to validate a few ideas I have. But rest assured, PocketFrog ain't dead yet. Like a phoenix, it will be reborn from it's (not quite yet) ashes.

Thierry

The question is how interesting performance improvements really are. I mean, since it's all basically memory copy operations, it can't be much faster than reading 32-bits and writing 32-bits, perhaps with variable loop unrolling optimized for the instruction cache of the device (this is one of the features of the GapiDraw HAL btw - which is individually optimized for each device, considering data and instruction cache among other features, even taking advantage of hardware blitters).

I'm also not sure if it's a good thing changing the API. PocketFrog have a group of fellow supporters (like Conan and fzammetti). They use PocketFrog since they really like the current API. Letting them know that the PocketFrog API will change significantly sometime in the future might put them off both from (a) continue development on the current platform since all this work probably will be worth nothing once the new HAL is in place, and (b) continue using PocketFrog since they are not motivated on expanding it further.

On GapiDraw we are currently working on providing support for more devices (outside the Microsoft sphere), something I would argue could be more important than features or performance improvements.

I have been conducting some research tonight in the hope of speeding up a straight fullscreen copy of a backbuffer in system memory to the display (GAPI). This blit is usually done using a single call to memcpy() and takes roughly 4.7 ms to execute.

I have found a way to speed this up by a factor of 2. My blit executes in just under 2.2 ms. This result in a theorical maximum of 455 FPS.

I have serious reasons to believe that similar improvements can be achieved with a 90 degrees rotation (or even a 180 degrees one). What's more, there is still a few ideas I haven't tried yet.

The tests were conducted on a plain (unmodified) Audiovox Maestro that is running the StrongARM processor at 206mhz.

Let me know if you want anything tested. I have a Dell Axim which runs at 400 or 200 Mhz plus an iPaq 3650 arm machine.

My interest in this area is getting PocketGL to write directly to PF's back buffer instead of it's own as this causes me to have to do a copy involving a lock & unlock and I lose lots of FPS. It's been done with GapiDraw recently so must be possible with PF however I have not managed yet with the current version.

Thierry, any plans on writing a custom image loader? I'm sure everyone is sick of my saying it by now, since there's about 10 threads in the past two weeks with these words: that's one of the big reasons my current project is GD-based. From what I gather from reading Johan's docs, there is a big memory hit using imgdecmp.dll. I had a huge problem with my Invasion: Trivia game because it required far too much memory, in fact about twice as much as I calculated it should. I could never understand why, but reading the GD docs makes me think this is the reason.

The other big advantage to GD from my point of view is it's use of DirectX on the desktop. Thierry, I understand your feelings about PF being for PocketPC's (and I know the "old school" feeling very well, all this relatively low-level stuff makes me feel like I'm back in the Atari 800/C64 days! I love it! Show me where the $d011 register is on a PocketPC and I'll have FLD running in five minutes!). That being said, I like GD because I can simultaneously release for PocketPC's and desktop PC's. This is something I can't do with PF (not with good performance that is). Do you have any thoughts on making PF use DX instead of GDI? Is it possible you can just write an x86 HAL that uses DX? If not, I'm thinking maybe some sort of add-on module or something along those lines. Although I have no DX coding experience, I'm willing to take a stab at this, if I know I can count on your support and, more importantly, guidance in how to incorporate it.

Truthfully though, the image loader issue is what I would actually consider a problem, the DX thing is just a big bonus, and I could do without it ultimately.

(Never used PF or GD - I'm just an interested "bystander").

Frank:

Was the "extra" memory ("twice as much") that was used at the storage/file stage or at the decompression stage?

fzammetti:

Image loading will be changed for sure. What SBL says is that imgdecmp.dll has too much overhead for game programming, and it might well be the case.

It should be trivial to recompile libjpg and/or libpng to work with PF, and I am really surprise no one has done it yet. I guess it wasn't a priority forme.

But yes, image loading will be one of the first thing that will be improved.


Concerning DirectX: PocketFrog already supports different display drivers, and adding a DX one should be trivial. Another thing that can easily be added but that I never had the time to do. I understand that this point is something a lot of people one, so it shall be added. I am also sick of playing PF game in a small 240x320 window.

The decompression stage. The game executable is 4.5M, but the game needs ~14M to run without crashing. I did an admittedly rough test, saving all my graphics as uncompressed BMP's instead of PNG's, and the WAVs are uncompressed to begin with. All the resources in those forms, plus the code and data, shouldn't require more than about 8M, give or take a bit, which means that the memory requirements is about double, a little more even, what I think it should be. This jives with what Johan states about imgdecmp.dll.