Allegro.cc - Online Community

Allegro.cc Forums » Off-Topic Ordeals » Some really obnoxious A5 questions

Credits go to Edgar Reynaldo, Elias, Evert, ImLeftFooted, Johan Halmén, Kitty Cat, Matt Smith, Milan Mimica, SiegeLord, Thomas Fjellstrom, and Thomas Harte for helping out!
This thread is locked; no one can reply to it. rss feed Print
 1   2   3 
Some really obnoxious A5 questions
weapon_S
Member #7,859
October 2006
avatar

OK, I know Allegro 5 is all the rage now, but I still want to make another thread about it.
allegro5/allegro5.h
Will it stay like this i.e. allegro5.h?
What's up with the "drawing primitives"? No do_circle() ?
Will Allegro now only work through system dependant API's and OpenGL (internally)?
Do I have to learn OpenGL syntax? (Now known as Allegro syntax ??? :P )
If I have to download extended functionality separately (like file formats), how useful is it integrating into the core Allegro API? Or am I mistaken and are all add-ons only invoked by including their separate headers/libraries? (How modular)
Will I be able to install functionality later on? Or will that be just reinstalling Allegro?
What's going to happen to the giftware "license"? (Especially with the add-ons)?
I hope I'm not being too obnoxious...for people to answer. Please? :-*
I'm considering to stick with 4... forever.

Johan Halmén
Member #1,550
September 2001

Quote:

I'm considering to stick with 4... forever.

I might do that, too. I don't have the whole picture about Allegro 5 and what Allegro will be in the future. Will it dissolve into a bunch of add on libraries and add on data structures? A4 is still something I can see as a coherent library, despite some add ons I use. bmp and tif is there, wav and mid is there, gui is there.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Years of thorough research have revealed that the red "x" that closes a window, really isn't red, but white on red background.

Years of thorough research have revealed that what people find beautiful about the Mandelbrot set is not the set itself, but all the rest.

Thomas Harte
Member #33
April 2000
avatar

I offer the following answers as someone who has been following Allegro 5, I believe them to be correct but I'm hardly authoritative... and I have no idea about your final two questions (sorry!)...

Quote:

What's up with the "drawing primitives"? No do_circle() ?

I believe SiegeLord is working on geometric primitives, the plan being that they'll be there, they just aren't yet.

Quote:

Will Allegro now only work through system dependant API's and OpenGL (internally)?

I think I must misunderstand the question; with the exception of the DOS port which is not currently maintained, Allegro has always only worked through system dependent APIs. But I think it will farm all its graphics chores out to OpenGL or DirectX as appropriate wherever it can, though I understand that software versions of all routines are being prepared, so I guess it'll support pure framebuffer targets too.

Quote:

Do I have to learn OpenGL syntax? (Now known as Allegro syntax)

I believe you won't, as Allegro will function where OpenGL doesn't exist. Some of the layout of the Allegro API may quite obviously be designed around the way it wants to use video hardware internally, but you'll still be using "the Allegro API" (albeit not the Allegro 2.0 — 4.x API).

Milan Mimica
Member #3,877
September 2003
avatar

Quote:

