As you all know, Allegro is a high level library.

So I've been using Godot recently. Compared to Allegro, it's a really hefty thing in terms of features (I mean, it's an actual full-blown engine) - it's pretty sweet though, and also is libre, and saves projects' resources in eternally versionable text files. I've thus grown to like it rather a lot.

However, I was absolutely shocked to discover that it doesn't implement al_grab_font_from_bitmap! Even worse, you are forced to use a sickening Win32 tool called BMFont to make your bitmap fonts. Unacceptable.

After wondering what kind of shoddy production they must be running, I decided to fix this injustice. Therefore, I'm sure you'll all be glad to hear that Godot has finally been brought up to speed with Allegro's modern features:

https://godotengine.org/asset-library/asset/598

So yeah, they pretty much have to add this to core now.

{"name":"diagram.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/9\/190987d05bf3b970a49f427fcefdccd8.png","w":1046,"h":512,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/9\/190987d05bf3b970a49f427fcefdccd8"}

Nice! What about the other way around - which feature should allegro copy from godot? I realize they are very different in goal and scope. But if there is one thing you could transfer the other way around, what would it be?

Very good question - I guess having an API for compute shaders would be pretty cool (if we're talking about shiny flashy features).

On the other hand, what'd be absolutely brilliant is a solid OpenGL ES profile selector. Ironically, I think Allegro's currently only works on X11?

Not sure exactly copy from Godot, but I think a 3D addon, which helped do a bunch of standard features would be great.

Mesh loading/construction/geometric shapes, material handling, and some basic camera functionality, would be pretty sweet.

Even though I've finally got my Voxel engine running, it's still effectively drawing it 2D, and thus, you cannot currently rotate the view, as to keep the framerate up, I have to cache all the vertices of drawn surfaces.

Arguably, maybe I should try a "3D engine/platform", but I must admit, I've never managed to get going with Godot or Unity; and always fall back to Allegro

All of the features in Allegro are low level and as such, I'm not sure what other modern low level features could be added. All the "next level" features require a more architectural, engine, or framework specific methodology. These are things like materials, shaders, geometry, or an entity system or scene graph, to name a few. All of those are typically coupled to each other in some specific way to make an "engine" and require some cohesive theory and/or baked in assumptions.

As an example, Allegro's multi-line text rendering feature realistically needed to come with an al_do_muliline_text variant. It almost seems to open a tear in the API, in order to accommodate all the divergent needs required since the introduction of al_draw_multiline_text. As such, any other net new layer of features would likely introduce even more complex seams to be truly open-ended.

I would love to hear a counter-argument, because I would love to see more features out-of-the box for Allegro. I'm not a fan of the reality of the points I laid out, that there is essentially a "moratorium" or "ceiling" on the Allegro API as it is.

One thing comes to mind, (though not very sexy), would be the addition of translation/internationalized strings. It would be a cool feature to add for all of our multi-lingual users and developers wanting to internationalize their application.

I have a relatively thorough module in AllegroFlare called Internationalization, it does some stuff:

• Internationalization header

• Internationalization source

• test files with a lot of example use cases

@Mark Oates, that's a fair point about it becoming an engine, which Allegro isn't.

On features:

One feature I did previously mention on IRC, was the ability, when creating a VOICE, was to select which physical output on the computer it went to.

ie, then you could open a voice for the speakers, and a different voice for headphones.

To be fair, I haven't really thought of a practical use for that feature; unless you wanted two players on a single computer with a headset each. But most multiplayer games these days would just use multiple computers.

Also, keeping to multiple users on a single computer, I saw a project called SNIIS (https://github.com/Schrompf/sniis) that allowed you to identify input from multiple mice and keyboards.

Again, a neat trick, but probably not something that would be used very often.

I have a library called ManyMouse that does essentially the same thing. Works on Windows with limited desktop integration (that is the hard part).

I plan to rewrite it and make it nicer and easier to use. Some day.

The idea that Allegro is "complete" is a big mistake imho.

Yeah, I think that - in summary - I'd just like better cross-platform support for the current featureset, rather than a bunch of new features.

Yea, I agree. If I could rely on Allegro to be relentlessly reliable and consistent across platforms out-of-the-box, that would be huge as far as I'm concerned.

Congratulations, you both just volunteered.

And you just delegated the task! I guess that means you're the manger.

Seriously, put your ideas in feature requests or bug reports. Wasting your time talking about it here won't do any good.

Right, allegro isn't an engine and shouldn't become one. Instead, this is what allegro is to me

• Cross-platform compatibility

• Abstraction layer over hardware - a transparent way to handle different inputs, different displays etc.

• Freedom of programming language. Given that it's so low level, it fits with many programming languages and paradigms.

• A fairly comprehensive dependency. Dependencies in C are a pain, and it's nice to have it all in one package, rather than having to chase up, say, a separate jpeg loading library for different platforms.

So, playing to allegro's strengths I think these would be worthwhile developments:

• add-ons for loading common game assets where they are sufficiently standardized, so that you don't have to manage the dependency. For example, sprite atlases, tilemaps, 3D meshes

• Abstractions for more hardware types. Managing multiple displays, multiple inputs, multiple sound outputs are nice examples.

• Useful cross-platform wrappers. A wrapper for winsock/bsdsockets comes to mind

• Anything that makes it easier to build games on other platforms, such as android / iOS, or cross-platform builds.

• More consistent support for more programming languages. Some of the wrappers are poorly supported.

ha. ha.

Not that I'd ever intended this to be a discussion on Allegro features (but hey this is a.cc) - yeah, Edgar's not wrong though. I'm gonna submit one for compute shaders now.

It really doesn't make much sense. That's what addons are for, so that anyone can create them without anyone's permission, although manufacturing as a totally external extra library there would be some differences.

This would provide a list of addons that anyone could add to. At least that's the idea I understand, sure?

" Managing multiple displays, multiple inputs, multiple sound output"
Like having monitor/input/sound id as a function parameter ? I like it.

"Useful cross-platform wrappers. A wrapper for winsock/bsdsockets comes to mind"
==> proposed to write one as an addons/full allegro port/whatever is good. The proposal got no real interest from the devs/users present during the talk.