Difference between revisions of "Modular Backends"

Jump to navigation Jump to search
336 bytes added ,  15:06, 7 June 2010
no edit summary
 
(3 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 39: Line 47:
* 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 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)
* 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 45: 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/)
* Scaler code (see common/scaler*) -> we already share some scaler code, but that could probably be done in a better way, and maybe some more generic scalers could be added (e.g. a good & fast downscaler).
* Plugins


== Source layout ==
== Source layout ==
1,079

edits

Navigation menu