Okay.. but the point still stands. People did a lot of screwy things and we can't convert everything. I doubt it is as simple as string replacement and would probably be similar to a compiler in structure. If you can prove otherwise please go ahead and i can write a conversion script. A proof would need to contain equivalent functions and effects without any restructuring of the code (which would require parsing/compiler type stuff).

Right now there is the potential for a compatibility layer. There are a few functions there already including the old periodic timer (cotimer.c). I have the feeling that most developers would rather focus their efforts on the A5 api before worrying about backwards compatibility. Some things will be impossible/extremely difficult to support. Take mode7 for example.

In the meanwhile allegro 4.4 branch will continue the legacy into the future. No doubt support will eventually be dropped in favour of the allegro 5 series. Hopefully by then virtual machines will be simple enough to use to provide support "forever".

An incomplete compatibility layer is useless, but I still think there needs to be a (thin) compatibility layer - obviously it's not the highest priority at the moment. Getting the new API to work and stable will be the first and most important goal.

Compatibility layer means API compatibility, meaning you can expect set_gfx_mode(AUTODETECT,...) to work. I don't think you need to expect set_gfx_mode(MODEX,...) or even set_gfx_mode(DIRECTX,...) or set_gfx_mode(X11,...) to work - no properly written code should depend on those anyway. Don't expect writing to the key[] array to work (or that the key[] array is the best way to get input), don't expect bug-for-bug or quirk-for-quirk compatibility. Expect compatibility on the level of the old demo programs compiling with no or very little modification.

The aim is/should be to have both by the time 5.0 is done.

Also, be careful with an argument like that! Someone working on Y but not X does not mean X would be done sooner if that person didn't work on Y, because s/he may not want to work on X.

I'm not persuaded of the need for software textured triangles. One of the goals for Allegro 5 should be easy maintainability and better code readability — in the hope of attracting more developers. With that in mind, finding the smallest possible useful set of functions is desirable.

That said, I can knock up a mean software texturer. Subdivision into affine grid-aligned quads is the future. Or was, circa 1995. If you want even more performance then make it a scene graph and chuck the quads into some stacks for deferred rendering. But I really, really don't think that we do?

EDIT:

Those are fine assertions, but they don't necessarily map to the entire library. For example, what do you intend to do about get_gfx_mode_list? I guess just ignoring the argument will probably do (?) — especially as the function is sufficiently useless that it's probably completely unused.

How would you write a resolution changer like gfx_mode_select without it?

I use gfx_mode_select fairly often , and I'd like to keep the ability to know which graphic modes are available. And what's this about getting some random graphics driver back? Will the ability to select a specific graphic driver no longer be available in Allegro5 ?

There is, not sure it's implemented yet though, and we likely might change the interface. At least there will have to be more fields in ALLEGRO_DISPLAY_MODE I think. http://www.liballeg.org/naturaldocs/files/display_new-c.html#al_get_display_mode

Indeed. It's also why we split things into "addons", like the current font rendering residing all in its own folder, and a way to disable it from the build system.

I don't really know how this deferred rendering optimization would work, but yeah, optimization of the software primitives is the big problem I guess. Something "like A4" (but without the shading and perspective correction and so on) is what I have in mind.

If we have textured triangles, it will mean, we can re-implement the 4.4 demo with A5, which would be nice

Btw., looking at your triangle code again, how would the sub-pixel precision play together with al_line? Like, if I do:

al_triangle(0, 0, 8, 6, 0, 10, ALLEGRO_FILLED, color)
al_line(0, 0, 8, 6, color)

Should we then have any semantics about possible overlap?

I'm reasonably confident that it's the same system that was used on the old PowerVR cards, including the one in the Sega Dreamcast. You divide the screen up into 8x8 pixel segments (or whatever), then divide all the polygons by those segments. Only once all polygons are added to the structure do you actually work out pixels (probably by an s-buffer, optimised for 8x8 blocks, or some such).

