PocketMatrix

PF can tell when 2 rectangles intersect. Pixel perfect intersects with masks can be coded easily on top of this.

BTW it's very wrong to imply that PF is somehow lacking in comparison to GD. I have twice looked at both in detail & see no reason to give up using PF. If MS Smartphones had enough ram & fast processor to run my games I would consider porting PF however having had a play with a real Orange SPV E100 recently I decided not to buy one as it's a pretty poor platform. (so I bought a cheap Mondo instead to have a PocketPC phone just for fun)

Your right, it's not an incredibly difficult thing to implement... My point though was that it's something I don't have to do myself when using GD, and it saves me some measure of time therefore. I'd like to see PF come out with it so that I can continue to save that time, should I switch back.

Remember that a little over a year ago I was pretty far along on my own graphics library. But, for a number of reasons, I decided that using someone else' was a better option. If for no other reason it allows me to focus on my projects, not the low-level code to make it work, same reason anyone chooses any library at all. Therefore, anything taht can be added to the library that I personally don't have to put time into is a welcome thing to me.

About how PF compares to GD, keep in mind that I love PF and see no real problem with it.

What convinced me to switch to GD was first and foremost DirectX support. I wanted the capability to simultaneously release for desktop and PocketPC, and GDI with PF just doesn't cut it in most cases. That more than anything got me to switch.

At the time I thought there was a major problem with image loading in PF, but I've since learned that's not the case. I think GD DOES have better image loaders, but that's not a big problem.

The collision detection built into GD was also a draw, but not a huge one.

As I recall, those were the points that got me to go with GD for my current project. That and the fact that, at the time, I was the only one supporting PF at all, and I don't frankly think I'm good enough to be doing that anyway. GD was supported and seemed likely to continue to be evolved by someone other than me, and that was also a factor in my decision.

But, fast-forward 4-5 months...

Thierry is back on the scene, so the support factor isn't a problem any more (at least not to the same degree).

Thierry has plans on doing a DirectX driver, so that factor is or at least will be nullified.

Thierry is (I think has?) rewritten the image loaders, so that GD advantage has been nullified.

So, in my list of points, colission detection is the only remaining point in GD's favor. Is it a huge one? No, least important of the bunch. But I see it as a valid suggestion to make, and one small area that GD has an advantage that can easily be matched or exceeded.

But, also consider that GD now supports Symbian, and is going to support Palm. Those are also considerations to me. The more platforms I can release on without substantially differing code bases, the better.

With all the licensing shennanigans over in GD world now, I may very well be willing to give up that aspect of it though.

Isn't collision detection as simple as going through each pixel in the image masks and seeing if that pixel has a set bit in each mask? So you have to have two masks, and two positions for that mask. You return the pixel intersecting, or none if no collision.

We could code that in minutes and put it in PocketFrog. No problem.

I don't use that type of collision detection myself, but I could see how it might be useful to others.

I'm just using the built in InRect function for collision detection

A main concern I have is, can I build with PocketFrog for PC? At least for development and testing? How much effort is involved in doing this?

My app currently uses GapiDraw and takes about 25ms on Pocket PC and 5ms on PC. So I have plenty of ms left to spare on the PC build.

I guess I should just download PocketFrog and check out the samples and tutorials, but a quick answer to this would be kind.

in reply to mlepage PocketFrog works fine on PC. The PC app runs much faster than the PocketPC one unless you include a frame rate limiter.

When building for both you need to understand the _t stuff ( TCHARS, TEXT("") etc and there are changes to file paths to build in but it's really easy & saves oodles of time over the emulator.

I'm happy to help if you don't already know this stuff & it won;t take long to get set up.

I already use all the _T stuff. I currently build for both PC and PPC using GapiDraw. So given that, how much of a headache to move to PocketFrog (just the PC/PPC issue, not other API issues)?

Is there an analogue to GapiDraw's "minimal" application that I can just start from? I typically build it in VC++6 for PC, and separately in eVC++3 for PPC. There are two projects which include all my source files. I don't use resources.

Last night it took me about two hours to get a small portion of my current GD app switched over to PF. I have the benefit of knowing both, but the bottom line is it shouldn't be that tough.

A quick run-down of what was required:

(1) All the usual environment setup stuff (see the sample apps included with the PF download for that)
(2) Assuming you use the PF framework, you'll beed to change your method names and signatures (really in trivial ways) to conform to PF's way. Not a big deal.
(3) PF's blit function maps almost perfectly to GD's blt, as long as you didn't use any of the options. If it's just a straight blit it's a simple change of names and types.
(4) For other blit types it'll be a bit more work. PF has a separate blt function for rotates and stretches whereas they are options in GD.
(5) As I've posted in this thread, I'm not sure about how to convert Intersects yet if you've used them (which I assume most people do for colission detection). In theory it shouldn't require more than writing your own detection function with a signature that's close to Intersect's and call that instead.

In the end, it comes down to mostly busy work, unless you've used a lot of the "fancier" GD options and such. If you've just done a lot of blts it's not a tough conversion on the whole.

mlepage: Don't let me stop you coding that up for me

The question that comes to mind is performance... How do you go about optimizing that algo? At the least it would take some time to research, unless Johan wants to share the basic concept as implemented in GD with us.

It also would require, as stated here, extra resources: the image masks. GD works without this (just has the requirement that the surfaces have key colors, i.e., transparent portions, set), which makes it sound like it's a pixel-by-pixel comparison as you stated. The docs say it does a simple bounds check first, which is the obvious optimization, but there's got to be more to it than that, or so I would expect.