Difference between revisions of "OpenTasks"

Jump to navigation Jump to search

OpenTasks (view source)

Revision as of 17:30, 25 February 2008

4,294 bytes removed ,  17:30, 25 February 2008
Removed some obsolete / boring tasks
(Removed some obsolete / boring tasks)
Line 48: Line 48:


== Generic infrastructure tasks ==
== Generic infrastructure tasks ==
=== Plugins ===
''Technical Contact'': [[User:Fingolfin|Max Horn]]
''Background:''
ScummVM contains by now over a dozen different engines for different adventure game systems. Each of these engines forms a "plugin", and it is possible to compile these plugins as loadable modules separate from the core of ScummVM itself. This makes it possible to (un)load engine code at will, ideal for systems with tight memory constraints; if you want to play a game, you only need to load the engine for that specific game, and can unload the others.
We always compile the engines as "plugins", but by default, they are compiled as so-called "static" plugins; these are not real plugins, but rather the engine gets compiled into the application (i.e. "static linked", hence the name), but is still treated by the rest of the application as a plugin (only that it is not dynamically loaded). Support for true "dynamic" plugin is only available on a subset of all plugins -- essentially most POSIX systems (including Linux, *BSD, Mac OS X) and the Dreamcast.
''The Task:''
There are various ways in which this plugin code could be improved:
* Add support for real "dynamic" plugins on Windows. This is currently not possible, because the ScummVM plugins rely on "backlinking" from the loaded modules to the core binary. This is not supported on Windows. There are various ways to solve this issue (use Google for more info). This is further complicated by the fact that while the interface of the *plugins* is well-defined (although not quite as well documented -- see base/plugins.h), the converse is not true -- plugins can call virtually arbitrary code within the core of ScummVM.
* Add support for "dynamic" plugins on more systems which might benefit from them.
* Improve the way we search for plugins. Right now we only look in the current directory. Should this be made configurable? On Unix, maybe /usr/share/scummvm should be searched, too? On Mac OS X, the CoreFoundation bundle API should be used to search for plugins inside the ScummVM.app bundle (which would also require the build system to be enhanced to properly bundle all plugins). Etc.


=== GUI ===
=== GUI ===
Line 185: Line 169:


This shouldn't require any deeper knowledge of the game engine. The renderer appears to be fairly well separated from the rest of the engine already.
This shouldn't require any deeper knowledge of the game engine. The renderer appears to be fairly well separated from the rest of the engine already.
=== Objectify CinE engine ===
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:Aquadran|Pawel Kolodziejski]]
''Background:''
The cinE engine started out as an external project started by [[User:Yazoo|Yaz0r]]. Originally it was written in plain C.
ScummVM is a C++ project, so we need to objectify this engine without changing/breaking its behavior.
The engine itself is well-structured, hence many functions / variables which might be good candidates for being grouped together into a C++ class are already grouped by files.
No deep knowledge of the engine internals is required, but in any case the Engine is not that big, and thus
it should be possible to learn enough about it to start working in a relatively short amount of time.
We have previously "objectified" several other engines, namely SAGA, Gob and AGI, so one can learn a lot about various approaches how to do this by tracing through our SVN repository.


=== Add 16bit graphics support to SCUMM engine ===
=== Add 16bit graphics support to SCUMM engine ===
Line 212: Line 181:


If you don't have any of the required games, there are several [http://www.scummvm.org/demos.php demos] available. A 16bit graphics demo example would be the [http://quick.mixnmojo.com/demos/ffcovedemo.zip Freddi5 demo].
If you don't have any of the required games, there are several [http://www.scummvm.org/demos.php demos] available. A 16bit graphics demo example would be the [http://quick.mixnmojo.com/demos/ffcovedemo.zip Freddi5 demo].
=== Add event recording ===
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:Fingolfin|Max Horn]]
''Background:''
All engines in ScummVM are driven by three sources of external influences (input):
* Mouse events
* Keyboard events
* Pseudo-random number generators (several, in different parts of the code)
It would be useful to have some layer in between our system-dependent backends and engines which can record these events to a file and play them back later. Time control is crucial here, since the games take some time to react to these events (i.e. you need to record when the events occured, too).
This will significantly help with regression testing, as it would be possible to make records of certain scenes that caused bugs; we can record the incorrect behavior, and then automatically run these tests to compare the recorded with the expected behavior. (How this comparision would be done precisely also needs to be determined. You could for example compare screen content).
The solution should be high-level, perhaps in the form of a custom event loop, so that all engines will be able to use it with minimal effort. (Note that the PRNGs likely are the biggest obstacle here).


== Implement "return to launcher" feature ==
== Implement "return to launcher" feature ==
Fingolfin
1,079

edits

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

Navigation menu