23 doesn't see the need for a DRS system in a screen update library. I am not sure myself if it's only going to be used in certain specialised situations.

right, that's what I said, make an add-on lib.

Lot's of 2d non-scrolling games need it.

It's about 3 functions to use. Why do you think it is complex?

I seriously doubt that.

I seriously doubt that too. You have to know that such an update method exists, in order to search for it. Most newbies don't.

Allegro has many many things that are not used 99% of the time...and it lacks the one thing that 100% of its users need, and that is the screen update method.

Add-on or not, such a piece of code is really needed.

Not quite:

So still done in 3 parts.

Yeah, Marcello mentioned that in the bottom of his code box.

I hope this API turns out; perhaps a collaboration is in store? You know how it goes: "Together, we stand..."

Sorry for being side-tracked.

Has your method been added to axilmar's download? I've wanted to try out dirty rectangles for some time and would be more than happy to test.

If they don't know about it and they also do something, then they don't probably need it. They can just read the example.

I don't. You don't need that kind of API if you don't want to have more than one update method.

You can do anything with the piece of code I posted.

What if they later find out they need it?

I don't think the Allegro's example DRS is a good solution. It can be improved in so many ways, as it has been shown in this thread.

I don't have use for compiled sprites either, or midi, or streaming, or FLI etc...but that's hardly an argument. Furthermore, all games make use of a screen update method; so why should't a screen update API be there out of the box?

It can be separate, but the point is to offer a complete solution. DRS is only a few lines of code...does it really worth the hassle of a separate download? especially since the context is the same?

I second Evert/axilmar on both accounts. Just, you know, in case.

Then why you said it then?

What do you mean? it does not. If it did, neither 23, nor me or any other person would make one.

A screen update API is something used by 100% of games, and therefore need to be in the core Allegro library. Path finding or any other functionality is not.

I agree that giving the API control over screen updating is good. I disagree that having a DRS system in the API is a good idea.

Here's one reason: a DRS system requires that the underlying system support a specific kind of buffering: copy-based buffering. OpenGL, however, supports arbitrary buffering; that is, they specifically tell you that the contents of the back buffer after a swap are undefined. They could be what the front buffer was (flip), it could retain the back buffer data (copy). It could copy random garbage from an arbitrary piece of video memory into the back buffer, and it will still comply with the OpenGL specification.

If GL-based 2D is at all a priority, then you cannot put something in the API that directly conflicts with it.

BTW, I am aware that, in theory, you can create copy-based rendering in OpenGL (using intermediate textures or render targets). However, this is needlessly slow.

Lastly, DRS, in and of itself, is a pretty outdated technology. If you're running a TNT2 or better, you can easily render an entire screen's worth of 2D data (including strings, etc) at well over 30 (if not 60)fps. It sounds very efficient, and it is, but if you're relying on hardware acceleration, it is efficiency that you will never use.

[edit]

However, after thinking about it a bit, I wouldn't be adverse to having AllegroPro provide optional support for a DRS-style framebuffer update mechanism. Because AllegroPro is designed to allow drivers to opt-in/out of various framebuffer update mechanisms, it's no problem to have drivers that can actually support it use it, and the GL driver (among others) not.

Hey; cool! Hope you're using the newest version; found a bad bug last night ...