Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » AllegroGL allegro-mode features

Credits go to Arthur Kalliokoski, Evert, James Stanley, and Milan Mimica for helping out!
This thread is locked; no one can reply to it. rss feed Print
AllegroGL allegro-mode features
tobing
Member #5,213
November 2004
avatar

The following applies to allegro 4.3.10 and allegroGL, both recent SVN head revisions.

Today, diving into more and more details of OpenGL and AllegroGL, I found that for example a call to draw_lit_sprite is not supported, which I found somewhat surprising. I'm using allegromode in that example, and got a NULL-pointer crash. Similarly, calling draw_sprite_ex with parameter DRAW_SPRITE_LIT leads me to a switch statement with a comment, saying that this is not supported...

Well, I also had a crash somewhere deep in strech_blit, which I can't figure out, because even in a debug build, I can't get any call stack.

So, the question is: Are there plans to implement these missing features?

My alternatives would only be to implement these myself, maybe I could give that a try. But more probably I will implement all my drawing using pure OpenGL... well, I hoped to be able to keep both versions of drawing as close together as possible, allegro-mode being ideal for this purpose.

James Stanley
Member #7,275
May 2006
avatar

I am not an expert on the current state of Allegro/AllegroGL, but AFAIK AllegroGL is becoming deprecated because Allegro 5 will have OpenGL support out of the box.

tobing
Member #5,213
November 2004
avatar

Quote:

but AFAIK AllegroGL is becoming deprecated because Allegro 5 will have OpenGL support out of the box

That's why I'm asking... but it will be some time until 5 is stable enough to be used.

Evert
Member #794
November 2000
avatar

Quote:

Are there plans to implement these missing features?

Probably. A lot of vtable entries were added to make them possible, the problem is that someone has to write the code to fill those entries.
So if you could write the code to do that and submit a patch...? ;)

Milan Mimica
Member #3,877
September 2003
avatar

Quote:

I found that for example a call to draw_lit_sprite is not supported

True. A function written in OpenGL that has the effect of allegro's draw_lit_sprite() will be accepted. Partial implementation is fine too. This is beyond my OpenGL knowlenge, and to be honest I never figured what does allegro's draw_lit_sprite() exactly do. Oh, and don't bother with palleted modes. Same goes for draw_gouraud_sprite().

Quote:

Well, I also had a crash somewhere deep in strech_blit, which I can't figure out, because even in a debug build, I can't get any call stack.

Stretching is implemented so it must be a bug. Does it happen always or just under some circumstances?

tobing
Member #5,213
November 2004
avatar

I'm currently beginning to learn OpenGL, so when I have something to submit I will do so.

Stretching: I had tried a few times, trying to stretch from 1800x1800 down to 256x256. The idea was to draw some image, then use that as a texture later on. It all works as long as I don't use stretch_blit...

Arthur Kalliokoski
Second in Command
February 2005
avatar

They all watch too much MSNBC... they get ideas.

Milan Mimica
Member #3,877
September 2003
avatar

Arthur said:

This has me worried...

What about it?

tobing: more specifically, do the examples that use stretching work? Is any of the used bitmaps a memory bitmap? What kind of bitmaps are involved? Can a minimal non-working example be reproduced?

tobing
Member #5,213
November 2004
avatar

I'll go into a smaller example tomorrow, perhaps. I had extextur for reference, and I looked into dumbtest. What I tried to do is stretch_blit from a memory bitmap to screen (allegro mode!) and then from one memory bitmap to another, both didn't work well...

Milan Mimica
Member #3,877
September 2003
avatar

Yep, it doesn't work with memory bitmaps. It would have to create a video bitmap internally.

tobing
Member #5,213
November 2004
avatar

Would it work when the target is a video bitmap? According to allegro documentation, the source must be a memory bitmap...

Milan Mimica
Member #3,877
September 2003
avatar

Quote:

Would it work when the target is a video bitmap?

No.

Quote:

According to allegro documentation, the source must be a memory bitmap...

AllegroGL's Allegro mode introduces quite a few API differences. Hopefully all mentioned at the wiki.
Well, ok, "The restriction that allows only memory bitmaps for arguments to functions like drawing_mode(), polygon3d(), stretch_sprite()... is released. Video bitmaps are allowed too." is not the most precise. Memory bitmaps are not allowed in this case.

