I am having a problem getting user input using allegro 5. I have seen all the
comments on this site concerning user input! All the comments seem to be somewhat over my head! I have just started using allegro 5. What I am concerned with is
getting user input from the keyboard such as a user's name. I would prefer that
it would be in ascii text using graphics mode. If someone could post a small portion
of code in C language showing a switch statement I would be most grateful. If you
would like more info I would be glad to post it. Thanks to all that would like to
help me with this problem.
There was one post by AmnesiA that was posted on 9-27-2013 @ 9:58 AM that was very
helpful but I never got anything it to work.

It's really not that hard. Hook an event queue up to the keyboard and listen for ALLEGRO_EVENT_KEY_CHAR events. Listen for ev.keyboard.unichar and ev.keyboard.keycode to determine what to do with the input.

Here's a quick example of how to check these events :

Thanks Edgar for your prompt reply.
I will slip it in my program and see what happens.

Your text will be built from the ev.keyboard.unichar field, and your commands come from ev.keyboard.keycode. If you don't get a command, you've got a char. Let me know how it goes.

EDIT
You can check out my TINS 2017 entry to see how to monitor text. Take a look here :

https://github.com/EdgarReynaldo/EagleGUI/blob/master/TINS2017/src/Game.cpp#L380-L479

Good morning Edgar:
I plugged your code into my program and code:blocks generated a few errors.
Some I have no idea what to do about! So, after 3 weeks dealing with this one
problem, I have had enough! I am going to try to forget about it! Maybe later
I will try again. I appreciate your time but Allegro is too much of a problem
for me! I had to give up on Python for the exact same reason. Thanks for your
time but it appears I can't master that keyboard! Have a great day my friend!

If you keep giving up every time you run into trouble, you'll never get anywhere with anything.

What were the errors you had? If we can help you fix them you might learn how to fix the next problem yourself.

My apologies, that code was missing brackets and other things. Try this structure instead :

Scooter,
If you keep giving up you'll never learn anything. Failure is normal. You need to keep going. When you get an error, read what it says, usually they help you figure out what is wrong. Also, you need some basic C programming skills. Python is actually not that difficult to understand.

Don't just plug code into your program. You need to understand what it does. Copy Paste Coding is the Source of all Evil^TM.

Also, I didn't show where I initialized the 'q' variable :

ALLEGRO_EVENT_QUEUE* q = al_create_event_queue();

and hook it up to the keyboard :

al_register_event_source(q , al_get_keyboard_event_source());

THEN, you can use it later on. But you have to set it up properly before doing so.

Note to LennyLen:

I appreciate your concern!
I have accomplished many GREAT things in my lifetime.
I consider what little programming I do to be a lot of FUN!
If it ever becomes NOT FUN, then I consider it NOT WORTHWHILE!
Not everyone can become an expert in programming!

We can help answer any questions you may have, but you need a good book on Programming in C. There are a lot of good websites out there too, such as http://cppreference.com (which has a good C reference as well). Once you're comfortable with C, you need to become comfortable with reading documentation for the libraries you're using, such as http://liballeg.org/a5docs/trunk/ .

Getting started : http://liballeg.org/a5docs/trunk/getting_started.html

There are tutorials for Allegro on the wiki, here :

https://wiki.allegro.cc/index.php?title=Allegro_5_API_Tutorials

If you don't understand something on one of those pages, ask here.

Good afternoon Edgar:
I may have left the wrong impression. I have been using the C language off and
on for the last 25 to 30 years. I don't consider myself an expert but I do have many
programs I have written. I started back in the day when Borland Turbo C was popular.
I guess I just told my age. Nonetheless, I am somewhat familiar with Allegro 5. I
have a Poker game I have written and a program displaying my favorite cars in a slide
show with music playing in the background. These programs all use the mouse to
navigate through the program. I would not consider either one professional, but they
both work perfectly. My main problem is the keyboard. None of the programs I have
found are using the keyboard like I am trying to. I do not have a problem with using
the arrow keys like many of the programs show. What I want to do is press a key and
it show on the screen the key I pressed. This would be like a person's name which
would be copied to a structure like an address book. None of the programs show how
this is done in Allegro 5. I guess my problem is the syntax in Allegro 5. At my age
this is something I do for fun and fun only. I have no intention of being a pro-
fessional programmer. I appreciate your help but I wanted to let you know what my
goals were. Have a great day!

