Finally it has arrived! Grab your own

Download, Web page, Manual and the Source only distribution

(I have to find out how to update the manual at the Retrospec's mirror...)

New graphics primitives (Thanks to Jim Sintha for the ideas and code structures of some of those)

• LineStrip functions (Manual entry)

• Ellipse functions (Manual entry)

• Slice functions (Manual entry)

• EllipseSlice functions (Manual entry)

• Arc functions (Manual entry)

New RenderModes and the ability to combine RenderModes with the sum operator!

• Clipped mode (Manual entry)

• Flipped mode replaces the old hFlipped-parameter (Manual entry)

• Alpha from an another Bitmap - mode (Manual entry)

• Slice multiply mode (Manual entry)

• MultiMode - combination of two RenderModes (use the sum operator of RenderMode) (Manual entry)

Named parameter versions of the following functions have been included:

• SetupProgram (Manual entry)

• SetupScreen (Manual entry)

• Bitmap constructor which takes an Allegro BITMAP (Manual entry)

Others:

• Added some simple demos which show how to load and show a bitmap, render text and write a game loop

• Bitmaps are no longer stored in the memory unless you choose them to be

• New Transforms -modifier: SetClipping - Sets the clipping region of the screen (Manual entry)

• Fixed the manual to reflect some modifications in the past versions

• Fixed the issue that the text would render always in black with some hardware

• Now the demo uses the correct version of Allegro

• Once again, several other minor stuff which were requested but I can't remember now

Also now with the new RenderMode system, do you think that I should add a way to rotate and stretch the sprite with something like RotationMode and StretchMode?

I'd also like to know what's in fact the best way to render to a texture. PBuffers or frame buffer objects? What are the possible limitations or issues with them?

Also something like PixelShadedMode is in my mind but I'll have to implement a nifty system I have in my mind first and it may take some time...

EDIT: Added a few list entries that I had forgot about
EDIT2: I forgot to mention that now OpenLayer uses an advanced FPS calculation system which tries to stabilize the game speed even better

PBuffers and framebuffer objects should work about the same (probably framebuffer object slightly better). PBuffers are IIRC Windows-only, you have to use WGL for them and have quite complex specifications, but framebuffer object isn't well supported (new NVidia drivers will support them, I have no idea when other vendors will start supporting them).

If OpenLayer isn't doing any strange things, the bitmap goes into system memory and OpenGL takes care of managing limited video memory space to make best use of it.

Fladimir, have you considered looking at some of the threads and documents Korval did on the Allegro Pro blitting method? He seemed to be also debating similar issues. Perhaps some of that would help you?

You forgot to remove Allegro/AllegroGL headers from Source only distribution.

Yeah the fonts were black, and the paddle tinting didn't work. Now it's all good

Seems that the triangles don't connect seamless in your case. Either OpenLayer isn't passing exactly the same coordinates for equal points (whic I doubt), or it's a bug in your driver.

Have you tried getting the latest version of video card drivers?

EDIT: Just noticed I've the same problem

The problem is in fact in the drivers or maybe with some graphics cards. I haven't experienced with my Radeon 9800 but many others have. OpenLayer renders everything by using GL_QUADS/GL_LINE_STRIP so the produced triangles should be seamlessly connected. But it seems that the bilinear filtering makes it to look uncorrect.

I should add a possibility to use multisampling instead of bilinear filtering, maybe then it would work with everyone. The problem would then be to choose when the bilinear filtering should be used or when multisampling should be used instead. Anyways it shoulds strange that the graphics cards just can't produce exact reasults...

If someone has found a good solution for this let me know!

If it does, it's a serious driver bug. Did you mean polygon smooth instead?

Do post this in Gamedev's news section. Openlayer could help a great many game developers in their search of hardware acceleration. And some publicity would be a good thing in the long run, both for Open Layer and Allegro.

OK, I've attached the only file that is modified in the post. Thanks in advance!

The reason for that I've only posted this to Allegro.cc thus far is that I've wanted to get it to a specific state (which is close) before releasing it to the wide public. Maybe now if the anti-aliasing fix works it's the time already.

Carrus, that's a great idea indeed! Actually I thought about separating Allegro's and AllegroGL's functions from the OpenLayer code the same way to make it easier to be ported to use other libraries instead. But I hadn't thought about using it in this case.

Even if it did and you would've used OpenLayer you might still not know After all, the "internal" stuff is separated from the actual interface and thus if you use the library it won't matter what the library actually does deep inside. All that you'd see would be functions like Bitmap::SetAsSurface and that's it.

Steve, did you try the version of the library I attached to this post? (Of course you'd have to re-compile the demo. I'd attach a compiled version of the demo, too, but it's too large to attach)

EDIT: Whoah, the download rates of OpenLayer have jumped to a new high!

EDIT2:

Yeah, usually they need to select the rendering position, store the old transformation state first, select the color and things like that. You're right, maybe all the "startup stuff" should be put in a function.