Suggested feature

[fzammetti]

[Kzinti]

[fzammetti]

The irony was not lost on me

But in fairness, I think I only asked for clipping and now this. I wasn't the only one asking for clipping either.

Thierry, I think you were ahead of the game with this feature though

[Pejo Software - Per]

Doesn't Blt( RECT* pDestRect, CGapiSurface* pSrcSurface, RECT* pSrcRect, DWORD dwFlags, GDBLTFX* pGDBltFx); do this for you.

[fzammetti]

Pejo, the way I understand it, no. I could be wrong, but my experimenting and doc reading seems to indicate that's not how it works.

It looks like that dest rectangle serves as almost a clipping region, i.e., if you scale an image to 500% and indicate a rect of 0,0,100,100, then even though the stretched image would go beyond that rect, it will get "clipped" to that rect.

Johan, am I correct here, or am I missing something?

[Kzinti]

[mlepage]

I'm not sure this would work, but if GapiDraw itself has the ability to scale in both the x and the y directions, then you should be able to write a simple wrapper function that takes your destination rectangle, calculates the proper scaling, then forwards to GapiDraw to do the work.

Which is to say, if GapiDraw already does this type of scaling, what you really want is simply another API to access that feature. But you could simply provide that API yourself.

(I haven't checked that GapiDraw does the sort of scaling required; I've not yet needed it for my first game.)

[Pejo Software - Per]

I am using Blt to scale to a RECT in my game, and it seems to work.... I am not using clipping though, I have my own clipping routine.

[fzammetti]

Pejo, could you post some sample code showing this? I tried earlier today and it didn't seem to work that way. I'd be very interested in seeing code that does it. Maybe using the internal clipper has some effect, but that doesn't on the surface make sense to me.

[DillRye]

[Pejo Software - Per]

fzammetti I created a modified Minimal app that can be downloaded from .

[Johan]

[fzammetti]

[fzammetti]

Pejo: I just tried your sample finally... All I get is a blank screen. I do notice that you used GD 2.03 for it, I tried it under 2.04. Perhaps a difference in the versions?

Johan: I have to admit I didn't understand your suggestion to try it. If I was getting it at all though, I suspect it won't work for me.

What I'm basically trying to do is this... If you imagine a driving game with trees on the side... as you go down the road, trees in the distance get larger and larger. It's essentially that kind of a thing.

However, they need to not only get larger, but they also need to diverge from a center point, moving outwards towards the edge of the screen (or in my case, a smaller 200x200 area).

To do this in PF, I could simply create a rect of say 0,0,10,10. I could then easily calculate the coordinates to center this rect on the screen, then tell PF to stretch blit to that rect the image of my tree. Because I know before the blit that the final image will be 10x10 and will be a complete version of my image (it'll look horrible of course if it's much larger than that in reality), it's easy to calculate what it's x/y coordinate should be as it moves outward.

Then, I can simply expand my rect to say 0,0,12,12 and then 0,0,14,14 and so on, and move the x coordinate of the blt left or right by the same number of pixels so they will diverge as they expand. Fairly simple.

The only way I can see to do this in GD is to myself calculate the size of the image with each percentage increase and calculate my x/y coordinates based on that. That could be slightly indeterminant though because depending on the percentages I pick, the outcomes may not be integers, and I have to take that into effect. Contrast that with just specifying an absolute rect size, which can easily always be integer, and always even for that matter, to make location calculations that much easier.

Nonw of that shouldn be a terribly big deal to implement in GD, and I'm going to go off and do so now, but that's where I was making a feature suggestion... The PF stretch blt approach makes this trivial and is a pretty powerful thing to have and I think would make a nice addition to GD as well. I don't think it should replace what you already have, but perhaps could supplement it nicely.

Thanks to every for the suggestions!

[Pejo Software - Per]

This thread is making me suspect that I am living in a different reality than the rest of you, This really worries me! Please tell me, is the grass green in the real world too?

Frank, the reason I used 2.03 was that Blt is supposed to be broken in 2.04.

Could someone Please shed some light on this! I can't well sleep at night now that my view of the world as been destroyed!