You should take a look at ex_keyboard_events.c. It shows you exactly how to use the keyboard.

What you need to understand about Allegro 5 is that it uses events. Keyboard information comes in the form of events. There are ALLEGRO_EVENT_KEY_DOWN, ALLEGRO_EVENT_KEY_UP, and ALLEGRO_EVENT_KEY_CHAR events. When you need to know what key was pressed you use ALLEGRO_EVENT_KEY_DOWN, and when you need to know what character was typed, you use ALLEGRO_EVENT_KEY_CHAR.

ALLEGRO_EVENT_KEY_CHAR

You may not be aspiring to be a professional programmer, but at the same time, this is pretty simple stuff. I believe that if a person is going to do something, they should do it to the best of their ability or not at all. Giving up because something is hard is self destructive. You will start to believe that you can't do it, and if you believe you can't then you actually can't do it. It's a self fulfilling prophecy. However, if you believe you can, you can. Mind set is everything.

They use two functions to display the character. al_utf8_encode, and al_keycode_to_name. The first gives you the character's unicode code point, and the second gives you the name of the key that was pressed. Notice how al_utf8_encode takes ev.keyboard.unichar? And al_keycode_to_name takes ev.keyboard.keycode?

I hope this helps clear things up.

Please ask if you need help.

Good afternoon Edgar:

Had no luck with your code segment! Finally wrote what I needed in C, away
from Allegro. Entered my info, saved to disk and loaded into my Allegro program.
A little extra work but worked out fine! That was my only hope! There is something
about that keyboard in Allegro that I can't understand. But I got the job done
and I am happy. Too many sleepless nights worrying about it! Thanks for your time.

Agreed. I wrote a complete game with all the various inputs for Allegro 4 (Deluxe Pacman 1 below) and for Allegro 5 (Deluxe Pacman 2 below). All work just fine.

You won't find it much different with anything else. Maybe programming is too much, perhaps game making software is more your style, Game Maker or such.

This is the high score entry code I have for my Deluxe Pacman 2... written in C (as my whole game is)

Neil:
Thanks for replying. I am going to try this again. I believe my problem
is the unichar. How would it look to use ascii text. Using the unichar my
program compiles fine, but when I sprintf the string in my buffer and use
textf to print buffer to screen, nothing shows on the screen. I really don't
know where my problem is. I have tried different ways and they all compile with
no warnings or errors, but I can't get a thing printed to the screen. That is
the reason I broke away from allegro and wrote it in straight C to get the job
done. I then saved my info to disk, brought up allegro and imported my info
to my structure and then printed to the screen. Everything worked as I wanted.
I believe I need to use straight ascii text and I would be fine. Any ideas on
that. Thanks for your time. This seems to be my main problem using allegro 5.
I have no problem with the arrow keys or the mouse.

My function above uses unicode to support all sorts of text as I have had people play my game from all over the world and there needed to be support for international characters etc. It wasn't difficult to be honest.

The one problem I had when I first converted over to unichar or whatever in heck they are called (been a while). Was my main project files needed to be encoded as UTF-8 files.

If you look at the source I shared, it works (download and run my Deluxe Pacman 2 game, that is the code straight from that game for the high score input).

If you look at my code, you will see I use special Allegro functions which will assign unicode text to things like my highscore array.

al_ustr_assign(hiscore[difficulty][myscore].name, yourname);

Here I assign "yourname" (the name you entered) to the hiscore array, which is just the list of highscores. Here's the variables I use to store the name in...

typedef struct HISCORES {
   ALLEGRO_USTR *name;
   unsigned long  score;
   int            level;
   char           time[TIME_LEN];   // Adjust the size to match characters needed for storage
} HISCORES;

static HISCORES hiscore[DIFFICULTY][NUM_SCORES];

static ALLEGRO_USTR *yourname;

As you can see, the "name" part of the struct where I store the text NEEDS to be an ALLEGRO_USTR in order to be able to store it properly.

It may seem like a bit of a pain now, but it really is worth it to understand how to handle unicode if you wish to make anything that can be used internationally. For my Deluxe Pacman games, I have had literally millions of downloads (free game), most from South America and other foreign nations, so the unicode support was a good thing to have. If your text is not appearing it could be due to not storing it properly or using the right functions to display it.

Go over your code a step at a time.

