This is one came out of our preparation meeting in Hamburg. We can start working on it right now, the deadline however would be the on the openclonk weekend. If you feel that we missed out something important, post it here.

(cursive: in progress; crossed out: done)

What Must be done

Stuff that we must do before a release

Scenarios: Reorganize scenarios into more self-descriptive categories (arena, parkour, settlement). Move scenarios that are not mature yet into Test (Mt. Brane, Skylands).

Rendercode: Adapt the mesh loader to the newest version of the OGRE mesh format to be useable with the newest exporters again. At least, fix the FIXMEs that turn up while loading the models. (Clonk-Karl)

Script engine: Fix the crash(es) on the end of a round. The crash is only regularly reproduceable on Windows, however, it also turns up using valgrind.

Controls customization dialog: While it does not work properly, hide it in the release version.
Instead, create a control set for the US-keyboard. (Newton)

Tutorials: check if the new controls are sufficiently explained in the tutorials and add any missing explanations

What Can be done

Still important but shouldn't be the reason to delay the release

Documentation: Fix the automatic documentation builds (if they are really broken)

Automatic release: Create a method with which the other developers can automatically create a release version with a press of a button. (Clonk-Karl, Newton)

New Control changes: Test Günther's changes to the controls and change what's not good yet

Scenarios: Create more uniform infos (descriptions, titles?) for all the scenarios in both German and English

GUI: Clean up the main menu - Remove Splash.c4v, adapt some strings for OpenClonk, ... (Newton)

Settlement concept: Finish it or at least advance it since this is the content for the next release. What f.e. has to be done in the art department is the cotton plant (see Fungiform's sketch), texture for the kitchen, armory and shipyard. More info what is left to do should be linked [url=]here[/url]. Also, contact Dragonclonk in that matter as he seems to be quite able as his environment pack for OC shows.

Controls customization dialog: What seems to be missing is localisation, setting mouse controls and a way to set multiple controls with one item (example see Collect). Interview Sven2 what has to be done and where the difficulties are, how we can reach a version that can be finalized for now. (Sven?)

Player controls: It must be possible somewhere to look up the controls in OpenClonk. If the above task cannot be completed, at least the controls explanation should be linked from the FAQ. Also, showing an image/text on the controls page instead of the configuration dialog that shows the default controls is possible.

What Should be done for the next release (5.4)

Important but too much of a hold-up to be included in this short-term release

Rendercode: Find out what is the bottleneck in Clonk (rendering) performance and optimize the code

Shader: Landscape lighting and landscape normal mapping (Peter)

What Could be done somewhen in the future

Interesting stuff but nothing that should hinder OC development

Engine ropes: A better and performant implementation of ropes and lines (Clonk-Karl)

Player controls: A next iteration of new controls (boni)

Rendering engine: Scout out if it would be feasable to use OGRE3D for parsing and rendering the ogre meshes. Interview Isilkor in that matter.

Script engine: Use floating-point (JCaesar)

Documentation: Write a tutorial for how to add lokalisation to the c4script-documentation

>Rendercode: Find out what is the bottleneck in Clonk (rendering) performance and optimize the code

Guenther gave me the idea today to run Clonk through a OpenGL profiler program (gDEBugger GL).

random output (where is the "export warnings"-button :/ ):

You draw 0.0122% of your vertices with 1.51% of your batches
You draw 2.9116% of your vertices with 90.33% of your batches
You draw 65.7666% of your vertices with 0.84% of your batches

It is good practice to draw as many vertices using as few batches as possible. Doing so will usually improve the application's rendering performance.

-A lot of warnings like:
Deprecated Feature:  Fixed Pipeline Vertex Processing

-And a lot of warnings like:
This function has a very high percentage of redundant calls
[see export file]

-warnings about GLBegin and GLEnd

-Using glGetError and similar functions slows down render performance and are unneeded for purposes other than testing.

-Functions that retrieve data from OpenGL are considered Get functions
Using "Get" or "Is" functions slows down render performance. These commands force the graphic system to execute all queued OpenGL calls before it can answer the "Get" or "Is" query.
-An OpenGL render context is a huge state machine. OpenGL offers many commands that manipulate state variable values. Setting a state variable to the same value it had before the set operation is considered a redundant state change.


That program also allows me to export the call history of all OGL calls (but the file from my test is too huge) :o

here is an export from the statistics tab, it shows f.e. the redundant calls: