My main complaint/comment about that piece of code is that there doesn't seem to be a good reason for the function to take an ALLEGRO_EVENT. In fact, it's probably better if it doesn't, because as it is you can't "drop it in" as is if you want different ways to safe a screenshot. Cleaner, in my opinion, is to catch the relevant event in the main loop and then call the relevant function.

I updated the code in the original post. Compiles and runs in my game (Allegro 5.0.0, MinGW).

I couldn't figure out a simple way to take adventage of al_get_app_name, since it can return the EXE's full filename (test.exe), and that would mess up the later call to al_set_path_extension(path, ".png"); (It would overwrite the timecode things)

My main complaint/comment about that piece of code is that there doesn't seem to be a good reason for the function to take an ALLEGRO_EVENT.

Fixed that too. Now there's two functions al_screenshot which just takes a path and name, and immediately takes the screenshot; and al_screenshot_process_event which is the convenience function that calls al_screenshot when F11 is pressed.

EDIT: Oh, also, it returns success codes now, so you can check that and have your game display "Screenshot taken" or something.

Do you not think it's confusing that the allegro wiki mixes A4 and A5 to the point where you are guessing which one you are reading (e.g. click on the 'examples' wiki entry).

Perhaps it's time to actively promote A5 and legacyise (a made-up word perhaps) A4; the best way being to make A4 wiki less prominent and make the wiki A5 focused? Just like in the allegro.cc home page where the entry point for 'Files' is allegro 5.

You have whatever name you wish, followed by the MMDDYY_HHMMSS (although I prefer YYMMDD_HHMMSS myself, the files will then be listed in the right order in a directory). This gets rid of any limits on how many you can do in a day because they will never be over written and it makes it easy to know when you took the screenshot at a glance.

You could also simply do a "screenshot%d" or "screenshot%03d" and add on a number you increment for each shot.

The function prefix could also be "a5_screenshot" if you're looking for something that is easily recognizable other than "al_".

Edit: I would also prefer it to be automated so that nothing needs to be passed to the function, just have it get the executable filename, crop the ".exe" off of it, then save the screenshot into the same folder that the executable resides in, perhaps creating a "screenshots" folder if one doesn't exist and saving all screenshots in there.

I would also prefer it to be automated so that nothing needs to be passed to the function, just have it get the executable filename, crop the ".exe" off of it, then save the screenshot into the same folder that the executable resides in, perhaps creating a "screenshots" folder if one doesn't exist and saving all screenshots in there.

Horrible idea in general. That's not the sort of behaviour you want to hard-code inside the function, because it's not portable.

It's perfectly okay to write another wrapper function that does those things and then calls the underlying ale_screenshot function (everything except the different time-format).

I personally like the idea of having the screenshots folder being created automatically, but past some point I didn't want to bloat out my code. I'm hoping for it to be part-useful tool/part-useful learning guide. Too much complexity and it becomes hard to understand.

So yeah, if you do write a wrapper, put it on the Wiki. It can be another sub-section of the article I put up, or a separate article linked from the original.

Under GNU/Linux, the executable may be installed to '/usr/bin', with its data stored at '/usr/share/mygame', then user files and configuration go to '~/.mygame'. The user will not have permissions to write to the executable or data directory.

____________________________________________________________________________________________"c is much better than c++ if you don't need OOP simply because it's smaller and requires less load time." - alethiophileOMG my sides are hurting from laughing so hard... :D