In scenes you would expect a software rasteriser to handle well, a lot of the 8x8 blocks are entirely covered by a single polygon and you can probably get away with drawing those blocks using a non-perspective fill as long as you have the perspective right at the edges. Though that's really about avoiding divides, so maybe it doesn't matter nowadays.

Oh, I meant to say - I think that code might have an error in its horizontal clipping that allows it to draw one pixel too far to the right to BITMAPS, potentially overrunning allocated memory. The fix should be a simple replacement of <= with <, it's because I was initially confused about which pixels that sit right on the boundary of a polygon are usually treated as being inside.

I think it's smart to just adopt the OpenGL semantics for everything? OpenGL has a system whereby you imagine a right-angled diamond with centred on each pixel, that extends halfway to the pixel above, halfway to the pixel below and halfway to the pixel on either side.

A pixel is covered by a line if it exits the diamond. E.g.

(image taken from section 3.4.1 Basic Line Segment Rasterization of the OpenGL 1.1 specification).

Obviously the polygon rule is (roughly) "pixels are drawn as part of a triangle if their centres fall within the polygon", so that produces a line that straddles the inside and outside of the polygon — there should never be a visible gap between the line and the polygon in your example, but the line won't necessarily fit completely inside the triangle. Which makes sense.

It's just being precise about the definitions of when pixels are and aren't inside polygons. Implementing that means that the code has to sometimes think about parts of pixels rather than whole pixels, so it necessarily has sub-pixel precision.

The hard-and-fast OpenGL rules are:
1) pixels are drawn if their centres fall within the polygon
2) pixels are not drawn if their centres fall outside the polygon

Then there's some lack of exactness about the third case concerning pixels that fall exactly on the boundary, but I went with:
3) pixels are drawn if they are exactly on the boundary, are on the right edge of a scanline which is not of zero length and covers at least one pixel centre

The point of that third rule being to try to colour pixels exactly once where polygons meet, no matter how they do so (so think two large polygons directly meeting, two polygons meeting but having a third polygon of zero size inbetween, etc).

In hardware land, I think a lot of cards use the half-space rule, which allows you to take any particular pixel and query whether it's in the polygon — which is great for parallelism. The code I suggested for Allegro 5 is a traditional top-to-bottom, left-to-right scanline filler which is probably better for a CPU.

I'd add also that it's quite a step away from a clean API. On the other hand it can help to make a transistion from Allegro 4.2 to Allegro 5.0

I seem to have slept in cave for a really long time. I'm just so excited to hear that finally this is coming to be released. Looks like I'll wait with coding another project till Allegro 5.0 comes out.

Is there any site I can get info about how it is structured? I'm also excited by native png and ogg support, since this reduces number of other libraries you have to learn to use, you have to compile and is convinient for a developer and for the end user.

The most important question is: what is the projected release date?

Well I have only one recent project that involves AllegroGL so there's no need for urgent update. But I keep that in mind.

Well I expected something between soon and infinity. I wonder how many things need to be done and how many of them are completed. I also wonder if I'd be of any help, since I haven't worked with anything involving hardware. I should se a todo list.

Surely I will as soon as I get my hands dirty with writing a new project and Allegro 5 won't be out I'll begin to mess with svn version.

As for that cave. I've missed a.cc news and haven't lurked into dev forum for a while. So I completely missed allegro 4.9.x. I just knew about 4.3.x being released some time ago and words of a revolution coming onto us.

Edit:
Looking at the docs it seems that Allegro got complete rehaul, as I don't see any familiar identificators. A completely new API, which looks clean and not so huge. Though I suspect that sound and datafile routines will come, as they are still not in there.

That's still true.

Let's not get ahead of ourselves.

I tried to build 4.9.2 with MSVC 7.1, but didn't really succeed. There are some things in headers that don't compile, and after some changes I discovered that I would need to install the DirectX SDK on my PC, is that right? It also seems that the build instructions are not up to date, and neither is the documentation, or did I miss something?