Just when you thought the world was safe from OpenLayer a new version strikes in!

Download 1.81, Update 1.8 -> 1.81 and Web page

• Added support for Bitmap blending effects (Thanks to Krzysztof Kluczek for the idea of the system)

• New blending effect: Tinted blitting (Thanks to Krzysztof Kluczek for the idea)

• Automated the loading and destruction of global Bitmaps and TextRenderers (No more "you have to wait until the screen is set up and then you can load them")

• Ability to enable automated garbage collecting for dynamically allocated Bitmaps and TextRenderers

• Screen has been renamed to Transforms to avoid naming collisions (Thanks to imaxcs for pointing out)

• New Transforms -effect: SetColorChannels - sets the strength of the output color channels

• Fixed the color conversion issue which disabled the alpha channel with other color depths than 32 (Thanks to Jeremy Vight for pointing out)

• Finally an offline version of the manual is included!

• Fixed the anti-aliasing setup functions (Thanks to NyanKoneko for pointing out in her article)

• Code has been separated to class-specific header and source files to increase maintainability (and readability)

• Several other minor fixes and tweaks (Thanks to many of you for testing!)

If you're using Screen in your code and used to it, #define OL_USE_SCREEN_ALIAS before including OpenLayer.hpp to use the name Screen instead of Transforms

This time I've tested it so well that I'd be surprised if any problems are found (by which I mean it's the "Find the problems" play again )

The webpage doesn't load for me

Why don't you mirror it on the sourceforge webspace? It's a nicer url anyway ...

The webpage doesn't load because Fladimir shuts down his server at night. But he already has a sourceforge mirror that was announced in the 1.7 thread: https:/sourceforge.net/projects/openlayer/

Wooot 1.8 is out! Cheers, Flad!

[EDIT]
Found a couple of problems

glyph.h and loadpng.h aren't included. (might be a problem for people who didn't install an earlier version of OpenLayer which did include these headers)

There seems to be a problem with either the Rgba class or with the TextRenderer:
This should produce a red font but it is indeed quite pink:
TextRenderer bigtxt("gfx/Arial.ttf", 30, 30, Rgba(255, 0, 0, 255));
Green and blue aren't looking their best, either

I second that

all my black text is now blue, and when I change the color of the text, it seems like the blue is always set to 1.0.

Yeah, I'm having similar troubles, Mark. (see my edit)

Perhaps Fladimir was in "Drunken Mode" when he was working on that part of his lib

er, I would hope he has a more friendly page than the default sourceforge project info one ... he can put it at http://openlayer.sourceforge.net I think, but he hasn't.

Anyway, it's not very friendly to link a page that is consistently down, especially without mentioning it ...

Any chance of backporting some of that functionality in AllegroGL? It would be a great time-saver as well for the new Allegro API OpenGL driver, I think.

Well, my sig tells that the site is down during the nights... so that I wouldn't need to explictly mention it over and over.

I haven't fully discovered all the features of SourceForge. Do they offer PHP and MySQL support? Those are vital to my site... I've also been offered a mirror in retrospec.sgn.net. So soon all these problems are gone. Sorry all Americans, I know the night here is exactly at the same time as the evening in there.

What the damned... must be because I changed the way the color channels were affecting text right before submitting. And I even tested it out but no... I'll submit a new package right on.

Ah, this time I made a totally fresh package and forgot those.

That must be it Though I don't intend to be in drunken more before Saturday...

What else... I forgot to change my sig of course!

How would that work then?

EDIT: Arght, anyone spot anything fishy in this line

Rgba affectedCol( col.r * channels.r, col.g * channels.g, channels.b * channels.b, col.a * channels.a );

No wonder I didn't find it with white text... No more drunken coding for me

EDIT: New package, 1.81 has been released. See my first post - for modem users there's a small update package from 1.8 to 1.81.

Yes sir! Shell into your account there at (shell.sourceforge.net) , there is lots of stuffs.
For more info go to your project page, into the admin portion, then to the link Shell/DB/Web.

A good idea would be to have a check-list to run by every time you create a new package.

Hehe, I actually have one I tested every function and also the final release package that they worked but it was just bad luck that white text worked even if every other text color didn't and I happened to try only white color You won't guess how much of my development time goes to testing... even if I've tried to code everything, even with the expense of performance, such that it works. And won't fail. Ever.

But hey, I needed only one fix revision this time! That's a lot better than with any previous version! I bet that's because now I've been organizing the project a lot better, I have all kinds of UML dependancy diagrams and whatnot.

That's great! If I manage to mirror the site to Retrospec's host I bet I can do that just as easily with SourceForge, and there it's all free bandwidth!

Text problem fixed! Good job

Awesome. check out the screenshot of my latest OpenLayer project.

- in the docs, the example code for PolygonGradient says PolygonOutline
- I would like (please very much) a texture shaping/stretching within the polygon routine. if you look at the attachment, you can see the heart meatre, which I would normally blit like so:

player_class player;
BITMAP health_bar;

float health_bar_width = (player.health/player.max_health) * health_bar->w;

masked_blit(health_bar, buffer, 0, 0, 20, 20, health_bar_width, health_bar->h);

my proposal for an OpenLayer solution is to have a function that changes the points of the clamped texture. That way it would also be possible to do some nifty texture stretching and maintain a clipped edge.

The evil copy paste strikes again!

I actually guessed that by looking at the screenshots Those been in my todo-list for a long time - textured polygons and clipped blitting. Shouldn't be too hard to do but designing the actual interface is a bit harder. If you have any ideas go ahead

ClipBlit(float des_x, des_y, tex_x1, tex_y1, tex_x2, tex_y2, rendermode, flipped)

ClipBlitTransformed(float des_x1, des_y1, des_x2, des_y2, tex_x1, tex_y1, tex_x2, tex_y2, rendermode, flipped)

the other interfaces would be the same like ClipBlitRotate, ClipBlitTransformed...

That'd mean an additional 14 blit functions I thought it could be more like a RenderMode or something... And then make a composite RenderMode which can be used to pass 2 or more RenderModes instead of one.

haha, true.. ok, so like..

Bitmap picture;
picture.ClampTexture(float x1, float y1, float x2, float y2); // adjustes all the blits and stuff
picture.ResetTexture(); // resets to the right corners

Right, even if that'd mean moving more and more towards a state based system. I think I'll allow both ways - using a RenderMode and functions like that.

yea... that does make me mumble a little bit I hate to ask you to do more work, but I would prefer the functions like ClipBlit. I can do whatever though. as long as I get my heart meater.

It's not the more work but more like the extra complexity and the huge number of different functions. Maybe I'll do it with the RenderMode system and nothing needs to be changed.

Then what about the textured polygon system?

Nice work Fladimir, I must say. I might whip up something with OpenLayer later
I haven't played with it yet, just took a few glances to the code.
Some remarks:

I think that

GfxRend:: PolygonOutline()

is missing

glLineWidth( lineWidth )

