Why not allow for 2 and 4bit color depths too? Just make the depth stuff extensible

Branch prediction has more to do with pipelining than with superscalar-ness.

The problem with pipelining is that the CPU takes several steps to "execute" instructions. Thus, it will not realize that a conditional jump has jumped (or not) before it's too late. This means that the CPU has probably started executing instructions from the wrong side of the branch. Worse, it may have already completed instructions from that side of hte branch, especially when you consider that the CPU is Out-of-Order!

When the CPU realizes that it took the wrong code path, it must stop its current operation, undo everything it has done upto the branch code, flush the instruction pipeline, update the instruction pointer, start fetching instructions from the new location, then restart executation from that point on.

This can cost hundreds of cycles (or more if the new code isn't in L1).

To remedy this, CPUs have a "branch prediction unit". This piece of of the CPU attempts to predict if a jump will pass or not as soon as it has fetched the instruction. This way, it can fetch subsequent instructions from the right location in memory.

The prediction unit uses a combination of static and dynamic prediction techiques. Statics are used when the branch instruction is new to the CPU (ie: there's no past history), and it includes things like "branch is taken if it goes backwards" (think: loops).

Dynamic prediction is statiscally based. If the branch was taken the last 50 times in a row, then there's a good chance that it will be taken the 51rst time too.

The cost of a mis-predict is still very high though.

Now, the trouble with RLE is that you're going to have really small spans of contiguous pixels (like 3 or 4, or maybe just 1 pixel). So you'll probably mispredict on the first loop iteration, as the last time you had exited the loop. You'll also mispredict on the last iteration of the loop. But if the loop runs only 3 times for three pixels, then you'll mispredict 66% of the time!

Hope this cleared up things!

There is a potential fix for the flickering in the CVS version of Allegro. This is unrelated to the API change, as it's a driver problem.

As for when v5 will be out, it'll be out when it's ready

i hope you mean truly ready when you say "ready". allegro 4.x is good enough for whatever everyone is doing now,. so i would hope that you optimize everything you can in 5 before you release it. dont worry about us end-users, well wait for perfection.

I like the ide with fonts being lists of AL_BITMAP
This would allow to implement Anti-Aliased fonts really easy (just use a bitmap with alpha channel)... i like the idea.

Ok, we now have a mailing list! Feel free to register here.

Discussion is probably easier since it's threaded. It'll also use up less bandwidth, and is publically archived.

It's in English, written in ASCII...

OOoooh, now I understand!
Well, I didn't pick the name, tjaden did

Good point.
In fact, it would be great if all the load / save functions would work on memory.

load_bitmap(filename) {
     allocate memory for file
     read file into memory
     decode in memory
     free memory
     return bitmap
}

if the decode-in-memory step would be a callable function, you could do lot's of nice stuff.

I get a 404 if I click to view the mailing list archive...

Marcello

From which one can conclude that packfiles will remain in the core library? Shame.

Its yet another feature that was added to Allegro despite the fact that it would sit better as an external library. And, despite the fact that in a world where ZLib exists, it already does.

Here are the benefits of ZLib over packfiles :

And here are the benefits of packfiles over ZLib :

[*]

Thats like arguing that a tile engine should be built in, or how else would anyone ever write a game that used tiled graphics? There are several other ways of getting sound and graphics into a game - notably including load_bitmap which is exactly what we were just talking about. Surely the argument should be one of how tightly the idea of datafiles as a core component is required by the remit of Allegro, but of course it doesn't seem to have a well defined remit. Which is something that needs to be addressed, in my opinion. "Allegro is a game library" isn't really good enough.

In any case, returning to the point, I don't see datafiles as a core component either, just as a feature of the packfile library.

Not relevant with discussion to Allegro 5, which is, after all, an entirely new library with the same name.

I read that Shawn originally shunned ZLib because it was 'too slow', but to be honest I'm not sure I believe that story. Either way, this is no longer relevant, due to a combination of factors.

Firstly, the concept of video and system bitmaps (and hardware samples if Allegro supported them explicitly) means that everyone has to accept they can't just pull very much data off the disc and use it without getting severe speed penalties.

Secondly, everything has sped up to the point where ZLib is fast enough on modern hardware, since drive speeds and CPU speed are rarely the bottleneck for 2d games. Personally, I've used ZLib in speed critical environments (see ElectrEm, on allegro.cc in the emulators section - UEF's are a chunk based format written on top of ZLib), and it has not caused any problems.