https://wiki.scummvm.org/api.php?action=feedcontributions&user=BgK&feedformat=atom
ScummVM :: Wiki - User contributions [en]
2024-03-28T12:12:24Z
User contributions
MediaWiki 1.36.0
https://wiki.scummvm.org/index.php?title=Keymapper&diff=30976
Keymapper
2020-09-25T15:00:33Z
<p>BgK: wording</p>
<hr />
<div>=== Keymapper considerations ===<br />
<br />
== Basics ==<br />
* Backends define what input devices are available and with which characteristics (number of buttons, button names..).<br />
* Engines define what kind of events they expect for input handing (mouse button presses, keyboard shortcuts, custom actions..) through keymaps.<br />
* The keymapper maps the events produced by the backend in use to those that are expected by the current engine based on default bindings and user preferences.<br />
<br />
The keymapper is not limited to mapping keyboard keys, it is meant to remap any kind of event. At the moment, mouse buttons, keyboard keys and joystick/gamepad buttons events are supported.<br />
<br />
== For engine developers ==<br />
* Keymaps are defined by implementing '''MetaEngine::initKeymaps'''. Keymaps can be seen as a contract for what the engine expects in terms of events for input handing. Key combinations,.. that are not defined by keymaps cannot be used on platforms without a mouse and keyboard. For engines that don't have a keymap, the default game keymap defined in ''metaengine.cpp'' is used. Events that don't match a keymap are sent to the engine unprocessed, as they are produced by the backend.<br />
* A keymap is made of actions. Using the remap dialog users can associate these actions to events generated by the backends. When defining actions engine developers decide what happens when the action is executed. There are two options (hybrids are possible):<br />
** Generate events that match what the existing event handling the engine expects. That's easy to do. Just declare the keymap and it's done. However there are issues with this approach. An user who changes the default binding for an action does not expect the original binding to still work. Depending on how the engine is structured this also may cause key handling to be defined twice. Once in the keymap, and once in the event loop.<br />
** Generate custom actions events with meaning private to the engine (''EVENT_CUSTOM_ENGINE_ACTION_{START,END}'').<br />
<br />
<br />
: Example when reusing the existing input handling:<br />
<br />
<syntaxhighlight lang="cpp"><br />
Common::Keymap *MyEngine::initKeymap(const char *target) {<br />
Keymap *engineKeyMap = new Keymap(Keymap::kKeymapTypeGame, "my-engine");<br />
<br />
Action *act;<br />
<br />
act = new Action("TALK", _("Talk"));<br />
act->setKeyEvent(KEYCODE_t);<br />
act->addDefaultInputMapping("t");<br />
act->addDefaultInputMapping("JOY_X");<br />
engineKeyMap->addAction(act);<br />
<br />
act = new Action("USE", _("Use"));<br />
act->setKeyEvent(KEYCODE_u);<br />
act->addDefaultInputMapping("u");<br />
act->addDefaultInputMapping("JOY_Y");<br />
engineKeyMap->addAction(act);<br />
<br />
return engineKeyMap;<br />
}<br />
<br />
void MyEngine::doInput() {<br />
Common::Event event;<br />
while (_system->getEventManager()->pollEvent(event)) {<br />
switch (event.type) {<br />
case Common::EVENT_KEYDOWN:<br />
switch (event.kbd.keycode) {<br />
case Common::KEYCODE_t:<br />
doTalk();<br />
break;<br />
case Common::KEYCODE_u:<br />
doUse();<br />
break;<br />
}<br />
}<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
: Example when using custom engine actions:<br />
<br />
<syntaxhighlight lang="cpp"><br />
enum MyEngineAction {<br />
kMyActionTalk,<br />
kMyActionUse<br />
}<br />
<br />
Common::Keymap *MyEngine::initKeymap(const char *target) {<br />
Keymap *engineKeyMap = new Keymap(Keymap::kKeymapTypeGame, "my-engine");<br />
<br />
Action *act;<br />
<br />
act = new Action("TALK", _("Talk"));<br />
act->setCustomEngineActionEvent(kMyActionTalk);<br />
act->addDefaultInputMapping("t");<br />
act->addDefaultInputMapping("JOY_X");<br />
engineKeyMap->addAction(act);<br />
<br />
act = new Action("USE", _("Use"));<br />
act->setCustomEngineActionEvent(kMyActionUse);<br />
act->addDefaultInputMapping("u");<br />
act->addDefaultInputMapping("JOY_Y");<br />
engineKeyMap->addAction(act);<br />
<br />
return engineKeyMap;<br />
}<br />
<br />
void MyEngine::doInput() {<br />
Common::Event event;<br />
while (_system->getEventManager()->pollEvent(event)) {<br />
switch (event.type) {<br />
case Common::EVENT_CUSTOM_ENGINE_ACTION_START:<br />
switch ((MyEngineAction)event.customType) {<br />
case kMyActionTalk:<br />
doTalk();<br />
break;<br />
case kMyActionUse:<br />
doUse();<br />
break;<br />
}<br />
}<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
: Engines with engine-driven input handing should prefer using custom action events as this approach it is more powerful. Engines where input handling is script-driven probably have no choice but to use the first option. It's up to the engine developer to choose which is the best in each specific context.<br />
<br />
* Keymaps can be situational, thus engines may define multiple keymaps. Keymaps can be enabled / disabled at any time to select which actions are relevant for the current situation. For example for a RPG game there may be one keymap for the overworld, one for combat and one for shops. <br />
* Text input needs special care in conjunction with the keymapper. Given that keys can be remapped, players may want to remap, for example, the arrow keys to WSAD. But then when text input is required, it is no longer possible to type those letters because they map to the arrow keys. The solution to this issue is to disable the keymap that handles key shortcuts while a text input widget is focused.<br />
* Keep in mind that some ports may not have a keyboard and mouse. The default input mapping should include mapping for game controllers.<br />
<br />
== For backend developers ==<br />
* To define the available input devices, a backend needs to implement '''OSystem::getHardwareInputSet'''. The declared input devices must match the events that are produced by the backend in reaction to user input. It's best not to have any hardcoded button mapping in the backend. For example in the case of a game console with solely a gamepad as input device, when the player presses a button, the backend should send ''EVENT_JOYBUTTON_{DOWN,UP}'' events, not ''EVENT_LBUTTON{DOWN,UP}''. The keymapper will do the transformation from joystick events to mouse events if necessary.<br />
* Backends can define (or replace) default bindings for any keymap. To do so, implement '''OSystem::getKeymapperDefaultBindings'''. This can be used to make room in the default keymaps for backend specific actions, or to provide better defaults for the platform than those defined in the keymap.<br />
* Backends can define keymaps to allow players to remap the backend specific features. To do so, implement '''OSystem::getGlobalKeymaps'''. When implementing backend specific keymaps, it's best to request ''EVENT_CUSTOM_BACKEND_ACTION_{START,END}'' events in response to the user input. During event handling, ''Event::customType'' is used to recognize the action that needs to be executed.<br />
<br />
== TODO ==<br />
* Consider adding support for joystick button combos<br />
* Rework the way keyboard input is mapped to actions. Match only on the keycode and then filter on the modifiers to handle partial matches. Besides keep a list of currently started actions. When receiving a key up event, check if an end event needs to be emitted for one of the started actions ignoring the modifiers (to handle the case where the user stops pressing the modifier keys first). Additionally filter the emitted actions based on the list of currently started actions to prevent an action from being started twice at the same time by two different inputs.</div>
BgK
https://wiki.scummvm.org/index.php?title=PlayStation_3&diff=28597
PlayStation 3
2020-06-24T19:02:45Z
<p>BgK: Update the SDL repository URL</p>
<hr />
<div>{{PortFeatures|<br />
name=PlayStation 3|<br />
backend=sdl|<br />
version={{StableVersion}}|<br />
status=Maintained|<br />
mp3=yes|<br />
ogg=yes|<br />
flac=yes|<br />
uncompressed=yes|<br />
zlib=yes|<br />
plugins=no|<br />
16bits=yes|<br />
buildbot=yes|<br />
firstversion=1.4.0|<br />
maintainer=[[User:BgK|BgK]]|<br />
packager=[[User:BgK|BgK]]|<br />
pkgend=-ps3.zip|<br />
forum=10|<br />
icon=ps3|<br />
<br />
agi=yes|<br />
agos=yes|<br />
cine=yes|<br />
cruise=yes|<br />
draci=yes|<br />
drascula=yes|<br />
gob=yes|<br />
groovie=yes|<br />
kyra=yes|<br />
lure=yes|<br />
made=yes|<br />
parallaction=yes|<br />
queen=yes|<br />
saga=yes|<br />
scumm=yes|<br />
sky=yes|<br />
sword1=yes|<br />
sword2=yes|<br />
teenagent=yes|<br />
tinsel=yes|<br />
touche=yes|<br />
tucker=yes|<br />
}}<br />
<br />
== About ==<br />
ScummVM has been ported to the [[Sony]] PlayStation 3. All games are supported and *should* work, but they have not all been tested.<br />
<br />
== Installation ==<br />
<br />
=== Prerequisites ===<br />
* A homebrew enabled PlayStation 3 console. As of now that mostly means having a custom firmware installed. Obtaining and installing such a software is out of the scope of this document. Sorry, but you're on your own for that one.<br />
* At least one ScummVM supported game. The list of compatible games can be seen here: http://www.scummvm.org/compatibility/<br />
The page http://wiki.scummvm.org/index.php/Where_to_get_the_games references some places where those games can be bought. Demonstration versions for most of the supported games are downloadable on http://scummvm.org/demos/<br />
* An USB drive.<br />
<br />
=== Installing ===<br />
From a computer, download the installable package of the PS3 port from ScummVM's main site. It should be a .pkg file. Copy it to an USB drive.<br />
After having plugged the USB drive to you PS3, the installation package should appear in the XMB under the "Games > Install Package" menu. Installing it copies ScummVM and its dependencies to your PS3's hard drive. It also adds the "Games > PlayStation 3 > ScummVM" XMB entry which is to be used to launch ScummVM.<br />
<br />
== Configuring and playing games ==<br />
The user manual describes how to add games to ScummVM and launch them : http://wiki.scummvm.org/index.php/User_Manual<br />
<br />
== PlayStation 3 Specifics ==<br />
Games can be launched either from an USB drive or from the internal hard drive. The internal hard drive has better performance though.<br />
Savegames are wrote in the /hdd0/game/SCUM12000/saves folder.<br />
<br />
== Joypad button mapping ==<br />
{{PlayStation3Controls}}<br />
<br />
== Building from source ==<br />
This port of ScummVM to the PS3 is based on SDL2. It uses the open source SDK PSL1GHT.<br />
<br />
The dependencies needed to build it are :<br />
<br />
* The toolchain from https://github.com/ps3dev/ps3toolchain<br />
* SDL2 from https://github.com/bgK/sdl_psl1ght/tree/psl1ght-2.0.3<br />
* ScummVM from https://github.com/scummvm/scummvm<br />
<br />
Once all the dependencies are correctly setup, an installable package can be obtained from source by issuing the following command :<br />
<br />
./configure --host=ps3 && make ps3pkg</div>
BgK
https://wiki.scummvm.org/index.php?title=Keymapper&diff=27942
Keymapper
2020-05-30T17:56:32Z
<p>BgK: Add an item to the TODO list</p>
<hr />
<div>=== Keymapper considerations ===<br />
<br />
== Basics ==<br />
* Backends define what input devices are available and with which characteristics (number of buttons, button names..).<br />
* Engines define what kind of events they expect for input handing (mouse button presses, keyboard shortcuts, custom actions..) through keymaps.<br />
* The keymapper maps the events produced by the backend in use to those that are expected by the current engine based on default bindings and user preferences.<br />
<br />
The keymapper is not limited to mapping keyboard keys, it is meant to remap any kind of event. At the moment, mouse buttons, keyboard keys and joystick/gamepad buttons events are supported.<br />
<br />
== For engine developers ==<br />
* Keymaps are defined by implementing '''MetaEngine::initKeymaps'''. Keymaps can be seen as a contract for what the engine expects in terms of events for input handing. Key combinations,.. that are not defined by keymaps cannot be used on platforms without a mouse and keyboard. For engines that don't have a keymap, the default game keymap defined in ''metaengine.cpp'' is used. Events that don't match a keymap are sent to the engine unprocessed, as they are produced by the backend.<br />
* A keymap is made of actions. Using the remap dialog users can associate these actions to events generated by the backends. When defining actions engine developers decide what happens when the action is executed. There are two options (hybrids are possible):<br />
** Generate events that match what the existing event handling the engine expects. That's easy to do. Just declare the keymap and it's done. However there are issues with this approach. An user who changes the default binding for an action does not expect the original binding to still work. Depending on how the engine is structured this also may cause key handling to be defined twice. Once in the keymap, and once in the event loop.<br />
** Generate custom actions events with meaning private to the engine (''EVENT_CUSTOM_ENGINE_ACTION_{START,END}'').<br />
<br />
<br />
: Example when reusing the existing input handling:<br />
<br />
<syntaxhighlight lang="cpp"><br />
Common::Keymap *MyEngine::initKeymap(const char *target) {<br />
Keymap *engineKeyMap = new Keymap(Keymap::kKeymapTypeGame, "my-engine");<br />
<br />
Action *act;<br />
<br />
act = new Action("TALK", _("Talk"));<br />
act->setKeyEvent(KEYCODE_t);<br />
act->addDefaultInputMapping("t");<br />
act->addDefaultInputMapping("JOY_X");<br />
engineKeyMap->addAction(act);<br />
<br />
act = new Action("USE", _("Use"));<br />
act->setKeyEvent(KEYCODE_u);<br />
act->addDefaultInputMapping("u");<br />
act->addDefaultInputMapping("JOY_Y");<br />
engineKeyMap->addAction(act);<br />
<br />
return engineKeyMap;<br />
}<br />
<br />
void MyEngine::doInput() {<br />
Common::Event event;<br />
while (_system->getEventManager()->pollEvent(event)) {<br />
switch (event.type) {<br />
case Common::EVENT_KEYDOWN:<br />
switch (event.kbd.keycode) {<br />
case Common::KEYCODE_t:<br />
doTalk();<br />
break;<br />
case Common::KEYCODE_u:<br />
doUse();<br />
break;<br />
}<br />
}<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
: Example when using custom engine actions:<br />
<br />
<syntaxhighlight lang="cpp"><br />
enum MyEngineAction {<br />
kMyActionTalk,<br />
kMyActionUse<br />
}<br />
<br />
Common::Keymap *MyEngine::initKeymap(const char *target) {<br />
Keymap *engineKeyMap = new Keymap(Keymap::kKeymapTypeGame, "my-engine");<br />
<br />
Action *act;<br />
<br />
act = new Action("TALK", _("Talk"));<br />
act->setCustomEngineActionEvent(kMyActionTalk);<br />
act->addDefaultInputMapping("t");<br />
act->addDefaultInputMapping("JOY_X");<br />
engineKeyMap->addAction(act);<br />
<br />
act = new Action("USE", _("Use"));<br />
act->setCustomEngineActionEvent(kMyActionUse);<br />
act->addDefaultInputMapping("u");<br />
act->addDefaultInputMapping("JOY_Y");<br />
engineKeyMap->addAction(act);<br />
<br />
return engineKeyMap;<br />
}<br />
<br />
void MyEngine::doInput() {<br />
Common::Event event;<br />
while (_system->getEventManager()->pollEvent(event)) {<br />
switch (event.type) {<br />
case Common::EVENT_CUSTOM_ENGINE_ACTION_START:<br />
switch ((MyEngineAction)event.customType) {<br />
case kMyActionTalk:<br />
doTalk();<br />
break;<br />
case kMyActionUse:<br />
doUse();<br />
break;<br />
}<br />
}<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
: Engines with engine-driven input handing should prefer using custom action events as this approach it is more powerful. Engines where input handling is script-driven probably have no choice but to use the first option. It's up to the engine developer to choose which is the best in each specific context.<br />
<br />
* Keymaps can be situational, thus engines may define multiple keymaps. Keymaps can be enabled / disabled at any time to select which actions are relevant for the current situation. For example for a RPG game there may be one keymap for the overworld, one for combat and one for shops. <br />
* Text input needs special care in conjunction with the keymapper. Given that keys can be remapped, players may want to remap, for example, the arrow keys to WSAD. But then when text input is required, it is no longer possible to type those letters because they map to the arrow keys. The solution to this issue is to disable the keymap that handles key shortcuts while a text input widget is focused.<br />
<br />
== For backend developers ==<br />
* To define the available input devices, a backend need to implement '''OSystem::getHardwareInputSet'''. The declared input devices must match the events that are produced by the backend in reaction to user input. It's best not to have any hardcoded button mapping in the backend. For example in the case of a game console with solely a gamepad as input device, when the player presses a button, the backend should send ''EVENT_JOYBUTTON_{DOWN,UP}'' events, not ''EVENT_LBUTTON{DOWN,UP}''. The keymapper will do the transformation from joystick events to mouse events if necessary.<br />
* Backends can define (or replace) default bindings for any keymap. To do so, implement '''OSystem::getKeymapperDefaultBindings'''. This can be used to make room in the default keymaps for backend specific actions, or to provide better defaults for the platform than those defined in the keymap.<br />
* Backends can use keymaps as well to allow players to remap the backend specific features. To do so, implement '''OSystem::getGlobalKeymaps'''. When implementing backend specific keymaps, it's best to request ''EVENT_CUSTOM_BACKEND_ACTION_{START,END}'' events in response to the user input. During event handling, ''Event::customType'' is used to recognize the action that needs to be executed.<br />
<br />
== TODO ==<br />
* Consider adding support for joystick button combos<br />
* Rework the way keyboard input is mapped to actions. Match only on the keycode and then filter on the modifiers to handle partial matches. Besides keep a list of currently started actions. When receiving a key up event, check if an end event needs to be emitted for one of the started actions ignoring the modifiers (to handle the case where the user stops pressing the modifier keys first). Additionally filter the emitted actions based on the list of currently started actions to prevent an action from being started twice at the same time by two different inputs.</div>
BgK
https://wiki.scummvm.org/index.php?title=Keymapper&diff=27896
Keymapper
2020-05-27T13:42:13Z
<p>BgK: remove an obsolete todo</p>
<hr />
<div>=== Keymapper considerations ===<br />
<br />
== Basics ==<br />
* Backends define what input devices are available and with which characteristics (number of buttons, button names..).<br />
* Engines define what kind of events they expect for input handing (mouse button presses, keyboard shortcuts, custom actions..) through keymaps.<br />
* The keymapper maps the events produced by the backend in use to those that are expected by the current engine based on default bindings and user preferences.<br />
<br />
The keymapper is not limited to mapping keyboard keys, it is meant to remap any kind of event. At the moment, mouse buttons, keyboard keys and joystick/gamepad buttons events are supported.<br />
<br />
== For engine developers ==<br />
* Keymaps are defined by implementing '''MetaEngine::initKeymaps'''. Keymaps can be seen as a contract for what the engine expects in terms of events for input handing. Key combinations,.. that are not defined by keymaps cannot be used on platforms without a mouse and keyboard. For engines that don't have a keymap, the default game keymap defined in ''metaengine.cpp'' is used. Events that don't match a keymap are sent to the engine unprocessed, as they are produced by the backend.<br />
* A keymap is made of actions. Using the remap dialog users can associate these actions to events generated by the backends. When defining actions engine developers decide what happens when the action is executed. There are two options (hybrids are possible):<br />
** Generate events that match what the existing event handling the engine expects. That's easy to do. Just declare the keymap and it's done. However there are issues with this approach. An user who changes the default binding for an action does not expect the original binding to still work. Depending on how the engine is structured this also may cause key handling to be defined twice. Once in the keymap, and once in the event loop.<br />
** Generate custom actions events with meaning private to the engine (''EVENT_CUSTOM_ENGINE_ACTION_{START,END}'').<br />
<br />
<br />
: Example when reusing the existing input handling:<br />
<br />
<syntaxhighlight lang="cpp"><br />
Common::Keymap *MyEngine::initKeymap(const char *target) {<br />
Keymap *engineKeyMap = new Keymap(Keymap::kKeymapTypeGame, "my-engine");<br />
<br />
Action *act;<br />
<br />
act = new Action("TALK", _("Talk"));<br />
act->setKeyEvent(KEYCODE_t);<br />
act->addDefaultInputMapping("t");<br />
act->addDefaultInputMapping("JOY_X");<br />
engineKeyMap->addAction(act);<br />
<br />
act = new Action("USE", _("Use"));<br />
act->setKeyEvent(KEYCODE_u);<br />
act->addDefaultInputMapping("u");<br />
act->addDefaultInputMapping("JOY_Y");<br />
engineKeyMap->addAction(act);<br />
<br />
return engineKeyMap;<br />
}<br />
<br />
void MyEngine::doInput() {<br />
Common::Event event;<br />
while (_system->getEventManager()->pollEvent(event)) {<br />
switch (event.type) {<br />
case Common::EVENT_KEYDOWN:<br />
switch (event.kbd.keycode) {<br />
case Common::KEYCODE_t:<br />
doTalk();<br />
break;<br />
case Common::KEYCODE_u:<br />
doUse();<br />
break;<br />
}<br />
}<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
: Example when using custom engine actions:<br />
<br />
<syntaxhighlight lang="cpp"><br />
enum MyEngineAction {<br />
kMyActionTalk,<br />
kMyActionUse<br />
}<br />
<br />
Common::Keymap *MyEngine::initKeymap(const char *target) {<br />
Keymap *engineKeyMap = new Keymap(Keymap::kKeymapTypeGame, "my-engine");<br />
<br />
Action *act;<br />
<br />
act = new Action("TALK", _("Talk"));<br />
act->setCustomEngineActionEvent(kMyActionTalk);<br />
act->addDefaultInputMapping("t");<br />
act->addDefaultInputMapping("JOY_X");<br />
engineKeyMap->addAction(act);<br />
<br />
act = new Action("USE", _("Use"));<br />
act->setCustomEngineActionEvent(kMyActionUse);<br />
act->addDefaultInputMapping("u");<br />
act->addDefaultInputMapping("JOY_Y");<br />
engineKeyMap->addAction(act);<br />
<br />
return engineKeyMap;<br />
}<br />
<br />
void MyEngine::doInput() {<br />
Common::Event event;<br />
while (_system->getEventManager()->pollEvent(event)) {<br />
switch (event.type) {<br />
case Common::EVENT_CUSTOM_ENGINE_ACTION_START:<br />
switch ((MyEngineAction)event.customType) {<br />
case kMyActionTalk:<br />
doTalk();<br />
break;<br />
case kMyActionUse:<br />
doUse();<br />
break;<br />
}<br />
}<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
: Engines with engine-driven input handing should prefer using custom action events as this approach it is more powerful. Engines where input handling is script-driven probably have no choice but to use the first option. It's up to the engine developer to choose which is the best in each specific context.<br />
<br />
* Keymaps can be situational, thus engines may define multiple keymaps. Keymaps can be enabled / disabled at any time to select which actions are relevant for the current situation. For example for a RPG game there may be one keymap for the overworld, one for combat and one for shops. <br />
* Text input needs special care in conjunction with the keymapper. Given that keys can be remapped, players may want to remap, for example, the arrow keys to WSAD. But then when text input is required, it is no longer possible to type those letters because they map to the arrow keys. The solution to this issue is to disable the keymap that handles key shortcuts while a text input widget is focused.<br />
<br />
== For backend developers ==<br />
* To define the available input devices, a backend need to implement '''OSystem::getHardwareInputSet'''. The declared input devices must match the events that are produced by the backend in reaction to user input. It's best not to have any hardcoded button mapping in the backend. For example in the case of a game console with solely a gamepad as input device, when the player presses a button, the backend should send ''EVENT_JOYBUTTON_{DOWN,UP}'' events, not ''EVENT_LBUTTON{DOWN,UP}''. The keymapper will do the transformation from joystick events to mouse events if necessary.<br />
* Backends can define (or replace) default bindings for any keymap. To do so, implement '''OSystem::getKeymapperDefaultBindings'''. This can be used to make room in the default keymaps for backend specific actions, or to provide better defaults for the platform than those defined in the keymap.<br />
* Backends can use keymaps as well to allow players to remap the backend specific features. To do so, implement '''OSystem::getGlobalKeymaps'''. When implementing backend specific keymaps, it's best to request ''EVENT_CUSTOM_BACKEND_ACTION_{START,END}'' events in response to the user input. During event handling, ''Event::customType'' is used to recognize the action that needs to be executed.<br />
<br />
== TODO ==<br />
* Consider adding support for joystick button combos</div>
BgK
https://wiki.scummvm.org/index.php?title=Template:3DSControls&diff=27193
Template:3DSControls
2020-04-13T10:13:43Z
<p>BgK: Initial version</p>
<hr />
<div>{| cellspacing=0 style="width:100%; background-color: #fdfdff; border: 1px solid #6666ff; margin: 5px; padding: 0px; text-align: left;"<br />
|-<br />
|colspan=2 style=" background-color: #f0f0ff; border-bottom: none; margin: 0px; padding: 0em; text-align:center;" | &nbsp;<b><i>Game Controller Mapping:</i></b><br />
|-<br />
!align="left" style="width:25%;"|Button<br />
!align="left" style="width:75%;"|Action<br />
|-<br />
|Circle Pad||Move the cursor<br />
|-<br />
|R + Circle Pad||Slow Mouse<br />
|-<br />
|A||Left mouse button<br />
|-<br />
|B||Right mouse button<br />
|-<br />
|X||Open virtual keyboard<br />
|-<br />
|Y||ESC (skips cutscenes and such)<br />
|-<br />
|DPad||Keypad "Cursor" Keys<br />
|-<br />
|L Trigger||Toggle magnify mode on/off<br />
|-<br />
|R Trigger||Toggle hover/drag modes<br />
|-<br />
|Start||Open global main menu<br />
|-<br />
|Select||Open 3DS config menu<br />
|}<br />
<br />
<noinclude><br />
[[Category:Backend Controls]]<br />
</noinclude></div>
BgK
https://wiki.scummvm.org/index.php?title=Nintendo_3DS&diff=27192
Nintendo 3DS
2020-04-13T10:06:43Z
<p>BgK: Initial version</p>
<hr />
<div>{{PortFeatures|<br />
name=Nintendo 3DS|<br />
version={{StableVersion}}|<br />
backend=3ds|<br />
status=Maintained|<br />
mp3=yes|<br />
ogg=yes|<br />
uncompressed=yes|<br />
flac=yes|<br />
zlib=yes|<br />
plugins=yes|<br />
16bits=yes|<br />
buildbot=yes|<br />
firstversion=2.1.1|<br />
maintainer=[[User:BgK|bgK]]|<br />
packager=[[User:BgK|bgK]]|<br />
pkgend=-3ds.zip|<br />
icon=3ds|<br />
forum=10|<br />
notes=|<br />
<br />
agi=yes|<br />
agos=yes|<br />
cine=yes|<br />
cruise=yes|<br />
draci=yes|<br />
drascula=yes|<br />
gob=yes|<br />
groovie=yes|<br />
kyra=yes|<br />
lure=yes|<br />
made=yes|<br />
parallaction=yes|<br />
queen=yes|<br />
saga=yes|<br />
scumm=yes|<br />
sky=yes|<br />
sword1=yes|<br />
sword2=yes|<br />
teenagent=yes|<br />
tinsel=yes|<br />
touche=yes|<br />
tucker=yes|<br />
}}<br />
<br />
== Installation ==<br />
There are two possible formats to be used: 3DSX and CIA.<br />
The 3DSX format is considered more ethical because it does not make use of <br />
invalid title IDs, which get logged. It is also compatible with homebrew loading<br />
methods that do not involve CFW.<br />
The 3DSX format is exclusively used by the Homebrew Launcher and its derivatives.<br />
The CIA format can be installed directly to the 3DS home menu and can be launched<br />
using any CFW (Custom Firmware) of your choice.<br />
<br />
Installing the Homebrew Launcher or any CFW is beyond the scope of this page.<br />
<br />
=== 3DSX installation ===<br />
You need to merely extract the ScummVM 3DSX files to your SD card so that all <br />
files reside in the <code>/3ds/scummvm/</code> directory. It can then be launched by Homebrew Launcher<br />
or a similar implementation.<br />
<br />
=== CIA installation ===<br />
The CIA format requires a DSP binary dump saved on your SD card as <code>/3ds/dspfirm.cdc</code><br />
for proper audio support. You can search online to find software to dump this.<br />
Not having this file will cause many problems with games that need audio, sometimes<br />
even crashing, so this is NOT considered optional.<br />
<br />
Using any CIA installation software (search elsewhere for that), you need to install<br />
the <code>scummvm.cia</code> file.<br />
<br />
== Controls ==<br />
=== Default key mappings ===<br />
<br />
The key mappings can be customized in the options dialog for the global mappings,<br />
and in the edit game dialog for per-game mappings. Per-game mappings overlay the<br />
global mappings, so if a button is bound to an action twice, the per-game mapping<br />
wins.<br />
<br />
The default keymap is:<br />
{{3DSControls}}<br />
<br />
=== Hover mode ===<br />
When you use the touchscreen, you are simulating the mere moving of the mouse. You<br />
can click only with taps, meaning it is impossible to drag stuff or hold down a<br />
mouse button without using buttons mapped to right/left-click.<br />
<br />
=== Drag mode ===<br />
Every time you touch and release the touchscreen, you are simulating the click and<br />
release of the mouse buttons. At the moment, this is only a left-click.<br />
<br />
=== Magnify mode ===<br />
Due to the low resolutions of the 3DS's two screens (400x240 for the top, and 320x240<br />
for the bottom), games that run at a higher resolution will inevitably lose some visual<br />
detail from being scaled down. This can result in situations where essential information<br />
is undiscernable, such as text. Magnify mode increases the scale factor of the top screen<br />
back to 1; the bottom screen remains unchanged. The touchscreen can then be used to change<br />
which part of the game display is being magnified. This can all be done even in situations<br />
where the cursor is disabled, such as during full-motion video (FMV) segments.<br />
<br />
When activating magnify mode, touchscreen controls are automatically switched to hover<br />
mode; this is to reduce the risk of the user accidentally inputting a click when changing<br />
the magnified area via dragging the stylus. Clicking can still be done at will as in normal<br />
hover mode. Turning off magnify mode will revert controls back to what was being used<br />
previously (ex: if drag mode was in use prior to activating magnify mode, drag mode will<br />
be reactivated upon exiting magnify mode), as well as restore the top screen's previous<br />
scale factor.<br />
<br />
Currently magnify mode can only be used when the following conditions are met:<br />
* In the 3DS config menu, "Use Screen" is set to "Both"<br />
* A game is currently being played<br />
* The horizontal and/or vertical resolution in-game is greater than that of the top screen<br />
<br />
Magnify mode cannot be used in the Launcher menu.<br />
<br />
== Supported Games ==<br />
While all the games should run on the 3DS (report if they do not), there are<br />
many games which are unplayable due to the lack of CPU speed on the 3DS. So if<br />
you play any games that run really slow, this is not considered a bug, but rather<br />
a hardware limitation.<br />
<br />
The New 3DS console has much better performance, but there are still many newer and<br />
high-resolution games that cannot be played. A list of these unplayable games and<br />
game engines will eventually be listed here.<br />
<br />
== Compiling ==<br />
=== Prerequisites ===<br />
* Latest version of devkitPro, which comes with devkitARM and <code>libctru</code><br />
* <code>citro3d</code> thorugh devkitPro's pacman<br />
* Optional: You should compile third-party libraries for the 3ds (commonly referred to as portlibs in the devkitPRO community). Some games requires these to operate properly.<br />
<br />
=== Compiling third-party libraries ===<br />
It is strongly recommended that you use devkitPro's pacman in order to get the most recent<br />
portlibs for your build.<br />
<br />
The following libraries can be downloaded with pacman:<br />
<br />
{|class="wikitable"<br />
! Library || Package <br />
|-<br />
| zlib || 3ds-zlib <br />
|-<br />
| libpng || 3ds-libpng <br />
|-<br />
| libjpeg || 3ds-libjpeg-turbo <br />
|-<br />
| freetype2 || 3ds-freetype <br />
|-<br />
| libmad || 3ds-libmad <br />
|-<br />
| libogg || 3ds-libogg <br />
|-<br />
| tremor || 3ds-libvorbisidec <br />
|-<br />
| flac || 3ds-flac <br />
|-<br />
| curl || 3ds-curl <br />
|}<br />
<br />
At the moment of writing, the version of <code>freetype2</code> packaged by devkitPro has an issue<br />
where it allocates too much data on the stack when ScummVM loads GUI themes.<br />
As a workaround, an older version can be used. Version 2.6.5 is known to work well. The<br />
instructions below can be used to compile it.<br />
<br />
At the moment of writing, <code>faad</code> is not in the devkitPro 3DS pacman repository. It<br />
can be compiled by following the instructions in the section below, in case it cannot<br />
be found through pacman.<br />
<br />
The following pacman packages are also recommended:<br />
* <code>3ds-dev</code><br />
* <code>devkitpro-pkgbuild-helpers</code><br />
<br />
Once you have the <code>devkitpro-pkgbuild-helpers</code> package, you should be able to find<br />
the following scripts in your <code>/opt/devkitpro</code> folder:<br />
* <code>devkitarm.sh</code><br />
* <code>3dsvars.sh</code><br />
<br />
Run them one after the other with `source` in order to setup your environment variables<br />
for cross-compiling:<br />
<syntaxhighlight lang="bash"><br />
source /opt/devkitpro/devkitarm.sh<br />
source /opt/devkitpro/3dsvars.sh<br />
</syntaxhighlight><br />
<br />
After that, you can download the libraries you want to cross compile, run any autoconf<br />
scripts that they may have, and then they can usually be built with the following steps<br />
from their source directory:<br />
<br />
<syntaxhighlight lang="bash"><br />
mkdir -p $PORTLIBS<br />
./configure --prefix=$PORTLIBS --host=arm-none-eabi --disable-shared --enable-static<br />
make<br />
make install<br />
</syntaxhighlight><br />
<br />
Most libraries used can be compiled with same commands and configuration flags.<br />
<br />
=== Manually setting up the environment ===<br />
In case you don't have the helpers package downloaded, you can use the following to set-up<br />
your environment variables.<br />
<br />
It is assumed that you have these variables already set up. If not, then do so:<br />
{|class="wikitable"<br />
| DEVKITPRO || Your root devkitPro directory<br />
|-<br />
| DEVKITARM || Your root devkitARM directory (probably same as $DEVKITPRO/devkitARM)<br />
|-<br />
| CTRULIB || Your root libctru directory (probably same as $DEVKITPRO/libctru) <br />
|}<br />
<br />
In the source directory of the library:<br />
<syntaxhighlight lang="bash"><br />
export PORTLIBS=$DEVKITPRO/portlibs/3ds<br />
export PATH=$DEVKITARM/bin:$PATH<br />
export PKG_CONFIG_PATH=$PORTLIBS/lib/pkgconfig<br />
export PKG_CONFIG_LIBDIR=$PORTLIBS/lib/pkgconfig<br />
export CFLAGS="-g -march=armv6k -mtune=mpcore -mfloat-abi=hard -O2<br />
-mword-relocations -ffunction-sections -fdata-sections"<br />
export CPPFLAGS="-I$PORTLIBS/include -I$CTRULIB/include"<br />
export LDFLAGS="-L$PORTLIBS/lib"<br />
</syntaxhighlight><br />
<br />
== Compiling ScummVM ==<br />
Do the following in a fresh terminal.<br />
<br />
In case you get a "compiler not found" message, add the toolchain's executables to your PATH:<br />
<syntaxhighlight lang="bash"><br />
export PATH=$DEVKITARM/bin:$PATH<br />
</syntaxhighlight><br />
<br />
Note: In more recent codebases of ScummVM, you may or may not need to set the following beforehand:<br />
<syntaxhighlight lang="bash"><br />
export PKG_CONFIG_LIBDIR=$PORTLIBS/lib/pkgconfig<br />
</syntaxhighlight><br />
See above for <code>$PORTLIBS</code>.<br />
<br />
ScummVM doesn't provide the CA certificates bundle required by the cloud synchronization features.<br />
You need to download it from the curl website: https://curl.haxx.se/ca/cacert.pem, and instruct<br />
the build system to package it in the binary:<br />
<syntaxhighlight lang="bash"><br />
export DIST_3DS_EXTRA_FILES=/path/to/cacert.pem<br />
</syntaxhighlight><br />
The name of the file must be <code>cacert.pem</code>.<br />
<br />
From the root of the scummvm repository:<br />
<syntaxhighlight lang="bash"><br />
./configure --host=3ds --enable-plugins --default-dynamic<br />
make<br />
</syntaxhighlight><br />
<br />
Additionally compile to specific formats to be used on the 3DS:<br />
<syntaxhighlight lang="bash"><br />
make scummvm.3dsx<br />
make scummvm.cia<br />
</syntaxhighlight><br />
<br />
Assuming everything was successful, you'll be able to find the binary<br />
files in the root of your scummvm folder.<br />
<br />
Note: for the CIA format, you will need the <code>makerom</code> and <code>bannertool</code> tools which are<br />
not supplied with devkitPro.<br />
<br />
Note: using dynamic plugins as suggested is required when building with most or all of the<br />
game engines enabled in order to keep the memory usage low and avoid stability issues.</div>
BgK
https://wiki.scummvm.org/index.php?title=Keymapper&diff=26694
Keymapper
2020-03-03T18:57:22Z
<p>BgK: remove completed todos</p>
<hr />
<div>=== Keymapper considerations ===<br />
<br />
== Basics ==<br />
* Backends define what input devices are available and with which characteristics (number of buttons, button names..).<br />
* Engines define what kind of events they expect for input handing (mouse button presses, keyboard shortcuts, custom actions..) through keymaps.<br />
* The keymapper maps the events produced by the backend in use to those that are expected by the current engine based on default bindings and user preferences.<br />
<br />
The keymapper is not limited to mapping keyboard keys, it is meant to remap any kind of event. At the moment, mouse buttons, keyboard keys and joystick/gamepad buttons events are supported.<br />
<br />
== For engine developers ==<br />
* Keymaps are defined by implementing '''MetaEngine::initKeymaps'''. Keymaps can be seen as a contract for what the engine expects in terms of events for input handing. Key combinations,.. that are not defined by keymaps cannot be used on platforms without a mouse and keyboard. For engines that don't have a keymap, the default game keymap defined in ''metaengine.cpp'' is used. Events that don't match a keymap are sent to the engine unprocessed, as they are produced by the backend.<br />
* A keymap is made of actions. Using the remap dialog users can associate these actions to events generated by the backends. When defining actions engine developers decide what happens when the action is executed. There are two options (hybrids are possible):<br />
** Generate events that match what the existing event handling the engine expects. That's easy to do. Just declare the keymap and it's done. However there are issues with this approach. An user who changes the default binding for an action does not expect the original binding to still work. Depending on how the engine is structured this also may cause key handling to be defined twice. Once in the keymap, and once in the event loop.<br />
** Generate custom actions events with meaning private to the engine (''EVENT_CUSTOM_ENGINE_ACTION_{START,END}'').<br />
<br />
<br />
: Example when reusing the existing input handling:<br />
<br />
<syntaxhighlight lang="cpp"><br />
Common::Keymap *MyEngine::initKeymap(const char *target) {<br />
Keymap *engineKeyMap = new Keymap(Keymap::kKeymapTypeGame, "my-engine");<br />
<br />
Action *act;<br />
<br />
act = new Action("TALK", _("Talk"));<br />
act->setKeyEvent(KEYCODE_t);<br />
act->addDefaultInputMapping("t");<br />
act->addDefaultInputMapping("JOY_X");<br />
engineKeyMap->addAction(act);<br />
<br />
act = new Action("USE", _("Use"));<br />
act->setKeyEvent(KEYCODE_u);<br />
act->addDefaultInputMapping("u");<br />
act->addDefaultInputMapping("JOY_Y");<br />
engineKeyMap->addAction(act);<br />
<br />
return engineKeyMap;<br />
}<br />
<br />
void MyEngine::doInput() {<br />
Common::Event event;<br />
while (_system->getEventManager()->pollEvent(event)) {<br />
switch (event.type) {<br />
case Common::EVENT_KEYDOWN:<br />
switch (event.kbd.keycode) {<br />
case Common::KEYCODE_t:<br />
doTalk();<br />
break;<br />
case Common::KEYCODE_u:<br />
doUse();<br />
break;<br />
}<br />
}<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
: Example when using custom engine actions:<br />
<br />
<syntaxhighlight lang="cpp"><br />
enum MyEngineAction {<br />
kMyActionTalk,<br />
kMyActionUse<br />
}<br />
<br />
Common::Keymap *MyEngine::initKeymap(const char *target) {<br />
Keymap *engineKeyMap = new Keymap(Keymap::kKeymapTypeGame, "my-engine");<br />
<br />
Action *act;<br />
<br />
act = new Action("TALK", _("Talk"));<br />
act->setCustomEngineActionEvent(kMyActionTalk);<br />
act->addDefaultInputMapping("t");<br />
act->addDefaultInputMapping("JOY_X");<br />
engineKeyMap->addAction(act);<br />
<br />
act = new Action("USE", _("Use"));<br />
act->setCustomEngineActionEvent(kMyActionUse);<br />
act->addDefaultInputMapping("u");<br />
act->addDefaultInputMapping("JOY_Y");<br />
engineKeyMap->addAction(act);<br />
<br />
return engineKeyMap;<br />
}<br />
<br />
void MyEngine::doInput() {<br />
Common::Event event;<br />
while (_system->getEventManager()->pollEvent(event)) {<br />
switch (event.type) {<br />
case Common::EVENT_CUSTOM_ENGINE_ACTION_START:<br />
switch ((MyEngineAction)event.customType) {<br />
case kMyActionTalk:<br />
doTalk();<br />
break;<br />
case kMyActionUse:<br />
doUse();<br />
break;<br />
}<br />
}<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
: Engines with engine-driven input handing should prefer using custom action events as this approach it is more powerful. Engines where input handling is script-driven probably have no choice but to use the first option. It's up to the engine developer to choose which is the best in each specific context.<br />
<br />
* Keymaps can be situational, thus engines may define multiple keymaps. Keymaps can be enabled / disabled at any time to select which actions are relevant for the current situation. For example for a RPG game there may be one keymap for the overworld, one for combat and one for shops. <br />
* Text input needs special care in conjunction with the keymapper. Given that keys can be remapped, players may want to remap, for example, the arrow keys to WSAD. But then when text input is required, it is no longer possible to type those letters because they map to the arrow keys. The solution to this issue is to disable the keymap that handles key shortcuts while a text input widget is focused.<br />
<br />
== For backend developers ==<br />
* To define the available input devices, a backend need to implement '''OSystem::getHardwareInputSet'''. The declared input devices must match the events that are produced by the backend in reaction to user input. It's best not to have any hardcoded button mapping in the backend. For example in the case of a game console with solely a gamepad as input device, when the player presses a button, the backend should send ''EVENT_JOYBUTTON_{DOWN,UP}'' events, not ''EVENT_LBUTTON{DOWN,UP}''. The keymapper will do the transformation from joystick events to mouse events if necessary.<br />
* Backends can define (or replace) default bindings for any keymap. To do so, implement '''OSystem::getKeymapperDefaultBindings'''. This can be used to make room in the default keymaps for backend specific actions, or to provide better defaults for the platform than those defined in the keymap.<br />
* Backends can use keymaps as well to allow players to remap the backend specific features. To do so, implement '''OSystem::getGlobalKeymaps'''. When implementing backend specific keymaps, it's best to request ''EVENT_CUSTOM_BACKEND_ACTION_{START,END}'' events in response to the user input. During event handling, ''Event::customType'' is used to recognize the action that needs to be executed.<br />
<br />
== TODO ==<br />
* Consider allowing to configure input repeat on a per-action basis to simulate keyboard key repeat<br />
* Consider adding support for joystick button combos</div>
BgK
https://wiki.scummvm.org/index.php?title=Keymapper&diff=26113
Keymapper
2020-02-09T06:07:39Z
<p>BgK: Add a TODO paragraph</p>
<hr />
<div>=== Keymapper considerations ===<br />
<br />
== Basics ==<br />
* Backends define what input devices are available and with which characteristics (number of buttons, button names..).<br />
* Engines define what kind of events they expect for input handing (mouse button presses, keyboard shortcuts, custom actions..) through keymaps.<br />
* The keymapper maps the events produced by the backend in use to those that are expected by the current engine based on default bindings and user preferences.<br />
<br />
The keymapper is not limited to mapping keyboard keys, it is meant to remap any kind of event. At the moment, mouse buttons, keyboard keys and joystick/gamepad buttons events are supported.<br />
<br />
== For engine developers ==<br />
* Keymaps are defined by implementing '''MetaEngine::initKeymaps'''. Keymaps can be seen as a contract for what the engine expects in terms of events for input handing. Key combinations,.. that are not defined by keymaps cannot be used on platforms without a mouse and keyboard. For engines that don't have a keymap, the default game keymap defined in ''metaengine.cpp'' is used. Events that don't match a keymap are sent to the engine unprocessed, as they are produced by the backend.<br />
* A keymap is made of actions. Using the remap dialog users can associate these actions to events generated by the backends. When defining actions engine developers decide what happens when the action is executed. There are two options (hybrids are possible):<br />
** Generate events that match what the existing event handling the engine expects. That's easy to do. Just declare the keymap and it's done. However there are issues with this approach. An user who changes the default binding for an action does not expect the original binding to still work. Depending on how the engine is structured this also may cause key handling to be defined twice. Once in the keymap, and once in the event loop.<br />
** Generate custom actions events with meaning private to the engine (''EVENT_CUSTOM_ENGINE_ACTION_{START,END}'').<br />
<br />
<br />
: Example when reusing the existing input handling:<br />
<br />
<syntaxhighlight lang="cpp"><br />
Common::Keymap *MyEngine::initKeymap(const char *target) {<br />
Keymap *engineKeyMap = new Keymap(Keymap::kKeymapTypeGame, "my-engine");<br />
<br />
Action *act;<br />
<br />
act = new Action("TALK", _("Talk"));<br />
act->setKeyEvent(KEYCODE_t);<br />
act->addDefaultInputMapping("t");<br />
act->addDefaultInputMapping("JOY_X");<br />
engineKeyMap->addAction(act);<br />
<br />
act = new Action("USE", _("Use"));<br />
act->setKeyEvent(KEYCODE_u);<br />
act->addDefaultInputMapping("u");<br />
act->addDefaultInputMapping("JOY_Y");<br />
engineKeyMap->addAction(act);<br />
<br />
return engineKeyMap;<br />
}<br />
<br />
void MyEngine::doInput() {<br />
Common::Event event;<br />
while (_system->getEventManager()->pollEvent(event)) {<br />
switch (event.type) {<br />
case Common::EVENT_KEYDOWN:<br />
switch (event.kbd.keycode) {<br />
case Common::KEYCODE_t:<br />
doTalk();<br />
break;<br />
case Common::KEYCODE_u:<br />
doUse();<br />
break;<br />
}<br />
}<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
: Example when using custom engine actions:<br />
<br />
<syntaxhighlight lang="cpp"><br />
enum MyEngineAction {<br />
kMyActionTalk,<br />
kMyActionUse<br />
}<br />
<br />
Common::Keymap *MyEngine::initKeymap(const char *target) {<br />
Keymap *engineKeyMap = new Keymap(Keymap::kKeymapTypeGame, "my-engine");<br />
<br />
Action *act;<br />
<br />
act = new Action("TALK", _("Talk"));<br />
act->setCustomEngineActionEvent(kMyActionTalk);<br />
act->addDefaultInputMapping("t");<br />
act->addDefaultInputMapping("JOY_X");<br />
engineKeyMap->addAction(act);<br />
<br />
act = new Action("USE", _("Use"));<br />
act->setCustomEngineActionEvent(kMyActionUse);<br />
act->addDefaultInputMapping("u");<br />
act->addDefaultInputMapping("JOY_Y");<br />
engineKeyMap->addAction(act);<br />
<br />
return engineKeyMap;<br />
}<br />
<br />
void MyEngine::doInput() {<br />
Common::Event event;<br />
while (_system->getEventManager()->pollEvent(event)) {<br />
switch (event.type) {<br />
case Common::EVENT_CUSTOM_ENGINE_ACTION_START:<br />
switch ((MyEngineAction)event.customType) {<br />
case kMyActionTalk:<br />
doTalk();<br />
break;<br />
case kMyActionUse:<br />
doUse();<br />
break;<br />
}<br />
}<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
: Engines with engine-driven input handing should prefer using custom action events as this approach it is more powerful. Engines where input handling is script-driven probably have no choice but to use the first option. It's up to the engine developer to choose which is the best in each specific context.<br />
<br />
* Keymaps can be situational, thus engines may define multiple keymaps. Keymaps can be enabled / disabled at any time to select which actions are relevant for the current situation. For example for a RPG game there may be one keymap for the overworld, one for combat and one for shops. <br />
* Text input needs special care in conjunction with the keymapper. Given that keys can be remapped, players may want to remap, for example, the arrow keys to WSAD. But then when text input is required, it is no longer possible to type those letters because they map to the arrow keys. The solution to this issue is to disable the keymap that handles key shortcuts while a text input widget is focused.<br />
<br />
== For backend developers ==<br />
* To define the available input devices, a backend need to implement '''OSystem::getHardwareInputSet'''. The declared input devices must match the events that are produced by the backend in reaction to user input. It's best not to have any hardcoded button mapping in the backend. For example in the case of a game console with solely a gamepad as input device, when the player presses a button, the backend should send ''EVENT_JOYBUTTON_{DOWN,UP}'' events, not ''EVENT_LBUTTON{DOWN,UP}''. The keymapper will do the transformation from joystick events to mouse events if necessary.<br />
* Backends can define (or replace) default bindings for any keymap. To do so, implement '''OSystem::getKeymapperDefaultBindings'''. This can be used to make room in the default keymaps for backend specific actions, or to provide better defaults for the platform than those defined in the keymap.<br />
* Backends can use keymaps as well to allow players to remap the backend specific features. To do so, implement '''OSystem::getGlobalKeymaps'''. When implementing backend specific keymaps, it's best to request ''EVENT_CUSTOM_BACKEND_ACTION_{START,END}'' events in response to the user input. During event handling, ''Event::customType'' is used to recognize the action that needs to be executed.<br />
<br />
== TODO ==<br />
* Show the keymaps tab in the in-game options dialog<br />
* Rework the "virtual mouse cursor" for it can be remapped by the keymapper<br />
* Consider allowing to configure input repeat on a per-action basis to simulate keyboard key repeat<br />
* Consider adding support for joystick button combos</div>
BgK
https://wiki.scummvm.org/index.php?title=Keymapper&diff=26012
Keymapper
2020-02-01T15:12:40Z
<p>BgK: Formatting</p>
<hr />
<div>=== Keymapper considerations ===<br />
<br />
== Basics ==<br />
* Backends define what input devices are available and with which characteristics (number of buttons, button names..).<br />
* Engines define what kind of events they expect for input handing (mouse button presses, keyboard shortcuts, custom actions..) through keymaps.<br />
* The keymapper maps the events produced by the backend in use to those that are expected by the current engine based on default bindings and user preferences.<br />
<br />
The keymapper is not limited to mapping keyboard keys, it is meant to remap any kind of event. At the moment, mouse buttons, keyboard keys and joystick/gamepad buttons events are supported.<br />
<br />
== For engine developers ==<br />
* Keymaps are defined by implementing '''MetaEngine::initKeymaps'''. Keymaps can be seen as a contract for what the engine expects in terms of events for input handing. Key combinations,.. that are not defined by keymaps cannot be used on platforms without a mouse and keyboard. For engines that don't have a keymap, the default game keymap defined in ''metaengine.cpp'' is used. Events that don't match a keymap are sent to the engine unprocessed, as they are produced by the backend.<br />
* A keymap is made of actions. Using the remap dialog users can associate these actions to events generated by the backends. When defining actions engine developers decide what happens when the action is executed. There are two options (hybrids are possible):<br />
** Generate events that match what the existing event handling the engine expects. That's easy to do. Just declare the keymap and it's done. However there are issues with this approach. An user who changes the default binding for an action does not expect the original binding to still work. Depending on how the engine is structured this also may cause key handling to be defined twice. Once in the keymap, and once in the event loop.<br />
** Generate custom actions events with meaning private to the engine (''EVENT_CUSTOM_ENGINE_ACTION_{START,END}'').<br />
<br />
<br />
: Example when reusing the existing input handling:<br />
<br />
<syntaxhighlight lang="cpp"><br />
Common::Keymap *MyEngine::initKeymap(const char *target) {<br />
Keymap *engineKeyMap = new Keymap(Keymap::kKeymapTypeGame, "my-engine");<br />
<br />
Action *act;<br />
<br />
act = new Action("TALK", _("Talk"));<br />
act->setKeyEvent(KEYCODE_t);<br />
act->addDefaultInputMapping("t");<br />
act->addDefaultInputMapping("JOY_X");<br />
engineKeyMap->addAction(act);<br />
<br />
act = new Action("USE", _("Use"));<br />
act->setKeyEvent(KEYCODE_u);<br />
act->addDefaultInputMapping("u");<br />
act->addDefaultInputMapping("JOY_Y");<br />
engineKeyMap->addAction(act);<br />
<br />
return engineKeyMap;<br />
}<br />
<br />
void MyEngine::doInput() {<br />
Common::Event event;<br />
while (_system->getEventManager()->pollEvent(event)) {<br />
switch (event.type) {<br />
case Common::EVENT_KEYDOWN:<br />
switch (event.kbd.keycode) {<br />
case Common::KEYCODE_t:<br />
doTalk();<br />
break;<br />
case Common::KEYCODE_u:<br />
doUse();<br />
break;<br />
}<br />
}<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
: Example when using custom engine actions:<br />
<br />
<syntaxhighlight lang="cpp"><br />
enum MyEngineAction {<br />
kMyActionTalk,<br />
kMyActionUse<br />
}<br />
<br />
Common::Keymap *MyEngine::initKeymap(const char *target) {<br />
Keymap *engineKeyMap = new Keymap(Keymap::kKeymapTypeGame, "my-engine");<br />
<br />
Action *act;<br />
<br />
act = new Action("TALK", _("Talk"));<br />
act->setCustomEngineActionEvent(kMyActionTalk);<br />
act->addDefaultInputMapping("t");<br />
act->addDefaultInputMapping("JOY_X");<br />
engineKeyMap->addAction(act);<br />
<br />
act = new Action("USE", _("Use"));<br />
act->setCustomEngineActionEvent(kMyActionUse);<br />
act->addDefaultInputMapping("u");<br />
act->addDefaultInputMapping("JOY_Y");<br />
engineKeyMap->addAction(act);<br />
<br />
return engineKeyMap;<br />
}<br />
<br />
void MyEngine::doInput() {<br />
Common::Event event;<br />
while (_system->getEventManager()->pollEvent(event)) {<br />
switch (event.type) {<br />
case Common::EVENT_CUSTOM_ENGINE_ACTION_START:<br />
switch ((MyEngineAction)event.customType) {<br />
case kMyActionTalk:<br />
doTalk();<br />
break;<br />
case kMyActionUse:<br />
doUse();<br />
break;<br />
}<br />
}<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
: Engines with engine-driven input handing should prefer using custom action events as this approach it is more powerful. Engines where input handling is script-driven probably have no choice but to use the first option. It's up to the engine developer to choose which is the best in each specific context.<br />
<br />
* Keymaps can be situational, thus engines may define multiple keymaps. Keymaps can be enabled / disabled at any time to select which actions are relevant for the current situation. For example for a RPG game there may be one keymap for the overworld, one for combat and one for shops. <br />
* Text input needs special care in conjunction with the keymapper. Given that keys can be remapped, players may want to remap, for example, the arrow keys to WSAD. But then when text input is required, it is no longer possible to type those letters because they map to the arrow keys. The solution to this issue is to disable the keymap that handles key shortcuts while a text input widget is focused.<br />
<br />
== For backend developers ==<br />
* To define the available input devices, a backend need to implement '''OSystem::getHardwareInputSet'''. The declared input devices must match the events that are produced by the backend in reaction to user input. It's best not to have any hardcoded button mapping in the backend. For example in the case of a game console with solely a gamepad as input device, when the player presses a button, the backend should send ''EVENT_JOYBUTTON_{DOWN,UP}'' events, not ''EVENT_LBUTTON{DOWN,UP}''. The keymapper will do the transformation from joystick events to mouse events if necessary.<br />
* Backends can define (or replace) default bindings for any keymap. To do so, implement '''OSystem::getKeymapperDefaultBindings'''. This can be used to make room in the default keymaps for backend specific actions, or to provide better defaults for the platform than those defined in the keymap.<br />
* Backends can use keymaps as well to allow players to remap the backend specific features. To do so, implement '''OSystem::getGlobalKeymaps'''. When implementing backend specific keymaps, it's best to request ''EVENT_CUSTOM_BACKEND_ACTION_{START,END}'' events in response to the user input. During event handling, ''Event::customType'' is used to recognize the action that needs to be executed.</div>
BgK
https://wiki.scummvm.org/index.php?title=Keymapper&diff=26011
Keymapper
2020-02-01T15:11:52Z
<p>BgK: Created page with "=== Keymapper considerations === == Basics == * Backends define what input devices are available and with which characteristics (number of buttons, button names..). * Engines..."</p>
<hr />
<div>=== Keymapper considerations ===<br />
<br />
== Basics ==<br />
* Backends define what input devices are available and with which characteristics (number of buttons, button names..).<br />
* Engines define what kind of events they expect for input handing (mouse button presses, keyboard shortcuts, custom actions..) through keymaps.<br />
* The keymapper maps the events produced by the backend in use to those that are expected by the current engine based on default bindings and user preferences.<br />
<br />
The keymapper is not limited to mapping keyboard keys, it is meant to remap any kind of event. At the moment, mouse buttons, keyboard keys and joystick/gamepad buttons events are supported.<br />
<br />
== For engine developers ==<br />
* Keymaps are defined by implementing '''MetaEngine::initKeymaps'''. Keymaps can be seen as a contract for what the engine expects in terms of events for input handing. Key combinations,.. that are not defined by keymaps cannot be used on platforms without a mouse and keyboard. For engines that don't have a keymap, the default game keymap defined in ''metaengine.cpp'' is used. Events that don't match a keymap are sent to the engine unprocessed, as they are produced by the backend.<br />
* A keymap is made of actions. Using the remap dialog users can associate these actions to events generated by the backends. When defining actions engine developers decide what happens when the action is executed. There are two options (hybrids are possible):<br />
** Generate events that match what the existing event handling the engine expects. That's easy to do. Just declare the keymap and it's done. However there are issues with this approach. An user who changes the default binding for an action does not expect the original binding to still work. Depending on how the engine is structured this also may cause key handling to be defined twice. Once in the keymap, and once in the event loop.<br />
** Generate custom actions events with meaning private to the engine (''EVENT_CUSTOM_ENGINE_ACTION_{START,END}'').<br />
<br />
<br />
:: Example when reusing the existing input handling:<br />
<br />
<syntaxhighlight lang="cpp"><br />
Common::Keymap *MyEngine::initKeymap(const char *target) {<br />
Keymap *engineKeyMap = new Keymap(Keymap::kKeymapTypeGame, "my-engine");<br />
<br />
Action *act;<br />
<br />
act = new Action("TALK", _("Talk"));<br />
act->setKeyEvent(KEYCODE_t);<br />
act->addDefaultInputMapping("t");<br />
act->addDefaultInputMapping("JOY_X");<br />
engineKeyMap->addAction(act);<br />
<br />
act = new Action("USE", _("Use"));<br />
act->setKeyEvent(KEYCODE_u);<br />
act->addDefaultInputMapping("u");<br />
act->addDefaultInputMapping("JOY_Y");<br />
engineKeyMap->addAction(act);<br />
<br />
return engineKeyMap;<br />
}<br />
<br />
void MyEngine::doInput() {<br />
Common::Event event;<br />
while (_system->getEventManager()->pollEvent(event)) {<br />
switch (event.type) {<br />
case Common::EVENT_KEYDOWN:<br />
switch (event.kbd.keycode) {<br />
case Common::KEYCODE_t:<br />
doTalk();<br />
break;<br />
case Common::KEYCODE_u:<br />
doUse();<br />
break;<br />
}<br />
}<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
:: Example when using custom engine actions:<br />
<br />
<syntaxhighlight lang="cpp"><br />
enum MyEngineAction {<br />
kMyActionTalk,<br />
kMyActionUse<br />
}<br />
<br />
Common::Keymap *MyEngine::initKeymap(const char *target) {<br />
Keymap *engineKeyMap = new Keymap(Keymap::kKeymapTypeGame, "my-engine");<br />
<br />
Action *act;<br />
<br />
act = new Action("TALK", _("Talk"));<br />
act->setCustomEngineActionEvent(kMyActionTalk);<br />
act->addDefaultInputMapping("t");<br />
act->addDefaultInputMapping("JOY_X");<br />
engineKeyMap->addAction(act);<br />
<br />
act = new Action("USE", _("Use"));<br />
act->setCustomEngineActionEvent(kMyActionUse);<br />
act->addDefaultInputMapping("u");<br />
act->addDefaultInputMapping("JOY_Y");<br />
engineKeyMap->addAction(act);<br />
<br />
return engineKeyMap;<br />
}<br />
<br />
void MyEngine::doInput() {<br />
Common::Event event;<br />
while (_system->getEventManager()->pollEvent(event)) {<br />
switch (event.type) {<br />
case Common::EVENT_CUSTOM_ENGINE_ACTION_START:<br />
switch ((MyEngineAction)event.customType) {<br />
case kMyActionTalk:<br />
doTalk();<br />
break;<br />
case kMyActionUse:<br />
doUse();<br />
break;<br />
}<br />
}<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
:: Engines with engine-driven input handing should prefer using custom action events as this approach it is more powerful. Engines where input handling is script-driven probably have no choice but to use the first option. It's up to the engine developer to choose which is the best in each specific context.<br />
<br />
* Keymaps can be situational, thus engines may define multiple keymaps. Keymaps can be enabled / disabled at any time to select which actions are relevant for the current situation. For example for a RPG game there may be one keymap for the overworld, one for combat and one for shops. <br />
* Text input needs special care in conjunction with the keymapper. Given that keys can be remapped, players may want to remap, for example, the arrow keys to WSAD. But then when text input is required, it is no longer possible to type those letters because they map to the arrow keys. The solution to this issue is to disable the keymap that handles key shortcuts while a text input widget is focused.<br />
<br />
== For backend developers ==<br />
* To define the available input devices, a backend need to implement '''OSystem::getHardwareInputSet'''. The declared input devices must match the events that are produced by the backend in reaction to user input. It's best not to have any hardcoded button mapping in the backend. For example in the case of a game console with solely a gamepad as input device, when the player presses a button, the backend should send ''EVENT_JOYBUTTON_{DOWN,UP}'' events, not ''EVENT_LBUTTON{DOWN,UP}''. The keymapper will do the transformation from joystick events to mouse events if necessary.<br />
* Backends can define (or replace) default bindings for any keymap. To do so, implement '''OSystem::getKeymapperDefaultBindings'''. This can be used to make room in the default keymaps for backend specific actions, or to provide better defaults for the platform than those defined in the keymap.<br />
* Backends can use keymaps as well to allow players to remap the backend specific features. To do so, implement '''OSystem::getGlobalKeymaps'''. When implementing backend specific keymaps, it's best to request ''EVENT_CUSTOM_BACKEND_ACTION_{START,END}'' events in response to the user input. During event handling, ''Event::customType'' is used to recognize the action that needs to be executed.</div>
BgK
https://wiki.scummvm.org/index.php?title=Developer_Central&diff=26010
Developer Central
2020-02-01T15:08:40Z
<p>BgK: Add a link to the keymapper page</p>
<hr />
<div>The purpose of this page is to give a link to all kinds of resources that contain information valuable to current and future developers of ScummVM.<br />
<br />
== Getting started ==<br />
* The first thing you need to be able to do is [[Git#Retrieving_the_code|get the ScummVM code]] from our [[Git]] repository.<br />
* Then you should [[Compiling ScummVM|compile ScummVM]].<br />
* If you are new to open source, you can also try reading https://opensource.guide/how-to-contribute/<br />
* Then read [[#Help! Where do I start with the code base?|Help! Where do I start with the code base?]] <br />
<br />
That was easy, right? Here are some more tips:<br />
<br />
* Some hints on [[Debugging ScummVM|debugging ScummVM]].<br />
* Before you write/submit code, '''you must read''' our [[Code Formatting Conventions]].<br>Patches which do not follow them will be rejected or at least delayed until they are cleaned up to comply to them.<br />
* Also, you should read and respect the general [[Coding Conventions]].<br />
* Our [https://bugs.scummvm.org bug tracker] might provide some easy tasks to start with and familiarise yourself with the ScummVM code base.<br />
* If you have write (push) access to our repository, you are expected to have read and to comply with our [[Commit Guidelines]].<br>Also, please read the tips for using Git here: [[Git tips]].<br>In particular, note the use of feature branches, when working on refactoring or other large connected changes, rather than committing directly to scummvm/master.<br />
* If you do not have write (push) access to our repository, you should submit your contributions by one of the following methods:<br />
** Using a [https://help.github.com/articles/using-pull-requests Github Pull Request].<br> This requires you to have/register a github account, fork our repository, commit your changes to a branch and then issue a Pull Request.<br>This is the current preferred method as it is easier for the team to review, discuss and amend prior to merging.<br>You are expected to have read and to comply with our [[Commit Guidelines]].<br />
** Using the [https://bugs.scummvm.org/ patch tracker].<br>This requires you to have/register a github account, and generate a [https://en.wikipedia.org/wiki/Patch_%28Unix%29 patch] file, but this may be easier for developers unfamilar with Git or for small single commit changes, where a Pull Request might be considered overkill.<br />
** If neither of the above methods are suitable, individual developers may be willing to accept patches or amended source files by other methods i.e. e-mail, but please ask in the project IRC channel or by e-mail before doing this.<br />
* Our [http://doxygen.scummvm.org/ Doxygen source code documentation] may help you to get the big picture about ScummVM.<br />
* Also, you might want to check our list for current [[Platform Limitations]].<br />
<br />
== Help! Where do I start with the code base? ==<br />
=== Code base structure ===<br />
The ScummVM code base is quite big, but well structured with five main components:<br />
{| class="wikitable"<br />
! style="text-align:left;"|Component<br />
! Source code location<br />
|-<br />
| The OSystem API, which defines available features a game can use, such a drawing on screen or receiving keyboard and mouse events.<br />
|common/system.h<br />
|-<br />
|The backends, which implement the OSystem API for various platforms.<br />
|backends/<br />
|-<br />
|The game engines.<br />
|engines/<br />
|-<br />
|Common code, that provides various utility classes (for example containers) and audio, image, and video codecs that game engines can use.<br />
|common/<br>audio//<br>image/<br>video/<br />
|-<br />
|Gui code, that provides a graphical user interface for the game launcher and options dialog.<br />
|gui/<br />
|}<br />
<br />
And then you have a few more directories:<br />
* base/<br />
: This is the entry point for the application. It for example handles command line argument parsing and the main loop. See [[#Entry points|Entry points]] below.<br />
*test/<br />
: Contains unit tests for some utility classes from the common code.<br />
* po/<br />
: Contains translation of the ScummVM GUI into various languages<br />
<br />
=== First steps ===<br />
The OSystem API shields game engines and gui code from the actual platform the software is running on. The backends code is the only part of the code base that is platform dependent. So if you want to work on a game engine for example you will need to look at the OSystem API to know what you can do in the engine, but you can ignore everything in the backends code as you don't need to know how the OSystem API is actually implemented. On the other hand if you wand to port ScummVM to a new platform, the backends code is what you will want to look at.<br />
<br />
You can start by browsing a bit the source code to see how it maps to the description above, and then depending on your interests select one piece of code to look at in more details. For example if you are interested in ports, look at how one specific port is implemented. Or if you are interested in game engines, look at one engine.<br />
<br />
In you are interested in game engines, the <code>plumber</code> engine is the simplest one by far, and you can start from there to see the overall structure of an engine. Then you can select an engine for one of the free games we have on our [https://www.scummvm.org/games/ download page] (for example [https://www.scummvm.org/games/#queen Flight of the Amazon Queen], with the corresponding engine source code in <code>engines/queen/</code>), or a game you already own. You can make changes and see how it behaves, run the engine with a debugger, and use an hexadecimal editor to look at the game data file and map them to what the engine does. At first you can in particular look at the engine's use of the classes in the common/ folder, such as Common::File, Common::Array. Start getting a feel for what classes are available before you move onto the graphic and event handling stuff.<br />
<br />
If you interest lies with ports and how ScummVM interacts with various operating systems, take a look at the source code in <code>backends/</code>. There are two main categories of backends: monolithique ones and modular ones. The modular backends split the OSystem API implementation between several modules, the GraphicsManager being maybe the most important. Most modular backends use the [https://www.libsdl.org SDL library] and share some code between them.<br />
<br />
Our [http://doxygen.scummvm.org doxygen documentation] might help to grasp class hierarchy and navigate the source code at first. In particular it provides a visual representation of the relationship between classes. Using an IDE such as Visual Studio, Xcode, Eclipse, QtCreator or CLion can also be a big help. See the create_project tool to generate projects for various IDE.<br />
<br />
Once you are no longer completely lost and have a grasp of the code base structure, a good way to dive deeper might be to find a task to work on. You can have a look at the [https://bugs.scummvm.org bug tracker] and the various TODO lists on this wiki. See the [[Developer_Central#Projects, plans, things to do|Projects, plans, things to do]] section. Once you have a sense of something concrete you want to work on, you are highly encourage to visit our IRC channel (#scummvm on freenode) where you can ask for helps and guidance from fellow developers. <br />
<br />
=== Entry points ===<br />
# The executable entry point varies depending on the platforms (and therefore it is in <code>backends/</code>). For example for Linux you will find it in <code>backends/platform/sdl/posix/posix-main.cpp</code> while for macOS it is in <code>backends/platform/sdl/macosx/macosx-main.cpp</code>.<br />
# From there it goes into the actual ScummVM main entry point, <code>scummvm_main()</code> implemented in <code>base/main.cpp</code>.<br />
# It alternates between showing the Game Launcher and running a game.<br />
## While the GUI is running (in the game launcher or options dialog) the main loop is <code>GuiManager::runLoop()</code> in <code>gui/gui-manager.cpp</code>.<br />
## Each game engine has its own entry point, which is its implementation of the pure virtual <code>Engine::run()</code> function.<br />
<br />
== Pull Request approval process ==<br />
The current procedure is as follow:<br />
# For a sizeable, significant changes it is advised to make a [https://help.github.com/articles/about-pull-requests/ Pull Request on GitHub].<br />
# Such Pull Request will have to stay for at least 2 weeks open for the comments.<br />
# Everyone is invited to comment and review and voice their opinion (views of non-team members are valuable, but have no decisive power).<br />
# If there are no unaddressed objections after 2 weeks, the PR could be merged. Exception could be made if there are suggestions over refactoring or tidying up the code, granted that they will be addressed in-tree.<br />
# Immediately after the merge the PR maker ensures that the [http://buildbot.scummvm.org buildbot] stays happy and is not worsened (historically we had few ports broken for months).<br />
<br />
The definition of what makes a sizeable changes not cast in stone. This is up to the discretion of the PR creator, but normally we would expect that anything which breaks existing OSystem API and the Common code, or significantly extends these, especially if it requires more work from the Porters, should go via a Pull Request process. The goal is to ensure that everything stays maintainable.<br />
<br />
Any developer is free to open a PR for less significant changes, and that process could be used for facilitating the discussion and collecting feedback, but when there are no big changes involved, no 2 weeks timeout is enforced.<br />
<br />
Individual engine sub-teams decide by themselves on the process. For example currently the SCI development is performed via PRs as well for any sizeable changes. It is up to that sub-team to drop this rule any time or make something even stricter. Just make sure you continue enjoying hacking the ScummVM code.<br />
<br />
== For Engine authors ==<br />
* If you want to provide a new Engine for ScummVM, check out our [[HOWTO-Engines|Engines HOWTO]].<br />
* If you work on a game engine for ScummVM, consider implementing [[Advanced Engine Features]].<br />
* If your engine supports multiple games / game variants, properly detecting and differentiating them all can be a nuisance. Use the [[Advanced Detector]] to overcome this hurdle.<br />
* Accessing files in a portable fashion is non-trivial. Read all about [[HOWTO-Open_Files|how to open files]].<br />
* Define remappable input handing using the [[Keymapper]].<br />
* Debugging endian issues can be tricky. [[HOWTO-Debug-Endian-Issues |This page]] gives some solutions.<br />
* If you want to have your engine merged into the ScummVM mainline, check out our [[HOWTO-Engine_Inclusion|Engine Inclusion HOWTO]].<br />
* For those starting out with reverse engineering, check out our [[HOWTO-Reverse_Engineering|Reverse Engineering HOWTO]].<br />
* Apart from git bisection to locate regressions in gameplay, the (experimental) [[Event_Recorder|Event Recorder]] provides a framework for recording and replaying gameplay to detect regressions.<br />
* For some general suggestions on developing engines, see the [[HOWTO-Tips_And_Tricks|Engine Development Tips & Tricks]]<br />
<br />
== For Backend authors ==<br />
* If you want to port ScummVM to a new platform, check out our [[HOWTO-Backends|Backends HOWTO]].<br />
* The [[HOWTO-Dynamic_Modules|Dynamic Modules HOWTO]] describes how to implement loadable modules on a smaller backend, even without operating system support.<br />
<br />
== For Web site maintainers ==<br />
If you want to update the main web site:<br />
* Update the files you want in the scummvm-web project<br />
* Trigger http://www.scummvm.org/site-update/ URL. (Ask sev for an account) <br />
* This is also covered in more detail by the relevant section of the Admin HOWTO [[HOWTO-Admin#How_to_edit.2Fupdate_webpages|here]].<br />
<br />
== Projects, plans, things to do ==<br />
We are usually happy to receive any kind of help with the things listed below.<br />
* [[OpenTasks|List of open tasks]], with relatively detailed descriptions, and contact points. Some rather small ones, some bigger ones, take a look. [[GSoC Ideas]] also has some ideas, intended for students applying for Google's Summer of Code.<br />
* [[TODO|Main TODO list]] (contains links to many further specialized TODO pages, e.g. for specific engines).<br />
* Our [https://bugs.scummvm.org/ bug tracker] lists bugs that need to be resolved and also lists features requested by all kinds of people.<br />
<br />
The following are partially outdated, but kept for now for the sake of reference.<br />
* [[Small Devices Backend]] -- this was under development as part of the GSoC, but additional help is welcome.<br />
* [[Keymapping Improvements]] -- still in the design stage. Help is welcome.<br />
* [[Music drivers redesign]] -- in phase of discussion<br />
<br />
== New GUI ==<br />
Our "new" GUI is themeable and translatable. If you are interested in writing a custom theme, the following may be of help for you:<br />
* [[GUI Themes]]<br />
* [[GUI Themes/Specs|GUI Theme Specs]]<br />
* [[Supporting_GUI_Translation|GUI Translation Support]] in code<br />
* [[HOWTO-Translate_ScummVM_GUI|Translation HOWTO]] for translation authors<br />
* [[GUI Themes/TODO|GUI TODO]]<br />
<br />
== Networking ==<br />
* [[Cloud Storage Support | Cloud Storage Support]]<br />
* [[Local Webserver | Local Webserver]]<br />
<br />
== Release Management ==<br />
* Our release guideline for ScummVM [[HOWTO-Release |Release HOWTO]]<br />
* Our release testing status for the latest stable release [[Release_Testing |Release Testing]]<br />
* Anyone who wishes to bundle ScummVM with games for legal commercial and non-commercial release should read the notes [[Bundling_ScummVM|here]].<br />
<br />
== Code statistics ==<br />
Our commit logs are fed to several freely available statistics tools:<br />
* [https://www.openhub.net/p/113 OpenHub project analysis] nice graphs and devs activity<br />
* [http://cia.vc/stats/project/ScummVM CIA.vc statistics], current development<br />
* [http://github.com/scummvm GitHub page], current development on github<br />
<br />
== Team Member Benefits ==<br />
Every active ScummVM Team member is eligible for enhanced access to our [[Project Services]] and some further benefits:<br />
* being added to our main credits (do it by yourself in scummvm/devtools/credits.pl)<br />
* @scummvm.org forwarding address<br />
* operator status in our [[IRC Channel]] #scummvm @ freenode<br />
* address cloak on freenode (in form of scummvm/undead/nick)<br />
* moderator status on ScummVM [[Forums]] and appropriate badge "ScummVM Developer" or "ScummVM Porter" or special one<br />
* ScummVM [[Wiki]] account<br />
* having development blog displayed on ScummVM [[Planet]]<br />
* using project donations for purchasing necessary things for the development, such as game copies, software licenses, etc.<br />
<br />
If you need any of the above, talk to [[User:Sev|sev]].<br />
<br />
If you do admin tasks e.g. responding to bugs, moderating the forums, you should read the Admin HOWTO [[HOWTO-Admin|here]] for tips and guidelines on doing this.<br />
<br />
== Tools ==<br />
* [https://www.scummvm.org/frs/extras/IDA/idafree50.exe IDA Freeware Version 5.0] - IDA is the preferred tool for disassembling old games from scratch. The most recent freeware version no longer supports disassembling DOS games, but this earlier version still supports it.<br />
<br />
== Misc ==<br />
* List of [[Defines]] used in the source code.<br />
* Documentation on how we performed our [[CVS2SVN|CVS to Subversion]] conversion.<br />
* Old page listing [[CVS vs SVN|pros and cons between CVS and SVN]] before the conversion was made.<br />
* A guide on submitting [[Screenshots]] for use on our website.</div>
BgK
https://wiki.scummvm.org/index.php?title=Summer_of_Code/GSoC_Ideas_2020&diff=25934
Summer of Code/GSoC Ideas 2020
2020-01-25T10:44:50Z
<p>BgK: </p>
<hr />
<div>If you'd like to get involved in ScummVM - or one of our sister projects, such as ResidualVM - we'd love to help you get started!<br />
<br />
We've had a lot of successful student projects as part of Google's Summer of Code in previous years -- we hope to inspire you to work with us and (hopefully) add your own success.<br />
<br />
We often get asks by students with no experience with ScummVM whether they have the necessary skills to participate with us. The idea of GSoC is to introduce students to open source development, so we are not expecting you to have experience with ScummVM. You will have time during the application and community bonding periods to familiarize yourself with the project. The technical skills required to work with us varies from task to task. For any work on ScummVM, you'll probably need to already be comfortable with a basic level of C++. Some of the tasks might need more specialized knowledge (for example, working with ResidualVM may need you to understand some OpenGL and 3D math, and some engine tasks may require some assembly or reverse engineering knowledge); we give our thoughts about this alongside each suggested task, below.<br />
<br />
Most importantly, we'd like you to join our community. There are many previous GSoC participants who are still involved in our project, and whether or not you participate as part of Summer of Code, we'd love for you to get involved too.<br />
<br />
You should come to our [[IRC Channel]] and introduce yourself! We're friendly, and it's often the easiest way to ask questions about the tasks and the code in general. The channel is the main form of everyday communication for the project, and there will almost always be developers there who can discuss your project ideas, answer questions and help out.<br />
<br />
You can find more information about what we expect from you before you apply at [[GSoC Application]].<br />
<br />
__TOC__<br />
<br />
== Introduction ==<br />
<br />
We have a list of potential tasks further down on this page, but before you look at them, perhaps you'd like to take a look at some of the successful projects from previous years! We encourage all of our students to maintain a blog during their summer work, which is a nice way to get some sense of what they accomplished.<br />
<br />
One popular type of task is to improve our support for the games you love, whether this means a new game engine, or helping us to perfect an existing one.<br />
<br />
Sometimes source code is available - in recent summers, students integrated code supporting games such as [[Sfinx]] ([http://urukgsoc.blogspot.hu/search/label/CGE2 blog]), [[The Prince and the Coward]] ([http://lukaslwgsoc.blogspot.com/ blog]) and [[Avalanche]] ([http://urukgsoc.blogspot.hu/search/label/Avalanche blog]) into ScummVM. In fact, our support for the [[Wintermute]] engine was not only started by a GSoC student ([http://summermute2012.blogspot.com/ blog]), who integrated the code into our tree, but also [[Wintermute/Games|drastically improved]] by another student a year later ([https://icodelikeacow.wordpress.com/ blog]). <br />
<br />
[[File:GSOC_EMI.png|160px]] [[File:GSOC_zvision.png|152px]] [[File:GSOC_EMI_asm.png|147px]]<br />
<br />
A more challenging (but hopefully rewarding) idea is to start (or continue) reverse engineering a game where no source is available. Two good examples are the pair of students who drastically improved ResidualVM's support for Escape from Monkey Island ([http://diggingemi.blogspot.com/ blog], [http://akzgsoc.blogspot.com/ blog]), and the work on improving [[Operation Stealth]] ([https://buddhahacks.wordpress.com/ blog]). Another option is to work on merging (and improving) someone else's reverse engineering work, such as was done with the [[ZVision]] engine ([http://richiesams.blogspot.com/search/label/ScummVM blog]).<br />
<br />
If you'd prefer to improve ScummVM more directly, there are even more options available there; in the past, students have (to give some examples) improved our OpenGL support, added a testing framework ([http://jakimushka.blogspot.com/ blog]), improved our scaler code ([http://singron.blogspot.com/ blog]), written a new GUI framework, added loadable modules for embedded platforms ([http://tonypuccinelli.blogspot.com/search/label/ScummVM blog]), rearchitected our keyboard input code ([http://kenny-gsoc.blogspot.com/ blog]) and added support for high-colour (16bpp and above) graphics. It's difficult for us to imagine ScummVM as it was before some of these projects, you can make a huge difference!<br />
<br />
== Tasks ==<br />
<br />
General contacts: Our IRC channel, our mailing list, or contact [[User:Sev|sev]], [[User:DJWillis|John Willis]], [[User:Strangerke|Arnaud Boutonné]]<br />
<br />
The ideas here are meant to be just that - '''ideas'''. We hope they help inspire your proposals, but you should also consider suggesting your own completely new project ideas. Pick something you really want to see improved/fixed, and come and talk to us about it!<br />
<br />
If you're looking for more inspiration for ideas, beware of our [[TODO]] (and the other TODO lists linked from there) and our [[OpenTasks]] pages. Many of the tasks listed there might be incomplete or outdated, or too difficult for a new developer. The best thing to do is to come and talk to us!<br />
<br />
== Game Tasks ==<br />
<br />
Technical contacts: Our IRC channel, our mailing list, or contact [[User:Sev|sev]], [[User:DJWillis|John Willis]], [[User:Strangerke|Arnaud Boutonné]], [[User:Md5|Filippos Karapetis]],<br />
<br />
If you already have reverse engineering experience, you could consider working on one of the external in-development game engines, or even on support for a new game. However, doing this kind of work is very difficult and time-consuming - you would have to convince us that you have the necessary skills to actually be sufficiently productive, probably by demonstrating some actual progress first.<br />
<br />
If you don't feel quite up to that level of challenge, we have lots of other suggestions:<br />
<br />
=== Macromedia Director</span>===<br />
Technical contacts: [[User:Sev|sev]]<br />
<br />
Difficulty level: Medium. You'll need a reasonable level of programming experience, and probably some Director games.<br />
<br />
Many 90s-era adventure games were developed using the Macromedia (now Adobe) Director tool. It would be nice to be able to play these games in ScummVM! We have a WIP engine in ScummVM tree, but it requires much more work in order to implement all hundreds of Lingo commands.<br />
<br />
=== Networking code for Moonbase Commander===<br />
Technical contacts: [[User:Sev|sev]]<br />
<br />
Difficulty level: Medium. You'll need a reasonable level of programming experience, and some network development experience.<br />
<br />
[[Moonbase Commander]] is a SCUMM-based strategy game. The original supported up to 4 network players. We have the source code for the original game, but it is based on top of Microsoft DirectPlay. We need to do a clean reimplementation, not necessarily compatible with the original. It may also require some basic server side for discovery. The networking libraries libcurl and SDL_Net are already part of ScummVM.<br />
<br />
=== Wintermute 3D ===<br />
Technical contacts: [[User:somaen|Einar Johan Trøan Sømåen]], [[User:aquadran|Paweł Kołodziejski]]<br />
<br />
Difficulty level: Medium/hard. You'll need to be able to understand 3D graphics, and rearchitecture/design the relevant parts of the engine.<br />
<br />
In 2012, support for games using the Wintermute engine was merged into ScummVM, but it still lacks support for games which use 3D graphics. It would be great to be able to play these games in ResidualVM!<br />
<br />
'''ResidualVM project.''' See [http://wiki.residualvm.org/index.php/GSoC_Ideas#Wintermute_3D_port Wintermute 3D] for more details.<br />
<br />
=== In Cold Blood engine refactor ===<br />
Technical contacts: [[User:somaen|Einar Johan Trøan Sømåen]], [[User:aquadran|Paweł Kołodziejski]], [[User:joostp|Joost Peters]]<br />
<br />
Difficulty level: Medium/hard. You'll need to be able to understand the relevant parts of the engine.<br />
<br />
'''ResidualVM project.''' See [http://wiki.residualvm.org/index.php/GSoC_Ideas#In_Cold_Blood_engine_refactor ICB engine refactor] for more details<br />
<br />
=== Maupiti Island ===<br />
Technical contacts: [[User:Strangerke|Strangerke]]<br />
<br />
Difficult level: Medium to Hard. Good knowledge of C++ and some knowledge of Pascal and Assembly are required. Some knowledge of French could also help a bit, though Strangerke could translate anything on demand.<br />
<br />
Maupiti Island is the sequel of Mortevielle Manor, both released by Lankhor. Both games were best sellers at the time and were games of the year in France. Nevertheless, best sellers of the time were still selling low volumes and Maupiti Island is nowadays pretty rare ans unknown.<br />
<br />
Partial Pascal sources of Maupiti Island (Atari ST) have been secured recently. Some utility functions are missing, which were written using a mix of Pascal and assembly. So, the whole harcoded logic is available with most of the utility functions. Some reverse engineering may be required if the equivalent functions in Mortevielle are not working out of the box for the DOS version.<br />
<br />
The purpose of this task is to reimplement a Maupiti Island engine for the DOS variants of the game in at least two languages, using Mortevielle Manor and the original sources as documentation.<br />
<br />
[https://www.mobygames.com/game/dos/maupiti-island/screenshots/gameShotId,732668/ Screenshots on Mobygames]<br />
<br />
=== The Immortal ===<br />
<br />
Technical contacts [[User:dreammaster|dreammaster]] or [[User:Strangerke|Strangerke]]<br />
<br />
Difficulty level: Hard. Good knowledge of C++ and assembly (x86 or 68K or 6502) is required.<br />
<br />
The immortal was released in 1990 by Electronic Arts. It's a mix of genres involving RPG elements with action and puzzles.<br />
The gameplay is different one variant to the other, and all variants are written in assembly, making it more difficult to support all the variants.<br />
<br />
In 2018, a GSoC student picked this task but, due to personal issues, didn't manage to complete the task. The purpose of the task is therefore to implement an engine for a variant of the game, using the original sources and the work of JoeFish as a documentation.<br />
<br />
[https://www.mobygames.com/game/immortal/screenshots Screenshots on Mobygames]<br />
<br />
=== Bring your own Adventure or RPG ===<br />
<br />
Technical contacts: Talk to us on IRC, or send us an email.<br />
<br />
Difficulty: Hard. You'll need good knowledge of C++, as well as knowledge of (reading) assembly.<br />
<br />
Our project consists of re-implementations of classic games, and we have listed<br />
a number of potential new game engines that you could work on here on our ideas<br />
page. However, you may have a classic 2D Adventure game or Role Playing Game<br />
(RPG) you are interested in yourself that is suitable for ScummVM that you<br />
would like to reverse engineer and re-implement. If so, great!<br />
<br />
Adding a completely new game engine is not easy, and you will have to convince<br />
us that you are aware of the challenges involved, that the game you are<br />
interested in is feasible, and that you have the necessary skills. Preferably,<br />
you will already have done some preliminary investigation, into for example<br />
data file formats, disassembly, etc.<br />
<br />
Please come talk to us to see if we have a mentor who would be interested in<br />
working with you on such a game. We'd be happy to help out.<br />
<br />
== Infrastructure Tasks ==<br />
<br />
Finally, there's always plenty of other practical tasks on our wishlist!<br />
<br />
=== Improve Android port</span>===<br />
<br />
Technical contacts: [[User:Sev|Sev]]<br />
<br />
Difficulty level: Medium/hard. You'll need some knowledge of C++, Java and ideally Android development and OpenGL. Access to at least one Android device is probably also necessary.<br />
<br />
Our current Android port is in need of improvement, especially combined with modern versions of Android. We'd like to improve the GUI and the input code in particular, but hopefully you also have your own ideas if you've tried the port (if you haven't: do so!). There are some patches already available, and it should be possible to merge code from other projects (such as SDL 2). A native configuration GUI could also be an option.<br />
<br />
=== Game packaging system ===<br />
<br />
Technical contacts: [[User:Sev|sev]] or [[User:DJWillis|DJWillis]] <br />
<br />
ScummVM offers 8 freeware games for download, but they need to be downloaded and installed manually. It would be great to develop a universal system which would let us descibe a game, e.g. provide screenshots, game descriptions, metadata, and package it for different platforms, so we could put them to different applicaiton distribution systems.<br />
<br />
Examples are: Linux packages, Google Play, Apple App Store, Steam, ForgeTV store, and anything beyond that.<br />
<br />
=== Support for shaders and arbitrary scalers ===<br />
<br />
Technical contacts: [[User:Sev|sev]]<br />
<br />
Difficulty: Medium<br />
<br />
ScummVM uses software scalers for graphics enhancements. In 2012 we were running GSoC for turning them into plugins. [https://github.com/scummvm/scummvm/pull/271 That work] needs to be completed, basically, it is just rebasing of the patch. The rebasing was started here: https://github.com/digitall/scummvm/tree/gsoc2012-scalers-cont<br />
<br />
Modern systems often have OpenGL with shader support. RetroArch project shaders are standard for them in open source gaming. LordHoto started work on adding support for those to ScummVM. His unfinished work could be found here: https://github.com/lordhoto/scummvm/tree/libretro-shader<br />
<br />
We need to add both improvements to our scaler system. Recent PSP2 port already adds some basics for scalers, particularly in GUI, so that could be reused too.<br />
<br />
We need to have it tested on desktops and at least Android, but preferably also Windows and iOS.<br />
<br />
=== Programming interface ===<br />
<br />
Technical contacts: [[User:BgK|bgK]]<br />
<br />
Difficulty: Medium<br />
<br />
The goal of this project is to add a programming interface to ScummVM that other programs could use to interact with it. This would allow advanced users to write companion applications such as:<br />
* Game interface enhancement tools: Automappers for RPG / Interactive Fiction games. Interactive hint systems for adventure games.<br />
* Input automation tools: Regression testing / Tool Assisted Speedrun scripts.<br />
* Highly integrated frontends.<br />
* Debugging / game development tools.<br />
<br />
The interface needs to be bi-directional with the companion application being able to send requests to query information from ScummVM and to receive responses, but also for ScummVM to send notifications to the clients. The interface needs to be easy to integrate with from various programming languages and easy to experiment with.<br />
<br />
The scope of the project is to design and implement the base system in ScummVM for Windows and Unix (using Named pipes / Unix domain sockets for communication), and to write a high quality companion application for one of the game engines in ScummVM.</div>
BgK
https://wiki.scummvm.org/index.php?title=Summer_of_Code/GSoC_Ideas_2020&diff=25933
Summer of Code/GSoC Ideas 2020
2020-01-25T10:44:24Z
<p>BgK: Remove extra vertical space</p>
<hr />
<div>If you'd like to get involved in ScummVM - or one of our sister projects, such as ResidualVM - we'd love to help you get started!<br />
<br />
We've had a lot of successful student projects as part of Google's Summer of Code in previous years -- we hope to inspire you to work with us and (hopefully) add your own success.<br />
<br />
We often get asks by students with no experience with ScummVM whether they have the necessary skills to participate with us. The idea of GSoC is to introduce students to open source development, so we are not expecting you to have experience with ScummVM. You will have time during the application and community bonding periods to familiarize yourself with the project. The technical skills required to work with us varies from task to task. For any work on ScummVM, you'll probably need to already be comfortable with a basic level of C++. Some of the tasks might need more specialized knowledge (for example, working with ResidualVM may need you to understand some OpenGL and 3D math, and some engine tasks may require some assembly or reverse engineering knowledge); we give our thoughts about this alongside each suggested task, below.<br />
<br />
Most importantly, we'd like you to join our community. There are many previous GSoC participants who are still involved in our project, and whether or not you participate as part of Summer of Code, we'd love for you to get involved too.<br />
<br />
You should come to our [[IRC Channel]] and introduce yourself! We're friendly, and it's often the easiest way to ask questions about the tasks and the code in general. The channel is the main form of everyday communication for the project, and there will almost always be developers there who can discuss your project ideas, answer questions and help out.<br />
<br />
You can find more information about what we expect from you before you apply at [[GSoC Application]].<br />
<br />
__TOC__<br />
<br />
== Introduction ==<br />
<br />
We have a list of potential tasks further down on this page, but before you look at them, perhaps you'd like to take a look at some of the successful projects from previous years! We encourage all of our students to maintain a blog during their summer work, which is a nice way to get some sense of what they accomplished.<br />
<br />
One popular type of task is to improve our support for the games you love, whether this means a new game engine, or helping us to perfect an existing one.<br />
<br />
Sometimes source code is available - in recent summers, students integrated code supporting games such as [[Sfinx]] ([http://urukgsoc.blogspot.hu/search/label/CGE2 blog]), [[The Prince and the Coward]] ([http://lukaslwgsoc.blogspot.com/ blog]) and [[Avalanche]] ([http://urukgsoc.blogspot.hu/search/label/Avalanche blog]) into ScummVM. In fact, our support for the [[Wintermute]] engine was not only started by a GSoC student ([http://summermute2012.blogspot.com/ blog]), who integrated the code into our tree, but also [[Wintermute/Games|drastically improved]] by another student a year later ([https://icodelikeacow.wordpress.com/ blog]). <br />
<br />
[[File:GSOC_EMI.png|160px]] [[File:GSOC_zvision.png|152px]] [[File:GSOC_EMI_asm.png|147px]]<br />
<br />
A more challenging (but hopefully rewarding) idea is to start (or continue) reverse engineering a game where no source is available. Two good examples are the pair of students who drastically improved ResidualVM's support for Escape from Monkey Island ([http://diggingemi.blogspot.com/ blog], [http://akzgsoc.blogspot.com/ blog]), and the work on improving [[Operation Stealth]] ([https://buddhahacks.wordpress.com/ blog]). Another option is to work on merging (and improving) someone else's reverse engineering work, such as was done with the [[ZVision]] engine ([http://richiesams.blogspot.com/search/label/ScummVM blog]).<br />
<br />
If you'd prefer to improve ScummVM more directly, there are even more options available there; in the past, students have (to give some examples) improved our OpenGL support, added a testing framework ([http://jakimushka.blogspot.com/ blog]), improved our scaler code ([http://singron.blogspot.com/ blog]), written a new GUI framework, added loadable modules for embedded platforms ([http://tonypuccinelli.blogspot.com/search/label/ScummVM blog]), rearchitected our keyboard input code ([http://kenny-gsoc.blogspot.com/ blog]) and added support for high-colour (16bpp and above) graphics. It's difficult for us to imagine ScummVM as it was before some of these projects, you can make a huge difference!<br />
<br />
== Tasks ==<br />
<br />
General contacts: Our IRC channel, our mailing list, or contact [[User:Sev|sev]], [[User:DJWillis|John Willis]], [[User:Strangerke|Arnaud Boutonné]]<br />
<br />
The ideas here are meant to be just that - '''ideas'''. We hope they help inspire your proposals, but you should also consider suggesting your own completely new project ideas. Pick something you really want to see improved/fixed, and come and talk to us about it!<br />
<br />
If you're looking for more inspiration for ideas, beware of our [[TODO]] (and the other TODO lists linked from there) and our [[OpenTasks]] pages. Many of the tasks listed there might be incomplete or outdated, or too difficult for a new developer. The best thing to do is to come and talk to us!<br />
<br />
== Game Tasks ==<br />
<br />
Technical contacts: Our IRC channel, our mailing list, or contact [[User:Sev|sev]], [[User:DJWillis|John Willis]], [[User:Strangerke|Arnaud Boutonné]], [[User:Md5|Filippos Karapetis]],<br />
<br />
If you already have reverse engineering experience, you could consider working on one of the external in-development game engines, or even on support for a new game. However, doing this kind of work is very difficult and time-consuming - you would have to convince us that you have the necessary skills to actually be sufficiently productive, probably by demonstrating some actual progress first.<br />
<br />
If you don't feel quite up to that level of challenge, we have lots of other suggestions:<br />
<br />
=== Macromedia Director</span>===<br />
Technical contacts: [[User:Sev|sev]]<br />
<br />
Difficulty level: Medium. You'll need a reasonable level of programming experience, and probably some Director games.<br />
<br />
Many 90s-era adventure games were developed using the Macromedia (now Adobe) Director tool. It would be nice to be able to play these games in ScummVM! We have a WIP engine in ScummVM tree, but it requires much more work in order to implement all hundreds of Lingo commands.<br />
<br />
=== Networking code for Moonbase Commander===<br />
Technical contacts: [[User:Sev|sev]]<br />
<br />
Difficulty level: Medium. You'll need a reasonable level of programming experience, and some network development experience.<br />
<br />
[[Moonbase Commander]] is a SCUMM-based strategy game. The original supported up to 4 network players. We have the source code for the original game, but it is based on top of Microsoft DirectPlay. We need to do a clean reimplementation, not necessarily compatible with the original. It may also require some basic server side for discovery. The networking libraries libcurl and SDL_Net are already part of ScummVM.<br />
<br />
=== Wintermute 3D ===<br />
Technical contacts: [[User:somaen|Einar Johan Trøan Sømåen]], [[User:aquadran|Paweł Kołodziejski]]<br />
<br />
Difficulty level: Medium/hard. You'll need to be able to understand 3D graphics, and rearchitecture/design the relevant parts of the engine.<br />
<br />
In 2012, support for games using the Wintermute engine was merged into ScummVM, but it still lacks support for games which use 3D graphics. It would be great to be able to play these games in ResidualVM!<br />
<br />
'''ResidualVM project.''' See [http://wiki.residualvm.org/index.php/GSoC_Ideas#Wintermute_3D_port Wintermute 3D] for more details.<br />
<br />
=== In Cold Blood engine refactor ===<br />
Technical contacts: [[User:somaen|Einar Johan Trøan Sømåen]], [[User:aquadran|Paweł Kołodziejski]], [[User:joostp|Joost Peters]]<br />
<br />
Difficulty level: Medium/hard. You'll need to be able to understand the relevant parts of the engine.<br />
<br />
'''ResidualVM project.''' See [http://wiki.residualvm.org/index.php/GSoC_Ideas#In_Cold_Blood_engine_refactor ICB engine refactor] for more details<br />
<br />
=== Maupiti Island ===<br />
Technical contacts: [[User:Strangerke|Strangerke]]<br />
<br />
Difficult level: Medium to Hard. Good knowledge of C++ and some knowledge of Pascal and Assembly are required. Some knowledge of French could also help a bit, though Strangerke could translate anything on demand.<br />
<br />
Maupiti Island is the sequel of Mortevielle Manor, both released by Lankhor. Both games were best sellers at the time and were games of the year in France. Nevertheless, best sellers of the time were still selling low volumes and Maupiti Island is nowadays pretty rare ans unknown.<br />
<br />
Partial Pascal sources of Maupiti Island (Atari ST) have been secured recently. Some utility functions are missing, which were written using a mix of Pascal and assembly. So, the whole harcoded logic is available with most of the utility functions. Some reverse engineering may be required if the equivalent functions in Mortevielle are not working out of the box for the DOS version.<br />
<br />
The purpose of this task is to reimplement a Maupiti Island engine for the DOS variants of the game in at least two languages, using Mortevielle Manor and the original sources as documentation.<br />
<br />
[https://www.mobygames.com/game/dos/maupiti-island/screenshots/gameShotId,732668/ Screenshots on Mobygames]<br />
<br />
=== The Immortal ===<br />
<br />
Technical contacts [[User:dreammaster|dreammaster]] or [[User:Strangerke|Strangerke]]<br />
<br />
Difficulty level: Hard. Good knowledge of C++ and assembly (x86 or 68K or 6502) is required.<br />
<br />
The immortal was released in 1990 by Electronic Arts. It's a mix of genres involving RPG elements with action and puzzles.<br />
The gameplay is different one variant to the other, and all variants are written in assembly, making it more difficult to support all the variants.<br />
<br />
In 2018, a GSoC student picked this task but, due to personal issues, didn't manage to complete the task. The purpose of the task is therefore to implement an engine for a variant of the game, using the original sources and the work of JoeFish as a documentation.<br />
<br />
[https://www.mobygames.com/game/immortal/screenshots Screenshots on Mobygames]<br />
<br />
=== Bring your own Adventure or RPG ===<br />
<br />
Technical contacts: Talk to us on IRC, or send us an email.<br />
<br />
Difficulty: Hard. You'll need good knowledge of C++, as well as knowledge of (reading) assembly.<br />
<br />
Our project consists of re-implementations of classic games, and we have listed<br />
a number of potential new game engines that you could work on here on our ideas<br />
page. However, you may have a classic 2D Adventure game or Role Playing Game<br />
(RPG) you are interested in yourself that is suitable for ScummVM that you<br />
would like to reverse engineer and re-implement. If so, great!<br />
<br />
Adding a completely new game engine is not easy, and you will have to convince<br />
us that you are aware of the challenges involved, that the game you are<br />
interested in is feasible, and that you have the necessary skills. Preferably,<br />
you will already have done some preliminary investigation, into for example<br />
data file formats, disassembly, etc.<br />
<br />
Please come talk to us to see if we have a mentor who would be interested in<br />
working with you on such a game. We'd be happy to help out.<br />
<br />
== Infrastructure Tasks ==<br />
<br />
Finally, there's always plenty of other practical tasks on our wishlist!<br />
<br />
=== Improve Android port</span>===<br />
<br />
Technical contacts: [[User:Sev|Sev]]<br />
<br />
Difficulty level: Medium/hard. You'll need some knowledge of C++, Java and ideally Android development and OpenGL. Access to at least one Android device is probably also necessary.<br />
<br />
Our current Android port is in need of improvement, especially combined with modern versions of Android. We'd like to improve the GUI and the input code in particular, but hopefully you also have your own ideas if you've tried the port (if you haven't: do so!). There are some patches already available, and it should be possible to merge code from other projects (such as SDL 2). A native configuration GUI could also be an option.<br />
<br />
=== Game packaging system ===<br />
<br />
Technical contacts: [[User:Sev|sev]] or [[User:DJWillis|DJWillis]] <br />
<br />
ScummVM offers 8 freeware games for download, but they need to be downloaded and installed manually. It would be great to develop a universal system which would let us descibe a game, e.g. provide screenshots, game descriptions, metadata, and package it for different platforms, so we could put them to different applicaiton distribution systems.<br />
<br />
Examples are: Linux packages, Google Play, Apple App Store, Steam, ForgeTV store, and anything beyond that.<br />
<br />
=== Support for shaders and arbitrary scalers ===<br />
<br />
Technical contacts: [[User:Sev|sev]]<br />
<br />
Difficulty: Medium<br />
<br />
ScummVM uses software scalers for graphics enhancements. In 2012 we were running GSoC for turning them into plugins. [https://github.com/scummvm/scummvm/pull/271 That work] needs to be completed, basically, it is just rebasing of the patch. The rebasing was started here: https://github.com/digitall/scummvm/tree/gsoc2012-scalers-cont<br />
<br />
Modern systems often have OpenGL with shader support. RetroArch project shaders are standard for them in open source gaming. LordHoto started work on adding support for those to ScummVM. His unfinished work could be found here: https://github.com/lordhoto/scummvm/tree/libretro-shader<br />
<br />
We need to add both improvements to our scaler system. Recent PSP2 port already adds some basics for scalers, particularly in GUI, so that could be reused too.<br />
<br />
We need to have it tested on desktops and at least Android, but preferably also Windows and iOS.<br />
<br />
=== Programming interface ===<br />
<br />
Technical contacts: [[User:BgK|bgK]]<br />
<br />
Difficulty: Medium<br />
<br />
The goal of this project is to add a programming interface to ScummVM that other programs could use to interact with it. This would allow advanced users to write companion applications such as:<br />
* Game interface enhancement tools: Automappers for RPG / Interactive Fiction games. Interactive hint systems for adventure games.<br />
* Input automation tools: Regression testing / Tool Assisted Speedrun scripts.<br />
* Highly integrated frontends.<br />
* Debugging / game development tools.<br />
<br />
The interface needs to be bi-directional with the companion application being able to send requests to query information from ScummVM and to receive responses, but also for ScummVM to send notifications to the clients. The interface needs to be easy to integrate with from various programming languages and easy to experiment with.<br />
<br />
The scope of the project is to design and implement base system in ScummVM for Windows and Unix (using Named pipes / Unix domain sockets for communication), and to write a high quality companion application for one of the game engines in ScummVM.</div>
BgK
https://wiki.scummvm.org/index.php?title=Summer_of_Code/GSoC_Ideas_2020&diff=25932
Summer of Code/GSoC Ideas 2020
2020-01-25T10:43:39Z
<p>BgK: Add the programming interface task</p>
<hr />
<div>If you'd like to get involved in ScummVM - or one of our sister projects, such as ResidualVM - we'd love to help you get started!<br />
<br />
We've had a lot of successful student projects as part of Google's Summer of Code in previous years -- we hope to inspire you to work with us and (hopefully) add your own success.<br />
<br />
We often get asks by students with no experience with ScummVM whether they have the necessary skills to participate with us. The idea of GSoC is to introduce students to open source development, so we are not expecting you to have experience with ScummVM. You will have time during the application and community bonding periods to familiarize yourself with the project. The technical skills required to work with us varies from task to task. For any work on ScummVM, you'll probably need to already be comfortable with a basic level of C++. Some of the tasks might need more specialized knowledge (for example, working with ResidualVM may need you to understand some OpenGL and 3D math, and some engine tasks may require some assembly or reverse engineering knowledge); we give our thoughts about this alongside each suggested task, below.<br />
<br />
Most importantly, we'd like you to join our community. There are many previous GSoC participants who are still involved in our project, and whether or not you participate as part of Summer of Code, we'd love for you to get involved too.<br />
<br />
You should come to our [[IRC Channel]] and introduce yourself! We're friendly, and it's often the easiest way to ask questions about the tasks and the code in general. The channel is the main form of everyday communication for the project, and there will almost always be developers there who can discuss your project ideas, answer questions and help out.<br />
<br />
You can find more information about what we expect from you before you apply at [[GSoC Application]].<br />
<br />
__TOC__<br />
<br />
== Introduction ==<br />
<br />
We have a list of potential tasks further down on this page, but before you look at them, perhaps you'd like to take a look at some of the successful projects from previous years! We encourage all of our students to maintain a blog during their summer work, which is a nice way to get some sense of what they accomplished.<br />
<br />
One popular type of task is to improve our support for the games you love, whether this means a new game engine, or helping us to perfect an existing one.<br />
<br />
Sometimes source code is available - in recent summers, students integrated code supporting games such as [[Sfinx]] ([http://urukgsoc.blogspot.hu/search/label/CGE2 blog]), [[The Prince and the Coward]] ([http://lukaslwgsoc.blogspot.com/ blog]) and [[Avalanche]] ([http://urukgsoc.blogspot.hu/search/label/Avalanche blog]) into ScummVM. In fact, our support for the [[Wintermute]] engine was not only started by a GSoC student ([http://summermute2012.blogspot.com/ blog]), who integrated the code into our tree, but also [[Wintermute/Games|drastically improved]] by another student a year later ([https://icodelikeacow.wordpress.com/ blog]). <br />
<br />
[[File:GSOC_EMI.png|160px]] [[File:GSOC_zvision.png|152px]] [[File:GSOC_EMI_asm.png|147px]]<br />
<br />
A more challenging (but hopefully rewarding) idea is to start (or continue) reverse engineering a game where no source is available. Two good examples are the pair of students who drastically improved ResidualVM's support for Escape from Monkey Island ([http://diggingemi.blogspot.com/ blog], [http://akzgsoc.blogspot.com/ blog]), and the work on improving [[Operation Stealth]] ([https://buddhahacks.wordpress.com/ blog]). Another option is to work on merging (and improving) someone else's reverse engineering work, such as was done with the [[ZVision]] engine ([http://richiesams.blogspot.com/search/label/ScummVM blog]).<br />
<br />
If you'd prefer to improve ScummVM more directly, there are even more options available there; in the past, students have (to give some examples) improved our OpenGL support, added a testing framework ([http://jakimushka.blogspot.com/ blog]), improved our scaler code ([http://singron.blogspot.com/ blog]), written a new GUI framework, added loadable modules for embedded platforms ([http://tonypuccinelli.blogspot.com/search/label/ScummVM blog]), rearchitected our keyboard input code ([http://kenny-gsoc.blogspot.com/ blog]) and added support for high-colour (16bpp and above) graphics. It's difficult for us to imagine ScummVM as it was before some of these projects, you can make a huge difference!<br />
<br />
== Tasks ==<br />
<br />
General contacts: Our IRC channel, our mailing list, or contact [[User:Sev|sev]], [[User:DJWillis|John Willis]], [[User:Strangerke|Arnaud Boutonné]]<br />
<br />
The ideas here are meant to be just that - '''ideas'''. We hope they help inspire your proposals, but you should also consider suggesting your own completely new project ideas. Pick something you really want to see improved/fixed, and come and talk to us about it!<br />
<br />
If you're looking for more inspiration for ideas, beware of our [[TODO]] (and the other TODO lists linked from there) and our [[OpenTasks]] pages. Many of the tasks listed there might be incomplete or outdated, or too difficult for a new developer. The best thing to do is to come and talk to us!<br />
<br />
== Game Tasks ==<br />
<br />
Technical contacts: Our IRC channel, our mailing list, or contact [[User:Sev|sev]], [[User:DJWillis|John Willis]], [[User:Strangerke|Arnaud Boutonné]], [[User:Md5|Filippos Karapetis]],<br />
<br />
If you already have reverse engineering experience, you could consider working on one of the external in-development game engines, or even on support for a new game. However, doing this kind of work is very difficult and time-consuming - you would have to convince us that you have the necessary skills to actually be sufficiently productive, probably by demonstrating some actual progress first.<br />
<br />
If you don't feel quite up to that level of challenge, we have lots of other suggestions:<br />
<br />
=== Macromedia Director</span>===<br />
Technical contacts: [[User:Sev|sev]]<br />
<br />
Difficulty level: Medium. You'll need a reasonable level of programming experience, and probably some Director games.<br />
<br />
Many 90s-era adventure games were developed using the Macromedia (now Adobe) Director tool. It would be nice to be able to play these games in ScummVM! We have a WIP engine in ScummVM tree, but it requires much more work in order to implement all hundreds of Lingo commands.<br />
<br />
=== Networking code for Moonbase Commander===<br />
Technical contacts: [[User:Sev|sev]]<br />
<br />
Difficulty level: Medium. You'll need a reasonable level of programming experience, and some network development experience.<br />
<br />
[[Moonbase Commander]] is a SCUMM-based strategy game. The original supported up to 4 network players. We have the source code for the original game, but it is based on top of Microsoft DirectPlay. We need to do a clean reimplementation, not necessarily compatible with the original. It may also require some basic server side for discovery. The networking libraries libcurl and SDL_Net are already part of ScummVM.<br />
<br />
=== Wintermute 3D ===<br />
Technical contacts: [[User:somaen|Einar Johan Trøan Sømåen]], [[User:aquadran|Paweł Kołodziejski]]<br />
<br />
Difficulty level: Medium/hard. You'll need to be able to understand 3D graphics, and rearchitecture/design the relevant parts of the engine.<br />
<br />
In 2012, support for games using the Wintermute engine was merged into ScummVM, but it still lacks support for games which use 3D graphics. It would be great to be able to play these games in ResidualVM!<br />
<br />
'''ResidualVM project.''' See [http://wiki.residualvm.org/index.php/GSoC_Ideas#Wintermute_3D_port Wintermute 3D] for more details.<br />
<br />
=== In Cold Blood engine refactor ===<br />
Technical contacts: [[User:somaen|Einar Johan Trøan Sømåen]], [[User:aquadran|Paweł Kołodziejski]], [[User:joostp|Joost Peters]]<br />
<br />
Difficulty level: Medium/hard. You'll need to be able to understand the relevant parts of the engine.<br />
<br />
'''ResidualVM project.''' See [http://wiki.residualvm.org/index.php/GSoC_Ideas#In_Cold_Blood_engine_refactor ICB engine refactor] for more details<br />
<br />
=== Maupiti Island ===<br />
Technical contacts: [[User:Strangerke|Strangerke]]<br />
<br />
Difficult level: Medium to Hard. Good knowledge of C++ and some knowledge of Pascal and Assembly are required. Some knowledge of French could also help a bit, though Strangerke could translate anything on demand.<br />
<br />
Maupiti Island is the sequel of Mortevielle Manor, both released by Lankhor. Both games were best sellers at the time and were games of the year in France. Nevertheless, best sellers of the time were still selling low volumes and Maupiti Island is nowadays pretty rare ans unknown.<br />
<br />
Partial Pascal sources of Maupiti Island (Atari ST) have been secured recently. Some utility functions are missing, which were written using a mix of Pascal and assembly. So, the whole harcoded logic is available with most of the utility functions. Some reverse engineering may be required if the equivalent functions in Mortevielle are not working out of the box for the DOS version.<br />
<br />
The purpose of this task is to reimplement a Maupiti Island engine for the DOS variants of the game in at least two languages, using Mortevielle Manor and the original sources as documentation.<br />
<br />
[https://www.mobygames.com/game/dos/maupiti-island/screenshots/gameShotId,732668/ Screenshots on Mobygames]<br />
<br />
=== The Immortal ===<br />
<br />
Technical contacts [[User:dreammaster|dreammaster]] or [[User:Strangerke|Strangerke]]<br />
<br />
Difficulty level: Hard. Good knowledge of C++ and assembly (x86 or 68K or 6502) is required.<br />
<br />
The immortal was released in 1990 by Electronic Arts. It's a mix of genres involving RPG elements with action and puzzles.<br />
The gameplay is different one variant to the other, and all variants are written in assembly, making it more difficult to support all the variants.<br />
<br />
In 2018, a GSoC student picked this task but, due to personal issues, didn't manage to complete the task. The purpose of the task is therefore to implement an engine for a variant of the game, using the original sources and the work of JoeFish as a documentation.<br />
<br />
[https://www.mobygames.com/game/immortal/screenshots Screenshots on Mobygames]<br />
<br />
=== Bring your own Adventure or RPG ===<br />
<br />
Technical contacts: Talk to us on IRC, or send us an email.<br />
<br />
Difficulty: Hard. You'll need good knowledge of C++, as well as knowledge of (reading) assembly.<br />
<br />
Our project consists of re-implementations of classic games, and we have listed<br />
a number of potential new game engines that you could work on here on our ideas<br />
page. However, you may have a classic 2D Adventure game or Role Playing Game<br />
(RPG) you are interested in yourself that is suitable for ScummVM that you<br />
would like to reverse engineer and re-implement. If so, great!<br />
<br />
Adding a completely new game engine is not easy, and you will have to convince<br />
us that you are aware of the challenges involved, that the game you are<br />
interested in is feasible, and that you have the necessary skills. Preferably,<br />
you will already have done some preliminary investigation, into for example<br />
data file formats, disassembly, etc.<br />
<br />
Please come talk to us to see if we have a mentor who would be interested in<br />
working with you on such a game. We'd be happy to help out.<br />
<br />
== Infrastructure Tasks ==<br />
<br />
Finally, there's always plenty of other practical tasks on our wishlist!<br />
<br />
=== Improve Android port</span>===<br />
<br />
Technical contacts: [[User:Sev|Sev]]<br />
<br />
Difficulty level: Medium/hard. You'll need some knowledge of C++, Java and ideally Android development and OpenGL. Access to at least one Android device is probably also necessary.<br />
<br />
Our current Android port is in need of improvement, especially combined with modern versions of Android. We'd like to improve the GUI and the input code in particular, but hopefully you also have your own ideas if you've tried the port (if you haven't: do so!). There are some patches already available, and it should be possible to merge code from other projects (such as SDL 2). A native configuration GUI could also be an option.<br />
<br />
=== Game packaging system ===<br />
<br />
Technical contacts: [[User:Sev|sev]] or [[User:DJWillis|DJWillis]] <br />
<br />
ScummVM offers 8 freeware games for download, but they need to be downloaded and installed manually. It would be great to develop a universal system which would let us descibe a game, e.g. provide screenshots, game descriptions, metadata, and package it for different platforms, so we could put them to different applicaiton distribution systems.<br />
<br />
Examples are: Linux packages, Google Play, Apple App Store, Steam, ForgeTV store, and anything beyond that.<br />
<br />
=== Support for shaders and arbitrary scalers ===<br />
<br />
Technical contacts: [[User:Sev|sev]]<br />
<br />
Difficulty: Medium<br />
<br />
ScummVM uses software scalers for graphics enhancements. In 2012 we were running GSoC for turning them into plugins. [https://github.com/scummvm/scummvm/pull/271 That work] needs to be completed, basically, it is just rebasing of the patch. The rebasing was started here: https://github.com/digitall/scummvm/tree/gsoc2012-scalers-cont<br />
<br />
Modern systems often have OpenGL with shader support. RetroArch project shaders are standard for them in open source gaming. LordHoto started work on adding support for those to ScummVM. His unfinished work could be found here: https://github.com/lordhoto/scummvm/tree/libretro-shader<br />
<br />
We need to add both improvements to our scaler system. Recent PSP2 port already adds some basics for scalers, particularly in GUI, so that could be reused too.<br />
<br />
We need to have it tested on desktops and at least Android, but preferably also Windows and iOS.<br />
<br />
<br />
=== Programming interface ===<br />
<br />
Technical contacts: [[User:BgK|bgK]]<br />
<br />
Difficulty: Medium<br />
<br />
The goal of this project is to add a programming interface to ScummVM that other programs could use to interact with it. This would allow advanced users to write companion applications such as:<br />
* Game interface enhancement tools: Automappers for RPG / Interactive Fiction games. Interactive hint systems for adventure games.<br />
* Input automation tools: Regression testing / Tool Assisted Speedrun scripts.<br />
* Highly integrated frontends.<br />
* Debugging / game development tools.<br />
<br />
The interface needs to be bi-directional with the companion application being able to send requests to query information from ScummVM and to receive responses, but also for ScummVM to send notifications to the clients. The interface needs to be easy to integrate with from various programming languages and easy to experiment with.<br />
<br />
The scope of the project is to design and implement base system in ScummVM for Windows and Unix (using Named pipes / Unix domain sockets for communication), and to write a high quality companion application for one of the game engines in ScummVM.</div>
BgK
https://wiki.scummvm.org/index.php?title=Summer_of_Code/GSoC_Ideas_2020&diff=25931
Summer of Code/GSoC Ideas 2020
2020-01-25T10:17:14Z
<p>BgK: Remove completed tasks</p>
<hr />
<div>If you'd like to get involved in ScummVM - or one of our sister projects, such as ResidualVM - we'd love to help you get started!<br />
<br />
We've had a lot of successful student projects as part of Google's Summer of Code in previous years -- we hope to inspire you to work with us and (hopefully) add your own success.<br />
<br />
We often get asks by students with no experience with ScummVM whether they have the necessary skills to participate with us. The idea of GSoC is to introduce students to open source development, so we are not expecting you to have experience with ScummVM. You will have time during the application and community bonding periods to familiarize yourself with the project. The technical skills required to work with us varies from task to task. For any work on ScummVM, you'll probably need to already be comfortable with a basic level of C++. Some of the tasks might need more specialized knowledge (for example, working with ResidualVM may need you to understand some OpenGL and 3D math, and some engine tasks may require some assembly or reverse engineering knowledge); we give our thoughts about this alongside each suggested task, below.<br />
<br />
Most importantly, we'd like you to join our community. There are many previous GSoC participants who are still involved in our project, and whether or not you participate as part of Summer of Code, we'd love for you to get involved too.<br />
<br />
You should come to our [[IRC Channel]] and introduce yourself! We're friendly, and it's often the easiest way to ask questions about the tasks and the code in general. The channel is the main form of everyday communication for the project, and there will almost always be developers there who can discuss your project ideas, answer questions and help out.<br />
<br />
You can find more information about what we expect from you before you apply at [[GSoC Application]].<br />
<br />
__TOC__<br />
<br />
== Introduction ==<br />
<br />
We have a list of potential tasks further down on this page, but before you look at them, perhaps you'd like to take a look at some of the successful projects from previous years! We encourage all of our students to maintain a blog during their summer work, which is a nice way to get some sense of what they accomplished.<br />
<br />
One popular type of task is to improve our support for the games you love, whether this means a new game engine, or helping us to perfect an existing one.<br />
<br />
Sometimes source code is available - in recent summers, students integrated code supporting games such as [[Sfinx]] ([http://urukgsoc.blogspot.hu/search/label/CGE2 blog]), [[The Prince and the Coward]] ([http://lukaslwgsoc.blogspot.com/ blog]) and [[Avalanche]] ([http://urukgsoc.blogspot.hu/search/label/Avalanche blog]) into ScummVM. In fact, our support for the [[Wintermute]] engine was not only started by a GSoC student ([http://summermute2012.blogspot.com/ blog]), who integrated the code into our tree, but also [[Wintermute/Games|drastically improved]] by another student a year later ([https://icodelikeacow.wordpress.com/ blog]). <br />
<br />
[[File:GSOC_EMI.png|160px]] [[File:GSOC_zvision.png|152px]] [[File:GSOC_EMI_asm.png|147px]]<br />
<br />
A more challenging (but hopefully rewarding) idea is to start (or continue) reverse engineering a game where no source is available. Two good examples are the pair of students who drastically improved ResidualVM's support for Escape from Monkey Island ([http://diggingemi.blogspot.com/ blog], [http://akzgsoc.blogspot.com/ blog]), and the work on improving [[Operation Stealth]] ([https://buddhahacks.wordpress.com/ blog]). Another option is to work on merging (and improving) someone else's reverse engineering work, such as was done with the [[ZVision]] engine ([http://richiesams.blogspot.com/search/label/ScummVM blog]).<br />
<br />
If you'd prefer to improve ScummVM more directly, there are even more options available there; in the past, students have (to give some examples) improved our OpenGL support, added a testing framework ([http://jakimushka.blogspot.com/ blog]), improved our scaler code ([http://singron.blogspot.com/ blog]), written a new GUI framework, added loadable modules for embedded platforms ([http://tonypuccinelli.blogspot.com/search/label/ScummVM blog]), rearchitected our keyboard input code ([http://kenny-gsoc.blogspot.com/ blog]) and added support for high-colour (16bpp and above) graphics. It's difficult for us to imagine ScummVM as it was before some of these projects, you can make a huge difference!<br />
<br />
== Tasks ==<br />
<br />
General contacts: Our IRC channel, our mailing list, or contact [[User:Sev|sev]], [[User:DJWillis|John Willis]], [[User:Strangerke|Arnaud Boutonné]]<br />
<br />
The ideas here are meant to be just that - '''ideas'''. We hope they help inspire your proposals, but you should also consider suggesting your own completely new project ideas. Pick something you really want to see improved/fixed, and come and talk to us about it!<br />
<br />
If you're looking for more inspiration for ideas, beware of our [[TODO]] (and the other TODO lists linked from there) and our [[OpenTasks]] pages. Many of the tasks listed there might be incomplete or outdated, or too difficult for a new developer. The best thing to do is to come and talk to us!<br />
<br />
== Game Tasks ==<br />
<br />
Technical contacts: Our IRC channel, our mailing list, or contact [[User:Sev|sev]], [[User:DJWillis|John Willis]], [[User:Strangerke|Arnaud Boutonné]], [[User:Md5|Filippos Karapetis]],<br />
<br />
If you already have reverse engineering experience, you could consider working on one of the external in-development game engines, or even on support for a new game. However, doing this kind of work is very difficult and time-consuming - you would have to convince us that you have the necessary skills to actually be sufficiently productive, probably by demonstrating some actual progress first.<br />
<br />
If you don't feel quite up to that level of challenge, we have lots of other suggestions:<br />
<br />
=== Macromedia Director</span>===<br />
Technical contacts: [[User:Sev|sev]]<br />
<br />
Difficulty level: Medium. You'll need a reasonable level of programming experience, and probably some Director games.<br />
<br />
Many 90s-era adventure games were developed using the Macromedia (now Adobe) Director tool. It would be nice to be able to play these games in ScummVM! We have a WIP engine in ScummVM tree, but it requires much more work in order to implement all hundreds of Lingo commands.<br />
<br />
=== Networking code for Moonbase Commander===<br />
Technical contacts: [[User:Sev|sev]]<br />
<br />
Difficulty level: Medium. You'll need a reasonable level of programming experience, and some network development experience.<br />
<br />
[[Moonbase Commander]] is a SCUMM-based strategy game. The original supported up to 4 network players. We have the source code for the original game, but it is based on top of Microsoft DirectPlay. We need to do a clean reimplementation, not necessarily compatible with the original. It may also require some basic server side for discovery. The networking libraries libcurl and SDL_Net are already part of ScummVM.<br />
<br />
=== Wintermute 3D ===<br />
Technical contacts: [[User:somaen|Einar Johan Trøan Sømåen]], [[User:aquadran|Paweł Kołodziejski]]<br />
<br />
Difficulty level: Medium/hard. You'll need to be able to understand 3D graphics, and rearchitecture/design the relevant parts of the engine.<br />
<br />
In 2012, support for games using the Wintermute engine was merged into ScummVM, but it still lacks support for games which use 3D graphics. It would be great to be able to play these games in ResidualVM!<br />
<br />
'''ResidualVM project.''' See [http://wiki.residualvm.org/index.php/GSoC_Ideas#Wintermute_3D_port Wintermute 3D] for more details.<br />
<br />
=== In Cold Blood engine refactor ===<br />
Technical contacts: [[User:somaen|Einar Johan Trøan Sømåen]], [[User:aquadran|Paweł Kołodziejski]], [[User:joostp|Joost Peters]]<br />
<br />
Difficulty level: Medium/hard. You'll need to be able to understand the relevant parts of the engine.<br />
<br />
'''ResidualVM project.''' See [http://wiki.residualvm.org/index.php/GSoC_Ideas#In_Cold_Blood_engine_refactor ICB engine refactor] for more details<br />
<br />
=== Maupiti Island ===<br />
Technical contacts: [[User:Strangerke|Strangerke]]<br />
<br />
Difficult level: Medium to Hard. Good knowledge of C++ and some knowledge of Pascal and Assembly are required. Some knowledge of French could also help a bit, though Strangerke could translate anything on demand.<br />
<br />
Maupiti Island is the sequel of Mortevielle Manor, both released by Lankhor. Both games were best sellers at the time and were games of the year in France. Nevertheless, best sellers of the time were still selling low volumes and Maupiti Island is nowadays pretty rare ans unknown.<br />
<br />
Partial Pascal sources of Maupiti Island (Atari ST) have been secured recently. Some utility functions are missing, which were written using a mix of Pascal and assembly. So, the whole harcoded logic is available with most of the utility functions. Some reverse engineering may be required if the equivalent functions in Mortevielle are not working out of the box for the DOS version.<br />
<br />
The purpose of this task is to reimplement a Maupiti Island engine for the DOS variants of the game in at least two languages, using Mortevielle Manor and the original sources as documentation.<br />
<br />
[https://www.mobygames.com/game/dos/maupiti-island/screenshots/gameShotId,732668/ Screenshots on Mobygames]<br />
<br />
=== The Immortal ===<br />
<br />
Technical contacts [[User:dreammaster|dreammaster]] or [[User:Strangerke|Strangerke]]<br />
<br />
Difficulty level: Hard. Good knowledge of C++ and assembly (x86 or 68K or 6502) is required.<br />
<br />
The immortal was released in 1990 by Electronic Arts. It's a mix of genres involving RPG elements with action and puzzles.<br />
The gameplay is different one variant to the other, and all variants are written in assembly, making it more difficult to support all the variants.<br />
<br />
In 2018, a GSoC student picked this task but, due to personal issues, didn't manage to complete the task. The purpose of the task is therefore to implement an engine for a variant of the game, using the original sources and the work of JoeFish as a documentation.<br />
<br />
[https://www.mobygames.com/game/immortal/screenshots Screenshots on Mobygames]<br />
<br />
=== Bring your own Adventure or RPG ===<br />
<br />
Technical contacts: Talk to us on IRC, or send us an email.<br />
<br />
Difficulty: Hard. You'll need good knowledge of C++, as well as knowledge of (reading) assembly.<br />
<br />
Our project consists of re-implementations of classic games, and we have listed<br />
a number of potential new game engines that you could work on here on our ideas<br />
page. However, you may have a classic 2D Adventure game or Role Playing Game<br />
(RPG) you are interested in yourself that is suitable for ScummVM that you<br />
would like to reverse engineer and re-implement. If so, great!<br />
<br />
Adding a completely new game engine is not easy, and you will have to convince<br />
us that you are aware of the challenges involved, that the game you are<br />
interested in is feasible, and that you have the necessary skills. Preferably,<br />
you will already have done some preliminary investigation, into for example<br />
data file formats, disassembly, etc.<br />
<br />
Please come talk to us to see if we have a mentor who would be interested in<br />
working with you on such a game. We'd be happy to help out.<br />
<br />
== Infrastructure Tasks ==<br />
<br />
Finally, there's always plenty of other practical tasks on our wishlist!<br />
<br />
=== Improve Android port</span>===<br />
<br />
Technical contacts: [[User:Sev|Sev]]<br />
<br />
Difficulty level: Medium/hard. You'll need some knowledge of C++, Java and ideally Android development and OpenGL. Access to at least one Android device is probably also necessary.<br />
<br />
Our current Android port is in need of improvement, especially combined with modern versions of Android. We'd like to improve the GUI and the input code in particular, but hopefully you also have your own ideas if you've tried the port (if you haven't: do so!). There are some patches already available, and it should be possible to merge code from other projects (such as SDL 2). A native configuration GUI could also be an option.<br />
<br />
=== Game packaging system ===<br />
<br />
Technical contacts: [[User:Sev|sev]] or [[User:DJWillis|DJWillis]] <br />
<br />
ScummVM offers 8 freeware games for download, but they need to be downloaded and installed manually. It would be great to develop a universal system which would let us descibe a game, e.g. provide screenshots, game descriptions, metadata, and package it for different platforms, so we could put them to different applicaiton distribution systems.<br />
<br />
Examples are: Linux packages, Google Play, Apple App Store, Steam, ForgeTV store, and anything beyond that.<br />
<br />
=== Support for shaders and arbitrary scalers ===<br />
<br />
Technical contacts: [[User:Sev|sev]]<br />
<br />
Difficulty: Medium<br />
<br />
ScummVM uses software scalers for graphics enhancements. In 2012 we were running GSoC for turning them into plugins. [https://github.com/scummvm/scummvm/pull/271 That work] needs to be completed, basically, it is just rebasing of the patch. The rebasing was started here: https://github.com/digitall/scummvm/tree/gsoc2012-scalers-cont<br />
<br />
Modern systems often have OpenGL with shader support. RetroArch project shaders are standard for them in open source gaming. LordHoto started work on adding support for those to ScummVM. His unfinished work could be found here: https://github.com/lordhoto/scummvm/tree/libretro-shader<br />
<br />
We need to add both improvements to our scaler system. Recent PSP2 port already adds some basics for scalers, particularly in GUI, so that could be reused too.<br />
<br />
We need to have it tested on desktops and at least Android, but preferably also Windows and iOS.</div>
BgK
https://wiki.scummvm.org/index.php?title=Summer_of_Code/GSoC_Ideas_2020&diff=25930
Summer of Code/GSoC Ideas 2020
2020-01-25T10:16:02Z
<p>BgK: Duplicate the 2019 page</p>
<hr />
<div>If you'd like to get involved in ScummVM - or one of our sister projects, such as ResidualVM - we'd love to help you get started!<br />
<br />
We've had a lot of successful student projects as part of Google's Summer of Code in previous years -- we hope to inspire you to work with us and (hopefully) add your own success.<br />
<br />
We often get asks by students with no experience with ScummVM whether they have the necessary skills to participate with us. The idea of GSoC is to introduce students to open source development, so we are not expecting you to have experience with ScummVM. You will have time during the application and community bonding periods to familiarize yourself with the project. The technical skills required to work with us varies from task to task. For any work on ScummVM, you'll probably need to already be comfortable with a basic level of C++. Some of the tasks might need more specialized knowledge (for example, working with ResidualVM may need you to understand some OpenGL and 3D math, and some engine tasks may require some assembly or reverse engineering knowledge); we give our thoughts about this alongside each suggested task, below.<br />
<br />
Most importantly, we'd like you to join our community. There are many previous GSoC participants who are still involved in our project, and whether or not you participate as part of Summer of Code, we'd love for you to get involved too.<br />
<br />
You should come to our [[IRC Channel]] and introduce yourself! We're friendly, and it's often the easiest way to ask questions about the tasks and the code in general. The channel is the main form of everyday communication for the project, and there will almost always be developers there who can discuss your project ideas, answer questions and help out.<br />
<br />
You can find more information about what we expect from you before you apply at [[GSoC Application]].<br />
<br />
__TOC__<br />
<br />
== Introduction ==<br />
<br />
We have a list of potential tasks further down on this page, but before you look at them, perhaps you'd like to take a look at some of the successful projects from previous years! We encourage all of our students to maintain a blog during their summer work, which is a nice way to get some sense of what they accomplished.<br />
<br />
One popular type of task is to improve our support for the games you love, whether this means a new game engine, or helping us to perfect an existing one.<br />
<br />
Sometimes source code is available - in recent summers, students integrated code supporting games such as [[Sfinx]] ([http://urukgsoc.blogspot.hu/search/label/CGE2 blog]), [[The Prince and the Coward]] ([http://lukaslwgsoc.blogspot.com/ blog]) and [[Avalanche]] ([http://urukgsoc.blogspot.hu/search/label/Avalanche blog]) into ScummVM. In fact, our support for the [[Wintermute]] engine was not only started by a GSoC student ([http://summermute2012.blogspot.com/ blog]), who integrated the code into our tree, but also [[Wintermute/Games|drastically improved]] by another student a year later ([https://icodelikeacow.wordpress.com/ blog]). <br />
<br />
[[File:GSOC_EMI.png|160px]] [[File:GSOC_zvision.png|152px]] [[File:GSOC_EMI_asm.png|147px]]<br />
<br />
A more challenging (but hopefully rewarding) idea is to start (or continue) reverse engineering a game where no source is available. Two good examples are the pair of students who drastically improved ResidualVM's support for Escape from Monkey Island ([http://diggingemi.blogspot.com/ blog], [http://akzgsoc.blogspot.com/ blog]), and the work on improving [[Operation Stealth]] ([https://buddhahacks.wordpress.com/ blog]). Another option is to work on merging (and improving) someone else's reverse engineering work, such as was done with the [[ZVision]] engine ([http://richiesams.blogspot.com/search/label/ScummVM blog]).<br />
<br />
If you'd prefer to improve ScummVM more directly, there are even more options available there; in the past, students have (to give some examples) improved our OpenGL support, added a testing framework ([http://jakimushka.blogspot.com/ blog]), improved our scaler code ([http://singron.blogspot.com/ blog]), written a new GUI framework, added loadable modules for embedded platforms ([http://tonypuccinelli.blogspot.com/search/label/ScummVM blog]), rearchitected our keyboard input code ([http://kenny-gsoc.blogspot.com/ blog]) and added support for high-colour (16bpp and above) graphics. It's difficult for us to imagine ScummVM as it was before some of these projects, you can make a huge difference!<br />
<br />
== Tasks ==<br />
<br />
General contacts: Our IRC channel, our mailing list, or contact [[User:Sev|sev]], [[User:DJWillis|John Willis]], [[User:Strangerke|Arnaud Boutonné]]<br />
<br />
The ideas here are meant to be just that - '''ideas'''. We hope they help inspire your proposals, but you should also consider suggesting your own completely new project ideas. Pick something you really want to see improved/fixed, and come and talk to us about it!<br />
<br />
If you're looking for more inspiration for ideas, beware of our [[TODO]] (and the other TODO lists linked from there) and our [[OpenTasks]] pages. Many of the tasks listed there might be incomplete or outdated, or too difficult for a new developer. The best thing to do is to come and talk to us!<br />
<br />
== Game Tasks ==<br />
<br />
Technical contacts: Our IRC channel, our mailing list, or contact [[User:Sev|sev]], [[User:DJWillis|John Willis]], [[User:Strangerke|Arnaud Boutonné]], [[User:Md5|Filippos Karapetis]],<br />
<br />
If you already have reverse engineering experience, you could consider working on one of the external in-development game engines, or even on support for a new game. However, doing this kind of work is very difficult and time-consuming - you would have to convince us that you have the necessary skills to actually be sufficiently productive, probably by demonstrating some actual progress first.<br />
<br />
If you don't feel quite up to that level of challenge, we have lots of other suggestions:<br />
<br />
=== Macromedia Director</span>===<br />
Technical contacts: [[User:Sev|sev]]<br />
<br />
Difficulty level: Medium. You'll need a reasonable level of programming experience, and probably some Director games.<br />
<br />
Many 90s-era adventure games were developed using the Macromedia (now Adobe) Director tool. It would be nice to be able to play these games in ScummVM! We have a WIP engine in ScummVM tree, but it requires much more work in order to implement all hundreds of Lingo commands.<br />
<br />
=== Networking code for Moonbase Commander===<br />
Technical contacts: [[User:Sev|sev]]<br />
<br />
Difficulty level: Medium. You'll need a reasonable level of programming experience, and some network development experience.<br />
<br />
[[Moonbase Commander]] is a SCUMM-based strategy game. The original supported up to 4 network players. We have the source code for the original game, but it is based on top of Microsoft DirectPlay. We need to do a clean reimplementation, not necessarily compatible with the original. It may also require some basic server side for discovery. The networking libraries libcurl and SDL_Net are already part of ScummVM.<br />
<br />
=== Wintermute 3D ===<br />
Technical contacts: [[User:somaen|Einar Johan Trøan Sømåen]], [[User:aquadran|Paweł Kołodziejski]]<br />
<br />
Difficulty level: Medium/hard. You'll need to be able to understand 3D graphics, and rearchitecture/design the relevant parts of the engine.<br />
<br />
In 2012, support for games using the Wintermute engine was merged into ScummVM, but it still lacks support for games which use 3D graphics. It would be great to be able to play these games in ResidualVM!<br />
<br />
'''ResidualVM project.''' See [http://wiki.residualvm.org/index.php/GSoC_Ideas#Wintermute_3D_port Wintermute 3D] for more details.<br />
<br />
=== In Cold Blood engine refactor ===<br />
Technical contacts: [[User:somaen|Einar Johan Trøan Sømåen]], [[User:aquadran|Paweł Kołodziejski]], [[User:joostp|Joost Peters]]<br />
<br />
Difficulty level: Medium/hard. You'll need to be able to understand the relevant parts of the engine.<br />
<br />
'''ResidualVM project.''' See [http://wiki.residualvm.org/index.php/GSoC_Ideas#In_Cold_Blood_engine_refactor ICB engine refactor] for more details<br />
<br />
=== Maupiti Island ===<br />
Technical contacts: [[User:Strangerke|Strangerke]]<br />
<br />
Difficult level: Medium to Hard. Good knowledge of C++ and some knowledge of Pascal and Assembly are required. Some knowledge of French could also help a bit, though Strangerke could translate anything on demand.<br />
<br />
Maupiti Island is the sequel of Mortevielle Manor, both released by Lankhor. Both games were best sellers at the time and were games of the year in France. Nevertheless, best sellers of the time were still selling low volumes and Maupiti Island is nowadays pretty rare ans unknown.<br />
<br />
Partial Pascal sources of Maupiti Island (Atari ST) have been secured recently. Some utility functions are missing, which were written using a mix of Pascal and assembly. So, the whole harcoded logic is available with most of the utility functions. Some reverse engineering may be required if the equivalent functions in Mortevielle are not working out of the box for the DOS version.<br />
<br />
The purpose of this task is to reimplement a Maupiti Island engine for the DOS variants of the game in at least two languages, using Mortevielle Manor and the original sources as documentation.<br />
<br />
[https://www.mobygames.com/game/dos/maupiti-island/screenshots/gameShotId,732668/ Screenshots on Mobygames]<br />
<br />
=== Hyperspace Delivery Boy ===<br />
Technical contact: [[User:sev|sev]] or [[User:DJWillis|DJWillis]] <br />
<br />
Difficulty level: Medium to hard. Good knowledge of C++ and some knowledge of Lua are required.<br />
<br />
Hyperspace Delivery Boy if a game written by (between others) John Romero after he left ID Software. The games has been ported to multiple platforms and is somehow a zelda like, mixing RPG, action and puzzles.<br />
<br />
The original sources have been secured. they are written in C++ and Lua.<br />
<br />
The purpose of the task is to write an engine for ScummVM of the Windows version. Sword25 engine is also written using Lua and could be used as an example of how to proceed.<br />
<br />
[https://www.mobygames.com/game/windows/hyperspace-delivery-boy/screenshots Screenshots on Mobygames]<br />
<br />
=== Mission Supernova games ===<br />
<br />
Technical contacts: [[User:Strangerke|Strangerke]] or [[User:Criezy|Criezy]]<br />
<br />
Difficulty level: Medium. Good knowledge of C++ and basic knowledge of C and ASM is required. Some knowledge of German language would also help. <br />
<br />
There were several adventure games by Steffen Dingel, which are freeware now: http://outpost.simplicity.de/ Among them were Mission Supernova and Mission Supernova 2.<br />
<br />
We got hold of the original source code written in C with some x86 assembler and Mission Supernova was ported to ScummVM and translated to English as part of GSoC 2017. We now need to rewrite the second game as well in a portable C++ and polish its English translation.<br />
<br />
=== The Immortal ===<br />
<br />
Technical contacts [[User:dreammaster|dreammaster]] or [[User:Strangerke|Strangerke]]<br />
<br />
Difficulty level: Hard. Good knowledge of C++ and assembly (x86 or 68K or 6502) is required.<br />
<br />
The immortal was released in 1990 by Electronic Arts. It's a mix of genres involving RPG elements with action and puzzles.<br />
The gameplay is different one variant to the other, and all variants are written in assembly, making it more difficult to support all the variants.<br />
<br />
In 2018, a GSoC student picked this task but, due to personal issues, didn't manage to complete the task. The purpose of the task is therefore to implement an engine for a variant of the game, using the original sources and the work of JoeFish as a documentation.<br />
<br />
[https://www.mobygames.com/game/immortal/screenshots Screenshots on Mobygames]<br />
<br />
=== Bring your own Adventure or RPG ===<br />
<br />
Technical contacts: Talk to us on IRC, or send us an email.<br />
<br />
Difficulty: Hard. You'll need good knowledge of C++, as well as knowledge of (reading) assembly.<br />
<br />
Our project consists of re-implementations of classic games, and we have listed<br />
a number of potential new game engines that you could work on here on our ideas<br />
page. However, you may have a classic 2D Adventure game or Role Playing Game<br />
(RPG) you are interested in yourself that is suitable for ScummVM that you<br />
would like to reverse engineer and re-implement. If so, great!<br />
<br />
Adding a completely new game engine is not easy, and you will have to convince<br />
us that you are aware of the challenges involved, that the game you are<br />
interested in is feasible, and that you have the necessary skills. Preferably,<br />
you will already have done some preliminary investigation, into for example<br />
data file formats, disassembly, etc.<br />
<br />
Please come talk to us to see if we have a mentor who would be interested in<br />
working with you on such a game. We'd be happy to help out.<br />
<br />
== Infrastructure Tasks ==<br />
<br />
Finally, there's always plenty of other practical tasks on our wishlist!<br />
<br />
=== Improve Android port</span>===<br />
<br />
Technical contacts: [[User:Sev|Sev]]<br />
<br />
Difficulty level: Medium/hard. You'll need some knowledge of C++, Java and ideally Android development and OpenGL. Access to at least one Android device is probably also necessary.<br />
<br />
Our current Android port is in need of improvement, especially combined with modern versions of Android. We'd like to improve the GUI and the input code in particular, but hopefully you also have your own ideas if you've tried the port (if you haven't: do so!). There are some patches already available, and it should be possible to merge code from other projects (such as SDL 2). A native configuration GUI could also be an option.<br />
<br />
=== Game packaging system ===<br />
<br />
Technical contacts: [[User:Sev|sev]] or [[User:DJWillis|DJWillis]] <br />
<br />
ScummVM offers 8 freeware games for download, but they need to be downloaded and installed manually. It would be great to develop a universal system which would let us descibe a game, e.g. provide screenshots, game descriptions, metadata, and package it for different platforms, so we could put them to different applicaiton distribution systems.<br />
<br />
Examples are: Linux packages, Google Play, Apple App Store, Steam, ForgeTV store, and anything beyond that.<br />
<br />
=== Support for shaders and arbitrary scalers ===<br />
<br />
Technical contacts: [[User:Sev|sev]]<br />
<br />
Difficulty: Medium<br />
<br />
ScummVM uses software scalers for graphics enhancements. In 2012 we were running GSoC for turning them into plugins. [https://github.com/scummvm/scummvm/pull/271 That work] needs to be completed, basically, it is just rebasing of the patch. The rebasing was started here: https://github.com/digitall/scummvm/tree/gsoc2012-scalers-cont<br />
<br />
Modern systems often have OpenGL with shader support. RetroArch project shaders are standard for them in open source gaming. LordHoto started work on adding support for those to ScummVM. His unfinished work could be found here: https://github.com/lordhoto/scummvm/tree/libretro-shader<br />
<br />
We need to add both improvements to our scaler system. Recent PSP2 port already adds some basics for scalers, particularly in GUI, so that could be reused too.<br />
<br />
We need to have it tested on desktops and at least Android, but preferably also Windows and iOS.</div>
BgK
https://wiki.scummvm.org/index.php?title=GSoC_Ideas&diff=25929
GSoC Ideas
2020-01-25T10:14:58Z
<p>BgK: Switch to the 2020 ideas page from 2019</p>
<hr />
<div><br />
<br />
<br />
----<br />
<br />
'''See [[Summer of Code/GSoC Ideas 2020|GSoC Ideas 2020]]''' for the 2020 version of this page.<br />
<br />
----<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<!--This page contains a list of ideas about projects/tasks for the ScummVM and the ResidualVM projects which we feel are relatively substantial (and so appropriate for at least ''part'' of a Google [[Summer of Code]] project), and accessible to newcomers with good C++ knowledge.<br />
<br />
These are just the few projects that we have come up with ourselves, and there are many many other tasks which would be helpful to the project - many ScummVM engines have their own TODO lists, and there are large tasks related to ResidualVM engines.<br />
<br />
Of course, if you are not participating in Summer of Code, you are also very welcome to try working on one of these projects.<br />
<br />
__TOC__<br />
== Introduction ==<br />
<br />
The projects below are sketches and ideas. Our project changes over time, so if you're not reading this during the Summer of Code application period, the descriptions might be outdated by the time you read them (although we strive to keep them up-to-date). You should talk with somebody from the team, ideally with someone listed as a possible technical contact, before starting work on any of them.<br />
<br />
Most developers are active in our [[IRC Channel]], and that is often the easiest way to ask questions about the tasks and the code in general. '''You should come to our IRC channel and introduce yourself.''' The channel is the main form of everyday communication for the project, and there will almost always be developers there who can discuss your project ideas and answer questions.<br />
<br />
== Summer of Code Applications ==<br />
The ideas here are meant to be just that - '''ideas'''. You should also consider suggesting your own completely new project ideas, or to suggest a modified version of one of our ideas, or a combination of ideas. Not all the ideas might be substantial enough for the whole of GSoC, while other ideas might be far too much work. We expect you to consider this in your application and proposed schedule.<br />
<br />
When writing this application, remember that the application has several important purposes. First of all, it should identify the objectives of your project (what you intend to get done). Furthermore, it needs to convince us your project is worth the effort we will be putting into mentoring it. Last, but not least, it should convince us that you are the right person for this task.<br />
<br />
In particular, your application is your opportunity to show us that you understand what you'll be doing for the task! We expect you to demonstrate that you've spent some of your own time thinking about it. A good example of what we do ''not'' want to see in your application is a copy of the text from our version of an idea's description.<br />
<br />
You '''must''' read the Summer of Code [[Summer of Code/Project Rules | Project Rules]], which are '''obligatory''' for our students, and tell you what you should do '''before you apply'''. There are also some [[Summer of Code/Students Guidelines | Guidelines]] for our students.<br />
<br />
We don't expect you to produce a perfect application without any help at all (although of course, that would be even more impressive), but we do expect you to show some independent insight into the task you've chosen, and to be willing to improve it based on our feedback and comments.<br />
<br />
=== Application template ===<br />
<br />
Your application should have at least the following information (adapted from the FreeBSD guidelines):<br />
<br />
* ''Name''<br />
* ''Email''<br />
* ''Online nicks''<br />
: You should at least add your IRC (freenode) nickname here.<br />
* ''Project Title''<br />
: State precisely what you intend your project to be about. 40 characters is usually a good upper limit.<br />
* ''Possible Mentor'' (optional)<br />
* ''Benefits to the ScummVM Community''<br />
: A good project will not just be fun to work on, but also generally useful to others. Why do you think it's a good project for us?<br />
* ''Deliverables''<br />
: The deliverables will be used to evaluate your progress/success at the mid-term/final evaluations, so it's very important that you list some clear goals here. Some examples:<br />
:* "Get scene X in game Y working."<br />
:* "Improve feature X in ways Y and Z."<br />
:* "Fix bug Z in game Q."<br />
:* "Write documentation for the new interfaces."<br />
:* "Improve test coverage by writing X more unit/regression tests."<br />
:* "Improve performance in this game scene by 20%."<br />
: Make sure there is a clearly visible set of '''goals''' that need to be accomplished for your project to be considered successful. It is also encouraged to list additional goals you plan to accomplish in the course of your project if everything goes as expected.<br />
: You should be sure to justify whether a goal is vital for the success of your project, or just optional, but be make sure not to mix this up with the description of the goals themselves.<br />
: Finally, be sure to describe some '''milestones''', your targets for the project. A milestone should be connected to the progress/accomplishment of goals. You should, at the very least, define 2 (two) milestones here. Again, describe the milestones and elaborate on your reasons for defining exactly these milestones. When you plan to accomplish the milestones will be handled in the schedule and not here.<br />
* ''Project Schedule''<br />
: Create a proposed schedule with (at least) the granularity of weeks. This schedule should (among other things) explain how long your project will take and when you can begin to work on it, and you should connect the weeks to the Summer of Code schedule, i.e. clearly make the start, mid-term evaluations, etc. visible. There are multiple ways to organize this, we trust you to find the best way to present your schedule.<br />
: Obviously we want to see a connection between your goals and your schedule: be sure to elaborate why you think X takes time Y and what possible issues might arise here; obviously your schedule will probably change once you've started working on your project, so we want to know what kind of risks and problems you think might cause such changes.<br />
: Last but not least, put a fixed date for each milestone you defined here. We want at least one milestone before the mid-term.<br />
* ''Availability''<br />
: How many hours per week can you spend working on this? What other obligations do you have this summer? Be honest if you're not going to have time in some weeks (due to exams, or vacation, or other work), and explain how plan to make this up.<br />
* ''Skype ID''<br />
: If you don't use Skype, install it.<br />
* ''Phone Number''<br />
: Cellular is preferable, for emergency contacts.<br />
* ''Timezone''<br />
: Where do you live.<br />
* ''Bio''<br />
: The two main questions you should answer here are:<br />
:* Who are you?<br />
:* What makes you the best person to work on this project?<br />
: Make sure you fill this with some life. We would like to know your age and university year for example. Also, explain your connection to ScummVM in the general and to your project in specific. What experience do you have with C++ or other languages required in your project? Have you taken university courses which you think will be helpful? Did you work on any projects we can take a look at? Do you think you will learn anything from your proposed project (if yes, explain what)?<br />
* ''Pull Request''<br />
: A link to the pull request you submitted as part of our [[Summer of Code/Project Rules | Project Rules]]<br />
<br />
=== Coding Rules ===<br />
<br />
You must follow our [[Coding Conventions]]. In particular, note that you can't use the standard C++ library for code used inside ScummVM itself. Using it for a non-essential tool should be fine, though.<br />
<br />
All code, unless stated differently (for example, platform-specific code), must be written in clean and portable C++; in particular, various versions of both GCC and Visual Studio must be able to compile it. We also have some [[Code Formatting Conventions]].<br />
<br />
We only accept clean and maintainable code. This is a somewhat vague requirement, but as a rule of thumb, if the code does what it is supposed to do, but is not extensible, a quick hack, or we need to rewrite it from scratch to properly integrate it, we will not accept it. In particular, we would rather have a maintainable, clean and incomplete piece of code that we could extend, than a complete but unmaintainable piece of code.<br />
<br />
Finally: All of the code submitted must be contributed under the terms of the GPL v2+.<br />
<br />
== ScummVM Projects ==<br />
=== Audio Output Configuration ===<br />
<br />
Technical contact: [[User:LordHoto|Johannes Schickel]].<br />
<br />
ScummVM needs an improved internal API and user interface for selecting and controlling audio output. Among other issues, at present there isn't a clear distinction between audio ''types', audio ''drivers'' and audio ''devices''.<br />
<br />
The idea is that a proper layer-based audio output system should be designed, implemented and used in all our engines, and an appropriate configuration GUI should be designed and added too.<br />
<br />
'''As this task involves a very precise design before starting implementation, please keep in touch with the mentors as soon as possible if you're interested.'''<br />
<br />
See [[OpenTasks/Audio/Audio Output Selection]] for more discussion and some technical details.<br />
<br />
=== MIDI Device Configuration ===<br />
<br />
Technical contact: [[User:LordHoto|Johannes Schickel]].<br />
<br />
At the moment, configuration of MIDI output is not linked to devices, despite a lot of the configuration options being specific to a device or driver.<br />
<br />
This task would involve designing and implementing an interface for querying and storage of a wide variety of MIDI drivers/devices, improving the GUI to allow this configuration, and working on some related improvements (such as allowing devices to be added/removed while ScummVM is running).<br />
<br />
'''As this task involves a very precise design before starting implementation, please keep in touch with the mentors as soon as possible if you're interested.'''<br />
<br />
See [[OpenTasks/Audio/MIDI Device Configuration]] for more discussion and some technical details.<br />
<br />
=== Improve Main GUI ===<br />
<br />
Technical contacts: [[User:Sev|Eugene Sandulenko]].<br />
<br />
Several years ago we switched to new XML-based and vector-based GUI. Unfortunately during this transition number of nice touches from previous version of Modern GUI were lost. Particularly current GUI lacks soft shadows, antialiasing in number of places, we are lacking proper widgets for PopUp and List widgets. Those need to be implemented as part of this task.<br />
<br />
Also there is need to implement better sliders, multiline text widgets as well as improve current List widget.<br />
<br />
See [[OpenTasks/Generic/Improve GUI Look]] for more details.<br />
<br />
=== Improve touchscreen GUI ===<br />
<br />
Technical contacts: [[User:Sev|Eugene Sandulenko]].<br />
<br />
Our launcher/options GUI has been designed for keyboard/mouse input, and does<br />
not work well in practice on modern touchscreen devices.<br />
<br />
Since it is theme based, part of the problem can be resolved by using a custom<br />
theme. However, our GUI code will need extensions to allow it to behave like a<br />
proper touchscreen application.<br />
<br />
See [[OpenTasks/Generic/Touch GUI]] for more details.<br />
<br />
=== Hardware accelerated blitting ===<br />
Technical contacts: Our IRC channel, our mailing list, or contact [[User:somaen|Einar Johan Trøan Sømåen]], [[User:LordHoto|Johannes Schickel]], [[User:Fuzzie|Alyssa Milburn]], [[User:Digitall|David G. Turner]]<br />
<br />
Some engines (Wintermute, Broken Sword 2.5) would greatly benefit from hardware acceleration for their graphics code.<br />
Obviously the purpose of this task is not to make it available on all ports. The impacted ports have to be determined in advance.<br />
<br />
See [[OpenTasks/Graphics/Hardware Acceleration]] for more details.<br />
<br />
=== Improve AGI Engine ===<br />
Technical contacts: [[User:Sev|Eugene Sandulenko]].<br />
<br />
The current implementation of our AGI Engine, which is used for the early Sierra On Line games; would greatly benefit from some implementation details present in the other open source AGI interpreter, NAGI.<br />
<br />
The important parts of this task would be to analyze the implementation differences between the ScummVM implementation and NAGI, particularly in the main loop and in the rendering class, then to reimplement these in the ScummVM engine without causing regressions of the currently supported games and to improve the support of the latest AGI games including the fangames.<br />
<br />
See [[OpenTasks/Engine/ImproveAGI]] for more details.<br />
<br />
=== Adding text to speech support in Mortville Manor ===<br />
Technical contacts: Our IRC channel, our mailing list, or contact [[User:Strangerke|Arnaud Boutonné]] or [[User:criezy|Thierry Crozat]]<br />
<br />
The original Mortville Manor game was using a speech synthesis based on PC Speaker. <br />
<br />
The purpose of this task is to replace obsolete speech synthesis by an external dependency which will allow to implement a <br />
decent text to speech generation, in (at least) French, German and English.<br />
<br />
=== Adding speech synthesis of on-screen text for people with reduced sight or for learning to read ===<br />
Technical contacts: Our IRC channel, our mailing list, or contact [[User:Strangerke|Arnaud Boutonné]] or [[User:criezy|Thierry Crozat]]<br />
<br />
Using the same library used in the previous task, add a similar text to speech generation for other games. The exact list of titles should be defined as soon as possible between the mentors and the student.<br />
<br />
This task would allow people suffering of sight issues to play more games in ScummVM, but it could also be very useful to help people to learn how to read.<br />
<br />
=== Macromedia Director ===<br />
Technical contacts: Our IRC channel, our mailing list, or contact [[User:Fuzzie|Alyssa Milburn]], [[User:Clone2727|Matthew Hoops]]<br />
<br />
Many 90s-era adventure games were developed using the Macromedia (now Adobe) Director tool. They don't run any more on modern systems, and current versions of Director can't even open the files (and too much has changed; Macromedia themselves have said that "reauthoring the movie from scratch" is often more efficient). It would be nice to be able to play these games in ScummVM!<br />
<br />
There is already (Python) code available which can parse and display the contents of Director 2 and Director 3 'movie' files, and the basic framework of a ScummVM C++ engine. The task would involve trying to implement enough of a ScummVM engine to allow some early Director adventures to be played; for example, parsing the movie files, implementing the frame-based playback system, drawing bitmaps and shapes, playing sounds and running some basic (Lingo) scripting.<br />
<br />
=== AGS ===<br />
Technical contacts: Our IRC channel, our mailing list, or contact [[User:Fuzzie|Alyssa Milburn]]<br />
<br />
The Adventure Game Studio engine has been open sourced. It would be nice to have it available (at least for legacy games) as part of ScummVM, so it can benefit from our platform support.<br />
<br />
There's an existing unfinished partially-rewritten(!) engine for ScummVM (see [[AGS]]) which is missing some core functionality (such as save/load code) but already allows you to complete some AGS games. Adding save/load functionality (not trivial) and implementing some of the other missing code would get it to a point where it could be merged into the main codebase.<br />
<br />
'''This task almost certainly needs experience in understanding/refactoring of complex existing codebases, so please contact us as soon as possible if you're interested.'''<br />
<br />
=== Port WebVenture engine ===<br />
Technical contacts: [[User:DJWillis|John Willis]], [[User:Md5|Filippos Karapetis]].<br />
<br />
The [http://seancode.com/webventure/ WebVenture] [https://github.com/mrkite/webventure engine] by Sean Kasun is a reimplementation of the [https://en.wikipedia.org/wiki/MacVenture MacVenture] engine from ICOM Simulations. <br />
<br />
It was used in the late 80s and in the early 90s for 4 games. The MacVenture games are still available for purchase from [http://www.zojoi.com/ Zojoi].<br />
<br />
The current code is written in JavaScript, which means it will have to be completely rewritten in C++ and integrated in ScummVM.<br />
<br />
'''This task requires C++ and JavaScript knowledge.'''<br />
<br />
=== Native OS X port ===<br />
Technical contacts: [[User:somaen|Einar Johan Trøan Sømåen]], [[User:aquadran|Paweł Kołodziejski]].<br />
<br />
ScummVM's current OS X port is SDL 1.2 based, which is a dead project, having been replaced by SDL2, and Apple has a tendency to change and deprecate functionality with each version of their OS, as such, the current state of the OS X port seems to degrade with each new OS X release. Functionality added in newer releases of OS X, such as the new Full-screen modes introduced in 10.7 are also not available for use in ScummVM with the current SDL1.2 port.<br />
<br />
One option for solving this, is to create a backend for OS X that doesn't use SDL. This would mean writing replacement code for the parts where SDL currently handles things (i.e. atleast audio/video/input, but possible other details). A major aim of such a project would be to retain backwards compatibility with 10.2 as we have today, while allowing for a good user experience on the very latest OS X versions as well.<br />
<br />
'''This task requires C++ and Objective-C/Cocoa knowledge.'''<br />
<br />
=== Improving the iPhone/iOS port ===<br />
<br />
Technical contact: [[User:LordHoto|Johannes Schickel]], [[User:Sev|Eugene Sandulenko]].<br />
<br />
The current iOS port, which we still label as iPhone, is functional but feels not really polished in a number of ways. The port comes from a time when the first two generations of the iPhone were still the top models. This, for example, makes it not as nicely usable on modern iOS devices because of resolution issues. Furthermore, while the gesture input serves as a great way to, for example, change control schemes, it also has some annoying issues. The most prominent example is that the "open global main menu" gesture sometimes causes the main menu to immediately close.<br />
<br />
Build wise the iOS port is currently only supported by using a custom toolchain. Supporting the official toolchain and XCode as development environment in '''addition''' to the current toolchain is something we would really like to see. We already have a tool to auto-generate project files for Microsoft Visual Studio. The idea would be to take the currently WIP XCode support and finish it. Building with the official toolchain on command line would also be nice to have.<br />
<br />
Essentially, this task requires working on various aspects of the iOS port. This includes graphics, GUI, input handling, but also build related aspects. Ideally, we want our iOS port to feel much smoother for the users, but also for developers working on it.<br />
<br />
'''This task requires C++, ObjC(++), and iOS development knowledge. It also requires access to a (jailbroken) iOS device, preferable both iPhone and iPad, and the official iOS development environment.'''<br />
<br />
=== Sources for other ideas ===<br />
<br />
Technical contacts: Our IRC channel, our mailing list, or contact [[User:Sev|Eugene Sandulenko]], [[User:DJWillis|John Willis]], [[User:Strangerke|Arnaud Boutonné]], [[User:LordHoto|Johannes Schickel]]<br />
<br />
One good place to start if you're looking for new ideas would be our [[TODO]] page (and the other TODO lists linked from there).<br />
Some other ideas (most of which might be incomplete or outdated, or too difficult for a new developer) can be found on our [[OpenTasks]] page. Again, be sure to talk to us before thinking too much about any idea on these lists, as many things are likely to be outdated or simply wrong.<br />
<br />
=== New game engines ===<br />
<br />
Technical contacts: Our IRC channel, our mailing list, or contact [[User:Sev|Eugene Sandulenko]], [[User:DJWillis|John Willis]], [[User:Strangerke|Arnaud Boutonné]], [[User:Md5|Filippos Karapetis]],<br />
<br />
If you already have reverse engineering experience, you could consider working on one of the external in-development game engines, or even on support for a new game. However, doing this kind of work is very difficult and time-consuming - you would have to convince us that you have the necessary skills to actually be sufficiently productive, probably by demonstrating some actual progress first.<br />
<br />
== ResidualVM Projects ==<br />
This section contains project ideas for ResidualVM. You will need some basic knowledge of OpenGL and 3D math, in addition to any extra skills indicated in each entry.<br />
<br />
=== Wintermute 3D ===<br />
Technical contacts: [[User:somaen|Einar Johan Trøan Sømåen]], [[User:aquadran|Paweł Kołodziejski]]<br />
<br />
In 2012, the Wintermute engine was ported into ScummVM. However, as this was a port of the 2D-only Lite-version of WME, and since ScummVM is designed to run only 2D games, the ScummVM port has no support for the 3D parts of the engine, and is thus not able to run any of the games that use them.<br />
<br />
See [http://wiki.residualvm.org/index.php/GSoC_Ideas#Wintermute_3D_port Wintermute 3D] for more details.<br />
<br />
=== In Cold Blood engine refactor ===<br />
Technical contacts: [[User:somaen|Einar Johan Trøan Sømåen]], [[User:aquadran|Paweł Kołodziejski]], [[User:joostp|Joost Peters]]<br />
<br />
See [http://wiki.residualvm.org/index.php/GSoC_Ideas#In_Cold_Blood_engine_refactor ICB engine refactor] for more details<br />
<br />
=== iOS port ===<br />
Technical contacts: [[User:aquadran|Paweł Kołodziejski]], [[User:somaen|Einar Johan Trøan Sømåen]]<br />
<br />
Currently ResidualVM has an in progress Android port, but it lacks an iOS port. This task is about to make it for iPhones and iPads.<br />
<br />
See [http://wiki.residualvm.org/index.php/GSoC_Ideas#iOS_port_of_ResidualVM iOS Port] for more details<br />
<br />
=== Sources for other ideas ===<br />
<br />
Technical contacts: ResidualVM IRC channel (#residualvm on freenode.net), or contact [[User:aquadran|Paweł Kołodziejski]], [[User:somaen|Einar Johan Trøan Sømåen]]<br />
<br />
=== New game engines ===<br />
<br />
Technical contacts: ResidualVM IRC channel (#residualvm on freenode.net), or contact [[User:aquadran|Paweł Kołodziejski]], [[User:somaen|Einar Johan Trøan Sømåen]]<br />
<br />
If you already have reverse engineering experience, you could consider working on one of the external in-development game engines, or even on support for a new game. However, doing this kind of work is very difficult and time-consuming - you would have to convince us that you have the necessary skills to actually be sufficiently productive, probably by demonstrating some actual progress first.<br />
--></div>
BgK
https://wiki.scummvm.org/index.php?title=Buildbot&diff=24539
Buildbot
2018-07-29T07:08:53Z
<p>BgK: The buildbot services are now managed using systemd</p>
<hr />
<div>{{Infobox Project Service Information|<br />
url=http://buildbot.scummvm.org|<br />
purpose=Provides automated build services for an increasing number of our supported platforms.|<br />
maintainer=Andre Heider ([[User:Dhewg|Dhewg]])<br>John Willis ([[User:DJWillis|DJWillis]])<br />
}}<br />
<br />
== Introduction ==<br />
<br />
From the [http://buildbot.net/ buildbot homepage]:<br />
<br />
:The BuildBot is a system to automate the compile/test cycle required by most software projects to validate code changes. By automatically rebuilding and testing the tree each time something has changed, build problems are pinpointed quickly, before other developers are inconvenienced by the failure. The guilty developer can be identified and harassed without human intervention. By running the builds on a variety of platforms, developers who do not have the facilities to test their changes everywhere before checkin will at least know shortly afterwards whether they have broken the build or not. Warning counts, lint checks, image size, compile time, and other build parameters can be tracked over time, are more visible, and are therefore easier to improve.<br />
<br />
:The overall goal is to reduce tree breakage and provide a platform to run tests or code-quality checks that are too annoying or pedantic for any human to waste their time with. Developers get immediate (and potentially public) feedback about their changes, encouraging them to be more careful about testing before checkin.<br />
<br />
You can find the ScummVM buildbot page [http://buildbot.scummvm.org/ here].<br />
<br />
== Goals ==<br />
<br />
* Compile all ports when a commit is done (both trunk and the active branch) to check if it broke one or more ports.<br />
* Notify developers about breakage (and if a following commit fixes it again).<br />
* Provide useful statistics.<br />
* Provide nightly builds of all ports.<br />
<br />
== Status ==<br />
<br />
What we have so far:<br />
* The bot already polls the [[Git|Git Server]] for changes on trunk and the current branch.<br />
* When a change occurs, all ports are being built incrementally.<br />
* Once every 24h (currently 4am CET), a full and clean rebuild is compiled for all ports.<br />
* Provide the [http://buildbot.scummvm.org/builds.html nightly builds via HTTP].<br />
* Notify developers upon problems through an IRC bot in [[IRC Channel]].<br />
<br />
What's missing:<br />
* Add more toolchains for all missing ports - when possible (see below).<br />
* Notify developers upon problems via mail.<br />
<br />
== Toolchains ==<br />
<br />
A few requirements must be met to add a toolchain to the buildbot server:<br />
* It must be possible to cross-compile the port from Linux (that might change in the future).<br />
* No custom Makefiles from the ''backend/'' folder, the port has to use the ''./configure'' script.<br />
* The compile process must neither modify nor add anything in the source tree. All builds are performed in external build directories, by invoking the ''./configure'' script in these external directories.<br />
* The port must be fully buildable from scratch with only ''./configure'' arguments and environment variables for it.<br />
<br />
The toolchain should be primarily maintained by the port maintainer, but since this requires a little Linux experience, its not a must ;). We will provide assistance with this where possible.<br />
<br />
If your toolchain/port is ready to be added, ask ''sev'', ''joostp'' or ''dhewg'' for an account.<br />
<br />
== Administration ==<br />
<br />
When the buildbot config files are changed, a user with shell access and sudo privileges needs to run the following commands. It's good practice to do this once buildbot is idle:<br />
<br />
<source lang="bash"><br />
sudo -s<br />
systemctl stop buildslave<br />
systemctl stop buildmaster<br />
cd ~buildbot/scummvm-sites<br />
sudo -u buildbot git pull --ff-only<br />
systemctl start buildmaster<br />
systemctl start buildslave<br />
</source><br />
<br />
If problems arise, check if all files in the master (~buildbot/scummvm-master) and slave (~buildbot/scummvm-slave) directories are owned by the correct user (buildbot:buildbot). If the daemons were incorrectly started, new files might have been created under another user account. In that case:<br />
<br />
* stop the daemons (see above)<br />
* fix the permissions with<br />
<source lang="bash"><br />
chown -R buildbot:buildbot ~buildbot/scummvm-master/*<br />
chown -R buildbot:buildbot ~buildbot/scummvm-slave/*<br />
</source><br />
* start the daemons<br />
<br />
=== Rebuilding Toolchain Libraries ===<br />
<br />
It is periodically necessary to update the toolchain libraries for<br />
newer version releases or to add new library dependencies.<br />
This is a basic outline procedure for how to build these on the<br />
buildbot.<br />
<br />
* Toolchains are located at /opt/toolchains/<host target> in general, with the following exceptions:<br />
** Though some of the MinGW 32 toolchain is present in<br />
/opt/toolchains/i586-mingw32msvc<br />
which should be used as the host/prefix in the following<br />
instructions, the binaries i.e. i586-mingw32msvc-gcc are located<br />
at /usr/bin. This is probably as they are precompiled to be<br />
installed at this location, so this is necessary.<br />
<br />
However, if the PATH step to the bin is omitted in the following,<br />
this will still work for this target, which is confusing and could<br />
result in odd builds as some of toolchain bin contents may be needed.<br />
<br />
* All source tarballs used and any patches should be left in /opt/toolchains for reference.<br />
<br />
* /opt/toolchains is actually a symlink to the real location of the external storage drive, but /opt/toolchains should be used in all configuration to ensure that this can be freely moved in future if necessary.<br />
<br />
libSDL:<br />
<br />
* Decompress the latest libSDL tarball to a temporary location i.e.<br />
<br />
<source lang="bash"><br />
tar -xvzf SDL-1.2.15.tar.gz -d /home/digitall<br />
</source><br />
<br />
* Apply any required patches i.e. Currently libSDL-1.2.15 snapshot has a error in the Win32 version strings.. This may occur again on future releases :/<br />
<br />
<source lang="bash"><br />
patch -p0 < SDL-1.2.15-Fix-Windows-DLL-Version.patch<br />
</source><br />
<br />
* Add toolchain binaries directory to path.<br />
<br />
<source lang="bash"><br />
PATH=/opt/toolchains/x86_64-w64-mingw32/bin:$PATH<br />
export PATH<br />
</source><br />
<br />
* Add out of tree build directory and configure the SDL codebase here with the host target and prefix to use the correct cross toolchain and target for make install.<br />
<br />
<source lang="bash"><br />
mkdir SDL-1.2.15-x86_64-w64-mingw32<br />
cd SDL-1.2.15-x86_64-w64-mingw32<br />
../SDL-1.2.15/configure --host=x86_64-w64-mingw32 --prefix=/opt/toolchains/x86_64-w64-mingw32<br />
</source><br />
<br />
* Compile the codebase.<br />
<br />
<source lang="bash"><br />
make<br />
</source><br />
<br />
* Install the compiled files. As you become root, you need to make the same modification to the path to get the required cross toolchain tools such as ranlib.<br />
<br />
<source lang="bash"><br />
sudo bash<br />
PATH=/opt/toolchains/x86_64-w64-mingw32/bin:$PATH<br />
export PATH<br />
make install<br />
</source></div>
BgK
https://wiki.scummvm.org/index.php?title=TODO&diff=24388
TODO
2018-03-13T17:02:43Z
<p>BgK: Remove iterator handling from the todo list. It is too much of a pitfall for GSoC students.</p>
<hr />
<div>{{Infobox_TODO|<br />
taskname=Main TODO List|<br />
techcontact=The ScummVM Team|<br />
subsystem=Generic|<br />
}}<br />
<br />
Here is a list of things we consider doing in the future. Note that we don't promise to do any of these, nor when we will do them. It's just a list of what we hope to be able to do one day, and some items on the list really are more like ideas than real proposals, so take it with a grain of salt.<br />
<br />
If you want to dig in, this is the stuff where you might make the most useful contribution. Note that this list is never complete, and may be partially outdated, so just because you don't see something here doesn't mean it is not important.<br />
<br />
Before you start work on something, you should first talk to the team! Ideally ask on scummvm-devel, our mailing list. This will help us to prevent double work, i.e. several people working on the same stuff at once without knowing about each other. Furthermore, sometimes entries on our list are actually obsolete (because the feature has been implemented, or because for some reason we no longer think it to be desirable). Special caution should be taken for TODO entries that say "we may want to" or similar things; that usually means that we aren't sure whether we really want to implement that feature.<br />
<br />
'''So, to repeat it: Always talk to the team before implementing a change on this list, or else risk having your patch rejected :-/.'''<br />
<br />
Finally, always make sure to check out our bug tracker and our feature request tracker for things that need work.<br />
<br />
<br />
== Documentation ==<br />
<br />
See also the [[Documentation/TODO]] page.<br />
<br />
=== General ===<br />
* Add port specific user documentation (dreamcast/palm especially). That would include things like:<br />
** How to use ScummVM on system XYZ<br />
* Update/enhance man page<br />
* Write a high level overview of how ScummVM and its engines work?<br />
<br />
=== README / Manual ===<br />
* A proper manual might be nice.<br />
* Maybe move all/most of the compression related stuff from our README completely to the tools README, and only leave a pointer to that in the main README. This would be beneficial because this way, it's only documented in one place; it's *completly* documented (currently, the main README doesn't mention compress_scumm_bun, for example); and people who want to use the compression tools need to download the tools package anyway.<br />
* It would be greate to have a "Developer's Guide to ScummVM" which explains the ScummVM framework, and also the engines, i.e.<br />
** stuff in common/, like the config manager etc.<br />
** the backend API, and how to create new backends<br />
** the sound system<br />
** how to create a new engine<br />
** a chapter for each engine, with as many/little details as the resp. engine teams deem appropriate...<br />
** ...<br />
<br />
== Web sites ==<br />
<br />
=== Primary website ===<br />
* Add big (green?) shiny buttons in the middle of the page for (1) Donations and (2) Downloads ?<br />
* Show "Release Date" on download page<br />
* Change all screenshot filenames to match our rules as described [[Screenshots|here]]. E.g. rename <code>data/screenshots/agos/simon/scummvm_2_4_0.jpg</code> to <code>data/screenshots/agos/simon/simon-0.jpg</code> etc.; also some stuff should maybe be moved to other directories.<br />
<br />
=== [[Buildbot]] ===<br />
* Track the size of the resulting binaries.<br />
** This would greatly help in tracking down when and why the size of the ScummVM binary increased.<br />
** Doing this should not be hard. Setup a database which stores for each commit the size of the (stripped) binary of each port. <br />
** Then, add a way to query that database via a webfront. At first, simply dumping all the numbers would be good enough. On the long run, it would be nice to show some cool graphical diagrams.<br />
** For bonus points, allow the user of that webpage to dynamically change it using javascript: i.e. selecting which ports to show, which range of revisions; mousing over a data point shows a little box with details on the commit; clicking on a revision number jumps to the corresponding page in our SVN repository viewer; etc. ;).<br />
* Install the new required dependencies (libpng and libtheora for [[Sword25]]) into the cross compiler environments of all ports that have a chance of supporting [[Sword25]].<br />
* Install the new required dependencies (libpng, libfreetype, boost and wx-widgets) into the cross compiler environments of all desktop ports to support building of tools.<br />
<br />
=== [[Doxygen]] ===<br />
* <s>Create a visual theme which matches that of our forum and website</s><br />
<br />
=== [[Forums]] ===<br />
* Upgrade to phpBB 3. This receives security updated, and would provide many new handy features for users and admins alike. The main issue here is that somebody would have to rewrite our custom theme for that. Maybe we can hire somebody to do this?<br />
<br />
=== [[Planet]] ===<br />
* Improve the visual theme to better match that of the forum and website<br />
<br />
=== [[Wiki]] ===<br />
* <s>Create a visual theme which matches that of our forum and website</s><br />
* Add content to [[Special:Wantedpages|Wanted Pages]]<br />
* Add some content to [[Help:Editing]], which is shown when editing a page<br />
<br />
== Common code, infrastructure ==<br />
<br />
=== General ===<br />
* Revise the way "quit" is handled. Maybe add a global variable "g_quit" which we set when the application should be quit (e.g. when an EVENT_QUIT is received). This is useful if multiple levels of event loops have to be ended<br />
* Make some generic "EventLoop" API/class which all backends and the GUI use. Initially this would just call the backend poll_event() etc. methods. But eventually the EventLoop object(s) could be made by the backend. This may allow for more efficient CPU usage etc. The current event handling model essentially is polling: the engines run some kind of main loop, which, besides many other things, also polls and dispatches events. The idea is to turn this around: the event loop frequently gives the engine time to do these "other things".<br />
* Maybe add ways to modify the game configs via the command line. E.g. allow<br />
./scummvm --add new_target --path=/foo monkey2<br />
./scummvm --remove new_target<br />
* The following things should be put into namespaces:<br />
** MIDI related classes either to Audio, or a new "MIDI" namespace<br />
** backend specific stuff into ??? (maybe new namespace "Backends" ?) not sure about this one.<br />
* Get rid of getenv in as many places as possible. Ideally, we'd only use it to query HOME on Unix systems.<br />
<br />
=== Events ===<br />
<br />
==== Event struct ====<br />
The following is a (revision of) a former comment in <code>common/events.h</code>:<br />
<br />
Rework/document this structure. It should be made 100% clear which field<br />
is valid for which event type. Implementation wise, we might want to use<br />
the classic union-of-structs trick. It goes roughly like this:<br />
<source lang="cpp"><br />
struct BasicEvent {<br />
EventType type;<br />
};<br />
struct MouseMovedEvent : BasicEvent {<br />
Common::Point pos;<br />
};<br />
struct MouseButtonEvent : MouseMovedEvent {<br />
int button;<br />
};<br />
struct KeyEvent : BasicEvent {<br />
...<br />
};<br />
...<br />
union Event {<br />
EventType type;<br />
MouseMovedEvent mouse;<br />
MouseButtonEvent button;<br />
KeyEvent key;<br />
...<br />
};<br />
</source><br />
<br />
However, this approach is contrary to classic OO paradigms. Indeed, its<br />
major drawback is that all event types now must be POD data types, so<br />
e.g. they can't contain a Common::Point as member. Bad.<br />
<br />
An alternative approach would be a more OO like switch to multiple Event<br />
subclasses. This would, however, then require us to pass events around<br />
as pointers to object instances, and also would require introducing type<br />
casting in code using events. The passing around of pointers could be<br />
mitigated by using<br />
<source lang="cpp"><br />
typedef Common::SharedPtr<BasicEvent> Event<br />
</source><br />
or something like that. Yet this would mean increased overhead in all<br />
our code, yet the gain is unclear. In conclusion, we probably are best<br />
off by staying with the existing monolithic struct Event, we should just<br />
enhance its documentation.<br />
<br />
=== Build System ===<br />
* Add test(s) for backend usability in the configure script.<br />
* Add an install target to the Makefile - Copy binary, install manpage, add menu items, install README. See also patch #891909 (Gnome/KDE .desktop file)<br />
* Investigate whether switching to [http://www.cmake.org CMake] or [http://www.scons.org SCons] or some other cross platform configuration environment would work for us. Potential advantage: Less effort to maintain and extend the build system, automatic generation of various kinds of project files (Makefiles, and project files for MSVC, XCode, Eclipse, KDevelop ...). Potential drawback: Problems with the customized build systems of our various ports. However, the latter might actually be improved by using CMake or SCons -- hard to say without tests.<br />
<br />
=== Audio ===<br />
<br />
==== Mixer ====<br />
* Get the high quality resample code to work<br />
* Consider changing the mixer volume to use range 0-255, for sake of consistency (but at a slight loss of efficiency). Note that this requires changes in at least rate.cpp and mixer.cpp.<br />
* Some of our engines support the speech_mute / sfx_mute / music_mute options, but most don't. Almost all support the corresponding FOO_volume config keys. All engines use Mixer::setVolumeForSoundType to push those through to the mixer. I am wondering: Maybe it would make sense to remove Mixer::setVolumeForSoundType, and instead leave it up to the mixer to query the ConfigManager for the corresponding FOO_volume/_mute values? That way we'd ensure 100% identical behavior in all engines and actually simplify the code a bit... ? Not sure if this would work smoothly, it needs to be investigated.<br />
* the "isReady" code is irritating. Most engines ignore it anyway. It's primary purpose is to allow ScummVM to run even if not digitial audio out is available. A better solution would likely be to enforce that all backends always return a valid mixer. In the worst case, if a backend cannot produce audio output, it should still instantiate an Audio::MixerImpl, with some arbitrary sample rate (I recommend 22050 Hz), and a fake playback thread, which acts like an audio output callback but simply discards the generated audio data. (Note: It doesn't suffice to just throw away input data in Mixer::playInputStream, as this breaks with QueuingAudioStream).<br />
* document the semantics of sound handles and sound ids<br />
* Are there backends which could benefit from a 'custom' mixer? If so, what would be required to implement such a thing? Needs talking to porters<br />
<br />
==== CD ====<br />
* Consider extending the Audio CD Manager with WAV or VOC support (essentially, the WAV/VOC code would need to be enhanced by adding a factory function similar to that provided for the FLAC/Vorbis/MP3 streams).<br />
* add a "pause" feature to the AudioCDManager (might require us to extend the OSystem CD API, too). Useful to be able to fully pause the currently running engine<br />
<br />
==== MIDI ====<br />
* See also [[Music drivers redesign]]<br />
* MIDI: Add API to OSystem which allows client code to query for "native" MIDI drivers (like Windows, ALSA, Zodiac, CoreAudio). Then change the MIDI interfacing code (GUI, command line, config file, etc.) and also MidiDriver::createMidi() to use both that list and the list of 'emulated' MIDI devices (AdLib, MT-32, PC Speaker, etc.) in an appropriate way.<br />
* Make it possible to pass options to the midi/music drivers. This would allow us to get rid of the getenv hacks in the alsa & seq drivers.<br />
**A simple approach would be to allow the user to specify "extended" driver descriptions. E.g. "alsa:1234" could indicate the alsa driver with port 1234; alternatively, "alsa:port=1234".<br />
**This doesn't allow for easy tweaking of those settings via the GUI.... to achieve that, one approach would be to invent a 'parameter description language' which allows a driver to specify which options with which kind of values it supports... very flexible, but possibly overkill.<br />
**Instead, one could add a hook method to MIDI drivers that let's them add a few controls of their own to the options dialog. This is probably a lot easier to implement, though not quite as "clean"...<br />
* Our XMIDI parser seems to have a couple of missing features, but it's unclear which ones are actually needed. Possible references for a better implementation include the [http://exult.sf.net Exult] project and the [http://www.thegleam.com/ke5fx/ source code for AIL Version 2]. The KYRA engine contains some more complete XMIDI implementation on top of our XMIDI parser class too, so it might also be a place to look at for reference.<br />
<br />
=== Config Manager ===<br />
* Modify the ConfigManager to make use of the ConfigFile class. This is more difficult than it sounds at first, because currently our ConfigManager is not just used for managing the active config, but also ab-used for editing config data (once for specific targets, in the launcher's "edit game" dialog, and once for editing the "active config" in the engines/dialog.cpp ConfigDialog). This mess needs to be untangled first.<br />
* Maybe even follow the pentagram (http://pentagram.sf.net) approach and have three classes:<br />
** SettingsManager (like our current ConfigManager)<br />
** ConfigFileManager (manages a set of config files, possibly merging the data from multiple config files)<br />
** ConfigFile (a simple .ini file accessor).<br />
*: This makes it easy to add additional config sources (e.g. XMLConfigFile); makes it possible to treat the command line data like another config file (CommandLineConfig); and simply follows the good old MVC approach, which is always a good idea.<br />
* Add a proper version to the Config file, which indicates true changes in the format / data in it. Right now, we only have a "fake" version number where any ScummVM instance will just write its version in. Which is totally useless. A proper version would allow us to ...<br />
** ... produce a warning if an older ScummVM version tries to load a config file written by a newer version with potentially incompatible changes (such as the switch from language code "hb" to "he" for Hebrew)<br />
** ... detect when we an old config file is loaded which needs to be updated (e.g. by changing language "hb" to "he"; by adding "guioptions" to targets; by fixing trailing slashes in "path"; maybe even updating old style; and maybe in the future by adding "engineid" fields to all targets)<br />
<br />
=== Files ===<br />
* Don't rely on the existence of SEEK_CUR, SEEK_END, SEEK_SET -- rather, define our own enum for this and convert all client code to use it.<br />
* Try to replace all usages of paths by FilesystemNode.<br />
<br />
=== GUI ===<br />
* [[GUI Themes/TODO|GUI TODO]]<br />
<br />
=== Plugins ===<br />
* On OSX: Support a plugin build in the bundle target: *.plugin files should be put into ScummVM.app/Contents/PlugIns/; this also means that the loader needs to search in the plugin dir of the active bundle. So use the CF bundle API, inside a #ifdef MACOSX block.<br />
* Make DetectedGame::updateDesc a normal function, not a member function.<br />
<br />
=== Launcher ===<br />
* Enhance the Mass detector to show a list with the results (and optionally, allow the user to edit/cull that list before adding it).<br />
* Game edit dialog: Consider adding some warnings to the platform/language fields ("Don't mess with these unless you know what you are doing"), or move them to an "advanced" tab<br />
* Make the gameid editable via an "advanced" tab entry?<br />
* <s>There is no way to reset the save/extra/theme paths. Adding a tiny button labeled "c" for clearing them (like for the soundfont path button) is not the way to solve this, I think. One approach would be to extend the Browser dialog, to allow an (optional) extra button, with customizable label. When pressed, the browser dialog closes and returns a special code. Well, and we'd use labels like "Use default savepath" or "Reset extrapath", or just always "Use default value".</s><br />
* The global options dialog may show a button for configuring the savepath even on systems where it is fixed -> not good. This button should be hidden/removed for these systems<br />
* separate launcher code even more from rest of ScummVM, to make custom launchers easier?<br />
** maybe separate launcher using MVC approach? Separate code which scans for games etc. from the presentation layer, to make it easier to write custom launchers with behavior matching that of the default launcher?<br />
* show cover art in launcher<br />
** this would only be done on "high end" systems, must be possible to disable code<br />
** we can't ship artwork directly, due to copyright concerns; so only ship artwork where it is legally possible, and otherwise allow users to setup "artwork packs"<br />
** control what artwork is shown using a config key<br />
<br />
=== Global Main Menu/Return to Launcher ===<br />
* Confirm exit dialog woes:<br />
** Double "confirm exit" dialog: When confirm exit is enabled in ScummVM, the ScummVM quit confirm dialog shows up in addition to the quit confirm dialogs for those games which have their own. For example, when you select 'Quit' from Beneath a Steel Sky's in-game menu, it asks you if you really want to quit. Then, after answering, ScummVM gives you another dialog asking you if you really want to quit. So, ScummVM should not show the quit confirm dialog if the in-game dialog has already been displayed. This affects any game which has it's own menu system from where you can quit, or has a native quit confirm dialog. So this means most games.<br />
** Add/unify "confirm exit" dialog, globally (see [https://sourceforge.net/tracker/index.php?func=detail&aid=1731025&group_id=37116&atid=418823 FR #1731025])<br />
* Options Dialog: Implement engine flags to define which features in the Options dialog are supported by the current running game. Use these flags to hide/show the appropriate sliders and buttons in the Options Dialog<br />
* Allow engines to extend the GMM more freely. E.g. for the SCUMM engine, we would want to add a "Help" button. Alternatively, just always have a help button and only show/hide resp. en-/disable it as needed.<br />
* Improve the look of the GMM: This could include displaying the engine name and the ScummVM logo somewhere on the GMM.<br />
* Config Dialog code: Resolve the FIXME in engines/dialogs.cpp which pertains to having to use the empty string as the domain name. This is a bigger task, but will enable many other changes (thus as finally changing ConfigManager to use ConfigFile). Essentially, the current game config dialog tries to abuse the system by editing the *active* settings via the config manager, in order to fully reduce the options dialog code from the launcher. But there is a big difference between editing the config settings of a specific target, and the active settings. So, one probably needs to rewrite the code for the config dialog shown from the GMM<br />
* Make it possible to reach the "key remapper" and "virtual keyboard" from the GMM, if available?<br />
* Sugar on the cake: In addition to the ScummVM logo and version, how about showing the engine name and game title at the top of the GMM?<br />
<br />
=== Error handling ===<br />
<br />
Sometimes, bugs are reported that are not easily reproducible, e.g. [https://sourceforge.net/p/scummvm/bugs/6751/ Bug #6751]. In such cases, it would be useful to have the error handler in ScummVM generate (and, optionally, automatically send) minidumps that can be used by us to successfully examine crashed ScummVM processes. Integration of something like [https://chromium.googlesource.com/breakpad/breakpad/ Google Breakpad] is one reasonable option. While it is not likely to be able to get such crash handling into all ports, just supporting the most popular platforms would be enough to make this feature very useful.<br />
<br />
== Engines / frontends ==<br />
<br />
=== [[SCUMM]] ===<br />
* see [[SCUMM/TODO|SCUMM TODO]] list<br />
<br />
=== [[AGI]] ===<br />
* see [[AGI/TODO|AGI TODO]] list<br />
<br />
=== [[AGOS]] ===<br />
* see [[AGOS/Bugs|AGOS Bugs]] list<br />
* see [[AGOS/TODO|AGOS TODO]] list<br />
<br />
=== [[Cine]] ===<br />
* see [[Cine/TODO|Cine TODO]] list<br />
<br />
=== [[CruisE]] ===<br />
* see [[Cruise/TODO|CruisE TODO]] list<br />
<br />
=== [[Drascula]] ===<br />
* see [[Drascula/TODO|Drascula TODO]] list<br />
<br />
=== [[Gob]] ===<br />
* see [[Gob/TODO|Gob TODO]] list<br />
<br />
=== [[Groovie]] ===<br />
* see [[Groovie/TODO|Groovie TODO]] list<br />
<br />
=== [[Hopkins]] ===<br />
* see [[Hopkins/TODO|Hopkins TODO]] list<br />
<br />
=== [[Hugo]] ===<br />
* see [[Hugo/TODO|Hugo TODO]] list<br />
<br />
=== [[Kyra]] ===<br />
* see [[Kyra/TODO|Kyra TODO]] list<br />
<br />
=== [[Lastexpress]] ===<br />
* see [[Lastexpress/TODO|Lastexpress TODO]] list<br />
<br />
=== [[MADE]] ===<br />
* see [[MADE/TODO|MADE TODO]] list<br />
<br />
=== [[Mohawk]] ===<br />
* see [[Mohawk/TODO|Mohawk TODO]] list<br />
<br />
=== [[Parallaction]] ===<br />
* see [[Parallaction/TODO|Parallaction TODO]] list<br />
<br />
=== [[SAGA]] ===<br />
* see [[SAGA/TODO|SAGA TODO]] list<br />
<br />
=== [[SCI]] ===<br />
* see [[SCI/TODO|SCI TODO]] list<br />
<br />
=== [[Sword1|Broken Sword 1]] ===<br />
* Modify MoviePlayer class to use ManagedArray for _movieTexts.<br />
* Add support for Bink RDFT compressed audio in the Smacker videos (used in some later releases).<br />
<br />
=== [[Sword2|Broken Sword 2]] ===<br />
* Fix the credits so they look more like the original. (Did we ever get the source code for that?)<br />
* Maybe work around script bug which causes the mop to disappear briefly when trying to pick it up from the top of the boat at the London docks. (The event to hide the mop is sent too early.) {{Tracker|id=2058}}.<br />
* Maybe (but probably not) work around a graphics glitch where George can be drawn partially in front of a metal beam he's walking behind. (He's obscured properly by the beam sprite, but part of the beam is only background.) {{Tracker|id=4483}}.<br />
* Unify some of the code with Broken Sword 1 (e.g. in router.cpp).<br />
<br />
=== [[Sword25]] ===<br />
* see [[Sword25/TODO|Sword25 TODO]] list<br />
<br />
=== [[Tinsel]] ===<br />
* see [[Tinsel/TODO|Tinsel TODO]] list<br />
<br />
=== [[Tony]] ===<br />
* see [[Tony/TODO|Tony TODO]] list<br />
<br />
=== [[Toon]] ===<br />
* see [[Toon/TODO|Tooon TODO]] list<br />
<br />
=== [[Touche]] ===<br />
* see [[Touche/TODO|Touche TODO]] list<br />
<br />
=== [[TsAGE]] ===<br />
* see [[TsAGE/TODO|TsAGE TODO]] list<br />
<br />
=== [[Tucker]] ===<br />
* see [[Tucker/TODO|Tucker TODO]] list<br />
<br />
=== [[Wintermute]] ===<br />
* see [[Wintermute/TODO|Wintermute TODO]] list<br />
<br />
== Backends and ports ==<br />
<br />
=== General ===<br />
* Add API to query backend for a list of available music engines. Useful for Options dialog. See [[Music drivers redesign]].<br />
* Right now gBitFormat is part of common/scaler.cpp; we might want to move it to common/system.cpp, or replace it with something better. No hasty changes here, please, make sure you understand how it is used right now before messing with it ;-)<br />
<br />
=== SDL backend ===<br />
* Right now, the WinCE and the Symbian backend subclasses the regular SDL backend. They both overload a lot of methods (mostly the graphics stuff). Since graphics.cpp uses the scalers (e.g. hq3x), these derived backends carry that baggage around, too, even though they don't need that code. Idea: split the SDL backend into two classes, one base class which only has the code which is used by all subclasses; and a "desktop" subclass, which implements the rest. Then WinCE/Symbian would only subclass the "base" SDL class.<br />
<br />
=== Windows ===<br />
* Add scripting code for creating a Windows installer to our code repository, so that a full Windows release can be built easily and directly. Could be based on [http://nsis.sourceforge.net NSIS] or [http://wix.sourceforge.net WiX].<br />
<br />
== Tools ==<br />
<br />
=== General ===<br />
* Use doxygen (or something else) to turn the short descs from the README into short man pages AND a single text file (replacing README) and a HTML file...<br />
<br />
=== GUI ===<br />
* One of the GUI assistants pages shows the following text to the user: "Note: Some tools display file picker here, this should perhaps be changed to always be directory output, since often don't want to name the output file." Clearly this should *not* be shown to the user, but rather is something we devs need to address.<br />
* The last page of the assistant is weird. E.g. after successful run, it shows a "Finish" button in the lower right, and two checkboxes: "Open output folder" and "Process another file". This seems unintuitive and artificial to me. An IMHO better alternative would be to remove the "Finish" button, and instead show some big buttons with captions like "Process another file" (which does just that), "Open output folder", and "Quit". One can probably still do better, somebody should think about this.<br />
<br />
=== Compression tools ===<br />
* (Semi-)automatically provide showhelp function<br />
* Modify encodeAudio to accept "input streams", so that we can avoid creating temporary WAVE files<br />
* Improved error checking !!! esp. for FT we got several reports about problems caused by the compression tool being called from the wrong directory. This should be avoidable by implementing suitable checks.<br />
<br />
=== Descumm ===<br />
* Turn it into a library, to be used by a command line frontend (like now), ScummVM debugger, and ScummEX. Basically, the API could consist of a single function, which takes a pointer to a memory buffer, its length, the Scumm version and optionally a game id. Also, it would get a pointer to a print function (in the case of the CLI tool, print to stdout; for ScummVM, print to our GUI console; for ScummEX, append to some window/widget)<br />
* Rewrite code to use 2 passes; first pass builds an intermediate graph, the second pass then tries to detect loops, break/continue statements etc.<br />
* Proper implementation of o6_startObjectQuick decompilation (see comment in descumm6.c). May require rewrite of core program logic.</div>
BgK
https://wiki.scummvm.org/index.php?title=Myst&diff=24111
Myst
2017-12-17T19:28:03Z
<p>BgK: Remove an obsolete remark</p>
<hr />
<div>{{GameDescription|<br />
name=Myst|<br />
image=https://www.scummvm.org/data/screenshots/other/myst/myst-win-de-03.jpg|<br />
release=1993|<br />
alternateNames=Myst Masterpiece Edition|<br />
publisher=[[Brøderbund]], [[Ubisoft]]|<br />
developer=[[Cyan Worlds]]|<br />
distributor=[[Brøderbund]], [[Ubisoft]]|<br />
platforms=Windows, Macintosh, Amiga, Atari Jaguar,<br>Sega Saturn, Sony PlayStation,<br>Windows Mobile, iOS, Philips CD-i, 3DO,<br>PlayStation Portable, Nintendo DS|<br />
resolution=544x332, 256 colors/True Color (MME)|<br />
engine=[[Mohawk]], HyperCard|<br />
support=Since 1.9.0<br />Only Myst and Myst: Masterpiece Edition are<br>supported. All other versions do not use<br>Mohawk and will never be supported.|<br />
purchase=[[Where to get the games#Other Games|Yes]]|<br />
}}<br />
<br />
'''Myst''' is the first game in the [[Myst series]]. It is one of the best selling PC games of all time and is the best selling adventure game of all time. You play as the Stranger who finds himself on a deserted island after placing his/her hand on the image of the island in a book. You must discover what happened to the island's inhabitants and hopefully find a way to the place that you came from.<br />
<br />
'''Myst Masterpiece Edition''' is a 1999 re-release of the original game with true color graphics and improved video quality.<br />
<br />
== Status ==<br />
<br />
The Windows version of Myst and Myst: Masterpiece Edition are completable in ScummVM.<br />
<br />
== External Links ==<br />
*[http://en.wikipedia.org/wiki/Myst Wikipedia article on Myst]<br />
*[http://www.mobygames.com/game/myst MobyGames article on Myst]<br />
<br />
[[Category:Mohawk Games]]<br />
[[Category:Supported Games]]</div>
BgK
https://wiki.scummvm.org/index.php?title=Riven:_The_Sequel_to_Myst&diff=24110
Riven: The Sequel to Myst
2017-12-17T19:27:28Z
<p>BgK: Only the mac and windows versions are supported</p>
<hr />
<div>{{GameDescription|<br />
name=Riven: The Sequel to Myst|<br />
image=http://www.scummvm.org/data/screenshots/other/riven/riven-win-en-03.jpg|<br />
release=1997|<br />
alternateNames=Riven|<br />
publisher=[[Brøderbund|Red Orb Entertainment]], [[Ubisoft]]|<br />
distributor=[[Ubisoft]]|<br />
developer=[[Cyan Worlds]]|<br />
platforms=Windows, Macintosh, Sega Saturn,<br>Sony PlayStation, Windows Mobile,<br>iOS|<br />
resolution=608x436, True Color|<br />
engine=[[Mohawk]]|<br />
support=Since ScummVM 2.0.0|<br />
purchase=[[Where to get the games#Other Games|Yes]]|<br />
}}<br />
<br />
'''Riven: The Sequel to Myst''' is, as the title says, the sequel to [[Myst]], and the second game in the [[Myst series]]. Continuing where the first game left off, Atrus asks you to go to Riven to rescue his wife Catherine and imprison his father Gehn. However, you soon run into complications when arriving on Riven.<br />
<br />
== Status ==<br />
<br />
The Windows and Mac versions of Riven are completable in ScummVM.<br />
<br />
== External Links ==<br />
*[http://en.wikipedia.org/wiki/Riven Wikipedia article on Riven]<br />
*[http://www.mobygames.com/game/http://www.mobygames.com/game/riven-the-sequel-to-myst MobyGames article on Riven]<br />
<br />
[[Category:Mohawk Games]]<br />
[[Category:Supported Games]]</div>
BgK
https://wiki.scummvm.org/index.php?title=Datafiles&diff=24109
Datafiles
2017-12-17T18:51:50Z
<p>BgK: /* Riven: The Sequel to Myst */ add more details regarding sound files</p>
<hr />
<div>This page lists all of the files required, for each particular game to run under ScummVM. The sound files of many games can be compressed too, check the 'Using compressed audio files' section of the readme included with ScummVM for specific details.<br />
<br />
Also the Macintosh versions of Indiana Jones and the Fate of Atlantis, Day of the Tentacle, Sam & Max, Full Throttle and The Dig can be manually [[HOWTO-Mac Games|extracted]] using extract_scumm_mac. However, this is ''not'' required, unless you want to compress some of the data files. Any files from Macintosh discs should be dumped as a data fork only (not in MacBinary or another container with a resource fork) unless noted otherwise.<br />
<br />
The DOS floppy version of The Legend of Kyrandia: The Hand of Fate can be extracted using extract_kyra. This is recommended for portable device usage, because it will significantly reduce the amount of memory required (since ScummVM will not have to cache the compressed files).<br />
<br />
Games that have ** shown in their name use CD audio tracks for music, check readme included with ScummVM to see how to convert them to compressed files.<br />
<br />
Do you have files with unknown MD5 checksums? Please follow our guidelines in [[Reporting unknown MD5 checksums]]<br />
<br />
Some ScummVM features are only available if additional [[External_Datafiles|external datafiles]] are provided e.g. MT32 Emulation.<br />
<br />
==3 Skulls of the Toltecs==<br />
*SAMPLE.AD<br />
*SAMPLE.OPL<br />
*WESTERN<br />
<br />
==7th Guest, The==<br />
'''''DOS/Windows**'''''<br />
*&#42;.gjd<br />
*&#42;.grv<br />
*&#42;.rl<br />
*fat.&#42;<br />
*sphinx.fnt<br />
'''''iOS'''''<br />
<br>''Note: Must be extracted from the .ipa file (which is just a standard zip file)''<br />
*&#42;.gjd<br />
*&#42;.grv<br />
*&#42;.m4a<br />
*&#42;.mp3<br />
*&#42;.rl<br />
*SeventhGuest<br />
*sphinx.fnt<br />
'''''Macintosh'''''<br />
*&#42;.gjd<br />
*T7GData<br />
*T7GMac<br />
**[[HOWTO-Mac_Games|A resource fork]]<br />
<br />
==AGI==<br />
This covers all [[AGI]] games from Sierra (like King's Quest, Larry, Space Quest, ...) but also [[AGI/Fan Games|fan made]] ones.<br />
<br />
'''''All platforms'''''<br />
<br />
* *VOL.* (e.g. GRVOL.0, KQ4VOL.11, VOL.1)<br />
* OBJECT<br />
* *DIR* (e.g. PQDIR, MH2DIR, DMDIR, DIRS, LOGDIR, PICDIR, SNDDIR, VIEWDIR)<br />
* WORDS.TOK<br />
and if available<br />
* PAL.*<br />
<br />
'''''Apple IIGS'''''<br />
<br />
These files are needed to enable music playback<br />
* *.SYS16 (e.g. KQ.SYS16, LL.SYS16, MG.SYS16, BC.SYS16, SQ2.SYS16)<br />
* SIERRASTANDARD<br />
<br />
==Amazon: Guardians of Eden==<br />
'''''All platforms'''''<br />
<br />
* *.AP <br />
* *.BLK<br />
* *.DAT<br />
* *.LZ<br />
* *.MAP<br />
<br />
==Backyard Baseball==<br />
'''''Macintosh'''''<br />
*BaseBall (0)<br />
*BaseBall (1)<br />
*BaseBall (2)<br />
*BaseBall (4)<br />
*BaseBall (9)<br />
'''''Windows'''''<br />
*BASEBALL.HE0<br />
*BASEBALL.HE1<br />
*BASEBALL.HE2<br />
*BASEBALL.HE4<br />
*BASEBALL.HE9<br />
<br />
==Backyard Football==<br />
'''''Macintosh'''''<br />
*FootBall (0)<br />
*FootBall (a)<br />
*FootBall (b)<br />
*FootBall (2)<br />
*FootBall (4)<br />
'''''Windows'''''<br />
*FOOTBALL.HE0<br />
*FOOTBALL.(A)<br />
*FOOTBALL.(B)<br />
*FOOTBALL.HE2<br />
*FOOTBALL.HE4<br />
'''''Windows Demo'''''<br />
*FOOTDEMO.HE0<br />
*FOOTDEMO.(A)<br />
*FOOTDEMO.HE2<br />
*FOOTDEMO.HE4<br />
<br />
==Backyard Soccer==<br />
'''''Macintosh'''''<br />
*Soccer (0)<br />
*Soccer (a)<br />
*Soccer (2)<br />
*Soccer (4)<br />
*Soccer (9)<br />
'''''Windows'''''<br />
*SOCCER.HE0<br />
*SOCCER.(A)<br />
*SOCCER.HE2<br />
*SOCCER.HE4<br />
*SOCCER.HE9<br />
<br />
==Bargon Attack==<br />
*&#42;.snd<br />
*&#42;.ang (English version)<br />
*&#42;.imd<br />
*intro.stk<br />
*traduc.cat<br />
''Note: Several files of the DOS version are only available after you have run the original installation program and installed Bargon Attack to the harddisk.''<br />
<br />
==Bear Stormin'==<br />
*BRSTORM.BRS<br />
*BRSTORM.HE0<br />
*BRSTORM.HE1<br />
<br />
== Beavis and Butt-Head in Virtual Stupidity ==<br />
* *.avi<br />
* *.000<br />
* *.aif<br />
* *.vnm<br />
<br />
while retaining the original directory layout<br />
<br />
==Beneath a Steel Sky==<br />
'''''PC CD and Floppy'''''<br />
*SKY.DNR<br />
*SKY.DSK<br />
*[https://github.com/scummvm/scummvm/raw/master/dists/engine-data/sky.cpt sky.cpt]<br />
<br />
==Big Red Adventure, The==<br />
'''''Amiga Demo'''''<br />
*backs folder<br />
*fonts folder<br />
*part1 folder<br />
*&#42;.win<br />
<br />
'''''Amiga'''''<br />
*backs folder<br />
*common folder<br />
*fonts folder<br />
*part0 folder<br />
*part1 folder<br />
*part2 folder<br />
*part3 folder<br />
*part4 folder<br />
*&#42;.win<br />
<br />
'''''DOS Demo'''''<br />
*ANI folder<br />
*BKG folder<br />
*EN folder<br />
*IT folder<br />
*MSC folder<br />
*PTH folder<br />
*RAS folder<br />
*SCRIPTS folder<br />
*SFX folder<br />
*TAL folder<br />
*&#42;.BMP<br />
*&#42;.FNT<br />
*&#42;.ICO<br />
*&#42;.RAS<br />
*&#42;.TAB<br />
*&#42;.WIN<br />
<br />
'''''DOS'''''<br />
*PART0 folder<br />
*PART1 folder<br />
*PART2 folder<br />
*PART3 folder<br />
*PART4 folder<br />
*&#42;.BMP<br />
*&#42;.FNT<br />
*&#42;.RAS<br />
*&#42;.WIN<br />
<br />
==Big Thinkers First Grade==<br />
'''''Macintosh'''''<br />
*Thinker1 (0)<br />
*Thinker1 (1)<br />
*Thinker1 (2)<br />
*Thinker1 (4)<br />
'''''Windows Demo'''''<br />
*1grademo.HE0<br />
*1grademo.HE1<br />
*1grademo.he2<br />
*1grademo.he4<br />
'''''Windows'''''<br />
*THINKER1.HE0<br />
*THINKER1.HE1<br />
*THINKER1.HE2<br />
*THINKER1.HE4<br />
<br />
==Big Thinkers Kindergarten ==<br />
'''''Macintosh'''''<br />
*ThinkerK (0)<br />
*ThinkerK (1)<br />
*ThinkerK (2)<br />
*ThinkerK (4)<br />
'''''Windows Demo'''''<br />
*KINDDEMO.HE0<br />
*KINDDEMO.HE1<br />
*KINDDEMO.HE2<br />
*KINDDEMO.HE4<br />
'''''Windows'''''<br />
*THINKERK.HE0<br />
*THINKERK.HE1<br />
*THINKERK.HE2<br />
*THINKERK.HE4<br />
<br />
==Bizarre Adventures of Woodruff and the Schnibble, The==<br />
*INTRO.STK<br />
*WOODRUFF.ITK<br />
<br />
==Blue's 123 Time Activities ==<br />
'''''Macintosh'''''<br />
*DATA folder<br />
*Blue's 123 Time (0)<br />
*Blue's 123 Time (2)<br />
*Blue's 123 Time (4)<br />
*Blue's 123 Time (a)<br />
*Blue's 123 Time (b)<br />
'''''Windows'''''<br />
*DATA folder<br />
*Blues123time.(a)<br />
*Blues123time.(b)<br />
*Blues123time.HE0<br />
*Blues123time.he2<br />
*Blues123time.he4<br />
<br />
==Blue's ABC Time Activities==<br />
'''''Macintosh'''''<br />
*Data folder<br />
*Blues ABC Time (0)<br />
*Blues ABC Time (2)<br />
*Blues ABC Time (4)<br />
*Blues ABC Time (a)<br />
*Blues ABC Time (b)<br />
'''''Windows'''''<br />
*Data folder<br />
*BluesABCTime.he0<br />
*BluesABCTime.(a)<br />
*BluesABCTime.(b)<br />
*BluesABCTime.he2<br />
*BluesABCTime.he4<br />
<br />
==Blue's Art Time Activities==<br />
'''''Macintosh'''''<br />
*Data folder<br />
*Blues-ArtTime (0)<br />
*Blues-ArtTime (2)<br />
*Blues-ArtTime (4)<br />
*Blues-ArtTime (a)<br />
*Blues-ArtTime (b)<br />
'''''Windows'''''<br />
*Data folder<br />
*ArtTime.(a)<br />
*ArtTime.(b)<br />
*ArtTime.HE0<br />
*ArtTime.HE2<br />
*ARTTIME.HE4<br />
<br />
==Blue's Birthday Adventure==<br />
'''''Red - Macintosh'''''<br />
*Data folder<br />
*Blue'sBirthday (b)<br />
*Blue'sBirthday-Red (0)<br />
*Blue'sBirthday-Red (a)<br />
*Blue'sBirthday-Red (2)<br />
*Blue'sBirthday-Red (4)<br />
'''''Red - Windows'''''<br />
*Data folder<br />
*Blue'sBirthday.(b)<br />
*Blue'sBirthday-Red.HE0<br />
*Blue'sBirthday-Red.(a)<br />
*Blue'sBirthday-Red.he2<br />
*Blue'sBirthday-Red.he4<br />
'''''Yellow - Macintosh'''''<br />
*Data folder<br />
*Blue'sBirthday (b)<br />
*Blue'sBirthday-Yellow (0)<br />
*Blue'sBirthday-Yellow (a)<br />
*Blue'sBirthday-Yellow (2)<br />
*Blue'sBirthday-Yellow (4)<br />
'''''Yellow - Windows'''''<br />
*Data folder<br />
*Blue'sBirthday.(b)<br />
*Blue'sBirthday-Yellow.HE0<br />
*Blue'sBirthday-Yellow.(a)<br />
*Blue'sBirthday-Yellow.he2<br />
*Blue'sBirthday-Yellow.he4<br />
<br />
==Blue's Reading Time Activities==<br />
'''''Macintosh'''''<br />
*Data folder<br />
*Blues-ReadingTime (0)<br />
*Blues-ReadingTime (2)<br />
*Blues-ReadingTime (4)<br />
*Blues-ReadingTime (a)<br />
*Blues-ReadingTime (b)<br />
'''''Windows'''''<br />
*Data folder<br />
*Blue's Reading Time.(a)<br />
*Blue's Reading Time.(b)<br />
*Blue's Reading Time.HE0<br />
*Blue's Reading Time.he2<br />
*Blue's Reading Time.he4<br />
<br />
==Blue's Treasure Hunt==<br />
'''''Disc 1 - Macintosh'''''<br />
*data folder<br />
*Blue'sTreasureHunt(b)<br />
*Blue'sTreasureHunt-Disc1 (0)<br />
*Blue'sTreasureHunt-Disc1 (2)<br />
*Blue'sTreasureHunt-Disc1 (4)<br />
*Blue'sTreasureHunt-Disc1 (a)<br />
'''''Disc 1 - Windows'''''<br />
*data folder<br />
*Blue'sTreasureHunt.(b)<br />
*Blue'sTreasureHunt-Disc1.(a)<br />
*Blue'sTreasureHunt-Disc1.HE0<br />
*Blue'sTreasureHunt-Disc1.he2<br />
*Blue'sTreasureHunt-Disc1.he4<br />
'''''Disc 2 - Macintosh'''''<br />
*data folder<br />
*Blue'sTreasureHunt(b)<br />
*Blue'sTreasureHunt-Disc2 (0)<br />
*Blue'sTreasureHunt-Disc2 (2)<br />
*Blue'sTreasureHunt-Disc2 (4)<br />
*Blue'sTreasureHunt-Disc2 (a)<br />
'''''Disc 2 - Windows'''''<br />
*data folder<br />
*Blue'sTreasureHunt.(b)<br />
*Blue'sTreasureHunt-Disc2.(a)<br />
*Blue'sTreasureHunt-Disc2.HE0<br />
*Blue'sTreasureHunt-Disc2.he2<br />
*Blue'sTreasureHunt-Disc2.he4<br />
<br />
==Blue Force==<br />
*&#42;.rlb<br />
''Note: Files of the floppy version are only available after you have run the original installation program and installed Blue Force to the harddisk.''<br />
<br />
==Broken Sword: The Shadow of the Templars==<br />
'''''Macintosh Demo and Windows Demo'''''<br />
*CLUSTERS folder<br />
*MUSIC folder<br />
*SPEECH folder<br />
'''''Macintosh'''''<br />
*&#42;.clm<br />
*swordres.rif<br />
*MUSIC folder<br />
*SMACKSHI folder<br />
*SPEECH folder<br />
*Rename speech.clu on CD1 to speech1.clu<br />
*Rename speech.clu on CD2 to speech2.clu<br />
'''''Windows'''''<br />
*&#42;.clu<br />
*swordres.rif<br />
*MUSIC folder (Except 2M29.WAV in CD2)<br />
*SMACKSHI folder<br />
*SPEECH folder<br />
*Rename speech.clu on CD1 to speech1.clu<br />
*Rename speech.clu on CD2 to speech2.clu<br />
'''''PlayStation'''''<br />
*&#42;.clu<br />
*swordres.rif<br />
*speech.tab<br />
*speech.lis<br />
*speech.inf<br />
*speech.dat<br />
*tunes.tab<br />
*tunes.dat<br />
*train.plx<br />
*STREAMS folder ([[HOWTO-PlayStation Videos|how to extract]])<br />
<br />
==Broken Sword II: The Smoking Mirror==<br />
'''''Windows Demo'''''<br />
*&#42;.clu<br />
*&#42;.inf<br />
*&#42;.tab<br />
'''''Windows'''''<br />
*&#42;.clu<br />
*&#42;.inf<br />
*&#42;.tab<br />
*&#42;.smk<br />
*credits.bmp<br />
*Rename music.clu on CD1 to music1.clu<br />
*Rename music.clu on CD2 to music2.clu<br />
*Rename speech.clu on CD1 to speech1.clu<br />
*Rename speech.clu on CD2 to speech2.clu<br />
'''''PlayStation'''''<br />
*&#42;.clu<br />
*&#42;.inf<br />
*&#42;.tab<br />
*CREDITS.TXT<br />
*STREAMS folder ([[HOWTO-PlayStation Videos|how to extract]])<br />
<br />
==Bud Tucker in Double Trouble==<br />
'''''DOS CD'''''<br />
*AUDIO folder<br />
*FX folder<br />
*GRAPHICS folder<br />
*MUSIC folder<br />
*SPEECH folder<br />
*SPRITES folder<br />
*&#42;.ENC<br />
*&#42;.PCX<br />
*&#42;.TXT<br />
*&#42;.DTA<br />
<br />
'''''DOS Demo'''''<br />
*Audio folder<br />
*Graphics folder<br />
*SAMPLE.&#42;<br />
<br />
==Chivalry is Not Dead==<br />
* data.dcp<br />
* arial.ttf (or equivalent replacement)<br />
* FONTS folder (specifically ALEAWB__.TTF)<br />
<br />
==Cruise for a Corpse==<br />
*D1<br />
*D2<br />
*D3<br />
*D4<br />
*D5<br />
*DELPHINE.LNG<br />
*SYSTEM.FNT<br />
*VOL.&#42;<br />
<br />
==Curse of Monkey Island, The==<br />
*RESOURCE folder (with content from both CDs)<br />
*COMI.LA0<br />
*COMI.LA1<br />
*COMI.LA2<br />
<br />
==Day of the Tentacle==<br />
'''''Macintosh CD'''''<br />
*Day of the Tentacle Data<br />
'''''Macintosh Demo'''''<br />
*Day of the Tentacle Demo Data<br />
'''''PC CD and Floppy'''''<br />
*MONSTER.SOU<br />
*TENTACLE.000<br />
*TENTACLE.001<br />
'''''PC Demo'''''<br />
*DOTTDEMO.000<br />
*DOTTDEMO.001<br />
*MONSTER.SOU<br />
<br />
==Dig, The==<br />
'''''Macintosh'''''<br />
*The Dig Data<br />
'''''Macintosh Demo'''''<br />
*The Dig Demo Data<br />
'''''PC'''''<br />
*VIDEO folder<br />
*DIG.LA0<br />
*DIG.LA1<br />
*DIGMUSIC.BUN<br />
*DIGVOICE.BUN<br />
*LANGUAGE.BND (Non-English versions)<br />
'''''PC Demo'''''<br />
*audio folder<br />
*video folder<br />
*dig.la0<br />
*dig.la1<br />
<br />
==Discworld==<br />
'''''DOS Floppy'''''<br />
*&#42;.GRA<br />
*&#42;.IDX<br />
*&#42;.TXT<br />
*MIDI.DAT<br />
*INDEX<br />
*SAMPLE.AD<br />
*SAMPLE.MT<br />
*SAMPLE.OPL<br />
<br />
'''''DOS CD'''''<br />
*&#42;.IDX<br />
*&#42;.GRA (if exists)<br />
*&#42;.SCN (if exists)<br />
*&#42;.SMP<br />
*&#42;.TXT<br />
*FAT.OPL (if exists)<br />
*MIDI.DAT<br />
*INDEX<br />
*SAMPLE.AD (if exists)<br />
*SAMPLE.OPL (if exists)<br />
<br />
==Discworld 2: Missing Presumed ...!?==<br />
'''''DOS and Windows CD'''''<br />
*&#42;.BMV<br />
*&#42;.CDP<br />
*&#42;.MUS<br />
*&#42;.SCN<br />
*GDATA<br />
*HOPPER<br />
*INDEX<br />
*SAMPLE.BNK<br />
*Rename ENGLISH.SMP on CD1 to ENGLISH1.SMP (English version)<br />
*Rename ENGLISH.TXT on CD1 to ENGLISH1.TXT (English version)<br />
*Rename ENGLISH.IDX on CD1 to ENGLISH1.IDX (English version)<br />
*Rename ENGLISH.SMP on CD2 to ENGLISH2.SMP (English version)<br />
*Rename ENGLISH.TXT on CD2 to ENGLISH2.TXT (English version)<br />
*Rename ENGLISH.IDX on CD2 to ENGLISH2.IDX (English version)<br />
<br />
The aforementioned files can also be named FRENCH(.SMP/.TXT/.IDX)<br />
in French versions, GERMAN(.SMP/.TXT/.IDX) in German versions<br />
or US(.SMP/.TXT/.IDX) in US English versions<br />
<br />
==Dragon History==<br />
'''''DOS CD'''''<br />
*ANIM.DFW<br />
*Big.fon<br />
*CD.SAM (dummy dubbing file, can be replaced by a real one with Czech dubbing)<br />
*CD2.SAM<br />
*CMF.INS<br />
*HRA.DFW<br />
*HUDBA&#42;.MID<br />
*IKONY.DFW<br />
*INIT.DFW<br />
*MAPY.DFW<br />
*MIST.DFW<br />
*OBJEKTY.DFW<br />
*OBR_AN.DFW<br />
*OBR_IK.DFW<br />
*OBR_MAS.DFW<br />
*PALETY.DFW<br />
*RETEZCE.DFW<br />
*ROZH&#42;.DFW<br />
*Small.fon<br />
<br />
==Drascula: The Vampire Strikes Back==<br />
'''''DOS CD**'''''<br />
*&#42;.ALD<br />
*&#42;.ALG<br />
*&#42;.ALS<br />
*&#42;.BIN<br />
*&#42;.CAL<br />
<br />
==Dreamweb==<br />
'''''All Floppy'''''<br />
*DREAMWEB.&#42;<br />
** Requires decompression from RNC files using original installer under DOSBox.<br />
<br />
'''''English CD'''''<br />
*DREAMWEB.&#42;<br />
*SPEECH folder<br />
<br />
'''''French CD'''''<br />
*DREAMWFR.&#42;<br />
*FRENCH folder<br />
<br />
'''''Spanish CD'''''<br />
*DREAMWSP.&#42;<br />
*SPANISH folder<br />
<br />
==Elvira: Mistress of the Dark==<br />
'''''Amiga'''''<br />
*&#42;.out<br />
*&#42;.pkd<br />
*&#42;tune<br />
*gameamiga<br />
*icon.dat<br />
*start<br />
'''''Amiga Demo'''''<br />
*&#42;.out<br />
*agos.mdf<br />
*elvira2<br />
*englishdemo<br />
*icon.dat<br />
'''''Atari ST'''''<br />
*&#42;.OUT<br />
*&#42;.PKD<br />
*GAMEST<br />
*ICON.DAT<br />
*START<br />
*TABLES&#42;<br />
*TBLLIST<br />
'''''Atari ST Demo'''''<br />
*&#42;.OUT<br />
'''''DOS'''''<br />
*&#42;.MUS<br />
*&#42;.SND<br />
*&#42;.VGA<br />
*GAMEPC<br />
*ICON.DAT<br />
*INSTR.DAT<br />
*START<br />
*TABLES&#42;<br />
*TBLLIST<br />
'''''DOS Demo'''''<br />
*&#42;.VGA<br />
*DEMO<br />
*ICON.DAT<br />
*INSTR.DAT<br />
*MOD8.MUS<br />
*TBLLIST<br />
<br />
==Elvira II: The Jaws of Cerberus==<br />
'''''Amiga'''''<br />
*&#42;.out<br />
*&#42;.pkd<br />
*&#42;tune<br />
*gameamiga<br />
*ICON.DAT<br />
*menus.dat<br />
*start<br />
*stripped.txt<br />
*tables&#42;<br />
*tbllist<br />
*text&#42;<br />
'''''Atari ST'''''<br />
*&#42;.OUT<br />
*&#42;.PKD<br />
*GAMEST<br />
*ICON.DAT<br />
*MENUS.DAT<br />
*START<br />
*STRIPPED.TXT<br />
*TABLES&#42;<br />
*TBLLIST<br />
*TEXT&#42;<br />
'''''DOS'''''<br />
*&#42;.MUS<br />
*&#42;.VGA<br />
*GAMEPC<br />
*ICON.DAT<br />
*MENUS.DAT<br />
*MUSIC.DRV<br />
*MYLIB.FXB<br />
*START<br />
*STRIPPED.TXT<br />
*TABLES&#42;<br />
*TBLLIST<br />
*TEXT&#42;<br />
<br />
==Eye of the Beholder==<br />
'''''DOS'''''<br />
<br />
If you have a version which only contains ''EYE.PAK'' you will need to run the original installer first.<br />
<br />
If you have a version with files like ''EOBDATA1.PAK'' you will need the following files:<br />
* EOBDATA1.PAK<br />
* EOBDATA2.PAK<br />
* EOBDATA3.PAK<br />
* EOBDATA4.PAK<br />
* EOBDATA5.PAK<br />
* EOBDATA6.PAK<br />
* EOBDATA.SAV<br />
* FONT6.FNT<br />
* FONT8.FNT<br />
<br />
Otherwise you will need these:<br />
* *.CMP<br />
* *.COL<br />
* *.CPS<br />
* *.DAT<br />
* *.ECN<br />
* *.EGA<br />
* *.ELO or *.INF or *.DRO (There should be exactly one of these file extensions present)<br />
* *.EMP<br />
* FONT6.FNT<br />
* FONT8.FNT<br />
* *.MAZ<br />
* *.PAL<br />
* TEXT.RAW<br />
* EOBDATA.SAV<br />
* *.VCN<br />
* *.VGA<br />
* *.VMP<br />
* XANATHA.VOL<br />
<br />
==Eye of the Beholder II: The Legend of Darkmoon==<br />
'''''DOS'''''<br />
* *.ADL<br />
* PALETTE.COL<br />
* *.CPS<br />
* *.DAT<br />
* *.DCR<br />
* *.DEC<br />
* *.EGA<br />
* FONT6.FNT<br />
* FONT8.FNT<br />
* *.INF<br />
* *.MAZ<br />
* *.PAL<br />
* EOBDATA0.SAV<br />
* *.SND<br />
* CREDITS.TXT<br />
* *.VCN<br />
* *.VMP<br />
<br />
==Fascination==<br />
'''''Amiga'''''<br />
* *.STK<br />
* MOD.EXTASY<br />
<br />
'''''Atari ST'''''<br />
* *.STK<br />
<br />
'''''PC CD**'''''<br />
* *.LIC<br />
* *.GDR<br />
* *.IMD<br />
* *.STK<br />
''Note: Extract *.STK using the [[User_Manual/Installing a game for use with ScummVM#Fascination|Fascination CD extraction tool]]. This will require an ISO image of the CD, but just the first data track i.e. ~11MB The second audio track should be extracted as per other games with CD-DA tracks.''<br />
<br />
'''''PC Floppy'''''<br />
* *.IMD<br />
* *.STK<br />
* *.ANG (if existing)<br />
''Note: Several files are only available after you have run the original installation program and installed Fascination to the harddisk.''<br />
<br />
==Fatty Bear's Birthday Surprise==<br />
'''''3DO'''''<br />
*&#42;.DMU<br />
*FBEAR.HE0<br />
*FBEAR.HE1<br />
*FBEAR.SNG<br />
*FBEAR.TLK<br />
'''''DOS Demo'''''<br />
*fbdemo.he0<br />
*fbdemo.he1<br />
*fbdemo.tlk<br />
'''''DOS'''''<br />
*FBEAR.HE0<br />
*FBEAR.HE1<br />
*FBEAR.SNG<br />
*FBEAR.TLK<br />
'''''Windows Demo'''''<br />
*FBDEMO.HE0<br />
*FBDEMO.HE1<br />
*FBDEMO.HE2<br />
*FBDEMO.HE3<br />
*FBDEMO.HE4<br />
'''''Windows'''''<br />
*FBEAR.HE0<br />
*FBEAR.HE1<br />
*FBEAR.HE2<br />
*FBEAR.HE3<br />
*FBEAR.HE4<br />
*FBEAR.SNG<br />
<br />
==Fatty Bear's Fun Pack==<br />
'''''3DO'''''<br />
*&#42;.DMU<br />
*FBPACK.C&#42;<br />
*FBPACK.HE0<br />
*FBPACK.HE1<br />
*FBPACK.PAL<br />
*FBPACK.TAN<br />
*FBPACK.TLK<br />
'''''DOS'''''<br />
*FBPACK.C&#42;<br />
*FBPACK.HE0<br />
*FBPACK.HE1<br />
*FBPACK.PAL<br />
*FBPACK.TAN<br />
*FBPACK.TLK<br />
<br />
==Feeble Files, The==<br />
'''''Amiga'''''<br />
*gfx folder<br />
*movies folder<br />
*sfx folder<br />
*speech folder<br />
*audio.wav (Non-English versions)<br />
*GAME22<br />
*gfxindex.dat<br />
*setup<br />
*TABLES&#42;<br />
*TBLLIST<br />
'''''DOS Demo'''''<br />
*&#42;.SMK<br />
'''''Macintosh'''''<br />
*movies folder<br />
*audio.wav (Non-English versions)<br />
*effects.wav<br />
*GAME22<br />
*graphics.vga<br />
*setup<br />
*TABLES&#42;<br />
*TBLLIST<br />
'''''Windows'''''<br />
<br />
''Note: Several files are only available after you have run the original installation program and installed Feeble Files to the harddisk.''<br />
<br />
*&#42;.SMK (Except DISK1/2/3/4.SMK)<br />
*&#42;.VGA<br />
*GAME33 (Polish 2CD version) or GAME22 (All others)<br />
*save.999<br />
*TABLES&#42;<br />
*TBLLIST<br />
*Rename voices.wav on CD1 to voices1.wav<br />
*Rename voices.wav on CD2 to voices2.wav<br />
*Rename voices.wav on CD3 to voices3.wav (For 4CD release only)<br />
*Rename voices.wav on CD4 to voices4.wav (For 4CD release only)<br />
<br />
==Flight of the Amazon Queen==<br />
'''''Amiga'''''<br />
*QUEEN.1<br />
*QUEEN.2<br />
*QUEEN.3<br />
*QUEEN.4<br />
*QUEEN.5<br />
*QUEEN.6<br />
*QUEEN.7<br />
*QUEEN.8<br />
*QUEEN.9<br />
*QUEEN.10<br />
*QUEEN.11<br />
*[https://github.com/scummvm/scummvm/raw/master/dists/engine-data/queen.tbl queen.tbl]<br />
'''''PC'''''<br />
*QUEEN.1<br />
*[https://github.com/scummvm/scummvm/raw/master/dists/engine-data/queen.tbl queen.tbl]<br />
'''''Freeware version'''''<br />
*queen.1c<br />
<br />
==Freddi Fish 1: The Case of the Missing Kelp Seeds==<br />
'''''Windows Demo'''''<br />
*freddemo.he0<br />
*freddemo.he1<br />
*freddemo.he2<br />
*freddemo.he3<br />
*freddemo.he4<br />
'''''Windows'''''<br />
*FREDDI.HE0<br />
*FREDDI.HE1<br />
*FREDDI.HE2<br />
*FREDDI.HE3 (Older version only)<br />
*FREDDI.HE4<br />
<br />
==Freddi Fish 2: The Case of the Haunted Schoolhouse==<br />
'''''Windows Demo'''''<br />
*FF2-DEMO.HE0<br />
*FF2-DEMO.HE1<br />
*FF2-DEMO.HE2<br />
*FF2-DEMO.HE4<br />
'''''Windows'''''<br />
*FREDDI2.HE0<br />
*FREDDI2.HE1 or FREDDI2.(A)<br />
*FREDDI2.HE2<br />
*FREDDI2.HE4<br />
<br />
==Freddi Fish 3: The Case of the Stolen Conch Shell==<br />
'''''Windows Demo'''''<br />
*F3-MDEMO.HE0<br />
*F3-MDEMO.HE1<br />
*F3-MDEMO.HE2<br />
*F3-MDEMO.HE4<br />
'''''Windows'''''<br />
*FREDDI3.HE0<br />
*FREDDI3.HE1<br />
*FREDDI3.HE2<br />
*FREDDI3.HE4<br />
<br />
==Freddi Fish 4: The Case of the Hogfish Rustlers of Briny Gulch==<br />
'''''Windows Demo'''''<br />
*f4-demo.HE0<br />
*f4-demo.(a)<br />
*f4-demo.he2<br />
*f4-demo.he4<br />
'''''Windows'''''<br />
*FREDDI4.HE0<br />
*FREDDI4.(A)<br />
*FREDDI4.HE2<br />
*FREDDI4.HE4<br />
<br />
==Freddi Fish and Luther's Maze Madness==<br />
'''''Windows'''''<br />
*maze.HE0<br />
*MAZE.HE1<br />
*MAZE.HE2<br />
*MAZE.HE4<br />
*MAZE.HE8<br />
<br />
==Freddi Fish and Luther's Water Worries==<br />
'''''Windows'''''<br />
*WATER.HE0<br />
*WATER.HE1<br />
*WATER.HE2<br />
*WATER.HE4<br />
*WATER.HE7<br />
<br />
==Freddi Fish's One-Stop Fun Shop==<br />
'''''Windows'''''<br />
*heidi folder<br />
*FreddisFunShop.(a)<br />
*FreddisFunShop.(b)<br />
*FreddisFunShop.he0<br />
*FreddisFunShop.he2<br />
*FreddisFunShop.he4<br />
<br />
==Full Throttle==<br />
'''''Macintosh'''''<br />
*Full Throttle Data<br />
'''''Macintosh Demo'''''<br />
*Full Throttle Demo Data<br />
'''''PC'''''<br />
*FT.LA0<br />
*FT.LA1<br />
*MONSTER.SOU<br />
*DATA folder, EXCEPT files:<br />
**BENBIKE.NUT<br />
**CHASEBEN.SAN<br />
**ROADRASH.NUT<br />
**ROADRSH2.NUT<br />
*VIDEO folder, EXCEPT files:<br />
**BIKESWAR.SAN<br />
**BLINK.SAN<br />
**BLINK2.SAN<br />
**BLINK3.SAN<br />
**CATCHUP.SAN<br />
**CRUSHDOG.SAN<br />
**CVRAMP.SAN<br />
**DEMOGOGG.TRS<br />
**DRIVEBY.SAN<br />
**FI.TRS<br />
**FI_14.SAN<br />
**HI_SIGN.SAN<br />
**LIMOBY.SAN<br />
**LIMOROAR.SAN<br />
**MIRANDA.TRS<br />
**PLNCRSH.SAN<br />
**POLEEXIT.TRS<br />
**REACHHER.SAN<br />
**RESTSTOP.TRS<br />
**RIPFELL.TRS<br />
**SHOWDOWN.TRS<br />
**TINYTRUC.SAN<br />
'''''PC Demo'''''<br />
*ft.000<br />
*ft.001<br />
*monster.sou<br />
*DATA folder, EXCEPT files:<br />
**benbike.nut<br />
**harlrev.sad<br />
**laser2.sad<br />
**liftbord.san<br />
**liftchay.san<br />
**liftgog.san<br />
**lidtsaw.san<br />
**roadrash.nut<br />
**roadrsh2.nut<br />
**smushcut.txt<br />
*VIDEO folder, EXCEPT files:<br />
**barkdog.san<br />
**bed.nut<br />
**bigfoot.nut<br />
**blackfrm.nut<br />
**blink.nut<br />
**blink2.nut<br />
**blink3.nut<br />
**burstdog.san<br />
**crash.nut<br />
**cvramp.san<br />
**demogogg.san<br />
**dodge.nut<br />
**face-6.nut<br />
**finsushi.san<br />
**fire.nut<br />
**fishgogg.nut<br />
**focus.nut<br />
**fucus-5.nut<br />
**goggles.nut<br />
**limopan.nut<br />
**peelout.nut<br />
**riding.nut,<br />
**takeoff.san<br />
**test.san<br />
**vision.san<br />
<br />
==Future Wars==<br />
'''''Amiga'''''<br />
*&#42;.dat<br />
*&#42;.prc<br />
*aliens<br />
*escalator<br />
*PART&#42;<br />
*superfutur<br />
<br />
'''''Amiga Demo'''''<br />
*&#42;.dat<br />
*&#42;.PRC<br />
*DEMO<br />
<br />
'''''Atari ST'''''<br />
*&#42;.DAT<br />
*&#42;.PRC<br />
*ALIENS<br />
*ESCAL<br />
*SFUTUR<br />
*PART&#42;<br />
<br />
'''''DOS'''''<br />
*&#42;.DAT<br />
*&#42;.PAL<br />
*&#42;.PRC<br />
*BASESON.SND<br />
*PART&#42;<br />
<br />
==Geisha==<br />
'''''Amiga, Atari ST, DOS'''''<br />
*&#42;.STK<br />
<br />
==Gobliiins==<br />
'''''Amiga, Atari ST, Demo, DOS CD&#42;&#42;'''''<br />
*&#42;.STK<br />
*COMMUN.EX1 (if existing) <br />
*GOB.LIC (for CD version)<br />
'''''DOS EGA, DOS VGA'''''<br />
*&#42;.STK<br />
*COMMUN.EX1 (if existing) <br />
*GOB.LIC (for CD version)<br />
''Note: Several files of the DOS floppy version are only available after you have run the original installation program and installed Gobliiins to the harddisk.''<br />
<br />
'''''Macintosh'''''<br />
*&#42;.STK<br />
*&#42;.ADL<br />
*&#42;.FNT<br />
*COMMUN.EX1 <br />
'''''Windows'''''<br />
*&#42;.STK<br />
*&#42;.MID<br />
*&#42;.FNT<br />
<br />
==Gobliins 2==<br />
'''''Amiga Demo, Amiga'''''<br />
*&#42;.DUM<br />
*&#42;.ins<br />
*&#42;.STK<br />
'''''Atari ST, Demo, DOS CD&#42;&#42;'''''<br />
*&#42;.STK<br />
*GOB2.LIC or GOBNEW.LIC (for CD version)<br />
'''''DOS EGA, DOS VGA'''''<br />
*&#42;.STK<br />
*GOB2.LIC or GOBNEW.LIC (for CD version)<br />
''Note: Several files of the DOS floppy version are only available after you have run the original installation program and installed Gobliins 2 to the harddisk.''<br />
<br />
'''''Macintosh, Windows'''''<br />
*&#42;.STK<br />
*&#42;.MID<br />
<br />
==Goblins 3==<br />
'''''Amiga'''''<br />
* &#42;.stk (game data)<br />
* &#42;.tot (extra scripts)<br />
* &#42;.ext (extra data)<br />
* &#42;.all (German texts) (if existing)<br />
* &#42;.ang (English (GB) texts) (if existing)<br />
* &#42;.dat (French texts) (if existing)<br />
* &#42;.esp (Spanish texts) (if existing)<br />
* &#42;.ita (Italian texts) (if existing)<br />
* &#42;.usa (English (US) texts) (if existing)<br />
* &#42;.ins (music instrument data)<br />
* &#42;.dum (music score data)<br />
<br />
'''''DOS CD&#42;&#42;'''''<br />
* &#42;.stk (game data)<br />
* imd.itk (movies)<br />
* mus_gob3.lic (CD audio index)<br />
* coktel.imd (Coktel logo animation)<br />
* degob3.itk (German speech) (if existing)<br />
* frgob3.itk (French speech) (if existing)<br />
* itgob3.itk (Italian speech) (if existing)<br />
* usgob3.itk (English speech) (if existing)<br />
<br />
'''''DOS Floppy'''''<br />
* &#42;.stk (game data)<br />
* imd.itk (movies)<br />
''Note: Several files of the DOS floppy version are only available after you have run the original installation program and installed Goblins 3 to the harddisk.''<br />
<br />
'''''Macintosh'''''<br />
* &#42;.stk (game data)<br />
* imd.itk (movies)<br />
* &#42;.mid (music score data)<br />
* &#42;.fnt (Mac-specific fonts)<br />
<br />
'''''Windows'''''<br />
* &#42;.stk (game data)<br />
* imd.itk (movies)<br />
* &#42;.mid (music score data)<br />
<br />
==Hi-Res Adventure #0: Mission Asteroid==<br />
'''''Apple II disk image'''''<br />
* MISSION.NIB<br />
<br />
==Hi-Res Adventure #1: Mystery House==<br />
'''''Apple II plain files'''''<br />
* AUTO LOAD OBJ<br />
* ADVENTURE<br />
* BLOCK&#42;<br />
* MESSAGES<br />
* MYSTERY.HELLO<br />
<br />
'''''Apple II disk image'''''<br />
* MYSTHOUS.DSK<br />
<br />
==Hi-Res Adventure #2: Wizard and the Princess==<br />
'''''Apple II disk image'''''<br />
* WIZARD.DSK<br />
<br />
==Hi-Res Adventure #3: Cranston Manor==<br />
'''''Apple II disk image'''''<br />
* CRANSTON.D13<br />
''Note: The .D13 format is a raw 13-sector disk image. Track 0, sector 10 is missing on the disk and should be zeroed out in the image (the KryoFlux tools seem to fill this sector with random garbage instead). This sector covers the 256 bytes starting at offset 2560 in the image.''<br />
<br />
==Hi-Res Adventure #4: Ulysses and the Golden Fleece==<br />
'''''Apple II disk images'''''<br />
* ULYSSESA.DSK<br />
* ULYSSESB.DSK<br />
<br />
==Hi-Res Adventure #5: Time Zone==<br />
'''''Apple II disk images'''''<br />
* TZONE1A.NIB<br />
* TZONE1B.NIB<br />
* TZONE2C.NIB<br />
* TZONE2D.NIB<br />
* TZONE3E.NIB<br />
* TZONE3F.NIB<br />
* TZONE4G.NIB<br />
* TZONE4H.NIB<br />
* TZONE5I.NIB<br />
* TZONE5J.NIB<br />
* TZONE6K.NIB<br />
* TZONE6L.NIB<br />
<br />
==Hi-Res Adventure #6: The Dark Crystal==<br />
'''''Apple II disk images'''''<br />
* DARK1A.DSK<br />
* DARK1B.NIB<br />
* DARK2A.NIB<br />
* DARK2B.NIB<br />
<br />
==Hugo's House of Horrors==<br />
'''''DOS'''''<br />
* &#42;.art<br />
* &#42;.b<br />
* &#42;.bsf (optional)<br />
* &#42;.dat<br />
* &#42;.fon<br />
* &#42;.o<br />
* &#42;.ob<br />
* &#42;.pix<br />
<br />
'''''Windows'''''<br />
* &#42;.bsf<br />
* &#42;.dat<br />
<br />
==Hugo 2: Whodunit?==<br />
'''''DOS'''''<br />
* &#42;.bsf (optional)<br />
* &#42;.dat<br />
* &#42;.fon<br />
<br />
'''''Windows'''''<br />
* &#42;.bsf<br />
* &#42;.dat<br />
<br />
==Hugo 3: Jungle of Doom==<br />
'''''DOS'''''<br />
* &#42;.bsf (optional)<br />
* &#42;.dat<br />
* &#42;.fon<br />
<br />
'''''Windows'''''<br />
* &#42;.bsf<br />
* &#42;.dat<br />
<br />
==I Have No Mouth, and I Must Scream==<br />
'''''English, German, French, Spanish, Russian Full PC Version'''''<br />
*musicfm.res<br />
*musicgm.res<br />
*scream.res<br />
*patch.re_<br />
*scripts.res<br />
*sfx.res<br />
*voicess.res<br />
*voices1.res<br />
*voices2.res<br />
*voices3.res<br />
*voices4.res (does not exist in the censored German and French versions)<br />
*voices5.res<br />
*voices6.res<br />
<br />
'''''English Mac Version'''''<br />
*scream.res<br />
*patch.res<br />
*scripts.res<br />
*sfx.res<br />
*Music folder<br />
*SFX folder<br />
*Voices folder<br />
<br />
'''''DOS Demo'''''<br />
*music.res<br />
*scream.res<br />
*scripts.res<br />
*sfx.res<br />
*voicesd.res<br />
<br />
==Indiana Jones and the Fate of Atlantis==<br />
'''''Amiga'''''<br />
*amiga&#42;.ims<br />
*atlantis.000<br />
*atlantis.001<br />
*atlantis.002<br />
*atlantis.003<br />
*atlantis.004<br />
*atlantis.005<br />
*atlantis.006<br />
*atlantis.007<br />
*atlantis.008<br />
*atlantis.009<br />
*atlantis.010<br />
*atlantis.011<br />
'''''FM-TOWNS'''''<br />
*INDY4.SOU<br />
*INDY4.000<br />
*INDY4.001<br />
'''''Macintosh CD (PPC)'''''<br />
*Fate of Atlantis Data<br />
'''''Macintosh CD/Floppy (m68k)'''''<br />
*MONSTER.SOU<br />
*ATLANTIS.000<br />
*ATLANTIS.001<br />
*iMuse Setups<br />
**[[HOWTO-Mac_Games|A resource fork]]<br />
''''' PC CD'''''<br />
*MONSTER.SOU<br />
*ATLANTIS.000<br />
*ATLANTIS.001<br />
'''''PC Floppy'''''<br />
*ATLANTIS.000<br />
*ATLANTIS.001<br />
'''''Demo'''''<br />
*PLAYFATE.000<br />
*PLAYFATE.001<br />
<br />
==Indiana Jones and the Last Crusade==<br />
'''''Amiga, Atari ST, FM-TOWNS&#42;&#42;, Macintosh, PC EGA or PC 256 color'''''<br />
*&#42;.LFL<br />
<br />
==Inherit the Earth: Quest for the Orb==<br />
'''''DOS CD/Floppy, iOS, Linux (Demo/Game), Mac OS X (Demo/Game), Windows (Demo/Game)'''''<br />
*&#42;.rsc<br />
*&#42;.bbm (if exists)<br />
*&#42;.iaf (if exists)<br />
*INSTR.AD or SAMPLE.AD<br />
*INSTR.OPL or SAMPLE.OPL<br />
*graphics/ folder (if exists)<br />
*music/ folder (if exists)<br />
*patch/ folder (if exists)<br />
*sound/ folder (if exists)<br />
*Inherit the Earth Voices (for Mac OS X version)<br />
'''''Macintosh CD'''''<br />
*ITE Music.bin<br />
*ITE Resources.bin<br />
*ITE Scripts.bin<br />
*ITE Sounds.bin<br />
*ITE Voices.bin (all files should be in MacBinary format)<br />
<br />
==Journeyman Project: Pegasus Prime, The==<br />
'''''Macintosh'''''<br />
* See [[HOWTO-Extract Pegasus Prime/File List|this list]] or [[HOWTO-Extract Pegasus Prime|this]] more comprehensive extraction guide.<br />
<br />
==Lands of Lore: The Throne of Chaos==<br />
<br />
'''''DOS Floppy'''''<br />
*WESTWOOD.&#42;<br />
*[https://github.com/scummvm/scummvm/raw/master/dists/engine-data/kyra.dat kyra.dat]<br />
<br />
'''''DOS Floppy (extracted/installed)'''''<br />
*&#42;.PAK<br />
*[https://github.com/scummvm/scummvm/raw/master/dists/engine-data/kyra.dat kyra.dat]<br />
<br />
'''''DOS CD'''''<br />
<br />
''Note: If you own the release from GoG.com you need to extract some of the following files from the "GAME.DAT" file (or "D.iso" file for the mac version), which is an image of the game CD. ScummVM intentionally does '''not''' work without extracting the files first.''<br />
<br />
*&#42;.ADL<br />
*FILEDATA.FDT<br />
*&#42;.PAK<br />
*&#42;.TLK<br />
*[https://github.com/scummvm/scummvm/raw/master/dists/engine-data/kyra.dat kyra.dat]<br />
And the following directories:<br />
*ENG<br />
*FRE<br />
*GER<br />
<br />
'''''DOS Demo'''''<br />
*&#42;.PAK<br />
*[https://github.com/scummvm/scummvm/raw/master/dists/engine-data/kyra.dat kyra.dat]<br />
<br />
'''''PC-98'''''<br />
*&#42;.PAK<br />
*[https://github.com/scummvm/scummvm/raw/master/dists/engine-data/kyra.dat kyra.dat]<br />
<br />
==Last Express, The==<br />
<br />
'''''DOS/Macintosh/Windows'''''<br />
*HD.HPF<br />
*CD1.HPF<br />
*CD2.HPF<br />
*CD3.HPF<br />
<br />
'''''Windows Demo'''''<br />
*Demo.hpf<br />
*blue.egg<br />
<br />
==Leather Goddesses of Phobos 2==<br />
*LGOP2.DAT<br />
*LGOP2.PRJ<br />
<br />
==Legend of Kyrandia, The==<br />
'''''DOS Floppy'''''<br />
*&#42;.ADL<br />
*&#42;.COL<br />
*&#42;.CPS<br />
*&#42;.DAT<br />
*&#42;.EMC<br />
*&#42;.FNT<br />
*&#42;.PAK<br />
*CREDITS.TXT<br />
*&#42;.WSA<br />
*&#42;.XMI<br />
*[https://github.com/scummvm/scummvm/raw/master/dists/engine-data/kyra.dat kyra.dat]<br />
'''''DOS CD'''''<br />
*&#42;.APK<br />
*&#42;.CPS<br />
*&#42;.PAK<br />
*&#42;.VRM<br />
*[https://github.com/scummvm/scummvm/raw/master/dists/engine-data/kyra.dat kyra.dat]<br />
'''''FM-TOWNS&#42;&#42;'''''<br />
*&#42;.PAK<br />
*[https://github.com/scummvm/scummvm/raw/master/dists/engine-data/kyra.dat kyra.dat]<br />
'''''Demo'''''<br />
*8FAT.FNT<br />
*BOTTOM.CPS<br />
*DEMO1.COL<br />
*DEMO1.WSA<br />
*DEMO2.COL<br />
*DEMO2.WSA<br />
*DEMO3.COL<br />
*DEMO3.WSA<br />
*DEMO4.COL<br />
*DEMO4.WSA<br />
*FINAL.CPS<br />
*INTRO.ADL<br />
*INTRO.XMI<br />
*KYRANDIA.WSA<br />
*START.CPS<br />
*TOP.CPS<br />
*WESTWOOD.WSA<br />
*[https://github.com/scummvm/scummvm/raw/master/dists/engine-data/kyra.dat kyra.dat]<br />
<br />
==Legend of Kyrandia, The: Hand of Fate==<br />
'''''DOS Floppy'''''<br />
* WESTWOOD.00&#42;<br />
*[https://github.com/scummvm/scummvm/raw/master/dists/engine-data/kyra.dat kyra.dat]<br />
<br />
'''''DOS Floppy (extracted/installed)'''''<br />
* &#42;.PAK<br />
*[https://github.com/scummvm/scummvm/raw/master/dists/engine-data/kyra.dat kyra.dat]<br />
<br />
'''''DOS/WIN CD'''''<br />
<br />
The files should be located in the HOF_CD folder.<br />
* &#42;.PAK<br />
* &#42;.TLK<br />
* FILEDATA.FDT<br />
*[https://github.com/scummvm/scummvm/raw/master/dists/engine-data/kyra.dat kyra.dat]<br />
<br />
'''''FM-TOWNS&#42;&#42;'''''<br />
* &#42;.PAK<br />
*[https://github.com/scummvm/scummvm/raw/master/dists/engine-data/kyra.dat kyra.dat]<br />
<br />
==Legend of Kyrandia, The: Malcolm's Revenge==<br />
'''''DOS'''''<br />
<br />
The HOF_CD directory contains a demo of the previous game, do not copy the files from there.<br />
*&#42;.PAK<br />
*&#42;.TLK<br />
*&#42;0.VQA<br />
*&#42;.AUD<br />
*FILEDATA.FDT<br />
*WESTWOOD.001<br />
*[https://github.com/scummvm/scummvm/raw/master/dists/engine-data/kyra.dat kyra.dat]<br />
<br />
'''''Macintosh'''''<br />
*&#42;.PAK<br />
*&#42;.TLK<br />
*&#42;0.VQA<br />
*&#42;.AUD<br />
*FILEDATA.FDT<br />
*[https://github.com/scummvm/scummvm/raw/master/dists/engine-data/kyra.dat kyra.dat]<br />
<br />
==Let's Explore the Airport with Buzzy==<br />
'''''Windows Demo'''''<br />
*AIRDEMO.HE0<br />
*AIRDEMO.HE1<br />
*AIRDEMO.HE2<br />
*AIRDEMO.HE3<br />
*AIRDEMO.HE4<br />
*AIRDEMO.HE9<br />
'''''Windows'''''<br />
*AIRPORT.HE0<br />
*AIRPORT.HE1<br />
*AIRPORT.HE2<br />
*AIRPORT.HE3<br />
*AIRPORT.HE4<br />
*AIRPORT.HE7<br />
*AIRPORT.HE9<br />
<br />
==Let's Explore the Farm with Buzzy==<br />
'''''Windows Demo'''''<br />
*FARMDEMO.HE0<br />
*FARMDEMO.HE1<br />
*FARMDEMO.HE2<br />
*FARMDEMO.HE3<br />
*FARMDEMO.HE4<br />
'''''Windows'''''<br />
*FARM.HE0<br />
*FARM.HE1<br />
*FARM.HE2<br />
*FARM.HE3<br />
*FARM.HE4<br />
*FARM.HE9<br />
<br />
==Let's Explore the Jungle with Buzzy==<br />
'''''Windows'''''<br />
*JUNGLE.HE0<br />
*JUNGLE.HE1<br />
*JUNGLE.HE2<br />
*JUNGLE.HE3<br />
*JUNGLE.HE4<br />
*JUNGLE.HE9<br />
<br />
==Living Books==<br />
* The book outline file, which can have various different names:<br />
** Windows v1: The .512 file, such as TORTOISE.512 or PAGES.512.<br />
** Windows v2: The .LB file, such as GREEN.LB or GREEN32.LB (either is fine).<br />
** Mac v1/v2: A text file named after the game, such as "The Tortoise and the Hare".<br />
** Otherwise: OUTLINE, OUTLINE.TXT or BookOutline.<br />
* The exe file or Mac application which goes with the outline.<br />
* All the files listed in the book outline (which is a text file) - normally this is the whole DATA directory.<br />
* SYSTEM.MHK (later v2/v3 games only).<br />
<br />
''Note: Some Macintosh versions of games use file or folder names containing forward slashes. If your system does not allow this, ScummVM will still recognize the files if you change them to underscores. E.g. instead of '''EnR/O''', use '''EnR_O'''.''<br />
<br />
==Loom==<br />
'''''Amiga, Atari ST, FM-TOWNS&#42;&#42;, PC EGA, PC Demo'''''<br />
*&#42;.LFL<br />
'''''PC CD&#42;&#42;'''''<br />
*DISK01.LEC<br />
*&#42;.LFL<br />
*Steam and GOG.com versions also have a CDDA.SOU file that is needed for speech.<br />
'''''Macintosh'''''<br />
*Loom&trade;<br />
**[[HOWTO-Mac_Games|A resource fork]]<br />
**The &trade; can be omitted from the file name<br />
*&#42;.LFL<br />
'''''TurboGrafx/PC Engine&#42;&#42;'''''<br />
*&#42;.LFL<br />
*&#42;pce.cdbios (Japanese version only)<br />
<br />
==Lost in Time==<br />
'''''DOS Floppy'''''<br />
<br />
''Note: This applies for Lost in Time Part 1 and Part 2.'' <br />
*&#42;.stk<br />
*&#42;.itk<br />
*&#42;.ltk (if existing)<br />
''Note: Several files of the DOS floppy version are only available after you have run the original installation program and installed Lost in Time to the harddisk.''<br />
<br />
'''''DOS CD&#42;&#42;'''''<br />
*&#42;.stk<br />
*&#42;.itk<br />
*&#42;.ltk<br />
*lost.lic<br />
'''''Windows'''''<br />
*&#42;.stk<br />
*&#42;.itk<br />
<br />
==Lure of the Temptress==<br />
'''''PC Floppy'''''<br />
*&#42;.vga<br />
*[https://github.com/scummvm/scummvm/raw/master/dists/engine-data/lure.dat lure.dat]<br />
<br />
==Manhole, The==<br />
'''''DOS EGA'''''<br />
*MANHOLE.DAT<br />
*&#42;.BLK<br />
'''''DOS VGA (New and Enhanced)**'''''<br />
*MANHOLE.DAT<br />
*MANHOLE.PRJ<br />
<br />
==Maniac Mansion (Original or Enhanced)==<br />
'''''Amiga, Atari ST, Macintosh, PC'''''<br />
*&#42;.LFL<br />
'''''Apple II'''''<br />
*Rename disk image 1 to maniac1.dsk.<br />
*Rename disk image 2 to maniac2.dsk.<br />
'''''Commodore 64'''''<br />
*Rename disk image 1 to maniac1.d64.<br />
*Rename disk image 2 to maniac2.d64.<br />
'''''NES'''''<br />
<br />
See [[User_Manual/Installing a game for use with ScummVM#Maniac Mansion NES|Maniac Mansion NES installation instructions]].<br />
<br />
==Monkey Island 2: LeChuck's Revenge==<br />
'''''Amiga'''''<br />
*amiga&#42;.ims<br />
*monkey2.000<br />
*monkey2.001<br />
*monkey2.002<br />
*monkey2.003<br />
*monkey2.004<br />
*monkey2.005<br />
*monkey2.006<br />
*monkey2.007<br />
*monkey2.008<br />
*monkey2.009<br />
*monkey2.010<br />
*monkey2.011<br />
'''''Macintosh'''''<br />
*MONKEY2.000<br />
*MONKEY2.001<br />
*iMuse Setups<br />
**[[HOWTO-Mac_Games|A resource fork]]<br />
'''''PC'''''<br />
*MONKEY2.000<br />
*MONKEY2.001<br />
'''''Demo'''''<br />
*DEMO.REC<br />
*MI2DEMO.000<br />
*MI2DEMO.001<br />
*MI2DEMO.002<br />
==Mortville Manor==<br />
'''''Dos'''''<br />
*AXX.MOR<br />
*AZZ.MOR<br />
*BMOR.MOR<br />
*BRUIT&#42;.<br />
*&#42;CFIEC.MOR<br />
*&#42;CFIPH.MOR<br />
*CHAI.MOR<br />
*CXX.MOR<br />
*DEC.MOR<br />
*DON.MOR<br />
*DXX.MOR<br />
*DZZ&#42;.MOR<br />
*FXX.MOR<br />
*MENU&#42;.MOR<br />
*MORT.&#42;<br />
*MORTP2<br />
*MXX.MOR<br />
*PHBRUI.MOR<br />
*PLXX.MOR<br />
*SA&#42;.MOR<br />
*SONMUS.MOR<br />
*TXX&#42;.&#42;<br />
<br />
==Myst==<br />
'''''Windows Demo'''''<br />
*CREDITS.DAT<br />
*DEMO.DAT<br />
*SLIDES.DAT<br />
*SNEAK.DAT<br />
*QTW folder<br />
<br />
'''''Windows'''''<br />
*CHANNEL.DAT<br />
*CREDITS.DAT<br />
*DUNNY.DAT<br />
*INTRO.DAT<br />
*MECHAN.DAT<br />
*MYST.DAT<br />
*SELEN.DAT<br />
*STONE.DAT<br />
*QTW folder<br />
<br />
'''''Windows Masterpiece Edition'''''<br />
*CHANNEL.DAT<br />
*CREDITS.DAT<br />
*DUNNY.DAT<br />
*Help.dat<br />
*INTRO.DAT<br />
*MECHAN.DAT<br />
*MYST.DAT<br />
*SELEN.DAT<br />
*STONE.DAT<br />
*QTW folder<br />
<br />
==Nippon Safes Inc.==<br />
'''''Amiga Demo'''''<br />
*disk0<br />
*fr<br />
*global.table<br />
*pointer <br />
'''''Amiga (Italian)'''''<br />
*disk0<br />
*global.table<br />
*it<br />
*pointer<br />
*Rename disk image 2 to disk1.<br />
*Rename disk image 3 to disk2.<br />
*Rename disk image 4 to disk3.<br />
*Rename disk image 5 to disk4.<br />
'''''Amiga (Multi-Lingual)'''''<br />
*disk0<br />
*en<br />
*fr<br />
*ge<br />
*global.table<br />
*pointer<br />
*Rename disk image 2 to disk1.<br />
*Rename disk image 3 to disk2.<br />
*Rename disk image 4 to disk3.<br />
*Rename disk image 5 to disk4.<br />
'''''DOS'''''<br />
*BOOGIE2.MID<br />
*COMICCNV.CNV<br />
*DINOHEAD.CNV<br />
*DINO.MID<br />
*DINOOBJ.CNV<br />
*DINOROBJ.CNV<br />
*DINO.TAB<br />
*DINOTAL.CNV<br />
*DISK1<br />
*DISK2<br />
*DISK3<br />
*DISK4<br />
*DONNAHEA.CNV<br />
*DONNA.MID<br />
*DONNAOBJ.CNV<br />
*DONNA.TAB<br />
*DONNATAL.CNV<br />
*DONNATRA.TAB<br />
*DONNATTA.CNV<br />
*DOUGHEA.CNV<br />
*DOUGHHEA.CNV<br />
*DOUGHOBJ.CNV<br />
*DOUGH.TAB<br />
*DOUGHTAL.CNV<br />
*DRKIHEAD.CNV<br />
*DRKIOBJ.CNV<br />
*DRKI.TAB<br />
*DRKITAL.CNV<br />
*EN<br />
*FR<br />
*GE<br />
*GLOBAL.TAB<br />
*INTRO.MID<br />
*IT<br />
*NUTS.MID<br />
*POINTER.CNV<br />
*SLIDECNV.CNV<br />
*SOFT.MID<br />
*TOPAZCNV.CNV<br />
<br />
==Operation Stealth==<br />
'''''Amiga, DOS (256 color)'''''<br />
*&#42;.DAT<br />
*&#42;.PAL ''(DOS)''<br />
*EGOUBASE<br />
*LABYBASE<br />
*PROC&#42;<br />
*SAMPLES&#42; ''(Amiga)''<br />
*SD&#42;<br />
*SINTRO2<br />
*VOL&#42;<br />
<br />
'''''DOS'''''<br />
*&#42;.DAT<br />
*EGOUBASE<br />
*LABYBASE<br />
*PROC&#42;<br />
*RSC&#42;<br />
*SON&#42;<br />
*VOL&#42;<br />
<br />
==Once Upon A Time: Little Red Riding Hood==<br />
'''''Atari ST, DOS, Windows'''''<br />
*&#42;.STK<br />
*&#42;.EXT (if existing)<br />
<br />
'''''Amiga'''''<br />
*&#42;.STK<br />
*MOD.BABAYAGA<br />
<br />
<br />
==Pajama Sam 1: No Need to Hide When It's Dark Outside==<br />
'''''Windows Demo'''''<br />
*PJS-DEMO.HE0<br />
*PJS-DEMO.HE1<br />
*PJS-DEMO.HE2<br />
*PJS-DEMO.HE4<br />
'''''Windows'''''<br />
*PAJAMA.HE0<br />
*PAJAMA.HE1<br />
*PAJAMA.HE2<br />
*PAJAMA.HE3<br />
*PAJAMA.HE4<br />
*PAJAMA.HE7<br />
<br />
==Pajama Sam 2: Thunder and Lightning Aren't so Frightening==<br />
'''''Windows Demo'''''<br />
*PJ2DEMO.HE0<br />
*PJ2DEMO.HE1<br />
*PJ2DEMO.HE2<br />
*PJ2DEMO.HE4<br />
'''''Windows'''''<br />
*PAJAMA2.HE0<br />
*PAJAMA2.HE1<br />
*PAJAMA2.HE2<br />
*PAJAMA2.HE4<br />
<br />
==Pajama Sam 3: You Are What You Eat From Your Head to Your Feet==<br />
'''''Windows Demo'''''<br />
*PJ3-DEMO.HE0<br />
*PJ3-DEMO.(A)<br />
*PJ3-DEMO.HE2<br />
*PJ3-DEMO.HE3<br />
'''''Windows'''''<br />
*PAJAMA3.HE0<br />
*PAJAMA3.(A)<br />
*PAJAMA3.HE2<br />
*PAJAMA3.HE4<br />
<br />
==Pajama Sam's Lost & Found==<br />
'''''Windows Demo'''''<br />
*data folder<br />
*SMALLER.HE0<br />
*SMALLER.(A)<br />
'''''Windows'''''<br />
*data folder<br />
*LOST.HE0<br />
*LOST.(A)<br />
*LOST.HE2<br />
<br />
==Pajama Sam's One-Stop Fun Shop==<br />
'''''Windows'''''<br />
*heidi folder<br />
*SamsFunShop.(a)<br />
*SamsFunShop.(b)<br />
*SamsFunShop.he0<br />
*SamsFunShop.he2<br />
*SamsFunShop.he4<br />
<br />
==Pajama Sam's Sock Works==<br />
'''''Windows'''''<br />
*SOCKS.HE0<br />
*SOCKS.HE1<br />
*SOCKS.HE2<br />
*SOCKS.HE4<br />
*SOCKS.HE7<br />
<br />
==Passport to Adventure==<br />
'''''Indy3, Loom and Monkey demos'''''<br />
*DISK01.LEC<br />
*&#42;.LFL<br />
<br />
==Personal Nightmare==<br />
'''''Amiga'''''<br />
*&#42;.IN<br />
*ICON.TMP<br />
*night.dbm<br />
*night.txt<br />
'''''Atari ST'''''<br />
*&#42;.IN<br />
*NIGHT.DBM<br />
*NIGHT.TXT<br />
*TEST.PRG<br />
'''''Atari ST Demo'''''<br />
*&#42;.IN<br />
'''''DOS'''''<br />
*&#42;.out<br />
*Night.dbm<br />
*Night.txt<br />
<br />
==Playtoons: Bambou le Sauveur de la Jungle==<br />
*intro.stk<br />
*bambou.itk<br />
<br />
==Putt-Putt & Fatty Bear's Activity Pack ==<br />
'''''DOS'''''<br />
*ACTIVITY.BRS<br />
*ACTIVITY.C&#42;<br />
*ACTIVITY.HE0<br />
*ACTIVITY.HE1<br />
*ACTIVITY.PAL<br />
*ACTIVITY.TAN<br />
*ACTIVITY.TLK<br />
'''''Macintosh'''''<br />
*Activity Pack BRS<br />
*Activity Pack C&#42;<br />
*Activity Pack PAL<br />
*Activity Pack TAN<br />
*Putt & Fatty's Actpack<br />
*Putt & Fatty's Actpack 0<br />
*Putt & Fatty's Actpack 1<br />
*Putt & Fatty's Actpack 2<br />
'''''Windows'''''<br />
*ACTIVITY.BRS<br />
*ACTIVITY.C&#42;<br />
*ACTIVITY.HE0<br />
*ACTIVITY.HE1<br />
*ACTIVITY.HE2<br />
*ACTIVITY.HE3<br />
*ACTIVITY.HE4<br />
*ACTIVITY.PAL<br />
*ACTIVITY.TAN<br />
<br />
==Putt-Putt and Pep's Balloon-O-Rama==<br />
'''''Windows'''''<br />
*balloon.HE0<br />
*BALLOON.HE1<br />
*BALLOON.HE2<br />
*BALLOON.HE3<br />
*BALLOON.HE4<br />
*BALLOON.HE8<br />
*BALLOON.HE9<br />
<br />
==Putt-Putt and Pep's Dog on a Stick==<br />
'''''Windows'''''<br />
*DOG.HE0<br />
*DOG.HE1<br />
*DOG.HE2<br />
*DOG.HE4<br />
*DOG.HE7<br />
*DOG.HE8<br />
<br />
==Putt-Putt Enters the Race==<br />
'''''Windows Demo'''''<br />
*RACEDEMO.HE0<br />
*RACEDEMO.(A)<br />
*RACEDEMO.HE2<br />
*RACEDEMO.HE4<br />
'''''Windows'''''<br />
*PUTTRACE.HE0<br />
*PUTTRACE.(A)<br />
*PUTTRACE.(B)<br />
*PUTTRACE.HE2<br />
*PUTTRACE.HE4<br />
<br />
==Putt-Putt Goes to the Moon==<br />
'''''3DO'''''<br />
*&#42;.DMU<br />
*PUTTMOON.BRS<br />
*PUTTMOON.HE0<br />
*PUTTMOON.HE1<br />
*PUTTMOON.TLK<br />
'''''DOS Demo'''''<br />
*moondemo.he0<br />
*moondemo.he1<br />
*moondemo.tlk<br />
'''''DOS'''''<br />
*PUTTMOON.BRS<br />
*PUTTMOON.HE0<br />
*PUTTMOON.HE1<br />
*PUTTMOON.TLK<br />
'''''Windows Demo'''''<br />
*MOONDEMO.HE0<br />
*MOONDEMO.HE1<br />
*MOONDEMO.HE2<br />
*MOONDEMO.HE3<br />
*MOONDEMO.HE4<br />
'''''Windows'''''<br />
*PUTTMOON.BRS<br />
*PUTTMOON.HE0<br />
*PUTTMOON.HE1<br />
*PUTTMOON.HE2<br />
*PUTTMOON.HE3<br />
*PUTTMOON.HE4<br />
<br />
==Putt-Putt Joins the Circus==<br />
'''''Windows Demo'''''<br />
*CIRCDEMO.HE0<br />
*CIRCDEMO.(A)<br />
*CIRCDEMO.HE2<br />
*CIRCDEMO.HE4<br />
'''''Windows'''''<br />
*PUTTCIRCUS.HE0<br />
*PUTTCIRCUS.(A)<br />
*PUTTCIRCUS.HE2<br />
*PUTTCIRCUS.HE4<br />
<br />
==Putt-Putt Joins the Parade==<br />
'''''3DO'''''<br />
*&#42;.DMU<br />
*PUTTPUTT.HE0<br />
*PUTTPUTT.HE1<br />
*PUTTPUTT.TLK<br />
'''''DOS Demo'''''<br />
*puttdemo.he0<br />
*puttdemo.he1<br />
*puttdemo.tlk<br />
'''''DOS'''''<br />
*PUTTPUTT.HE0<br />
*PUTTPUTT.HE1<br />
*PUTTPUTT.TLK<br />
'''''Windows Demo'''''<br />
*PUTTDEMO.HE0<br />
*PUTTDEMO.HE1<br />
*PUTTDEMO.HE2<br />
*PUTTDEMO.HE3<br />
*PUTTDEMO.HE4<br />
'''''Windows'''''<br />
*PUTTPUTT.HE0<br />
*PUTTPUTT.HE1<br />
*PUTTPUTT.HE2<br />
*PUTTPUTT.HE3<br />
*PUTTPUTT.HE4<br />
<br />
==Putt-Putt Saves the Zoo==<br />
'''''iOS'''''<br />
<br>''Note: Must be extracted from the .ipa file (which is just a standard zip file)''<br />
*game.(a)<br />
*game.he0<br />
*game.he2<br />
*game.he4<br />
'''''Windows Demo'''''<br />
*ZOODEMO.HE0<br />
*ZOODEMO.HE1<br />
*ZOODEMO.HE2<br />
*ZOODEMO.HE3<br />
*ZOODEMO.HE4<br />
'''''Windows'''''<br />
*PUTTZOO.HE0<br />
*PUTTZOO.HE1 or PUTTZOO.(A)<br />
*PUTTZOO.HE2<br />
*PUTTZOO.HE3<br />
*PUTTZOO.HE4<br />
<br />
==Putt-Putt's Fun Pack==<br />
'''''3DO'''''<br />
*&#42;.DMU<br />
*FUNPACK.HE0<br />
*FUNPACK.HE1<br />
*FUNPACK.TLK<br />
'''''DOS'''''<br />
*FUNPACK.HE0<br />
*FUNPACK.HE1<br />
*FUNPACK.TLK<br />
<br />
==Putt-Putt Travels Through Time==<br />
'''''Windows Demo'''''<br />
*TIMEDEMO.HE0<br />
*TIMEDEMO.HE1<br />
*TIMEDEMO.HE2<br />
*TIMEDEMO.HE3<br />
*TIMEDEMO.HE4<br />
'''''Windows'''''<br />
*PuttTTT.HE0<br />
*PuttTTT.HE1 or PuttTTT.(A)<br />
*PuttTTT.HE2<br />
*PuttTTT.HE4<br />
<br />
==Putt-Putt's One-Stop Fun Shop==<br />
'''''Windows'''''<br />
*heidi folder<br />
*PuttsFunShop.(a)<br />
*PuttsFunShop.(b)<br />
*PuttsFunShop.he0<br />
*PuttsFunShop.he2<br />
*PuttsFunShop.he4<br />
<br />
==Return to Zork==<br />
'''''DOS Floppy'''''<br />
*RTZ.DAT<br />
*RTZ.PRJ<br />
'''''DOS CD**'''''<br />
*RTZCD.RED or RTZCD.DAT<br />
*RTZCD.PRJ<br />
*&#42;.PMV<br />
<br />
Note: The GoG version can be used but you need to extract the files from the RTZ.gog disk image, which is a bit tricky (it is not a standard ISO). See the GoG.com forum for detailed instructions.<br />
<br />
'''''DOS Demo'''''<br />
*DEMO.DAT<br />
*DEMO.PRJ<br />
<br />
==Rex Nebular and the Cosmic Gender Bender==<br />
*&#42;.00?<br />
*&#42;.HAG<br />
*&#42;.RES<br />
*DIGITAL.ADA<br />
<br />
==Ringworld: Revenge of the Patriarch==<br />
*ring.rlb<br />
*tsage.rlb<br />
''Note: Files of the floppy version are only available after you have run the original installation program and installed Ringworld to the harddisk.''<br />
<br />
==Riven: The Sequel to Myst==<br />
<br />
'''''Macintosh/Windows 5CD'''''<br />
<br />
*a_Data.mhk<br />
*a_Sounds.mhk<br />
*b_Data.mhk<br />
*b_Data1.mhk ''(Optional, 1.02 patch file)''<br />
*b_Sounds.mhk<br />
*extras.mhk '''or''' arcriven.z<br />
*g_Data.mhk<br />
*g_Sounds.mhk<br />
*j_Data1.mhk<br />
*j_Data2.mhk<br />
*j_Data3.mhk ''(Optional, 1.02 patch file)''<br />
*j_Sounds.mhk<br />
*o_Data.mhk<br />
*o_Sounds.mhk<br />
*p_Data.mhk<br />
*p_Sounds.mhk<br />
*r_Data.mhk<br />
*r_Sounds.mhk<br />
*riven.exe '''or''' arcriven.z '''or''' Riven ''(Mac executable)''<br />
*t_Data.mhk<br />
*t_Sounds.mhk<br />
<br />
'''''Macintosh/Windows DVD'''''<br />
<br />
*a_Data.mhk<br />
*a_Sounds.mhk<br />
*b_Data.mhk<br />
*b_Sounds.mhk<br />
*extras.mhk '''or''' arcriven.z<br />
*g_Data.mhk<br />
*g_Sounds.mhk<br />
*j_Data1.mhk<br />
*j_Data2.mhk<br />
*j_Sounds.mhk<br />
*o_Data.mhk<br />
*o_Sounds.mhk<br />
*p_Data.mhk<br />
*p_Sounds.mhk<br />
*r_Data.mhk<br />
*r_Sounds.mhk<br />
*riven.exe '''or''' arcriven.z '''or''' Riven ''(Mac executable)''<br />
*t_Data1.mhk<br />
*t_Data2.mhk<br />
*t_Sounds.mhk<br />
<br />
'''''Windows Demo'''''<br />
<br />
*a_Data.mhk<br />
*a_Sounds.mhk<br />
*extras.mhk '''or''' arcriven.z<br />
*j_Data.mhk<br />
*j_Sounds.mhk<br />
*rivendmo.exe '''or''' arcriven.z<br />
*t_Data.mhk<br />
*t_Sounds.mhk<br />
<br />
'''''Note'''''<br />
<br />
The '''[a,b,g,j,o,p,r,t]_Sounds.mhk''' files may be present twice on game media. Either version can be used, but the largest files (from the '''assets1''' directory) are recommended as they are encoded with a higher audio quality.<br />
<br />
==Rodney's Funscreen==<br />
*RODNEYS.DAT<br />
*RODNEYS.PRJ<br />
<br />
==Sam &amp; Max Hit the Road==<br />
'''''Macintosh CD'''''<br />
*Sam & Max Data<br />
'''''Macintosh Demo'''''<br />
*Sam & Max Demo Data<br />
'''''PC Floppy'''''<br />
*MONSTER.SOU<br />
*SAMNMAX.SM0<br />
*SAMNMAX.SM1<br />
'''''PC CD'''''<br />
*MONSTER.SOU<br />
*SAMNMAX.000<br />
*SAMNMAX.001<br />
'''''PC Demo'''''<br />
*samdemo.000<br />
*samdemo.001<br />
<br />
==SCI==<br />
This covers all [[SCI]] games from Sierra (like later King's Quest, Larry, Space Quest, ...) but also [[SCI/Fan Games|fan made]] ones.<br />
<br />
WARNING: Unlike other games, SCI games have significant variation in the naming of required files.<br> They also can load supplementary files by resource maps, so it is recommended to keep all files in the game data directory from the CD.<br> Unless otherwise specified, do '''NOT''' remove any file from the directory, even if it does not appear on the following list, since this will likely cause weird bugs:<br />
<br />
===All SCI16 ([[Sierra_Game_Versions#SCI0_.28early.29|SCI0/1]]) games===<br />
<br />
* Copy all files to the game directory. Some games need additional work:<br />
<br />
'''''Floppy games with RESOURCE.p01, p02, etc. and/or RESOURCE.a01, a02, etc. files'''''<br />
<br />
* Concatenate all RESOURCE.p0* files to RESOURCE.000 (e.g. <tt>copy /b RESOURCE.p0* RESOURCE.000</tt> on Windows, or <tt>cat RESOURCE.p0* > RESOURCE.000</tt> on *nix).<br />
* Concatenate all RESOURCE.a0* files to RESOURCE.AUD (e.g. <tt>copy /b RESOURCE.a0* RESOURCE.AUD</tt> on Windows, or <tt>cat RESOURCE.a0* > RESOURCE.AUD</tt> on *nix).<br />
<br />
===All SCI32 ([[Sierra_Game_Versions#SCI2|SCI2/3]]) games===<br />
<br />
* Copy all files from each disk or CD to the game directory. Some games need additional work:<br />
<br />
'''''Games with multiple CDs'''''<br />
<br />
* Directories that exist on multiple discs (e.g. ROBOT and VMD directories) must be merged together, not replaced.<br />
* Rename the RESOURCE.SFX from each CD to RESSFX.00<cdnumber>, and the RESOURCE.AUD from each CD to RESAUD.00<cdnumber>, to match the corresponding RESSCI.00<cdnumber> file that exists on each CD.<br />
* It should be safe to replace any other files from later CDs that were copied already from earlier CDs, except in Phantasmagoria 1 (see below).<br />
<br />
'''''Gabriel Knight 1 from GOG.com'''''<br />
<br />
Rename GK1.GOG to GK1.ISO, mount the ISO, and copy the files from the ISO in the normal manner.<br />
<br />
'''''Leisure Suit Larry 6 hires'''''<br />
<br />
* If your game comes with a HIRES directory, copy all files from the HIRES directory to the game directory, then copy all files from the AUD and SFX directories to the game directory.<br />
<br />
'''''Phantasmagoria 1 from CDs'''''<br />
<br />
* Copy the PDOCO.TXT from the ''first'' CD only.<br />
<br />
'''''Police Quest 4 from GOG.com'''''<br />
<br />
Rename PQ4.gog to PQ4.ISO, mount the ISO, and copy the files from the ISO in the normal manner.<br />
<br />
==Secret of Monkey Island, The==<br />
'''''Amiga or Amiga demo'''''<br />
*&#42;.LEC<br />
*&#42;.LFL<br />
*music.dat<br />
*sample.dat<br />
'''''Atari ST, PC EGA Floppy, PC VGA Floppy or PC Demo'''''<br />
*&#42;.LEC<br />
*&#42;.LFL<br />
'''''PC VGA CD&#42;&#42;'''''<br />
*MONKEY.000<br />
*MONKEY.001<br />
'''''Alternative PC VGA CD&#42;&#42;'''''<br />
*MONKEY1.000<br />
*MONKEY1.001<br />
'''''Macintosh'''''<br />
*Monkey Island<br />
**[[HOWTO-Mac_Games|A resource fork]]<br />
*MONKEY1.000<br />
*MONKEY1.001<br />
'''''Alternative Macintosh'''''<br />
*Monkey Island<br />
**[[HOWTO-Mac_Games|A resource fork]]<br />
*MONKEY1.000<br />
*MONKEY1.001<br />
*MONKEY1.002<br />
*MONKEY1.003<br />
*MONKEY1.004<br />
*MONKEY1.005<br />
<br />
==Simon the Sorcerer==<br />
'''''Acorn CD or Acorn CD demo'''''<br />
*DATA<br />
*EFFECTS<br />
*GAMEBASE<br />
*ICONDATA<br />
*SIMON<br />
*STRIPPED<br />
*TBLLIST<br />
'''''Acorn Floppy'''''<br />
*&#42;.dat<br />
'''''Amiga Floppy'''''<br />
*&#42;tune<br />
*&#42;.pkd<br />
*gameamiga<br />
*icon.pkd<br />
*stripped.txt<br />
*tables&#42;<br />
*tbllist<br />
*text&#42;<br />
'''''Amiga CD32'''''<br />
*&#42;Effects<br />
*&#42;simon<br />
*&#42;tune<br />
*&#42;.out<br />
*gameamiga<br />
*icon.pkd<br />
*stripped.txt<br />
*tables&#42;<br />
*tbllist<br />
*text&#42;<br />
'''''DOS Floppy Demo'''''<br />
*&#42;.VGA<br />
*GDEMO<br />
*ICON.DAT<br />
*MOD2.MUS<br />
*MUSIC.DRV<br />
*STRIPPED.TXT<br />
*TABLES&#42;<br />
*TBLLIST<br />
*TEXT&#42;<br />
'''''DOS Floppy'''''<br />
*&#42;.MUS<br />
*&#42;.VGA<br />
*GAMEPC<br />
*ICON.DAT<br />
*MT_FM.IBK<br />
*STRIPPED.TXT<br />
*TABLES&#42;<br />
*TBLLIST<br />
*TEXT&#42;<br />
'''''DOS CD or DOS CD Demo'''''<br />
*EFFECTS.VOC<br />
*GAMEPC<br />
*ICON.DAT<br />
*MT_FM.IBK<br />
*SIMON.GME<br />
*SIMON.VOC<br />
*STRIPPED.TXT<br />
*TBLLIST<br />
'''''Windows CD'''''<br />
*GAMEPC<br />
*ICON.DAT<br />
*SFX&#42;<br />
*SIMON.GME<br />
*SIMON.WAV<br />
*STRIPPED.TXT<br />
*TBLLIST<br />
<br />
==Simon the Sorcerer II: The Lion, the Wizard and the Wardrobe==<br />
'''''Amiga or Macintosh'''''<br />
*voices folder<br />
*gsptr30<br />
*icon.dat<br />
*Simon2.gme<br />
*simon2.dic<br />
*simon2.english<br />
*simon2.french<br />
*simon2.german<br />
*simon2.italian<br />
*stripped.txt<br />
*tbllist<br />
'''''DOS Floppy'''''<br />
*GAME32<br />
*ICON.DAT<br />
*MIDPAK.AD<br />
*SIMON2.GME<br />
*STRIPPED.TXT<br />
*TBLLIST<br />
'''''DOS CD or DOS CD Demo'''''<br />
*GSPTR30<br />
*ICON.DAT<br />
*MIDPAK.AD or SETUP.SHR<br />
*SIMON2.GME<br />
*SIMON2.VOC<br />
*STRIPPED.TXT<br />
*TBLLIST<br />
'''''Windows CD'''''<br />
*GSPTR30<br />
*ICON.DAT<br />
*SIMON2.GME<br />
*SIMON2.WAV<br />
*STRIPPED.TXT<br />
*TBLLIST<br />
<br />
==Simon the Sorcerer's Puzzle Pack==<br />
'''''Windows'''''<br />
*&#42;.vga<br />
*&#42;.wav<br />
*Gdimp<br />
*Gjumble<br />
*Gpuzzle<br />
*Gswampy<br />
*Music<br />
<br />
==Soltys==<br />
'''''DOS Registered and Freeware versions'''''<br />
*VOL.CAT<br />
*VOL.DAT<br />
<br />
==SPY Fox 1: Dry Cereal==<br />
'''''Windows Demo'''''<br />
*SPYFOX.HE0<br />
*SPYFOX.HE1<br />
*SPYFOX.HE2<br />
*SPYFOX.HE4<br />
'''''Windows'''''<br />
*SPYFOX.HE0<br />
*SPYFOX.HE1 or SPYFOX.(A)<br />
*SPYFOX.HE2<br />
*SPYFOX.HE4<br />
<br />
==SPY Fox 2: Some Assembly Required==<br />
'''''Windows Demo'''''<br />
*SF2-DEMO.HE0<br />
*SF2-DEMO.(A)<br />
*SF2-DEMO.he2<br />
*SF2-DEMO.HE4<br />
'''''Windows'''''<br />
*SPYFOX2.HE0<br />
*SPYFOX2.(A)<br />
*SPYFOX2.HE2<br />
*SPYFOX2.HE4<br />
*SPYFOX2.he9<br />
<br />
==SPY Fox 3: Operation Ozone==<br />
'''''Windows Demo'''''<br />
*SF3-DEMO.HE0<br />
*SF3-DEMO.(A)<br />
*SF3-DEMO.HE2<br />
*SF3-DEMO.HE3<br />
*SF3-DEMO.HE4<br />
'''''Windows'''''<br />
*SPYOZON.HE0<br />
*SPYOZON.(A)<br />
*SPYOZON.HE2<br />
*SPYOZON.HE3<br />
*SPYOZON.HE4<br />
<br />
==SPY Fox in Cheese Chase==<br />
'''''Windows'''''<br />
*Custom folder<br />
*Levels folder<br />
*CHASE.HE0<br />
*CHASE.HE1<br />
*CHASE.HE2<br />
*CHASE.HE4<br />
*CHASE.HE8<br />
*CHASE.HE9<br />
<br />
==SPY Fox in Hold the Mustard==<br />
'''''Macintosh'''''<br />
*images folder<br />
*map (i)<br />
**[[HOWTO-Mac_Games|A resource fork]]<br />
*Mustard (0)<br />
*Mustard (2)<br />
*Mustard (4)<br />
*Mustard (7)<br />
*Mustard (a)<br />
'''''Windows'''''<br />
*images folder<br />
*map.ini<br />
*MUSTARD.HE0<br />
*MUSTARD.(A)<br />
*MUSTARD.HE2<br />
*MUSTARD.HE4<br />
*MUSTARD.HE7<br />
<br />
==Starship Titanic==<br />
*Assets folder<br />
*newgame.st<br />
<br />
==TeenAgent==<br />
*&#42;.dat<br />
*&#42;.res<br />
<br />
==The Lost Files of Sherlock Holmes==<br />
For both the Case of the Serrated Scalpel and the Case of the Rose Tattoo.<br />
<br />
*chess.pth<br />
*journal.lbv<br />
*sample.&#42;<br />
*&#42;.dig<br />
*&#42;.lib<br />
*&#42;.mdi<br />
*&#42;.rlb<br />
*&#42;.rrm<br />
*&#42;.snd<br />
*&#42;.txt<br />
*&#42;.vgs<br />
<br />
==Toonstruck==<br />
<br />
* ACT1 folder<br />
* ACT2 folder<br />
* MISC folder<br />
<br />
==Touché: The Adventures of the Fifth Musketeer==<br />
*TOUCHE.DAT<br />
*OBJ<br />
*V&#42;<br />
<br />
==Troll's Tale==<br />
*troll.img<br />
==U.F.O.s / Gnap==<br />
*.AVI<br />
*.DAT<br />
*.EXE<br />
*.MID<br />
<br />
==Urban Runner==<br />
*&#42;.stk<br />
*&#42;.itk<br />
<br />
==Voyeur==<br />
*&#42;.voc<br />
*&#42;.rl2<br />
*&#42;.blt<br />
<br />
==Waxworks==<br />
'''''Amiga'''''<br />
*&#42;.OUT<br />
*&#42;.pkd<br />
*&#42;tune<br />
*gameamiga<br />
*icon.pkd<br />
*MENUS.DAT<br />
*start<br />
*stripped.txt<br />
*tables&#42;<br />
*tbllist<br />
*text&#42;<br />
*xtable&#42;<br />
*xtbllist<br />
'''''DOS'''''<br />
*&#42;.MUS<br />
*&#42;.VGA<br />
*GAMEPC<br />
*ICON.DAT<br />
*MENUS.DAT<br />
*MUSIC.DRV<br />
*ROOMS&#42;<br />
*ROOMSLST<br />
*START<br />
*STATELST<br />
*STRIPPED.TXT<br />
*TABLES&#42;<br />
*TBLLIST<br />
*TEXT&#42;<br />
*WAX.FXB<br />
*XTABLE&#42;<br />
*XTBLLIST<br />
<br />
==Ween: The Prophecy==<br />
'''''Amiga'''''<br />
*&#42;.dum<br />
*&#42;.ins<br />
*&#42;.stk<br />
'''''Atari ST'''''<br />
*&#42;.snd<br />
*&#42;.stk<br />
'''''DOS'''''<br />
*&#42;.stk<br />
''Note: Several files of the DOS floppy version are only available after you have run the original installation program and installed Ween to the harddisk.''<br />
<br />
==Zak McKracken and the Alien Mindbenders==<br />
'''''Amiga, Atari ST, FM-TOWNS&#42;&#42;, Mac, PC'''''<br />
*&#42;.LFL<br />
*The GOG.com version has *.MP3 files that are needed for music.<br />
'''''Commodore 64'''''<br />
*Rename disk image 1 to zak1.d64.<br />
*Rename disk image 2 to zak2.d64.<br />
<br />
==Zork Nemesis: The Forbidden Lands==<br />
'''''All versions'''''<br />
* Download the [https://releases.pagure.org/liberation-fonts/liberation-fonts-ttf-2.00.1.tar.gz Liberation(tm) fonts package] and unpack all the ttf files into your ScummVM extras directory<br />
** Alternatively, download the [https://ftp.gnu.org/gnu/freefont/freefont-ttf.zip GNU FreeFont TTF package] and unzip all the ttf files from the '''sfd''' directory into your ScummVM extras directory, though at the time of writing these fonts cause some text rendering issues<br />
* Download the [http://www.thezorklibrary.com/installguides/znpatch.zip subtitles patch] and unzip the '''addon''' directory into the game root directory<br />
'''''GoG version'''''<br />
* Use the GoG installer, no further file copying is needed<br />
'''''CD version'''''<br />
* Copy the following from the '''nemesis''' directory of CD1 into the game root directory:<br />
** The '''znemmx''' directory<br />
** The '''znemscr''' directory<br />
** nemesis.str<br />
* From CD1, copy the '''zassets''' directory into the game root directory<br />
* From CD2, copy the '''zassets''' directory into the game root directory, overwriting any duplicate files<br />
* From CD3, copy the '''zassets''' directory into the game root directory, overwriting any duplicate files<br />
'''''DVD version'''''<br />
* Copy the following from the '''nemesis''' directory into the game root directory:<br />
** The '''znemmx''' directory<br />
** The '''znemscr''' directory<br />
** nemesis.str<br />
** ''Note: You'll also need to move cursor.zfs from the zassets/global directory into the znemscr directory''<br />
* Copy the '''disc2''' directory into the game root directory<br />
* Copy the '''disc3''' directory into the game root directory<br />
* Copy the '''zassets''' directory into the game root directory<br />
<br />
==Zork: Grand Inquisitor==<br />
'''''All versions'''''<br />
* Download the [https://releases.pagure.org/liberation-fonts/liberation-fonts-ttf-2.00.1.tar.gz Liberation(tm) fonts package] and unpack all the ttf files into your ScummVM extras directory<br />
** Alternatively, download the [https://ftp.gnu.org/gnu/freefont/freefont-ttf.zip GNU FreeFont TTF package] and unzip all the ttf files from the '''sfd''' directory into your ScummVM extras directory, though at the time of writing these fonts cause some text rendering issues<br />
'''''GoG version'''''<br />
* Use the GoG installer, no further file copying is needed<br />
'''''CD version'''''<br />
* Copy the following from the '''zgi''' directory of CD1 into the game root directory:<br />
** The '''zgi_mx''' directory<br />
** cursor.zfs<br />
** death.zfs<br />
** inquis.str<br />
** inquis.zix<br />
** r.svr<br />
** scripts.zfs<br />
** subtitle.zfs<br />
* From CD1, copy the '''zassets1''' directory into the game root directory<br />
* From CD2, copy the '''zassets2''' directory into the game root directory<br />
* It's recommended to apply [http://www.thezorklibrary.com/installguides/Zpatch.exe patch 1.2], but you may have to install the game normally for that, as the patch has its own installer<br />
'''''DVD version'''''<br />
* Copy the following from the '''zgi_e''' directory into the game root directory:<br />
** The '''addon''' directory (game patch 1.2)<br />
** The '''zgi_mx''' directory<br />
** cursor.zfs<br />
** death.zfs<br />
** inquis.str<br />
** inquis.zix<br />
** r.svr<br />
** scripts.zfs<br />
** subtitle.zfs<br />
* Copy the '''eng_mpeg''' directory (hires MPEG2 video files) into the game root directory<br />
* Copy the '''zassetsc''' directory into the game root directory<br />
* Copy the '''zassetse''' directory into the game root directory</div>
BgK
https://wiki.scummvm.org/index.php?title=TODO&diff=24092
TODO
2017-12-06T19:41:06Z
<p>BgK: Remove some obsolete TODO items</p>
<hr />
<div>{{Infobox_TODO|<br />
taskname=Main TODO List|<br />
techcontact=The ScummVM Team|<br />
subsystem=Generic|<br />
}}<br />
<br />
Here is a list of things we consider doing in the future. Note that we don't promise to do any of these, nor when we will do them. It's just a list of what we hope to be able to do one day, and some items on the list really are more like ideas than real proposals, so take it with a grain of salt.<br />
<br />
If you want to dig in, this is the stuff where you might make the most useful contribution. Note that this list is never complete, and may be partially outdated, so just because you don't see something here doesn't mean it is not important.<br />
<br />
Before you start work on something, you should first talk to the team! Ideally ask on scummvm-devel, our mailing list. This will help us to prevent double work, i.e. several people working on the same stuff at once without knowing about each other. Furthermore, sometimes entries on our list are actually obsolete (because the feature has been implemented, or because for some reason we no longer think it to be desirable). Special caution should be taken for TODO entries that say "we may want to" or similar things; that usually means that we aren't sure whether we really want to implement that feature.<br />
<br />
'''So, to repeat it: Always talk to the team before implementing a change on this list, or else risk having your patch rejected :-/.'''<br />
<br />
Finally, always make sure to check out our bug tracker and our feature request tracker for things that need work.<br />
<br />
<br />
== Documentation ==<br />
<br />
See also the [[Documentation/TODO]] page.<br />
<br />
=== General ===<br />
* Add port specific user documentation (dreamcast/palm especially). That would include things like:<br />
** How to use ScummVM on system XYZ<br />
* Update/enhance man page<br />
* Write a high level overview of how ScummVM and its engines work?<br />
<br />
=== README / Manual ===<br />
* A proper manual might be nice.<br />
* Maybe move all/most of the compression related stuff from our README completely to the tools README, and only leave a pointer to that in the main README. This would be beneficial because this way, it's only documented in one place; it's *completly* documented (currently, the main README doesn't mention compress_scumm_bun, for example); and people who want to use the compression tools need to download the tools package anyway.<br />
* It would be greate to have a "Developer's Guide to ScummVM" which explains the ScummVM framework, and also the engines, i.e.<br />
** stuff in common/, like the config manager etc.<br />
** the backend API, and how to create new backends<br />
** the sound system<br />
** how to create a new engine<br />
** a chapter for each engine, with as many/little details as the resp. engine teams deem appropriate...<br />
** ...<br />
<br />
== Web sites ==<br />
<br />
=== Primary website ===<br />
* Add big (green?) shiny buttons in the middle of the page for (1) Donations and (2) Downloads ?<br />
* Show "Release Date" on download page<br />
* Change all screenshot filenames to match our rules as described [[Screenshots|here]]. E.g. rename <code>data/screenshots/agos/simon/scummvm_2_4_0.jpg</code> to <code>data/screenshots/agos/simon/simon-0.jpg</code> etc.; also some stuff should maybe be moved to other directories.<br />
<br />
=== [[Buildbot]] ===<br />
* Track the size of the resulting binaries.<br />
** This would greatly help in tracking down when and why the size of the ScummVM binary increased.<br />
** Doing this should not be hard. Setup a database which stores for each commit the size of the (stripped) binary of each port. <br />
** Then, add a way to query that database via a webfront. At first, simply dumping all the numbers would be good enough. On the long run, it would be nice to show some cool graphical diagrams.<br />
** For bonus points, allow the user of that webpage to dynamically change it using javascript: i.e. selecting which ports to show, which range of revisions; mousing over a data point shows a little box with details on the commit; clicking on a revision number jumps to the corresponding page in our SVN repository viewer; etc. ;).<br />
* Install the new required dependencies (libpng and libtheora for [[Sword25]]) into the cross compiler environments of all ports that have a chance of supporting [[Sword25]].<br />
* Install the new required dependencies (libpng, libfreetype, boost and wx-widgets) into the cross compiler environments of all desktop ports to support building of tools.<br />
<br />
=== [[Doxygen]] ===<br />
* <s>Create a visual theme which matches that of our forum and website</s><br />
<br />
=== [[Forums]] ===<br />
* Upgrade to phpBB 3. This receives security updated, and would provide many new handy features for users and admins alike. The main issue here is that somebody would have to rewrite our custom theme for that. Maybe we can hire somebody to do this?<br />
<br />
=== [[Planet]] ===<br />
* Improve the visual theme to better match that of the forum and website<br />
<br />
=== [[Wiki]] ===<br />
* <s>Create a visual theme which matches that of our forum and website</s><br />
* Add content to [[Special:Wantedpages|Wanted Pages]]<br />
* Add some content to [[Help:Editing]], which is shown when editing a page<br />
<br />
== Common code, infrastructure ==<br />
<br />
=== General ===<br />
* Revise the way "quit" is handled. Maybe add a global variable "g_quit" which we set when the application should be quit (e.g. when an EVENT_QUIT is received). This is useful if multiple levels of event loops have to be ended<br />
* Make some generic "EventLoop" API/class which all backends and the GUI use. Initially this would just call the backend poll_event() etc. methods. But eventually the EventLoop object(s) could be made by the backend. This may allow for more efficient CPU usage etc. The current event handling model essentially is polling: the engines run some kind of main loop, which, besides many other things, also polls and dispatches events. The idea is to turn this around: the event loop frequently gives the engine time to do these "other things".<br />
* Maybe add ways to modify the game configs via the command line. E.g. allow<br />
./scummvm --add new_target --path=/foo monkey2<br />
./scummvm --remove new_target<br />
* The following things should be put into namespaces:<br />
** MIDI related classes either to Audio, or a new "MIDI" namespace<br />
** backend specific stuff into ??? (maybe new namespace "Backends" ?) not sure about this one.<br />
* Get rid of getenv in as many places as possible. Ideally, we'd only use it to query HOME on Unix systems.<br />
<br />
==== Iterator handling ====<br />
* Implement proper reverse_iterators for Common::List. Our current implementation is the same as forward iterators, just that rbegin will return the last element instead of the first and there is no rend. Check [http://www.sgi.com/tech/stl/ReverseIterator.html SGI Documentation] for proper description of revese_iterator in the STL.<br />
<br />
=== Events ===<br />
<br />
==== Event struct ====<br />
The following is a (revision of) a former comment in <code>common/events.h</code>:<br />
<br />
Rework/document this structure. It should be made 100% clear which field<br />
is valid for which event type. Implementation wise, we might want to use<br />
the classic union-of-structs trick. It goes roughly like this:<br />
<source lang="cpp"><br />
struct BasicEvent {<br />
EventType type;<br />
};<br />
struct MouseMovedEvent : BasicEvent {<br />
Common::Point pos;<br />
};<br />
struct MouseButtonEvent : MouseMovedEvent {<br />
int button;<br />
};<br />
struct KeyEvent : BasicEvent {<br />
...<br />
};<br />
...<br />
union Event {<br />
EventType type;<br />
MouseMovedEvent mouse;<br />
MouseButtonEvent button;<br />
KeyEvent key;<br />
...<br />
};<br />
</source><br />
<br />
However, this approach is contrary to classic OO paradigms. Indeed, its<br />
major drawback is that all event types now must be POD data types, so<br />
e.g. they can't contain a Common::Point as member. Bad.<br />
<br />
An alternative approach would be a more OO like switch to multiple Event<br />
subclasses. This would, however, then require us to pass events around<br />
as pointers to object instances, and also would require introducing type<br />
casting in code using events. The passing around of pointers could be<br />
mitigated by using<br />
<source lang="cpp"><br />
typedef Common::SharedPtr<BasicEvent> Event<br />
</source><br />
or something like that. Yet this would mean increased overhead in all<br />
our code, yet the gain is unclear. In conclusion, we probably are best<br />
off by staying with the existing monolithic struct Event, we should just<br />
enhance its documentation.<br />
<br />
=== Build System ===<br />
* Add test(s) for backend usability in the configure script.<br />
* Add an install target to the Makefile - Copy binary, install manpage, add menu items, install README. See also patch #891909 (Gnome/KDE .desktop file)<br />
* Investigate whether switching to [http://www.cmake.org CMake] or [http://www.scons.org SCons] or some other cross platform configuration environment would work for us. Potential advantage: Less effort to maintain and extend the build system, automatic generation of various kinds of project files (Makefiles, and project files for MSVC, XCode, Eclipse, KDevelop ...). Potential drawback: Problems with the customized build systems of our various ports. However, the latter might actually be improved by using CMake or SCons -- hard to say without tests.<br />
<br />
=== Audio ===<br />
<br />
==== Mixer ====<br />
* Get the high quality resample code to work<br />
* Consider changing the mixer volume to use range 0-255, for sake of consistency (but at a slight loss of efficiency). Note that this requires changes in at least rate.cpp and mixer.cpp.<br />
* Some of our engines support the speech_mute / sfx_mute / music_mute options, but most don't. Almost all support the corresponding FOO_volume config keys. All engines use Mixer::setVolumeForSoundType to push those through to the mixer. I am wondering: Maybe it would make sense to remove Mixer::setVolumeForSoundType, and instead leave it up to the mixer to query the ConfigManager for the corresponding FOO_volume/_mute values? That way we'd ensure 100% identical behavior in all engines and actually simplify the code a bit... ? Not sure if this would work smoothly, it needs to be investigated.<br />
* the "isReady" code is irritating. Most engines ignore it anyway. It's primary purpose is to allow ScummVM to run even if not digitial audio out is available. A better solution would likely be to enforce that all backends always return a valid mixer. In the worst case, if a backend cannot produce audio output, it should still instantiate an Audio::MixerImpl, with some arbitrary sample rate (I recommend 22050 Hz), and a fake playback thread, which acts like an audio output callback but simply discards the generated audio data. (Note: It doesn't suffice to just throw away input data in Mixer::playInputStream, as this breaks with QueuingAudioStream).<br />
* document the semantics of sound handles and sound ids<br />
* Are there backends which could benefit from a 'custom' mixer? If so, what would be required to implement such a thing? Needs talking to porters<br />
<br />
==== CD ====<br />
* Consider extending the Audio CD Manager with WAV or VOC support (essentially, the WAV/VOC code would need to be enhanced by adding a factory function similar to that provided for the FLAC/Vorbis/MP3 streams).<br />
* add a "pause" feature to the AudioCDManager (might require us to extend the OSystem CD API, too). Useful to be able to fully pause the currently running engine<br />
<br />
==== MIDI ====<br />
* See also [[Music drivers redesign]]<br />
* MIDI: Add API to OSystem which allows client code to query for "native" MIDI drivers (like Windows, ALSA, Zodiac, CoreAudio). Then change the MIDI interfacing code (GUI, command line, config file, etc.) and also MidiDriver::createMidi() to use both that list and the list of 'emulated' MIDI devices (AdLib, MT-32, PC Speaker, etc.) in an appropriate way.<br />
* Make it possible to pass options to the midi/music drivers. This would allow us to get rid of the getenv hacks in the alsa & seq drivers.<br />
**A simple approach would be to allow the user to specify "extended" driver descriptions. E.g. "alsa:1234" could indicate the alsa driver with port 1234; alternatively, "alsa:port=1234".<br />
**This doesn't allow for easy tweaking of those settings via the GUI.... to achieve that, one approach would be to invent a 'parameter description language' which allows a driver to specify which options with which kind of values it supports... very flexible, but possibly overkill.<br />
**Instead, one could add a hook method to MIDI drivers that let's them add a few controls of their own to the options dialog. This is probably a lot easier to implement, though not quite as "clean"...<br />
* Our XMIDI parser seems to have a couple of missing features, but it's unclear which ones are actually needed. Possible references for a better implementation include the [http://exult.sf.net Exult] project and the [http://www.thegleam.com/ke5fx/ source code for AIL Version 2]. The KYRA engine contains some more complete XMIDI implementation on top of our XMIDI parser class too, so it might also be a place to look at for reference.<br />
<br />
=== Config Manager ===<br />
* Modify the ConfigManager to make use of the ConfigFile class. This is more difficult than it sounds at first, because currently our ConfigManager is not just used for managing the active config, but also ab-used for editing config data (once for specific targets, in the launcher's "edit game" dialog, and once for editing the "active config" in the engines/dialog.cpp ConfigDialog). This mess needs to be untangled first.<br />
* Maybe even follow the pentagram (http://pentagram.sf.net) approach and have three classes:<br />
** SettingsManager (like our current ConfigManager)<br />
** ConfigFileManager (manages a set of config files, possibly merging the data from multiple config files)<br />
** ConfigFile (a simple .ini file accessor).<br />
*: This makes it easy to add additional config sources (e.g. XMLConfigFile); makes it possible to treat the command line data like another config file (CommandLineConfig); and simply follows the good old MVC approach, which is always a good idea.<br />
* Add a proper version to the Config file, which indicates true changes in the format / data in it. Right now, we only have a "fake" version number where any ScummVM instance will just write its version in. Which is totally useless. A proper version would allow us to ...<br />
** ... produce a warning if an older ScummVM version tries to load a config file written by a newer version with potentially incompatible changes (such as the switch from language code "hb" to "he" for Hebrew)<br />
** ... detect when we an old config file is loaded which needs to be updated (e.g. by changing language "hb" to "he"; by adding "guioptions" to targets; by fixing trailing slashes in "path"; maybe even updating old style; and maybe in the future by adding "engineid" fields to all targets)<br />
<br />
=== Files ===<br />
* Don't rely on the existence of SEEK_CUR, SEEK_END, SEEK_SET -- rather, define our own enum for this and convert all client code to use it.<br />
* Try to replace all usages of paths by FilesystemNode.<br />
<br />
=== GUI ===<br />
* [[GUI Themes/TODO|GUI TODO]]<br />
<br />
=== Plugins ===<br />
* On OSX: Support a plugin build in the bundle target: *.plugin files should be put into ScummVM.app/Contents/PlugIns/; this also means that the loader needs to search in the plugin dir of the active bundle. So use the CF bundle API, inside a #ifdef MACOSX block.<br />
* Make DetectedGame::updateDesc a normal function, not a member function.<br />
<br />
=== Launcher ===<br />
* Enhance the Mass detector to show a list with the results (and optionally, allow the user to edit/cull that list before adding it).<br />
* Game edit dialog: Consider adding some warnings to the platform/language fields ("Don't mess with these unless you know what you are doing"), or move them to an "advanced" tab<br />
* Make the gameid editable via an "advanced" tab entry?<br />
* <s>There is no way to reset the save/extra/theme paths. Adding a tiny button labeled "c" for clearing them (like for the soundfont path button) is not the way to solve this, I think. One approach would be to extend the Browser dialog, to allow an (optional) extra button, with customizable label. When pressed, the browser dialog closes and returns a special code. Well, and we'd use labels like "Use default savepath" or "Reset extrapath", or just always "Use default value".</s><br />
* The global options dialog may show a button for configuring the savepath even on systems where it is fixed -> not good. This button should be hidden/removed for these systems<br />
* separate launcher code even more from rest of ScummVM, to make custom launchers easier?<br />
** maybe separate launcher using MVC approach? Separate code which scans for games etc. from the presentation layer, to make it easier to write custom launchers with behavior matching that of the default launcher?<br />
* show cover art in launcher<br />
** this would only be done on "high end" systems, must be possible to disable code<br />
** we can't ship artwork directly, due to copyright concerns; so only ship artwork where it is legally possible, and otherwise allow users to setup "artwork packs"<br />
** control what artwork is shown using a config key<br />
<br />
=== Global Main Menu/Return to Launcher ===<br />
* Confirm exit dialog woes:<br />
** Double "confirm exit" dialog: When confirm exit is enabled in ScummVM, the ScummVM quit confirm dialog shows up in addition to the quit confirm dialogs for those games which have their own. For example, when you select 'Quit' from Beneath a Steel Sky's in-game menu, it asks you if you really want to quit. Then, after answering, ScummVM gives you another dialog asking you if you really want to quit. So, ScummVM should not show the quit confirm dialog if the in-game dialog has already been displayed. This affects any game which has it's own menu system from where you can quit, or has a native quit confirm dialog. So this means most games.<br />
** Add/unify "confirm exit" dialog, globally (see [https://sourceforge.net/tracker/index.php?func=detail&aid=1731025&group_id=37116&atid=418823 FR #1731025])<br />
* Options Dialog: Implement engine flags to define which features in the Options dialog are supported by the current running game. Use these flags to hide/show the appropriate sliders and buttons in the Options Dialog<br />
* Allow engines to extend the GMM more freely. E.g. for the SCUMM engine, we would want to add a "Help" button. Alternatively, just always have a help button and only show/hide resp. en-/disable it as needed.<br />
* Improve the look of the GMM: This could include displaying the engine name and the ScummVM logo somewhere on the GMM.<br />
* Config Dialog code: Resolve the FIXME in engines/dialogs.cpp which pertains to having to use the empty string as the domain name. This is a bigger task, but will enable many other changes (thus as finally changing ConfigManager to use ConfigFile). Essentially, the current game config dialog tries to abuse the system by editing the *active* settings via the config manager, in order to fully reduce the options dialog code from the launcher. But there is a big difference between editing the config settings of a specific target, and the active settings. So, one probably needs to rewrite the code for the config dialog shown from the GMM<br />
* Make it possible to reach the "key remapper" and "virtual keyboard" from the GMM, if available?<br />
* Sugar on the cake: In addition to the ScummVM logo and version, how about showing the engine name and game title at the top of the GMM?<br />
<br />
=== Error handling ===<br />
<br />
Sometimes, bugs are reported that are not easily reproducible, e.g. [https://sourceforge.net/p/scummvm/bugs/6751/ Bug #6751]. In such cases, it would be useful to have the error handler in ScummVM generate (and, optionally, automatically send) minidumps that can be used by us to successfully examine crashed ScummVM processes. Integration of something like [https://chromium.googlesource.com/breakpad/breakpad/ Google Breakpad] is one reasonable option. While it is not likely to be able to get such crash handling into all ports, just supporting the most popular platforms would be enough to make this feature very useful.<br />
<br />
== Engines / frontends ==<br />
<br />
=== [[SCUMM]] ===<br />
* see [[SCUMM/TODO|SCUMM TODO]] list<br />
<br />
=== [[AGI]] ===<br />
* see [[AGI/TODO|AGI TODO]] list<br />
<br />
=== [[AGOS]] ===<br />
* see [[AGOS/Bugs|AGOS Bugs]] list<br />
* see [[AGOS/TODO|AGOS TODO]] list<br />
<br />
=== [[Cine]] ===<br />
* see [[Cine/TODO|Cine TODO]] list<br />
<br />
=== [[CruisE]] ===<br />
* see [[Cruise/TODO|CruisE TODO]] list<br />
<br />
=== [[Drascula]] ===<br />
* see [[Drascula/TODO|Drascula TODO]] list<br />
<br />
=== [[Gob]] ===<br />
* see [[Gob/TODO|Gob TODO]] list<br />
<br />
=== [[Groovie]] ===<br />
* see [[Groovie/TODO|Groovie TODO]] list<br />
<br />
=== [[Hopkins]] ===<br />
* see [[Hopkins/TODO|Hopkins TODO]] list<br />
<br />
=== [[Hugo]] ===<br />
* see [[Hugo/TODO|Hugo TODO]] list<br />
<br />
=== [[Kyra]] ===<br />
* see [[Kyra/TODO|Kyra TODO]] list<br />
<br />
=== [[Lastexpress]] ===<br />
* see [[Lastexpress/TODO|Lastexpress TODO]] list<br />
<br />
=== [[MADE]] ===<br />
* see [[MADE/TODO|MADE TODO]] list<br />
<br />
=== [[Mohawk]] ===<br />
* see [[Mohawk/TODO|Mohawk TODO]] list<br />
<br />
=== [[Parallaction]] ===<br />
* see [[Parallaction/TODO|Parallaction TODO]] list<br />
<br />
=== [[SAGA]] ===<br />
* see [[SAGA/TODO|SAGA TODO]] list<br />
<br />
=== [[SCI]] ===<br />
* see [[SCI/TODO|SCI TODO]] list<br />
<br />
=== [[Sword1|Broken Sword 1]] ===<br />
* Modify MoviePlayer class to use ManagedArray for _movieTexts.<br />
* Add support for Bink RDFT compressed audio in the Smacker videos (used in some later releases).<br />
<br />
=== [[Sword2|Broken Sword 2]] ===<br />
* Fix the credits so they look more like the original. (Did we ever get the source code for that?)<br />
* Maybe work around script bug which causes the mop to disappear briefly when trying to pick it up from the top of the boat at the London docks. (The event to hide the mop is sent too early.) {{Tracker|id=2058}}.<br />
* Maybe (but probably not) work around a graphics glitch where George can be drawn partially in front of a metal beam he's walking behind. (He's obscured properly by the beam sprite, but part of the beam is only background.) {{Tracker|id=4483}}.<br />
* Unify some of the code with Broken Sword 1 (e.g. in router.cpp).<br />
<br />
=== [[Sword25]] ===<br />
* see [[Sword25/TODO|Sword25 TODO]] list<br />
<br />
=== [[Tinsel]] ===<br />
* see [[Tinsel/TODO|Tinsel TODO]] list<br />
<br />
=== [[Tony]] ===<br />
* see [[Tony/TODO|Tony TODO]] list<br />
<br />
=== [[Toon]] ===<br />
* see [[Toon/TODO|Tooon TODO]] list<br />
<br />
=== [[Touche]] ===<br />
* see [[Touche/TODO|Touche TODO]] list<br />
<br />
=== [[TsAGE]] ===<br />
* see [[TsAGE/TODO|TsAGE TODO]] list<br />
<br />
=== [[Tucker]] ===<br />
* see [[Tucker/TODO|Tucker TODO]] list<br />
<br />
=== [[Wintermute]] ===<br />
* see [[Wintermute/TODO|Wintermute TODO]] list<br />
<br />
== Backends and ports ==<br />
<br />
=== General ===<br />
* Add API to query backend for a list of available music engines. Useful for Options dialog. See [[Music drivers redesign]].<br />
* Right now gBitFormat is part of common/scaler.cpp; we might want to move it to common/system.cpp, or replace it with something better. No hasty changes here, please, make sure you understand how it is used right now before messing with it ;-)<br />
<br />
=== SDL backend ===<br />
* Right now, the WinCE and the Symbian backend subclasses the regular SDL backend. They both overload a lot of methods (mostly the graphics stuff). Since graphics.cpp uses the scalers (e.g. hq3x), these derived backends carry that baggage around, too, even though they don't need that code. Idea: split the SDL backend into two classes, one base class which only has the code which is used by all subclasses; and a "desktop" subclass, which implements the rest. Then WinCE/Symbian would only subclass the "base" SDL class.<br />
<br />
=== Windows ===<br />
* Add scripting code for creating a Windows installer to our code repository, so that a full Windows release can be built easily and directly. Could be based on [http://nsis.sourceforge.net NSIS] or [http://wix.sourceforge.net WiX].<br />
<br />
== Tools ==<br />
<br />
=== General ===<br />
* Use doxygen (or something else) to turn the short descs from the README into short man pages AND a single text file (replacing README) and a HTML file...<br />
<br />
=== GUI ===<br />
* One of the GUI assistants pages shows the following text to the user: "Note: Some tools display file picker here, this should perhaps be changed to always be directory output, since often don't want to name the output file." Clearly this should *not* be shown to the user, but rather is something we devs need to address.<br />
* The last page of the assistant is weird. E.g. after successful run, it shows a "Finish" button in the lower right, and two checkboxes: "Open output folder" and "Process another file". This seems unintuitive and artificial to me. An IMHO better alternative would be to remove the "Finish" button, and instead show some big buttons with captions like "Process another file" (which does just that), "Open output folder", and "Quit". One can probably still do better, somebody should think about this.<br />
<br />
=== Compression tools ===<br />
* (Semi-)automatically provide showhelp function<br />
* Modify encodeAudio to accept "input streams", so that we can avoid creating temporary WAVE files<br />
* Improved error checking !!! esp. for FT we got several reports about problems caused by the compression tool being called from the wrong directory. This should be avoidable by implementing suitable checks.<br />
<br />
=== Descumm ===<br />
* Turn it into a library, to be used by a command line frontend (like now), ScummVM debugger, and ScummEX. Basically, the API could consist of a single function, which takes a pointer to a memory buffer, its length, the Scumm version and optionally a game id. Also, it would get a pointer to a print function (in the case of the CLI tool, print to stdout; for ScummVM, print to our GUI console; for ScummEX, append to some window/widget)<br />
* Rewrite code to use 2 passes; first pass builds an intermediate graph, the second pass then tries to detect loops, break/continue statements etc.<br />
* Proper implementation of o6_startObjectQuick decompilation (see comment in descumm6.c). May require rewrite of core program logic.</div>
BgK
https://wiki.scummvm.org/index.php?title=Riven:_The_Sequel_to_Myst&diff=23862
Riven: The Sequel to Myst
2017-07-31T18:02:27Z
<p>BgK: Add a screenshot</p>
<hr />
<div>{{GameDescription|<br />
name=Riven: The Sequel to Myst|<br />
image=http://www.scummvm.org/data/screenshots/other/riven/riven-win-en-03.jpg|<br />
release=1997|<br />
alternateNames=Riven|<br />
publisher=[[Brøderbund|Red Orb Entertainment]], [[Ubisoft]]|<br />
distributor=[[Ubisoft]]|<br />
developer=[[Cyan Worlds]]|<br />
platforms=Windows, Macintosh, Sega Saturn,<br>Sony PlayStation, Windows Mobile,<br>iOS|<br />
resolution=608x436, True Color|<br />
engine=[[Mohawk]]|<br />
support=Not officially supported. A WIP engine<br>for the Windows/Macintosh version is<br>available in our Git repository. All<br>other versions do not use Mohawk<br>and will never be supported.|<br />
purchase=[[Where to get the games#Other Games|Yes]]|<br />
}}<br />
<br />
'''Riven: The Sequel to Myst''' is, as the title says, the sequel to [[Myst]], and the second game in the [[Myst series]]. Continuing where the first game left off, Atrus asks you to go to Riven to rescue his wife Catherine and imprison his father Gehn. However, you soon run into complications when arriving on Riven.<br />
<br />
== External Links ==<br />
*[http://en.wikipedia.org/wiki/Riven Wikipedia article on Riven]<br />
*[http://www.mobygames.com/game/http://www.mobygames.com/game/riven-the-sequel-to-myst MobyGames article on Riven]<br />
<br />
[[Category:Mohawk Games]]<br />
[[Category:Unsupported Games]]</div>
BgK
https://wiki.scummvm.org/index.php?title=Myst&diff=23859
Myst
2017-07-30T10:32:58Z
<p>BgK: Added a screenshot</p>
<hr />
<div>{{GameDescription|<br />
name=Myst|<br />
image=https://www.scummvm.org/data/screenshots/other/myst/myst-win-de-03.jpg|<br />
release=1993|<br />
alternateNames=Myst Masterpiece Edition|<br />
publisher=[[Brøderbund]], [[Ubisoft]]|<br />
developer=[[Cyan Worlds]]|<br />
distributor=[[Brøderbund]], [[Ubisoft]]|<br />
platforms=Windows, Macintosh, Amiga, Atari Jaguar,<br>Sega Saturn, Sony PlayStation,<br>Windows Mobile, iOS, Philips CD-i, 3DO,<br>PlayStation Portable, Nintendo DS|<br />
resolution=544x332, 256 colors/True Color (MME)|<br />
engine=[[Mohawk]], HyperCard|<br />
support=Since 1.9.0<br />Only Myst and Myst: Masterpiece Edition are<br>supported. All other versions do not use<br>Mohawk and will never be supported.|<br />
purchase=[[Where to get the games#Other Games|Yes]]|<br />
}}<br />
<br />
'''Myst''' is the first game in the [[Myst series]]. It is one of the best selling PC games of all time and is the best selling adventure game of all time. You play as the Stranger who finds himself on a deserted island after placing his/her hand on the image of the island in a book. You must discover what happened to the island's inhabitants and hopefully find a way to the place that you came from.<br />
<br />
'''Myst Masterpiece Edition''' is a 1999 re-release of the original game with true color graphics and improved video quality.<br />
<br />
== Status ==<br />
<br />
The Windows version of Myst and Myst: Masterpiece Edition are completable in ScummVM, however, as they are newly added to ScummVM, these games could use more testing.<br />
<br />
== External Links ==<br />
*[http://en.wikipedia.org/wiki/Myst Wikipedia article on Myst]<br />
*[http://www.mobygames.com/game/myst MobyGames article on Myst]<br />
<br />
[[Category:Mohawk Games]]<br />
[[Category:Supported Games]]</div>
BgK
https://wiki.scummvm.org/index.php?title=Mohawk/TODO&diff=23838
Mohawk/TODO
2017-07-05T18:41:23Z
<p>BgK: Remove completed TODOs</p>
<hr />
<div>{{Infobox_TODO|<br />
taskname=Mohawk Engine TODO|<br />
techcontact=[[Mohawk]] Engine Team|<br />
subsystem=Engine|<br />
}}<br />
<br />
== Main Mohawk TODO ==<br />
=== Video ===<br />
* Some Cinepak frames have corruption.<br />
** The Myst linking book video on D'ni has a corrupted Cinepak frame (data-wise). Right now, we just skip that frame (and throw a warning). It looks like QuickTime does this too.<br />
** The CD (but ''not'' the DVD) version of Riven has at least two videos with a corrupt frame: the wood chipper (when power is directed elsewhere) and using the trap book before talking with Gehn (when not on Tay).<br />
* Myst's fortress rotation holo-simulator requires playing QT movies with edit lists backwards. For now this is hacked around in the Mechanical code so that the puzzle works properly.<br />
<br />
== Myst Status ==<br />
The game is completable to all four endings.<br />
<br />
=== Known issues ===<br />
* Myst ME 10th Anniversary Edition requires Sorenson Video 3 for the UbiSoft logo<br />
** Since SVQ3 is quite large (and based on h.264), we may suggest the user just take the video from the Macintosh portion of the disc, which is QTRLE<br />
* The help system is missing in Myst ME<br />
<br />
== Riven TODO ==<br />
=== Status ===<br />
The game first became completable with [https://github.com/scummvm/scummvm/commit/bb5db4a bb5db4a]. As of [https://github.com/scummvm/scummvm/commit/245b733 245b733], the game is completable with no prior knowledge.<br />
<br />
=== Main TODO ===<br />
* Cleanup hotspot debugging mode. The water effect and videos write over it.<br />
<br />
== Living Books TODO ==<br />
<br />
* Take another look at how rewinding is meant to work.<br />
* Implement fading between palettes.<br />
* Add fading between pages - do full preloading (including sound) and use the relevant cursors.<br />
* Implement the hardcoded mini-games in Green Eggs and Ham and Arthur's Reading Race.<br />
* Implement the rest of the scripting used in the later LB games, including variable saving/loading.<br />
* Handle the proxies and compiled scripts used in v4 (The Rugrats Adventure Game, Arthur's Computer Adventure). fuzzie has preliminary code for this.<br />
<br />
== CSTime TODO ==<br />
<br />
* Implement the intro/transition videos (HQ/time tunnel).<br />
* Draw the text on Carmen's notes.<br />
* Fix feature priorities.<br />
* Implement music, environmental sounds, the rest of the animation code.<br />
* Implement the Chronopedia.<br />
* Render the torch mask for case 1.<br />
* Support the other sound sync cues.<br />
* Implement cases 3-20.<br />
* A host of other things, no doubt.<br />
<br />
== Other Games TODO ==<br />
<br />
* They (mostly) all use QuickTime video. <br />
** The re-release of Zoombinis uses Bink Video!<br />
** Some Kid Pix games use Smacker (in tSMK resources)<br />
* Some educational games (e.g. Treehouse, Zoombini) use some TrueType fonts.</div>
BgK
https://wiki.scummvm.org/index.php?title=Myst&diff=22636
Myst
2016-04-03T10:31:24Z
<p>BgK: Sync the Myst resolution with the code</p>
<hr />
<div>{{GameDescription|<br />
name=Myst|<br />
image=|<br />
release=1993|<br />
alternateNames=Myst Masterpiece Edition|<br />
publisher=[[Brøderbund]], [[Ubisoft]]|<br />
developer=[[Cyan Worlds]]|<br />
platforms=Windows, Macintosh, Amiga, Atari Jaguar,<br>Sega Saturn, Sony PlayStation, Windows Mobile,<br>iOS, Philips CD-i, 3DO, PlayStation Portable,<br>Nintendo DS|<br />
resolution=544x332, 256 colors/True Color (MME)|<br />
engine=[[Mohawk]], HyperCard|<br />
support=Not officially supported. A WIP engine for the<br>Windows version (and Windows versions of<br>Masterpiece Edition) is available in our git<br>repository. All other versions do not use Mohawk<br>and will never be supported.|<br />
purchase=[[Where to get the games#Other Games|Yes]]|<br />
}}<br />
<br />
'''Myst''' is one of the best selling PC games of all time and the best selling adventure game of all time. You play as the Stranger who finds himself on a deserted island after placing his/her hand on the image of the island in a book. You must discover what happened to the island's inhabitants and hopefully find a way to the place that you came from.<br />
<br />
'''Myst Masterpiece Edition''' is a 1999 re-release of the original game with true color graphics and improved video quality.<br />
<br />
== External Links ==<br />
*[http://en.wikipedia.org/wiki/Myst Wikipedia article on Myst]<br />
*[http://www.mobygames.com/game/myst MobyGames article on Myst]<br />
<br />
[[Category:Mohawk Games]]<br />
[[Category:Unsupported Games]]</div>
BgK
https://wiki.scummvm.org/index.php?title=Mohawk/TODO&diff=22497
Mohawk/TODO
2016-03-05T20:03:51Z
<p>BgK: Update Myst TODO</p>
<hr />
<div>{{Infobox_TODO|<br />
taskname=Mohawk Engine TODO|<br />
techcontact=[[Mohawk]] Engine Team|<br />
subsystem=Engine|<br />
}}<br />
<br />
== Main Mohawk TODO ==<br />
=== Video ===<br />
* Some Cinepak frames have corruption.<br />
** The Myst linking book video on D'ni has a corrupted Cinepak frame (data-wise). Right now, we just skip that frame (and throw a warning). It looks like QuickTime does this too.<br />
** The CD (but ''not'' the DVD) version of Riven has at least two videos with a corrupt frame: the wood chipper (when power is directed elsewhere) and using the trap book before talking with Gehn (when not on Tay).<br />
* Myst's fortress rotation holo-simulator requires playing QT movies with edit lists backwards. For now this is hacked around in the Mechanical code so that the puzzle works properly.<br />
<br />
== Myst Status ==<br />
The game is completable to all four endings.<br />
<br />
=== Known issues ===<br />
* Myst ME 10th Anniversary Edition requires Sorenson Video 3 for the UbiSoft logo<br />
** Since SVQ3 is quite large (and based on h.264), we may suggest the user just take the video from the Macintosh portion of the disc, which is QTRLE<br />
* The help system is missing in Myst ME<br />
<br />
== Riven TODO ==<br />
=== Status ===<br />
The game first became completable with [https://github.com/scummvm/scummvm/commit/bb5db4a bb5db4a]. As of [https://github.com/scummvm/scummvm/commit/245b733 245b733], the game is completable with no prior knowledge.<br />
<br />
=== Main TODO ===<br />
(In Order of Priority):<br />
* Finish External Commands (Many are done, most are self-explanatory)<br />
* Transitions<br />
* Finish ambient sound handling: Only fading is left<br />
* Cleanup video handling<br />
** We should emulate the QuickTime overlay, without doing so causes a couple glitches:<br />
*** Rarely before a video, the screen that should be shown after the video flashes before the video starts (for example: opening the linking book in the Rebel tunnel puzzle).<br />
*** Rarely after a video, the engine does not update with the correct screen. As far as I can tell, this ''only'' affects the easter egg videos on gspit and ospit under normal conditions. However, it can be noticed when skipping a video on occasion.<br />
**** We should also be showing the last frame when skipping<br />
*** In one instance, the lower staircase with the sunners, the water effect can overwrite the video.<br />
* Cleanup hotspot debugging mode. The water effect and videos write over it.<br />
<br />
=== Stack TODO/Known Bugs ===<br />
<br />
==== gspit ====<br />
* The underwater viewer is partially implemented.<br />
** xgwharksnd needs to be implemented.<br />
** Has hardcoded background sounds.<br />
<br />
==== tspit ====<br />
* Marbles not drawn on grid when standing one step back from the marble puzzle<br />
** xt7600_setupmarbles needs to be completed.<br />
<br />
== Living Books TODO ==<br />
<br />
* Take another look at how rewinding is meant to work.<br />
* Implement fading between palettes.<br />
* Add fading between pages - do full preloading (including sound) and use the relevant cursors.<br />
* Implement the hardcoded mini-games in Green Eggs and Ham and Arthur's Reading Race.<br />
* Implement the rest of the scripting used in the later LB games, including variable saving/loading.<br />
* Handle the proxies and compiled scripts used in v4 (The Rugrats Adventure Game, Arthur's Computer Adventure). fuzzie has preliminary code for this.<br />
<br />
== CSTime TODO ==<br />
<br />
* Implement the intro/transition videos (HQ/time tunnel).<br />
* Draw the text on Carmen's notes.<br />
* Fix feature priorities.<br />
* Implement music, environmental sounds, the rest of the animation code.<br />
* Implement the Chronopedia.<br />
* Render the torch mask for case 1.<br />
* Support the other sound sync cues.<br />
* Implement cases 3-20.<br />
* A host of other things, no doubt.<br />
<br />
== Other Games TODO ==<br />
<br />
* They (mostly) all use QuickTime video. <br />
** The re-release of Zoombinis uses Bink Video!<br />
** Some Kid Pix games use Smacker (in tSMK resources)<br />
* Some educational games (e.g. Treehouse, Zoombini) use some TrueType fonts.</div>
BgK
https://wiki.scummvm.org/index.php?title=PlayStation_3&diff=21934
PlayStation 3
2015-12-22T14:00:52Z
<p>BgK: Updates for the new SDL library</p>
<hr />
<div>{{PortFeatures|<br />
name=PlayStation 3|<br />
backend=sdl|<br />
version={{StableVersion}}|<br />
status=Maintained|<br />
mp3=yes|<br />
ogg=yes|<br />
flac=yes|<br />
uncompressed=yes|<br />
zlib=yes|<br />
plugins=no|<br />
16bits=yes|<br />
buildbot=yes|<br />
firstversion=1.4.0|<br />
maintainer=[[User:BgK|BgK]]|<br />
packager=[[User:BgK|BgK]]|<br />
pkgend=-ps3.zip|<br />
forum=10|<br />
icon=ps3|<br />
<br />
agi=yes|<br />
agos=yes|<br />
cine=yes|<br />
cruise=yes|<br />
draci=yes|<br />
drascula=yes|<br />
gob=yes|<br />
groovie=yes|<br />
kyra=yes|<br />
lure=yes|<br />
made=yes|<br />
parallaction=yes|<br />
queen=yes|<br />
saga=yes|<br />
scumm=yes|<br />
sky=yes|<br />
sword1=yes|<br />
sword2=yes|<br />
teenagent=yes|<br />
tinsel=yes|<br />
touche=yes|<br />
tucker=yes|<br />
}}<br />
<br />
== About ==<br />
ScummVM has been ported to the [[Sony]] PlayStation 3. All games are supported and *should* work, but they have not all been tested.<br />
<br />
== Prerequisites ==<br />
* A homebrew enabled PlayStation 3 console. As of now that mostly means having a custom firmware installed. Obtaining and installing such a software is out of the scope of this document. Sorry, but you're on your own for that one.<br />
* At least one ScummVM supported game. The list of compatible games can be seen here: http://www.scummvm.org/compatibility/<br />
The page http://wiki.scummvm.org/index.php/Where_to_get_the_games references some places where those games can be bought. Demonstration versions for most of the supported games are downloadable on http://scummvm.org/demos/<br />
* An USB drive.<br />
<br />
== Installing ==<br />
From a computer, download the installable package of the PS3 port from ScummVM's main site. It should be a .pkg file. Copy it to an USB drive.<br />
After having plugged the USB drive to you PS3, the installation package should appear in the XMB under the "Games > Install Package" menu. Installing it copies ScummVM and its dependencies to your PS3's hard drive. It also adds the "Games > PlayStation 3 > ScummVM" XMB entry which is to be used to launch ScummVM.<br />
<br />
== Configuring and playing games ==<br />
The user manual describes how to add games to ScummVM and launch them : http://wiki.scummvm.org/index.php/User_Manual<br />
<br />
== PlayStation 3 Specifics ==<br />
Games can be launched either from an USB drive or from the internal hard drive. The internal hard drive has better performance though.<br />
Savegames are wrote in the /hdd0/game/SCUM12000/saves folder.<br />
<br />
== Joypad button mapping ==<br />
{{PlayStation3Controls}}<br />
<br />
== Building from source ==<br />
This port of ScummVM to the PS3 is based on SDL2. It uses the open source SDK PSL1GHT.<br />
<br />
The dependencies needed to build it are :<br />
<br />
* The toolchain from https://github.com/ps3dev/ps3toolchain<br />
* SDL2 from https://bitbucket.org/bgK/sdl_psl1ght/branch/psl1ght-2.0.3<br />
* ScummVM from https://github.com/scummvm/scummvm<br />
<br />
Once all the dependencies are correctly setup, an installable package can be obtained from source by issuing the following command :<br />
<br />
./configure --host=ps3 && make ps3pkg</div>
BgK
https://wiki.scummvm.org/index.php?title=Code_Formatting_Conventions&diff=21932
Code Formatting Conventions
2015-12-21T17:44:11Z
<p>BgK: typo</p>
<hr />
<div>== Use common sense ==<br />
<br />
These are conventions which we try to follow when writing code for ScummVM. Sticking to a common set of formatting / indention rules makes it easier to read through our source base (which now exceed half a million lines of code by far, making this quite important). If you want to submit patches, please try to adhere to these rules.<br />
<br />
We don't always follow these rules slavishly, in certain cases it is OK (and in fact might be favorable) to stray from them. Applying common sense, as usual, is a good idea.<br />
<br />
In the following examples tabs are replaced by spaces for visual consistency with the Code Formatting Conventions. But in actual code, use tabs for indentations (our tabs are assumed to be 4 spaces wide).<br />
<br />
== Hugging braces ==<br />
<br />
Braces in your code should look like the following example:<br />
<br />
<syntax type="C++"><br />
for (int i = 0; i < t; i++) {<br />
[...]<br />
}<br />
<br />
if (j < k) {<br />
[...]<br />
} else if (j > k) {<br />
[...]<br />
} else {<br />
[...]<br />
}<br />
<br />
class Dummy {<br />
[...]<br />
};<br />
</syntax><br />
<br />
Did you see the {}'s on that?<br />
<br />
== Tab indents, with tabstop at four spaces ==<br />
<br />
Says it all, really.<br />
<br />
== Whitespaces ==<br />
<br />
'''Conventional operators surrounded by a space character'''<br />
<br />
<syntax type="C++"><br />
a = (b + c) * d;<br />
</syntax><br />
<br />
'''C++ reserved words separated from opening parentheses by a white space'''<br />
<br />
<syntax type="C++"><br />
while (true) {<br />
</syntax><br />
<br />
'''Commas followed by a white space'''<br />
<br />
<syntax type="C++"><br />
someFunction(a, b, c);<br />
</syntax><br />
<syntax type="C++"><br />
int d, e;<br />
</syntax><br />
<br />
'''Semicolons followed by a space character, if there is more on a line'''<br />
<br />
<syntax type="C++"><br />
for (int a = 0; b < c; d++)<br />
</syntax><br />
<syntax type="C++"><br />
doSomething(e); doSomething(f); // This is probably bad style anyway<br />
</syntax><br />
<br />
'''Semicolons preceded by a space character, if it ends an empty loop body'''<br />
<br />
It should also contain a comment to make it clear that the loop is intentionally empty.<br />
<syntax type="C++"><br />
while (i < length - 1 && array[++i] != item) ; // Look for index of item with an empty loop<br />
</syntax><br />
The following syntax is also acceptable:<br />
<syntax type="C++"><br />
while (i < length - 1 && array[++i] != item)<br />
; //this loop is intentionally empty<br />
</syntax><br />
<br />
'''When declaring class inheritance and in a ? construct, colons should be surrounded by white space'''<br />
<br />
<syntax type="C++"><br />
class BusWheel : public RubberInflatable {<br />
</syntax><br />
<syntax type="C++"><br />
(isNight) ? colorMeDark() : colorMeBright();<br />
</syntax><br />
<br />
'''Indentation level is not increased after namespace clause'''<br />
<br />
<syntax type="C++"><br />
namespace Scumm {<br />
<br />
byte Actor::kInvalidBox = 0;<br />
<br />
void Actor::initActorClass(ScummEngine *scumm) {<br />
_vm = scumm;<br />
}<br />
<br />
} // End of namespace Scumm<br />
</syntax><br />
<br />
'''Array delete operator has no whitespace before []'''<br />
<syntax type="C++"><br />
delete[] foo;<br />
</syntax><br />
<br />
'''Template definitions'''<br />
<br />
No whitespace between template keyword and <<br />
<syntax type="C++"><br />
template<typename foo><br />
void myFunc(foo arg) {<br />
// ...<br />
}<br />
</syntax><br />
<br />
'''Operator overloading'''<br />
<br />
Operator keyword is NOT separated from the name, except for type conversion operators where it is required.<br />
<syntax type="C++"><br />
struct Foo {<br />
void operator()() {<br />
// ...<br />
}<br />
<br />
operator bool() {<br />
return true;<br />
}<br />
};<br />
</syntax><br />
<br />
'''Pointers and casts'''<br />
<br />
No whitespace after a cast; and in a pointer, we write a whitespace before the star but not after it.<br />
<syntax type="C++"><br />
const char *ptr = (const char *)foobar;<br />
</syntax><br />
<br />
'''References'''<br />
<br />
We use the same rule for references as we do for pointers: use a whitespace before the "&" but not after it.<br />
<syntax type="C++"><br />
int i = 0;<br />
int &ref = i;<br />
</syntax><br />
<br />
== Switch/Case constructs ==<br />
<br />
<syntax type="C++"><br />
switch (cmd) {<br />
case kSomeCmd:<br />
someCmd();<br />
// Fall Through intended<br />
case kSomeVerySimilarCmd:<br />
someMoreCmd();<br />
break;<br />
case kSaveCmd:<br />
save();<br />
break;<br />
case kLoadCmd:<br />
case kPlayCmd:<br />
close();<br />
break;<br />
default:<br />
Dialog::handleCommand(sender, cmd, data);<br />
}<br />
</syntax><br />
* Note comment on whether fall through is intentional.<br />
<br />
== Naming ==<br />
<br />
'''Constants'''<br />
<br />
Basically, you have two choices (this has historical reasons, and we probably should try to unify this one day):<br />
<br />
# Camel case with prefix 'k': <pre> kSomeKludgyConstantName </pre ><br />
# All upper case, with words separated by underscores (no leading/trailing underscores): <pre>SOME_KLUDGY_CONSTANT_NAME</pre><br />
<br />
(As a side remark, we recommend avoiding #define for creating constants, because these can lead to weird and difficult to track down conflicts. Instead use enums or the <code>const</code> keyword.)<br />
<br />
'''Type names'''<br />
<br />
Camel case starting with upper case.<br />
<br />
<syntax type="C++"><br />
class MyClass { /* ... */ };<br />
struct MyStruct { /* ... */ };<br />
typedef int MyInt;<br />
</syntax><br />
<br />
'''Class member variables'''<br />
<br />
Prefixed with '_' and in camel case (Yo! no underscore separators), starting with lowercase.<br />
<br />
<syntax type="C++"><br />
char *_someVariableName;<br />
</syntax><br />
<br />
'''Class methods'''<br />
<br />
Camel case, starting with lowercase.<br />
<br />
<syntax type="C++"><br />
void thisIsMyFancyMethod();<br />
</syntax><br />
<br />
'''Local variables'''<br />
<br />
Use camel case (Yo! no underscore separators), starting with lowercase.<br />
<br />
<syntax type="C++"><br />
char *someVariableName;<br />
</syntax><br />
<br />
Note that for POD structures it is fine to use this rule too.<br />
<br />
'''Global variables'''<br />
<br />
In general you should avoid global variables, but if it can't be avoided, use 'g_' as prefix, camel case, and start with lowercase<br />
<br />
<syntax type="C++"><br />
int g_someGlobalVariable;<br />
</syntax><br />
<br />
== Special comments ==<br />
<br />
=== Special Keywords ===<br />
<br />
The following goes slightly beyond code formatting: We use certain keywords (together with an explanatory text) to mark certain sections of our code. In particular:<br />
* '''FIXME''' marks code that contains hacks or bad temporary workarounds, things that really should be revised at a later point.<br />
* '''TODO''' marks incomplete code, or things that could be done better but are left for the future.<br />
* '''WORKAROUND''' marks code that works around bugs in the original game, like script bugs. Sometimes these bugs worked in the original due to bugs in the original engine, sometimes the bug was visible in the original, too. It's important that you explain here what exactly you work around, and if applicable, refer to relevant tracker items!<br />
<br />
=== Doxygen documentation comments ===<br />
<br />
ScummVM uses the [http://www.doxygen.org/ Doxygen] software to generate HTML documentation for the codebase (available [http://doxygen.scummvm.org here]).<br />
<br />
Doxygen supports ''documentation blocks''. These are specially-formatted comments that doxygen prints out in the generated documentation. They are similar in purpose to Java's JavaDoc or Python's docstrings.<br />
<br />
There are many ways to mark such comments, but developers are encouraged to use the JavaDoc style:<br />
<br />
<syntax type="C++"><br />
/**<br />
* Move ("warp") the mouse cursor to the specified position in virtual<br />
* screen coordinates.<br />
* @param x the new x position of the mouse<br />
* @param y the new y position of the mouse<br />
*/<br />
virtual void warpMouse(int x, int y) = 0;<br />
</syntax><br />
(See [http://doxygen.scummvm.org/d9/df4/classOSystem.html#ecab84670def917107d6c1b5ca3b82c3 here] for the docs generated from this.)<br />
<br />
As shown in the example, documentation blocks also support several special commands such as '''param'''. Those are prefixed with either '''@''' or '''\''', but developers should always use '''@'''.<br />
<br />
If you want to add a brief explanation of a variable or function ''after'' its declaration, this is the correct syntax:<br />
<syntax type="C++"><br />
int16 x; ///< The horizontal part of the point<br />
int16 y; ///< The vertical part of the point<br />
</syntax><br />
(See [http://doxygen.scummvm.org/d7/d66/structCommon_1_1Point.html#2d868735aeaaf391ce9b3df9232c031f here] for the docs generated from this.)<br />
<br />
For more information, visit the official documentation:<br />
* [http://www.stack.nl/~dimitri/doxygen/docblocks.html Documentation blocks].<br />
* [http://www.stack.nl/~dimitri/doxygen/commands.html List of available commands].<br />
<br />
== Automatically converting code to our conventions ==<br />
The following settings for [http://astyle.sourceforge.net/ Artistic Style] (also known as astyle) approximate our code formatting conventions and can be used to quickly convert a big bunch of source files to our conventions. Note that you may still have to manually clean up some stuff afterwards.<br />
<pre><br />
indent=tab=4<br />
style=attach<br />
pad-oper<br />
pad-header<br />
align-pointer=name<br />
unpad-paren<br />
indent-preprocessor<br />
convert-tabs<br />
</pre><br />
<br />
=== Emacs style ===<br />
Put the following in your .emacsrc file<br />
<br />
<pre><br />
(setq-default default-tab-width 4)<br />
(setq-default c-basic-offset 4)<br />
(setq-default indent-tabs-mode t)<br />
</pre></div>
BgK
https://wiki.scummvm.org/index.php?title=Mohawk/TODO&diff=20129
Mohawk/TODO
2013-12-23T12:25:22Z
<p>BgK: we have libjpeg now</p>
<hr />
<div>{{Infobox_TODO|<br />
taskname=Mohawk Engine TODO|<br />
techcontact=[[Mohawk]] Engine Team|<br />
subsystem=Engine|<br />
}}<br />
<br />
== Main Mohawk TODO ==<br />
=== Video ===<br />
* Some Cinepak frames have corruption.<br />
** The Myst linking book video on D'ni has a corrupted Cinepak frame (data-wise). Right now, we just skip that frame (and throw a warning). It looks like QuickTime does this too.<br />
** The CD (but ''not'' the DVD) version of Riven has at least two videos with a corrupt frame: the wood chipper (when power is directed elsewhere) and using the trap book before talking with Gehn (when not on Tay).<br />
* Myst's fortress rotation holo-simulator requires playing QT movies with edit lists backwards.<br />
* The last frame of some QT movies is not displayed.<br />
<br />
== Myst TODO ==<br />
The game is playable and should be completable to all four endings, though many issues still need to be fixed.<br />
<br />
=== Main TODO ===<br />
* Myst ME 10th Anniversary Edition requires Sorenson Video 3 for the UbiSoft logo<br />
** Since SVQ3 is quite large (and based on h.264), we may suggest the user just take the video from the Macintosh portion of the disc, which is QTRLE<br />
* Add Help System (Myst ME only)<br />
<br />
=== Stack TODO/Known Bugs ===<br />
<br />
==== Mechanical ====<br />
* Fortress rotation holo-simulator not working properly<br />
** Requires playing QT movies with edit lists backwards. See [[Mohawk/TODO#Video|above]]<br />
<br />
== Riven TODO ==<br />
=== Status ===<br />
The game first became completable with [https://github.com/scummvm/scummvm/commit/bb5db4a bb5db4a]. As of [https://github.com/scummvm/scummvm/commit/245b733 245b733], the game is completable with no prior knowledge.<br />
<br />
=== Main TODO ===<br />
(In Order of Priority):<br />
* Finish External Commands (Many are done, most are self-explanatory)<br />
* Transitions<br />
* Finish ambient sound handling: Only fading is left<br />
* Cleanup video handling<br />
** We should emulate the QuickTime overlay, without doing so causes a couple glitches:<br />
*** Rarely before a video, the screen that should be shown after the video flashes before the video starts (for example: opening the linking book in the Rebel tunnel puzzle).<br />
*** Rarely after a video, the engine does not update with the correct screen. As far as I can tell, this ''only'' affects the easter egg videos on gspit and ospit under normal conditions. However, it can be noticed when skipping a video on occasion.<br />
**** We should also be showing the last frame when skipping<br />
*** In one instance, the lower staircase with the sunners, the water effect can overwrite the video.<br />
* Cleanup hotspot debugging mode. The water effect and videos write over it.<br />
<br />
=== Stack TODO/Known Bugs ===<br />
<br />
==== gspit ====<br />
* The underwater viewer is partially implemented.<br />
** xgwharksnd needs to be implemented.<br />
** Has hardcoded background sounds.<br />
<br />
==== tspit ====<br />
* Marbles not drawn on grid when standing one step back from the marble puzzle<br />
** xt7600_setupmarbles needs to be completed.<br />
<br />
== Living Books TODO ==<br />
<br />
* Take another look at how rewinding is meant to work.<br />
* Implement fading between palettes.<br />
* Add fading between pages - do full preloading (including sound) and use the relevant cursors.<br />
* Implement the hardcoded mini-games in Green Eggs and Ham and Arthur's Reading Race.<br />
* Implement the rest of the scripting used in the later LB games, including variable saving/loading.<br />
* Handle the proxies and compiled scripts used in v4 (The Rugrats Adventure Game, Arthur's Computer Adventure). fuzzie has preliminary code for this.<br />
<br />
== CSTime TODO ==<br />
<br />
* Implement the intro/transition videos (HQ/time tunnel).<br />
* Draw the text on Carmen's notes.<br />
* Fix feature priorities.<br />
* Implement music, environmental sounds, the rest of the animation code.<br />
* Implement the Chronopedia.<br />
* Render the torch mask for case 1.<br />
* Support the other sound sync cues.<br />
* Implement cases 3-20.<br />
* A host of other things, no doubt.<br />
<br />
== Other Games TODO ==<br />
<br />
* They (mostly) all use QuickTime video. <br />
** The re-release of Zoombinis uses Bink Video!<br />
** Some Kid Pix games use Smacker (in tSMK resources)<br />
* Some educational games (e.g. Treehouse, Zoombini) use some TrueType fonts.</div>
BgK
https://wiki.scummvm.org/index.php?title=Mohawk/TODO&diff=18397
Mohawk/TODO
2012-12-16T09:32:34Z
<p>BgK: Remove completed item</p>
<hr />
<div>{{Infobox_TODO|<br />
taskname=Mohawk Engine TODO|<br />
techcontact=[[Mohawk]] Engine Team|<br />
subsystem=Engine|<br />
}}<br />
<br />
== Main Mohawk TODO ==<br />
=== Video ===<br />
* Some Cinepak frames have corruption.<br />
** The Myst linking book video on D'ni has a corrupted Cinepak frame (data-wise). Right now, we just skip that frame (and throw a warning). It looks like QuickTime does this too.<br />
** The CD (but ''not'' the DVD) version of Riven has at least two videos with a corrupt frame: the wood chipper (when power is directed elsewhere) and using the trap book before talking with Gehn (when not on Tay).<br />
* Myst's fortress rotation holo-simulator requires playing QT movies with edit lists backwards.<br />
* The last frame of some QT movies is not displayed.<br />
<br />
== Myst TODO ==<br />
The game is playable and should be completable to all four endings, though many issues still need to be fixed.<br />
<br />
=== Main TODO ===<br />
* Myst ME 10th Anniversary Edition requires Sorenson Video 3 for the UbiSoft logo<br />
** Since SVQ3 is quite large (and based on h.264), we may suggest the user just take the video from the Macintosh portion of the disc, which is QTRLE<br />
* JPEG optimization for Myst ME<br />
* Improve SVQ1 color<br />
** The current 410 algorithm results in color being "blocky" -- should switch to using linear interpolation<br />
* Add Help System (Myst ME only)<br />
<br />
=== Stack TODO/Known Bugs ===<br />
<br />
==== Mechanical ====<br />
* Fortress rotation holo-simulator not working properly<br />
** Requires playing QT movies with edit lists backwards. See [[Mohawk/TODO#Video|above]]<br />
<br />
== Riven TODO ==<br />
=== Status ===<br />
The game first became completable with r52735. As of r55299, the game is completable with no prior knowledge.<br />
<br />
=== Main TODO ===<br />
(In Order of Priority):<br />
* Finish External Commands (Many are done, most are self-explanatory)<br />
* Transitions<br />
* Finish ambient sound handling: Only fading is left<br />
* Cleanup video handling<br />
** We should emulate the QuickTime overlay, without doing so causes a couple glitches:<br />
*** Rarely before a video, the screen that should be shown after the video flashes before the video starts (for example: opening the linking book in the Rebel tunnel puzzle).<br />
*** Rarely after a video, the engine does not update with the correct screen. As far as I can tell, this ''only'' affects the easter egg videos on gspit and ospit under normal conditions. However, it can be noticed when skipping a video on occasion.<br />
**** We should also be showing the last frame when skipping<br />
*** In one instance, the lower staircase with the sunners, the water effect can overwrite the video.<br />
* Cleanup hotspot debugging mode. The water effect and videos write over it.<br />
<br />
=== Stack TODO/Known Bugs ===<br />
<br />
==== gspit ====<br />
* The underwater viewer is partially implemented.<br />
** xgwharksnd needs to be implemented.<br />
** Has hardcoded background sounds.<br />
<br />
==== tspit ====<br />
* Marbles not drawn on grid when standing one step back from the marble puzzle<br />
** xt7600_setupmarbles needs to be completed.<br />
<br />
== Living Books TODO ==<br />
<br />
* Take another look at how rewinding is meant to work.<br />
* Implement fading between palettes.<br />
* Add fading between pages - do full preloading (including sound) and use the relevant cursors.<br />
* Implement the hardcoded mini-games in Green Eggs and Ham and Arthur's Reading Race.<br />
* Implement the rest of the scripting used in the later LB games, including variable saving/loading.<br />
* Handle the proxies and compiled scripts used in v4 (The Rugrats Adventure Game, Arthur's Computer Adventure). fuzzie has preliminary code for this.<br />
<br />
== CSTime TODO ==<br />
<br />
* Implement the intro/transition videos (HQ/time tunnel).<br />
* Draw the text on Carmen's notes.<br />
* Fix feature priorities.<br />
* Implement music, environmental sounds, the rest of the animation code.<br />
* Implement the Chronopedia.<br />
* Render the torch mask for case 1.<br />
* Support the other sound sync cues.<br />
* Implement cases 3-20.<br />
* A host of other things, no doubt.<br />
<br />
== Other Games TODO ==<br />
<br />
* They (mostly) all use QuickTime video. <br />
** The re-release of Zoombinis uses Bink Video!<br />
** Some Kid Pix games use Smacker (in tSMK resources)<br />
* Some educational games (e.g. Treehouse, Zoombini) use some TrueType fonts.</div>
BgK
https://wiki.scummvm.org/index.php?title=Mohawk/TODO&diff=18396
Mohawk/TODO
2012-12-16T06:15:14Z
<p>BgK: Update Myst TODO</p>
<hr />
<div>{{Infobox_TODO|<br />
taskname=Mohawk Engine TODO|<br />
techcontact=[[Mohawk]] Engine Team|<br />
subsystem=Engine|<br />
}}<br />
<br />
== Main Mohawk TODO ==<br />
=== Video ===<br />
* Some Cinepak frames have corruption.<br />
** The Myst linking book video on D'ni has a corrupted Cinepak frame (data-wise). Right now, we just skip that frame (and throw a warning). It looks like QuickTime does this too.<br />
** The CD (but ''not'' the DVD) version of Riven has at least two videos with a corrupt frame: the wood chipper (when power is directed elsewhere) and using the trap book before talking with Gehn (when not on Tay).<br />
* Myst's fortress rotation holo-simulator requires playing QT movies with edit lists backwards.<br />
* The last frame of some QT movies is not displayed.<br />
<br />
== Myst TODO ==<br />
The game is playable and should be completable to all four endings, though many issues still need to be fixed.<br />
<br />
=== Main TODO ===<br />
* Myst ME 10th Anniversary Edition requires Sorenson Video 3 for the UbiSoft logo<br />
** Since SVQ3 is quite large (and based on h.264), we may suggest the user just take the video from the Macintosh portion of the disc, which is QTRLE<br />
* JPEG optimization for Myst ME<br />
* Improve SVQ1 color<br />
** The current 410 algorithm results in color being "blocky" -- should switch to using linear interpolation<br />
* Add more transitions<br />
* Add Help System (Myst ME only)<br />
<br />
=== Stack TODO/Known Bugs ===<br />
<br />
==== Mechanical ====<br />
* Fortress rotation holo-simulator not working properly<br />
** Requires playing QT movies with edit lists backwards. See [[Mohawk/TODO#Video|above]]<br />
<br />
== Riven TODO ==<br />
=== Status ===<br />
The game first became completable with r52735. As of r55299, the game is completable with no prior knowledge.<br />
<br />
=== Main TODO ===<br />
(In Order of Priority):<br />
* Finish External Commands (Many are done, most are self-explanatory)<br />
* Transitions<br />
* Finish ambient sound handling: Only fading is left<br />
* Cleanup video handling<br />
** We should emulate the QuickTime overlay, without doing so causes a couple glitches:<br />
*** Rarely before a video, the screen that should be shown after the video flashes before the video starts (for example: opening the linking book in the Rebel tunnel puzzle).<br />
*** Rarely after a video, the engine does not update with the correct screen. As far as I can tell, this ''only'' affects the easter egg videos on gspit and ospit under normal conditions. However, it can be noticed when skipping a video on occasion.<br />
**** We should also be showing the last frame when skipping<br />
*** In one instance, the lower staircase with the sunners, the water effect can overwrite the video.<br />
* Cleanup hotspot debugging mode. The water effect and videos write over it.<br />
<br />
=== Stack TODO/Known Bugs ===<br />
<br />
==== gspit ====<br />
* The underwater viewer is partially implemented.<br />
** xgwharksnd needs to be implemented.<br />
** Has hardcoded background sounds.<br />
<br />
==== tspit ====<br />
* Marbles not drawn on grid when standing one step back from the marble puzzle<br />
** xt7600_setupmarbles needs to be completed.<br />
<br />
== Living Books TODO ==<br />
<br />
* Take another look at how rewinding is meant to work.<br />
* Implement fading between palettes.<br />
* Add fading between pages - do full preloading (including sound) and use the relevant cursors.<br />
* Implement the hardcoded mini-games in Green Eggs and Ham and Arthur's Reading Race.<br />
* Implement the rest of the scripting used in the later LB games, including variable saving/loading.<br />
* Handle the proxies and compiled scripts used in v4 (The Rugrats Adventure Game, Arthur's Computer Adventure). fuzzie has preliminary code for this.<br />
<br />
== CSTime TODO ==<br />
<br />
* Implement the intro/transition videos (HQ/time tunnel).<br />
* Draw the text on Carmen's notes.<br />
* Fix feature priorities.<br />
* Implement music, environmental sounds, the rest of the animation code.<br />
* Implement the Chronopedia.<br />
* Render the torch mask for case 1.<br />
* Support the other sound sync cues.<br />
* Implement cases 3-20.<br />
* A host of other things, no doubt.<br />
<br />
== Other Games TODO ==<br />
<br />
* They (mostly) all use QuickTime video. <br />
** The re-release of Zoombinis uses Bink Video!<br />
** Some Kid Pix games use Smacker (in tSMK resources)<br />
* Some educational games (e.g. Treehouse, Zoombini) use some TrueType fonts.</div>
BgK
https://wiki.scummvm.org/index.php?title=Residual_TODO&diff=17357
Residual TODO
2012-01-06T14:30:35Z
<p>BgK: renaming to ResidualVM</p>
<hr />
<div>#REDIRECT [[ResidualVM]]</div>
BgK
https://wiki.scummvm.org/index.php?title=Residual/Sets&diff=17356
Residual/Sets
2012-01-06T14:30:21Z
<p>BgK: renaming to ResidualVM</p>
<hr />
<div>#REDIRECT [[ResidualVM]]</div>
BgK
https://wiki.scummvm.org/index.php?title=ResidualVM/Sets&diff=17355
ResidualVM/Sets
2012-01-06T14:30:03Z
<p>BgK: renaming to ResidualVM</p>
<hr />
<div>#REDIRECT [[ResidualVM]]</div>
BgK
https://wiki.scummvm.org/index.php?title=Residual/TODO&diff=17354
Residual/TODO
2012-01-06T14:29:50Z
<p>BgK: renaming to ResidualVM</p>
<hr />
<div>#REDIRECT [[ResidualVM]]</div>
BgK
https://wiki.scummvm.org/index.php?title=ResidualVM/TODO&diff=17353
ResidualVM/TODO
2012-01-06T14:29:24Z
<p>BgK: renaming to ResidualVM</p>
<hr />
<div>#REDIRECT [[ResidualVM]]</div>
BgK
https://wiki.scummvm.org/index.php?title=Residual_Sets&diff=17352
Residual Sets
2012-01-06T14:28:58Z
<p>BgK: renaming to ResidualVM</p>
<hr />
<div>#REDIRECT [[ResidualVM]]</div>
BgK
https://wiki.scummvm.org/index.php?title=LucasArts&diff=17351
LucasArts
2012-01-06T14:27:06Z
<p>BgK: renaming to ResidualVM</p>
<hr />
<div>'''LucasArts''' is a computer game company founded by George Lucas. Before becoming a separate entity, the games were released under the '''Lucasfilm Games''' label.<br />
<br />
While building its reputation as a developer of excellent graphic adventure games beginning in the late 1980s, the company switched to marketing the Star Wars franchise in the late 1990s. It is doubtful LucasArts will produce any more adventure games.<br />
<br />
LucasArts produced many adventures like the [[Monkey Island series]] based on the SPUTM engine, which used the [[SCUMM]] scripting language, which also gave [[ScummVM]] its name.<br />
<br />
* [[Maniac Mansion]]<br />
* [[Zak McKracken and the Alien Mindbenders]]<br />
* [[Indiana Jones and the Last Crusade]]<br />
* [[Loom]]<br />
* [[Passport to Adventure]]<br />
* [[The Secret of Monkey Island]]<br />
* [[Monkey Island 2: LeChuck's Revenge]]<br />
* [[Indiana Jones and the Fate of Atlantis]]<br />
* [[Day of the Tentacle]]<br />
* [[Sam & Max Hit the Road]]<br />
* [[Full Throttle]]<br />
* [[The Dig]]<br />
* [[The Curse of Monkey Island]]<br />
<br />
The last two LucasArts adventures [[Grim Fandango]] and [[Escape from Monkey Island]], being 3D Adventures, did not use the SCUMM scripting language. However, at least for Grim, there is [[ResidualVM]].<br />
<br />
[http://www.sqeagz.com/passigar/ PASSIGAR] also has a very good list of almost all known LucasArts game versions<br />
<br />
==External links==<br />
[http://en.wikipedia.org/wiki/LucasArts Wikipedia article on LucasArts]<br />
<br />
[[Category:Companies]]</div>
BgK
https://wiki.scummvm.org/index.php?title=ResidualVM&diff=17350
ResidualVM
2012-01-06T14:23:37Z
<p>BgK: renaming to ResidualVM</p>
<hr />
<div>[http://www.residualvm.org ResidualVM] is an engine which allows you to play [[LucasArts]]' two [http://www.lua.org Lua]-based 3D adventure games on several platforms.<br />
<br />
For more detailed information on the current status please read the [http://apps.sourceforge.net/mediawiki/residual ResidualVM Wiki] page.</div>
BgK
https://wiki.scummvm.org/index.php?title=Residual/TODO&diff=17349
Residual/TODO
2012-01-06T14:22:15Z
<p>BgK: moved Residual/TODO to ResidualVM/TODO</p>
<hr />
<div>#REDIRECT [[ResidualVM/TODO]]</div>
BgK
https://wiki.scummvm.org/index.php?title=ResidualVM/TODO&diff=17348
ResidualVM/TODO
2012-01-06T14:22:15Z
<p>BgK: moved Residual/TODO to ResidualVM/TODO</p>
<hr />
<div>#REDIRECT [[Residual]]</div>
BgK
https://wiki.scummvm.org/index.php?title=Residual/Sets&diff=17347
Residual/Sets
2012-01-06T14:22:15Z
<p>BgK: moved Residual/Sets to ResidualVM/Sets</p>
<hr />
<div>#REDIRECT [[ResidualVM/Sets]]</div>
BgK
https://wiki.scummvm.org/index.php?title=ResidualVM/Sets&diff=17346
ResidualVM/Sets
2012-01-06T14:22:15Z
<p>BgK: moved Residual/Sets to ResidualVM/Sets</p>
<hr />
<div>#REDIRECT [[Residual]]</div>
BgK
https://wiki.scummvm.org/index.php?title=Residual&diff=17345
Residual
2012-01-06T14:22:15Z
<p>BgK: moved Residual to ResidualVM</p>
<hr />
<div>#REDIRECT [[ResidualVM]]</div>
BgK
https://wiki.scummvm.org/index.php?title=ResidualVM&diff=17344
ResidualVM
2012-01-06T14:22:15Z
<p>BgK: moved Residual to ResidualVM</p>
<hr />
<div>[http://residual.sourceforge.net Residual] is an engine which allows you to play [[LucasArts]]' two [http://www.lua.org Lua]-based 3D adventure games on several platforms.<br />
<br />
For more detailed information on the current status please read the [http://apps.sourceforge.net/mediawiki/residual Residual Wiki] page.</div>
BgK
https://wiki.scummvm.org/index.php?title=Mohawk/TODO&diff=16781
Mohawk/TODO
2011-08-14T07:44:16Z
<p>BgK: /* Myst TODO */ Remove completed tasks</p>
<hr />
<div>{{Infobox_TODO|<br />
taskname=Mohawk Engine TODO|<br />
techcontact=[[Mohawk]] Engine Team|<br />
subsystem=Engine|<br />
}}<br />
<br />
== Main Mohawk TODO ==<br />
=== Video ===<br />
* Backwards playback/seeking<br />
** Myst ME:<br />
*** Myst Card 4113: Retracting weight in the clock tower<br />
** Myst Original:<br />
*** Stoneship Card 2138: Chest key animation with no chest present<br />
*** Stoneship Card 2132: Chest valve animation when chest is empty<br />
*** Channelwood Card 3385: Closing stairs upper door animation<br />
* Playback at custom framerates - Needed for Myst Cabin Boiler videos.<br />
* The Cyan logo repeats some frames at the end. I call it "Cyan logo syndrome." This is caused by the lack of handling of multiple edit lists. FFmpeg doesn't handle this yet either.<br />
* Some Cinepak frames have corruption.<br />
** The Myst linking book video on D'ni has a corrupted Cinepak frame (data-wise). Right now, we just skip that frame (and throw a warning). It looks like QuickTime does this too.<br />
** The CD (but ''not'' the DVD) version of Riven has at least two videos with a corrupt frame: the wood chipper (when power is directed elsewhere) and using the trap book before talking with Gehn (when not on Tay).<br />
* Unify the 8bpp to 16/32bpp code snippets. This is mostly done already. I have a patch to add it to graphics/conversion.h, but still waiting on that one.<br />
<br />
== Myst TODO ==<br />
The game is playable and should be completable to all four endings, though many issues still need to be fixed.<br />
<br />
=== Main TODO ===<br />
* Myst ME support is missing these codecs: QDesign Music 2 (partially working) and Sorenson Video 1.<br />
* Myst 10th Edition requires the Myst ME codecs plus Sorenson Video 3.<br />
* JPEG Optimization for Myst ME.<br />
* Add Transitions.<br />
* Myst Demo Only - Add fading<br />
* Myst ME Only - Add Help System.<br />
<br />
=== Stack TODO/Known Bugs ===<br />
<br />
==== Myst Island ====<br />
* Cabin Boiler Movie Playback Logic - Card 4097, 4098<br />
** This also requires QT movie playback at custom rates - See [[Mohawk/TODO#Video|above]]<br />
* Myst ME lacks the weight going back up - Card 4113<br />
** See [[Mohawk/TODO#Video|above]]<br />
<br />
==== Channelwood ====<br />
* Animation of closing stairs upper door incorrect - Card 3385<br />
** See [[Mohawk/TODO#Video|above]]<br />
<br />
==== Mechanical ====<br />
* Fortress Rotation not working - Complete opcode 205<br />
** See [[Mohawk/TODO#Video|above]]<br />
* Fortress Rotation Holo-Simulator not working - Complete opcode 206<br />
** See [[Mohawk/TODO#Video|above]]<br />
<br />
==== Stoneship ====<br />
* Chest key animation with no chest and Opening Chest Valve when empty in the Stoneship Lighthouse incorrect<br />
** See [[Mohawk/TODO#Video|above]]<br />
<br />
== Riven TODO ==<br />
=== Status ===<br />
The game first became completable with r52735. As of r55299, the game is completable with no prior knowledge.<br />
<br />
=== Main TODO ===<br />
(In Order of Priority):<br />
* Finish External Commands (Many are done, most are self-explanatory)<br />
* Transitions<br />
* Finish ambient sound handling: Only fading is left<br />
* Cleanup video handling<br />
** We should emulate the QuickTime overlay, without doing so causes a couple glitches:<br />
*** Rarely before a video, the screen that should be shown after the video flashes before the video starts (for example: opening the linking book in the Rebel tunnel puzzle).<br />
*** Rarely after a video, the engine does not update with the correct screen. As far as I can tell, this ''only'' affects the easter egg videos on gspit and ospit under normal conditions. However, it can be noticed when skipping a video on occasion.<br />
**** We should also be showing the last frame when skipping<br />
*** In one instance, the lower staircase with the sunners, the water effect can overwrite the video.<br />
** Honor the MLST volume field<br />
* Cleanup hotspot debugging mode. The water effect and videos write over it.<br />
<br />
=== Stack TODO/Known Bugs ===<br />
<br />
==== gspit (Survey Island - internally Garden) ====<br />
* The underwater viewer is partially implemented.<br />
** xgwharksnd needs to be implemented.<br />
** Has hardcoded background sounds.<br />
<br />
==== tspit (Temple Island) ====<br />
* Marbles not drawn on grid when standing one step back from the marble puzzle<br />
** xt7600_setupmarbles needs to be completed.<br />
<br />
== Living Books TODO ==<br />
<br />
* Take another look at how rewinding is meant to work.<br />
* Implement fading between palettes.<br />
* Add fading between pages - do full preloading (including sound) and use the relevant cursors.<br />
* Implement the hardcoded mini-games in Green Eggs and Ham and Arthur's Reading Race.<br />
* Implement the rest of the scripting used in the later LB games, including variable saving/loading.<br />
* Handle the proxies and compiled scripts used in v4 (The Rugrats Adventure Game, Arthur's Computer Adventure). fuzzie has preliminary code for this.<br />
<br />
== CSTime TODO ==<br />
<br />
* Implement the intro/transition videos (HQ/time tunnel).<br />
* Draw the text on Carmen's notes.<br />
* Fix feature priorities.<br />
* Implement music, environmental sounds, the rest of the animation code.<br />
* Implement the Chronopedia.<br />
* Render the torch mask for case 1.<br />
* Support the other sound sync cues.<br />
* Implement cases 3-20.<br />
* A host of other things, no doubt.<br />
<br />
== Other Games TODO ==<br />
<br />
* They (mostly) all use QuickTime video. <br />
** The re-release of Zoombinis uses Bink Video!<br />
** Some Kid Pix games use Smacker (in tSMK resources)<br />
* Some educational games (e.g. Treehouse, Zoombini) use some TrueType fonts.</div>
BgK
https://wiki.scummvm.org/index.php?title=PlayStation_3&diff=16709
PlayStation 3
2011-07-15T14:22:34Z
<p>BgK: </p>
<hr />
<div>{{PortFeatures|<br />
name=PlayStation 3|<br />
backend=sdl|<br />
version=n/a|<br />
status=Maintained|<br />
mp3=yes|<br />
ogg=yes|<br />
flac=yes|<br />
uncompressed=yes|<br />
zlib=yes|<br />
plugins=no|<br />
16bits=yes|<br />
buildbot=yes|<br />
firstversion=n/a|<br />
maintainer=[[User:BgK|BgK]]|<br />
packager=[[User:BgK|BgK]]|<br />
pkgend=-ps3.zip|<br />
forum=10|<br />
icon=ps3|<br />
<br />
agi=yes|<br />
agos=yes|<br />
cine=yes|<br />
cruise=yes|<br />
draci=yes|<br />
drascula=yes|<br />
gob=yes|<br />
groovie=yes|<br />
kyra=yes|<br />
lure=yes|<br />
made=yes|<br />
parallaction=yes|<br />
queen=yes|<br />
saga=yes|<br />
scumm=yes|<br />
sky=yes|<br />
sword1=yes|<br />
sword2=yes|<br />
teenagent=yes|<br />
tinsel=yes|<br />
touche=yes|<br />
tucker=yes|<br />
}}<br />
<br />
== About ==<br />
All games are supported and *should* work, but they have not all been tested.<br />
<br />
== Prerequisites ==<br />
* A homebrew enabled PlayStation 3 console. As of now that mostly means having a custom firmware installed. Obtaining and installing such a software is out of the scope of this document. Sorry, but you're on your own for that one.<br />
* At least one ScummVM supported game. The list of compatible games can be seen here: http://www.scummvm.org/compatibility/<br />
The page http://wiki.scummvm.org/index.php/Where_to_get_the_games references some places where those games can be bought. Demonstration versions for most of the supported games are downloadable on http://scummvm.org/demos/<br />
* An USB drive.<br />
<br />
== Installing ==<br />
From a computer, download the installable package of the PS3 port from ScummVM's main site. It should be a .pkg file. Copy it to an USB drive.<br />
After having plugged the USB drive to you PS3, the installation package should appear in the XMB under the "Games > Install Package" menu. Installing it copies ScummVM and its dependencies to your PS3's hard drive. It also adds the "Games > PlayStation 3 > ScummVM" XMB entry which is to be used to launch ScummVM.<br />
<br />
== Configuring and playing games ==<br />
The user manual describes how to add games to ScummVM and launch them : http://wiki.scummvm.org/index.php/User_Manual<br />
<br />
== PlayStation 3 Specifics ==<br />
Games can be launched either from an USB drive or from the internal hard drive. The internal hard drive has better performance though.<br />
Savegames are wrote in the /hdd0/game/SCUM12000/saves folder.<br />
<br />
== Joypad button mapping ==<br />
* Left stick => Mouse<br />
* Cross => Left mouse button<br />
* Circle => Right mouse button<br />
* Triangle => Game menu (F5)<br />
* Square => Escape<br />
* Start => ScummVM's in global game menu<br />
* Select => Toggle virtual keyboard<br />
* L1 => AGI predictive input dialog<br />
<br />
== Building from source ==<br />
This port of ScummVM to the PS3 is based on SDL. It uses the open source SDK PSL1GHT.<br />
<br />
The dependencies needed to build it are :<br />
<br />
* The toolchain from https://github.com/ps3dev/ps3toolchain<br />
* SDL from https://github.com/zeldin/SDL_PSL1GHT<br />
* ScummVM from https://github.com/scummvm/scummvm<br />
<br />
Once all the dependencies are correctly setup, an installable package can be obtained from source by issuing the following command :<br />
<br />
./configure --host=ps3 && make ps3pkg</div>
BgK
https://wiki.scummvm.org/index.php?title=Mohawk/TODO&diff=16410
Mohawk/TODO
2011-05-16T17:39:46Z
<p>BgK: </p>
<hr />
<div>{{Infobox_TODO|<br />
taskname=Mohawk Engine TODO|<br />
techcontact=[[Mohawk]] Engine Team|<br />
subsystem=Engine|<br />
}}<br />
<br />
== Main Mohawk TODO ==<br />
=== Video ===<br />
* Backwards playback/seeking<br />
** Myst ME:<br />
*** Myst Card 4113: Retracting weight in the clock tower<br />
** Myst Original:<br />
*** Stoneship Card 2138: Chest key animation with no chest present<br />
*** Stoneship Card 2132: Chest valve animation when chest is empty<br />
*** Channelwood Card 3385: Closing stairs upper door animation<br />
* Playback at custom framerates - Needed for Myst Cabin Boiler videos.<br />
* The Cyan logo repeats some frames at the end. I call it "Cyan logo syndrome." This is caused by the lack of handling of multiple edit lists. FFmpeg doesn't handle this yet either.<br />
* Some Cinepak frames have corruption.<br />
** The Myst linking book video on D'ni has a corrupted Cinepak frame (data-wise). Right now, we just skip that frame (and throw a warning). It looks like QuickTime does this too.<br />
** The CD (but ''not'' the DVD) version of Riven has at least two videos with a corrupt frame: the wood chipper (when power is directed elsewhere) and using the trap book before talking with Gehn (when not on Tay).<br />
* Unify the 8bpp to 16/32bpp code snippets. This is mostly done already. I have a patch to add it to graphics/conversion.h, but still waiting on that one.<br />
<br />
== Myst TODO ==<br />
The game is playable and should be completable to all four endings, though many issues still need to be fixed.<br />
<br />
=== Main TODO ===<br />
* Myst ME support is missing these codecs: QDesign Music 2 (partially working) and Sorenson Video 1.<br />
* Myst 10th Edition requires the Myst ME codecs plus Sorenson Video 3.<br />
* JPEG Optimization for Myst ME.<br />
* Add Transitions.<br />
* Myst Demo Only - Add "Return To Main Menu"<br />
* Myst ME Only - Add Help System.<br />
<br />
=== Stack TODO/Known Bugs ===<br />
<br />
==== Myst Island ====<br />
* Cabin Boiler Movie Playback Logic - Card 4097, 4098<br />
** This also requires QT movie playback at custom rates - See [[Mohawk/TODO#Video|above]]<br />
* Myst ME lacks the weight going back up - Card 4113<br />
** See [[Mohawk/TODO#Video|above]]<br />
<br />
==== Channelwood ====<br />
* Animation of closing stairs upper door incorrect - Card 3385<br />
** See [[Mohawk/TODO#Video|above]]<br />
<br />
==== Mechanical ====<br />
* Fortress Rotation not working - Complete opcode 205<br />
** See [[Mohawk/TODO#Video|above]]<br />
* Fortress Rotation Holo-Simulator not working - Complete opcode 206<br />
** See [[Mohawk/TODO#Video|above]]<br />
<br />
==== Stoneship ====<br />
* Chest key animation with no chest and Opening Chest Valve when empty in the Stoneship Lighthouse incorrect<br />
** See [[Mohawk/TODO#Video|above]]<br />
<br />
==== Demo ====<br />
* Missing opcodes<br />
<br />
==== Preview (Demo) ====<br />
* Missing opcodes<br />
<br />
== Riven TODO ==<br />
=== Status ===<br />
The game first became completable with r52735. As of r55299, the game is completable with no prior knowledge.<br />
<br />
=== Main TODO ===<br />
(In Order of Priority):<br />
* Finish External Commands (Many are done, most are self-explanatory)<br />
* Complete the complexPlayMovie opcode<br />
** Used in a couple places, fairly straightforward, but will involve a new video loop<br />
* Transitions<br />
* Finish ambient sound handling: Only fading is left<br />
* Cleanup video handling, all involve the QuickTime overlay:<br />
** Rarely before a video, the screen that should be shown after the video flashes before the video starts (for example: opening the linking book in the Rebel tunnel puzzle).<br />
** Rarely after a video, the engine does not update with the correct screen. As far as I can tell, this ''only'' affects the easter egg videos on gspit and ospit under normal conditions. However, it can be noticed when skipping a video on occasion.<br />
* Cleanup hotspot debugging mode. The water effect and videos write over it.<br />
<br />
=== Stack TODO/Known Bugs ===<br />
<br />
==== gspit (Survey Island - internally Garden) ====<br />
* The underwater viewer is partially implemented.<br />
** xgwharksnd needs to be implemented.<br />
** Has hardcoded background sounds.<br />
<br />
==== jspit (Jungle Island) ====<br />
* Missing randomized sunner videos.<br />
** xjlagoon700_alert and xjlagoon800_alert need to be implemented.<br />
** Has hardcoded background videos.<br />
<br />
==== tspit (Temple Island) ====<br />
* Marbles not drawn on grid when standing one step back from the marble puzzle<br />
** xt7600_setupmarbles needs to be completed.<br />
<br />
== Living Books TODO ==<br />
<br />
* Take another look at how rewinding is meant to work.<br />
* Implement fading between palettes.<br />
* Add fading between pages - do full preloading (including sound) and use the relevant cursors.<br />
* Implement the hardcoded mini-games in Green Eggs and Ham and Arthur's Reading Race.<br />
* Implement the rest of the scripting used in the later LB games, including variable saving/loading.<br />
* Handle the proxies and compiled scripts used in v4 (The Rugrats Adventure Game, Arthur's Computer Adventure). fuzzie has preliminary code for this.<br />
<br />
== CSTime TODO ==<br />
<br />
* Implement the intro/transition videos (HQ/time tunnel).<br />
* Draw the text on Carmen's notes.<br />
* Fix feature priorities.<br />
* Implement music, environmental sounds, the rest of the animation code.<br />
* Implement the Chronopedia.<br />
* Render the torch mask for case 1.<br />
* Support the other sound sync cues.<br />
* Implement cases 3-20.<br />
* A host of other things, no doubt.<br />
<br />
== Other Games TODO ==<br />
<br />
* They (mostly) all use QuickTime video. <br />
** The re-release of Zoombinis uses Bink Video!<br />
** Some Kid Pix games use Smacker (in tSMK resources)<br />
* Some educational games (e.g. Treehouse, Zoombini) use some TrueType fonts.</div>
BgK