shaptic / zenderer Goto Github PK

Support for basic Lua scripting.

Draft and implement a management system for OpenGL shader programs. With all of the local gfx::CEffect instances, there is a lot of duplicate programs linking together the same shader objects.

• Draft manager
• Test manager
• Document manager
• Integrate manager

Create a more complete zen::math::matrix4x4_t class that supports translation, rotation, and scaling via vectors and other matrices.

• Translation
• Rotation
• Scaling
• Shearing

With commit df62bf0 and the closing of Issue #17 came a new problem that doesn't allow for anything but the model-view and projection matrices to be changed within a shader / effect.

The easiest and likely best fix would be to separate setting custom matrices and setting the standard ones.

zEffect::SetProjectionMatrix(const math::matrix4x4_t& proj) const;
zEffect::SetModelViewMatrix(const math::matrix4x4_t& mv) const;

zEffect::SetParameter(const string_t& name, math::matrix4x4_t& matrix);

Note which are const and which aren't.

Currently, the font API uses individual quads for every character, and thus causes a performance hit with the excessive state changes when rendering to a obj::CEntity instance.

The suggested model would use a texture atlas internally, thus speeding up rendering performance significantly. All changes should happen behind the scenes, so any documentation should properly transfer to the new functionality and the user should not see any changes in the way they use the API.

• Write texture coordinate offset shader
• Write new font API
• Ensure compatibility with old API calls

Implement a sort of "uniform lookup table" in order to minimize queries to OpenGL via glGetUniformLocation().

Something like this would be ideal:

GLuint gfxcore::zShaderSet::GetUniformLocation(const string_t& name)
{
    if (m_cache.find(name) == m_cache.end())
    {
        GLint loc = glGetUniformLocation(m_program, name.c_str());
        if (loc == -1)    // bad uniform
            return -1;

        m_cache[name] = loc;
    }

    return m_cache[name];
}

• Write high-speed stack memory allocator
• Re-write all uses of logging to use singleton access
• Update to GLFW 3
• Test audio API
• Work around existing shader deletion (one at a time)
• Allow variety of timer precisions to work with FPS delays
• Figure out why lighting shaders need the screen offset uniform
• Allow for loading assets via C-string literal (currently assumes void* when really string_t)
• Maintain reference to projection matrix in CRenderTarget instead of copy

Adding buttons to menus renders the wrong text for all buttons past the first one.

The current version of the material API is a convoluted interface with complex access to internal members and their respective functionality (CEffect and CTexture). There is too much pointer interaction and possibility for segmentation faults via nullptr access.

Possible ideas for improvement include:

• Inheritance of the components instead of composition
• Required initialization (use defaults if nothing)
• ZEN_FATAL errors when accessing a nullptr member

There are also issues with access to the CAssetManager necessary for loading the shaders and the CTexture instance internally.

There are a lot of issues passing around CAssetManager& instances right now, largely due to the fact that there are no high-level interfaces completed yet (I'm looking at you, CScene). Possible workarounds include:

• A default, engine-wide CAssetManager instance, that can be accessed similarly to CLog::GetEngineLog()
• Sucking it up and passing CAssetManager& in the constructor of any object that needs it, or via an AttachAssetManager(CAssetManager&) method if the object is an asset itself, or if it's optional, like in gfx::CWindow (thus storing a pointer since references must be initialized immediately). If there is nothing attached and some operation is done, a ZEN_FATAL error should be thrown, or something along those lines.

The current test-bed program crashes after exiting. In a debug build (ZEN_DEBUG_BUILD enabled), the relevant assertion is as follows:

glDeleteProgram(m_program) failed at line 284 of zenderer\src\coregraphics\shaderset.cpp: 1282 (invalid operation).

In a non-debugging build, on Windows, the program gives a runtime error indicating a "pure virtual function call," followed by an APPCRASH in MSVCR110.dll.

This crash only occurs if the user clicks the 'X' button to exit. If they choose the "Quit" menu option, there is no crash. It's unknown whether this is only for this specific program, or for all cases, thus the necessary to investigate the cause.

I believe that the bug is caused by a flaw in the engine resource management architecture. When a window is deleted, all OpenGL assets are invalidated. Later, when zen::Quit() is called, the routine will attempt to free all registered OpenGL subsystems (gfxcore::zGLSubsystem), and object destructors are called. This, in turn, will call gfxcore::zShaderSet::~zShaderSet(), which then attempts glDeleteProgram() on an invalid OpenGL program handle.

Re-design obj::zEntity to accommodate a variety of primitives (not limited to gfx::zQuad). This includes using gfx::zPolygon and collision detection via triangulation.

Potential ideas:

• Re-implement the gfxcore::zDrawable base class as gfx::zPolygon is, and have child classes such as gfx::zQuad just be 4-vertex specializations of the polygon.
• Allow any gfxcore::zDrawable object to be given to obj::zEntity and somehow appropriately handle each individual child class.

This milestone is dedicated to bug-fixes that are found post-alpha. It will be developed hand-in-hand with a game using the engine.

Create an animation API layered on top of obj::zEntity. Functionality should be something like this:

obj::zAnimation& Anim = MyScene.AddAnimation();
Anim.LoadFromFile("walk_sprite_sheet.png");
Anim.SetKeyframeCount(4);
Anim.SetKeyframeSize(math::vectoru16_t(24, 52));
Anim.SetKeyframeRate(120);

Which would create a four-frame animated entity from "walk_sprite_sheet.png", in which each frame is a 24x52 block. When updating the animation, a new key-frame will be loaded every 120 frames.

• Logging system
• Subsystem architecture
• Math functions
• 3D Vector
• .ini file parser
• Asset manager
• WAV sound playing
• Audio manager
• Settings module
• Shader wrapper class
• Write VAO Wrapper
• Plan rendering architecture
• Implement primitive drawing basics
• Test shader/effect wrappers
• Implement quad drawing
• Write lighting wrapper
• Implement texture loading (used stb_image)
• Write texture wrapper
• Write FBO wrapper
• Test FBO wrapper
• Write scene class
• Full lighting support
• Post-processing effect support
• Test all scene functions
• Implement entity drawing
• Implement font system
• Font loading (sub-task)
• Font rendering (sub-task)
• Font caching (sub-task)
• Convenience functions (sub-task)
• Implement basic physics-reactive entity
• Event handling:
• Mouse events (sub-task)
• Window events (sub-task)
• Keyboard events (sub-task)
• Easy menu creation
• Buttons (sub-task)

For easily creating games, a GUI level editor would be handy. There is a decent one already created for IronClad, so it may be useful to build off of that.

• Write level file format specification
• Write level loader
• Create level editor

Prefixing classes with C looks stupid, and is completely unnecessary with namespaces. But, it does appear valid when a user, for example, wants to create a Vector instance but cannot, because he has done using namespace zen::math. Thus Vector<int> Vector(1, 2, 3); does not compile. A "C" prefix just looks generic, so we will prefix with a lowercase "z" character, instead.

CVector -> zVector

User code:

using namespace zen::math;
zVector<int> Vector(1, 2, 3);

I need to integrate a custom physics engine into Zenderer prior to starting any real work on a game.

Necessary components:

• Basic structures
• Collision detection (AABB vs. AABB, circle vs. circle)
• High-level entity wrapper
• Material data (friction, mass, etc.)
• Integration
• Testing
• Documentation

Possibly look into integrating Box2D instead of rolling my own.