Naming pickiness

Yes, I’m crazy about naming stuff, so I need to find the right conventions as I find it fit, probably will changed, but for now its ok. So, changed the naming for debug geometry rendering, dynamic geometry rendering, like lines, spheres, text, etc., all the functions start with dbg , example:

render().mainContext().dbgDrawLine(0, 0, 200, 300);
render().mainContext().dbgDrawSolidSphere(10, 20, 20);
render().mainContext().dbgDrawText(0, 0, "TROLOLOLO");

Such naming will separate the debug rendering code from other “normal” rendering code.
Old name for “debug” rendering code was “basic” :) .
Work continues on stabilizing the coding style of the core rendering functions. After that, I’ll get into more high levels stuff, like the entity component system.

Posted in Nytro Engine | Leave a comment

Hardware Instancing

Setting up to use true hardware instancing in OpenGL is not hard to do, as long as you know HOW to do it :) , but hey, its part of the challenge! So, got it working and I am impressed by nowadays power of the GPUs. Made some test with roughly 23 million tris on screen, per frame! not second. This will be awesome when I’ll get to vegetation rendering and other instantiated stuff.

Behold:

On the move! (over 9000! for sure, 125000 (503) more precisely):

 

Posted in Nytro Engine | Leave a comment

To D3D11 or not to D3D11…

I’m currently using the OpenGL render manager and after seeing that GL has most of the things I need, even the new stuff from D3D11, I wonder if I should keep D3D11 render manager, history says GL drivers are slower, but then again, it probably wouldn’t be such a hard hit on the engine anyway. I don’t want to get into religious wars here, D3D or OGL, but since I am planning to go OSX, Android, Linux and iOS, I am thinking on ditching D3D11 for now… what do you think ?

Update: D3D11 code zipped and shelved. Done.

 

Posted in Nytro Engine | Leave a comment

Bitmap Font creation and rendering

This one is an old nemesis of mine, and probably for many of you :) . The font rendering is done using a traditional bitmap per character technique. I am using Freetype to generate the glyphs (characters), and I’ve tried to use FreeImage_Paste function to blend (combine) two or more  characters on top of each other (this is needed to bake shadows and outlines in the font texture), which failed due to a bug in the library, so I had to write my own alpha blending function, when things began to look weird… After some research on how to do proper alpha compositing (link to PDF) and after looking in the DevIL image library ilBlit function, I have finally found the right formulas. The fonts looks good at even the smallest generated glyph size. It can have no shadow, simple shadow (you can specify offset) and outline. When rendering the font glyphs it just renders the character one time, with the baked shadow, so no need anymore to draw the text twice (black, for shadow + white for normal text). All in all, I am happy now with the results, and I can move forward with other things.

Some examples:

       
Coloring happens in the engine runtime (tinting the white font glyph quads/vertex color).

Posted in Nytro Engine | Leave a comment

Render Contexts, Simple Geometry Rendering and other demons…

Made the basic geometry rendering of simple debug gizmos and such, to run on many render contexts, each context has a buffer with the produced vertices and it puts the render commands on their queues (like drawSphere, drawLine, drawWireBox etc.).

The text rendering is also queued. When you call RenderContext::drawText, what it will do is putting the drawtext command on the context’s command queue with the text to be written, after that, when all contexts commands are merged and sorted, the renderer will take the text, the current text attributes and generate letter quads in a special vertex buffer only for text rendering. So, basically, text rendering is not physically happening when you call drawText(), but its deferred to the main thread render command queue processing, like all the other render context functions, making this scheme pretty nice for multi-render-context-multithreaded rendering…of things..

Amazing (!) multithreaded (!) rendering of basic debug geometry :) :

Aside that, I have changed the shader system a little bit:
- I dont use CgFX anymore, just plain Cg with
- There are no techniques and passes in the shader, only render methods. I think technique passes are sort of obsolete and since I was usually having one pass in the shaders, was kind of useless, plus going towards a deferred rendering approach, did influence this decision.
- Material is holding the render layers (which can be thought of as passes), but in a deferred renderer they will be used slightly differently.

A shader example:
File: shaders/basic.shader (JSON)
This file is the source file, it is compiled by the asset compiler into basic.nshader (bin)

