I'm curious. I'm seeing a lot of discussion about whether or not to support the i386 ASM code. But, the compiler optimized code is faster, and people are having to make an effort trying to get even a 486 computer to test stuff on. Since DOS support is being dropped (incidentally or on purpose) for 4.3x, why even bother with the i386 ASM? I believe it's long lived its days, and worth retiring, especially if it's easier to maintain the code. And I have a hunch that it would be much easier, since, (and this is only from what I can understand) nobody seems to be maintaining it anyway. It IS still 386 code, after all, and nobody seems to have been interested in updating it.

Now, don't get me wrong, I'm not knocking the quality of the code. It's far more organized and well written than anything I could dream of writing. But it just seems, to me, that keeping this legacy code in it, that isn't being updated when the rest of the system is, is pointless. If someone is going to be using Allegro in DOS on a 386DX, (any takers? ANYone?) the 4.03 release should be more than sufficient. I just read the changelog for everything between 4.03 to 4.1.18, and there were no references to any fixes to any 386 or DOS code. In fact, quite the contrary.

There were a significant portion of fixes BECAUSE of the 386 code!! This seems a little counterintuitive, to me. Someone mentioned not worrying about the DOS support in 4.3x because it doesn't make much sense to support an unaccellerated platform. I'd say the 386 follows the same...

Now, I've been using Allegro for years and years and years. I plan on getting involved in the development of the core system once I have some free time to do so. So please don't think I'm knocking the development team, or anything of the like. I have very much respect for those of you that work on Allegro. But I cannot, for the life of me, understand why there's even a discussion of whether or not to update the code from 386 support! Chuck it.

My two cents.

Unless compiling for a pre-MMX compatible system, using an optimizing compiler will be faster than pure 386 assembly. And more portable. Period.

I'm just saying, if nobody is maintaining the 386 ASM, then chuck it, because it's getting in the way of the compiler's optimizations.

Yes, as I said in this (or another) thread already, I'm happy myself about the prospect of removing the current asm code.

Yes, that would be nice. Allegro's test program is quite awkward to use, without any automated benchmark feature.

Although I think this is the most recent major addition that has been seen recently. As Elias pointed out, this was included because it lead to a speed increase. If benchmarks now indicate the C version is faster, well... that's peculiar and something to be investigated.
As for fixes specific to the DOS/DJGPP code, there have been several fixes, but they are not clearly marked in the docs as being DOS specific.

Also, if there are no fixes, I think that is more a sign that there are no known bugs in those portions of code. The DOS and 386 assembler code are probably the oldest parts of the library. As long as there are no changes to the internals, they do not need to be touched or modified and no new bugs appear.

Anyway, it will stay for 4.2, we can discuss removing or disabling the code after that. But, as long as there are people who want to maintain the DOS or 386 code they are welcome to do so (and yes, there are people actually interested in that).

None of us have much time anyway, so you should fit right in now.

Because it works and has been well tested over the years and you should take care before you change something that works. It may be that the asm code is slower than the code the compiler produces on the latest generation of processors. As I said, a year ago this was not the case.
The C only version already exists and can be made the default in due time if that makes sense. But it will have to be looked into and considered first.

The first step to making the C version more useful, in my opinion, would be to get it to compile in MSVC without the aid of MinGW or DJGPP.

It's also a sign of neglected code. Assembly isn't something you write once and leave. As processors change, you update and add to it, if possible. The point of writing in assembler is that you can utilize the maximum potential of the processor. If you're not updating the code, you're not utilizing the maximum potential of the processor. I'm not saying it doesn't work, I'm saying it doesn't work well enough.

Are you still using an Apple II? Progress is worth change.

I'm suprised that after almost 10 years of hardware accelerated graphics, Allegro still won't use the blending features found on any cheap 3D card. If it's a problem of compatability, use different rasterizers: software and hardware. This isn't a new concept, the two biggest graphics API's come to mind: OpenGL and DirectX.

And please don't tell me that "it's coming", because I know. 4.3x is supposed to have it. I'm just without understanding why these optimizations haven't been implimented yet, is all. If someone can tell me, please. I'm not upset that Allegro doesn't use the latest and greatest, but I'm upset that nobody seems to be saying why.

