[Library] modrun - an alternative plug&play love.run with callbacks, custom events, and more.
Posted: Mon Jul 11, 2016 10:51 am
Just something I've written for an older project of mine, and polished up recently. It doesn't modify any existing behavior, which means it's 100% safe to plug into any love project that doesn't replace love.run.
Its featureset is fairly simple: The primary features are:
And that's it folks! Any event callbacks you put on the state table will be called, including the custom enter/exit events and all love events. Similar scaffolding code can be written for various libraries which typically require manually calling their callbacks, including special cases for when you want to, say, feed them fabricated info, or short-circuit if your UI lib handled input already.
I've tested all of its features, and I believe that it should work without problems. The library is mostly complete, the only additions I'm debating are making base handlers callbacks like all others, adding support for "pre_" and "post_" variants of all events, for rudimentary event ordering or profiling, or priority numbers for callbacks, but I don't know if it'd actually be a worthwhile addition - in the end, you need to handle a lot of the event flow manually, as a part of your "framework", and at least with how I used it - handling most stuff with the dispatch event - callback priorities don't seem like something so important...
Well, either way, thanks for reading, I'd appreciate any input or code review
Links:
Its featureset is fairly simple: The primary features are:
- Callbacks - The ability to attach any amount of handlers to events, along with error handlers, and "self objects", which will pass a given object as first argument to both the callback, and the error handler
- Short circuiting - If a callback(including defaults, e.g. love.update) returns true, further callbacks will not be executed. Useful for, for example, UI capturing input
- New events:
- pre_update, post_update, for when you need to do things before/after the frame.
- postprocess - For nonintrusive overlays, FPS counters, or postprocessing, when you can't rely on callback registration order
- pre_quit - An event executed before quitting, allows for canceling it, to, say, display an "Are you sure?" dialog
- dispatch - A catch-all event, to which all events(except itself, of course) are sent, can be used to dispatch all events to a library
- And more! - modrun supports custom events, just register your event type, and use either modrun.push or love.event.push!
- Support for FPS throttling that takes in mind all events, and automatically turns off when vsync is enabled
- 100% plug and play - it won't even conflict with other copies of this module!
Code: Select all
local eventman = {}
local noop = function() end
function eventman:dispatch(event, ...)
if eventman.state == nil then return end
local handler = (eventman.state[event] or noop)
handler(...)
end
function eventman:setState(state)
love.event.push("exit_state", state)
eventman.state = state
love.event.push("enter_state", state)
end
function eventman:setup()
runman.registerEventType("enter_state")
runman.registerEventType("exit_state")
runman.addCallback("dispatch", eventman.dispatch, eventman)
return eventman
end
return eventman
I've tested all of its features, and I believe that it should work without problems. The library is mostly complete, the only additions I'm debating are making base handlers callbacks like all others, adding support for "pre_" and "post_" variants of all events, for rudimentary event ordering or profiling, or priority numbers for callbacks, but I don't know if it'd actually be a worthwhile addition - in the end, you need to handle a lot of the event flow manually, as a part of your "framework", and at least with how I used it - handling most stuff with the dispatch event - callback priorities don't seem like something so important...
Well, either way, thanks for reading, I'd appreciate any input or code review
Links: