Notes on built-in clipping performance

[fzammetti]

[warmi]

[fzammetti]

[tedson]

I live by the statement, "make it work right, then make it work fast." A clever optimization is almost never worth the complexity of the code, and when running a program through a profilier the bottlenecks are almost always some place unexpected.

[warmi]

"make it work right, then make it work fast."

That's precisely why it is much simpler and much less error prone to create a generic clipping routine that will work in every situation than to worry about solutions like oversized surfaces and similar stuff that changes with every game and can lead to memory overrun errors as soon as your sprite strays even only 1 pixels beyond the limits of the surface.

[fzammetti]

I disagree with part of what you said warmi...

Since GD just doesn't draw anything that strays off the edge of a surface, and since we all trust Johan to have implemented that in such a way that a memory overrun wouldn't occur, that solution is no more error-prone than a generic clipper in my mind.

In addition, since you are basically creating a viewport by virtue of the fact that you are only blitting to backbuffer a portion of the oversized surface, it's not truly as inefficient as it could be. Worse than simply clipping, true (that was the point of my post), but not terribly so.

Creating a generic clipper that works in every case isn't quite as trivial as it seems (I think even Johan had some trouble with regard to clipping and rotations if I remember correctly). It's arguably not an efficient use of my time to code that, even if it only takes an hour let's say, when I can do the oversized surface thing in 1 minute and spend the other 59 minutes coding my game.

I do agree that such a solution might well change from game to game, and that is undesireable. But I think it's not what I would call a big deal: "hmm, lemme see... my oversized surface was 400x400 in the last game, but this is a full-screen game, so I guess it should be something like 480x640 this time around". See, not a big deal to change it.

That all being said, this is all really more a matter of code aesthetics, since performance is pretty close with either solution. My original point was simply that when I had to have extra lines in my own code to do clipping myself, I didn't like it and preferred the "cleaner" approach, relatively speaking, of the oversized surface approach. With it built into GD now, that concern has been rendered null and void and I don't advocate the oversized surface approach at all. Just offering a comparison if anyone else is considering it for some reason.

In the end, I suspect we're all going to use the built-in clipper and be happy doing so. The rest of this discussion is just interesting chatter now.

[tedson]