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

Do you ship the correct Allegro .dll with the demo this time? I wont be using Windows for some time so I wont have a chance to test it before you can give me an answer, most likely.

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).

Very nice! Lots of new stuff.

Rendermodes are easy to use and could really clean up some of the api. example:
Blit, BlitRotated, BlitStretched, BlitTransformed, BlitDistorted
now become... Blit
Then again, maybe all that extra Mode()+Mode()+Mode() typing would get tedious?
Maybe the *Mode()s could become Tint(), Flip(), Clip()

How does GainAlphaMode differ from other blenders? Should it be in the blender section?

What happens if I attempt to store a bitmap in video memory, but video memory is full?

It looks like the api is becoming inconsistent, but is improving at the same time. I see 1.9 as a transition phase. The api needs to remain clean, simple, consistent, sensibly organized, and small; but capable of a lot. It also needs to have a familiar look and feel for Allegro graphics function users.

Extreme Restructuring ?: I notice that individual things (bitmaps, ellipses, whatnot) all have similar transforms before the global transforms are applied. Strangely, they all have different interfaces. ...but I am too tired to think clearly now

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.

Maybe, and I'm most afraid of that the newcomers may not get the idea immediately, thus thinking that there's no way to rotate or stretch the Bitmaps.

I don't think so. GainAlphaMode adds an extra alpha channel to the Bitmap when it's rendered. The two alpha channels (the Bitmap's own and the one from GainAlphaMode) are multiplied together to get a cumulative effect. I should add an example to show how to use this but the concept is pretty simple actually.

For example if you wish to blend a texture on top of a player:

Bitmap texture( ... );
Bitmap playerBmp( ... );

// Render player's Bitmap as usual //
playerBmp.Blit( x, y );

// Render the texture on top of it with 30% opacity //
texture.Blit( x, y, GainAlphaMode( playerBmp ), 0.30 );

Note that you can also choose the anchor point of the alpha Bitmap.

Actually it comes with a demo which uses the correct dll instead

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?

Just wanted to say that the demo game finally works as it should on my PC! Yayness! Good work, Fladimir!

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

OK, now it's fixed.

I'll take a look at those then.

That's great indeed! I take it was the text rendering that didn't work correctly before?

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

If I switch to drunken mode in the demo, I get lines diagonally through all the bricks (one line per brick) and lines through the background, too

Screeny here: [url http://www.andrew.cmu.edu/user/jandrews/lines_screeny.PNG]

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

Similar problem was reported in previous thread and was fixed by turning off antialiasing.

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!

I just noticed that too:)

I suppose you mean antialiasing?

Bilinear filtering can't cause this kind of artifacts.
I suggest two different functions: one to turn on/off bilinear filtering (or preferably choose between "nearest", "linear" and "linear_mipmap_linear" [with automatic mipmap generation:P]) and one to turn on/off antialiasing.

btw, I think you forgot to include the two changes in Includes.hpp I send you:
#include <gl/glu.h> --> #include <GL/glu.h>
#undef DestroyAll

doesn't matter too much though

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

Ah, sorry I should really make a todo log or something. Well, at least I changed those now.

About the anti-aliasing problem, could you try the version of the library I've attached in this post and tell me if it makes any difference?

Now when I think of it I believe this is the one which is guilty, too. That's why I posted a version of the library which uses only the GL_LINEAR texture parameter for anti-aliasing. After all the bilinear filtering is a texture raster thing which shouldn't affect the edges of the polygon.

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.

Sorry running Linux most of the time, so can't use the library. If you could attach the modified source files (or the entire Source/ dir or a patch) I can test it.

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.

Perhaps a driver architecture could be used to help prevent such problems? I mean, you can detect supported extensions, it shouldn't be to hard to dynamically create a polymorphic class that operates slightly different than the base driver, thus providing what essentially is a 'driver' class. Heck, doing that you could even implement a software driver for really slow, really old, really crappy video cards.

Then again, this may be how it works currently anyway. But I dunno... Haven't done much with openlayer yet

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.

I get the odd lines too (GeForce 6600GT).
It's worse in drunken mode BTW.

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.

(As I said in the other thread) the new version you attached fixed the lines problem for me. Hooray

Finally! Time for the 1.91 release.

Download 1.91, Update 1.9 to 1.91 (No precompiled demo), the Demo .exe only and the source only distribution

• Fixed away the diagonal lines which crossed the Bitmaps with some hardware

• Included the correct version of Loadpng in the package

• Fixed the header files to work in Linux without modifications

Seems to have cleared up the line issue for me Keep up the excellent work Fladimir.

void Print( const std::string &text, int x, int baselineY, const RenderMode &mode);
//RenderMode would need rotate() and stretch())

Fix that with demo programs and screenshots? or... maybe BlitRotated would call Blit(,, + Rotate(angle))? But having 2 ways of doing the same thing is just asking for work and confusion.

Are all OL angles CCW positive(including transforms)?
Might want to mention that arc and ellipse angles can be positive or negative.

GfxRend: Ok, I'm converted. The only thing left is EllipticalArcGradient- the mother of them all. (j/k!);D

And again and again...

EDIT: Ever thought about making DLL version on OpenLayer?

I'm hopeless I know I always just think that for a source distribution I have to include all the sources and headers from the original package...

Well, I haven't thought that's necessary.

Well, that's possible with the new system in fact. It requires some extra work in the TextRenderer's side, but still.

That's what I thought as well.

Yeah, I should indeed.

Cool stuff! I have to check this out! I'm not done with "terrain renderer" yet though so I can't fiddle around with anyhing else.

Wouldn't that be a little hard with the current rate of updates? Seriously though, if it is going to become a DLL, any program that use it should have an updater to keep the DLL updated.

Oh, and don't you think OL 2.0 should actually become OL 1.0? I mean, 1.0 wasn't a real finished one...

Hi,

i have created a Bitmap-object from an Allegro BITMAP, but when i try to blit it to the screen nothing appears!

I think that i have detected the reason in line 868 of file "Bitmap.cpp":

bool Bitmap::
Load( BITMAP *bmp, bool hasAlphaChannel, bool convertMagicPink ) {
   Destroy();
   
   this->bmp = bmp;
   this->isSolid = !hasAlphaChannel;
   width = width;
   height = bmp->h;

Instead of 'width = width' it should be 'width = bmp->w'.
Otherwise 'width' remains zero.

Ouch, that's because of the search and replace I had to do because I didn't store the bitmap in the memory anymore... It also seems that this wasn't the only problem in the loading functions. Thanks Norebo, I'll post the version 1.92 immediately.

OpenLayer 1.92 Released

Download 1.92, Update 1.91 to 1.92, the source only distribution

• Fixed all the Bitmap loading functions

• Fixed the named arguments that some of the functions take (I have no idea what I was thinking about when I wrote the bit masks...)

• Changed the source to not to use the GCC min/max extensions

Even if you want 3D graphics you can still use OpenLayer to render text, load textures and render the GUI. Remember that you can use pure OpenGL along with OpenLayer.

Yes, GUI was what I had in mind.

Note that loading the textures with the correct format is very easy when using OpenLayer. Simply:

Bitmap myTexture( "Gfx/Texture.png" );

// Get ready to render with the texture //
myTexture.Select();

The Select -method is equal to OpenGL's glBindTexture.

Hmm, sorry to say: it seems you broke the demo in 1.92. Fix below:

EDIT: forgot to say, I used to 1.91->1.92 upgrade zip

OK, thanks, I just had included a wrong version of the demo in the package. I also changed the extraLifes >? 0 to max( extraLifes, 0 ).

Demo crashes for me. Last line in the log is loading the background. Also, does it compile for MSVC? Have you considered not using uppercase in your filenames?

[edit]
I'll have some time to work on a nice demo I'm thinking of in a few hours. But I'd need to be able to use OpenLayer to be able to use OpenLayer

You're using 1.92, right? Could you check if the bitmap exists where the log says it should? But if the log doesn't say that the bitmap isn't found or is in a wrong format then I'm clueless without some extra information because at least everything works for me. I've attached a .bat file to compile the debug version of the library, so could you use it instead and tell me where it crashes?

About the uppercase letters in the file names, is it bad? I don't know yet if it compiles for MSVC as I can't try that myself.

I could make life easier to newcomers (

1 .a + 1 .dll

-VS-

8 .a + 3 .dll

).

Speaking of DLLs, they must be in same folder as exe in order to be found, ie putting them in "DLLs" won't work.

It's not "bad", so much as "annoying". Because Linux users have case-sensitive filesystems. I think, maybe, today I will write some scripts that "fix up" your library, primarily making everything into lowercase (with reference checking and all), then try compiling under Cygwin, which has case-sensitivity also, then try to make it work under MSVC. Your ">?" stuff might not work though, it seems, so I'm worried about that.

Hrvoje: Or they can be in the PATH.

Yeah, I originally had them in the base folder of OpenLayer but then I thought everything would be better organized if the were in a Dlls -folder instead. Of course this may cause many "Why doesn't this demo run?" problems if I introduce OpenLayer in Gamedev where few have Allegro (or GZip) installed and not everyone would think that if a dll is not found it can be found in the dlls folder. So maybe I'll move them to the same folder as the demo.

Maybe, maybe. I hadn't thougth that I could include the other dlls inside OpenLayer's dll file.

I've got rid of those in 1.92.

I always use Windows as if the file system would be case-sensitive and I don't find that so annoying. But maybe that's just me, I like starting all the names with an uppercase letter.

Well, as long as you're certain that you've followed case-sesitivity, I suppose I can let it be. It'll still be an annoyance for me and probably other Linux users, though

And if you've gotten rid of it, then good. I'll try making up a project file for it in a while. Would you like to include it in the distribution? It'll be a VC7 project, unfortunately, but still.

Allegro's angles are CCW negative. Traditional Angles are CCW positive. I don't care which standard OL uses as long as it's consistent throughout the api; I'm making myself float d2r(float); //degrees to radians anyway.

Is OL z-negative into the screen? If it is, great. Without changing the projection, I could render 3d stuff in a layered 2d overhead world. UP = z_positive. No worries about render order.

No, no! I'm wrong! "Regular" gfx_rend functions provide instant syntax checking for coders, which prevents bugs. A "StartupStuff" function may reduce the GfxRend function list by 60%. Unfortunately, coders may forget to add all of the parameters for what they want to do, and end up cursing over why their circles are all 1 pixel at (0,0).

Sure why not, as long as it compiles in GCC (I can do the required modifications if those are needed, though).

Jim, I forgot to say that you can compile OpenLayer with -DOL_ANGLES_IN_DEGREES and the angles are then passed in degrees

By the way, it seems that I forgot to mention that now OpenLayer uses an advanced FPS calculation system which tries to stabilize the game speed even better. The problem with the usual FPS calculation method is that if the FPS is calculated over only a few frames it won't be stable and accurate. On the other hand if the FPS is calculated over dozens of frames the game won't be able to act to sudden drops or jumps in the game speed (like an explosion which spits out thousands of particles).

Therefore I decided to use a system which tries to combine the best parts of both methods by dynamically changing the number of frames over which the FPS is calculated depending on the situation. If the game speed drops or jumps suddenly the FPS calculator will be set to temporarily to use the higher frequency calculations increasing the responseability. Then when the FPS stabilizes it'll gradually switch to use the lower frequency calculations increasing the accuracy.

What about this code for SetOrthographicProjection (instead of the current code of course):

void Settings::
SetOrthographicProjection(int w, int h) {
  glMatrixMode( GL_PROJECTION );
  glPushMatrix();
  glLoadIdentity();
  glOrtho( 0, w, 0, h, -1, 1000 );
  glScalef( 1, -1, 1 );
  glTranslatef( 0, -h, 0 );

  glMatrixMode( GL_MODELVIEW );
  glLoadIdentity();
  glDisable( GL_DEPTH_TEST );
}

To preserve API compatibility add default arguments
SetOrthographicProjection(int w = SCREEN_W, int h = SCREEN_H);
to the declaration.

It allows you to write a program designed for 800x600 and run it in any resolution with all graphics automagically rescaled by OpenGL, by passing the real resolution to SetupScreen and the design resolution to SetOrthographicProjection.

There are some issues with GK though which cause text to appear in different size. These can be solved by adding

gfx_driver->w = DESIGN_W;
gfx_driver->h = DESIGN_H;

after SetOrthographicProjection. This causes SCREEN_W and SCREEN_H to return the design resolution to GK.

Note: I grepped through Allegro's source and it appears to be quite safe to change these. Of course, it is still a dirty hack which might be less portable than normal Allegro code. So use it at your own risk!

For example, demo in 1280x1024 fullscreen by changing the call to SetupScreen to:

   // Open the game in a 800 x 600 window //
   if( Setup::SetupScreen( 1280, 1024, FULLSCREEN ) == false ) {
      allegro_message( "Error while trying to set graphics mode!" );
      //exit( -1 );
   }

   Settings::SetOrthographicProjection( 800, 600 );

   gfx_driver->w = 800;
   gfx_driver->h = 600;

great idea

Fladimir: So, when OL can do hardware rendering to video BITMAPs, will all of the blit,text, and gfx_rend functions get an extra *BITMAP parameter, or will there be a global target *BITMAP?
Will each BITMAP have its own set of transform settings?

What additional functionalities would make openlayer complete?
Given that, what do you want the final api to look like?

Sounds good, but I think I'll change the OpenGL port of Glyph Keeper instead of changing any internal values of Allegro. An another way to get the same effect would be Transforms::SetStretch( 800.0/1280.0, 600.0/1024.0 ) but then SetStretch couldn't be used to anything else (without multiplying the parameters with those parameters).

I believe I just write Bitmap::SetAsDestination() or a similiar function. Of course I have to add a function to set the screen as the destination. In fact as it's possible to use the screen contents as a texture I could include a global screen variable as in Allegro. I'm not sure about this yet, though.

Pixel shaders, for example. I've been designing a system I call ShaderLayer and it's intended to be an easy-to-use tool to make 2D shaders.

And I've also thought about making an gui library for OpenLayer and then there's the rendering to Bitmaps.

Well, new stuff is always new stuff. The final API will just include more and do everything better but thus far the API looks fine for me...

Hmm. You should only include files with "..." if the file is in the same directory. It seems MSVC doesn't like to search the include paths. (Working on the conversion now)

[edit]
Alright. I got it to compile. Making a diff now. Is there a CVS repo anywhere?

[edit]
Well, I have it compiled, but I don't have allegro gl. Phooey. I'll have to look more later. Anyways, currently attached are the diff and vcproj files.

Um... no. He has yet to put it on CVS AFAIK.

Two more things about libz dll: both libz.dll and zlib1.dll are same and are not needed because lib/libz.a is static library. You should also replace allegro library with static version.

Nope, seems like I'll have to play with SourceForge a bit. I have to get the web page and the manual there and get the CVS to work. Is there any way to apply the .diff file without CVS, though?

Thanks a lot! Could you also send me the .lib files so I could add a Visual C distribution?

Yeah, but for some reason Glyph Keeper sets the library to use dynamical linking. I should try to disable that, though.

Maybe, I've always used dynamical linking myself but static linking could be easier for the newcomers.

Alright, I'll keep that in mind.

Try cd'ing to the openlayer directory, and running patch -p1 <file>

Assuming you are using linux of course. That just flat out doesn't work without properly downloaded programs in windows... (assuming flad is using windows).

Maybe Native Win32 ports of some GNU utilities will help?

Yeah, I'm using Windows so there's no patch -command. The GNU utilities seems to not to have that either...

Ah OK, I thought I was supposed to use the command prompt thing that came with it.

He said not using CVS, not not using basic tools like patch

Not quite, actually. Allegro's angles are anti-clockwise positive.

Remember that on a computer screen the y coordinate increases downward!

1.92 bug: LineStrip: when 2 adjacent control points have the same x or y values, spiking occurs (see attachment)

It would look better if the (highest index) control points were rendered last. The attachment shows an overlap point.

LineStripGradient( *xCoords, *yCoords, numCoords, innerStartCol, innerEndCol, outerStartCol, outerEndCol, float lineWidth = 1.0);Can anyone think of a use for this function other than curved lasers?
You can do something similar by overlapping plain lineStripGradients.

BUG - Building ol::Bitmap from datafile

Both OpenLayer and Allegro will try to free bitmap pointer (data->dat) causing Segmentation Fault.

Perhaps there should be a Bitmap(DATAFILE * data, int index) constructor? Or some way to make Destroy() not free the bitmap?

Actually a similiar function exists already (the one with the side colors). I'm using that one to make an "afterburner" effect.

Thanks for that, I already started to wonder why the line strips weren't always rendered correctly.

Well, I always use it the other way around. Just flip your arrays and colors and it's fine.

OK, now I've made the Bitmap to not to try to free any Allegro BITMAP it's given.

Well, Fladimir, I got it compiled. And it works. 1.47 megs of fun, available for your pleasure at [url http://cgamesplay.com/files/openlayer.zip].

Now, why do i only get a half frame per second?

Thanks a lot!

Bad drivers I guess so that it uses software rendering instead of the graphics card? Could you try updating your drivers? You should be getting at least a few hundred of FPS in the demo...

EDIT: Ps.
http://crystalstorm.ath.cx/Shot4Small.jpg
(The image works only when the server is online)

I think I'll have to improve the look of the radar, though. Any suggestions?

Radar looks good, where are all the little dots... oh and the green bar should be more prominent, maybe a single color.

Eh? Is there a problem with the image loading or something?

Also CGamesPlay, could you also change the Install.txt to show how you can install the package for MSVC (If all the .lib files are in the Libs-folder)? Thanks in advance!

- Link your projects with (gcc): -lol -lglyph -lfreetype -lloadpng -lpng -lz -lagl -lalleg
                                 -luser32 -lgdi32 -lglu32-lopengl32
                                 (All linker commands should be in a single line)
                         (MSVC): alleg.lib ol.lib agl.lib user32.lib gdi32.lib opengl32.lib
                                 glyph.lib freetype.lib glu32.lib loadpng.lib libpng.lib zlib.lib

Easiest thing I've done all day

Updating my drivers fixed the problem, now it runs nicely. About 60 FPS.

Can't get the ball to go up though, and it likes to shoot to the left, and are the physics dependant on the framerate (if I move the paddle up too much the ball goes through it, maybe)?

I get 60 FPS too with WindowsXP Pentium4 and a GeForceMX4000. So I assume this is because of Vsync since my lcd monitor refresh rate is 60hz. It might be useful to have a DisableVsync() function so we could at least test the potential FPS...

At least with nvidia drivers you should be able to turn vsync off somewhere in the drivers configuration.

But I agree, a function to turn off vsync would be nice.

I noticed Demo.cpp still #includes <loadpng.h>

There's no need to include the loadpng header anymore, right?

Indeed it seems that way.

      // Does the ball hit the paddle? //
      if( ballYPos >= paddleYPos && ballYPos < paddleYPos + paddle.Height()
          && ballXPos >= paddleXPos
          && ballXPos <= paddleXPos + paddle.Width() ) {

This will break if the framerate is such that the ball speed is faster than expected. A quick fix would be:

      // Does the ball hit the paddle? //
      if( ballYPos >= paddleYPos && lastBallYPos < paddleYPos + paddle.Height()
          && ballXPos >= paddleXPos
          && ballXPos <= paddleXPos + paddle.Width() ) {

This does demonstrate the benefits of the 'standard' allegro method of framerate control, which simplifies testing as you know the behavior will be exactly the same at all framerates, not just similar. With a solution like the OpenLayer-encouraged one, all collision checks should really check the whole line of possible positions, as it is no longer correct to make assumptions about the maximum movement speed of anything.

A symmetrical outerStartColor and outerEndColor would look better. I'd replace the left/right color function with that. Then the outercolors could get a gradient too.
Inner (1.0,0.7,0.7,1.0) to (1.0,1.0,1.0,0.3) //pink to smoke
outer (0.0,0.0,1.0,0.5) to (1.0,1.0,1.0,0.0) //half blue aura fades away