Open main menu
ScummVM :: Wiki

Difference between revisions of "OpenTasks"

OpenTasks (view source)

Revision as of 19:40, 15 February 2009

847 bytes removed ,  19:40, 15 February 2009
→‎Generic infrastructure tasks: changed order of tasks and removed "recorded play" ideas from "Add a testing framework for ScummVM's subsystems" (as proposed by Max on -devel)
(→‎Generic infrastructure tasks: changed order of tasks and removed "recorded play" ideas from "Add a testing framework for ScummVM's subsystems" (as proposed by Max on -devel))
Line 67: Line 67:
* Excellent Makefile skills
* Excellent Makefile skills


=== Implement recorded play ===
''Technical Contact'': [[User:Sev|Eugene Sandulenko]]
''Background:''
Number of ScummVM supported games grows with each release. Since 0.8.0 we are performing extensive prerelease testing. Basically it is game replaying for finding regressions. This becomes somewhat tiresome process and takes much time.
In fact there should be no changes in the gameplay in most cases, so event recording and proper replaying should be enough. There is some code for that based on [http://sourceforge.net/tracker/index.php?func=detail&aid=1738058&group_id=37116&atid=418822 Action recorder patch], but the recordings are not played consistently. The main problem is that there is no guarantee of the events to be in sync with other engine parts, so the playback may deviate, depending on the machine speed.
''The Task:''
Implement proper event recorder and player. It should be multiplatform and not depend on the CPU power. I.e. it should ''guarantee'' proper event sequence and time. It should store mouse, keyboard events, as well as generated random numbers and any other functions dealing with extern world such as time. Basically it should be implemented as some globally blocking cycle which will be driven by recorded events.
The format should contain also ways to give name to the recording, keep a screenshot, and optional savegame, so arbitrary portions of the game could be recorded.
Additionally there should be implemented possibility to create screenshots at specified intervals, so the output could be compared.
The GUI should preferably include an overlay image which will indicate that the game is being recorded or played back. But it will require some work in backends.
Optionally there could be implemented step-by-step mode with ability to pause the playback at any place. And as a big bonus ability to annotate the recordings with on-screen messages could be also implemented.
''Required Skills:''
* Good C++ skills.
* Access to slow(er) devices such as handhelds is preferable.


=== Implemented support for loadable modules on Nintendo DS and other ports ===
=== Implemented support for loadable modules on Nintendo DS and other ports ===
Line 183: Line 156:
# Unit tests: Add many more tests to our test suite in "tests/". This would also require some enhancements to our build system, since currently we do not link against all of our code for the test suite. Also new test mechanisms are needed to make it possible to e.g. test audio & graphics output (e.g. code that can load an existing reference image and compare it to the output of a graphics primitive). It might also be helpful to enhance the "null" backend so that all unit tests can be run against that, headless (good for automated tests on a server with actual graphics/audio output.
# Unit tests: Add many more tests to our test suite in "tests/". This would also require some enhancements to our build system, since currently we do not link against all of our code for the test suite. Also new test mechanisms are needed to make it possible to e.g. test audio & graphics output (e.g. code that can load an existing reference image and compare it to the output of a graphics primitive). It might also be helpful to enhance the "null" backend so that all unit tests can be run against that, headless (good for automated tests on a server with actual graphics/audio output.
# A "test" engine: Unit tests probably would likely only be runnable on "desktop" ports like Windows and Linux, and not on ports like PSP or NDS, due to run environment restrictions. To allow extended coverage on *all* ports, [[HOWTO-Engines|implementing a "test" engine]] would be helpful. In addition to running on all ports, the "test" engine also provides an environment to test things in an integrate, non-isolated way, unlike unit tests.It should test as many features as possible: game detection, file loading/saving, navigating the file system, testing graphics and audio output, etc. -- and it must be possible to verify everything. I.e. compare results to reference data, output progress data on the screen, create dump logs, and so on. Lots can be done here.  
# A "test" engine: Unit tests probably would likely only be runnable on "desktop" ports like Windows and Linux, and not on ports like PSP or NDS, due to run environment restrictions. To allow extended coverage on *all* ports, [[HOWTO-Engines|implementing a "test" engine]] would be helpful. In addition to running on all ports, the "test" engine also provides an environment to test things in an integrate, non-isolated way, unlike unit tests.It should test as many features as possible: game detection, file loading/saving, navigating the file system, testing graphics and audio output, etc. -- and it must be possible to verify everything. I.e. compare results to reference data, output progress data on the screen, create dump logs, and so on. Lots can be done here.  
# A framework for testing actual games: At some point it would also be useful (but quite likely beyond this task) to be able to perform testing on actual games, to ensure certain bugs do not occur anymore (regression tests). This might include loading a savegame, feeeding a set of virtual user events to the game, then comparing screen snapshots, internal variables etc. to reference data.


The  test suite extension would be easiest to use on Linux etc. and there is already some existing code to build on. An test engine would work on all ports, including game consoles and phones, and is nice for testing in a more "holistic" and complete way. Of course best would be to have both, and also make it possible to run all unit test from inside the test engine.
The  test suite extension would be easiest to use on Linux etc. and there is already some existing code to build on. An test engine would work on all ports, including game consoles and phones, and is nice for testing in a more "holistic" and complete way. Of course best would be to have both, and also make it possible to run all unit test from inside the test engine.


Overall the test engine has the highest priority, since it would give us the possibility to test ''all'' ports without additional work. Thus the primary task would be to implement and document at least a test engine, which tests (preferably) all of ScummVM's subsystems extensively.
Overall the test engine has the highest priority, since it would give us the possibility to test ''all'' ports without additional work. Thus the primary task would be to implement and document at least a test engine, which tests (preferably) all of ScummVM's subsystems extensively.
Implementing a testing framework for games / game engines would also be of high interest (esp. if it worked on all ports), as many bugs we have to deal with occur on only certain tests systems. Having automated tests for these would help our porters a lot, but are also difficult to implement, and require the tester to own copies of the games to be tested. This could be considered as an alternative primary task, but would require substantially more knowledge about ScummVM.


''Required Skills:''
''Required Skills:''
Line 200: Line 170:
''Also required:''
''Also required:''
* Access to a non-desktop testing device (PSP, NDS, PS2, WinCE or Symbian mobile, etc.) and the ability to compile and run ScummVM on it (the ScummVM team would help with compiling and running).
* Access to a non-desktop testing device (PSP, NDS, PS2, WinCE or Symbian mobile, etc.) and the ability to compile and run ScummVM on it (the ScummVM team would help with compiling and running).
=== Add a testing framework for ScummVM's engines ===
''Technical Contact'': [[User:Sev|Eugene Sandulenko]]
''Background:''
Number of ScummVM supported games grows with each release. Since 0.8.0 we are performing extensive prerelease testing. Basically it is game replaying for finding regressions. This becomes somewhat tiresome process and takes much time.
In fact there should be no changes in the gameplay in most cases, so event recording and proper replaying should be enough. There is some code for that based on [http://sourceforge.net/tracker/index.php?func=detail&aid=1738058&group_id=37116&atid=418822 Action recorder patch], but the recordings are not played consistently. The main problem is that there is no guarantee of the events to be in sync with other engine parts, so the playback may deviate, depending on the machine speed.
''The Task:''
Implement proper event recorder and player. It should be multiplatform and not depend on the CPU power. I.e. it should ''guarantee'' proper event sequence and time. It should store mouse, keyboard events, as well as generated random numbers and any other functions dealing with extern world such as time. Basically it should be implemented as some globally blocking cycle which will be driven by recorded events.
The format should contain also ways to give name to the recording, keep a screenshot, and optional savegame, so arbitrary portions of the game could be recorded.
Additionally there should be implemented possibility to create screenshots at specified intervals, so the output could be compared.
The GUI should preferably include an overlay image which will indicate that the game is being recorded or played back. But it will require some work in backends.
Optionally there could be implemented step-by-step mode with ability to pause the playback at any place. And as a big bonus ability to annotate the recordings with on-screen messages could be also implemented.
''Required Skills:''
* Good C++ skills.
* Access to slow(er) devices such as handhelds is preferable.


== Audio related tasks ==
== Audio related tasks ==
LordHoto
561

edits

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