Allegro.cc - Online Community

Allegro.cc Forums » Off-Topic Ordeals » If it's true, you don't believ in the afterlife.

This thread is locked; no one can reply to it. rss feed Print
If it's true, you don't believ in the afterlife.
Trent Gamblin
Member #261
April 2000
avatar

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

Erethar
Member #15,753
October 2014

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
Member #261
April 2000
avatar

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

furinkan
Member #10,271
October 2008
avatar

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
Member #261
April 2000
avatar

One vote against GitHub here.

(that patch is applied)

furinkan
Member #10,271
October 2008
avatar

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
Member #7,827
October 2006
avatar

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

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

Thomas Fjellstrom
Member #476
June 2000
avatar

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.

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

pkrcel
Member #14,001
February 2012

One vote against GitHub here.

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

It is unlikely that Google shares your distaste for capitalism. - Derezo
If one had the eternity of time, one would do things later. - Johan Halmén

Schyfis
Member #9,752
May 2008
avatar

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.

________________________________________________________________________________________________________
[freedwill.us]
[unTied Games]

Thomas Fjellstrom
Member #476
June 2000
avatar

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.

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

Schyfis
Member #9,752
May 2008
avatar

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.

________________________________________________________________________________________________________
[freedwill.us]
[unTied Games]

Thomas Fjellstrom
Member #476
June 2000
avatar

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.

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

furinkan
Member #10,271
October 2008
avatar

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
Member #12,293
October 2010

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
Member #1,090
July 2003
avatar

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
Member #476
June 2000
avatar

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.

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

furinkan
Member #10,271
October 2008
avatar

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
Member #12,293
October 2010

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
Member #11,410
October 2009

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
Member #1,881
January 2002
avatar

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.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs

DanielH
Member #934
January 2001
avatar

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
Member #261
April 2000
avatar

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
Member #7,536
July 2006
avatar

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
Member #261
April 2000
avatar

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.



Go to: