Difference between revisions of "OpenTasks"

Jump to navigation Jump to search

OpenTasks (view source)

Revision as of 13:19, 10 July 2008

6 bytes added ,  13:19, 10 July 2008
m
typos
(→‎XMIDI parser: added some more info on XMidi)
m (typos)
Line 18: Line 18:
=== Some good advice ===
=== Some good advice ===
The PostgrSQL folks have some real good
The PostgrSQL folks have some real good
[http://www.postgresql.org/developer/summerofcodeadvice.html Advice to Students on Submitting SoC Applications]. We recommand all students interested in applying with us (or any other SoC project, for that matter) to read this.
[http://www.postgresql.org/developer/summerofcodeadvice.html Advice to Students on Submitting SoC Applications]. We recommend all students interested in applying with us (or any other SoC project, for that matter) to read this.


=== Student application template ===
=== Student application template ===
Line 70: Line 70:
Details, scope and further suggestions as to how to achieve this can be found on the [[Small Devices Backend]] page.
Details, scope and further suggestions as to how to achieve this can be found on the [[Small Devices Backend]] page.


Besides this, optimising code for speed and memory usage benefits all our targets. In particular these "small devices". Hence doing this is a worthy goal on its own.
Besides this, optimizing code for speed and memory usage benefits all our targets. In particular these "small devices". Hence doing this is a worthy goal on its own.


''Required Skills:''
''Required Skills:''
Line 83: Line 83:
''Background:''
''Background:''


ScummVM is a highly portable application, running on a multitude of devices, ranging from desktop PCs running Linux, Mac OS X, Windows and other systems, over game consoles like the Playstation or the Nintendo DS, down to small mobile devices like PDAs and smartphones running PalmOS, WinCE or Symbian. One key component which makes this possible is our relatively strict separation between "backend code" (which implements the device specific functionality, like graphics drawing or sound output), and "frontend code" (which implements support for certain games). These two parts are held together by a bit of middle layer code. The key API for all backends is the [http://scummvm.org/docs/doxygen/html/classOSystem.php OSystem class] (you can use it as a great starting point to figure out most of the rest of the backend API).
ScummVM is a highly portable application, running on a multitude of devices, ranging from desktop PCs running Linux, Mac OS X, Windows and other systems, over game consoles like the PlayStation or the Nintendo DS, down to small mobile devices like PDAs and smartphones running PalmOS, WinCE or Symbian. One key component which makes this possible is our relatively strict separation between "backend code" (which implements the device specific functionality, like graphics drawing or sound output), and "frontend code" (which implements support for certain games). These two parts are held together by a bit of middle layer code. The key API for all backends is the [http://scummvm.org/docs/doxygen/html/classOSystem.php OSystem class] (you can use it as a great starting point to figure out most of the rest of the backend API).


Two key components of the backend API are the game graphics (used for drawing the game graphics, surprise surprise), which are currently limited to 8bit palette mode, and the overlay graphics (used to e.g. draw the GUI, and currently either 16bit or 8bit palette, fixed at compile time). For the overlay API, it would be nice if we could support arbitrary graphics modes, e.g. also 24/32bit modes.
Two key components of the backend API are the game graphics (used for drawing the game graphics, surprise surprise), which are currently limited to 8bit palette mode, and the overlay graphics (used to e.g. draw the GUI, and currently either 16bit or 8bit palette, fixed at compile time). For the overlay API, it would be nice if we could support arbitrary graphics modes, e.g. also 24/32bit modes.
Line 91: Line 91:
''The Task:''
''The Task:''


Get rid of the evil gBitFormat variable. Instead, introduce a new Graphics::PixelFormat struct (modeled after [http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fPixelFormat SDL_PixelFormat]). Enhance Graphics::Surface to use it (similiar to [http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fSurface SDL_Surface]). Add a new getOverlayPixelFormat method to OSystem, and implement it in the SDL backend. Rewrite the GUI code and other code accessing the overlay to make use of the PixelFormat data, instead of using gBitFormat. This also includes updating some of the scalers (at least the simple ones; for the special ones, like HQ2x, we have to determine how to treat them best).
Get rid of the evil gBitFormat variable. Instead, introduce a new Graphics::PixelFormat struct (modeled after [http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fPixelFormat SDL_PixelFormat]). Enhance Graphics::Surface to use it (similar to [http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fSurface SDL_Surface]). Add a new getOverlayPixelFormat method to OSystem, and implement it in the SDL backend. Rewrite the GUI code and other code accessing the overlay to make use of the PixelFormat data, instead of using gBitFormat. This also includes updating some of the scalers (at least the simple ones; for the special ones, like HQ2x, we have to determine how to treat them best).


For all this, API flexibility has to be carefully weight against API complexity, and efficiency -- since we have to support small devices with limited resources, we don't want to needlessly waste CPU cycles nor memory.
For all this, API flexibility has to be carefully weight against API complexity, and efficiency -- since we have to support small devices with limited resources, we don't want to needlessly waste CPU cycles nor memory.
Line 150: Line 150:
''The Task:''
''The Task:''


Specifically, we require support for XMIDI_CONTROLLER_FOR_LOOP and XMIDI_CONTROLLER_NEXT_BREAK. There are many more XMIDI controllers, however, and ideally support for all would them great. Some references:
Specifically, we require support for XMIDI_CONTROLLER_FOR_LOOP and XMIDI_CONTROLLER_NEXT_BREAK. There are many more XMIDI controllers, however, and ideally support for all of them would be great. Some references:


* The XMIDI code from the [http://exult.sf.net Exult] project (see Exult's audio/midi_drivers/XMidiSequence.cpp) could be used as a reference again.
* The XMIDI code from the [http://exult.sf.net Exult] project (see Exult's audio/midi_drivers/XMidiSequence.cpp) could be used as a reference again.
* In addition, [http://pentagram.sf.net Pentagram] has XMidi code based on the Exult code, but maybe cleaner (see [http://pentagram.svn.sourceforge.net/viewvc/pentagram/pentagram/trunk/audio/midi/ here].)
* In addition, [http://pentagram.sf.net Pentagram] has XMidi code based on the Exult code, but may be cleaner (see [http://pentagram.svn.sourceforge.net/viewvc/pentagram/pentagram/trunk/audio/midi/ here].)
* Another good reference for this task is the AIL library which has been recently open-sourced by its [http://www.thegleam.com/ke5fx/ author]. This is infact where XMIDI comes from, and it even contains specs. To find them, unzip AIL2.ZIP; in there you find A214_D2.ZIP, which when unzipped contains a dir DOC, which in turn contains ASCIIDOC.ZIP, which then contains XMIDI.TXT and some other files which might be of use (e.g. NOTES.TXT).
* Another good reference for this task is the AIL library which has been recently open-sourced by its [http://www.thegleam.com/ke5fx/ author]. This is infact where XMIDI comes from, and it even contains specs. To find them, unzip AIL2.ZIP; in there you find A214_D2.ZIP, which when unzipped contains a dir DOC, which in turn contains ASCIIDOC.ZIP, which then contains XMIDI.TXT and some other files which might be of use (e.g. NOTES.TXT).


Clone2727
2,051

edits

Retrieved from "https://wiki.scummvm.org/index.php?title=Special:MobileDiff/9191"

Navigation menu