Difference between revisions of "Small Devices Backend"

From ScummVM :: Wiki
Jump to navigation Jump to search
(It should not be SDL based)
 
(15 intermediate revisions by 4 users not shown)
Line 3: Line 3:
=== Possible Targets ===
=== Possible Targets ===


* WinCE -- small screen, no keyboard
* [[Windows_CE|Windows CE]] -- small screen, no keyboard
* PalmOS -- small screen, no keyboard, low resources, low memory
* [[PalmOS]] -- small screen, no keyboard, low resources, low memory
* SymbianOS -- 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, possibility of running bits of the backend on 2nd CPU core
* PSP -- small screen, no keyboard
* [[PlayStation_Portable|PSP]] -- small screen, no keyboard
* PS2 (?) -- no keyboard
* [[PlayStation_2|PS2]] -- no keyboard
* DC (?) -- no keyboard
* [[Dreamcast]] (?) -- no keyboard
* Nokia770 -- no keyboard, low resources, low memory(?)
* [[Nintendo_DS|Nintendo DS]] -- small screen, no keyboard, low memory, two screens (interesting use for zoning?)
* [[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.


=== Structure ===
=== Structure ===
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 --> WinCE
   SmallDevices --> WindowsCE
               --> PalmOS
               --> PalmOS
               --> SymbianOS
               --> SymbianOS
               --> GP32
               --> GP2X
               --> PSP
               --> PSP
               --> Nokia770
               --> Maemo


Most functions should be virtual, so functionality could be overriden. An example is PSP which has hardware scalers, and PS2 where Lavos wants to implement 3D virtual keyboard.
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.


* 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 highly modular, so that one only has to compile and link a given module / feature if one actually needs it. So if for example a port does not need the virtual keyboard, it does not have to link it in (which would increase the binary size, a bad thing on small devices). Yet if I still need the downscalers, I should be able to use those.


=== Common Subsystems ===
=== Common Features ===


* Virtual keyboard (we need so specify an API, so backends could make their own)
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 Improvements|Virtual keyboard]]: Provide a default implementation, but offers hooks to allow for custom implementations.
* [[Keymapping Improvements|Keymapper]]: Flexible solution without relying on gameids
* Splash screen (most of ports have it, so it could be unified)
* Splash screen (most of ports have it, so it could be unified)
* Downscalers (used to display on smaller-than-game-content screens)
* 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.
* 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, obviously cannot rely on fast FPU)
* 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 disable some/all scalers, but that should be under #ifdef as PSP and PS2 have enough power
* Possibility to cleanly disable unneeded scalers
* Low-res sound (8bit, mono, probably partly implemented in main mixer code for speed)
* 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 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)
* Device specific options pages - Extend the ScummVM GUI to provide a way for a port to populate a custom options page with it's own settings. This needs to use the existing ScummVM widgets and provide a clean way for a backend to populate the page without 'define soup'. Maybe via something hooked into the backend at creation time (something that could just return a stub if no custom page was required). The DS port currently does this via defines and backend specific hooks.
 
=== 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.


=== OSystem changes ===
Comments?
* Probably it's a really good time for adding more modularity to OSystem. I.e. separate these:
** Scaling
** Input (events)
** Drawing
** Timers
** Mutexes
** Sound

Latest revision as of 19:06, 4 November 2008

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

Possible Targets

  • Windows CE -- small screen, no keyboard
  • PalmOS -- small screen, no keyboard, low resources, low memory
  • SymbianOS -- small screen, no keyboard, low resources, low memory
  • GP2X -- small screen, no keyboard, low resources, low memory, possibility of running bits of the backend on 2nd CPU core
  • PSP -- small screen, no keyboard
  • PS2 -- no keyboard
  • Dreamcast (?) -- no keyboard
  • Nintendo DS -- small screen, no keyboard, low memory, two screens (interesting use for zoning?)
  • 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.

Structure

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

 SmallDevices --> WindowsCE
              --> PalmOS
              --> SymbianOS
              --> GP2X
              --> PSP
              --> Maemo

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 be highly modular, so that one only has to compile and link a given module / feature if one actually needs it. So if for example a port does not need the virtual keyboard, it does not have to link it in (which would increase the binary size, a bad thing on small devices). Yet if I still need the downscalers, I should be able to use those.

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.
  • Keymapper: Flexible solution without relying on gameids
  • 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
  • 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)
  • Device specific options pages - Extend the ScummVM GUI to provide a way for a port to populate a custom options page with it's own settings. This needs to use the existing ScummVM widgets and provide a clean way for a backend to populate the page without 'define soup'. Maybe via something hooked into the backend at creation time (something that could just return a stub if no custom page was required). The DS port currently does this via defines and backend specific hooks.

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?