Difference between revisions of "Small Devices Backend"

From ScummVM :: Wiki
Jump to navigation Jump to search
(Link tot he new modular backends page)
Line 30: Line 30:


* It should be written with extensive use of #ifdefs, so if I, say, don't need a virtual keyboard or downscalers for platform Foo, I don't bloat my code.
* It should be written with extensive use of #ifdefs, so if I, say, don't need a virtual keyboard or downscalers for platform Foo, I don't bloat my code.
* It should take advantage of the [[Modulare Backends]] project.


=== Common Features ===
=== Common Features ===
Line 43: Line 45:
* Possibi for low-res sound (8bit, mono, probably partly implemented in main mixer code for speed)
* Possibi 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)
=== OSystem changes ===
Now might be a good time for making OSystem more modular. That is, instead of using subclassing,
use a "component" approach, were instead of a single monolithic backends interface, we split responsibility for
various features into several components/modules.
Possible modules include
* Drawing
* Sound (possibly allow for custom mixer implementations?)
* Input (events)
* Timers (the current code would be left as default implementation, but e.g. Morphos port could override it easily)
* Mutexes (only used when timers are involved, so could be joint with that)
* Virtual keyboard
* Filesystem code (already modular, see backends/fs/)
* SaveFileManager (already modular)
* Native MIDI drivers (already modular, backends/midi/)
* Scaler code (see common/scaler*) -> we already share some scaler code, but that could probably be done in a better way, and maybe some more generic scalers could be added (e.g. a good & fast downscaler).
Note: 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.

Revision as of 21:27, 30 April 2006

A base backend used by smaller devices with limited functionality. I.e. small screen, no keyboard, low memory, low processor etc.

Possible Targets

  • WinCE -- small screen, no keyboard
  • PalmOS -- small screen, no keyboard, low resources, low memory
  • SymbianOS -- small screen, no keyboard, low resources, low memory
  • GP32 -- small screen, no keyboard, low resources, low memory
  • GP2X -- small screen, no keyboard, low resources, low memory, posibility of running bits of the backend on 2nd CPU core
  • PSP -- small screen, no keyboard
  • PS2 (?) -- no keyboard
  • DC (?) -- no keyboard
  • DS -- small screen, no keyboard, low memory, two screens (interesting use for zoning?)
  • Nokia770 -- no keyboard, low resources, low memory(?)

Structure

All above devices will subclass this backend and possibly override system-specific methods, i.e.:

 SmallDevices --> WinCE
              --> PalmOS
              --> SymbianOS
              --> GP32
              --> GP2X
              --> PSP
              --> Nokia770

Most functions should be virtual, so functionality could be overriden. An example is PSP and GP2X which have hardware scalers, and PS2 where Lavos wants to implement 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 be written with extensive use of #ifdefs, so if I, say, don't need a virtual keyboard or downscalers for platform Foo, I don't bloat my code.

Common Features

The following is a list of features / characteristics that are common to many small device systems. Note that not all systems will use each of these, so it is important to be able to pick some of them without being forced to use/implement the others.

  • Virtual keyboard: Provide a default implementation, but offers hooks to allow for custom implementations.
  • Splash screen (most of ports have it, so it could be unified)
  • Downscalers (used to display on smaller-than-game-content screens)
  • Zoning, like used in WinCE and SymbianOS. It is a way of switching around between the main area, actions area and inventory area for devices lacking mouse or touchscreen. The position within each zone is stored when switching between them. It makes playing with joystick-like controls a lot easier. This can also be used together with showing a part of the game screen 1:1 and needing to scroll the display, instead of downscaling.
  • 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
  • Possibi 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)