1,079
edits
Difference between revisions of "Modular Backends"
Jump to navigation
Jump to search
no edit summary
(Added notes on we could organize the source.) |
|||
| (6 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{| border="0" cellpadding="2" cellspacing="1" align="right" style="margin:1em; background:#FF0000; width:40%" | |||
|- align="center" | |||
| '''THIS PAGE IS OUT OF DATE''' | |||
|- style="margin-left:1em; background:#ffffff;" | |||
|- style="background:#ffffff" | |||
|ScummVM has changed considerably since this page was created, rendering most of its content obsolete. It is only preserved here for reference purposes. | |||
|} | |||
== Introduction == | == Introduction == | ||
We are considering to change our backends to use a more modular approach to things. This would be reflect in both the implementations and also in the interface (i.e. OSystem). | We are considering to change our backends to use a more modular approach to things. This would be reflect in both the implementations and also in the interface (i.e. OSystem). | ||
| Line 9: | Line 17: | ||
=== X11 backend === | === X11 backend === | ||
The X11 backend directly uses the X11 API to implement graphics output for ScummVM on any system that supports X11. But of course, being a backend, it also needs to provide a way to output audio. X11 doesn't offer an API for that (AFAIK, at least), so it has to use something else. Sadly, this limits its portability. Right now, it has code for any system that supports <code>sys/soundcard.h</code> resp. <code>linux/soundcard.h</code> (I think that means OSS | The X11 backend directly uses the X11 API to implement graphics output for ScummVM on any system that supports X11. But of course, being a backend, it also needs to provide a way to output audio. X11 doesn't offer an API for that (AFAIK, at least), so it has to use something else. Sadly, this limits its portability. Right now, it has code for any system that supports <code>sys/soundcard.h</code> resp. <code>linux/soundcard.h</code> (I think that means OSS) | ||
With the modular system approach, we'd split it into a "graphics & input" module which was implemented based on X11, and a "sound" module implemented based on OSS. | With the modular system approach, we'd split it into a "graphics & input" module which was implemented based on X11, and a "sound" module implemented based on OSS. | ||
| Line 20: | Line 28: | ||
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 | 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 == | ||
| Line 37: | Line 46: | ||
* Graphics | * Graphics | ||
* Input (events) -> possibly have graphics, input & event code all in a single type of module, just like SDL does -- after all they are usually tightly tied together anyway. | * Input (events) -> possibly have graphics, input & event code all in a single type of module, just like SDL does -- after all they are usually tightly tied together anyway. | ||
* Sound (possibly allow for custom mixer implementations. Maybe even make it possible to use | * Sound (possibly allow for custom mixer implementations. Maybe even make it possible to use custom MP3 playback implementations and such things, for platforms that offere optimized implementations. Of course, this is tricky, and may not be possible at all) | ||
* Audio CD (could be mixed with Audio/Sound, but then again the code overlap is probably non-existent, at least in the current backends) | |||
* Timers (the current code would be left as default implementation, but e.g. Morphos port could override it easily) | * Timers (the current code would be left as default implementation, but e.g. Morphos port could override it easily) | ||
* Mutexes (only used when timers & threads are involved, so could be part of that) | * Mutexes (only used when timers & threads are involved, so could be part of that) | ||
| Line 44: | Line 54: | ||
* SaveFileManager (already modular to an extent, but should be moved to backends/saves/) | * SaveFileManager (already modular to an extent, but should be moved to backends/saves/) | ||
* Native MIDI drivers (already modular, backends/midi/) | * Native MIDI drivers (already modular, backends/midi/) | ||
* | * Plugins | ||
== Source layout == | == Source layout == | ||
| Line 53: | Line 62: | ||
* <code>backends/fs/..</code> | * <code>backends/fs/..</code> | ||
* <code>backends/saves/default</code> | * <code>backends/saves/default</code> | ||
* <code>backends/saves/psp</code> | * <code>backends/saves/psp</code> | ||
* <code>backends/timer/default</code> | * <code>backends/timer/default</code> | ||
| Line 66: | Line 74: | ||
I don't want to be too strict on how far we use subdirs or not. E.g. <code>backends/midi</code> currently does not use subdirs. And the subdirs in <code>backends/fs</code> are not really needed either, since each implementation so far consists of a single source file only, so we might want to flatten it. Those are fine details we still can decide (and change) latter. | I don't want to be too strict on how far we use subdirs or not. E.g. <code>backends/midi</code> currently does not use subdirs. And the subdirs in <code>backends/fs</code> are not really needed either, since each implementation so far consists of a single source file only, so we might want to flatten it. Those are fine details we still can decide (and change) latter. | ||
The point of keeping a "platforms" directory is to allow backends to stay monolithic if they prefer: If, for example, it's easier for the DC backend to stay in a single file, then it shall be able to do so. Adding subdirs to the backends/MODULE/ dirs is mostly interesting if those are likely to be reused (but of course porters are welcome to do this separation anyway if they like to). | |||
== External Links == | == External Links == | ||