408
edits
Difference between revisions of "Talk:Modular Backends"
Jump to navigation
Jump to search
Added user name and time stamp to my earlier comment
Eriktorbjorn (talk | contribs) (Added user name and time stamp to my earlier comment) |
|||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
* Another candidate for modularization would be the DYNAMIC_MODULES. Right now the dynamic loading is handled by base/plugins.cpp, with #ifdefs galore. | * Another candidate for modularization would be the DYNAMIC_MODULES. Right now the dynamic loading is handled by base/plugins.cpp, with #ifdefs galore. | ||
: Fully agreed, Marcus. I am not yet 100% how that would look, but it's indeed a natural candidate. Another one probably is the config file save/load code... considering that on some targets (like DC, I believe), you can't just save a file like that... :-) [[User:Fingolfin|Fingolfin]] 23:31, 2 May 2006 (UTC) | : Fully agreed, Marcus. I am not yet 100% how that would look, but it's indeed a natural candidate. Another one probably is the config file save/load code... considering that on some targets (like DC, I believe), you can't just save a file like that... :-) [[User:Fingolfin|Fingolfin]] 23:31, 2 May 2006 (UTC) | ||
* It's outside my own personal sphere of interest - it won't make much, if any, difference to the game engines themselves, right? - but it seems like a sensible idea. And if it eventually makes it easier to put a new backend together, so much the better! | * It's outside my own personal sphere of interest - it won't make much, if any, difference to the game engines themselves, right? - but it seems like a sensible idea. And if it eventually makes it easier to put a new backend together, so much the better! [[User:Eriktorbjorn|Eriktorbjorn]] 13:18, 5 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) | * 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) | ||
| Line 15: | Line 15: | ||
::# 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 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) | ::# 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) | ||
:::Third approach looks most natural to me. With wise selection of methods to overload this looks like a cleanest solution. -- [[User:Sev|Sev]] 14:25, 8 May 2006 (UTC) | |||