If the developers don't still use 486s, then they're probably not developing for them. Which means that the 386/486 users are getting little to no benefit from using the latest version of Allegro. The non-architectural changes since the last major 386 and DOS code updates are negligible, and make almost no, if any, difference to a developer on a 386.

The 386 and DOS users have their Allegro 4.03. I'm not saying that it should be cut out before 4.3x, but if the 386 assembly is not updated for 4.3x, you're still backboning on an inferior technology. Like running Windows on top of DOS. It's a fruitless method.

Those optimizations are incompatible with Allegro's API.

That is exactly my point. "(near?) future" Nobody is even sure when it will be implimented. It's been 2 years since the last "stable" version of Allegro came out. It'll probably another 2 years before OpenGL support comes to Allegro.

Not entirely. Phasing in certain features is a good way to move an API from one direction to another. The primitive drawing could be done in 3D. Any bitmap objects can be textures. (There are system bitmaps, video bitmaps, etc, why not texture bitmaps). Writing to these texture bitmaps would be slow, but if you're developing with that in mind, you could simply not do per-pixel drawing, or updating of bitmaps, very often.

Blitting from a bitmap to screen would then be done via texturing a GL quad primitive. There's nothing the GUI draws that can't be done in 3D. Most of the blending functions wouldn't be able to translate without pixel shaders, and I admit that would be a downside. But how often do people use the "saturate" blender? Stretching, rotating, lighting, shading, and flipping sprites would be insanely easy in GL. With exception to writing directly to the screen, every drawing function can be done with GL, albiet slower if you try to draw directly to textures every frame. But using GL as a rendering device could be explicitly defined in the source, so older programs will use the software rendering, and programs wanting to use GL can. Obviously, those using GL wouldn't work in some environments, like DOS (unless you also included Mesa), but drawing 200 half-transparent sprites is gonna suck any way you do it on a 386. Oh, and the 3D drawing functions could actually draw in...3D.

I guess my whole point boils down to this: Why is fblend still an external library?! If it is a highly recommended library for any Allegro developer, then why does it even exist? Why is it not in the Allegro library? That makes no sense. It's this kind of backassward development that lead to my developing my own software and hardware rasterizer for Allegro. This kind of stuff should be in Allegro to begin with.

IMHO, Allegro is easily the best game development library to work with. Even though SDL is designed for any form of cross-platform multimedia development, there's a reason why it's the most widely used free library for making games. It's not at all easier to use. But nobody developing SDL is saying "and you should take care before you change something that works.". But having to use an external library for decently fast blending means it doesn't work!

I'm done.

This just proves my point as with fblend. Why is it not part of the Allegro core?

I disagree. I have a feeling it has to do with lack of project organization. There's no public roadmap that I can find. I hear about this magical roadmap all the time, and people keep referencing it, but I have yet to see it. If it does exist, I would appreciate someone telling me where I can find it. I, for some time, wanted to get involved with Allegro, but I have no idea how. There's no "head honcho" to get in touch with. The website offers little information on getting involved, as well. The SourceForge page has 5 admins listed, with no indication of who to contact to help support the project.

Like I said in my last post, I am writing a software and hardware rasterizer. Please thoughly read my posts before responding to them.

Do you know what a rasterizer does?

edit: misread your edit
edit: Thomas Fjellstromm, thank you. I will join the dev list.

Give me a couple more weeks, and you will see. You may not hate me anymore when I'm done.

Edit: Well, now, Thomas, after reading some of the mail list, I retract what I said about them being unorganized (though I never said they were lazy). When most of the development progress takes place in a mail list, it makes it seem, to the public, that there's not much going on. Obviously I was wrong, though it would be nice to have more frequent updates to the homepage. But that's just me being picky!

Well, I'm currently merging the Allegro blending code with fblend so they both work with the regular Allegro blend functions. I'll probably have something to submit by tomorrow.

I thought I heard that FBlend only works on memory bitmaps. I could be wrong or thinking of something else, though.