PocketMatrix

Sounds great Johan!

I'm all for native clipping. I got spoiled with PocketFrog having it built-in.

I'm guessing that adding clipping doesn't hurt performance much at all. Doing our own clipping externally doesn't seem to cost very much, I'd bet that doing it internally, and based on the fact that your an optimization monster Johan!, I very much look forward to this.

The idea of a SetViewport function I like a great deal. It's very helpful just to clip to the physical screen, but as an example, my current game would benefit greatly if I could say "ok, clip against this particular RECT until further notice". That would allow me to go directly against backbuffer rather than the temporary surface concept I've been using. I'd bet I would see a frame rate increase if I unbound the frame rate.

By all means, you absolutely have my support! (not as if you needed it, but still )

You've got my vote for the GDBLTFAST_CLIP route! One can always complicate things, but I think you should K.I.S.S (Keep It Simple Sam)...

I have to admit that I'm a fan of making SetViewport apply to the surface and all subsequent operations to the surface, without requiring additional flags on the calls.

So in Johan's example of a game with smaller viewport for the playing area and an overlayed UI, presumably overlapping the edges of the play area to make it non-rectangular:

surface.SetViewport( CRect(10, 10, 50, 50) );
surface.BltFast( sprite1 );
surface.BltFast( sprite2 );
surface.BltFast( sprite3 );

surface.SetViewport( NULL );
surface.BltFast( ui_overlay );

Requiring the flags on the individual calls doesn't seem like a benefit to me; the perf impact of testing for a clipper inside the Blt functions is infinitesimal compared to the cost of pushing pixels around. It keeps the client code cleaner since the bulk of the game code doesn't even need to be aware that a clipper is being used.

You could imagine taking the GD sprite demo and adding a few lines of code outside the main sprite loop which implement a clipper rect which is moving from frame to frame; it would be nice to be able to simply add that code without modifying any of the rest of the code.

I agree with InexorableTash.

This soluton is similar what is used in most of GUI toolkits = some sort of graphics context which is set/reset using its own set of calls and which then gets applied to every graphic call.

If you don't stop adding so many good features, I will go crazy waiting for the release! I like the idea. Hope GD 2.02 comes out soon.