1,079
edits
Difference between revisions of "Modular Backends"
Jump to navigation
Jump to search
m
Typo
m (Typo) |
|||
| Line 28: | Line 28: | ||
Modularization must be done in such a way that it doesn't hurt porters -- after all it's meant to *help* them. But many ports are rather monolithic, and actually wouldn't benefit much from being modularized (e.g. the PSP, PS2, Dreamcast, etc. ports) compared to the current situation. I.e. it should be relatively pain free to transit to the new system, and not force anybody to reinvent the wheel. | Modularization must be done in such a way that it doesn't hurt porters -- after all it's meant to *help* them. But many ports are rather monolithic, and actually wouldn't benefit much from being modularized (e.g. the PSP, PS2, Dreamcast, etc. ports) compared to the current situation. I.e. it should be relatively pain free to transit to the new system, and not force anybody to reinvent the wheel. | ||
In particular, we want to avoid bloat. Implementing new backends should becomes *easier* with the module approach, not harder. So we have to try to | In particular, we want to avoid bloat. Implementing new backends should becomes *easier* with the module approach, not harder. So we have to try to avoid over design, and also should avoid breaking things down into too small bits, because then it becomes harder to maintain them. In particular, we probably still want to allow relatively "monolithic" implementations, by not forcing porters to split everything into multiple files (but maybe encouraging it). | ||
It's usually a good idea to look at how SDL manages its backends & modules. For example, graphics, input and event code are usually all found in <code>src/video/FOO</code>. | |||
== Potential modules == | == Potential modules == | ||