1) Am I using unicode storage? ALLEGRO_USTR
2) am I copying text using unicode functions? al_ustr_assign()
3) am I using unicode functions to display it?

etc... you can do this. I know, I was frustrated with this as well until one day when you get it right.

You don't need any ALLEGRO_USTR's to use ev.keyboard.unichar . Encode it to utf-8 and then you have the ascii value in the lower byte.

I already posted code... `if(event.keyboard.unichar >= 32) {` And what I posted, works. But feel free to piss around with other methods.

Feel free to needlessly complicate things by using an ALLEGRO_USTR if you want Neil. The lower byte of ev.keyboard.unichar IS ascii, due to the way it is encoded. And you have to check for the upper bound as well, not just the lower bound.

If ((unichar >= 32 && unichar <= 127)) {...}

If you want to use pure ASCII, than ditch Unicode entirely and just do ASCII. It is absolutely pointless to have Unicode when you want ASCII. But if you want to support Unicode, than you don't want an upper boundary!

In my code you absolutely do not want an upper boundary as it is a highscore input and people will be typing in their names which may be using characters that go well above 127! You do realize that there are other characters in the world right and that is the whole point of Unicode?

To set boundaries to ASCII in a Unicode routine doesn't make any sort of sense. At least not for the use I have in my own code example. As soon as someone from another nation, say a French person, types in "é", limiting your characters to ASCII will miss this!

He specifically asked for ascii.

He wants user input like a user NAME, so he will want Unicode, not ASCII. As I stated, I already gave an example of using it that works and I explained why I do not have an upper limit.

If you want ASCII, than don't use Unicode! But don't fucking criticize MY Unicode because it doesn't have an upper limit, it only shows off your ignorance.

Listen closely you old fart. You were the one who criticized me first. I don't appreciate it. Watch your mouth.

If all you want is ascii, then characters above 127 are extranneous. If you want to piss around with ALLEGRO_USTRs, by all means go ahead, but for someone who only wants ASCII, it is a ton of wasted work. See how that sounds? So piss off. Seems to be your favorite saying, hope you enjoy people saying it to you.

Having trouble reading?

"piss around with" is the same as saying "mess around with" or "screw around with" or whatever. You take offense too easily. He wanted input for names which is why I recommended using Unicode.

As for my age (53, hardly old)...

1 Timothy 5:1 (NIV)
Do not rebuke an older man harshly, but exhort him as if he were your father.

Not to mention that it's usually been the policy around here to point people towards the proper way of doing things, not the quick'n'easy way.

My apologies Neil. But you really know how to get on my nerves.

As for the OP, he's clearly struggling with this, and complicating things with ALLEGRO_USTRs is bound to make things harder for him.

And to be honest, the USTR api in allegro is probably my least favorite. Handling strings in C is a pain in the rear.

That there isn't a better C++ standard string is quite frankly appalling, given the number of decades they've had to make one. std::string is still better than messing around with c-strings though.

It stems directly from C++ and C's poor way of handling dynamic arrays.

Well, if you look over my code you can see that I handled it with no problem, and that was one of the first times I had really dealt with Unicode. If you want to make a game these days and want to make certain anyone, from any language can enter their name, you want unicode. Personally, I didn't have a problem with it and have never had a problem handling C strings, or pointers etc.

This is the main reason I posted the code I use in my game. It's simple and works well. I think this is one area where Allegro done a great job. I don't find it difficult at all, look at my code, that's pretty simple, part of that code has stuff in it for my sound effects and what not, trim them out and there isn't much to it.

In any event, whether you find it more difficult or not, if you wish to create a game that anyone can use, you will have to support this or limit your audience. And the vast majority or people that play my game are people from other countries, usually non-English speaking nations. For fun or for profit, there's a huge market out there of people in non-English speaking countries. It's best to learn to do it right early on.

Good afternoon to Neil and Edgar:
I am so sorry that I caused you two to have bad feelings between you. That
certainly was NOT my intention. Hope you can mend your differences. I only ask
a question because I need help and I still do. I have been working on this problem
for the past two days and have gotten nowhere. To me, there is no reason why this should be so hard to figure out. I have been able to do everything I needed to do
with allegro 5, but this keyboard is a problem I can't solve. The code supplied
allows me to press a key and it will show on the screen, but it is beyond me how
to get it in my buffer and be able to display it. I have tried al_draw_ustr() and
everything else I could fine but nothing is displayed. I am still shooting in the
dark on this one. Oh, I forgot to mention I have used al_ustr_to_buffer() but still
nothing. I will get back in touch with you later. Hang on, its been a bumpy ride so far. Have a great day my friends!

