User Tools

Site Tools


Sidebar

Current version: 0.8.5
iOS: 0.8.1+
Android: 0.8.5 (Play/Market version is obsolete!)

Github Coding has become social! Fork us!


News

Latest commit

https://github.com/gemrb/gemrb/commits/master

# ideally, but does not work on sourceforge (does elsewhere); even http proxies don't help rss>https://github.com/gemrb/gemrb/commits/master.atom 1 author 30m sidebar for frequently accessed stuff

developers:gsoc_ideas

Ideas for Google's Summer of Code

FIXME

http://en.flossmanuals.net/GSoCMentoring/making-your-ideas-page/

The GemRB core is written in a mix of C and C++, while the userfacing GUI and logic is glued together by python. Therefore, most of the ideas below assume you know C++, unless noted otherwise.

OpenGL renderer

IN PROGRESS GemRB currently only has a software renderer using SDL. An OpenGL version would help lift some of the performance loss, which especially noticeable on embedded platforms. Therefore an OpenGL ES / 2 version would be preffered. There is no 3d rendering involved.

The current SDLVideo plugin also deals with general SDL events and is closely tied to the core, so the goal would not be a separate rendering plugin, but a rewrite to use OpenGL exclusively. This way the task would not be overwhelming and would provide a good starting point for the future development of a separate plugin.

Experience required: OpenGL
Difficulty: Medium to hard.

Better support for different resolutions

The original IE supports only a limited amount of resolutions using separate data files for each. There is no scaling as it only adds fancy borders. That is understandable though, since all the fonts and sprites are ordinary bitmaps, so they would look blurry when upscaled.

The widescreen mod, our TTF font plugin and the out-of-tree downscaler are some of the work already being done to remedy the situation.

Scaling (output, better yet controls)? Better integration with the widescreen mod? FIXME: http://gibberlings3.net/forums/index.php?showtopic=23870

Experience required: no extra
Difficulty: Hard.

Rewrite DLTCEP for portability

STARTED, SLOW PROGRESS DLTCEP, the most complete game editor for IE, was written with old windows C APIs and is therefore not portable to other platforms. Luckily it somewhat works with wine, but that's only minor mitigation. The goal is to port it to one of the portable open source toolkits.

Experience required: knowledge of one of these toolkits, e.g. QT
Difficulty: Medium

Messagging system improvements

Currently we log (ingame) everything and have no infrastructure to support message filtering, delayed display, grouping or the PST special-named-case strings and hovering. Some more details are available on the todo page.

Experience required: no extra
Difficulty: Easy

Improved internationalisation support

All the strings in GemRB are stored in a dialog.tlk file with no encoding info. This makes it problematic to use with our TTF plugin and more complex (far-eastern) languages.

Goals: support unicode, support the female form (dialogF.tlk), FIXME

Experience required:
Difficulty: Medium

Performance improvements

(mos) tile cache, mmap()ed file stream, more more FIXME

Experience required:
Difficulty: Medium

Touch input improvements

Pinch and zoom (depends on OpenGL renderer above) and other candies? FIXME

Experience required:
Difficulty: Easy to Medium

Game selection UI

Create a GUI inside GemRB that would allow it to start without a config file, àla ScummVM. User would use it to locate their installed IE games, eventually set some GemRB-specific settings and then select a game and run it with GemRB. It should save the user-made configuration to config files to avoid entering it the next time.

It should probably be realized as a specific gametype, using some minimal IE resources for the UI.

Experience required: C++ to add missing bits, Python
Difficulty: Easy

Extract GameScript into a plugin

Much of storyline and ADnD rules in Infinity Engine-based games is implemented using scripts written in so-called [FIXME] BAF language. Our interpreter for those scripts, GameScript, resides for historical reasons in the core engine. It would be better to extract it into its own plugin, similar to FXOpcodes plugin. Reasons include better modularity, possibility to swap its actions and triggers for those suited to another game system and separation of the code from GemRB proper.

Experience required: C++, a bit of BAF for testing
Difficulty: Medium

Some other idea

Experience required:
Difficulty:

Your idea

Anything goes, but consult the developer community first if you want to have a chance at success.

Experience required:
Difficulty: Hard

developers/gsoc_ideas.txt · Last modified: 2015/01/01 23:12 by lightkey