1,079
edits
Difference between revisions of "Talk:Modular Backends"
Jump to navigation
Jump to search
no edit summary
(Comment on Endy's not-so-pointless entry) |
|||
| Line 4: | Line 4: | ||
* I like the idea, particularly for the ease of reusing components for the Small Devices Backend. The only question is the balance between 'file bloat' and sensible organisation. As far as my comments on this, I suggest combining the Audio/Sound directories into one AV directory under backends. Eg, backends/av/sdl (/audio.cpp | video.cpp), /x11/video.cpp, /oss/audio.cpp). Going by purpose, '/backends/saves' could be moved to /backends/fs/saves in this nested hierarchy. I don't really think too many extra subdirectories under /backends/ will be needed if the files are linked by the platform build system, since the purpose of the modularised files should be clear. [[User:Ender|Ender]] 07:07, 6 May 2006 (UTC) | * I like the idea, particularly for the ease of reusing components for the Small Devices Backend. The only question is the balance between 'file bloat' and sensible organisation. As far as my comments on this, I suggest combining the Audio/Sound directories into one AV directory under backends. Eg, backends/av/sdl (/audio.cpp | video.cpp), /x11/video.cpp, /oss/audio.cpp). Going by purpose, '/backends/saves' could be moved to /backends/fs/saves in this nested hierarchy. I don't really think too many extra subdirectories under /backends/ will be needed if the files are linked by the platform build system, since the purpose of the modularised files should be clear. [[User:Ender|Ender]] 07:07, 6 May 2006 (UTC) | ||
: But there are cases when audio and video come from different sources. I.e SDL video vs custom audio (GP32) or SDL audio and direct framebuffer buffer access (PSP) --[[User:Sev|Sev]] 11:00, 6 May 2006 (UTC) | : But there are cases when audio and video come from different sources. I.e SDL video vs custom audio (GP32) or SDL audio and direct framebuffer buffer access (PSP) --[[User:Sev|Sev]] 11:00, 6 May 2006 (UTC) | ||
:: As for saves vs. fs -- those two actually have not much in common in most cases, so I don't think we should put the one "into" the other. But that's a minor point in the end. [[User:Fingolfin|Fingolfin]] 12:05, 6 May 2006 (UTC) | |||
:: Regarding Audio: The Audio API is tiny (set/clear the audo callback, query sample rate). Audio CD would be a different module anyway (I just added that to the list of module candidates). OTOH, the Graphics API is rather big compared to that. I looked at the SDL backend, it should be quite easy to untangle the audio and the video code. So I don't think we have to keep A/V code together (though I was considering of keeping video & input code together, although I am not sure if that is any better, probably not :-). [[User:Fingolfin|Fingolfin]] 12:05, 6 May 2006 (UTC) | |||
:: So, why ask for "merging" modules into bigger units? AFAIK, Ender's main concern is "file bloat", i.e. spreading things over too many modules. Why is that a problem? Well. the main issues with this, from my perspective, is that it becomes harder to look at all of the code for a single backend at once; and it's right now totally unclear how to share data & code between modules. In particular, where is the main() function and common initialisation code (think SDL_Init, SDL_VideoInit)? What if both the audio and the video code need to access a shared variable (I am not sure if that is necessary in any backend right now, but it *could* be necessary). I.e. not all modules are fully independant of each other. For the sake of a common init/deinit & main, we probably could add a new "main" module to the list (again similar to what SDL does). This would also serve as the central anchor for a given "backend composition". I.e. the code in main() probably would also be responsible for instantiating all the modules, *before* handing off control to scummvm_main. [[User:Fingolfin|Fingolfin]] 12:05, 6 May 2006 (UTC) | |||
:: Last but not least, there is OSystem::initBackend(). This method currently is necessary, because it gets called by scummvm_main *after* the command line has been parsed and the config file read. This way, backends can read/store settings in the config file, too. Without it, that wouldn't be possible. Well, we could solve this in at least three ways: | |||
::# We keep a similar method/function (but where would it be defined? Maybe passed as a param to scummvm_main?) | |||
::# We move the responsibility for parsing the command line & reading the config file to the backend. That actually makes some sense, after all, not all backends even have a command line at all, those could just not call the command line parsing code etc.. OTOH it means a bit more code duplication again. | |||
::# We turn the code in class main.cpp into a (virtual) class Main(). Backends would provide subclasses of that class. That way, backends could overload any portions of it they want, e.g. the command line parsing code, the launcher dialog code (which currently works with some #ifdefs in main.cpp), etc.. [[User:Fingolfin|Fingolfin]] 12:05, 6 May 2006 (UTC) | |||