{
    "description":"Basic unlit, textured/untextured shader,
 used for UI and debug rendering",
    "renderMethods":
    [
        {
            "name": "textured",
            "program": "../engine_src/programs/basic.cg",
            "vertexMain": "mainTexVS",
            "pixelMain": "mainTexPS",
            "constants":
            [
                {
                    "type": "worldViewProjection",
                    "name": "mtxWorldViewProjection"
                },
                {
                    "type": "texture",
                    "name": "diffuseSampler"
                },
                {
                    "type": "float4",
                    "name": "diffuseColor"
                },
                {
                    "type": "float2",
                    "name": "uvDiffuseRepeat",
                    "value": "1;1"
                },
                {
                    "type": "float2",
                    "name": "uvDiffuseOffset",
                    "value": "0;0"
                }
            ]
        },
        {
            "name": "solid",
            "isDefault": "true",
            "program": "../engine_src/programs/basic.cg",
            "vertexMain": "mainVS",
            "pixelMain": "mainPS",
            "constants":
            [
                {
                    "type": "worldViewProjection",
                    "name": "mtxWorldViewProjection"
                },
                {
                    "type": "float4",
                    "name": "diffuseColor"
                }
            ]
        }
    ]
}
Posted in Nytro Engine | Leave a comment

Multithreaded render contexts

Renamed ‘gfx’ to ‘render’ :) .
I am stripping all operations that can be queued from render manager to a render context class, so many threads can use their own render context and render in parallel, they would actually write render commands to a local command buffer, in the end all render command buffers, from the threaded render contexts, would be sorted and dispatched either on a single thread execution in the graphics API, or for example in D3D11 on many device contexts to take advantage of the parallelism.

Another interesting fact is that I tend to go back to C coding style, using structs and simple functions, which are relatively easy to put on many threads, since C++ OOP tends to, well, create hierarchies, but you can keep a max of 1-2 levels of inheritance, which can be fit to multi-threading. The C language itself allows the coder to focus more on flat data lines, all in all its simpler to look at and fit into the worker threads.

Posted in Nytro Engine | 2 Comments

Dropping the D3D9 renderer

Keeping 3 renderers in sync its kind of a boring and time consuming task, and I have decided that D3D 9 renderer plugin to be dropped. There are new concepts in D3D 11  that I think will pave the way of graphics in the future. Same for OpenGL, I will use the 4.0 version features (since it seems to provide compatibility with OpenGL ES).

So there we have it: DX11 and OpenGL 4 rendering only :) , I guess should be enough, and when the engine would go public I’m sure DX15 will be out anyway :) .

Goodbye Direct3D 9, was a a fun ride, you will not really be missed though…

Posted in Nytro Engine | Leave a comment

Shaders

I hate that shaders can be written in so many ways, its too much freedom :) , also now that I support 3 APIs, DX11, DX9 (which will get deprecated in the engine) and OpenGL (+ ES), with 3 different shader initializations and pre-compiling, with several Cg profiles to take care of (Shader model 3 4 5), its becoming complex, but hopefully the system I have now can cope with it. I have eliminated Cg from runtime, now its in the asset compiler which bakes Cg shaders into hlsl and glsl. Deleted alot of code from the graphics manager, trying to keep things simple for the developers and me :) . Also got some time spent with the entity system, wrote and/or converted Camera scene node to a component, and the scene node to a SceneObject, because I dont want to use node and graph words anymore, since it will not be a true scene graph on the rendering side, but mostly some local trees scene objects with children scene objects (a scene object is also a component). Entity does not contain transform information, you need to add the Transform component to have a positionable entity. For example saw that Unity has a forced Transform component attached to a new object, and afaik, you cannot delete that component. Anyway, nice changes, and virtually ready for the platforms: Windows, Linux, MacOSX, Android and iOS. Stay tuned.

Posted in Nytro Engine | Leave a comment

OpenGL + CgFX texture/shader drama

So I was implementing the OpenGL renderer, all was going well, until I needed to show a textured quad for testing. I am still using Cg in the runtime, which is not a happy situation for speed, but for now it will do it, in the future I intend to compile with Cg and store the asm into the final production file. So, while testing, the texturing didnt work, and found out that the Cg runtime was requiring the sampler name and not the texture name in the CgFX file, but did worked on the DX9 side. Oh well, just another thing to be aware. I will change it to offline Cg shader processing ASAP, in the NAC (Nytro Asset Compiler).

Posted in Nytro Engine | Leave a comment

Component and entity system (and MacOS X)

The engine is using now a component based approach for game entity composition. Also it compiles on MacOS X, but it still needs an OpenGL (ES) renderer.
There is no Scene, World or other major class. There is a SceneRenderer component which is gathering the render packets to be rendered from the entities and their components.
Deleted a lot of code, shrinked and simplified the game manager,  easier and faster to use right away to create games.
Worked on the Nytro Project Manager tool, which will basically manage a .project file, where you will specify a game project with all its dependencies (game data folders, the runtime game class name, levels, etc). This manager will be used from within Nytro Studio too (the main game level editor of the engine).

Posted in Nytro Engine | Leave a comment