The virtual file system should support read only zip archives.

This class will be used to describe a complete render target, ie what draw targets it should, depth attachments etc .. this is then used to initialize an fbo, getting rid of all the various initialization methods that are currently in use.

A function in ShaderProgram to get the uniform location for an alias, for example if the following uniform is declared uniform(vec3, myLightPosition, LightPosition), then GetAliasedUniformLocation("LightPosition") will get the uniform location of myLightPosition.

HasUniformAlias is just used to check if a specific alias exists :)

Create a simple test application showing a cube or something to test the mesh, shader and texture systems.

Will probably find a few bugs while doing this as nothing has been tested yet :D

More specificallly optimize the Matrix4[] array methods for the garbage collector.

Instead, expose a single ProcessCommands method that can be run from the outside. The rendering backend will have to be constructed on the main rendering thread.

Renderer resource transfer & creation will be done in ProcessCommands. With a time limit just like it currently is.

But the public interface to add commands to the work queue will be remove.

// Add
public void ProcessCommands();
// Remove
public void AddCommandToWorkQueue(Action workItem);

The high level sub systems like Triton.Graphics should use custom math classes, projects that use these sub systems should not have to reference OpenTK directly. I will probably use much of the basic OpenTK math classes however or maybe look into the math classes in SlimDX or SharpDX, I think they were quite nice :)

Let's get the bandwidth requirements down.

• EmptyWindow (Done)
• Mesh Loading
• Simple scene with box and physics

Move functionality to content processors instead.

This can cause the respective OpenGL functions to execute on the wrong thread. They must be executed on the main thread that owns the GL contexts.

Not sure if I want this :)

Ie in the graphics system CreateMesh, CreateTexture etc. should have some kind of callback to indicate that they are done.

These callbacks are then used in the resource management system. This will allow us to check when all resources have been loadede etc.

Suggested callback in graphics subsystem:

// int => resource handle, bool => success, string => error messages
Action<int, bool, string> ResourceInitialized

Suggested callback for resource loaders:

Action<Resource> ResourceLoaded

Get the shader compilation status code instead of parsing the actual stored error messages. This will make the code a bit cleaner.

The OnLoaded callback is guaranteed to run on the renderer thread so this is a good place to do it.

This is going to involve a lot of work. A lib for the actual animation, the mesh file format has to be extended with bone information or maybe separate files for animations/bones is enough?

This should not be part of begin instance, implement separate methods instead.

Spot
Point (cube maps, with geometry shaders?)
Directional (PSSM)

PCF filtering or maybe something else like ESM or VSM?

Support in content processor + physics layer.

This is used to implement SpriteBatch classes, particle systems and other kind of dynamic renderers.

class BatchBuffer : IDisposable {
    public BatchBuffer(int intialVertexCount);

    // Begins rendering of a new batch
    public void Begin();

    /** Methods that add data to th vertex buffer **/
    public void AddVector3(float x, float y, float z);
    public void AddVector3(ref Vector3 v);

    public void AddVector4(float x, float y, float z, float w);
    public void AddVector4(ref Vector4 v);

    // Adds a triangle to the index buffer
    public void AddTriangle(int v1, int v2, int v3);

    // Flushes the buffer and uploads the data to the gpu
    public void End();

    // Internal resource handle, should probably not be managed by the resource manager?
    public Resources.Mesh Mesh { get; }
}

I need a test mesh, maybe a cube? :)

Plugins, output/input should be defined here.

Maybe use assimp for this?

It should support inheritance, efficient saving of derived templates would be cool as well (ie only write changed values).

A game object is just a list of components, the components should probably implement the serialization explicitly. But an automated solution could work. ServiceStack might work nicely for that if we can customize it enough to work with the inheritance feature.

Proposed json syntax:

// object_templates/base_crate.tmpl.v
{
    "components": [
        {
            "type": "Mesh",
            "filename": "models/crate"
        },
        {
            "type": "BoxRigidBody",
            "length": 1,
            "width": 1,
            "hiehgt": 1,
            "mass": 10
        }
    ]
}
// object_templates/heavy_box.tmpl.v
{
    "parent": "object_templates/base_crate",
    "components": [
        {
            "type": "BoxRigidBody",
            "mass": 100
        }
    ]
}

Start with basic frustum culling, maybe implement some better methods after that?

Yeah, returning null is probably a stupid idea ... :)

Need to support custom vertex formats somehow. Necessary for particle systems, sprites etc that need vertex color and usually do not need normals or tangents.

Probably because the window is already destroyed ... We still want to exit nicely.

We need a stage system in the graphics subsystem. Graphics entities will be created on the stage, each entity should have a location and orientation, or maybe just a world matrix.

The stage will then be used to feed the graphics backend and render the scene.

This will allow mrt's to be used. The preprocessor has to be extended to detect shader outputs. ie something like:

out(vec4, oColor, 0);

The last parameter will determine the color output index.

It should be possible to create render targets in the render system.

Proposed interface

int CreateRenderTarget(int width, int height, PixelFormat pixelFormat, int textureHandle, int? depthTextureHandle)
void ResizeRenderTarget(int handle, int width, int height)
void DestroyRenderTarget(int handle)

This interface will work for now, in the future we will want support for MRT and maybe shared depth buffers, stencil targets etc.

I will use Jitter physics for this, just make a semi nice wrapper so that it can be exchanged if necessary.

Should probably use CSM or PSSM

Processes assets in the Media folder and puts them in the Data folder.

Start with texture and mesh processing.