Do I have to learn OpenGL syntax? (Now known as Allegro syntax

No. I assume that by "syntax" you mean API. No. Allegro has it's own graphics API. It just uses OpenGL internally sometimes. You don't have to care about that. Again, no.

Quote:

If I have to download extended functionality separately (like file formats),

... you don't. It's all in the same package.

Evert
Member #794
November 2000
avatar

Quote:

OK, I know Allegro 5 is all the rage now, but I still want to make another thread about it.

At the risk of sounding like a broken record, Allegro 5 is not done yet. You cannot and should not judge it on the basis of an incomplete WIP release. Do not call 4.9.5 Allegro 5. It is not Allegro 5 (yet).

Quote:

Will it stay like this i.e. allegro5.h?

Something like that anyway, to avoid conflicts with Allegro 4's allegro.h.
I agree that the 5 tacked onto it looks a bit goofy, especially if we ever want to have a 6 that's compatible with 5. Feel free to suggest an alternative.

Quote:

What's up with the "drawing primitives"? No do_circle() ?

yet. For do_circle(), the A4 function could actually be pretty much copied verbatim. Feel free to help out here.

Quote:

Will Allegro now only work through system dependant API's and OpenGL (internally)?

Allegro will use platform dependent APIs internally, yes. I must admit I don't see the point you're trying to make though, it's like that in A4 as well. How else do you expect to get DirectX on Windows and X11 in Linux?

Quote:

Do I have to learn OpenGL syntax?

If you intend to do 3D stuff that's probably a good idea. Other than that, no.

Quote:

If I have to download extended functionality separately (like file formats),

Who says you have to do that?
Loaders are all addons, meaning they are independent modules. Modularity is good. But you get the modules providing basic functionality along with the core library.
In A4 you have to jump through hoops (or at least install addons yourself) to get PNG and Ogg support. In A5 you get those out of the box. So in fact you have to download fewer addons.

Quote:

Or am I mistaken and are all add-ons only invoked by including their separate headers/libraries? (How modular)

Yes.

Quote:

Will I be able to install functionality later on?

I'm not sure what you mean. Do you mean "can I leave out the image loader and install it later"? Yes, you can, but I don't see why you would.

Quote:

Or will that be just reinstalling Allegro?

At the moment, you run cmake and make again to build the skipped addon, which will only compile said addon and not the rest of Allegro.
When A5 is out and we have binary packages up for download - who knows? Maybe you can pick and choose which components you want. I still don't see why you'd leave out one of the default addons.

Quote:

What's going to happen to the giftware "license"? (Especially with the add-ons)?

I don't think anything happens to the giftware license. As far as I know A5 and its bundled addons are all giftware. People providing their own addons can pick whatever license they want, just as they can with A4.

SiegeLord
Member #7,827
October 2006
avatar

Quote:

What's up with the "drawing primitives"? No do_circle() ?

Err, pretty much everything I was planning on making myself is outlined here: Linky. There is still no do_circle because that is beyond my meager mathematical skills to implement properly (although, there is this which, unfortunately, does not work too well). So yeah, help appreciated ;D.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

weapon_S
Member #7,859
October 2006
avatar

[obligatory but sincere sucking up] You guys rock! :) You (almost) answered all my questions. ;D

Evert said:

Allegro 5 is not done yet.

Ah,... yes,... my apologies.

Thomas Harte said:

I understand that software versions of all routines are being prepared

That's what I meant to ask with my silly "platform dependant API's internally".

Milan Mimica said:

No. I assume that by "syntax" you mean API.

