Allegro 5 GUI

Ok, I'm cooking with gas with my current project, but It's been slow going implementing controls like buttons and such. The next stage of my game is quite GUI heavy and was wondering id there is any GUI implementations for Allegro 5. I'm seeing a lot for Allegro 4 and many dead links... I'm not seeing anything jump out at me in the documentation.


Wow, I just took a quick glance at that... I'm going to probably make a few facepalm here, but looking at that page, I have no idea how to even download such a beast much less integrate that into my code. (It looks overly complicated) I'm using VS2015 and had to resort to NuGET to install Allegro after failing to compile it myself. (Back in the late 90s I cut my teeth on Allegro with DJGPP, and then went to linux. Seems things got complicated when I tried to compile for code::blocks in windows 10.

I'm also writing in C, which may complicate things. Can I mix C and C++? I assuming I download those files and add them to the my solution?

I know these seem like noob questions. I'm kind of jumping in head first resurrecting old projects of my younger years.

In a perfect world something where I can draw a button and then write a function if it is clicked would be nice, or draw a slider and have it return it's value.

I found this - I'll experiment with it later


Then you should try:

Single-file header and C, with an Allegro 5 back-end. It's similar to imgui ( in design.

edit: didn't see your edit :)


Agui is not that complicated ::)


Here's one.

No offense to Aguilar, but some people, like myself, don't want to use C++.
Anyway there are several C GUI systems you can use with A Allegro, But sometimes custom us best, a so I am writing my own GUI system for my own game.


I'm sure in a C++ context it's not that complicated, but I don't write Object -orientated code at all. Sometimes people who don't use the full OO paradigm in C++ code in "C with Classes". I, sadly, don't even do that. In a pinch I can code in "C with struct-functions"*(see footnote) when I toy with C++ forgoing simple things as namespaces and constructors.

It looks like one of the requirements of Agui is CMAKE, and I'm using VS2015. That pretty much put it dead in the water for me. I tried to use GCC and it's related build tools in win32, but Allegro is kind of a hot mess to even compile under that environment. VS2015 +NuGET + Allegro and I was good to go.

Looks like WidgetZ uses CMAKE too. Sorry :(

*(footnote) No one was able to teach me what a "class" was so so for long I honestly see C++ classes as structs with functions in them.

Chris Katko

I don't see why C++ is so hated. I mean, it has plenty of flaws but "OO" shouldn't be one of them. There's no reason you can't do "C with classes", or even do straight Data-oriented design with nothing but global functions that operate on arrays of plain-old-data (POD) structs.


object_type obj_array1;


But when it comes to a GUI? You almost ALWAYS want OO. That's the one place where OO shines. GUI's are inherently object-oriented. While random physics equations and the execution units they run on have nothing to do with OO (and that's why it's so slow), GUI's are just graphs of contexts.

I mean, I've seen people who "hate C++" go out of their way to implement vtables in C, so they can have classes with inheritance. And I'm like "What is wrong with you?" Instead of poorly reinventing the wheel, why not change "gcc" to "g++" on the commandline and magically have everything work based on millions of man hours of other developer's time?

Use OO or not. Use the right tool for the job. You can even use C++ only for the GUI, and have everything else in C that talks to it through a GUI DLL (which contains all the OO code). Depending on how you split the hierarchy lines, you could get away with it and not spend hundreds of extra hours debugging. You'd have best of both worlds. C for game, C++ only for the GUI.

Or hell, use any language for the GUI. D. Python. HTML. once you split it off from the main executable.

But I think using non-OO for a GUI of any substantial complexity, is the wrong tool for the job. In C# and Android, you can basically "inherit from" any GUI widget in the library, override only the methods you care about (like draw()) and magically add functionality like special font coloring/bolding/etc to a textbox inside of a cellgrid (like Excel) and have it touch NOTHING else. One class, inherited, override one method, and boom. You don't have to touch the data binding code. You don't have to touch random code throughout your codebase. A single function (almost) perfectly encapsulated. I'm no Microsoft buff, but when it comes to GUI, C# and WPF is heaven. (I wish against wishes they'd add WPF to Linux.) Everything is so easy that braindead college graduates who barely graduated can produce beautiful looking applications that (mostly) function according to spec.

[edit] I do think it's funny how Java embodies everything thats wrong (tm) with OO. Tons of boilerplate. And how every book and teacher talked about "getters and setters" like they were life savers, and now, everyone says they're terrible and you should never do them. You should use actions on an object, (almost) never directly set a field. Where getters were "the field can change name! Wow. Like search-and-replace never existed in our text editors..." now they're like "how dare you tell anyone a field exists." But in general, I kind of like the new strategy. It highlights that interfaces should be more "top-down" (how are people going to use this? = interface) than "bottom up" (implementation = interface).


Cmake is a free download for windows too, an it can generate Visual Studio project files. Cmake is a widely used tool for portably building C or C++ code. Even Allegro itself is built with CMake. It should not stop you from using a library or tool. Give it a try, it is quite easy to use.

I think it is not a secret I dislike C++. I know it quite well, and I use it if I really must, but I got burned by it too many times. I won't discuss more in detail since it would derail this thread, but I shav some very good reasons to stick to pure C, even for GUI libraries.

Edgar Reynaldo

You're welcome to use my gui library Eagle with CB and MinGW if you like, but it still needs a lot of work.

Caveat Emptor :

I'm willing to build binaries if you like, but you'll have to use MinGW, that's all I support right now. It also builds in Linux, and on Windows with Code::Blocks.

Anyway, feel free to browse through the source :

Chris Katko
nshade said:

*(footnote) No one was able to teach me what a "class" was so so for long I honestly see C++ classes as structs with functions in them.

Well.. they are... they just a context pointer inside of the function arguments. So

class my_class
int x;
my_function(int a) //method
x = 2;


void my_class_my_function(*my_class this) //normal / global function

I think it's more of a "how you use it" difference than a physical difference. Although, basically 99% of introduction to programming courses teach you the horrible idea that a class is an object like a tree. So you have a green tree? Inherit from tree! But wait, I have a "big tree". Inherit from tree! Now I have a "big green tree"... inherit ... from both "big tree" AND "green tree"? PSSSSSSSSSSHHHHHHHHHLDFLDPHGADFpndkgnlkdgnlakdsgnowethqtewq.

There's no physical, conceptual, or computer tech requirement that trees have to be their own object and "big tree" should be inherited. And, the second you treat "tree" as an individual object with methods that only operate on ONE object at a time (itself) you have now completely destroyed any chance of your code running fast. Computers work great doing "one operation on many" at a time. The second you use methods that ASSUME one object ("me") the compiler (and CPU) can no longer reason about bundles of objects and the computer slams to a snails pace of what it could be. Every time you load draw() for an object, it then has to load the relevant pieces into cache. But, then you call update() and it has to unload draw() and load update(). But then you touch the next object. You call object2.draw(). It unloads object1.update() and loads object2.draw(). Over and over and over.

On the other hand, if you loaded draw() and drew object1, then object2, then object3 the "draw" function is already in cache. That one simple architectural change pays off huge dividends in performance because it's no longer destroying the cache. (The biggest bottleneck on modern computers is RAM<->cache. RAM is 100x to 200x slower than a CPU.) Furthermore, the second you treat objects in order (draw this, then that, then that) you can now work on bundles of objects. draw_these(OBJS_ARRAY) instead of draw_one(obj). The speed up continues.

Finally, you then go for "optimizing for the most common case". You almost always draw a group, so the main functions draw groups. Then, if you have to draw a single object, you treat that as another pathway that incurs a penalty (if / switch / etc) to access. As long as the most common case gets through without tons of branching, the net speedup far exceeds what you'd "lose" making the lesser known cases require more branching to get here. (And then you can also "sort" branching cases so that objects with similar branches occur together, and how every "bool" in your code is effectively another branch requirement. But I'm really getting off topic here, eh?)