- line there. Also, that very same line isn't needed in

GfxRend::RectOutline()

.

You're using GL_QUADS quite a lot. IIRC the triangle strip is a bit faster (on some cards, maybe?). So it might be worth converting those to GL_TRIANGLE_STRIP and doing some benchmarking. That's quite a lot of work and might not even be worth it. Actually, I might try that myself. I will keep you informed should I find some time to benchmark them.

As for the demo game, you might want to change the ball and the paddle color. Now they're both quite grey which makes them hard to spot from the background (especially the ball). That's an opportunity to use the tinting feature!

Anyways, looking good, keep it up!

EDIT: Oh, the fonts show up in black on this old K6-2 machine of mine. Geforce 2 MX and WinXP. Also the Game over text doesn't seem to be properly centered vertically (don't know if this is intentional or not). On my new PC all worked fine, though I think it was 1.7x version I tested there. I will try this on that new PC as soon as I get home. Screenshot attached.

quote: what about the textured polygon system

uh.. that's a tough one, that when you get into the whole UV unwrapping thing. just leave that one out for now.

well, on second thought you should probibly use an array of points like you did with point[NumVerticies] and Colors[NumVerticies]. you would have to check that all the points are witin the bitma.... but if you didn't.. oooOOOhhhh, then you could have texture patterned sprites!

Gar... a bit frustrated.

• All of my pictures have a white background again where they should be transparent. The wierd thing is, after I display some text from my GUI functions, the transparent stuff works and the white goes away. The worst part is, I can't fix this by putting set_color_conversion(COLORCONV_KEEP_TRANS); in the startup function anymore. Can you simply remove your color conversion settings and just let the programmer specify the color conversion mode? Here is the text display code:

• I still have to call Settings::SetOrthographicProjection(); after all text printing functions.

  
  

• What happended to the BlitTransformed arguments for x,y,pivotX,pivotY? My sprites seem to draw as if the x,y is at the upper-left position, when it used to be in the center of the sprite (hence the pivotX and pivotY were in the center), code:

  if(d_visible&&graphics.current_image()!=__apsl_blank)
    graphics.current_image()->BlitTransformed(d_x,d_y,get_width(),get_height(),get_width()/2,get_height()/2,d_rotation/57.2957795131,d_factor,d_flip);

I can't seem to get it to act like it did in previous versions.

[ EDIT ] I just tried compiling and running my main OpenLayer project, and not only does everything draw not at the pivot, it crashes now after the main menu... not sure why, all I know is that it didn't before.

I had a similar problem. add a Blenders::Set(( ALPHA_BLENDER ));
before you start drawing the alpha bitmaps and see if that works.

Nope, the Blenders::Set(( ALPHA_BLENDER )); doesn't do the trick. Thanks for trying to help tho.

Try putting a one-pixel-wide outline around the bitmaps

heh, I know this sounds wierd, but try printing some text to the screen before you draw the bitmaps

That's from the 1.7 release thread. Sounds like the same problem you're having, Jeremy.

How does the pixel thin border fix it? Must it be a transparent border? Why did it work just fine for me in version 1.7x and not 1.8x? Why does it work after my text printing function and not before?

The bigger problem is my sprites/Blits are not drawing at the pivots anymore, making everything shift to the lower-right (I was drawing at the center of the sprite). Anyway, 1.8x has unfortunately broken my projects quite a bit, and I'll roll back to 1.72 (if I can find the older versions files).

I've been drawing only png's And text so I haven't run into any of those problems yet.

I'm sure Fladimir will be checking this thread and he'll figure out the problem. I have 1.72 if you need it in the meantime...

Thanks, but I grabbed 1.72 from sourceforge -- luckilly he posts older versions.

I won't roll-back yet, I'll wait for Fladimir to see if he wants me to try anything.

I am only drawing PNGs myself...

Whoa, Mark is right. Drawing text before blitting the Bitmap is what makes it work. I was doing that and that's why my Bitmap backgrounds were properly transparent. I removed the text.Print and now my Bitmap background is solid black

How would I go about getting OpenLayer 1.8 to work with MSVC?

I think you would need to build all the required libs with MSVC. That might not be a lot of fun. It might be a whole lot easier if you just used Dev-C++...

Yeah, me! Well, I'm glad to know you got two something out of USteroids I wish something like OpenLayer had existed back then, because the initial plan was to convert Steroids to OpenGL (in 2d) and work on top of that. Although, IIRC the fact that the Steroids code was so messy was the reason I opted for a complete rewrite (in 3d as well).

But yeah, I might do a simple game with this later, because my current project has been pretty much frozen for the past 6 months

Anyway, what do you think of the GL_QUADS --> GL_TRIANGLE_STRIP conversion? Might it be worth trying?

Probably, I could make it so that if you #define OL_USE_TRIANGLE_STRIP it'd use the triangle strip instead to make everyone happy

Maybe it's best that it didn't Ultimate Steroids is great as it is, though a bit hard especially if you don't get any weapon upgrades for a while. I've always thought about changing the source to give at least one weapon upgrade every 4 levels but I thought it'd be cheating...

I get the same error as in 1.7 - I even tried to compile the sample Dev-Cpp project to be sure I haven't made any stupid mistakes, but it does not work, too.

edit

I am downloading Dev-Cpp 5 now... maybe that helps?

Aagh! Guess what was wrong with the bitmaps? When I was re-arraging the code I, for some reason, got rid of the line glEnable( GL_BLEND ) from a setup function (as I thought about moving it to somewhere else). Simply call:

glEnable( GL_BLEND );

before you call any rendering functions and everything should work just fine

Damned with me...

I hope so... it somehow seems like you're using a wrong kind of a compiler or something.

Heh, yeah... they were originally supposed to look "metallic", but maybe I'll add some tinting to make them look nice... any suggestions about colors?

EDIT: About BlitTransformed... That was just a small code re-arrange problem... I forgot to apply the pivot after moving the raw drawing code out of the function. I'll post 1.82 soon, it'll be fixed then. About the crash - I have no idea about that, there's nothing in the function that could possibly crash. But when I looked at your code it almost looks like if you try to inline everything... maybe the compiler doesn't like that?

BlitTransformed in all it's simpicity:

aha! new request please. I would like a GfxRend::Line function that takes more than 2 points. I have drawn multiple line segments, but they look disconnected with their thick width... so:

GfxRend::Lines(Rgba color, float width, float x, float y, float x2, float y2, ...);

pretty please?

as for the ball, I think just bright white would be dandy.

AFAIK that's just the way OpenGL draws thick likes.

I have a request, too. Is there any way you can make a function that will continue to code my game and draw gfx while I'm at work tomorrow?

Settings::MakeGameWhileImAtWork(true);

Damn, the weekends go way too fast!

That's why I have to make the function to use quads instead of lines. Any ides of how to do this best?

Sure, I actually guessed you need that by looking at the screenshot.

I actually made it white myself, and made the paddle blue.

