1,079
edits
Difference between revisions of "User:Fingolfin"
Jump to navigation
Jump to search
→Misc: added unsorted blob of random ideas / visions / TODOs
m (→Misc) |
(→Misc: added unsorted blob of random ideas / visions / TODOs) |
||
| Line 60: | Line 60: | ||
* rename scummsys.h; and/or split it (types.h, defs.h ... ?) | * rename scummsys.h; and/or split it (types.h, defs.h ... ?) | ||
* Implement a "Main" class, from which backends derive. The "Main" of each backend then would become: | * Implement a "Main" class, from which backends derive. The "Main" of each backend then would become: | ||
< | <syntax type="C++"> | ||
int main() { | int main() { | ||
Main *m = new MyCustomMain(); | Main *m = new MyCustomMain(); | ||
| Line 96: | Line 96: | ||
}; | }; | ||
</ | </syntax> | ||
* use IdeaTorrent for ScummVM? | |||
* revamp TODO page in Wiki; distinguish better between things that clearly should be done, and ideas resp. visions resp. crazy ideas... ;) | |||
* show cover art in launcher | |||
** this would only be done on "high end" systems, must be possible to disable code | |||
** we can't ship artwork directly, due to copyright concerns; so only ship artwork where it is legally possible, and otherwise allow users to setup "artwork packs" | |||
** control what artwork is shown using a config key | |||
* design a smooth cool new UI | |||
* separate launcher code even more from rest of ScummVM, to make custom launchers easier? | |||
** maybe separate launcher using MVC approach? Separate code which scans for games etc. from the presentation layer, to make it easier to write custom launchers with behavior matching that of the default launcher? | |||
* TrueType support for GUI | |||
** improved GUI experience for small devices *and* "big" devices ? | |||
** helpful for localization | |||
* Localize ScummVM | |||
** initially only to systems with 8bit encodings | |||
** investigate "full" UTF-8 encoding support. May be too muchfor small ports, though. Can we switch between both approaches during compile time? | |||
** use gettext for localization? | |||
** investigate existing localization patch(es) | |||
** translate engines as well? what about errors? | |||
* add support for saving/loading from the GMM in more engines | |||
** some engine authors claim this to be impossible. This is false stated this way; what is true is that it might be very difficult to achieve for games using scripts to control save/load. Some ideas to hack those anyway: One needs to find out which script to invoke, at which offset, with which params. | |||
*** locate scripts relative to others: "the verb script is N, then the load script is N+5" | |||
*** instead of using script *byte* offsets, use instruction offsets (automatically skips over embedded translated text messages correctly) | |||
*** ... more techniques possible ... | |||
* add support for freezing/saving/restoring/unfreezing arbitrary games at arbitrary points (even in mid-video) | |||
** very difficult, requires work on all levels: backends, engines=frontends, glue code (e.g. video player) | |||
** reward: Ability to suspend/resume ScummVM, super great for cell phones | |||
** backends could support setting offsets for "getMillis" so that the engine doesn't even notice the time shift (helpful for syncing etc.. | |||
** videos would have to store the current offset and restore accordingly | |||
** engines would have to add support saving at semi-arbitrary points in time. No script based saving! instead save full engine state | |||
** incompatible save state format compared to "native" engine save format, but far more flexible. | |||
** Drawback: Harder to use game's built in save/load :/ | |||
* Should we add a mandatory "engineid" to all ScummVM game targets? This would reduce pressure on gameid usage. Reduces requirement to load all engines just to detect which is the right one when starting a game. | |||
* Change config file "version" to a real version, not just the version of the last ScummVM to have written the file. This could then be used to track whether the file was already updated to use new features, like "engineid" | |||
* add some generic code to detect outdated config files and upgrade them. Be way of backward incompatible changes, though! Adding engineid everywhere is compatible, so is tweaking descs; but removing obsolete keys isn't. | |||
* investigate status of key (re)mapper | |||
** GUI part? non-GUI part? | |||
** does it work? | |||
** how does it work? | |||
** which backends make use of it? | |||
** for the others, what needs to be done to fix this? | |||
** what about engine support? i.e. letting engines specify which "keys" a given game wants? | |||
* why do some ARM targets not use all ARM assembler code? | |||
** maybe enable it all for ARM builds, and let ARM ports explicitly *disable* it if necessary? | |||
* merge NDS changes from branch into trunk | |||
== Wish list == | == Wish list == | ||