Open main menu

Difference between revisions of "Modular Backends"

164 bytes added ,  21:55, 30 April 2006
Line 20: Line 20:
Another typical candidate for modularization is the Timer code. Currently, most backends are happy using our default Time class, which is based on <code>OSystem::setTimerCallback</code> method. But the Morphos backend actually needs a custom implementation. The results in a rather nasty hack.
Another typical candidate for modularization is the Timer code. Currently, most backends are happy using our default Time class, which is based on <code>OSystem::setTimerCallback</code> method. But the Morphos backend actually needs a custom implementation. The results in a rather nasty hack.


If we were doing things in a somewhat more modularized fashion, then this would become much simpler: Essentially, we'd have a "timer" module, and a default implementation of that which would be 99% identical to our current timer code. The difference being that we make it explicitly possible to replace it. Most backends would simple keep using the default implementation by providing the optional OSystem::setTimerCallback method (probably in a different way, but let's not get too specific here). But porters could also add an alternate implementation if desired.
If we were doing things in a somewhat more modularized fashion, then this would become much simpler: Essentially, we'd have a "timer" module, and a default implementation of that which would be 99% identical to our current timer code. The difference being that we make it explicitly possible to replace it. Most backends would simple keep using the default implementation. But porters could also add an alternate implementation if desired.


The higher level code would simply ask the backend once for the "timer manager" via a new <code>OSystem::getTimerManager</code> method (similar to the existing <code>OSystem::getSavefileManager</code> method). The result is virtually identical for the client code (only a bit in main.cpp has to be changed), and also virtually identical for porters
The higher level code would simply ask the backend once for the "timer manager" via a new <code>OSystem::getTimerManager</code> method (similar to the existing <code>OSystem::getSavefileManager</code> method). The result is virtually identical for the client code (only a bit in main.cpp has to be changed), and also virtually identical for porters


OTOH, the <code>Timer</code> class would only need a minor change: Instead of taking an <code>OSystem</code> parameter, the backend would be responsible to hook up the timer callback appropriately, which amounts to a single line of code. In other words, the change would be almost trivial.


== Requirements ==
== Requirements ==
1,079

edits