Has anyone else had the problem of the window not closing upon exit and you have to shut it down by force? Seems to be more of a problem in windowed mode than in fullscreen. I'm guessing it's an AllegroGL bug because I always had a problem shutting down the examples that come with AllegroGL. Anyone else having this problem with their OpenLayer programs?

Upgrade your version of Allegro.

None of the Allegro4.03 examples exhibit the problem. Currently, OpenLayer doesn't work with the WIP or the beta releases of Allegro.

I'm having trouble using Bitmap::LoadListOfBitmaps; likea so:

I get a compile error that says Blit has not been declared, or BlitStretched (whichever the case may be).

Nevertheless, it is a bug in Allegro 4.0.3.

Not even if you use the proper (ie, CVS) version of AllegroGL?

I have a very strange problem. I haven't read everything that was posted about OpenLayer so I appologize if this was already answered somewhere. Anyway, here's the deal. Demo.exe worked out of the box just fine. Then I compiled all the necessary libraries and OpenLayer myself with the latest version of Allegro (off CVS), AllegroGL (also off CVS) and GlyphKeeper (0.26.2), everything for static-linking. Then I wrote a simple test program that just clears the screen and draws a white rectangle. That compiles and runs too, but it doesn't display right. The rectangle is visibly made of two triangles. Then I added some text and a sprite and again, every rectangle (sprites and glyphs) is made of two triangles with a diagonal line in the middle. And now comes the weird part: Demo.exe does that too now. I haven't touched it or anything else in the OpenLayer directory, everything is straight out of the zip. It was working before and now it doesn't. And one more thing, when demo.exe was working, it did about 450 FPS, now it does >1000. Any ideas?

Did you enable GL_POLYGON_SMOOTH? It's off by default. Did you enable blending? It's off by default.

Polygon Smoothing will cause a double-hit along edges of connected triangles. If you enable blending on top of that, you'll get double blending, which is likely what you're seeing.

That sounds like what could be going on. Except that I did nothing like that. All I did was compile the code that was in OpenLayer/Source and the following code:

But, I just noticed, if I comment out the text.Print(...) line, the double edge problem goes away. But then there's another problem: the mouse sprite is drawn with the bright pink background!

EDIT:
Adding Settings::SetAntialiasing(false); solves the first problem. But the second one (the pink background of the mouse sprite) is still there. And it doesn't explain why the same Demo.exe that was working before doesn't work anymore...

Excellent news, everybody! Hrvoje Ban sent me his precompiled version of the CVS dump of AllegroGL and it worked! When I had tried to compile it myself it couldn't for some reason to set the graphics mode at all so I couldn't have used it thus far. Let's see if this will fix some of the strange problems that some of you were experiencing. This calls for a new release (which I was planning to release anyways to fix the few things that I had messed up when I re-organized the code).

OpenLayer 1.82 Released!

Download and Website

• Included the latest versions of Allegro and AllegroGL in the package

• Corrected the blending setup functions

• Corrected the pivoted version of BlitTransformed

• Fixed one of the GfxRend's functions to not taking the line width in account

• Made the GfxRend's functions static (I had originally planned to store the circle accuracy and the line width there but then I wrote the Settings-class)

• Corrected the code to be strictly ANSI and Wall correct.

• Added the Allegro and AllegroGL headers to the package

• Corrected the offline manual to show advanced functions

Thanks to everyone who has replied in this thread and to Hrvoje Ban who told me about several things I needed to correct in the code!

EDIT:

Have you tried if that happens (with 1.82) with every bitmap with magic pink parts for you? Might be an incompability with the color depth of the bitmap and the color depth of the screen...

The fonts are black on my new PC as well, Athlon XP 2600+ and Radeon 9600 Pro. Also the ball and the paddle are still grey, that means the tinting isn't working on my Radeon. Maybe the fog settings are wrong?

The font in the demo is black on my pc, too. I'm guessing Flad might have compiled the demo with some of the older libs because the demo isn't exiting cleanly but programs compiled with the new libs shut down fine. So that problem seems to be fixed now with the new libs. Thanks Hrvoje! Looks like you were right, Evert - it must have been a 4.03 bug

It's good to be using the latest Allegro and AllegroGL rather than using the outdated versions...

My problems are going from bad to worse (1.72->1.81->1.82)...

Now OpenLayer cannot set any graphics mode. When the program gets to the SetupScreen function, the screen just blinks a couple of times like it is trying to set a display mode... and then it fails. I couldn't get full screen/windowed 800x600x32 or 640x480x(32/16) to work. The program then doesn't exit so friendly, just hangs after it fails to set a display mode.

Your demo even failed to set any display mode.

I'm not sure if anything else is wrong/fixed... can't get that far...

I copied all of the .DLLs to C:\windows\system32, I copied the include files to C:\MinGW\include, all the libs to c:\mingw\lib from the package...