Big duhhh on my part:-[
So some 3D things will be directly via OpenGL. Hm...
As I realize now, I'm very much confused about the add-on thingy. So this is what I guess now:
Allegro 5 will have (slightly?) more "out of the box" functionality, but also incorporates a structure that allows for easy extensions. So will allegro have all the libraries listed here "OTB"(Out of The Box???) ? And 4D graphics? :P (I really think it should have 4D graphics for the aforementioned reasons). More seriously, speech synthesis? I heard somebody about it... I think.

Evert said:

Feel free to suggest an alternative.
...
For do_circle(), the A4 function could actually be pretty much copied verbatim. Feel free to help out here.

allegroN.h ? And allegroO.h for the old one?
(That's pretty much how I manage all my code :-/) But don't listen to me if you want anything maintainable. Sooooo, about the drawing primitives. I only see those vertex things now in the primitives. So will al_circle() be invoked through that ??? Vertex circle ? AL_VERTEX2D al_do_circle()??? Or is it another function? Should it incorporate sub-pixel accuracy as well? I'd like to help out, but currently I'm doing my "developing" on a old PC with w95. (Works pretty well actually: conTEXT, Mingw, DJGPP, project dogwaffle. Yes, I'm upgrading "soon" ;D)
But more importantly installing a WIP version is a pain in the lower back.
Yes, I'm confused about the drawing primitives too :P
[edit]SiegeLord posted...before me
[edit]So I actually can help out...Sweet. Just know: I'm not reliable.
I thought a vertex was something 3D:-X It's a pixel.
May I suggest (and make;D perhaps:-[):

void al_do_circle(BITMAP *bmp, float x, float y, float radius, int d, void (*proc)(BITMAP *, float, float, int));
void al_do_circle(BITMAP *bmp, int x, int y, int radius, int d, void (*proc)(BITMAP *, int, int, int));
void al_do_fast_circle(BITMAP *bmp, float x, float y, float radius, int d, void (*proc)(BITMAP *, float, float, int))
void al_do_fast_circle(BITMAP *bmp, int x, int y, int radius, int d, void (*proc)(BITMAP *, int, int, int))

(Yes, nitpicking.)
And of course circle drawing version too.(See Siegelords links : )
I don't get al_draw_primitive_2d. And where did SiegeLord make this page come from? I didn't see any links.
[edit]Damnit! Where's Weapon S 2.0 with mutex support?
[edit] realized I made some mistakes in my "suggestions"

SiegeLord
Member #7,827
October 2006
avatar

Quote:

al_circle() be invoked through that ??? Vertex circle ? AL_VERTEX2D al_do_circle()??? Or is it another function? Should it incorporate sub-pixel accuracy as well?

At this particular time, everything is a polygon or a polyline, so al_draw_circle would be a many sided polygon. In theory, it is possible to create something that would be subpixel accurate, and I did link to one of my abortive attempts at that, (although I challenge you to find the difference between a very many sided polygon and a true circle), but I do not have the concentration/skill/time to do them at this time. Trust me, having polygonal approximation is better than having nothing at all.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Thomas Harte
Member #33
April 2000
avatar

It would be relatively trivial to do a pixel-perfect on-GPU circle drawer using a pixel shader. So: is there currently any shadery stuff in Allegro 4.9 at all (for uploading them, managing them, ensuring they survive context changes or video memory flushes if necessary, depending on OS, etc, etc) and, furthermore, would a path that relied not just on a particular API but also a particular class of hardware being available integrate nicely or be acceptable?

SiegeLord
Member #7,827
October 2006
avatar

Quote:

It would be relatively trivial to do a pixel-perfect on-GPU circle drawer using a pixel shader. So: is there currently any shadery stuff in Allegro 4.9 at all (for uploading them, managing them, ensuring they survive context changes or video memory flushes if necessary, depending on OS, etc, etc) and, furthermore, would a path that relied not just on a particular API but also a particular class of hardware being available integrate nicely or be acceptable?

Here are my own thoughts, as I have not seen Allegro devs proper discuss this before. Any and all operations that Allegro does seem to have a software backup, which makes writing in new graphical features a little difficult at times. I agree that with shaders, pretty much anything can be done. My own thoughts on this matter basically ended up at this conclusion: there will be a second primitive addon that will be shader based. It will allow for pixel perfect primitives, as well as anti-aliasing. Somehow, it will have shaders for DX, OpenGL and software. For hardware without shaders, the software shaders will be used that will operate on memory bitmaps that will be transfered back and forth between RAM and VRAM (might not be an issue with AMD Fusion and such).

weapon_S: What's the difference between fast/non-fast versions of those functions?

Quote:

And where did SiegeLord make this page come from? I didn't see any links.

From my mind. Nobody does these things anymore, and perhaps never did, so I just made it from scratch.

Quote:

I don't get al_draw_primitive_2d. al_draw_primitive_2d

It'll probably make more sense once I actually make it, and then make a usage example.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Evert
Member #794
November 2000
avatar

Quote:

There is still no do_circle because that is beyond my meager mathematical skills to implement properly

For do_circle or do_circle-like functionality, you can just copy A4's function. It's not tied to the A4 API in any way except maybe the argument list of the callback function. However, whether A4's method for drawing a circle outline is the best way to do it in A5 is perhaps another question.

Quote:

So this is what I guess now:
Allegro 5 will have (slightly?) more "out of the box" functionality, but also incorporates a structure that allows for easy extensions.

That's right.

Quote:

So will allegro have all the libraries listed here "OTB"(Out of The Box???) ?

It will have those you can take seriously. Of course it does not have speech synthesis, PHP, 4D graphics or /dev/null compression. It also doesn't have console ports at the moment (it's quite enough work getting it running on Windows, Linux and OS X at the moment).
I know I ran down that list in another post a couple of weeks ago, so use the forum search to look it up.

Quote:

So will al_circle() be invoked through that ??? Vertex circle ?

I hope not. Polygons really suck when you compare them to proper circles.
Doing the outline (using a do_circle() like function) is easy. The problem is doing a filled circle. The best way to do that, as far as I know, is along the lines of filling in the bounded square and then fill in the remaining arcs with increasingly small triangles, until your triangles become as thin as a single line of pixels. I don't know how fast or slow that will be, but I can imagine it taking up an inordinate amount of time filling in the region close to the boundary. Alternatively, a higher-order polygon can be used and the remaining sections filled in in the same way. I would need to do some more reading on the subject (using triangle fans is not the proper way to go, apparently, before someone brings that up).

Quote:

although I challenge you to find the difference between a very many sided polygon and a true circle

The difference is quite obvious in some of the examples I've seen, actually.

Quote:

Trust me, having polygonal approximation is better than having nothing at all.

That is a disputable point and whether you agree with it or not depends on what you're trying to do. In general terms, I think having something that does it only half right is worse than not having it at all, because it's of no use to me anyway if I want it done right.
So if you care about having a good approximation to a circle, then no, it's not better. If you want something that maybe looks vaguely like a circle (if you squint), then yes, it's better.

SiegeLord
Member #7,827
October 2006
avatar

Well, squinting means having something to compare to :P It's basically a pixel here or there once you have a sufficient number of line segments. That sufficient number is not that large either, up to 1000 segments will take care of most circle sizes, especially if I implement clipping of circles.

You can't just use the allegro's do_circle because it takes integer arguments. A5 seems to have a preference towards floating point arguments for its functions, so having one of its primitive drawers ignoring the floating part would be bad.

Quote:

using triangle fans is not the proper way to go, apparently, before someone brings that up

People say that, but never provide a better method :P

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

ImLeftFooted
Member #3,935
October 2003
avatar

Evert said:

Of course it does not have speech synthesis, PHP, 4D graphics or /dev/null compression. It also doesn't have console ports at the moment (it's quite enough work getting it running on Windows, Linux and OS X at the moment).

Damn, I was really pushing for PHP.

A more serious problem: Now that A5 is actually coming out, what version will be the magical one with Mind Control and PHP?

Evert
Member #794
November 2000
avatar

Quote:

You can't just use the allegro's do_circle because it takes integer arguments. A5 seems to have a preference towards floating point arguments for its functions, so having one of its primitive drawers ignoring the floating part would be bad.

I think you can generalise it to work with floats, but I must admit I haven't tried.

Quote:

That sufficient number is not that large either, up to 1000 segments will take care of most circle sizes

Yes, and if you come across one of those where it doesn't?
Well, you probably weren't going to draw a circle with a 3-pixel radius using 1000 line segments anyway.

Quote:

People say that, but never provide a better method :P

I just did.
I can't take the credit for thinking of it though (Bob posted it in a previous discussion on the topic, and he also explains why triangle fans are not the way to go).

SiegeLord
Member #7,827
October 2006
avatar

Quote:

I think you can generalise it to work with floats, but I must admit I haven't tried.

I'm sure you can. The thing I posted is the result of months of my trying to generalize it before I gave up.

Quote:

I just did.
I can't take the credit for thinking of it though (Bob posted it in a previous discussion on the topic, and he also explains why triangle fans are not the way to go).

Meh, until I see some benchmarks, I am not going to believe that. All of these methods have the same number of polygons anyway, so I hardly think there'll be any difference. In fact, drawing scanlines via GL_LINES manually was faster than polygons at a certain point anyway.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Milan Mimica
Member #3,877
September 2003
avatar

Quote:

So: is there currently any shadery stuff in Allegro 4.9 at all (for uploading them, managing them, ensuring they survive context changes or video memory flushes if necessary, depending on OS, etc, etc)

No, there isn't any of this. I thought that shaders are part of the OpenGL state, and state is built to stay.

Quote:

and, furthermore, would a path that relied not just on a particular API but also a particular class of hardware being available integrate nicely or be acceptable?

I don't know. Separate shaders rendering paths for particular hardware class, even particular vendor, scares me. I imagine we could have two or three different shader programs that do the same thing. Sounds much worse than ASM code in A4. But then, the one is always afraid of things he doesn't know.

Looking at the future, I think it would be a better idea to start thinking of a next-generation OpenGL backhand for A5, which would not even try to work on old hardware.

Matt Smith
Member #783
November 2000

Quote:

what version will be the magical one with Mind Control

If we wait too long, it won't be a joke anymore._45110385_monkey_nerves_226.gif

Quote:

I don't know. Separate shaders rendering paths for particular hardware class, even particular vendor, scares me. I imagine we could have two or three different shader programs that do the same thing. Sounds much worse than ASM code in A4. But then, the one is always afraid of things he doesn't know.

The ASM code was, in its time, a great part of the performance of Allegro 3.x. Getting rid of it was just clearing the decks for this decade's neat trick, which is shaders. It's a complication we should accept, IMHO, because the benefits are potentially so large. I'm not offering to write any of this shader code, but I have the CUDA SDK & Driver installed ready to test :)

Thomas Harte
Member #33
April 2000
avatar

Quote:

No, there isn't any of this. I thought that shaders are part of the OpenGL state, and state is built to stay.

Right, but my understanding was that using OpenGL with the Windows API is a painful process that often necessitates destroying your current rendering context and creating a new one if you want to do much more than have a fixed-size window that stays on one monitor. In DirectDraw (at least when I used it), you couldn't even assume that anything you had in video memory would stay in place from one blit to the next. I guess that's all part of trying to tack something persistant onto a (pre-Vista) inherently nonpersistant windowing model.

Quote:

I don't know. Separate shaders rendering paths for particular hardware class, even particular vendor, scares me.

If we start with GLSL then we get every OpenGL vendor with a reasonably recent card (last three or four years) and can do everything that I understand the Allegro API to be likely to require. I guess DirectX people can do whatever they need to for that driver.

As Matt implies, we're probably now at the stage in computer development where OS-level graphics-specific APIs are on the way out, to be replaced with much more general languages that, by the way, can also use their many-threaded output to plot colours to a pixel based display. But I don't think Allegro needs to care.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Quote:

As Matt implies, we're probably now at the stage in computer development where OS-level graphics-specific APIs are on the way out, to be replaced with much more general languages that, by the way, can also use their many-threaded output to plot colours to a pixel based display. But I don't think Allegro needs to care.

Isn't that precisely the reason A5 should care about these things? Is compatibility with equipment that is becoming obsolete a part of the A5 mission statement? Don't we want A5 to stick around well into the future without being bogged down on future development because it's forced to be compatible with older than recent hardware and OS'es?

Thomas Harte
Member #33
April 2000
avatar

Quote:

Isn't that precisely the reason A5 should care about these things? Is compatibility with equipment that is becoming obsolete a part of the A5 mission statement? Don't we want A5 to stick around well into the future without being bogged down on future development because it's forced to be compatible with older than recent hardware and OS'es?

I'm sorry, I think I was unclear. I meant to say that after a decade and a bit of the 3d APIs competing to do everything they possibly can, I think that they are probably now at their last hurrah and that general purpose languages which, by the way, can also target GPUs will be the future. The CPU manufacturers need to push the world to greater parallelism anyway, so it all ends up tying together neatly.

The reason I raised this was to support my never really stated argument that supporting the OpenGL & DirectX shading languages of the last few years is probably the sum total of the shading language support that Allegro will ever need. I don't think the graphics-specific APIs are necessarily going much further (though how the branding will transfer, I don't know) and I think the cross-vendor shading languages have been sufficient for anything Allegro will want to do for many years.

If, one day, OpenGL and DirectX are about as well supported as QuickDraw is now under OS X or GDI under Vista then of course Allegro should move on, but it'll be a case of writing a new system target.

Incorporating shading language stuff into Allegro should be a target-specific task that won't escalate up and infect the whole library with complexity as the x86 assembler did in the past. It also shouldn't add too much complexity to each specific target (at least, it wouldn't for OpenGL; I left the DirectX fold long before pixel shaders came along but I'd be surprised if it was much more complicated there).

EDIT: sorry, I know I got a bit into "futurology seems a bit useless now but in 50 years it'll be the single most important profession", key points were:

  • support for shaders would be something that lives down in the bowels of the target specific code;

  • there's not much reason to support more than one set of shaders per target at the minute; and

  • I can't see that they'll need that much work to be kept up to date until such time as entire new targets need adding.

I should also add that they're all written in quite high-level languages now, so would be much easier to maintain than ye olde x86 assembly on that front too.

Milan Mimica
Member #3,877
September 2003
avatar

Quote:

Right, but my understanding was that using OpenGL with the Windows API is a painful process that often necessitates destroying your current rendering context and creating a new one if you want to do much more than have a fixed-size window that stays on one monitor.

That's only when you switch from fullscreen to windowed and vice-versa. I think allegro should not even allow that, but it does ATM and it is broken on all platforms I've tried. We better drop that.

Even now, without changing anything, al_create_display() can select the appropriate OpenGL backhand. It's just that there is only one.

Quote:

there's not much reason to support more than one set of shaders per target at the minute

Good. There must be someone who will say NO when someone else comes saying "hey this circle drawing shader could be implemented 5% more efficient using NV specifics!".

Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

it is broken on all platforms I've tried. We better drop that.

It just isn't implemented on X atm. In X, there is no "full screen", all windows are equal. Just create a window thats the size of the screen and move it to the right place.

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

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Quote:

That's only when you switch from fullscreen to windowed and vice-versa. I think allegro should not even allow that, but it does ATM and it is broken on all platforms I've tried. We better drop that.

I don't get it. If A5 can create a fullscreen or windowed display, and can destroy a fullscreen or windowed display context, then why can't it do both at the same time?

Matt Smith
Member #783
November 2000

Quote:

...when you switch from fullscreen to windowed and vice-versa. I think allegro should not even allow that,

This is an essential feature of practically any modern PC game. It's unthinkable to disallow it.

Elias
Member #358
May 2000

Quote:

This is an essential feature of practically any modern PC game. It's unthinkable to disallow it.

Yes, we absolutely need to support it. However, we could destroy the OpenGL state in the process. Then users simply would have to "re-upload" all shaders themselves. In case the users are also using Allegro's OpenGL driver, and Allegro itself created textures or FBOs (or with that shader-primitives addon also shaders) - Allegro of course must take care to restore them after the switch. For example in the case of textures, it's a matter of going through all bitmaps and re-creating the texture of each in the new OpenGL context.

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

 1   2   3 


Go to: