|
|
| Line 50: |
Line 50: |
| == Generic infrastructure tasks == | | == Generic infrastructure tasks == |
|
| |
|
| === GUI ===
| |
| ''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:LordHoto|Johannes Schickel]]
| |
|
| |
| ''Background:''
| |
|
| |
| ScummVM implements its own GUI code. We can't use any of the portable GUI kits out there, as they are mostly not portable enough,
| |
| use too many resources or simply are not flexible enough to work atop our backend system. Also, our GUI must look equally good
| |
| with 8bit, 16bit or 32bit graphics, at 320x200, 320x240 or 640x480 resolutions -- and ideally also at 240x200, 256*192 or at 1280x1024.
| |
|
| |
| Currently we have a quite flexible system for defining the look and feel of our GUI. Almost every aspect of it can be specified
| |
| via external theme file described [[GUI_Themes/Specs|here]]. Even though this has proven to meet our needs
| |
| it is too complex and hard to use. Furthermore, our GUI layout is contained in the same config file as the renderer configuration, which requires custom renderer themes to be manually updated, even though nothing in the renderer has been changed.
| |
|
| |
| Our current GUI implementation also has some further downsides. Currently we handle redraws very inefficiently, for example
| |
| on a single widget change we redraw the whole GUI. Also our pixmap approach is pretty unsophisticated, and so the
| |
| overall renderer efficiency suffers. Last but not least our complete widget handling could be cleaned up and improved a bit.
| |
|
| |
| ''The Task:''
| |
|
| |
| Rework our GUI implementation completely. To achieve this you should look at different GUI implementations out there like
| |
| [http://www.paragui.org/ ParaGUI] and of course at our GUI. With the information you gather from that, design and implement
| |
| a GUI to fit our needs. Here is a small list of features we would like to have:
| |
|
| |
| * Support for low end devices, like the Nintendo DS with 4 MB of RAM and a slow CPU (ARM with 67MHz)
| |
| * Layout and widget look should be pretty much the same as our current GUI (although we are open to suggestions for improvements)
| |
| * A vector graphics based renderer sounds like a nice thing for customizability
| |
| * Antialiased fonts for more powerful machines would be a nice addition
| |
| * TrueType font support would be cool, but of course it should still be portable
| |
| * Widgets should be configurable in the layout description, i.e. font to use, text, position etc.
| |
| * Internalization support would be nice, but of course this is a lot of extra work
| |
| * Eye candy like highlighting buttons while hovering etc. would be a really nice addition for high end machines
| |
| * Support at least 15/16 bits per pixel screen depths, additional support for 24BPP and 32BPP would be nice
| |
| * Extendible design, which should make it easy to support new widgets
| |
|
| |
|
| |
|
| |
| === Virtual Keyboard and Keymapper ===
| |
| ''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:JoostP|Joost Peters]], [[User:Fingolfin|Max Horn]], [[User:DJWillis|John Willis]]
| |
|
| |
| ''Background:''
| |
|
| |
| Many devices supported by ScummVM are keyboard-less. Also many of them still feature small number of keys, but they are very port-specific and even device-specific. Currently several of our backends feature virtual keyboards in different incompatible forms, and every new keyboard-less port has to reinvent the wheel over again. Additionally there is a rudimentary keymapper, which is duplicated in several backends, but it uses a gross hacks and is not flexible enough.
| |
|
| |
| ''The Task:''
| |
|
| |
| Your tasks would be to develop a fully configurable portable virtual keyboard as well as extending current keymapper and making it more flexible.
| |
|
| |
| For the keyboard one of possible solutions would be to make it accept an arbitrary bitmap with keys drawn on it, and a map attached to that image. The map format could be some derivative of HTML ImageMap, since it eliminates requirement of writing a keyboard layout editor. Then there should be possibility to switch layouts on the fly (upper case, lower case, special symbols) and define image maps fo different screen resolutions.
| |
|
| |
| The keymapper should have 2 main sources of control information. First is a backend which tells it how many and which keys does current device have, and a game engine which tells which actions should be mapped on keys. Then the keymapper should translate any input according to user-defined preferences. Additionally a scheme for sane automapping should be developed. A quite creative task.
| |
|
| |
| See also the pages on [[Keymapping Improvements]] and [[Virtual Keyboard Improvements]] in this Wiki.
| |
|
| |
|
| === Small Devices Backend === | | === Small Devices Backend === |
| Line 129: |
Line 77: |
| * Refactoring skills. | | * Refactoring skills. |
| * Knowledge of one or more ScummVM platform backends is desirable. | | * Knowledge of one or more ScummVM platform backends is desirable. |
|
| |
| === Improve Savestate management ===
| |
| ''Technical Contact'': [[User:Fingolfin|Max Horn]]
| |
|
| |
| ''Background:''
| |
|
| |
| With ScummVM, you can replay many fantastic classical graphic adventures. Since playing through these takes some time, virtually all of them implement some kind of save states -- i.e. you can save the current state of your game and resume playing at a later point. Also, many engines automatically save the current state at certain time intervals, in case a crash or some other circumstances cause ScummVM to abruptly terminate. ScummVM also offers a command line switch to immediately load a certain savestate and resume playing with that. E.g. you could type
| |
| ./scummvm -x5 monkey
| |
| to resume playing Monkey Island with the 5th savestate.
| |
|
| |
| ''The Task:''
| |
|
| |
| Not all engines implement the code necessary for the -x command line switch to work. Even less implement the code needed for the --list-saves command line option (introduced in 0.12.x). Finally, there is no way to manage savestates from the GUI, so if you use the Launcher (the builtin GUI frontend of ScummVM), you can not load a specific savestate, nor delete it. Your task would include these items (or a suitable subset):
| |
| * implement MetaEngine::listSaves() in all engines which are missing it and where it makes sense
| |
| * likewise, add support for the "-x" command line option in all engines
| |
| * new GUI dialog in the launcher listing all savegames, making it possible to load and delete savegames from the launcher
| |
| * optionally: extend the MetaEngine API with code that allows "renaming" savestates, moving savestates to different slots, etc.
| |
| * optionally: the same dialog could also be made accessible from all engines (in addition to their "native" save/load dialogs), via a special hotkey, to make it possible to load games in a unified way in all engines (this would require adding a way to tell engines to load a different savestate, e.g. by introducing a new EVENT type for this)
| |
| * optionally: extend the MetaEngine API to support showing thumbnails, and use this to make SCUMM thumbnails visible in the generic load dialog
| |
| * optionally: add new list widget which shows images+text instead of only text (i.e. a screenshot thumbnail for the savegame). Use this to enhance the load dialog to look much cooler than it does now
| |
|
| |
| Many more things are possible in this direction, depending on your interests. For example, a global uniform *save* dialog (once again, in addition to the "native" dialogs of the games) would be nice, too, but would require some careful research as to how to interface it with the game engines best.
| |
|
| |
| ''Required Skills:''
| |
|
| |
| * Good C++ skills.
| |
|
| |
|
| === Improve the overlay API === | | === Improve the overlay API === |
| Line 180: |
Line 102: |
| * Refactoring skills. | | * Refactoring skills. |
| * Knowledge of one or more ScummVM platform backends is desirable. | | * Knowledge of one or more ScummVM platform backends is desirable. |
|
| |
| === "Return to launcher" and global main menu ===
| |
| ''Technical Contact'': [[User:Fingolfin|Max Horn]], [[User:JoostP|Joost Peters]]
| |
|
| |
| ''Background:''
| |
|
| |
| Presently we have to exit the ScummVM application completely when a users exit a game because most
| |
| engines do not clean up memory properly on their exit. In particular, it is not possible to return to the
| |
| launcher (short: Rtl) without restarting ScummVM, which is annoying, especially on systems where "exit" equals
| |
| "reboot" (e.g. certain gaming consoles).
| |
|
| |
| Also, there is no uniform GUI in ScummVM which lets the user Quit/Return to launcher/Set game options. The SCUMM engine
| |
| has such a dialog (shown when pressing F5), but most engines have custom dialogs for this, and not all offer everything
| |
| (like there may be no button for quit, no way to change all game options available in the launcher, etc.)
| |
|
| |
| ''The Task:''
| |
|
| |
| The first part concerns the Rtl feature.
| |
| What we need is to analyze what's going on there and plug all memory leaks, properly shut down
| |
| subsystems like sound, so it will be possible to play more than a single game within one
| |
| session.
| |
|
| |
| The task will require good use of a memory leak analyzer and C++.
| |
|
| |
| * Make sure engines cleanup all properly after themselves: Find & fix memoy leaks, make sure sounds are stopped, files are closed, etc.
| |
| * Offer the user the option to return to the launcher (short: RTL), instead of quitting.
| |
| ** E.g. add a dialog which is shown upon a quit trigger which asks whether to quit, RTL or cancel. (See also the code handling the "confirm_exit" config variable in <code>backends/events/default/default-events.cpp</code> and elsewhere.)
| |
| ** In SCUMM, add a "RTL" button to the F5 menu.
| |
|
| |
| Make sure to reuse code when possible and appropriate (e.g. for the quit confirmation dialog).
| |
|
| |
| The next part of the task is to implement a "main menu" dialog (using our GUI code, modeled after the one in SCUMM). This dialog would have buttons for "About", "Options", "Quit", "Return to launcher", "Cancel", and should be extensible (so that e.g. the SCUMM main dialog could be a subclass of this, which adds extra buttons for "Save" and "Load"). The "main menu" dialog should be usable from all engines via a shared hotkey (so e.g. you might want to hook it up via the EventManager).
| |
| As a bonus, make the dialog look cool, e.g. by displaying the ScummVM logo in it.
| |
|
| |
|
| |
|
| == Audio related tasks == | | == Audio related tasks == |
|
| |
| === Add support for TFMX, and more Amiga MOD formats ===
| |
| ''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:DrMcCoy|Sven Hesse]]
| |
|
| |
| ''Background:''
| |
|
| |
| Since we're adding (and have added so far) support for different Amiga game versions, we need support for the sound files too.
| |
| Currently we need support for following formats:
| |
|
| |
| * Desktop Tracker format used by music in the Acorn disk version of Simon the Sorcerer 1. [http://www.tribbeck.com/software/sonor/dtt/manual/appx_f.html Information] about the specifications of the Desktop Track format and [http://members.optusnet.com.au/wormmon/mods/ sample mods] are available.
| |
|
| |
| * MaxTrax support for Kyrandia 1. The Amiga version isn't supported yet, but [[User:LordHoto|LordHoto]] will be working on it when his copy arrives. A Motorola 68000 (short: 68k) assembler implementation by Joe Pearce can be found [http://amiga.emucamp.com/wt/files/sources/SRC_MaxTrax.lzx here]. It would be necessary to re-implement it in proper C++, naturally a must for this task is 68k assembler knowledge. If you don't have the Amiga version of the Legend of Kyrandia, there are [http://www.exotica.org.uk/tunes/unexotica/games/Legend_of_Kyrandia.html sample modules] available.
| |
|
| |
| * TFMX a (non-MOD) format used by Monkey Island 1. There is a [http://freshmeat.net/projects/tfmx-play/ player] for it already, which is written in rather poor C, also it misses several macros implementation. [http://www.wotsit.org/download.asp?f=tfmx This] documentation may be useful, it isn't complete though. If you don't have the Amiga version of Monkey Island 1 you can use the [http://quick.mixnmojo.com/demos/mi1amigademo.zip demo] of Monkey Island 1. The main objective of this task is to write a TFMX player with all the effects and macros needed by the Monkey Island music tunes. Work can be based on the original - uncommented - replayer routine disassembly (Motorola 68k).
| |
|
| |
|
| === Improve sound support in SCUMM games === | | === Improve sound support in SCUMM games === |
| Line 302: |
Line 176: |
|
| |
|
| == Engine/game specific == | | == Engine/game specific == |
|
| |
|
| |
| === (Free)SCI engine ===
| |
| ''Technical Contact'': [[User:Fingolfin|Max Horn]]
| |
|
| |
| ''Background:''
| |
|
| |
| ScummVM currently does not support games using Sierra's SCI engine, used for many games from the Space Quest, King's Quest and other series. See [http://en.wikipedia.org/wiki/Sierra_Entertainment#SCI here] and [http://en.wikipedia.org/wiki/Sierra%27s_Creative_Interpreter] for more information on SCI. ScummVM does however support AGI, the predecessor of SCI. There have been many requests for us to add support for these games to us. However, there is already a project dedicated to support these games: [http://freesci.linuxgames.com FreeSCI].
| |
|
| |
| Jordi V, member of both the ScummVM and FreeSCI teams, started to work on a patch which turns FreeSCI into a ScummVM engine. His work can be found [http://darcs.jvprat.com/ here]. It would be nice to improve this backend. Another FreeSCI team member even put up [http://wiki.yak.net/894 some bounties] on some specific tasks.
| |
|
| |
| ''The Task:''
| |
|
| |
| Improve the FreeSCI engine. That is, improve its integration into ScummVM, enhance the FreeSCI code itself, etc.
| |
| TODO -- add more content here
| |
|
| |
|
| |
|
| === Objectify CinE engine === | | === Objectify CinE engine === |
| Line 335: |
Line 193: |
|
| |
|
| As a bonus you may consider finishing support for Operation Stealth game, but this task has much higher complexity. | | As a bonus you may consider finishing support for Operation Stealth game, but this task has much higher complexity. |
|
| |
| === Add support for Operation Stealth ===
| |
| ''Technical Contact'': [[User:Sev|Eugene Sandulenko]]
| |
|
| |
| ''Background:''
| |
| The cinE engine is used for two games, ''Future Wars'' and ''Operation Stealth''. ''Future Wars'' is very well supported, and was completable since 0.10.0. But ''Operation Stealth'' is still in not a good shape.
| |
|
| |
| ''The Task:''
| |
| Your task will be to finish reverse engineering of the engine and implement missing features in the engine. It is a task of very high complexity, and most probably you will not be able to finish it in the GSoC timeframe unless you already have experience with x86 assembly and reverse engineering.
| |
|
| |
| Currently several opcodes implementation is missing, as well as there are masking issues. Of course, you have to own a copy of the game. It is not known whether current engine allows to complete the game.
| |
|
| |
|
| === Objectify CruisE engine === | | === Objectify CruisE engine === |