Don't worry about it Scooter. Neil and I argue all the time. It's normal. Yes, we're a little dysfunctional around here...

You need to use a string concatenation function, whether it be for a c-string (whether it's encoded in ascii, utf-8 or something else) or an ALLEGRO_USTR, or whatever you want to store it in. Then you need to draw it on the screen using allegro and an ALLEGRO_FONT* that you create.

Show us the code that you're using, and we can tell you what needs to be fixed.

Use <code>code_goes_here();</code> tags to post code.

I'll try to come up with a quick example in the mean time.

They're both adults. If they're in an argument, it's nobody's fault but their own.

If you scroll down through the messages, you will see that I didn't start any argument. But I won't be helping anyone in these forums again, this way "Edgar" won't get upset.

Neil, I never had any problem with you helping someone. But complicating things needlessly for beginners is a bad idea, and it is not what he asked for! You're the one who started insulting me.

So I'm ignorant. Thanks.

So my methods aren't worth using? That's funny. The first thing I posted was working example code, and then I posted the allegro example program.

I find it odd that it's always my fault when you're the one who is continually getting upset at me because I don't agree with you. Don't have a hissy fit just because you're wrong. Grow the fuck up and deal with it.

You want my advise Scooter? Honestly I advise you stay far away from Allegro, any version. A MUCH better API is SDL2.

It's better supported, has a few AAA titles under it's belt, pre-compiled versions of it are super easy to get, and they work as intended.

And you can get plenty of help with it online without someone constantly engaging in arguments. There are tons of Youtube videos with help, the SDL2 wiki is amazing, probably the best designed for help I have seen.

It's what I have switched to. I won't make anything with Allegro ever again. It's a dead API. It was good in it's day, but it's day has passed.

You're a traitor and a coward. Good riddance to bad rubbish.

@Scooter
Don't listen to him, he's just a bitter old man.

Allegro 5 has a very good API, and you can do it all easier with Allegro than you can with SDL2. We may not be as popular and we may not have as many users, but there are AAA titles made with Allegro 5 as well, such as Factorio and others. Our small user base makes it harder for us to distribute binaries, but I have been releasing binaries for MinGW for the last several years, as well as the binaries that SiegeLord provides on liballeg.org. Neil himself has been using my binaries for a while now. Or didn't he tell you that? I'm sure he's going to boycott me now, as well as allegro, because he can't stand people disagreeing with him. He's just a sore loser.

And if our forum has problems with people arguing, it's usually limited to the off topic ordeals board. But Neil likes to start shit with me, and I don't care for it. I don't start fights, I finish them.

Our forums are usually very good natured, and people almost always get help within a day or two. If that's too long, you can go on IRC on #allegro on freenode.net and get help almost right away.

Now I'll try to get back to making an example for you like I said.

If your code isn't working, post it. Then we can show you what's wrong.

Just being honest and giving him alternative choices. It's always good to try different things and see which one works best for you.

Good afternoon Edgar:
I finally have something that works pretty good. If you have time can you look
this over. You would not believe the hours I have in this code! If you have the
time, I would love to see this in strictly ascii code. I do not want to see the
words unichar or ustr ever again! This represents the worse problem I have ever
had with Allegro. Here's the code:

It's a little late tonight, but I'll give you feedback on your code tomorrow if no one else does. I've also put together a full example program but I have to work out a couple kinks first. Too tired to work on it anymore tonight though.

EDIT

Here's an example program and the accompanying source code. It's written entirely in C (for your sake) and uses an ALLEGRO_USTR and an unsigned int code point array (because I hate variable width characters).

InputDemo.zip

{"name":"611284","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/6\/16c0fb481952a8a3024a7a2550c4725f.png","w":802,"h":633,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/6\/16c0fb481952a8a3024a7a2550c4725f"}

Regarding your source code, there are a few things you could improve. It's pretty disorganized. The formatting is rough and inconsistent. Combined, those two things make it hard to read and understand. It's a decent start, but could use some organization and proper formatting.

In my source code I tried to comment as well as I could so you can understand what I'm doing. If you have any questions ask away.

My example program is pretty functional, but I didn't include everything that a real text box input widget would have.

Personally, I would much rather avoid C altogether in favor of C++. Manually inserting and deleting characters into an array is kind of obnoxious in C. The string is stored in an unsigned integer array, and then encoded into an ALLEGRO_USTR for display on demand.

Here's the code :

Good morning Edgar:
I have downloaded you program and I say WOW! That is a lot of code to
digest! That will keep me busy for quite a while. I switch to Linux a few
years back, but I do have some Windows machines around here. I will fire
one up and give your program a test. I think its great that you have this
stuff figured out. I will get back to you later. Have a great day my friend!

Scooter, that code should compile fine on Linux as well.

Good afternoon Edgar:
I am trying to compile your program on Linux with Code:Blocks. It is
generating some errors. This is one thing its complaining about on line 33.

for (int i = 0 ; i < size ; ++i) {
al_ustr_append_chr(ustr , cbuf[i]);

Code:Blocks returns this error:

error:'for' loop initial declarations are only allowed in C99 mode. I find nothing on Code:Blocks that gives me a clue what this means and what to do about it.

There are other errors being reported but most are concerned with the 'for loops'.

I use 'for loops' all the time, but never seen this error. New one on me!

Scooter, here's the fix for that :

C is whiny about stuff sometimes. You can't declare new variables after you write code. The declarations always have to go at the top of the function, or into a new code block like so :

Even single-line comments are not C They are introduced by either :
- C++ (every version and implementation, it's part of the base standard)
- ISO C99
- GNU extension (any gcc compiler where you don't disable them by specifying a compilation standard that excludes them)
- Other compiler-specific extensions ? (MSVC6 maybe?)

In 2018, unless you're creating a really specialized system or you care about ridiculous portability , or writing a library, I do not really get the appeal of using a C compiler to write C.

C++ adds those few things that just makes life easier. You can still program C-style in C++ but without having to worry about silly things like line comments.

I would also make a few thin wrappers around basic stl things like vector, map, etc, rather than reinventing the wheel for such basic things.

Not really relevant to a C question, but I have a class in Agui for utf8 manipulations on std strings https://github.com/jmasterx/Agui/blob/master/include/Agui/UTF8.hpp

Taking advice from people who say things like this...

Is about as foolish as one can get. Comments?! I have coded in C since the '90s and haven't "worried about comments" ever. Single line has been a part of C for two decades. Just about everything in C++ comes from C, that's why it has a "C" in it's name.

Here's a fun thought, if you pulled everything that is C out of C++ you would be left with an unusable language... basic things like if/else, switch/case, {}, return, headers, includes... you name it, it is all C. The ++ is things like classes and such that is C++ specific... but comments... yeah... comments, lets focus on that. Stupidity.

This is simply laughable and blatantly untrue! I have been declaring variables mid code for two decades now! It hasn't been a problem since the '90s, and even then, it wasn't a problem.

Lets just test out the code mentioned with GCC and see what happens shall we? I'll compile it with just "gcc main.c" and I will post a screenshot of all warnings and errors to be fair and lets just see if what was stated is true or not...

I typed "gcc -v" to show the version, ironically, this is the mingw version I got from Edgar. I then just typed "gcc main.c" with the above code, unaltered, even the /// in there... this was the result...

{"name":"611287","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/e\/ce74302a99d6078ae445f24cef04d309.jpg","w":775,"h":173,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/e\/ce74302a99d6078ae445f24cef04d309"}

Notice, I didn't tell it which standard of C I was using, I used the code above EXACTLY as Edgar posted it with zero errors and not even a warning.

Now these arguments would have been true in the mid 1990s! But haven't been true for a very long time. And of course now there is the 2011 C standard which adds in more functionality. Heck, C++ itself has changed dramatically since the same time, and for the better. Comparing modern C++ to old C? How is that even remotely fair?

Now if you want to use C++, go for it. I can certainly see the appeal, but at least be honest and compare it to MODERN C and use the one you want because YOU like it. C isn't going anywhere, anytime soon.

There's good reason why the majority of libraries and drivers are written in C.

Use what you feel more comfortable with, but do your own research on this and pull out a modern C compiler like GCC and test what they said and see if it is true or a lie.

Edit: the following alterations to the above code also compiles just fine with "gcc main.c"

You took what I said a bit out of context. My point was just, yeah, C++ is C with the ++.
Which means you can still do everything C can do with the ++. You conveniently ignored my portion about stl.

The main advantage I see of using pure modern C, is not depending on the C++ runtime.

and for things like hardware drivers that makes sense.

But trying to program a decent video game without some equivalent of stl (or boost & co) is silly. You either roll it out by hand or find some library that you have to learn and work around its license and quirks. STL is tried, tested and heavily supported on sites like SO, so it's great for people learning to code who do not yet understand how to make dynamic arrays and the such.

Neil, you do honestly come across like you're bashing with that kind of talk. It's hard to defend that. You're treating us like we're children or something and that's very unwelcome.

You could have stated your point without making me seem like an uncredible piece of s​hit.

Guess what, people still use compilers that only support C90, and that code in C90 is illegal. My compiler happens to be more recent, and uses a different default standard. Instead of being a C Nazi, why don't you chill out and take a step back and realize that not everyone is using a modern compiler. Granted, they should upgrade or compile with a different standard. But all this hate towards C++ is just immature and ridiculous. Grow up.

Our most Christian Christians acting out their agape again... So sad.

Guess what, those same people will also still be using compilers that do not support modern C++ as well, so the same comment can be made about that! The fact is, modern compilers which are freely available, which you yourself uses has NO problems with the bullshit code you posted! Making you our to be a liar!

And I NEVER stated I hate C++, I am defending the blatent hatred and falsehoods being posted about C!

THIS is what I said about C++

Just don't post code and state that C will reject it when it will not. When you discuss these things, you need to compare equal versions. So if you want to compare 1990 C++ with 1990 C, go for it. But it is unfair to compare 2018 C++ with 1990 C!

If you prefer C++, great, wonderful, it's certainly a very powerful language. There are aspects I like about it for sure. It does strings really well, it has vectors which are awesome. But be honest about it all. Compare modern C with modern C++. And modern C can do threads, one line comments, variable declarations mid code etc... etc... etc... it just doesn't have classes, which is something I can't stand and I have even seen a move by some away from them as the problems with classes are starting to become apparent, but that's another topic. I'm not posting to attack C++, I am only defending the lies being posted against C.

What the fuck does this have to do with religion moron?! This is about programming, grow a brain!

Who's angry now?

Also it's clear that he didn't have a "modern compiler", which makes it perfectly reasonable that it doesn't use the C99 standard by default.

Than it's clear he needs to download one! Who the hell doesn't have a modern compiler these days?! It's not like they're hard to find. In either way, your information about C was completely false.

No, no it wasn't.

We were speaking of an entirely different standard. But you interpreted that as saying that none of the C standards worked that way.

Lighten up.

My apologies. But it does need to be stated that modern C is not that way anymore or you could send a false impression to someone.

Both C and C++ have changed quite a bit since the '90s, and for the better.

I always say, use what you are the most comfortable with. Give both a try and see which you prefer.

Good morning Edgar:
I got your 'input.c' program to compile. A super program indeed.
It works perfectly! This will help a lot of folks having problems
working with the keyboard. I know it took a great deal of time to put
it together, and for that, I say THANKS!
Something you might want to take a look at: Code:Blocks issues a
Warning on line 19. Evidently it means nothing because the program
runs fine. Here's the code in question:

void AssertHandler(const char* expr , const char* file , int line , const char* func) {
int i = 0;

printf("%s failed in file %s on line %d in function %s\n" , expr , file , line , func);

i /= 0;
return;
}

i /= 0; You should get a warning about this one, you're trying to divide by zero?

I don't even see why int i = 0; is in there. It sets i to zero, then later tries to divide it by zero then return. i is not used.

Just remove it entirely.

void AssertHandler(const char* expr , const char* file , int line , const char* func)
{
   printf("%s failed in file %s on line %d in function %s\n" , expr , file , line , func);
}

...that should work just fine. No need for the i variable, the divide by zero or even the return statement as it is a void function.

Neil, it's intentional. The divide by zero is on purpose, because it allows the debugger to catch the exception. This allows you to get a backtrace when the program fails an ALLEGRO_ASSERT. Otherwise the program exits and you can only see where the assert failed, not the stack when it does.

So keep the divide by zero, it's on purpose.

Ah, okay, I had a feeling that might have been it. That's an interesting trick.