If it's true, you don't believ in the afterlife.
Dizzy Egg

I don't have any 'real' friends. I speak the truth.

Allegro is dead, man. A4/A5....dead....allegro.cc......dead.....let's all just admit it.....I'm the only egg with the balls to say it, so, again, "I'll be the bad guy".

;D. Damn shame, I thought A5 would get us back but.....let's admit it guys, it's done.

:-/

>:(

torhu

:-/

Trent Gamblin

It does look that way... I can't force myself to work on it anymore. I'll fix them as I need fixes but that's about it.

jmasterx

I really don't get why it's so dead. I seriously don't get the appeal of Unity et al. I tried it, I did not like it. SDL 2 has haptics but it has a lot of other issues that Allegro solves for you. SFML is cute but no mobile support. Lib GDX is only for Java, Cocos2D only works on mobile...

I can't think of a better library than Allegro in its domain. Sure, I would probably not use it for a 3D game but for 2D games, Unity is not that amazing. I have seen countless students at my University try to make games with Unity. They get certain things done super fast, but then a bunch of things are broken/missing/crash. To get a solid polished 2D game I would say is not much easier with Unity, other than the syntax sugar of C#.

I watched a video the other day of a games company that makes their money writing Unity plugins, because a lot of people are like, ouuu we're gonna use Unity and make this super ultra amazing game, then they buy all these plugins, tile editors, etc, and the game never even gets close to done because they underestimate how much work it is to make a full polished game. Because, it's not really much easier with Unity.

As you can probably tell, I'm not a big fan of big frameworks.

In Unity, if something is broken you are at their mercy, in Allegro, just submit a patch. When I started building my game, I found bugs in A5 that I submitted patches for and they became part of 5.0/5.1. That's a pretty neat feeling if you ask me! I stopped contributing to Allegro because my game became stable. If ever my game starts crashing because of Allegro again, I will fix it.

All the libraries I use are either built by me or 100% open source / bsd. I have contributed several fixes to the networking library I use too.

That's something I just can't have with closed sourced proprietary Unity plugins. >:(

Thomas Fjellstrom

Allegro is pretty much a scratch an itch type thing. Work gets done when someone has an itch they need scratching.

Aikei_c
jmasterx said:

SFML is cute but no mobile support.

There is a not yet officially released mobile port, just look on the forums.

https://github.com/LaurentGomila/SFML/wiki/Tutorial:-Building-SFML-for-Android
https://github.com/LaurentGomila/SFML/tree/master/examples/android

bamccaig

I think the problem is that Allegro 5 changed what Allegro was. The members that were still using Allegro were alienated by it and moved on. If they had to learn something new they might as well learn something better. Allegro had its place in the 90s and early 00s, but it is more or less just nostalgic now. You can absolutely make a game with it, but it is in no way unique in that regard. And in practically all cases something better exists and has a larger user base..

The aged design of the library combined with the fact that most of our members "grew up" and "got a life" means that we have basically nobody left in the community. Even I have a girlfriend, for fucks sake. It's just a matter of time before Hell freezes over and the universe is sucked down a drain. :o

I think that a higher-level library is in order though. Those that still want to use Allegro 5 (or Allegro 4 for that matter) more power to you. Bug fixes where appropriate. However, low-level is just outdated... How many Allegro users ever really stressed the hardware? Probably almost none. At least within the last 5 years. And even if they did, the hardware is still faster now so it's probably not a problem anymore... Or those that continue to have performance issues are probably suffering from poor algorithms, probably in CPU code. We could probably afford to have a higher-level implementation without hurting performance significantly.

I think the ultimate failing of Allegro is that experience with Allegro can't be considered practical. You won't learn to be a "professional" game programmer writing games with Allegro. The game is forever changed. Those people seeking employment as a game's programmer need to go elsewhere. That's probably the real problem. Most of our game's industry members have moved on to greener pastures because Allegro just wasn't practical for their careers. And what's the point of working on software that isn't really useful? Perhaps we should arrange to have an online "meeting" to discuss the future of the Allegro project and come up with outrageous ideas to really make it useful again.

StevenVI
Quote:

Even I have a girlfriend, for s sake.

Seriously. None of us ever expected that that was even possible! :-X

bamccaig said:

I think that a higher-level library is in order though.

It's not an "us versus them" game. Find something high level that already works and use it/contribute to it. We don't need to make Allegro Unity or the Allegro Game Engine or some such nonsense. You'd only need to construct a new project if there's an actual use for it.

james_lohr

Maybe you're over-estimating the "language barrier"?

I used to use Allegro quite a lot. Now I use Libgdx. It's a fantastic library. Java / C / C#, who cares?

I do occasionally still yearn for ye-old days of mode-13 and putting down pixels exactly where I want them; but these days are long gone, and OpenGL has now become a familiar friend.

For pleasure-coding, I hate frameworks too. I fell in love with Libgdx within a week of using it. It's wonderfully well constructed.

bamccaig said:

The aged design of the library combined with the fact that most of our members "grew up" and "got a life" means that we have basically nobody left in the community.

I got married, bought a house, and am now a manager of a department of around 100 developers. ....I still spend the same amount of free time coding games as ever, I just don't play WoW / Wc3 / SC any more. ;D

FMC

I more or less agree with bammcaig, specifically with Allegro being too low level to be practical.

I started programming games with Allegro, then abandoned game programming (didn't have time anymore) and just recently (thanks to a thread here) tried Unity and fell in love with it. :P

For me, the problem was that with only allegro everything took too much time to accomplish. It's not that Allegro is doing something wrong, it's that there are still a lot of steps you need before working on your actual game ideas!

With Unity i don't have to worry about resolution, physics engines, file loading, path finding, animation, and whole load of other low\mid-level stuff. The things I personally implement are the ones that I actually want to make different and unique. It's really faster and more pleasant!

And while i think it would be nice to have an open source alternative to Unity i doubt there is enough energy left in this community to attempt a project of such magnitude :-/

Thomas Fjellstrom

There was never that much energy or direction in this community. Ever. Things like it pop up on occasion... Ever seen a monday project thread? :D

FMC

I did, but years ago people at least seemed to be interested :P

Thomas Fjellstrom

Well, at least in my case, i'm interested but I'm also pragmatic. Would I like it to happen? Sure! Do I expect it to happen? Not really no.

Dennis

I am considering to shift my priorities away from developing an HTML5 lib and to dedicate more time to developing using Allegro5(maybe start with porting/rewriting all my A4 programs) for reasons taking into consideration performance and machine access restrictions imposed by HTML5.

It is certainly nice to be able to quickly run/test everything directly in a browser without waiting for anything to compile but there still seem to be too many drawbacks (webgl performance is sluggish on hardware which is just a couple of years old and the very restricted access to the local filesystem makes it impossible to implement things like periodic autosaving(unless backed up by a webserver adding more bloat)... there is also no way to get low level access to UDP/TCP socket programming yet in the browser world).

Erethar

I'm pretty new here, but I'd hate to see it go. I only started programming a few years ago (and game programming shortly after that), but Allegro clicked in a way no other library did. Over the past 2-3 years, I've tried Rubygame, XNA, MonoGame, Unity, SDL, SFML, and Allegro. The only one I liked close to as much was RubyGame, and thats long-since dead. Plus there are the performance concerns with Ruby (as much as I love the language).

I personally don't get the Unity thing, and I HAVE spent a decent amount of time working with it. I don't want to struggle with a heavyweight UI and massive API, I just want a thin library that provides a layer of abstraction over the parts that really ARE too low-level for me to want to deal with (low-level graphics/sound/input/events) and lets me do the rest.

That seems to leave me with 3 options: SDL, SFML, and Allegro. I tried them in that order. The basic examples for SDL and SFML had me tearing my hair out. Maybe I just got unlucky but everything seemed to go wrong for reasons I had trouble diagnosing. Then I tried the introductory Allegro5 tutorials, and everything "just worked".

The thing is, I recently started a project with a small group of people. I suggested Allegro, and everybody said "what?". Then someone else suggested Unity, and I was outnumbered everyone-else vs me. So we went with Unity. And it works alright. I make progress, but there's something missing.

On the side, I'm still working on my own Allegro project, and its just more 'fun'. I've started using the D programming language, and the bindings provided by DAllegro provide something that feels much more natural than UnityEngine+C#. Combine that with Vim and some other nice open-source tools (LMMS, Aseprite, Inkscape, Audacity, Tiled) and I have an environment that I can actually enjoy working in (after all, this is my free time I'm spending).

Well, that turned out to be a longer comment than I intended.

Sirocco

The logical response is: A5 is dead; time to start on A6 and not fuck it up this time.

Look to the core strengths of Allegro. It was always easy to set up, understand, and get 2D apps knocked out quickly. A lot of people felt that A5 reversed those trends. You had a place in the gaming world and you lost it. Curiously, few things have really moved in to fill the void.

Also, don't totally ignore the Windows branch. No one here wants to hear this but that was a major fuckup. For a long time it wouldn't even build from scratch for most people.

jmasterx

@Erethar
Exactly, Unity has sort of become what SDL was in the late 90's / early 00's.

It's sad too though that in general, Allegro is the absolute last choice in everything. I see that trend often... SDL -> SFML -> Allegro

It should probably be more: Allegro -> SFML -> SDL

Allegro IS too low level by today's standards, but, I would say Unity is too high level. Things like sprite sheet animation, events, etc should be done for you, but for example, I know some students who, for their 4th year undergraduate project in Software Engineering attempted a Magic card game in Unity where 2 players can vs each other.

They used the Photon plugin for networking. After 3 months, the result of 3 students was basically a menu with generic looking buttons, the client WAS the server which caused all kinds of bugs, there were several bugs that they did not understand, the game could only play 1 land card and had to be played perfectly or the game froze/crashed. When one player lost life, the other player's life label was overlapped on top of your life label... they did not understand why... Keep in mind, these are 4th year students in computer science taking a software engineering course. Another student told me after that he could probably have gotten equivalent functionality in about a weekend in Java. Which I would agree with.

Some things they had, like a full-fledged lobby, is a nice out of the box feature, but other things like the game logic looked so tangled that I wonder if all that high level functionality is worth it.

I noticed they had a big interface for their cards, which could be resolved better with composition instead of inheritance.

That's sort of a problem too with having your first game programming experience with Unity. You do not understand fundamentally how to program. Unity uses very advanced OOP mechanisms and to use it effectively you should know OOP and design patterns.

But I guess you run into the same problems with C/C++, however with Unity, the framework is built around those OOP concepts and you should have some experience before taking on a massive project.

Another issue, which is similar to how programming shifted from asm to C, is that the new generation of programmers do not learn about concept such as:
Pointers, Heap vs Stack, Dynamic allocation vs stack allocation, function pointers, vtables etc. Therefore, you can end up with some very inefficient designs and little concern for performance. Then people blame it on JIT when in fact they are dynamically requesting memory in a super tight loop.

Computer Science programs do cover these topics, but there is nothing like hobby programming to learn the ropes.

I was talking with someone the other day and I was wondering if it is possible with Unity to create a Minecraft clone that runs as fast as its Java counterpart. I was wondering if, in general, Unity manages so much for you that you cannot make low level optimizations needed for a game displaying millions of the same cube without switching the texture in OpenGL. Can you optimize the frustum culling, the occlusion culling, PVS, etc? How many cubes would it naively render with its algorithms vs the number MC does?

Maybe it does this just fine, but I did wonder. If it can do it, how much of the wheel are you reinventing, does it require as much work as doing it in Java?

Thomas Fjellstrom
Sirocco said:

Curiously, few things have really moved in to fill the void.

Because not enough people wanted it?

Quote:

Also, don't totally ignore the Windows branch.

I don't know about you, but I tend not to work on things that don't interest me. If people want it, they can work on it.

Quote:

For a long time it wouldn't even build from scratch for most people.

Which version and when? I know its a pain to compile from scratch, including all of the dependencies, but it's not been impossible as far as I can remember. Now-adays you can just grab msys2 with mingw64 and go to town. It includes most of the dependencies (possibly all of them), and its much easier to build yourself.

l j
jmasterx said:

They used the Photon plugin for networking. After 3 months, the result of 3 students was basically a menu with generic looking buttons, the client WAS the server which caused all kinds of bugs, there were several bugs that they did not understand, the game could only play 1 land card and had to be played perfectly or the game froze/crashed.

I hate the free networking solutions for Unity so much I made my own. Using a simple client-server model. I might release it publically when it's done and optimized.

When allegro 5 was released, SDL was still using its outdated API and SFML had compatibility issues with AMD. This is why I chose allegro 5, I felt it was ahead of the competition when it was released.

Sirocco

Which version and when? I know its a pain to compile from scratch, including all of the dependencies, but it's not been impossible as far as I can remember. Now-adays you can just grab msys2 with mingw64 and go to town. It includes most of the dependencies (possibly all of them), and its much easier to build yourself.

Dunno. We're talking a few years back, and I don't/didn't care enough to have kept the old files. I remember seeing a note on the download page strongly urging people to download pre-built binaries instead of rolling your own lib.

Quote:

I don't know about you, but I tend not to work on things that don't interest me. If people want it, they can work on it.

Uh huh. You don't see where that leads, do you? People don't work on it because SDL et alia already exist and are easier to get started with. People come here, download A5, see what it has to offer, and walk away. It's time to stop ignoring that.

Trent Gamblin

Allegro 5 on Windows has never been ignored and has always easily compiled. It was the FIRST branch of A5 to ever exist actually. If you can't compile it, look elsewhere for the blame.

Allegro 5 isn't, never will be and shouldn't be for everyone. For what it is it's actually very very good. I don't care one bit if it's not popular.

Polybios

I wholeheartedly disagree with the general sentiment. Allegro is better than ever.
Problems with A5: It's late, not advertised, crucial features (shaders, Android) are marked as 'unstable', building binaries could be easier.

This means: More and more people learn to use SDL/... instead. Those will hardly ever become A5 users, even if we know it's better. Everyone learning SDL now is probably lost for Allegro.

Priority should therefore be: Get 'stable' A 5.2 out, provide binaries, advertise and see. This is IMHO more important than adding 'some cool feature X I like', but maybe not gonna happen? :-/

What is even planned for 5.2? I think some people have shown their willingness to help out recently, but at least I have the impression that there is no binding plan. There is a roadmap, but Trent (one of the core devs) said it's incorrect. IMHO, we need a binding plan, so people can see where they could contribute. IMHO this has to be done by the core devs, because they know the project best.

edit:

I don't care one bit if it's not popular.

Just to clarify: I'm not for popularity as an end in itself, but because I think more users means more bug reports, more stability, more potential developers, overall better quality and less risk of 'dying'.

Trent Gamblin

The only "core devs" willing to help out anymore, from what I gather are SiegeLord and I. I personally don't think much needs to be done for it to happen. Once Siege gets his compressed texture addon done, we'll release it. I'll tidy up a few things but I don't have time to do everything everyone wants (and don't agree on a lot of it anyway :P).

jmasterx

I also wanted to add that, I've always sort of thought that the name Allegro itself might be a source of pitfall because Allegro up to A4 was software rendered and ran on DOS. I think a lot of people think Allegro and they think software rendered. A lot of people I have spoken to think this as well. They are unaware that a hardware accelerated Allegro even exists. Calling it something like libGator would probably have yielded more interest in itself.

I really think releasing 5.2.0 is a great idea, and releasing binaries, and having some very basic getting started guides for each platform could help a lot too. In addition, maybe also some kind of template project that comes with Allegro could be really useful too. This template project has everything to get started fast. You do not have to understand timers or event queues, it exposes a function for logic, a function for rendering, functions for mouse callbacks, etc. A bit like GLUT. GLUT was so popular because of how blatantly easy to get something going, not because it was that great.

There needs to be a way for people to get their ideas out as quickly as with A4. Then once they gain xp, they can look deeper into how the template works and modify it.

This is how I learned A5. I copied a tutorial from the Wiki and did not understand much, but I had a render, logic, kb, and mouse callback so I started making games.

Dennis

Allegro 5 on Windows has never been ignored and has always easily compiled.

Allegro 5 itself maybe... I faintly recall earlier versions (before cmake was around to configure and provide project files), getting all the dependencies and then Allegro 5 compiled using MSVC was a royal pain.

I have not recently compiled Allegro 5 on Windows but only two days ago grabbed the latest version from git and compiled almost without problems (only had to fix one undeclared symbol due to it having finally been removed from ffmpeg (I sent a patch to the mailing list) after it had been deprecated for a long time already) on Arch Linux.

The next challenge will be to find a way to cross-compile Windows binaries from within Linux... I guess winegcc is what I will need for that but I am unsure whether that will produce binaries which will only run in Wine and not in actual Windows.

Polybios

@Trent: That's really good news about 5.2.

but I don't have time to do everything everyone wants

Preserving the 'essence' is quite important. / One Unity is enough. ;D

@jmasterx: Agree 100%.

Trent Gamblin

I took a look at what I said I was going to in the other thread - building Android examples. To my surprise, it's already there. Guess I ignored it all this time. Just needed a few small modifications to get it to work on Windows host. So I'll move on to the next thing on the list. :P

Yodhe23

I still use Allegro5 to write games, I like the fact I can port a game between Android/Windows and Linux in a less than a day.

I like the fact that I could update a 50,000+ line code game from Allegro4 -> 5 in only a couple of days.

I like the fact that I could port that game from Linux to Android in less than a week.

I like the fact it is free, and made in the best spirit of doing stuff, because I remember the days when you had to pay for graphics libraries and compilers, and how difficult it was to make indie games back in the 90's.

It will be nice to see 5.2+, but for the next year or two I will still be making games with it.

Erethar
jmasterx said:

Things like sprite sheet animation, events, etc should be done for you

I feel like these kinds of things belong in some sort of extension library rather than Allegro itself.
When you first get started, having too many features available can be overwhelming.

I remember spending a lot of time in XNA wondering what the hell a 'SpriteBatch' was and why I had to use it for all my drawing.

When I started using allegro, drawing things to the screen actually felt simpler -- it was just a single function and the arguments I was passing felt pretty self explanatory. As I got more experienced, I started struggling with meticulous manual ordering of draw calls and use of al_hold_bitmap_drawing. Finally I decided to write a module that would handle sorting bitmaps by a 'depth' value and batching for efficiency. About halfway through developing it, I finally went 'OH! I bet THAT's what a SpriteBatch is' (this was around a year after I had stopped using XNA).

jmasterx said:

That's sort of a problem too with having your first game programming experience with Unity. You do not understand fundamentally how to program. Unity uses very advanced OOP mechanisms and to use it effectively you should know OOP and design patterns.

Just got out of a University where most classes teach OOP as THE programming paradigm. After writing terrible, terrible OOP code in Java, C#, and C++, I finally started to program in pure, raw C. C taught me more about how to write good OOP code than any OOP language had, because for the first time, I actually understood that OOP isn't a necessity or requirement. OOP is a tool that can be extremely useful, but so easy to abuse.

I remember assignments that had me building inheritance hierarchies just for the sake of demonstrating what inheritance IS. Turns out that the best way to understand inheritance is to try working without it.

Edgar Reynaldo
Sirocco said:

The logical response is: A5 is dead; time to start on A6 and not F it up this time.

I'm not quite sure why you feel this way - I feel myself A5 is a definite improvement over A4 (except maybe in the sound dept, but I digress). Why do you think we need to start over? What does A5 do wrong in your opinion? I do agree that our user base is at an all time low, and we are running out of regular time developers, and both of those need to be remedied.

Do you feel A5 is still too low level? That is one of the reasons I created my Eagle library, to provide a higher level abstraction over the low level code. My library does advanced input handling and simplifies setup to the point where it is only a few simple lines now. Basic facilities like an event queue and system timer are provided. Most objects are members of an Object class that tracks all the memory allocated by any of those objects. There is a GUI engine on top of it all to go with it. Some thing I would like to include in my lib is an image atlas manager.But there doesn't seem to be much demand for a higher level library, despite allegro's low level routines.

Polybios said:

I wholeheartedly disagree with the general sentiment. Allegro is better than ever.
Problems with A5: It's late, not advertised, crucial features (shaders, Android) are marked as 'unstable', building binaries could be easier.

This means: More and more people learn to use SDL/... instead. Those will hardly ever become A5 users, even if we know it's better. Everyone learning SDL now is probably lost for Allegro.

I agree with this completely, but I want to add that there is an aura of misinformation about Allegro 5 due to its predecessor's legacy. I think we need a campaign to educate potential users about the differences between them.

But I think we need to do something to stimulate Allegro, before Allegro falls totally out of use. There are other websites out there where we could spread the word about Allegro 5, especially like GameDev.net and there must be others that you know of. I'm not a social butteerfly anymore so I'm kind of out of touch.

pkrcel

Well, I am absolutely new and can't program a game to save my life, but I KNOW that deploying allegro for Windows both with MSVC and Mingw64 is easy.

And I mean that, you only have to know some VERY basic concepts about building the damn stuff.

Might be because for work (oh so long ago) I had to jump through fiery hoops to get my code to work on embedded platforms so in comparison this feels easy, but I doubt it.

Allegro 5 is instuitive and complete, I can't do much for comparison (having dabbled only a tiny bit with SDL) but it's no doubt a VERY good lib.

The real problem to me is that there seems to be no regular devs besides Trent and SiegeLord (as per Trent's words) and so there's a definitive slowdown in release pace....this might have shrunk the community interest and thus the community itself ...in projects like this the community drive is of paramount importance.

I'd LOVE to contribute, but as a matter of fact I'd just love to BE ABLE to...I'm simply not enuff skilled, and can't dedicate myself to improve such skill.

Biggest concern out there I think should be (after the prioritires for 5.2) tidy up the Android port deployment, I guess. I don't care for it particularly but it clearly the hot topic in gaming and might attract more users, and in and of itself the mobile marketplace is a powerful showcase.

Allegro is not done, but unfortunately it surely suffers.

beoran

Allegro isn't dead until we give up on it and I'm not going to do so. Allegro is a great library that I use for my own game development and that works fantastically.

However, with my newborn son and young daughter I hardly have any time left for myself these day. I contributed to Allegro this summer and I'd love to be able to do more but as of yet I feel unable to do so. I hope it gets better but I don't know when I will get there... :p

I've been making a lot of suggestions in other threads before to promote Allegro, but they sort of went nowhere due to bike shedding. Maybe we need to give someone able and willing the role of "PR tzar" to edit the web site, logo and other promotional channels as that person thinks best.

Maybe one suggestion I'd like to make is to change the development mode of Allegro from the current way, which is appropriate for a widely used lib where stability matters the most, to a more dynamic approach. Move main development to Github, and it's pull requests and issue tracker and use that to allow more rapid development. Communicate over the forum and IRC, but abandon the mailing list since it is barely used. Make regular releases, and increase the version number once per year. There are still many features we could add, and still many bugs to be fixed, and for now I feel we need a more agile approach.

And to all who still work on Allegro: thanks and keep up the good work!

Sirocco

Allegro 5 on Windows has never been ignored and has always easily compiled. It was the FIRST branch of A5 to ever exist actually. If you can't compile it, look elsewhere for the blame.

Allegro 5 isn't, never will be and shouldn't be for everyone. For what it is it's actually very very good. I don't care one bit if it's not popular.

The denial in this thread is nigh legendary.

Trent Gamblin

The denial that you're not good at building a simple library?

EDIT: By the way, anybody who thinks Allegro 4 was at any time better than 5 is a complete and total NOOB.

Fishcake

I like Allegro for what it is, and especially the community. I don't think it's important for Allegro to be popular. For me, I feel that Allegro is like that odd coffee shop hidden at one corner of a town that people rarely go to. Every time you pass by, you'll see the same bunch of people hanging out. Every year. As time passes, so did those people. Some got married. Others have girlfriends. But they'll still come back to that coffee shop to meet up. And that's cool. I like that coffee shop.

Reminds me of this xkcd comic: http://xkcd.com/1305/

Or maybe I'm just too sentimental. ;D

Ultio

There's a lot of hearsay in this thread regarding the popularity of Allegro. Let me try to coax this thread back into reality...

Instead of just making conjecture, let's look at the actual download numbers:

http://sourceforge.net/projects/alleg/files/stats/timeline?dates=2000-01-01+to+2014-12-07

Other than the peak in 2002 and valley in 2003, it appears Allegro's popularity (at least based off download rate) is actually quite consistent (at least compared to itself).

Perhaps Matthew (does he still run this place?) could provide download stats for a.cc.

It may also be worth comparing this to download stats for other similar libraries.

:]

Sirocco
Ultio said:

Instead of just making conjecture, let's look at the actual download numbers:

Good. Exactly what this thread needs. With those numbers, and the ones I'm working on from actual developers, we'll have a (hopefully) good idea of whether anyone is actually using the lib they are downloading, because that's what actually matters.

Thomas Fjellstrom
Sirocco said:

Uh huh. You don't see where that leads, do you? People don't work on it because SDL et alia already exist and are easier to get started with. People come here, download A5, see what it has to offer, and walk away. It's time to stop ignoring that.

Are you sure you're up to date? Not sure you are.

Again, why force yourself to do something you don't enjoy doing? I don't enjoy working in windows at all, and currently have no need for it. Maybe someday, I'll work on a serious game and make sure to port it to windows. But today is not that day.

PoVRAZOR

I like to occasionally appear, though usually it's when friends remind me Allegro is still a thing.

So a decade ago, I had a need Allegro could have filled: General purpose raster graphics library. No, not cross platform, but general purpose. Give it a chunk of memory, and here are a library of function for doing anything you could ever want (sprite wise) in that RAM. Hey maybe even some simple 3D too. I would have loved to have it as a fallback renderer, when a GPU wasn't available. I still think there's a distinct lack of a good (or any) general purpose fast raster graphics library. And heck, if there was an API variation you could feed a single triangle/quad render function too, it could be forward compatible as well. Would have been great for PC/Console/Obscure porting. Alas.

When I was a wee-lad using Allegro for my gamedev on DOS and Windows 95 machines, it was the raster graphics performance and features that made me use it. Before Allegro I was a big user of a Turbo Pascal library I think was called SPX. It was capable of rendering full-screen 2D graphics at 60 FPS on my 486 DX computer. I didn't understand what or how it was so capable (I didn't understand Assembly yet), but it was easy to make, load, and display sprite graphics. It came bundled with a tool SPXMaker, and that was my workflow (edit sprites, export, load, draw in game). It felt good.

When I eventually moved to C, Allegro filled the same niche. I paired it with a similarly useful sprite and package editor, the name of which I can't remember (I never found anyone else that heard of it or used it). I believe I had a Pentium 90, which was like infinite CPU power back then. I would dabble with other libraries and tools, but Allegro is the one that performed best (at least on my teenage budget of $0). Screw Direct X, I had DJGPP and this monster.

To me, Allegro was a complete C workflow for making, packaging, loading and displaying sprite graphics on screen fast.

Eventually I start doing Nintendo GameBoy homebrew. Lo and behold, the community has an amazing sprite and map editor freely available. My workflow stays intact (make assets, load assets, display assets). Before I know it, I'm making commercial GameBoy games.

A friend starts Ludum Dare. I champion Allegro as a viable tool for rapid development, because my workflow. Easy to make, load, and display assets. I use it for years, most of the early years of LD. It's me and my workflow.

At some point I stop using Allegro. I had worked on nearly a dozen console games, 4 of those in assembly, and I was always the tech lead (doing the low level shite nobody else wanted to). It just doesn't feel right anymore. I'm thinking of high resolutions and bit-depths, file format conversions, PNG files, and whatnot. The Paletted BMP and PCX formats just don't cut it anymore. SDL becomes my new home.

The thing I lost moving to SDL: Fast Raster Performance, and the workflow. The workflow was already gone. I think my mystery Sprite Editor was a DOS DJGPP program, and I was a "Paint Shop Pro" user now. Switching to a fullscreen DOS app really felt clumsy (though it had basic animation support, or rather, a button I could push to toggle frames). It's the mid 2000's, and nobody runs DOS apps anymore.

SDL quickly solved its inadequacies by having native OpenGL support. Suddenly I could do stuff again, faster than ever, with free scaling and rotating support. I still lacked a great workflow for making assets. I had an okay one, painting large images and inputting numbers (regions), but nothing so clean and optimal ever again.

Basically: If Allegro did something with that heritage of being a great sprite library (or even a full workflow), it would still be useful. I don't know what A5 is trying to be. Nostalgic? Newstalgic?

Dennis

Most of the reasons for me to dislike Allegro5(the library) seem to be purely cosmetic and in some cases exist due to outdated memories of problems with the API and WIP versions.

If I look at the latest docs ( http://alleg.sourceforge.net/a5docs/refman/index.html ) I get the impression that most if not everything I would need in simple games and utilities (except some barebones GUI building/running routines) is already there.

Whether the API is optimal and as easily and straightforwardly usable as in A4 is certainly debatable but ignoring cosmetics for a moment, functionality in A5 (just by looking at the docs) does in fact seem very much superior.

What I haven't tested is how much A5 is going to get in the way when I combine it with other stuff. Last time I tried to use OpenGL directly while using only a few of A5s convenience rendering functions (that was a couple of years ago) I remember A5 changing OpenGL settings behind my back (and by that I mean, the docs did not mention any changes to OpenGL rendering behaviour leading to some hard to track rendering bugs).

I think those rendering problems could be history though as I saw some functions in the A5 docs which seem to be capable of re/storing render states so it should be fairly easy now to combine A5 drawing functions with custom OpenGL code/shaders.

It appears to me as if many of the decisions in how to structure the (convoluted looking) API of Allegro5 were based on how the APIs of its dependencies were/are structured and Allegro5 trying to provide an abstraction layer over them which would in extreme cases be usable almost exactly like the API of the respective dependency (that does raise the question though as to where the benefit in using A5 lies in those use-cases, if one could instead just use the crossplatform dependencies directly).

So... it's hard to describe this potential issue, probably it is best describes as a vague "fear/uncertainty" about how much using A5 does impose/force it upon me to stay within the A5 API and use only A5 API calls to do stuff and how much it can be freely combined with more direct access to underlying systems like input/graphics/sound/filesystem/etc or whether straying away from using A5 data structures and functions everywhere is likely to break things as in causing issues with how A5 uses those underlying systems without being specific about certain state changes (as in them being undocumented)...

...so well, there is only one way to find out and that is to go ahead and use A5 in a project.

OICW
bamccaig said:

The aged design of the library combined with the fact that most of our members "grew up" and "got a life" means that we have basically nobody left in the community.

Few weeks ago there was this thread where we tried to remember people from the old days. Sure, lots of people have moved on but some are still here and are working on Allegro because it's their hobby. Nevertheless, the reason why I'm still lurking around and using Allegro library is the community.

I remember few years back when asked why I chose Allegro over SDL for my project. I answered that it's a matter of taste. I've used SDL for some school assignments because the boilerplate code was using it. It seemed reminiscent but I'm familiar with Allegro. Allegro was the first graphics library that I was introduced to so if it hadn't been this way I would have been now posting on some SDL forum probably. Thanks to this I've found a way into this wonderfull community.

Another reason why I'm still using it is the fact that I like the engineering part of game programming - getting the engine together and on top of that the gameplay mechanics. Right now I'd like to embark on creating small turn based strategy. I was thinking about Unity and then I realised that I'd get full blown game engine I'd need to learn and just use it, not to tamper with it. I like to get my hands dirty, I want to learn something. Not just to use some complicated technology of which 70% I won't even utilise. Not to mention that lots of recent Unity games sometimes suffer from occasional performance drops. I mean, I'd rather not finish the game but learn something new in the process.

Sirocco said:

The denial in this thread is nigh legendary.

:) Anyway, to sort of back up your position. Back in the days of Allegro 4 when I was still using Windows I can't remember ever trying to build Allegro because of the dependencies, instead I was using prebuilt binaries. Fast forward, nowdays I'm using Linux and Windows fills the role of a gaming console. When I was porting my projects to Windows I chose again prebuilt binaries of Allegro 5 because I couldn't be bothered with building the damn thing from sources. But I wouldn't blame Allegro for that. Thanks to the cmake the build is super easy, the hard part is setting up the development environment on Windows, setting up cmake and obtaining and building the dependencies.

Edit:

Dennis said:

What I haven't tested is how much A5 is going to get in the way when I combine it with other stuff. Last time I tried to use OpenGL directly while using only a few of A5s convenience rendering functions (that was a couple of years ago) I remember A5 changing OpenGL settings behind my back (and by that I mean, the docs did not mention any changes to OpenGL rendering behaviour leading to some hard to track rendering bugs).

As far as I can remember from my last project - procedural world generator library with demonstration application - it worked nicely. I used Allegro for loading bitmaps and converting them to OpenGL textures and then for setting up the window and handling inputs. I managed all the rendering by myself using Allegro only for rendering fonts and GUI (using Guichan). I never came across problems on this part.

-- end of edit --

Oh and by the way:

bamccaing said:

Even I have a girlfriend, for fucks sake. It's just a matter of time before Hell freezes over and the universe is sucked down a drain. :o

I thought much the same in 2012 :D congratulations, as someone mentioned, we haven't thought it would be possible 8-)

Thomas Fjellstrom

If you use allegro 5's 2d stuff, it does expect to have control of the OpenGL state. The only thing you need to care about is storing current state before changing it, and return the state to how it was before using allegro drawing routines.

I posted a link to some code that I wrote for my minecraft map viewer that I wrote in C++. I save the allegro state (ie: ALLEGRO_STATE) including OpenGL stuff, set up my custom projection transform, draw with GL directly, then restore the old state, and use things like al_draw_bitmap (to show the current texture sheet for debugging), and al_draw_textf (to display current location). It works great. this is the entire contents of my main drawing (not including the direct gl stuff that uses shaders and vbos that assume they have control).

OICW

Tomasu: I believe I have similar code in my project as well :) the only problem I've ever ran into was trying to be smart when accessing private BITMAP data to construct OpenGL cubemap texture :)

Polybios
PoVRAZOR said:

I don't know what A5 is trying to be. Nostalgic? Newstalgic?

Just curious: Did you ever look at / actually use A5?

Dennis said:

there is only one way to find out and that is to go ahead and use A5 in a project.

I'd call this the essence of your post. :P

About OpenGL and A5, as far as I understand it, there are three possibilities: You either leave drawing to A5 or you manage drawing yourself and use A5 only for display creation, input, image/texture loading etc. Or, when you mix the two, you save/restore state for Allegro. That seems rather logical to me.

beoran

PoVRAZOR: Allegro 5 allows you to get the psed of OpenGL for 2d games without needing to learn the complex API. But it works well in concert with opengl as well. Allegro 5 is in essence allegro for the OpenGL age. And yes we support PNG and JPEg now as well. Which goes to show that the reputation of Allegro4 as a dDOS library still haunts us. Maybe we should rename the library after all? Allegretto perhaps :p

As of the popularity of Allegro, 5000 downloads per month isn't bad, but I see a slow but undeniable downwards trend from 2011. I think the lack of recent updates may be responsible for that.

Dennis

The number of downloads per time unit are of fairly insignificant relevance in estimating the popularity of Allegro5 here since there is an undeniable and pretty obvious lack of active projects using it. Or... maybe it's just that the user base decided to develop their stuff in secret or has another community somewhere away from here where they hang out and share all their A5 related stuff but I doubt that as everyone knows, the nicest Allegro community was always here.

Trent Gamblin

FWIW I hear about people using Allegro 5 fairly frequently that do not visit this site.

Polybios

Truth must be that people are actually getting work done on their many amazing A5 projects instead of spamming on the forums. 8-)

Dennis

FWIW I hear about people using Allegro 5 fairly frequently that do not visit this site.

Try to convince them to come here to talk about their projects. It would bring some life to this (half)dead community and might inspire more people to give A5 a fair chance instead of simply not using it because it seems dead, unused and frowned upon in the light of more popular alternatives... well, I know you said you don't give a damn about popularity, but more users could mean more potential devs for the library as well as they find more bugs and could implement more features, so you would not have to stay grumpy over having to do everything yourself.

Sirocco

Cross-posting; sorta.

Quote:

I don't have proper stats (not yet), but you can get rough numbers. Here is August's event (too early for this one, we're only 24 hours in). If you scroll down a little, there's a poorly placed search box. Type a platform/tool name in there, and you'll roughly see how many people are using it. Be warned, it's just a search, so anyone mention a word will also match.

http://ludumdare.com/compo/ludum-dare-30/?action=preview

Not very scientific, but here's rough numbers using that searchbox.

2 - Allegro
4 - Emscripten (C/C++ to JavaScript+HTML)
4 - OpenFL (Haxe with Flash-like API)
11 - PyGame (Python)
16 - Unreal Engine
22 - Python
23 - SDL
27 - OpenGL
24 - Twine (text games, outputs html)
30 - Construct 2 (drag+drop gamedev, outputs HTML)
35 - Haxe (Flash-like, exports to flash, replacing flash)
36 - C++
42 - LibGDX (Java Library, popularized by Notch)
77 - Flash
141 - Java
297 - Unity (Engine with C# scripting)
357 - Web (various)
778 - HTML (various)

The site isn't really set up for that data at the moment, but I had PoV (the guy running Ludum Dare, and former Allegrite) pull some rough-ish stats. Ludum Dare is a pretty damn big phenomenon now and routinely gets upwards of 2K projects each compo. It gives you a large swath of indie and even some pro developers. Allegro isn't making much of a showing, or the developers have taken a vow of silence, etc.

There's no evidence of activity: no one coming to a.cc, hardly anyone asking questions about the lib (even on other forums), and no widely covered or hugely popular A5 projects. I think the lib gets plenty of eyeballs on it, but there are better fits out there for most people.

I'm done here. You can continue doing things the same way and continue sliding into irrelevance, or you can make a change.

jmasterx
Polybios said:

Truth must be that people are actually getting work done on their many amazing A5 projects instead of spamming on the forums. 8-)

Yup, that's exactly what's happening
{"name":"609074","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/7\/b7b3cd5c0d8a4a7da5b317a9424168b3.png","w":1677,"h":1010,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/7\/b7b3cd5c0d8a4a7da5b317a9424168b3"}609074

Trent Gamblin

Doesn't surprise me. SDL is the only one on the list (what is C++ anyway?) that is relevant to what Allegro is. Are you suggesting we make an HTML framework? ;D.

jmasterx

If A5 could somehow work with asm.js I think that would give the library a huge advantage over competitors.

furinkan

As I mentioned a long while ago, I used A5 for a command line utility. It functions beautifully. I'll always come to Allegro with my game needs.

I'm sorry that I haven't had time to contribute! I'm trying not to break while I complete my degree, plan for a wedding, and run my company.

I appreciate every second that has been put into this project by the devs and patchers. This marks about 8 years of enjoyment from this library and community!

Chris Katko
furinkan said:

and run my company.

How's that going? What's the details? Is it (game) programming related?

furinkan

@Chris: Sadly no, it isn't game related. I write software for local companies to get me through school. Since you're doing development too, hit me up on LinkedIn[1] (that goes for everyone)! I described it a little better there.

I'm buying my partner out and reestablishing the company as a worker-owned cooperative. I hope to create an environment where we can pay competitively and where the devs really matter. I believe that having your whole team genuinely care about the company is superior to paying your team to feign caring about the company. I also have no desire to make money off of my peers; I want all my dev friends to profit in proportion to their skill and effort. Worker-owned is the only way to go in my book. ;D

jmasterx

LinkedIn Said:

You and this LinkedIn user don’t know anyone in common

You can only view the profiles of users within your network. However, as you add connections, you may discover people you know in common.

:(

furinkan

Ugh. Dammit LinkedIn! Quit being a douche! What ever happened to forums, where you could talk to people and never even know their names?

Dizzy Egg

My name is Dizzy. I am Egg.

The thing that killed A5 for me was the last Speedhack. It was shoddy, poorly run, no-one was interested, apart from myself and the other contributors (ahem, E'th) I just thought "what's the point".

Leverton didn't seem that arsed, and the 'usual contributors' didn't bother offering much opinion.

So, like, yeah. Up yours. Anyway, more music on the way.

Love you :D

MiquelFire

This been bugging me, why did everyone think it wasn't possible for bamccaing to get a girlfriend?

Dizzy Egg

Because of bam's posts! We all thought.....man....

MiquelFire

I'm going to blame my poor memory, but I don't really remember anything that would make me think that.

LennyLen

I'm going to blame my poor memory, but I don't really remember anything that would make me think that.

While it's probably not intentional, generally whenever he has talked about women in the past he has come off as a crazy misogynistic stalker.

Thomas Fjellstrom
Sirocco said:

I'm done here. You can continue doing things the same way and continue sliding into irrelevance, or you can make a change.

Like what? Create UnityPro? Or maybe turn it into a Javascript only lib? Give us some options. What do you think Allegro should be? And if that is what you want, why haven't you helped drive change?

One thing I think has hurt in the past is the community. It can be abrasive at times. I've heard more than one person complain about it.

furinkan

Like what? Create UnityPro? Or maybe turn it into a Javascript only lib? Give us some options. What do you think Allegro should be? And if that is what you want, why haven't you helped drive change?

One thing I think has hurt in the past is the community. It can be abrasive at times. I've heard more than one person complain about it.

I agree that Allegro must change to survive. Our niche is going away, and we haven't found a new one. We must target a new demographic! 2D games are often considered less impressive than 3D ones by consumers. There are higher level (easier) solutions for n00bs. Most hobbyists build on frameworks using higher level languages than C/C++.

@Sirocco: I disagree that support of a given platform is the responsibility of our (volunteer) maintainers! >:( I don't even have a Windows box, and you'll never get my ass to supply a Windows patch. Sorry, but that's the way volunteers are.

pkrcel
furinkan said:

Ugh. Dammit LinkedIn! Quit being a douche! What ever happened to forums, where you could talk to people and never even know their names?

Just share your public profile instead of your own private, that might allow us to connect.

ANYWAY:
I really don't uderstand the sentiment for which Allegro5 has done something wrong...the wrongness being "not being SDL".

Allegro has unfortunately a small comnunity behind which coincidentally is not extremely productive in terms of game output, but apart from that it still is a low level library, and has a very specific target.

The "game changer" (if ever) could be following Beoran's suggestion about pushung to a more active release cycle (even thou it could impact code stability in terms of API) AND putting up the "nightlies" build server for several platform.

furinkan

@pkrcel: Sigged it. Do connect! My profile is lonely! ;D

I feel like publicizing A5 projects would go a long way. It is hard to say what a library can do until you see what is being built on it. Sadly, we don't have much to publicize at the moment...

Thomas Fjellstrom

Back when the 4.9 wips were going, I convinced people to make more releases, and it DID help. We got more new people, and I think more A4 people migrated as well, and people who felt they needed to go to SDL or something else decided A5 was better.

Trent Gamblin

I convinced people to make more releases

Really?

(rhetorical question, don't answer)

Onewing

If it's any consolation, I love you all, in a totally anonymous way. :-*

Dennis

So... is there an official TODO list anywhere and what do I need to do to get write/commit access to the GIT repository? (I sent a patch to the developer mailing list a few days ago but it seems it is being ignored so I would like to be able to apply patches myself in the future if it is not too much to ask.)

Arthur Kalliokoski

The thing that turns me off in A5 is returning structs for colors (?) instead of simply allocating and initializing an RGBA struct, possibly in global memory. Otherwise it's all good.

beoran

Allegro isn't a Javascript library, and neither is it a 3D library. It's a C library mainly aimed at 2D games on modern systems, although it can be used as the foundation of more complex engines. It's not the old allegro 4 CPU blitting anymore, everything is hardware accelerated. Our 2 main competitors are SDL and SFML.

All other ways to develop games, from unity over click and play to Javascript in a browser are not what Allegro is about or should try to be. Allegro is low level game routines and that is fine. It's true that the general market for game developers has shifted, and nowadays, even people who are not hardcore C programmers can make games with easier to use systems. But that ease of use always comes at the espense of complecity, loss of performance, and the "engine effect" where all game made with engine X look and feel similar to each other. Allegro is for C programmers who want to make their own engine, an easy to port low level abstraction over what the hardware qnd operating system and it's GUI environment provide.

The reason I proposed Github is because I see for other open source projects that it makes it easier to contribute and easier to get into a fast development mode though the pull requests, cloning and merging. Sourceforge is fine for hosting the web page, but I feel it's a much slower, less convenient place to contribute.

This is what I think is the best plan: make it easier to contribute, make releases more often, and make a build server for easier binary releases. Even the linux kernel has dropped the old fashioned "stable and unstable version" release model, I think we should do the same. And all contributors, please go over the road map in the wiki and decide what features are desirable and which ones aren't. And be open to other low level features not mentioned that people are willing to implement and contribute.

Trent Gamblin

Dennis, I've seen your patch. I haven't tested it yet and I haven't ever used the video addon and don't have FFMPEG compiled so I haven't tested it. If I ran Linux I would test and apply it but I fear compiling FFMPEG on Windows is going to be a huge ordeal. I will write down right now that I have to reboot to Linux and test your patch (I'm sure it's fine but I don't commit anything without testing it.)

I can't give you commit access just yet. If you continue providing patches and they are all well and good, eventually you can gain commit access.

Erethar
beoran said:

The reason I proposed Github is because I see for other open source projects that it makes it easier to contribute and easier to get into a fast development mode though the pull requests, cloning and merging.

As someone who only started programming a few years ago, I got my chops in a world where Github is pretty much the de-facto standard.

Sure, when you're working locally with Git it doesn't really matter where the repo is, but I think it would make the project a lot more visible, plus a lot more natural for new contributors to get started.

For one, Git issues would be a much more formalized way to organize bugs and work that needs to be done. It also seems like it would also be easier to fork and manage pull requests, which I think would be cleaner than sending patches or requiring access to the main repo.

Not criticising your current dev flow, just giving my two cents :).

Dennis said:

only had to fix one undeclared symbol due to it having finally been removed from ffmpeg

Are you talking about AVCODEC_MAX_AUDIO_FRAME_SIZE? Just tried to build on Archlinux and ran into that.

Trent Gamblin

Erethar, Dennis' patch was for that. I've attached it. If it works for you I'll apply it.

Erethar

Trent, Dennis' patch fixed the error.

There are still a few warnings from ffmpeg for me though. A number of deprecated fuctions, as well as one implicit declaration:

ffmpeg.c:266:4: warning: implicit declaration of function ‘av_gettime’ [-Wimplicit-function-declaration]

Other than that everything built cleanly and the demos run fine.

Trent Gamblin

Thanks. I'll be applying the patch soon. And thank you Dennis.

furinkan

For what it is worth: GitHub is already integrated into my workflow. When I do get down and dirty (which isn't often), it would be easier on me to submit pull requests there.

My current understanding is that there is a Git mirror of the Sourceforge svn repo. I haven't been on Sourceforge in 4-eva. I use GitHub weekly.

Trent Gamblin

One vote against GitHub here.

(that patch is applied)

furinkan

I haven't contributed to Allegro, so I hope my vote for GitHub will be weighted appropriately. ;)

It is life preventing me from helping out, not Sourceforge. I bet that this is a common situation around here.

SiegeLord

Woah, this is a big thread. Not reading it!

I just sent a nice big patch to the mailing list with compressed texture support for A5... so A5 is not dead, it's just sleeping!

As for github, yes there's a mirror, and yes, we accept pull requests. It's pretty straight-forward to merge them manually (can't use github's UI, since it is a one-way mirror). E.g. for this PR you can just follow the manual directions on that page... or just append a '.diff' to the address (to get https://github.com/liballeg/allegro5/pull/6.diff) and manually apply that. (This specific PR is un-merged since I haven't had time to really look at it).

Thomas Fjellstrom

I will try and up my game when it comes to allegro. Try and help more, especially since I'm using it more :D

In fact, I had an idea while working on some matrix math last night.

Would anyone be interested in adding a few ALLEGRO_TRANSFORM functions, ie:

al_transpose_transform, al_negate_transform, and al_unproject_transform? I specifically needed the last one, and had to figure out how to do it myself (I am really really bad at this "advanced" math, so it took a while and tons of googling, I still don't quite understand it). This is essentially it, it may not be the "correct" way to do it, but it seems to work ok so far.

void Renderer::getWorldPos(Vector3D &pos)
{
  float vec[3] = { camera_transform_.m[3][0], camera_transform_.m[3][1], camera_transform_.m[3][2] };
  
  ALLEGRO_TRANSFORM neg;
  al_copy_transform(&neg, &camera_transform_);
  
  pos.x = -(neg.m[0][0] * vec[0] + neg.m[0][1] * vec[1] + neg.m[0][2] * vec[2]);
  pos.y = -(neg.m[1][0] * vec[0] + neg.m[1][1] * vec[1] + neg.m[1][2] * vec[2]);
  pos.z = -(neg.m[2][0] * vec[0] + neg.m[2][1] * vec[1] + neg.m[2][2] * vec[2]);

}

I imagine the allegro function prototype would look like: void al_unproject_transform(ALLEGRO_TRANSFORM *t, float *x, float *y, float *z);. It just gets the camera location in world coordinates. Much like gluUnProject does.

Basically I think if we added some matrix math operations to the ALLEGRO_TRANSFORM api, it could become much more useful.

pkrcel

One vote against GitHub here.

I'm curious since I have no basis for a preference, might I ask why you oppose Github?

Schyfis

Thought I'd drop in and give my 2 cents. Some of this might sound harsh, but I only have the future of Allegro in mind.

Sirocco said:

Look to the core strengths of Allegro. It was always easy to set up, understand, and get 2D apps knocked out quickly. A lot of people felt that A5 reversed those trends. You had a place in the gaming world and you lost it. Curiously, few things have really moved in to fill the void.

Also, don't totally ignore the Windows branch. No one here wants to hear this but that was a major up. For a long time it wouldn't even build from scratch for most people.

I agree with these points wholeheartedly. I use Windows, and a couple years back I had a very difficult time getting Allegro to play nice.

Allegro's main problem is barrier to entry. Allegro is not easy to set up.

Let that sink in. We should be viewing libGDX as one of Allegro's main competitors, because it absolutely is. Both are tools that help you make games, and both excel at 2D. To not view them as competitors is silly.

LibGDX does a lot of things right and a lot of things wrong, but one of the things it nails is barrier to entry. When I started working with it, it came with a neat little GUI-based project setup wizard that generated Eclipse projects. Easy as that. When I wanted to run a test program on Android, all I had to do was plug my phone in and run it.

I'll admit, expectations like that are unrealistic for Allegro. But it could be significantly easier. Here's my story.
XNA died last year, and Allegro was the first place I looked as an alternative.

After trying to fix basic problems Allegro had on Windows (which is leaps and bounds more than you can expect an average user to do), I tried to get Allegro working with Android. What a mess.

At the time it wasn't even possible to build Allegro for Android on Windows, so I had to fumble around on Linux and even then I couldn't get it to work, even after posting here. If that doesn't scream "high barrier to entry" I don't know what does.

I still don't even know if it's possible to build Allegro for Android on Windows, because I switched to libGDX and barely looked back. About a year later, we released our first game on Windows/Mac/Linux/Android.

What can we do to lessen the barrier to entry? I dunno, I'll leave that to the more capable among us. I just feel like nobody has properly recognized and identified this major problem.

Allegro needs that "it just works" factor.

Thomas Fjellstrom
Schyfis said:

Allegro's main problem is barrier to entry. Allegro is not easy to set up.

It's easier than it was. I agree that it could be easier, but we need people to work on it. It's already plenty easy on linux where I do all of my work (and play).

So far it just seems like very few windows users care enough to help.

Schyfis

Unless something has changed since over a year ago when I struggled to build 5.1.7, then I don't see any improvement... and that was on Linux! If anyone wants to get Allegro working on Android, they face a steep uphill battle.

I'd love to help any way I can. The super technical stuff and inner workings of Allegro are mostly beyond me, so trying to bring the "barrier to entry" issue to your attention is the best I can do right now. I feel like it's an issue that hasn't really had a proper discussion centered around it, even though it's arguably the biggest problem with Allegro.

Thomas Fjellstrom

Last I heard, it is much easier to use the android port. I haven't taken a look at it in a while though.

Schyfis said:

Unless something has changed since over a year ago when I struggled to build 5.1.7, then I don't see any improvement... and that was on Linux!

I'm not sure what you mean. Building on linux is incredibly easy. Install the dependencies using your package manager, and then just compile allegro using cmake. I prefer using ccmake, as it lets you select the options you want to include. After that you install allegro, and use it. What did you have problems with?

I am pretty sure things have gotten easier since 5.1.7 for most ports.

furinkan

If Allegro is to remain relevant we have to revitalize the community on multiple fronts. Failure to revitalize ourselves will result in the eventual death of the project, and with it the community that I adore. Again, I feel bad for not being there for the community that set me on a track to success, but LIFE IS KICKING MY ASS!!!!!!! :o

We need more n00bs, for starters. Most n00bs will have a Windows machine as their primary development machine. We all know that it is easiest to compile for the machine you're on, so Windows support is a must. Not just compiler support, but n00b support! We need a graphic installer, we need to integrate with Code::Blocks and other common beginner tools better. I learned some tricks from some other libraries that may assist us on Windows.

@ML: Our community needs some CSS love. I dig the simplicity of the site, but younger people will think this is antiquated. Its functionality on small screens is also a little frustrating. I can donate time to work on this, and I'm quite familiar with responsive design. Do email me or PM me, and I'll try to figure something out for next year.

We need a secondary team to write a higher level wrapper around A5. Something that can degrade to low level routines if the power is needed, but sufficiently wraps the library in kid gloves. It needs to be powerful enough that we would use it too, otherwise we won't have any good examples. I liked the GLUT comment, and am thinking of the following: KDE to Qt. GNOME3 to GTK+. (Something) to Allegro 5.

Ideas?
Please fork and edit if you have an account:
https://gist.github.com/derrekbertrand/717a4739214a2b3ea288

Perhaps we can organize a little better by transcending the forum.

Polybios
furinkan said:

Our community needs some CSS love. I dig the simplicity of the site, but younger people will think this is antiquated.

allegro.cc is actually not that bad. The official website is way worse. Not only the looks, but also the outdated content (many dead links to Allegro4 tutorials) and general focus on A4. There's been discussion about that already. If I have the time, I'm going to clean it up content-wise after 5.2 is released and if no one else has done it until then.
IIRC, Mark Oates volunteered to contribute a professional redesign when he has time.

Dennis
OICW said:

I used Allegro for loading bitmaps and converting them to OpenGL textures and then for setting up the window and handling inputs. I managed all the rendering by myself using Allegro only for rendering fonts and GUI (using Guichan). I never came across problems on this part.

If you use allegro 5's 2d stuff, it does expect to have control of the OpenGL state. The only thing you need to care about is storing current state before changing it, and return the state to how it was before using allegro drawing routines.

That is good to know and exactly how I expect the state stuff to work from the docs (I hope it really does re/store all of the OpenGL state).

I can't give you commit access just yet. If you continue providing patches and they are all well and good, eventually you can gain commit access.

That would be good. I will only fix stuff which blocks my progress though so... I will only write patches when something does not compile or has bug(s) (or maybe if I think something would be a nice-to-have feature to include in the lib (like the builtin font I supplied in the past) then I will submit that for review and for suggestion to include it (...and then campaign like a month or two while trying hard to stay patient until it finally gets accepted into the lib :D (that might be another "barrier of entry", one for potential contributors, not quite the same as the one described by Schyfis for library users (who could be potential contributors as well though, so yeah, something should be done to lower the barrier of entry for developers and users alike(I think the best approach to that would be via more documentation, like an "Allegro 5 Hackers Guide" which explains library structure and contains hints on where to look when adding/expanding stuff, where to document it, how to write an addon, how the development process in general works, how code gets reviewed/accepted, ...)).

Erethar said:

re you talking about AVCODEC_MAX_AUDIO_FRAME_SIZE? Just tried to build on Archlinux and ran into that.

Yeah that one. (I'm using Arch Linux as well but that problem was not specific to Arch but due to updates to ffmpeg.)

Erethar said:

There are still a few warnings from ffmpeg for me though.

Same here but I never actually used ffmpeg so I did not look any deeper than necessary and only fixed the showstopper compiler error and ignored the warnings for the time being.

Thanks. I'll be applying the patch soon. And thank you Dennis.

Thank you.

furinkan said:

a higher level wrapper around A5. Something that can degrade to low level routines if the power is needed, but sufficiently wraps the library in kid gloves.

That. Unless my memory is failing me, I think A4 did a much better job at that than A5 currently does. It should be done in an addon of course and the low level routines need to stay in the API as well for those of us who need a finer level of control over what's going on. Bonus points (for advanced programmers) if it would be possible to inject ones own versions of code into A5 functionality by setting certain function pointers and then having all A5 functions use those where they would otherwise call another A5 function (something like we already have with al_set_memory_interface for example but basically for "everything" (that would make it possible to port to unsupported platforms without even having to recompile the library itself or also to "hotfix/patch/test" problems/optimizations more easily without modifying the library source itself until tests show the injected piece of code (via function pointer) is superior to the existing code in the lib).

So far it just seems like very few windows users care enough to help.

It seems like Windows is no longer an attractive platform for developers but unfortunately it is still the most widely used platform in desktop computing, so basically every project must at least support Windows in order to not become irrelevant (or convince everyone to switch to a Linux distro which would be more beneficial to the global home computing community as a whole in the long run).

Thomas Fjellstrom

I don't really see how a high level wrapper would help. To be a good api, it would have to abstract all of Allegro away. At that point you might as well use Unity or Quake.

furinkan
Polybios said:

IIRC, Mark Oates volunteered to contribute a professional redesign when he has time.

Good to hear! :D We could use a little TLC.

@Dennis: That's the idea. I feel like A4 was much more n00b friendly and had both advanced and simple interfaces.

Like this in A5:

//I haven't used C in like 4 months, so please be gentle
al_get_joystick_state(&myJoy, &myState);

No return value and I have to pass in a struct to fill out? A good design that helps ensure better memory management! Also VERY confusing to those who don't have a grasp on memory management. We have a beautiful API directed at good programmers, but in order to poll a joystick you need to understand pointers, memory, and that parameters can be outputs. Seems elementary to us, but to a fresh programmer this is pretty steep to check if a button is down on a joystick. ;D

We don't need to write Unity; we just need to take the edge off this API.

Polybios
furinkan said:

//I haven't used C in like 4 months, so please be gentle
al_get_joystick_state(&myJoy, &myState);

You'd probably be using events anyway with A5.
There are enough examples and tutorials can easily be written to explain how to use them.

jmasterx

But if you are a n00b will you remember to do:

al_destroy_joystick_state(myState);
al_destroy_joystick(myJoy);

I would rather get a compiler error about needing to pass the address of my struct than to find out in 3 months that my game is riddled with leaks. After all, it IS C, a systems programming language designed to be a high level abstraction of assembly. If you're going to use C, you will need to learn about pointers sooner or later.

Chris Katko
jmasterx said:

find out in 3 months that my game is riddled with leaks.

Which won't affect the operating system at all when the game closes. :P

Unless you've got a leak in reoccurring object creation functions causing massive RAM theft, that leak isn't going to contribute to anything serious and can be dealt with casually at a later time.

That's not saying it shouldn't be dealt with, but it's certainly not going to harm anything while you put it off.

DanielH

Wanted to add my 2 cents on the subject.

1. Library. I agree that Allegro is not ideal for everyone. It is a low level graphics/gaming library. The lower the level means more work involved, but more control. Yes, we need more noobs, as stated earlier, but the "more work" is daunting.

Reminds me of a time when all I had was BASIC and my brother wanted to learn. He asked me to show him how to "move the guy across the screen." It's not that simple, you have to go crawl before you can walk before you can run. We get these noobs that want to make an RPG when they no nothing about programming.

2. 5 Branch I'm going to show my age, but I've been using Allegro for almost 20 years (1995). I was very put out when I realized that the Allegro 5 branch took over active development. That meant learning a entirely new, almost, library. I say "almost" because the same objects are there, but access to them has changed. At that point, I debated switching to another library or learn Allegro 5. Switching was easier than I thought. I'm either too loyal or too lazy.

At the time, I was working on a platformer. I thought I could teach myself the library while switching the code. There were some changes that had to occur, but these changed weren't difficult. The end result was even better than the original. In the end, I'm glad I switched.

3. Documentation I think that we need more in depth documentation. Some of the explanations of the functions left me scratching my head. Especially int32_t al_ustr_get(const ALLEGRO_USTR *ub, int pos): Return the code point in us beginning at pos. Took me a while to realize that the input was in offsets not actual indexes.

4. Examples/Tutorials Maybe we need more. Not just about using the library, but about using the library while making games with documentation in an easy place to find them. Somewhere on the interweb. Maybe a peer reviewed repository.

5. Allegro Dead? Please say no. I'd have to start over again.

Trent Gamblin

The thing that probably worries me the most is Allegro ever getting out of date. Already on OS X there are a LOT of deprecation warnings. Same could happen with DirectX or any other dependency. It would be nice if we could fix all that. For what it's supposed to do Allegro 5 is already complete enough to do pretty much everything, but I want it to stay that way.

bamccaig

I agree with Dennis' suggestion to have a "Hacker's Guide". That's a very good idea. A defacto standard is a HACKING text file in the root of the project, but that can always refer to an alternative location if preferred (something bundled with the source is ideal).

As for a higher-level interface, I'm not opposed to the idea, but I can also see Thomas' point of view. Unless you define exactly what scope a higher-level interface would look like I can't imagine something getting past the imagination stage.

Trent Gamblin

I think we can dispel the high level interface right away. If someone wants to work on that, that's fine but it shouldn't be part of Allegro. If it can be separated there's no reason to keep them together. We can link to it or promote it to people we deal with but I'm firmly against adding it to Allegro proper. Besides, we can't find people to even work on the low-level interface (and that's not going away.)

EDIT: My reason is this: I've been making games for 20 years, and I know by now that a fantastic engine to one person is a HORRIBLE engine to others, whereas the low level interface doesn't really matter much. Just look at Unity: tonnes of people LOVE it, I would NEVER use it.

bamccaig
furinkan said:

//I haven't used C in like 4 months, so please be gentle
al_get_joystick_state(&myJoy, &myState);

No return value and I have to pass in a struct to fill out? A good design that helps ensure better memory management! Also VERY confusing to those who don't have a grasp on memory management. We have a beautiful API directed at good programmers, but in order to poll a joystick you need to understand pointers, memory, and that parameters can be outputs. Seems elementary to us, but to a fresh programmer this is pretty steep to check if a button is down on a joystick. ;D

We don't need to write Unity; we just need to take the edge off this API.

The event handling is a somewhat advanced topic too for a n00b. A simple wrapper that has its own loop, and allows binding event handlers might be useful. Turn n00b Allegro programs into:

#SelectExpand
1void draw(ALLEGRO_GAME_STATE *, void *); 2void init(void *); 3void logic(ALLEGRO_GAME_STATE *, void *); 4 5// My game state is global cause I'm a n00b. 6 7int main(int argc, char * argv[]) 8{ 9 return al_standard_loop(1024, 768, 30, init, logic, draw); 10} 11 12void draw(ALLEGRO_GAME_STATE * state, void * userdata) 13{ 14 draw_all_the_things(); 15} 16 17void init(void * userdata) 18{ 19 load_bitmaps(); 20} 21 22void logic(ALLEGRO_GAME_STATE * state, void * userdata) 23{ 24 process_time(state->game_time); 25 process_inputs(state->user_input); 26} 27 28...

A simple interface could be hacked into a library relatively easily. Input from members that are actually using it to build games would be good so we don't leave out important things. The main things I can think of for a basic A4 compatible game is knowing user inputs, having a concept of time (and knowing the rate of execution is controlled and fixed), and having a procedure to process the logic of the game (perhaps over a delta of time), and a procedure to draw the state of the game to the screen at the given time.

I can understand Trent not wanting to add to their burden for maintaining such a thing, but it will also confuse matters to call it something else. Either we'd need to provide a separate Web site, forum, etc., to host it and provide support for it, or people would be confused by it having a different name. And also, without having its own site and community, giving it a different name might make it seem like a bad route to take. Whereas I can see such a wrapper being sufficient for most Allegro users! The few that need more power can see the source for the wrapper to see how to do it themselves.

This could be an official add-on. allegro_loop or something. Does anybody see a showstopping limitation to this interface that would prevent making basic 2D games? What is it missing that really matters for most users? I suggest keeping it simple and making it just enough for a n00b to get started quickly. Once they get over the initial hurdle of just drawing something to the screen and moving it we can peel back the curtain and show them how Allegro 5 actually works to accomplish more.

pkrcel

If Mark Oates really proposed to look at the project page design we should REALLY try to bug him into sketching something together.

He is AWFULLY awesome at this kind of design tasks, that would be a definitive step up in visibility.

And PLEASE follow Trent suggestion about the high level interface....are we SERIOUSLY suggesting to ease users (n00b or not) on memory management?

bamccaig

If Mark is MIA at the moment I see no harm in furinkan coming up with something, as long as he realizes it is gratis, and he may have to compete if Mark is secretly locked in a basement working on it. In the meantime, I'd assume that Mark got busy with other stuff and didn't get around to it.

Edgar Reynaldo

I've been working on an intermediate wrapper for Allegro for a while now, in my Eagle library. It's all about making programs easier to write the way we want to write them isn't it? What about code like this for input?

#SelectExpand
1Input quit_key(KB , PRESS , EAGLE_KEY_ESCAPE); 2 3InputGroup secret_key_combo = Input(KB , HELD , EAGLE_KEY_LCTRL) && 4 Input(KB , HELD , EAGLE_KEY_LSHIFT) && 5 Input(KB , PRESS , EAGLE_KEY_BACKSPACE); 6 7do { 8 9 //get event 10 11 HandleInputEvent(ev); 12 13 if (secret_key_combo) {Start();/* okay, let the user play now */} 14 15} while (!quit_key);

Or something like this :

InputAssignment game_inputs;
game_inputs["StartGame"] = secret_key_combo;

/* in loop  */
HandleInputEvent(ev);
if (game_inputs["StartGame"]) {Start();}
/* end loop */

And you can work directly with the key states through shortcut functions as well (these depend on HandleInputEvent too) :

if (kb_press(EAGLE_KEY_ESC)) {game.Quit();}
if (ms_dblclick(LMB)) {game.Start();}

In my looser onion that is way easier than the low level way you would have to do it with allegro. My library does that and so much more, and I would love to have people use and/or contribute to it. I still need atlases, tile maps, and to port my gui, but it can do a lot already. So if anybody wants a higher level library that makes development easier I think Eagle would do it, and I should have some free time this month and a half or so to work on porting more widgets.

The full header InputHandler.hpp is attached. And that's just the input handler! There's a lot more, if you're interested hit up the subversion repo (sorry thats what I'm using atm) url at this website.

http://sourceforge.net/p/eagle5gui/code/HEAD/tree/

Haven't made a commit in a few weeks or so, but I need to solidify something first.

Trent Gamblin

Having higher level libraries is great, a lot of people will prefer to use them so I encourage others to work on and use them if they like. That's not what Allegro is about though. It's just a building block. Use it to build higher level libraries or use it directly in your game or make a custom engine from it. Let's just not force these abstractions on anyone. The existing abstractions are for portability mainly.

OICW

Having higher level libraries is great, a lot of people will prefer to use them so I encourage others to work on and use them if they like. That's not what Allegro is about though. It's just a building block. Use it to build higher level libraries or use it directly in your game or make a custom engine from it. Let's just not force these abstractions on anyone.

I second this. The problem is that the abstraction might not suit your programming style and taste or even your needs. I can't imagine to write good abstraction over the Allegro user events in case of the loop example bamccaig posted. I can imagine something will eventually come out when you actually try to implement something in your own engine and use it for a while, but coming with something from scratch, I don't think it's a good idea, certainly not to be a part of the library.

bamccaig said:

I can understand Trent not wanting to add to their burden for maintaining such a thing, but it will also confuse matters to call it something else. Either we'd need to provide a separate Web site, forum, etc., to host it and provide support for it, or people would be confused by it having a different name.

Few years back I've used OpenLayer for maybe two projects. One never got finished and the other was a Christmas hack entry. The project seems to be dead for quite some time now. It provided some nice C++ abstractions over the Allegro 4.x core plus enabled hardware acceleration using AllegroGL. At the time it was good because AGL wasn't quite friendly to use for my taste. But now, I don't even remember how to compile my projects.

I developed them with Bloodshed Dev-Cpp (another long dead project) on Windows and now I observe that the code rotted quite a lot since then. My point is, let's not jump to make something big that won't get finished and will drain energy from all developers in the process. Abstraction is fine, but I see Allegro as a Lego construction set - you get lot of bricks and what you do with them is entirely up to you. Just as Trent said.

furinkan said:

No return value and I have to pass in a struct to fill out?

I haven't checked the manual but isn't it like most of the allegro function return success/failure/error code as their return value? The options are either this or error codes returned via function parameter or not at all.

Sirocco said:

Also, don't totally ignore the Windows branch. No one here wants to hear this but that was a major up. For a long time it wouldn't even build from scratch for most people.

Shyfis said:

I agree with these points wholeheartedly. I use Windows, and a couple years back I had a very difficult time getting Allegro to play nice.

furinkan said:

I disagree that support of a given platform is the responsibility of our (volunteer) maintainers! >:( I don't even have a Windows box, and you'll never get my ass to supply a Windows patch. Sorry, but that's the way volunteers are.

Well, I know that somewhere up there I said I never had the balls to compile Allegro on Windows and later ditched the platform altogether (save for playing games), but this actually is a problem. I haven't thought about that earlier but as I'm reading the comments on this thread one of the issues that occur to me is that major active Allegro developers are developing on Linux.

Don't get me wrong, I appreciate your work really much - hell, I've never seen more flawless build on Linux than Allegro (and one thing I really don't enjoy is building other people's work) - but I think there's a need for an active dev who'd be using Windows to make sure everything works nice there. Maybe I'm wrong in the sense that all the active devs are Linux based, please correct me. Or maybe I haven't really tried Windows port for quite a while. I really should try to build it.

Trent Gamblin

Windows is supported and as far as I'm aware (after supporting and building it thousands of times) it's not more difficult than Linux save for the lack of a package manager.

EDIT: Oh let me guess, you want us to build a package manager too. :P

furinkan

@Trent: Yes. With nightly automated builds, signed packages, and I want it delivered by next Monday's thread. 8-)

Thomas Fjellstrom

I am still expecting to get the build server done at some point. But it's taken a back seat to things like getting married, and the fact that the server is half a world away, the latency is horrible (even over ssh), and the fact that that box has shorewall enabled, and some idiot forgot to ALLOW(SSH). What a dumbnut.

Aikei_c
OICW said:

I developed them with Bloodshed Dev-Cpp (another long dead project)

Actually, there is a fork which lives up to this day

OICW

Windows is supported and as far as I'm aware (after supporting and building it thousands of times) it's not more difficult than Linux save for the lack of a package manager.

I guess that the lack of package manager and standard lib and include paths is the main problem that bugs me everytime I'm forced to develop on Windows. Sooner or later I get the feeling that everything is messy and needs cleaning up - library here, library there, compilers everywhere. Like I said, I'd better go and try to build Allegro 5 on Windows to see what it's like, it's probably just me and my aversion to anything development related on Windows :-/

Trent Gamblin said:

EDIT: Oh let me guess, you want us to build a package manager too. :P

Well, if you'd be so kind :D Reminds me how I needed to pack and ship all the libraries with my project because the supervisor wasn't really into the idea that it's the responsibility of the person who wants to build the project to obtain the prerequisities.

Aikei_c said:

Actually, there is a fork which lives up to this day

Sweet, although i bit late. In the meantime I found Code::Blocks which worked well on Linux as well. Though, lately I have found that QtCreator might suit me better. I'm still undecided which way to go.

Thomas Fjellstrom

If you grab msys2 you get a nice dev package manager :D though it doesn't handle msvc.

Paul whoknows

I only use Windows OSes ;) I use the A5 devpack for Dev-C++, it takes only a few minutes to install, not using A5 seriously so I don't know if these devpacks are up to date.

Here are the devpacks I'm talking about:

http://devpaks.org/category.php?category=Allegro

l j

I had no idea those devpaks were still being made. Those are certainly far more user-friendly than downloading the library files and manually linking them. Might also scare newbies less.

furinkan

That's another thing. If there was no Dev-Pak, then it was a huge mess to work on windows. The clutter confused my then-n00b self. Managing my libraries by hand could end up quite messy after awhile, and I often deleted my whole toolchain and re-installed as a way to cope. There's so many binaries for Windows. Which one do I need, and which toolchain is the best? "Whatever you want" is the answer for experienced devs, but that will not suffice for n00bs. It causes confusion. They can barely grasp what a toolchain is, so don't tell them to use their own judgement!

Our library is designed to allow you to program using whatever models you prefer. We offer multiple interfaces for the same thing, often with override-able functionality. Pointers are used profusely to allow custom management of structs in memory. Hell, even memory management functions are customizable!

This is not a library for n00bs anymore. This is a library aimed at serious performance, for engines or ballz-fast games!

We need more users to remain viable. n00bs or 1337s? Which is it, because our branding says one thing and our library/community is another? ???

Arthur Kalliokoski

The n00bs can always get DarkBasic.

furinkan

They can cut their junk off with a plastic spoon, too, but we don't suggest that they do it! >:(

Matthew Leverton

To me, it's always been more about the community than the bits of software. Allegro is "dead" only because the people who built it grew up. :'(

But with respect to the software, a problem has always been that by the time the library is ready, a new generation of computing has arrived. Allegro: Atari Low-Level Game Routines. Whoops, got to rewrite it for DOS. Oh, here comes Windows. Got to get it working on Windows. DirectX is no more, needs to be Direct3D. The old API doesn't work well with this. Got to make Allegro 5. Oh, the Internet is here. Flash games. Got to make it work in a browser. Phones... iOS, Android!

The reality is that there is very little use for a library like Allegro, especially if it doesn't work perfectly on Windows, OS X, iPhone, and Android. (I'm sorry, but people still don't care about Linux, even as I type this on my Mint Ubuntu VM running inside XUbuntu.) Putting a little lipstick on the marketing side of things, writing great docs, revamping Allegro.cc into a modern cute website, switching to GitHub... e.g., cater to the people who were born after Allegro.cc was created... then there will be a little uptick in usage.

And good for those new converts, but it still isn't going to bring back RHIDE. :'(

bamccaig

/me bows to our wise, all-knowing, all-seeing leader! /o\

Chris Katko

Got to make Allegro 5. Oh, the Internet is here. Flash games. Got to make it work in a browser. Phones... iOS, Android!

Let them keep their damned rehash games. And if the quality wasn't bad enough, the market is trash. 99% of the mobile market is either advertising supported, or part of a companies advertising (download the new Sony/Pizza Hut/Durex app!) so the going price for mobile video games is... effectively $0. I for one and not going to work on a game that generates a mere $2,000 a year. That's pathetic and unacceptable for a serious professional.

Just because Joe Sixpack doesn't mind playing games ripping off the mechanics of popular games from the 80's/90's but with prettier vector graphics, on a tiny screen, with a crappy speaker, and filled with advertising popups... doesn't mean I don't mind. And if I exist, there are thousands like me who will play my games.

Steam is living proof that the PC still rules, and there are plenty of successful, original indie games on Steam. Be it 4x4 off-road simulators with realistic deformable mud physics, space simulation, turn-based/real-time space rogue likes, and more.

Hell, Space Station 13 is a free game, on a extremely crappy underlying engine (designed originally for online JRPGs) It makes zero money except for server donations, and yet gets expanded by multiple groups. It still pulls an audience of 200-400 (often 400 every night.) a good ten years since the game was originally created. Multiple groups are now moving to capitalize on a spiritual successor to the core mechanics that keep bringing people back.

Humble Bundle may now offer mobile versions, but it wouldn't exist today if it hadn't become so popular selling good PC games.

I think the money is there if you're willing to grab it. I don't see Allegro as a problem with that. Allegro may have its annoying moments, but it's a tiny fraction compared to the libraries I have to interface to on a daily basis for work. The popularity of PC games in media outlets is at a low, but the gamers are still there as eager as ever.

Paul whoknows
furinkan said:

This is not a library for n00bs anymore. This is a library aimed at serious performance, for engines or ballz-fast games!

I've always thought that blaming the users is a cheap way out, it makes you look so unprofessional, I would never hire a person with such an attitude.

Arthur Kalliokoski
furinkan said:

This is not a library for n00bs anymore.

I believe the problem is terse, incomplete docs. I've <ahem>"acquired" most of the OpenGL Superbible books, which are much more conversational than the A5 docs and examples, and even they don't hold up when you actually go to compile the programs and try to understand what's going on. VBO examples only using points, necessary support functions hidden away in header files in another directory, etc. They're nice to just read and ooh and ahh over though.

I especially hated the source of one of those Superbible books (4th edition?), there was a horrible script masquerading as a makefile at the top of the source tree which forked off a whole bunch of crap that didn't work, it took up 4Gb of memory before I managed to kill it.

Thomas Fjellstrom

I've said it before, and I'll say it again. We need help. The few of us left don't have the time, or will to keep allegro fresh.

Help is needed in all parts, docs, linux, windows, osx, android, ios, etc. ALL THE THINGS.

furinkan

I've always thought that blaming the users is a cheap way out, it makes you look so unprofessional, I would never hire a person with such an attitude.

Easy, killer! I'm not blaming anyone; I'm saying our projected status as a library/community is disjoint from where we need to be. We need to cater to newbies and rope them in, or start to be up front about just how bleeding edge our library actually is. I think there's a lot here for serious developers, and we don't show that with our anthropomorphic cartoon alligator. ;D

To me, it's always been more about the community than the bits of software.

Quote:

ALL THE THINGS.

Agreed. I'll start by reinvesting myself in the community. Try to read more of the threads, and stir stuff up. When free time comes, I'll be more invested in this than other things.

Thomas Fjellstrom

I just learnt about a thing called NuGet. A dev package manager for msvc? That might be something we want to support if it works for c/c++ packages.

Dennis

Help is needed in all parts, docs, linux, windows, osx, android, ios, etc. ALL THE THINGS.

That is a little vague. It would help if there was an official detailed TODO list and to get contributors started, a hackers guide would be a priority on that list.

Thomas Fjellstrom

A hackers guide would be good. Just more we need help with. The wiki could use more tutorials too.

I believe there's an unofficial todo on the wiki and one in the source?

Arthur Kalliokoski

About all I could do is blog about my slow muddling through it, trying to get it to work.

Edgar Reynaldo

Grepping for todo is epic fail.

c:\mingw\LIBS\A5GIT\allegro>grep -r -E -I -n "todo" .\*.*
.\demos/speed/speed.txt:137:Still todo: more interesting enemy movememnt, you dying.

c:\mingw\LIBS\A5GIT\allegro>

Seriously, things that need to be done in the code should be marked with a TODO somewhere or be on an official list somewhere.

Arthur Kalliokoski

That '-I' parameter to grep should be lowercase to specify "ignore case"

CMakeLists.txt:# TODO:
README_android.txt:TODO
addons/video/ogv.c: * TODO:
addons/video/ffmpeg.c:/* TODO: Thsi is just a quick ffmpeg video player test. Eventually this
addons/video/ffmpeg.c: * TODO: al_get_audio_stream_fragments actually might be useful for
addons/image/macosx.m:   // TODO: We should check it really is a bitmap representation.
addons/image/macosx.m:      // TODO: Read from stream until we have the whole image
addons/image/png.c:   // TODO: can this be different from rowbytes?
addons/image/iphone.m:      // TODO: Read from stream until we have the whole image
addons/audio/alsa.c:         al_rest(0.005); /* TODO: Why not use an event or condition variable? */
addons/audio/alsa.c:   // TODO: Setting this to 256 causes (extreme, about than 10 seconds)
addons/audio/pulseaudio.c:    * TODO: Maybe we should have a force flag to the audio driver
addons/audio/opensl.c:/* TODO:
addons/audio/opensl.c:    /* TODO: review the channelMasks */
addons/audio/opensl.c:    /* TODO */
addons/audio/opensl.c:    /* TODO */
addons/audio/openal.c:/* TODO: make these configurable */
addons/audio/openal.c:/* TODO: review */
addons/audio/openal.c:/* TODO: review */
addons/audio/dsound.cpp:/* TODO: review */
addons/acodec/flac.c:   /* TODO: test this array flattening process on 5.1 and higher flac files */
addons/primitives/triangulator.c:            // TODO: optimize this by removing if
addons/primitives/line_soft.c:   TODO: Need to clip them first, make a copy of the vertices first then
addons/primitives/line_soft.c:   TODO: This bit is temporary, the min max's will be guaranteed to be within the bitmap
addons/primitives/primitives.c:    * TODO: Somehow free the d3d_decl
addons/primitives/high_primitives.c:   TODO: Doing this as a triangle fan just doesn't sound all that great, perhaps shuffle the vertices somehow to at least make it a strip
android/allegro_activity/src/Key.java:   static final int ALLEGRO_KEY_SEMICOLON2  = 105;   /* MacOS X -- TODO: ask lillo what this should be */
cmake/Toolchain-android.cmake:#there may be a way to make cmake deduce these TODO deduce the rest of the tools
cmake/Toolchain-android.cmake:#for some reason this is needed? TODO figure out why...
cmake/AllegroFindFFMPEG.cmake:# TODO: Windos and OSX
demos/speed/speed.txt:Still todo: more interesting enemy movememnt, you dying.
docs/scripts/make_protos.c:      /* TODO: Should the above regexp match it? If so it doesn't here... */
docs/man/al_attach_shader_source.3:TODO: Is ALLEGRO_PROGRAMMABLE_PIPELINE set automatically in this case?
docs/html/refman/shader.html:<p>TODO: Is ALLEGRO_PROGRAMMABLE_PIPELINE set automatically in this case?</p>
docs/src/refman/latex.template:% TODO: I don't like the sans serif fonts much.
docs/src/refman/shader.txt:TODO: Is ALLEGRO_PROGRAMMABLE_PIPELINE set automatically in this case?
examples/ex_utf8.c:/* TODO: we should also be checking on inputs with surrogate characters
include/allegro5/keycodes.h:   ALLEGRO_KEY_SEMICOLON2	= 105,	/* MacOS X -- TODO: ask lillo what this should be */
include/allegro5/platform/aintunix.h:/* TODO: integrate this above */
include/allegro5/platform/albcc32.h:   /* TODO: check if BCC has inttypes.h and/or stdint.h */
include/allegro5/keyboard.h:/* TODO: use the config system */
misc/gcc-uni.sh:# TODO: use trap to cleanup
src/x/xmousenu.c:   /* TODO: is there a way to detect whether z/w axis actually exist? */
src/x/xmousenu.c:   event.mouse.pressure = 0.0; /* TODO */
src/x/xdisplay.c:    * TODO: Find out details?
src/x/xglx_config.c:         /* TODO: Right now Allegro's own OpenGL driver only works with a 3.0+
src/x/xkeyboard.c:/* TODO: is this needed?
src/win/d3d_render_state.cpp:   /* TODO: We could store the previous state and/or mark updated states to
src/win/wmouse.c:   event.mouse.pressure = 0.0; /* TODO */
src/win/wgl_disp.c:      /* TODO: we could use the context sharing feature */
src/win/d3d_display_formats.cpp:                  // TODO: Is it ok to use the quality level here?
src/android/android_mouse.c:      event.mouse.dx = 0; // TODO
src/android/android_mouse.c:      event.mouse.dy = 0; // TODO
src/android/android_mouse.c:      event.mouse.dz = 0; // TODO
src/android/android_mouse.c:      event.mouse.dw = 0; // TODO
src/android/android_mouse.c:      event.mouse.pressure = 0.0; // TODO
src/android/android_system.c:   /* TODO: add the non native activity driver */
src/opengl/ogl_bitmap.c:// TODO: To support anisotropy, we would need an API for it. Something
src/opengl/extensions.c:    /* TODO: use these somewhere */
src/opengl/extensions.c:      /* TODO: use these somewhere */
src/opengl/ogl_render_state.c:   /* TODO: We could store the previous state and/or mark updated states to
src/keybdnu.c:/* TODO: use the config system for these */
src/iphone/iphone_mouse.m:      event.mouse.dx = 0; // TODO
src/iphone/iphone_mouse.m:      event.mouse.dy = 0; // TODO
src/iphone/iphone_mouse.m:      event.mouse.dz = 0; // TODO
src/iphone/iphone_mouse.m:      event.mouse.dw = 0; // TODO
src/iphone/iphone_mouse.m:      event.mouse.pressure = 0.0; // TODO
src/iphone/iphone_joystick.m:    // TODO: What's a good frequency to use here?
src/iphone/EAGLView.m:   // TODO: handle double-clicks (send two events?)
src/iphone/iphone_display.m:      // TODO
src/tri_soft.c:   TODO: Need to clip them first, make a copy of the vertices first then
src/tri_soft.c:   TODO: This bit is temporary, the min max's will be guaranteed to be within the bitmap
src/linux/lmseev.c: *  TODO: missing handle_axis_event calls
src/linux/lmseev.c:   event.mouse.pressure = 0.0; /* TODO */
src/linux/lkeybdnu.c: *      TODO: diacriticals
src/system.c:    * TODO: Maybe we want to do the check after the "bootstrap" system
src/display.c:      /* TODO:
src/macosx/hidjoy-10.4.m: * TODO this only works for simple joysticks and

bamccaig

NuGet isn't all that awesome. It's nothing like package managers as *nix users understand them. It's more or less just an "app store" for Visual Studio add-ons. I don't think it would be a good way to distribute Allegro (for one, you'd still have to build all of the dependencies and bundle them inside it, unless you want to create and maintain different packages for each dependency). MSYS2 is probably a better solution to that problem, but I haven't tried it yet.

Edgar Reynaldo

That '-I' parameter to grep should be lowercase to specify "ignore case"

Oh, I was thinking that -I meant "ignore binary". Oops.

Arvidsson

I have created an Xcode project template: https://github.com/arvidsson/Allegro-Xcode-Project-Template

I created this a few years ago but got no response. It seems to still work with Xcode 6 and Yosemite. I copied a lot of stuff from how SFML did their project template. I put it on my github again - feel free to test if you have a mac!

jhuuskon

I still haven't forgiven MS for giving up on XNA.

jmasterx

I have created an Xcode project template: https://github.com/arvidsson/Allegro-Xcode-Project-Template

I created this a few years ago but got no response. It seems to still work with Xcode 6 and Yosemite. I copied a lot of stuff from how SFML did their project template. I put it on my github again - feel free to test if you have a mac!

That's really great. It would be great if 5.1.9/5.2.0 came out because then this could be modified to be both an osx and an ios template.

I installed Unity the other day to see how easy it is to port.

When you use Unity, it's so easy to take your project and have it generate an XCode project with all the libraries and frameworks all nice and linked up.

It would be great if somehow Allegro could have this too. We need more automation. I really wish I had a clue on how to do something like that because that's something I would be very interested in contributing to.

We need to automate building somehow, but after that, we really need to make it easier to deploy. I have been working on a project for over 4 years and have only ever used it on Windows because I can't figure out how I would keep my MSVC, XCode, Eclipse etc projects synchronized. That's a big edge that Unity has that I think a library like Allegro should have.

Thomas Fjellstrom
bamccaig said:

MSYS2 is probably a better solution to that problem, but I haven't tried it yet.

Only for those that use gnu toolchains, many on windows use VS, and probably aren't going to change just to use allegro. Like it or not, both windows and VS are something we must support.

StevenVI
jhuuskon said:

I still haven't forgiven MS for giving up on XNA.

That's kind of how MS operates. Make something today, deprecate it tomorrow.

I stopped concerning myself with learning their APIs after they deprecated Managed DirectX. The target moves too fast for me. :P

Trent Gamblin
StevenVI said:

That's kind of how MS operates. Make something today, deprecate it tomorrow.

I wouldn't call that a pattern with Microsoft whatsoever. Windows 3.1 apps still run on Windows 10. :P

Chris Katko

I wouldn't call that a pattern with Microsoft whatsoever. Windows 3.1 apps still run on Windows 10. :P

Oh really???

Edgar Reynaldo

Oh, I was thinking that -I meant "ignore binary". Oops.

Okay, so I did it right, and tried to pipe grep's output to a file :

grep -r -E -i -n todo .*.* > TODO.txt

And it just kept running and running. Eventually I got a disk space is full message and I had to kill grep and delete the text file, which had grown to 50GB!!! I tried updating grep and doing it again, and I killed it when the file reached 1.8GB. :P Can anybody verify this behavior on Linux? I might file a bug report. I can verify the output without piping it to a file is correct, and looks like Arthur's.

Arvidsson said:

I have created an Xcode project template: https://github.com/arvidsson/Allegro-Xcode-Project-Template

I created this a few years ago but got no response. It seems to still work with Xcode 6 and Yosemite. I copied a lot of stuff from how SFML did their project template. I put it on my github again - feel free to test if you have a mac!

That's great! Thanks arviddson! If I was on OSX I'd probably be using it. You should submit a patch to the mailing list. That seems like the best way to get changes added to allegro.

I think it would be great if we could have pre-built projects to get people started with allegro, like a solution for MSVC, a project for CB, and whatever else people use. If it's not too hard I could make a CB project template for building allegro projects. I'm not sure what is involved or whether I could just create a generic project.

Edit
Perhaps add a project directory to allegro's source distribution? With subdirectories for each project type.

Aikei_c

I just learnt about a thing called NuGet.

Never used it before, but I've just been able to install latest boost binaries seamlessy with NuGet. Allegro should be harder to install since it has a bunch of dependencies, but it seems doable.

Trent Gamblin

Oh really???

Yes really. That link is irrelevant to what we're talking about (XNA, Managed DirectX, ...)

EDIT: Ok, MS does stop working on some things, but they always maintain backwards compatibility far beyond their competitors.

Dennis

grep -r -E -i -n todo .*.* > TODO.txt
And it just kept running and running. Eventually I got a disk space is full message and I had to kill grep and delete the text file, which had grown to 50GB!!! I tried updating grep and doing it again, and I killed it when the file reached 1.8GB. :P Can anybody verify this behavior on Linux? I might file a bug report. I can verify the output without piping it to a file is correct, and looks like Arthur's.

I bet the file growth is exponential and I bet it's because after it is finished writing all the TODO to TODO.txt it notices that TODO.txt was created/has changed and parses it again, adding all the TODO from TODO.txt again to TODO.txt, notices that TODO.txt has changed and parses it again, adding all the... you get the idea.

Changing the output to ../TODO.txt should prevent it if it is that.

Trent Gamblin

What are all those flags for? Just grep -ri todo . will work. :P

Edgar Reynaldo

Ah, that was it. Thanks Dennis! :)

Although it still seems like a bug, recursively searching the file that you are creating and then adding to it and then searching it again, and then adding to it... even if it is in the search directory.

Edit for Trent
-r is for recursive search
-E is for regular expression (not used this time)
-i is for ignore case
-n is for displaying the line number.

:P

Trent Gamblin

I thought maybe one of the flags enabled that. That is kind of weird.

bamccaig

Although it still seems like a bug, recursively searching the file that you are creating and then adding to it and then searching it again, and then adding to it... even if it is in the search directory.

It's not a bug. You're just doing it wrong. grep(1) has no idea that you're writing TODO.txt. Your shell opens a file handle for "TODO.txt", and binds grep(1)'s stdout file handle to it. grep(1) is still just writing to stdout. There are various --exclude options to prevent that, or you can do as Dennis suggested and write that file to a path that isn't being scanned.

grep(1) never searches the file again. It never gets to stop because every time it writes something to TODO.txt the file gets larger, guaranteeing that the next read operation will succeed with more data. It isn't until the file system fills up and the write operation fails that grep(1) finally signals an error and exits.

bash(1) appears to glob the arguments to grep(1) before opening the TODO.txt file so as long as that file doesn't exist before you start that should also suffice. If you ever try again without cleaning up the original file you will again find yourself re-cursing indefinitely. The power of this is one of the many things that make stdio great.

There is no bug. There is only PEBKAC.

Edgar Reynaldo

Yes, it really is a bug. You shouldn't be recursively searching the file that you are creating. It happens even when the file doesn't exist, which shows that it is actively re-reading the file. I would definitely call that a bug, as it should only read the files that were passed to it, of which TODO.txt was not passed to it because it didn't exist.

What the hell does pebkac mean? Oh, thanks urban dictionary. :P

More like Problem Exists Between Intent and Implementation. Of course you wouldn't want to search the file you are writing for occurrences of the word you are searching for as they are written to the same file. PEBKAC my ass. grep should use a list of the files that existed at the time it was created called, not files that were created during execution. :P :P :P :P :P

bamccaig

Yes, it really is a bug. You shouldn't be recursively searching the file that you are creating. It happens even when the file doesn't exist, which shows that it is actively re-reading the file. I would definitely call that a bug, as it should only read the files that were passed to it, of which TODO.txt was not passed to it because it didn't exist.

What the hell does pebkac mean? Oh, thanks urban dictionary. :P

More like Problem Exists Between Intent and Implementation. Of course you wouldn't want to search the file you are writing for occurrences of the word you are searching for as they are written to the same file. PEBKAC my ass. grep should use a list of the files that existed at the time it was created, not files that were created during execution. :P :P :P :P :P

If you want to unravel the mystery add echo before the command to expand it for you. Your shell should be globbing for you. grep(1) has no idea that you said .*.*. All it sees is . .. foo.txt bar.txt ...etc.... Again, grep(1) has absolutely no idea which file the shell told it to write to. It is exactly as I said, PEBKAC. In fact, it doesn't even have to be a file on disk. It can be anything a file handle can refer to. It could be an IP socket, a UNIX socket, a pipe, or even a device. To *nix systems the differences are transparent to the API. Though in some cases you can try to figure it out by going above and beyond and using platform specifics, but in this case I don't even think grep(1) can identify the file system path. A file handle generally refers to an inode, not a file path. *nix systems resolve names into inodes. That allows you to unlink (i.e., "delete") the named file while another program has a handle to it and is reading or writing to it. I don't think there's even a way to ask the kernel "which inode is this?" because again it isn't guaranteed to be one. And even if it could, an inode can have many names (i.e., paths in the file system) referring to it. In any case, it goes above and beyond the scope of grep(1) to be that extra curricular. It's generally up to the user to make reasonable requests (special files can read different than what was written to them).

Edgar Reynaldo

And guess what .\*.* expands to when TODO.txt doesn't exist? It is reading a file that doesn't exist at the time of execution, which is a bug as far as I am concerned, especially when it searches the file it is writing for the things it is writing. F'in dumb if you ask me. In what case would that ever be desirable behaviour? It's the fault of the developers to put in a 'feature' that is not one. We've taken this too OT already, so if you wanna prove your case we can argue on IRC or something. :P

And if you don't remember, echo doesnt' work with globs on Windows. It just dumbly echos out what you typed in.

In an effort to get back on topic, about a hacker's guide for Allegro. Has anything changed since Allegro 4 in terms of hacking guidelines? Because allegro 4 has a hacker's guide.

Copy of Allegro 4 Hacker's guide

Trent Gamblin

Globs are not expanded by the shell on Windows, they're expanded by the program/runtime, so that explains that.

bamccaig

Oh, sorry, I didn't realize that Edgar was running this in Windows. Thank you, Trent. Yes, report that bug to Microsoft. It's their bug. The MSYS developers had to hack their utilities to do the globbing themselves because the Windows command shell doesn't. So the shell would create the TODO.txt file and literally send ".*.*" to MSYS grep. MSYS grep then would do the globbing because Windows is too stupid to, and would find TODO.txt in the process since the shell had already created it. Again, grep(1) doesn't know that it is writing to TODO.txt, and Windows even less likely to make it possible for it to find out (not that it's even responsible for such a thing). grep(1) has no bug in this case, except for the globbing which is a workaround for the bug in Windows.

Edgar Reynaldo

I just looked at the Allegro Hacker's Guide more in depth, and it is totally dated to A4. Perhaps we could create a new one?

Also, I am starting a page on the wiki on Contributing to Allegro. It just has the recently grepped TODO list on it right now, but feel free to add to it. It also has a link to the A5 roadmap for what its worth.

Also, what about having an Allegro Hack Day? There hasn't been one since 2008! :o You know you want to!

Re: grep

I'm running the gnuwin32 versions of the tools btw.

Hate to bother you, but this :

Globbing.cpp#SelectExpand
1 2#include <cstdio> 3 4int main(int argc, char** argv) { 5 for (int i = 0 ; i < argc ; ++i) { 6 printf("Arg %d = '%s'\n" , i , argv[i]); 7 } 8 printf("\n"); 9 return 0; 10}

does this when run :

c:\...\page_table>mingw32-g++ -Wall -o Globbing.exe Globbing.cpp

c:\...\page_table>Globbing.exe .\*.*
Arg 0 = 'Globbing.exe'
Arg 1 = '.\Globbing.cpp'
Arg 2 = '.\Globbing.exe'
Arg 3 = '.\pagedebug.exe'
...
Arg 13 = '.\Utility.hpp'

c:\...\page_table>

So it isn't the program expanding the glob. It is either the shell or the mingw runtime.

Let's try an experiment.

(Globbing.txt does not exist yet)

c:\...\page_table>Globbing.exe .*.* > Globbing.txt

c:\...\page_table>type Globbing.txt
Arg 0 = 'Globbing.exe'
Arg 1 = '.\Globbing.cpp'
Arg 2 = '.\Globbing.exe'
Arg 3 = '.\Globbing.txt'
Arg 4 = '.\pagedebug.exe'
...
Arg 14 = '.\Utility.hpp'

c:\...\page_table>

So the file handle is created before the program is run, and then passed to the program as stdout. And since the file is already there, the globbing run by the shell or runtime sees Globbing.txt and happily passes it to the program.

I guess that's another bug in the cmd shell. But, is it still grep's fault? What if you open a write file handle and then try to open a read handle on the same file? What happens? Let's find out.

If you try to open a FILE handle in "w" mode to a file that is being piped to by the shell, it fails on Vista with MinGW 4.8.1 at least. If you try it in "rw" mode it succeeds but reads and writes to the file silently fail. If you try it in "r" mode it succeeds but reads fail. I tried it. If you try to open a read handle to the file being piped to it never reads input and fgetc returns EOF right away.

What's my point? If grep is opening the TODO.txt file in read-write or read mode at the same time as it is being piped to then all reads should be failing and their file "w" handle should be null too. I can't explain why they're not. How are they able to open the file and successfully read and write to it (recursively no less) if MinGW can't?

Edit
There is another wiki page similar to the one I just made, Allegro development. How about we merge the two? I put in some more details that might be helpful.

bamccaig

Perhaps we should note that just because somebody writes "TODO" in source code does not mean that what they describe is correct. It just means that they felt their solution was incomplete and that more attention may be needed to make things work their best. If the change is non-trivial you should discuss it on the mailing list first.

Re: grep(1)

The idea of exclusively locking files is more of a DOS/Windows-ism. In the *nix world, unless you go to lengths to lock the file, another process is free to read from it, and possibly to also write to it. I suspect that the UNIX software does its best to work this way despite the limitations and design flaws of Windows. That said, allegedly cmd.exe opens files for redirection exclusively, which might explain the behavior that you see, but doesn't explain how grep(1) is able to access the file then. Of course, I'd still say the bug is in Windows. Not only is it stupid for cmd.exe to ask for exclusive access, but it's the Windows kernel that is presumably letting grep(1) bypass that somehow. I suppose the only way to know would be opening up the MinGW grep source code.

Dennis

Sooooo... what's up?

LennyLen
Dennis said:

Sooooo... what's up?

Anything that's not down.

Erin Maus

I still use Allegro! In C#. Well, kind of. I use it for everything but drawing.

Because I wrote a resolution independent curve renderer and it requires a few more modern features than Allegro exposes...

But it works pretty nicely.

Here is the test image in InkScape:

{"name":"609093","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/4\/2446b0f1addd28d971f667a615ebd98c.png","w":1280,"h":720,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/4\/2446b0f1addd28d971f667a615ebd98c"}609093

And here it is in my C# 'Canvas API':

{"name":"609094","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/3\/a3928f307e014663100690114ecbdfae.png","w":1280,"h":720,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/3\/a3928f307e014663100690114ecbdfae"}609094

Preeeetty nifty.

Thomas Fjellstrom

I wrote a resolution independent curve renderer and it requires a few more modern features than Allegro exposes...

Like what exactly?

Erin Maus

Like what exactly?

Well, I use forward compatible OpenGL 3 context. I use the stencil buffer and various depth buffer sorting modes, things that aren't exposed by Allegro. I also use OpenGL 3.0 GLSL shaders (well that's kind of obvious) because I fetch noninterpolated texels so I can batch the geometry into as few draw calls as possible.

To clarify, I'm not rendering raster images. In one draw call, I render that entire scene, with the proper depths to ensure order independent translucency (stored in a R32 texture) and colors (stored in a simple RGBA8 texture). With my curve rendering, I can zoom in... as far as I want...

{"name":"609095","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/7\/9747b836629e957b2be798050d3aac8f.png","w":1280,"h":720,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/7\/9747b836629e957b2be798050d3aac8f"}609095

Chris Katko

Dude, you're my hero. :o

bamccaig

^ This. That looks damn cool. Remember:

{"name":"f3e0a39eca9ed9f234ed2a48a0736d200daaa01d4a49e4c1dd9a853c61f4f7cf.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/5\/b5864abd6315feb995ec326732d6e2e5.jpg","w":445,"h":280,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/5\/b5864abd6315feb995ec326732d6e2e5"}f3e0a39eca9ed9f234ed2a48a0736d200daaa01d4a49e4c1dd9a853c61f4f7cf.jpg

Onewing

Well, I use forward compatible OpenGL 3 context. I use the stencil buffer and various depth buffer sorting modes, things that aren't exposed by Allegro. I also use OpenGL 3.0 GLSL shaders (well that's kind of obvious) because I fetch noninterpolated texels so I can batch the geometry into as few draw calls as possible.

I am going to memorize this word for word and then drop it on a non-tech client (add a scoff to "well that's kind of obvious") whenever they make a "small" front end change request. :)

Thomas Fjellstrom

Well, I can say that we do support OpenGL3, not entirely sure if its a forward compatible context or not, but I'm actually using GL3 in my little personal project. Stencil support is something I think we should add. And depth buffer modes sounds like it should just be a display or bitmap option, and shouldn't be too hard to add. If you're interested, one or more of the dev's would be happy to assist you in adding these features.

I already blast all kinds of data at the GPU at once via VBOs and do all my actual "rendering" in a shader (super simple at the moment, but it'll probably need to do some more advanced shenanigans later on).

furinkan

That's super cool, dude!

And I think Allegro makes a great compliment to GL. ;D That's one of its strongest attributes: the ability to play nice with GL. You could feasibly use this for a 3D game, if you desired. Just replace the draw code with your own.

Gideon Weems

And here it is in my C# 'Canvas API':

I tried telling you guys.

BitCruncher

Allegro must not be dead if we're still getting new members; somebody still believes in it.

Chris Katko

SDL spies!

jmasterx

SDLers be so tots jelly of our mind control addon.

Ariesnl

I still prefer Allegro 5 above SDL.
why ? try making a counter or another "thing with changing text output" and hardware acceleration in SDL2 ..... ::)

Allegro is much easier to use and has more features

SDL is easier to install on linux though.

Thomas Fjellstrom
Ariesnl said:

SDL is easier to install on linux though.

Really? On my machines all it takes is an "aptitude install liballegro5-dev". As for installing from source, its like any source build, find the dependencies (that are listed in the readme and the wiki), install them, run the build tool (cmake in allegro's case), and install. How has SDL made it easier than that?

Gideon Weems

I think he meant Windows?

Ariesnl

I meant linux, but maybe it's an ubuntu thing.
Anyway Allegro 5 is not dead at all, at least not to me

Gideon Weems

You and thousands of others. ;)

What was Allegro's installation process like on Ubuntu? Did you install from binaries or build from source?

Chris Katko
Quote:

DOWNLOADS
37,698

Those were all me, trying to get it to compile! :o

Ariesnl

I think I was trying to build from source.
I'm on a slow loan computer right now, but I'll try to build and install allegro 5 right now.

using this ...

https://emman31.wordpress.com/2013/01/21/ubuntu-12-04-installing-allegro-5-on-codeblocks/

Arthur Kalliokoski

As the instructions say, all you need is to unpack A5 to location of your choice, then

$mkdir build
$cd build
$cmake ..
$make
#make install

except that as an end-user distro (for consumers, not producers) quite a few libraries are missing by default.

Thomas Fjellstrom

except that as an end-user distro (for consumers, not producers) quite a few libraries are missing by default.

All of the developer files (headers, etc) will be missing assuming he hasn't installed any of the -dev packages.

Gideon Weems
The article linked said:

sudo apt-get install libpng-dev libcurl4-nss-dev libfreetype6-dev libjpeg-dev libvorbis-dev libopenal-dev libphysfs-dev libgtk2.0-dev libasound-dev libpulse-dev libflac-dev libdumb1-dev

That's not enough?

Ariesnl, if you have a good tolerance for initial frustration, abandon Code::Blocks for vim and makefiles. The very foundations of Linux flow to this, and being closer to the metal makes a lot of things simpler (installations generally being one of them)... I'll stop pimping now. Have a safe New Year's, everyone.

furinkan

I think you're still missing the documentation dependencies, and some optional stuff. ;D

I will say though, that daunting as this looks to noobs, make and vim have been around since the 70's. They got their shit figured out.

PS: this tread doesn't believe in the afterlife.

Neil Roy

I still prefer Allegro for my 2D games. Allegro 5 was a great upgrade, but a few of the things that put me off of it and made it frustrating was building it. Specifically CMAKE. Sorry, but no matter how much it is touted as a great thing, I hate it. I was always able to build my own Allegro 4 in the past, Allegro 5 has a lot of dependancies which has hurt it, and you have to figure out how to build all or some of those (if you can find them), then try and build Allegro once you're done without errors (good luck with that). I only thank God there are people who can build binaries and release them for my compiler, and even they have been dying off it seems which means, I cannot use a newer version of MinGW because the latest binaries are for 4.7.1, so I am stuck at that (not that it matters that much to be honest). If a newer Allegro comes out, I can only hope someone takes the time to put up binaries. I already tried to compile it and was frustrated. Missing dependencies etc... etc... but I trudge on. Currently I have Allegro 5.0.10 installed with MinGW32 4.7.0 and have programmed a decent game (my Deluxe Pacman 1 game, still gets over 2000 downloads a week from one website I checked, and it is Allegro 4! I only wish I got $1 for each download, heheh).

Also, someone else nailed it about us all aging. I am about to turn 50 and I started programming with Allegro 2 I think it was when I was around 30 I think. Since then I have diabetes, my eye sight went from perfect to crap. The programming bug that infected me since the early 1980s seems to be vanishing. I guess I just miss the days of the 1990s and earlier, modern programming just seems to have sucked the fun out of it, for me anyhow.

I'm trying to get back into it. Certain online games (WoW) took up a few years of my time, but they are boring anymore. Maybe we'll get more people back now that the MMO fad is (hopefully) fading. ;) I know I want to do more programming, but my patience isn't what it used to be.

I am VERY thankful for all the work all of the Allegro maintainers have put into it over the years, no matter what happens I fully understand if people get tired of working on it.

Now I just need a time machine so I can go back to the 1990s, that was probably the most fun for me programming with Allegro for DOS. :D

jmasterx
NiteHackr said:

modern programming just seems to have sucked the fun out of it, for me anyhow.

I'm quite young, but I certainly agree with this. It's fun to just make a simple Tetris in C or something simple. I miss software that did one thing and did it well.

These days if you are going to make a serious game, expectations are quite high.

Even for say a Pac-Man game on the App Store. You're going to at least need in-app purchases, and most games should work online, and do a lot more than just one thing like stack blocks and make lines.

Then you basically have no choice but to program properly which kind of takes the fun out of it. Dealing with events, design patterns, working with lots and lots of libraries, etc is not really that fun, for me at least. I don't enjoy programming nearly as much as when I started with Allegro 4.2 over 5 years ago.

Most of my projects with 4.2 only depended on A4 and were only a few files in size. Now my biggest project has over 250 classes, uses A5.1x and a couple other libraries, and I'm still planning how I will port it to OSX, Linux, ios and Android.

I wish I had been born in the time where working software was all that was required. Now software has to do everything while being the most maintainable codebase on the planet. Or you're fired >:(

Arthur Kalliokoski
jmasterx said:

I wish I had been born in the time where working software was all that was required. Now software has to do everything while being the most maintainable codebase on the planet. Or you're fired >:(

Sure, the old stuff seems easy now, but back then it was about as difficult to achieve. It was difficult to get compilers, paint programs and documentation without the internet, and the few that existed were buggy and hard to use.

Thomas Fjellstrom
NiteHackr said:

Allegro 5 has a lot of dependancies which has hurt it

The only non optional dependencies A5 has over A4 is OpenGL or D3D. The rest you can get away with not caring about as you could with A4 (how many people actually bothered to install libpng and loadpng? A5 just comes with an image loading addon that supports jpeg and png, where as A4 supported neither in a convenient way)

CMake isn't the best, but its miles better to support than autocrap.

jmasterx said:

design patterns, working with lots and lots of libraries, etc is not really that fun

That is all optional. you don't need lots of libraries other than allegro and D3D/OpenGL, and the only one you need to interface with is Allegro itself.

jmasterx

That is all optional. you don't need lots of libraries other than allegro and D3D/OpenGL, and the only one you need to interface with is Allegro itself.

What I meant is, to make a practical large project, you'll need more than just A5. You'll probably need an xml library, networking, gui, and several others depending on your project. And unlike writing something in C# or Java, C++ letting you do whatever you want results in some libraries not being const correct, and several other issues can come up which makes it tricky. For example, a gui library might not use std string, or might not use char*. This complicates things. Even with Allegro, while al_ustr is awesome, you sort of have to riddle your code with it if you use it and it makes it harder to port your game to another library or have your strings be compatible with another library. In .Net or Java this probably would not be an issue.

That is of course not Allegro's fault. I was talking in the general sense comparing back to simpler games of the 80s or 90s that would not need xml, networking, or gui and back then, if you just linked to A4, you could probably build a commercial game with just linking to A4.

Thomas Fjellstrom
jmasterx said:

if you just linked to A4, you could probably build a commercial game with just linking to A4.

sure, but you'd either have to do all of the other stuff yourself, or have a simple game.

Thread #614860. Printed from Allegro.cc