Cross-platform "file changed event" support
roger levy

This would be cool for allowing games to update in realtime whenever you save assets you're editing in other programs, like the way Unity does.


Write some code which monitors file sizes and perhaps dates to detect changes. if you have a project, you could possibly compare the asset file dates to the last date the project file was saved and then update accordingly.

roger levy

Does Allegro have enough cross-platform functionality to do this?

Also it could get very slow / delayed reaction when the # of assets gets large. That's the advantage to OS file change events.


Allegro doesn't have such functionality. Anyway, the best way is what Neil Roy said: monitorize file sizes and/or dates by yourself. AFAIK there's no other way (I think no OS has such event, do they?).

Also it could get very slow / delayed reaction when the # of assets gets large.

Actually you should do it only when your game/engine recover focus after losing it. Look at the ALLEGRO_EVENT_DISPLAY_SWITCH_IN event.


Of course the OS supports it. How do you think File Explorer works? Polling?


As jmasterx says - never poll file size or dates that just wastes a lot of resources when the kernel already does it for free. In Linux I use inotify - it's very easy to use:

roger levy

I'm glad that some people know what I'm talking about. Support in Allegro shouldn't be very hard to add, should it? :D


I honestly didn't know about that. It's not exactly functionality most programs, even game programs need.

Of course, if you want to see such functionality added, feel free to download the Allegro source code and add it yourself. You could then submit your changes and they could be included in the library and you will be credited.

In the two decades I have used Allegro I have never seen a need for such functionality, so if you wait for someone else to add it in, well... it could be a while. :)

Chris Katko

I think it might be useful as an addon or module.

"OS-specifics" module that allows you to do some stuff that might not be as cross-platform or game-related.

I've heard a lot of articles lately from decades-long senior programmers who say "it's impossible to write cross-platform code. So just don't. Write your logic in one module, and have all the per-OS-specific GUI code in native code in a separate module/DLL." And that it reduces the coupling/spaghetti-ness of your code because there aren't tons of if's/defines for each OS-specific path in the same function.

Maybe that point isn't 100% on-topic. But the idea would be, Allegro supporting things that aren't "as 100% cross-platform encapsulated" as the rest of the codebase, but are still very useful.

Then again, file notifications are pretty useful and cross-platform supported. So maybe we could use an addon/module for lesser-used functionality for games (but maybe more often for tools). Like, file system manipulation/access.

Tools are pretty much essential for any mid-size or larger game. I'm still planning on building an elaborate remote debugger with automatic screenshots, pausing/resuming/etc, examining objects, etc for my games. At some point, I'll definitely need an Allegro OpenGL context inside of a native Windows dialog/window.

Mark Oates

The OSX version requires -framework CoreServices. I have a rudimentary FileSystemChangeNotifier class that I was working on (close to being finished) and had to pivot to something else before I could finish it.

The unmerged branch against master is here. It currently works in its example program, and the implementation relies on a callback function. I haven't figured out an ideal way to write tests for it, partially because it requires writing files to the file system, and that's not the best environment to rely on for running tests.

Regardless, if this were to be modified to an allegro addon, it should emit an event instead, and would be functional (not object-oriented). But, for OSX it would likely work more-or-less the same way.

Chris Katko

and would be functional (not object-oriented). But, for OSX it would likely work more-or-less the same way.

To clarify, you mean... imperative/C... not functional like Haskell. Right? There's not some strange requirement for Allegro addons to be functional, is there?

Mark Oates

To clarify, you mean... imperative/C... not functional like Haskell. Right? There's not some strange requirement for Allegro addons to be functional, is there?

Functional as in C-like, and not Object-oriented as in C++ like. My projects are all (at least in this phase of my life) strongly Object-oriented. Allegro has no objects in the C++ sense.


Functional as in C-like

Functional programming and C are two completely different beasts. This is what functional code looks like:

apply :: (Ord k) => k -> v -> (v -> v) -> [(k,v)] -> [(k,v)]
apply k v f ds =
  let (p1,px) = span ( (k >) . fst) ds
      (p2,p3) = case px of
        []     -> ((k,v),[])
        (x:xs) -> if fst x == k
           then ((k, f $ snd x), xs)
           else ((k, v),       x:xs)
  in  p1 ++ (p2 : p3)

C is an imperative language.


Functionnal programming sucks.
Use C, it's and order ! (imperative language)


Functionnal programming sucks.

I actually quite enjoyed doing functional programming at university. I wouldn't want to use it for anything large, but it's good for developing algorithms.

Chris Katko

While I don't need to use graph based algorithms often, I really wonder if functional is just some big fad, or actually useful.

Like, I tried Haskell, and I tried making some toy algorithms. Factorial here. Some algorithm there. But... it felt terrible. Like, there was zero implicit understanding of whether or not the code would work 100% 10% 1% or .00001% of the speed of a C implementation. It felt like I was just specifying schematic and the "compiler" would become a wizard and magically run the code and if it was fast or slow, was a roll of the dice.

I mean, there are clear, useful, functional (ish) code. Map. Zip. Unzip. All those typical Javascript, Python (and D!) ones.

I like how D's API is setup to use method chaining and functional like calls.

Actual code, from's example codes:

import std.stdio, std.array, std.algorithm;

// Print all lines of stdin, sorted.
void main()
        .sort!((a, b) => a > b) // descending order

That's about as self-documenting, clear-intent code you can make in any language!

The really cool thing with D is... you can do most stuff at compile time too. So you can literally (on that same webpage, sort an array, at compile time, with a single call.

I kind of like the D version of functional programming. You can mark any imperative function as pure, and all calls it calls have to be pure as well. That's great for concurrency. You can also use functional snippets where ever you want, without requiring the entire program to be functional. (Or hell, write entirely functional in D, if you want.)

That way, I can use "as much as necessary and no more" functional programming, in the places where I gain a large productivity bonus, and if necessary, replace any slow sections with imperative versions.

But back to functional as a whole. It confuses me. Like, imperative languages bog down when you have to emulate functions. But, functional languages bog down when you have to use imperative logic. "Do this, then this, then this." is the core of 99% of all business logic in the world. So why would I try to map imperative, to functional, just for the sake of "functional"?

I don't know. I know there are lots of different use-cases for programmers. But literally zero of the professional works I've done have involved any need for functional programming and it's been only relegated to "for the sake of itself" or curiosity.

Thread #617285. Printed from