I can see OOs usefulness, and I am far from hating on C++. However, I come an ancient realm. I learned programming by way of BASIC which then "advanced" to 6502 and 8088 assembly the early 80s. I'm really at home hanging out just above the metal. I recently have some free time to work on a few passion projects and wanted to pick up programming again. C is that lovely bed sheet that covers the mattress of assembly over the box spring of machine code. It's light enough that I can peel back a bit an poke at the CPU, for no other reason that it tickles my childhood.

I admit. Keeping track of variables via "globals.c" and "externs.h" it a little trying. (Scope? What's that?) Also sequestering my functions into .c/.h "objects" is very dated. But I also play with game code from the 1970s and 80s so, like the Millennium Falcon, it's really rough, and sometimes sputters, but it's the fastest hunk of junk in the galaxy...

I'm seen some things in C that are really archaic like creating pointers in structs and using them to call functions is odd. (Calling a function by pointer is just strange for me in general.)

I may be getting a little off topic now though..

As far as CMAKE goes.. I thought MAKE was a program that just checked of a source file was touched recently and if it was, told the compiler to recompile the object file for the linker. I figure since Visual Studio keeps track of that internally, there is no need for something like that under win32 unless you are using UNIX-like build tools. Maybe I'm mistaken and I will look into it.

Edgar Reynaldo

CMake is perfectly compatible with MSVC 2015, you just have to pass the right generator to cmake.

The following generators are available on this platform:
  Visual Studio 15 2017 [arch] = Generates Visual Studio 2017 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 14 2015 [arch] = Generates Visual Studio 2015 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 12 2013 [arch] = Generates Visual Studio 2013 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 11 2012 [arch] = Generates Visual Studio 2012 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 10 2010 [arch] = Generates Visual Studio 2010 project files.
                                 Optional [arch] can be "Win64" or "IA64".
  Visual Studio 9 2008 [arch]  = Generates Visual Studio 2008 project files.
                                 Optional [arch] can be "Win64" or "IA64".
  Visual Studio 8 2005 [arch]  = Generates Visual Studio 2005 project files.
                                 Optional [arch] can be "Win64".
  Visual Studio 7 .NET 2003    = Deprecated.  Generates Visual Studio .NET
                                 2003 project files.
  Borland Makefiles            = Generates Borland makefiles.
  NMake Makefiles              = Generates NMake makefiles.
  NMake Makefiles JOM          = Generates JOM makefiles.
  Green Hills MULTI            = Generates Green Hills MULTI files
                                 (experimental, work-in-progress).
  MSYS Makefiles               = Generates MSYS makefiles.
  MinGW Makefiles              = Generates a make file for use with
  Unix Makefiles               = Generates standard UNIX makefiles.


OO is a tool. If you use it incorrectly, it will not be useful and just set you back.
Favor programming to interfaces.
Favor composition over inheritance.
An object in an OO language can represent a physical thing, it is not that physical thing.
This is why doing:

class Square : public Rectangle

Is a terrible idea and will have you swearing off OO forever.

Wow, I wrote Agui 7 years ago. Holly crap :o

Edgar Reynaldo
jmasterx said:

Favor composition over inheritance.

Inheritance is composition, without all the extra work. I don't think this adequately conveys the idea you were trying to represent.

Thread #617070. Printed from