:'(:'(:'(:'(:'(

I would try deleting all the allegro and allegrogl and openlayer includes and libs from the mingw folder and doing a clean install. So far the new release is working perfectly for me on windowsXP...
{EDIT}
Also check your task manager to make sure your game isn't running in the background. I had that problem yesterday and it caused strange behavior.

I just tried deleting/re-installing... nope.

It might be more specific to my hardware... I have the latest drivers. I am running on a Gateway laptop with an Intel Extreme graphics chipset.

But, at least every version of OpenGL software I've tried seemed to work on this laptop... up until OpenLayer 1.82

Thanks... but I'm still out of luck... still thinking I may have to revert to 1.72...

:'(

[ EDIT ] I don't see it running in the background... the Demo program hangs and likes to run in the background and I have to give it the ol' CTRL+ALT+DELETE, but my programs which don't check if the graphics mode was set (;D) continue to try and do graphical operations... which causes a nice ILLEGAL OPERATION SHUTDOWN screen to appear.

Did you check the running Processes in the task manager? My game made itself at home there in the processes and was causing all sorts of strange things until I shut it down. That seems to be fixed in the latest version, though...

Yeah, I checked there... no apsl_test.exe, demo.exe etc.

<large, bold>:'(</large, bold>

I finally got OL to run and to learn how to use it I copy-pasted some code snippets from the forums and compiled them. The above code snippet crashes at the specified line and Windows asks me if to send an error report. When I comment it out, it works fine and displays a white rectangle in the top left corner.

edit

Since we ( that means I, because I am the programmer, but speaking for the whole team ) decided to update our code with the OpenLayer Library, it would be useful if there were simple update files that automatically perform the changes to the next version. Just a thought, though.

In 1.82 the magic pink problem goes away

The antialiasing problem is still there though. What good is it to have this antialiasing thing if it doesn't work? Or is it just my system? I have a GeForce 6600 GT with reasonably recent drivers on WinXP...

Btw, are the antialiasing and other settings written to and then read from some sort of global system wide allegro.cfg file or something? That's the only explanation I could think of for Demo.exe not working right...

That code assumes you have arial.ttf in the same directory as the exe. It crashes if you don't...

Multisampling works just fine. Polygon smoothing, however, has some catches. OpenLayer should NOT use it without telling you, because it will likely break your program.

Edit: oops, dropped a negation there.

Good to know, maybe I should use multisampling instead. I just thought that it requires some specific hardware to work. But so it seems that the polygon smoothing does, too.

In OpenLayer, there's Settings::SetAntialiasing, which defaults to true. So it's not entirely "without telling you" (the manual says that anti-aliasing is on by default)

Always when our OpenLayer program crashes, check allegro.log! OpenLayer logs all error messages there!

You mean, there'd be a scrip to change new TintMode to TintMode etc. in the code or something?

This happened to me with the latest version of AllegroGL before but doesn't happen anymore with the binaries included in 1.82. If nothing else works you can use the liballeg.a and libagl.a from the previous versions.

That's strange. The font is loaded as an 8-bit "alpha" texture and the color of the font is set with glColor. Maybe this is why it doesn't work? I have radeon 9800 myself (a too new card so I can't catch all card specific problems ) About the fog settings, can you see anything fishy here:

EDIT:

If the precompiled .exe works for you but when you compile the .exe yourself it doesn't the problem is likely that you're using wrong versions of the external libraries. You're using exactly the same library files that come with the package, right?

I have recompiled the demo and it continues to crash. It's giving me a seg fault.

I am not getting an allegro.log.

Did the previous version do that? Have you copied all of the library and header files to the compiler's folders? A plain sigsev doesn't tell much... Do you have DrMingw or something like that installed and could you try compiling the demo with debugging information and running it to know where it crashes?

Hmm... then it probably crashes before the main-function is reached. I got that with the latest version of Allegro, too, before the new binaries. Sometimes I've thought about dropping the whole Allegro and AllegroGL to not to depend on them anymore... Could you try if the older versions of Allegro and AllegroGL work?

How odd..... I had a libagl.a that was very old in my lib folder
Replaced and it now it runs fine, no problems accept one noticed thing.
This time it dumped an allegro.log

How come I see a "No such bitmap." there?
I think your loadlistofbitmaps routine is going 1 extra.

Yeah, it's just my style. LoadListOfBitmaps tries to download bitmaps until it can't find one. The logging is done in Bitmap::Load instead of Bitmap::LoadListOfBitmaps. I could change this behavior, but I've always done the logging this way...

I did NOT recompile Demo.exe. At first it worked, then I made my own test.exe which didn't work, and then Demo.exe didn't work either. Demo.exe from v1.82 has the same problem too. I did NOT recompile Demo.exe! I repeat, I did NOT recompile Demo.exe!

Maybe I'll switch to use multisampling instead (or at least make it an option) and let's see if that helps then.

Hey Fladimir, thought I'd just say DONT GIVE UP! Its seems that the more people start to use open layer the more problems are coming up, but this is a very good thing! It'll soon be perfect and 100% compatible with everybodies setup and then you'll be a hero!

Heh, who has said I'd give up Slowly but surely I'm going to archieve my goal, and I'm going to do it no matter what. I still have one major version number to go before the big 2.0 public release. And a lot of minor version numbers for smaller fixes! There's nothing to be afrad of.

All this positive feedback just keeps me going and I don't think any bug/issue reports are anything negative at all - better to spot the problems now than later.

If I roll back to the older libraries for AllegGL and Allegro, then will I have to roll back to Allegro 4.0.3 .DLL? Will this cause some version issues to crop up again, or you don't know and I'll just have to try?

I'm at work now... so I can't play with it...

[ EDIT ] Yeah Fladimir, OpenLayer is awesome... it opens up alot of doors that regular Allegro didn't - I really want to use it, and it is exactly what I need for my latest projects... I just want it to work oh-so-bad.

Probably not. OpenLayer should now work with both AllegroGL 0.2.4 and the CVS version.

It also seems that 1.83 is in order to allow for multisample based anti-aliasing and I'm thinking what else I should include in right now... 1.9 is supposed to have the new primitive functions (multi-line drawing, ellipses, textured polygons, maybe something else) and TexturizedMode, MultiMode, some other Bitmap drawing modes (any ideas?). Anything else?

Here's also a nice way to tint several Bitmaps to a color efficiently:

TintMode myTint( Rgba( ... ));

// Enable tinting manually //
myTint.Select();

// All the following 100 bitmaps will be tinted //
for( i = 0; i < 100; i++ )
   bmp<i>.Blit( x, y );

// Disable tinting //
myTint.Unselect();

Fladimir, is there any chance you will consider doing a C version in the future?

Hm... why does that crash?

RP: Why? There is no need for a C Version...

edit

Jeremy, give us your specs please...

Since someone is asking, there IS a need for a C version .

So? Then give me the reason...

This has been discussed of already and I think it shouldn't be too hard to compile the C code as C++ even if you'd need to modify the malloc lines slightly... In my eyes it's the same thing that if a C++ user would have to use a C library they'd need to adapt C coding style to use the library.

EDIT:

Post allegro.log. Maybe the bitmap couldn't be loaded?

Because someone needs a C version. Or maybe you want to know why that someone needs a C version: because some people prefer to use pure C, or they don't know C++ at all, or they don't have a C++ compiler (ok, this is improbable, but still counts).

If that is the case, they are to write a wrapper. That easy.

Not knowing C++ isn't much of a problem as the examples in the manual show how to use the classes and functions. Prefering pure C... why do I use Allegro even if I prefer C++ over C?

Someone who doesn't know C++... to write a C wrapper over a C++ library?

If he/she does not know C++, he/she cannot either use the library or find someone who writes a wrapper for him/her. Personally, I prefer C++ very much over C, so that is why I am so strict.

It's not that possible to just to write a C wrapper over a C++ library... the whole inner workings must be changed in this case. The only C++ you have to know to use OpenLayer is to know how to call a member function of a class. And the manual shows how to do this.

I understand all the C users, but... if you want to use a C library you have to learn C coding style. It's the same as if you want to use a C++ library you have to learn C++ coding style.

That's exaclty the point. By using C++ you limit the potential users of the library. It's not a bad thing for the developer or C++ programmers, but for C programmers that need the functionality, it's a bad thing. And do you think it's right to alienate those programmers just because of a personal preference?

Ok, I'm just playing devil's advocate here, I do know C++, so why do I care?

But with that logic you could also say that by using C you limit the potential users (as I state in my previous posts). The best thing would be to have both C++ and C versions but... I'm not a C coder and maintaining the library is a big task already. If the C coders wish to use the C++ version all they have to do is to learn to call a member function

Since C++ is a superset of C, that's clearly not true, is it?

Since C++ is a superset of C, you can compile a C program in C++ with little or no changes (and by using extern "C" in your code, with no changes). But the C and C++ coding styles are different and that's the point. The problem is not what the compiler can do, but what the programmer can do!

Fladimir da Gorf: I think you're mixing object oriented vs. structured programming. We're talking C vs. C++.

Exactly

Yep, I don't know C++. Maybe I'll look into calling these member functions in the future though.

Just do what people often do when the library is officially in C and people want it in C++: write a wrapper.

Actually what I mean by the difference between the coding styles is exactly what you said - you can do OOP both C and C++ way, the difference is only your coding style. If you have to do it the C way you have to learn the C way and the same with C++.

EDIT:

The thing is that C++ coders are believed to know C but not the other way around.

ohhh baby!!

drools

I had an idea for a drawing mode that uses and ADDITIVE_BLENDER and SUBTRACTIVE_BLENDER, basically to add shadows or hilights on top of a sprite without the heed for an alpha channel.

also, I'd like more options for blenders. I have a full-screen one called desaturate (should probibly be called reduce_contrast()). it draws a transparent black and then transparent white block over the screen.

void desaturate_type_1(double ammount)
{
     gfx.Rect( 0, 0, RESOLUTION_X, RESOLUTION_Y, Rgba(0.0,0.0,0.0,ammount);
     gfx.Rect( 0, 0, RESOLUTION_X, RESOLUTION_Y, Rgba(1.0,1.0,1.0,ammount));
}

void desaturate_type_2(double ammount)
{
     Blenders::Set(( SUBTRACTIVE_BLENDER ));
     gfx.Rect( 0, 0, RESOLUTION_X, RESOLUTION_Y, Rgba(0.0,0.0,0.0,ammount));
     Blenders::Set(( ADDITIVE_BLENDER ));
     gfx.Rect( 0, 0, RESOLUTION_X, RESOLUTION_Y, Rgba(1.0,1.0,1.0,ammount));
     Blenders::Set(( ALPHA_BLENDER ));
}

the second one has 3 calles to change the blender (not very efficent). but if that gives you any ideas.

hmm....
NEGATIVE_BLENDER
HUE_BLENDER

But take the OO out of C++ and you have C. His point is a valid one. esp this->

Unless you want him to burn out, don't make crazed suggestions. I've tried to support a community tool myself (Freya), and I burnt out by implementing too many user suggestions.

Speaking of which, have you thought of building in Lua or Python wrappers?

I am fed up, for the stupid meh: give me a minimalistic pr*gram with ol that simply displays a bitmap. There is something I am doing wrong, but I can't see the forest because of trees meh thinks...

How does that actually reduce contrast? It effectively gets rid of dark shades at least But reducing contrast would mean multiplying the distance of the color from the middle gray by the amount, I think.

Also, wouldn't a function called desaturate get rid of the saturation (making the image grayscale?)

EDIT:
Micah, you need to register the png file type, see the manual for Bitmap.

register_bitmap_file_type( "png", load_png, 0 );

This won't be needed in the next version as I'll include an updated version of Loadpng (which has the missing source file...) You need to #include <loadpng.h> for that, though.

And always check allegro.log! I did that and saw that the bitmap loading failed so I guessed what was wrong right away

ah, I also have used a dotted line in my progam, perhaps it's something you might want to add.

transparency = 0.4;
float xCoordinates[numVertices] = { x1-7+offset_x, x2+5+offset_x, x2-2+offset_x, x1+5+offset_x };
float yCoordinates[numVertices] = { y1-4+offset_y, y1-2+offset_y, y2+4+offset_y, y2-2+offset_y };
glEnable(GL_LINE_STIPPLE);  // sets the line type to dotted
glLineStipple(1, 255);  // defines the dash-dot pattern
glLineWidth(10);  // well, sets the width, DUH! ;)
gfx.PolygonOutline( xCoordinates, yCoordinates, numVertices, color );
glDisable(GL_LINE_STIPPLE);  // set the line type back to normal

[edit:]

yes. I guess it would. that sounds like a cool idea. http://www.markmusicproduction.com/stuff/wistle.bmp

reduce_contrast basically adds grey to the picture, so yea, you're right about that one.

Micah, I think you should start a new thread.

Yeah, having a parameter to enable GL_LINE_STRIPPLE would be best, but I think some predefined line modes would be in order (as well as being able to specify the dotting with a bit mask). Also the *Outline-functions should all take a line width parameter, it's best to use that instead as it lets OpenLayer to know what you're trying to do there. Otherwise you can't be sure that it'll work like it should in the future versions (for example, RectOutline doesn't use glLineWidth to produce exact reasults).

I'd look at developing functions which can let people easily do cool console and PC game special effects. You might already be able to do that for all I know, but if not then I think that will prove very attractive.

What kind of effects do you mean? Currently you can do the following:

- Render bitmaps with varying opacity
- Tint bitmaps to colors
- Tint the whole screen to a color
- Change the strengths of the output color channels
- Move, rotate and stretch the screen
- Change the blending mode to do additive and subtractive blending
- Make some nice effects with gradient-filled primitives (as the opacity is a part of the colors)

If you can think of any effects you'd like to be implemented let me know!

maybe shaders?

That's possible, but what can you actually do with them in 2D games?

I was thinking water ripple effects, fire/heat effects would be really sweet. random link. if OpenLayer is Ortho? you could draw those effects in front of everything since most of those effects are based on depth.

Fire/heat effects? You mean like volumetric fire or something? I thought about implementing Patches - 2D grids which distort the bitmap when you move a grid point (how could I describe it best...) That could be used to create water effects and like.

volumetric fire was something I was initally thinking about, and then it made me think of how heat distorts light on the highway on a hot day, or on the back of a jet engine. Those would be good effects to have. I also like your idea of the 2d grid.

<besides>

This also crashes.

</besides>

I think water effects would be pretty cool...

Add this piece of code right after foo.Load(...):

if (!foo.IsValid()) {
   allegro_message("Prepare for a crash.");
}

EDIT: Also you should seriously consider either using forward slashes or double backslashes (backslash starts an escape sequence in C/C++).

EDIT2: Yeah, and what Mark Oates said

Micah: crashes or doesn't compile? I think you have to create a GfxRend object before you can use it.

GfxRend gfx;
gfx.FillScreen(Rgba::WHITE);

also, check that "C:\Dev-Cpp\Projects\test.png" is in the right spot. I advise changing it to "test.png" and moving the file to the same directory as the executable. and test that it's there like Miran said.

I don't know the specific effect names. But I was thinking of effects such as; nice particle/explosion effects, Shockwave effects around explosions with white lighting, Glow effects, 4 point lighting effects (for lighting square and isometric tiles).

Since 1.82 all GfxRend functions are static, so you don't need to create GfxRend object.

EDIT: Fladimir, any chance of making source distribution that will only include OpenLayer's source without libs and screenshots.

hmm, I'm thinking more along the lines of effects that would need a new design/interface. Particle/explosion effects are the kind of thing that you would do yourself. same with glow effects, that's an ADTITIVE_BLENDER thing

Oh sorry, I didn't mean predesigned effects. Just make it easy to do those effects and perhaps some explanation of how to do them?

Like Mark said, you can do all these with the alvailable functions. The distortion effect (like from the heat of the jet engines) would indeed be pretty nifty! Now to find out how to do that best with pixel shaders... Maybe there's even a tutorial or two somewhere.

Sure it is. EDIT: Here

If you'd need a particle engine you could copy those few lines from Demo.exe

I got it to work, but I can clearly see that the screen consists of two triangles. Seems as if there was a problem with the antialiasing...

Old.

A few pages old.

I am currently working on a test game with OpenLayer ( to learn to use it ), see a ship in progress: http://www.jray.de/shipmod1.jpg

I only hope I will be able to add nice fire effects

Great that you got it to work! Nice looking ship indeed, I bet you're going to down-scale it a bit, though

Also here's a neat trick: If you wish to be able to rotate the ship you can make the whole screen to rotate along the ship, like in Hellcarrier. Just do this before drawing the view:

Transforms::SetRotationPivot( shipScreenX, shipScreenY );
Transforms::SetRotation( -shipAngle );

Remember to call Transforms::ResetTransforms() before drawing the HUD and GUI, though

I actually thought about making a demo game like that with some neat effects I have in my mind (which can be done with OpenLayer already)... just use your imagination, Luke!

EDIT: Though the rotations would look a bit better if the anti-aliasing worked for you. Don't worry, I'll release a new version soon with multi-sample anti-aliasing.

Moving these masses of pixels feels strange to meh DOS freak, but somehow works...

I set the player sprite to 320x260 and the screen resolution to 1280x1024x32... the performance is unbelievable... it is a pity I have school tommorrow - I could hack down that game in one night

Thanks again Flad...

Remember to use the delta time system (check FpsCounter from the manual). It's specifically designed to stabilize games which push out hundreds of FPS.

blur. yes! blur!

also is it possible to darken an alpha sprite with TintMode?

Sure if you tint the Bitmap to black. The blending modes don't affect TintMode, though.

From what I've seen of the code, it looks like it should be possible to put a lot of the functionality in AllegroGL itself. Actually, I would go so far as to say that many things could be reused for Allegro 4.3+'s to-be native OpenGL driver.

With Fladimir's consent, of course.

Anyway, I didn't read all of the thread. Carry on if the topic has changed by now.

Evert, if you see anything which could be used in plain Allegro or AllegroGL, then go ahead and take it. Like the license says, use it whatever you want as long as the origination of the code is clear.

My specs are:

Gateway M305CRV,
http://support.gateway.com/s/Mobile/Gateway/M305CRV/3501715sp58.shtml

I have 512mb RAM, 2.4Ghz Intel Celeron processor.

Now you said the latest binaries solved your 'not setting graphics mode' problem? Which exact binary was it that fixed it?

I would like to use the latest binaries and have mine work as well...

I'm really surprised that a delta time system was never implemented in Allegro. This is a HUGE improvement over the typical simple Allegro game timer. It gets rid of the graphical hiccups.

I guess because it's really easy to implement. Just look into

OpenLayer/Source/FpsCounter.cpp

.
Putting this in FAQ might be a good idea.

Kudos for including all of the pre-compiled libraries!

When I compiled the CVS version of AllegroGL it couldn't set the graphics mode but the binaries included in the latest package solved it for me. You could try compiling the CVS version yourself and try if that works but... the older binaries of Allegro and AllegroGL should work, too. Of course they might have bugs that are fixed in the later versions.

Great that you like it! Have you noticed that in the latest versions FpsCounter::NewFrameStarted also returns the delta time to even reduce the amount of coding needed.

Fladimir: I've just had a quick look at the online manual. Why did you chose a Bitmap class with the same name as the existing Allegro data type? Does this not cause conflicts?

BITMAP and ol::Bitmap are two different names.

Well, yes they are different cases, but I still found it a little confusing having two usages of the word bitmap.

What other name would you suggest? Surface?

Gitmap!

In fact, the original name of the Bitmap is Texture. But that was before OpenLayer actually existed and when it was only the GraphicsFunctions.hpp -file in my Spaceforce game project. The name was changed to be similiar to Allegro's BITMAP and because the structure actually represented a bitmap (and a texture, too, but not "only" a texture because it included extra functionality).

Now when I think of it, the thing that OpenLayer lacks the most is some simple demos wich only show how to set up the program and create a simple game loop. Of course that could be done in a few lines, but still. Anyways, here's one which will be included in the package:

In my PC (AMD64 3200+ and Radeon 9800 Pro) it runs @ about 2400 fps with a fairly large bitmap, but that's not important, though

Maybe I'm just lazy, but I never really liked the "isValid" style of checking, so I just overloaded operator(bool) so I can have my if(!bmp) { ... }

Heh, actually I happened to think the same when I wrote that and the next version will have overloaded bool, too

What I would like is that

Bitmap::Load

and other methods that could fail throw exception.

Bitmap bmp( "Gfx/Bitmap.png" );
Fladimir, don't you think this should be bmp.load to make it clear what is happening?

Using the constructor to load the bitmap is perfectly clear if you read the documentation. There is also a Load() member function if you prefer that.

You don't need to look into documentation to figure out what will bitmap constructor do with file name.

Well it seems kind of inconsistent to me without a load part.

There's no reason not to be on the safe side. You never know what crazy stuff Fladimir is up to.

What should be changed is using enums instead of bools:

SetupProgram(true, true, true);  SetupProgram(KEYBOARD | MOUSE | TIMER);
Bitmap(bmp, true, true);         Bitmap(bmp, HAS_ALPHA_CHANNEL | CONVERT_MAGIC_PINK);

I tried using the older libraries to get the graphics mode to set with 1.82... but now it complains that there is an undefined reference to _install_allegro and something else similar... not that I really want to be coding with 1.82 and older libraries anyway...

I hope you can figure out what is wrong... I don't want 1.72 to be where my road of updates end

Are you linking with allegro?

Jeremy, you may have been right that your problems with 1.82 were specific to your hardware. Nobody else has reported the problem. Maybe Gateway will have driver updates for your laptop that might fix the problem. Have you checked the Intel site for extreme graphics driver updates? http://support.intel.com/support/graphics/index.htm

Thank you very much for that link!

I've been to Gateway's website many times, and they only had updates from 2004 which I have installed... but this intel link has drivers from just two months ago

Maybe these updated drivers will solve all my problems... thank you very much!

4mb... 40kbps connection.... ugh

You're welcome

Let us know if that does the trick! Hopefully that will get the OpenLayer1.82 package working using the new libs. The new libs have important bug fixes.

IT WORKS!

Everything is fixed with the latest video drivers -- transparency, calling SetOrthoGraphicProjection after text printing, setting the graphics mode... it all just works now exactly as it should.

Thank you all! And forgive me for bashing Fladimir when it was all my fault for not getting the latest drivers

YAY!
... that actually made me happy

so many tears, so many tears..

Glad to hear it! 'tis a great day for OpenLayer and the like.

Now back to work on my APSL and 'Dread' game!

-- I am going to start a thread in the off-topic forum about why I don't get to spend as much time as I want on this tho

Jeremy, great that you got it to work! So now the only problem is that the bilinear filtering doesn't work correctly with some people, but you could always turn anti-aliasing off.

Sure, I could add overloaded versions of the functions.

I have antialiasing switched off. It makes it run even faster anyway. Antialiasing is nice for some things but it's not always really necessary.

I guess that does look nicer since you can type in the exact parameters instead of (true, false, true). But it's not really that big of a problem, in my opinion.

I like the bit flags, makes it clearer what you're trying to do.

Code is untested, but I hope it gets into openlayer(tm)

Now we need arcs!...

Arc( float x, float y, float start_angle, float end_angle,
     Rgba col, float accuracy ); //ummmm... pie slice
ArcOutline( float x, float y, float start_angle, float end_angle,
            Rgba col, float lineWidth, float accuracy );
ArcGradient( float x, float y, float start_angle, float end_angle,
             Rgba innerCol, Rgba outerCol, float accuracy );

Just a general question, figured I'd ask it here: Does OpenLayer work under OS X? I know OL depends on some outside libraries, which is why I ask this question.

Fladimir: For polygon vertex lists, do you have any plans to add template functions to support
arrays of generic objects
with x and y members? (object.x, object.y)

In addition to arrays of objects being supported,
users could support a regular array of x,y values like so:

<code>
//please excuse any syntax errors

struct myvertex{
float x;
float y;
}

float array1[20]; //filled with x,y values
*myvertex array2;

array2 = array1;

Polygon(,,array2,10,,);

How about this:

Just a quick question for Mr. Gorf - Why haven't you placed openlayer on the SF CVS yet? It would allow us to help patch your code much more efficiently, not to mention it provides a nice way to "roll back" potentially buggy changes.

You could even move your openlayer page to the SF page hosting services...

I'd do that if I'd find an IDE with auto CVS system like in Eclipse for Java. About buggy changes - if they need any rollback there's probably a design issue, in which case the whole thing must be redesigned.

Yeah, I could. So much to do, so little time

Sounds pretty nice but a different operator might be in order. Otherwise some people might think that calculates vector sums.

Yeah, I had forgot about that...

Sure, that's exactly how it should be done. I'll just add a rotation parameter and I'm done

Well, isn't that an easy job

There's no reason why it shouldn't... but you'll need the fixed OS X headers/sources for AllegroGL.

Hmm... maybe the C/C++ extension for eclipse would have such functionality? I'll look into it.

Just thought I'd mention that you guys might want to try starting different threads (prefix with "[OpenLayer]" if you want) instead of having all OpenLayer-related posts in a single thread.

Huh! good idea.:) Will this be the first gamelib with rotatable ellipses?

Instead of OL forcing us to use it's data structures,
Template Polygon(); functions would allow us to store our vertices almost any way we like.

Mr. Gorf:
LineListGradient(); ? // good for movement trails
LineList(); ? // just to be complete

I'll do that if Mr. Gorf would prefer it that way

Anyway, it's been fun to have one big OpenLayer party thread instead of having a hundred little threads about OpenLayer. But whatever floats your boat...

Did you get my message that openlayer 1.82 has the demo compiled for allegro 4.0 but comes with the 4.2 dll?

speaking of the demo:

The code should be short and easy to follow.
Simpler demos could demonstrate OL's features.

The ball should be a bright color & possibly have a movement trail.

Yeah, I wouldn't take the time to make those either.

I feel a great disturbance in the force. I think Mr. Gorf might be preparing a new release... (in which the demo is probably fixed)

Yeah, I forgot that Eclipse is actually an all-in-one solution...

Well, I don't know for sure, but in software they'd be a lot harder to implement. Now all it takes is 3 simple code lines (glPushMatrix, OlRotateMatrix and glPopMatrix).

Those are a must, and I actually think about changing the *Outline-functions to use that kind of a mechanism instead. The problem here is that the lines must be connected regardless of the line width and that they must not overlap. So that means they'll have to be rendered with quads/triangles. Now this calls for some math stuff...

Well, that'll be changed in the future. Sorry, too many messages so that I may miss something ocassionally...

It was originally

That's what I'm aiming for. I've already started writing small tutorial-like demos.

Sure.

Am I not always

conalleg: Depending on it's internal structures, maybe OL (glyph) could read from conalleg.:D

TileMap rendering : having only 1 function keeps it simple

TileMap( x, y, map_x, map_y, map_width, map_height,
       *BITMAP )  //points to an array of *BITMAPS

Transforms could handle the rest such as centering map coordinates center-screen while rotating and scaling the thing.

clip area: good for split-screens & minimaps

SetClipArea( int x, int y, int width, int height);
relative screen coordinates:
All players see the same world area no matter what the resolution.8-)
Coders could easily change the hardware resolution & artwork by just adding 1 line after SetupScreen(); :

SetRelativeCoords(1200);
//only the relative x-resolution is specified
//In the case of a 4:3 window ratio, the relative y-resolution automatically becomes 900 in this case.

Setup::SetupScreen(); should automatically call
SetRelativeCoords(int width); to support exhisting code.

What's that?

Maybe, if that's not too high level...

That's planned, too.

That's possible, though it could be done with the current methods (by using SetStretch etc.).

conalleg- A simple scrolling console component for Allegro
http://www.inf.ufrgs.br/~fcecin/conalleg/
Scrollable text in a fixed size text buffer.
You can read & write to it.
...

So, If I wrote my game for 640x480, but changed the res:

float stretch_x = new_screen_w / 640;
float stretch_y = new_screen_h / 480;

SetStretch( stretch_x, stretch_y );

cool. no need to gum up the api
I don't see why it wouldn't work with any onscreen SetPosition();

Well, a console lib sounds a bit high level to me. Making a console isn't much of a job and it seems that if I wanted to use conalleg I'd have to rewrite most of it anyways.

That's right.

Putting this up on CVS, since you have a SF page for it, would help others assist you in development and adding features. They can submit patches, which you can review and test and then append them to the current cvs. SF also provides a means for bug reporting which can assist you in problem tracking, monitoring, and prioritizing.
Moving your page to openlayer.sf.net is allot easier to remember as well. ;P
For more info on using and setting up cvs on SF here is a link:
CVS
It would be great to see this progress to where we can just download the source and compile with current libs, thus getting rid of the need to re-distribute other libs.

There's lite and full OL versions ( source with and without libs ).

Precompiled libs are so easy though. If I had to compile 6 support libraries, I wouldn't touch openlayer.

Sin & Cos tables (8192 elements each) would speed up circle drawing, but the extra logic required might make the code less maintainable.
I wouldn't change the interface; just have the inner workings use tables.
1600x1200 resolution
1600+1200+1600+1200-4 = 5594 perimeter pixels < 8192 elements

calculating dA for ellipses: I'd calculate it from the longer side because a thin, 3 pixel wide ellipse would become very short (when it should be long)
Or... render 90 degrees of the ellipse at a time if calculating dA from the short side.

linelistGradient direction: Would the
direction of the gradient be across it's thickness (for curved lasers and whatnot), or
along it's length with a color info array (for movement trails, etc.) ?
Or 2 versions of the function?

redundant function removal:
Disk replaces CircleOutline?
LineList replaces PolygonOutline?

arc prototype-proposal revision:

Slice        ( x, y, radius, color, start_angle, end_angle, accuracy );
SliceGradient( x, y, radius, innerCol, outerCol, start_angle, end_angle, accuracy );
Arc          ( x, y, inner_rad, outer_rad, color, start_angle, end_angle, accuracy );
ArcGradient  ( x, y, inner_rad, outer_rad, innerCol, outerCol, start_angle, end_angle, accuracy );

Maybe just let ArcGradient(); Cover them all

Precompiled libs are easy, UNLESS you happen to want to compile the library using a newer patched version of a library...

On a serious note, it would probably be a bit more prudent to supply the precompiled version of the library seperately, and allow persons to download and compile the program and all of the libraries themselves if they so desire.

Great work

I've read the thread and it seems this didn't come out: could you add a directory with examples(much like allegro)?

Actually I said I'm writing a series of simple demos, which are quite like the examples in Allegro I've actually posted one of them in this thread.

I don't think I'm going to remove those. Actually a lot of rendering functions would benefit from LineLists and CircleOutline does in fact use Disk.

That's probably the best way.

This calls for some testing. I could also use something like the average as well. Also, there's a minium dA set already such that very small primitives wouldn't look ugly.

Yeah, I like that one better. Though I'll change the argument names to upperCaseNotation.

With today's hardware I'm not that sure. For some reason I've never been too fond of sin/cos lookup tables.

Sounds good, I already signed up to the system. Now I'll just have to find out the best way to add the files there.

Err... i did say it SEEMS
Great work

Now that I think about it, curved lasers are a very specific case.
Coders could support them themselves with gradient polygons or multiple linelists:
first linelist blue thickness 5
then linelist lightblue thickness 3
finally linelist white thickness 1

So... the more important LineListGradient version would receive an array of color data. Another candidate for templates?

I know I'm getting fussy about minimizing the number of functions available. I just don't want to see openlayer get bloated and confusing. Just clean and simple like it is now.

gfx.CircleOutline( 400.0, 300.0, 280.0, Rgba::BLUE, 35.0);

It doesn't make sense to add lookup tables IMHO. If you really care about speed you put the circle in a display list and resize it using matrix scaling operations.

You could even create an array of display lists for different levels of detail.

ArcGradient WORKS!!!!!!!!!!!!!

Heh, thanks for the code! Like I said it's no job to modify the existing functions to get the Arc functions

You'd get better performance using GL_TRIANGLE_STRIP.

I've heard that before but that sounds pretty strange - if using a triangle srip is faster then why doesn't OpenGL replace the quads with triangle strips?

Actually, I meant rendering entire arc as single triangle strip (or quad strip). This way you have to specify only half of vertexes. I've heard about triangle strips being faster than quads, but I haven't checked this personally.

Yeah of course. Why didn't I think of that...

Actually, I think that a triangle strip is faster than the corresponding quad. IIRC, the drivers apparently convert them automatically, but that's not happening on older cards I'd assume. Not that I have measured this personally either I've just always used triangle strips, just in case

How so?

He is drawing quad strip using GL_QUADS, so he is passing middle vertexes two times each.

+--+ +--+ +--+
|  | |  | |  |
+--+ +--+ +--+

vs.

+--+--+--+
|  |  |  |
+--+--+--+

If it's CPU or AGP-limited, it's going to be faster, isn't it?

I'm almost finished with the next release. Now all it needs is some throughout testing (once again )

Sure, but then just use quad strips. No need to rework the code to work with triangle strips.

Wouldn't triangle strip use exactly the same vertex order as quad strip?

I'm 99% sure that it'd be slower. Unless it's cached, a memory lookup would be bad in most occurances. Just for example, my DDR runs at 133/266mhz compared to 1600mhz on my CPU.

I guess it doensn't matter if you don't use line mode rendering, stipple or edge flags.

Question: SUBTRACTIVE_BLENDER does which one? ...
final_color = dest_color - src_color;
final_color = src_color * dest_color; (values 0.0 to 1.0)

Request: OL hardware rendering to other (video ?) bitmaps.
If I had access to this power, I could do some really cool stuff. It'll be like gradient-capable stencil buffers.

The first one, after all the name is subtractive blender, not multiply blender

Yeah, rendering to a texture is possible so I could implement rendering to an another Bitmap. Check this or this, for example.

But which way does it go? dest - source != source - dest

Uggh. You really should just use EXT_framebuffer_object (supported all the way back from the TNT2 to the latest and greatest GeForce). It's simpler, faster and has less issues.

doh! so, is MULTIPLY_BLENDER a possible addition? I was thinking per-color channel instead of using the alpha component.

Request: blitting a rect portion of a bitmap to the screen.
(overload the blit function?)

OL angles are clockwise-positive. Would you rather have them be the traditional CCW positive?

Does FillScreen set the alpha value as well? (that would be nice)

What I like about OL: Everything, except half of the GfxRend function prototypes. But that's ok! 'Cause I can make my own and they play (husky black man voice) real nice with OL.

Thanks for the tip. Though I think I'll release OpenLayer 1.9 before including the rendering to bitmaps.

Both screen clipping region and Bitmap rendering region are included in 1.9. Instead of overloading any functions it'll use the new RenderMode combinator. For example:

Blit( x, y, ClippedMode( x, y, w, h ) + TintMode( color ) + FlippedMode( VERTICAL ));

Well, which ones you don't like and why?

OpenLayer's motto is that you aren't limited to its functionality

Well, There's nothing wrong with them, it's just personal preference.
For instance: I like to input metric degrees. I like my angles to be traditionally counter-clockwise positive. I like even fewer versions of functions(2 or 3 max), so it'll be easier to remember the parameter list. Example: 1 or 2 no-frills + 1 ultra-deluxe

CircleGradient, Disk, DiskGradient
I would combine these into 1 function CircleGradient. It would act like DiskGradient.

Given all these changes, maybe it's best if I make my own.
Other than that, OL is shaping up superbly for me.

If you don't wish to use some of the functions then don't use them The thing here is that not everyone who sees DiskGradient obviously thinks that you can render solid circles with it.

By the way, the next version is complete. I just need to write all those numerious new manual entries, you can check the manual and see them appearing

And credits go to all those who have helped with the development!

Is anything supporting it at the moment? Most people don't have access to NVidia developer drivers and I even don't know if ATI is planning to support it.

wow! that's an incredibley intuitive way to do it.

A new driver release should happen any day now...