Difference between revisions of "Summer of Code/GSoC Ideas 2022"

Jump to navigation Jump to search
→‎YAGA engine: Clarifying permissions
(Adding list items for the starting info)
(→‎YAGA engine: Clarifying permissions)
 
(4 intermediate revisions by 2 users not shown)
Line 71: Line 71:


[https://www.mobygames.com/game/immortal/screenshots Screenshots on Mobygames]
[https://www.mobygames.com/game/immortal/screenshots Screenshots on Mobygames]




Line 86: Line 88:




=== YAGA engine ===
* Technical contacts: [[User:Sev|sev]]
* Difficulty level: Medium.
* Size: 175 hours
This engine was used for two later [[Humongous Entertainment]] games, [[Pajama Sam: Life is Rough When You Lose Your Stuff]] and [[Putt-Putt: Pep's Birthday Surprise]]. The engine is basically an extension of Python 2.2. There exists an almost complete reimplementation by cyx [https://github.com/cyxx/linyaga on GitHub] (which we have permission to use) that can be used as a base, and we also have the complete source code for the original game.
The task is relatively straightforward, the only difficulty with it is adding Python as an external dependency, but a mentor is there to help. Implementing the missing "Lip Sync" feature will be the main part of this task.
The goal is to bring cyx's code to ScummVM and use the original code as a reference later.
=== Finishing implementation of incomplete engines ===
* Technical contacts: [[User:Sev|sev]]
* Difficulty level: Medium or High
* Size: 175 hours or 350 hours
ScummVM currently has a number of engines which are very close to completion. Many of them were parts of previous GSoCs. For them, we need a playthrough and slight bugfixing, or additional portability fixes.
Some of the engines are:
* [[MacVenture]], based on a [http://seancode.com/webventure/ JavaScript reimplementation]. Very close to completion, playthrough is missing and rechecking ties to our Mac GUI emulation.
* [[Avalanche]], some engine parts like Outro are not finished. Complete list is [[Avalanche#TO-DO|here]]
* [[DM]]


=== Bring your own Adventure or RPG Reimplementation (only existing games) ===
=== Bring your own Adventure or RPG Reimplementation (only existing games) ===
Line 121: Line 148:
=== Support Unicode input in GUI ===
=== Support Unicode input in GUI ===


*Technical contacts: [[User:Sev|sev]]
* Technical contacts: [[User:Sev|sev]]
* Difficulty: Medium
* Difficulty: Medium
* Size: 175 hours
* Size: 175 hours


Last year we enhanced our GUI for supporting Unicode output. Now we need to enhance our input system, so Unicode input is supported as well. This includes RTL support (we have FriBiDi employed for output).
Last year we enhanced our GUI for supporting Unicode output. Now we need to enhance our input system, so Unicode input is supported as well. This includes RTL support (we have FriBiDi employed for output).
=== Networking code for Moonbase Commander===
* Technical contacts: [[User:Sev|sev]]
* Difficulty level: Medium
* Size: 175 hours
[[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. There is an [https://github.com/scummvm/scummvm-sites/tree/multiplayer unfinished server code] based written in PHP. The code supports creating game sessions, joining sessions and the gameplay.
The optional task extension is fixing several remaining rendering bugs in the game.
=== Optimize blending code for AGS games ===
* Technical contacts: [[User:Criezy|Criezy]]
* Difficulty level: Medium
* Size: 175 hours
One of the main bottleneck in term of performances for AGS games in ScummVM lies in the way sprites are blended together. The AGS engine has 10 different blending modes, and they are currently implemented in a generic way with the colors for both sources being decomposed into their RGBA components before being blended, and then the resulting color being composed back. Those generic decompositions and composition operations are slow and in many cases could be eliminated when implementing specialised versions of the blending functions for a specific pixel format. The task will consist in first changing the blending code so that it can benefit from specialised implementations (for example use template functions or a function pointer). Then specialized optimized implementations of the blending functions can be added for the most commonly used input and output pixel formats combinations.


== Infrastructure Tasks ==
== Infrastructure Tasks ==
TrustedUser
567

edits

Navigation menu