I don't know if it's good to have 2 threads on the same topic, but somebody said in the other thread that I should make my own thread. So here it is, for your programming pleasure, a very nice screen update API with the following capabilities:

1) triple buffering, page flipping, double buffering (accelerated or not) screen update modes with autodetect capabilities
2) balancing game loop as in Allegro FAQ
3) DRS update mode that avoids overlapping blits without using rectangle operations (very fast)

In the attachment you will find HTML documentation in the file doc/index.htm.

Hey, it's a ...trade secret! :-)

Ok, I'll give you a hint: old coin-ops use it as a method of screen updating.

Nope. Close enough. It's very simple.

I don't understand what you are saying. What are x1 and x2?

What if you have two overlapping rects?

I guess you haven't looked at the attachment at all.

Oh well...one more try and I will explain it to you.

It was easy, wasn't it?

Block size is user-definable. In reality, a good size is 32x32, especially for tile-oriented games.

EDIT:

By the way, something like the screen updating code I posted above should be part of Allegro. It's trivial (only a couple of hundrends of lines of code), but it would make life easier for a lot of programmers, especially newbies.

My way works a bit differently:

This blits three rectangles all horizontally optimized for veritcal refresh.

It is not, because if there are lots of rectangles, computations take exponentionally more time; there is a lot of coordinate comparison, data transfer etc. The grid system is much simpler and much faster, and takes much less memory, and there is no upper limit to the rectangles that can be updated.

EDIT: before you jump on me, I've tested the DRS system that Steve Terry describes through lib DRS, which is quite a good lib, and I have a thorough understanding of its internals.

I am also the author of the MX-Window system, and I have quite a good experience on regions; and DRS the way Steve Terry describes it is almost like regions for a window system: rectangle lists that are intersected, united etc.

And when the rectangles take a good percentage of the screen (75%), the algorithm automatically switches to double buffer for that frame.

Ah ok. But is such a trivial case. is it worth mentioning?

By choosing the appropriate size for blocks, the extra blitting is minimized. Furthermore, a few extra pixels blitting is not a real problem, is it?

No, it does not take a lot of sprites for the block approach to be faster. Even with minimum number of sprites, the block approach can be faster, because, in classic DRS, for each new rectangle that is added, it must be compared against all others. The block approach is possibly slower only when there is a relatively low number of big sprites (sprites that occupy lots of blocks).

I agree though that a detailed benchmarking is needed. I may be totally wrong.

I really see no advantage in the traditional DRS approach. It is quite complex to code right, and the fact that the block approach maybe a little slower when the sprites are big and few, does not justify its use. Of course, that's just me, though.

Might I propose an alternate version of this DRS system which I already used in HiSPEC (my ZX spectrum emulator)? This system uses a table splitting the spectrum screen into 8 x 8 blocks.

For a PC system I would use 32 x 32 blocks as you suggested, each block can contain 0 for unchanged, and 1 for changed. This table is set to 0 hen the DRS system is initialized.

When you add a DRS rectangle, all it does is mark the relevant rectangle of blocks with a 1.

Then when you call the DRS update routine it does this:

Starting from the top line, it scans from left to right. As soon as it finds a changed block (1) it changes mode and continues until the first free block on that line is found, or the end of that line is found instead. The position of the 'cursor' in the table is now saved. Also any changed blocks are changed to unchanged (or 0) once the mode has been changed.

It now has the width of changed blocks for this line. Now it searches down the table, scanning from the start of the original line to the end, to find how many rows of exactly this width it can find, for each row of the same width it zeros the blocks. Once it has found an unequal length (or broken length) it stops and draws the rectanglar area of unbroken and changed blocks it has found.

The routine now restores it's position to the saved one and carries on as before. Once the routine has gotten to the end of the table, all changed blocks will have been put to unchanged automatically. No areas will have been drawn twice and for a little extra processing the number of blits per frame can be drastically reduced.

So if you passed one large sprite of say 256 x 256, rather than 64 blits, only one would be used. If you passed the full screen, only one blit would be done.

Steve's example would be done like this:

Even with overlapping areas when only one width vertical segments can be found, the number of blits are still reduced. In my visual tests with the spectrum emulator it seemed to vastly simply the blits per frame required..

What do you think?

I thought you'd missed my post...

well, there are a lot of simple things that are cool that take very few lines of code to implement. But where does the necassity of inclusion in the library become a point? Allegro already has a lot of stuff crammed in it. It probably need fblend more than it needs a DRS.

I say, why not create a nice allegro extras lib? I would contribute a Mode7 function as well as water effect using cos/sin