208
edits
Difference between revisions of "Small Devices Backend"
Jump to navigation
Jump to search
m
Revise content to feature some info on CPU archs and fix a few typos.
m (Revise content to feature some info on CPU archs and fix a few typos.) |
|||
| Line 11: | Line 11: | ||
* [[Dreamcast]] (?) -- no keyboard | * [[Dreamcast]] (?) -- no keyboard | ||
* [[Nintendo_DS|Nintendo DS]] -- small screen, no keyboard, low memory, two screens (interesting use for zoning?) | * [[Nintendo_DS|Nintendo DS]] -- small screen, no keyboard, low memory, two screens (interesting use for zoning?) | ||
* [[Maemo]] ( | * [[Maemo]] (Nokia 770,800 etc.) -- no keyboard, low resources, low memory(?) | ||
Additionally the Small Devices Backend could be applied to any future resource constrained platforms. Greatly assisting efforts to get ScummVM running on such platforms. | Additionally the Small Devices Backend could be applied to any future resource constrained platforms. Greatly assisting efforts to get ScummVM running on such platforms. | ||
| Line 18: | Line 18: | ||
All above devices will subclass this backend and possibly override system-specific methods, i.e.: | All above devices will subclass this backend and possibly override system-specific methods, i.e.: | ||
SmallDevices --> | SmallDevices --> WindowsCE | ||
--> PalmOS | --> PalmOS | ||
--> SymbianOS | --> SymbianOS | ||
--> GP2X | --> GP2X | ||
--> PSP | --> PSP | ||
--> | --> Maemo | ||
Most functions should be virtual, so functionality could be | Most functions should be virtual, so functionality could be overridden. An example is PSP and GP2X which have hardware scalers, and PS2 where there is a desire to implement a 3D virtual keyboard. | ||
* It should add another level of abstraction and should let lowest level functions like input and screen blitting to be overriden. For example, PalmOS and GP32 backends do not use SDL. That shouldn't be really hard, as most functionality is in place and current SDL backend performs blitting only from 2 functions. | * It should add another level of abstraction and should let lowest level functions like input and screen blitting to be overriden. For example, PalmOS and GP32 backends do not use SDL. That shouldn't be really hard, as most functionality is in place and current SDL backend performs blitting only from 2 functions. | ||
| Line 44: | Line 43: | ||
* Variable upscaler for non-standard resolutions (only used for making small fullscreen resolutions, say <=640x480. Should be done using integer math / fixed point arithmetic, since usually no FPU is available) | * Variable upscaler for non-standard resolutions (only used for making small fullscreen resolutions, say <=640x480. Should be done using integer math / fixed point arithmetic, since usually no FPU is available) | ||
* Possibility to cleanly disable unneeded scalers | * Possibility to cleanly disable unneeded scalers | ||
* | * Possibility for low-res sound (8bit, mono, probably partly implemented in main mixer code for speed) | ||
* Should hide unneeded options from GUI like MT-32, MIDI device (i.e. those which either don't make sense or are too fat for small devices) | * Should hide unneeded options from GUI like MT-32, MIDI device (i.e. those which either don't make sense or are too fat for small devices) | ||
=== CPU Architectures === | |||
Increasingly small device platforms are making use of blocks of custom code written for the underlying CPU architecture of the platform. This can be seen in the number of custom routines now available for ARM platforms within the codebase. | |||
Whist this is an aside to the main Small Device Backend work it would be very nice to look into encapsulating this code in a manageable and maintainable way. Possibly by extending the backends model to have an additional CPU architecture construct. | |||
Comments? | |||