tobing
Member #5,213
November 2004
avatar

Thanks for pointing me to the wiki, never guessed that part of the documentation would only be there and not be included in the docs of allegrogl itself. Might be a good idea to point this out somewhere...

Well, so I guess this all means that using allegrogl implies that many things are done in a different way than they would be done using plain allegro. This makes me curious of how it will be done with allegro 5! In the meantime, I'll continue to learn using plain OpenGL.

Thanks for all the help!

Elias
Member #358
May 2000

A5 has no draw_lit_sprite, but has some blending capabilities: http://alleg.sourceforge.net/naturaldocs/files/tls-c.html#al_set_blender

Using OpenGL is a good idea in any case, and works seamless with A5.

But otherwise, yes, if you stick to the A5 API, it will be completely supported by all drivers, as development was different than with A4 - working OpenGL and DirectX implementations were a pre-requisite to have something in the API. With AllegroGL, some things simply are hard to retro-fit to the software implementation.. draw_lit_sprite probably would require using a fragment shader.

--
"Either help out or stop whining" - Evert

GullRaDriel
Member #3,861
September 2003
avatar

And what prevent you from using OpenGL along AllegroGL ?

I have them both mixed without problem, using pure OpenGL calls when I need an unsupported feature. This have allow taking the advantage of what's already done in Allegro and AllegroGL.

Well, you were perhaps already aware of that information, but I was asking myself why you still stick at pure OpenGL.

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

This makes me curious of how it will be done with allegro 5!

Things are a lot easier to define when you plan ahead for them ;) Allegro 5 assumes hardware acceleration for most/all of its main graphics features. There currently isn't a software engine/driver at the moment, so realistically everything in A5 is defined in a sane enough way that it works "the same" on as many hardware archetectures as we've gotten our hands onto. And a software implementation will have to go out of its way to implement things so they work the same way as well.

Right now, A5 does its best to speed up operations at the cost of a little extra system/gfx memory use. It can, and typically will allocate your ALLEGRO_BITMAP as a texture, and a memory bitmap. And operations are defined in such a way that typical blit/blend/whatever operations are made to use the texture, rather than the bitmap, but cpu write operations operate on the memory bitmap, and are synced to the texture (IIRC, though this may not be the actual case. I think its possible to modify textures directly given an available GL extension, and in a decently performant way if all you're doing is a block write) the memory bitmap is also used to recreate the texture in case its lost (DX/windows context switching anyone?). (edit3: you can ofcorse select what kind of BITMAP you want, just like in a4, just with the added bennifit of a dual life bitmap as explained above)

At least this is what I've gathered from the recent developments :) Others like elias, trentg, mimix, and maybe KCat can probably correct me where I'm wrong. :)

edit:

Quote:

And what prevent you from using OpenGL along AllegroGL ?

Absolutely nothing. Infact thats AllegroGL's main use. It turns Allegro into a SUPER GLUT.

edit2: though I think you were replying to tobing... so nm ;)

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

GullRaDriel
Member #3,861
September 2003
avatar

Quote:

though I think you were replying to tobing... so nm ;)

You were thinking right but that's one more cent in my bag anyway ;-)

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

tobing
Member #5,213
November 2004
avatar

Quote:

And what prevent you from using OpenGL along AllegroGL ?
...
Well, you were perhaps already aware of that information, but I was asking myself why you still stick at pure OpenGL.

Well, of course nothing, besides maybe my very lacking knowledge of OpenGL.

To be honest, my first thinking was to just use the code I have written for plain allegro with allegro mode in allegrogl. That will not work, as I now know, so I think I will use OpenGL where it is appropriate, and allegrogl whereever it helps me to keep my code simple.

I have my code wrapped in such a way that I can (more or less) easily switch between different graphics back ends during startup, a cancept introduced using guichan basically. That way it's not too hard to add the allegrogl code, but the downside is, that I have to write certain routines twice. And the one thing I really hesitate to write twice is the map display, which not only is somewhat complicated, but also changes from time to time.

Maybe I'll consider the allegrogl use as sort of exercise for now, and switch to allegro 5 next year... not sure yet, if that's such a good idea...

Go to: