 |
Nytro Game Engine Development Blog |
game engine development ramblings |
Made the font_baker.exe command line utility to bake font characters into a texture and output a JSON file with the character position and sizes in the texture. It supports unicode character ranges and kerning pairs. Using Freetype for this one.
Font texture (will be packed more tightly if needed in the future by some bin packer algos / atlas packer):
And some test rendering of the font text, observe proper char spacing and kerning:
For the game data, I’ve chosen to have a data source folder and a final data folder. The engine will load binary data, optimized for the given platform. The tools and editor will work with “fat” data, as JSON text files and source data from FBX, PSD. etc.
The NAC (Nytro Asset Compiler) command line utility will take as input the source folder and output the final data folder and it will compile the data. It can skip files not needed to be compiled or it can be forced to compile everything.
The engine runtime loads only optimized and binary data.
I have also made a font baker, which generates a texture with glyphs and a corresponding JSON .font file with info about the glyphs. It supports Unicode characters. The utility uses Freetype to generate the glyphs, so its quite cross platform.
Simplified initialization of the engine, multi-game development in the same engine folder, added project files for a game project which specifies per-game settings, used by game deployment tool and editor/tools.
Other details coming soon!
Things are progressing, alot of changes being made right now, hopefully for good puposes.
Here are some changes I am making to the engine:
- get rid of STL for runtime and use custom containers and string classes (faster compile, more control over the container/string features)
- use strings only where needed (faster code, less memory(or mempool) fragmentation)
- use IDs instead of names, for various objects for the runtime (faster checks/lookups and data loading)
- separate subsytems so they will not use pointers, but handles for the objects (better for making them as multi-core jobs)
- use #pragma once instead of old school .H guards in headers (the header looks cleaner and pragma once is supported by the major compilers)
- split files with multiple classes in separate files (faster compilation)
- putting the variable system to good use, for settings, runtime tweaking and so on (aka console variables)
- using alot of forwarding and avoiding including too many headers in one header
- not using precompiled headers (promotes cleaner headers)
- shortening all the names to reasonable lengths (Ex: getGraphicsProvider()->getCamera() to gfx()->camera() )
And many other things I will post in the next posts. As always, stay tuned..
I know, the dreaded “refactoring” word, but its part of the learning process, plus it makes things exciting.
So, the engine will be refactored in such a way that you would not need STL, and even strings in the engine’s code, I will use a hashed id system for resources, data, as few pointers as possible, and no parsing or expensive dynamical things at runtime, assets will be always cooked to highly optimized production formats specific to each platform, easy to load and feed to the job system.
I will have to revamp some old container code to replace STL, imho STL is good for offline processing in tools, when speed is not such a critical factor and it helps faster development of tools and source data file formats.
Since major systems will be rewritten, I will try to keep the blog updated with the changes I make.
This “revelation” was started by some DICE’s presentations and some other internets reads like http://BitSquid.se .
In the past the engine was not emphasizing on speed too much, but I think its time I go into optimizations more, a good reason to learn new things also. Stay tuned for some architectural decisions blogging.
While attending GDCE 2011, I went to some talks about multi threading engines, and I thought I should split and multithread the engine’s subsystems, making them independent data-wise.
Another thing is high quality rendering, brought to extremes, no legacy support for lower end machines, DX11+, target rendering quality: (CGI movie) http://www.youtube.com/watch?v=VCTtIIW1WA0
Editor side, command based editor, empty at first, then UI filled up by plugins. As for the GUI SDK, Qt will be used.
Also trying to clean up the code, to release an alpha SDK for people to play, its not written in stone, but lets hope I will do it.
With the grow of Android and iPhone, I had to keep up also, so the engine is now relatively easy to compile using CMake project files generator, on Windows, Linux, MacOS, iOS, Android and maybe XBox (but I do not own a XDK, yet), no PS3 because is a hell to develop for..
Cleaned up the engine, secured code with some more const-ness, and researched Qt for editor UI, so far I’m pleased by the functionality and free licensing, so I will probably make the editor in Qt. The editor functionality is separated from UI, so it will not be a full editor rewrite, just the UI itself.
Renamed some longer file extensions, and stripped out the DevIL image library from the engine, now the engine only loads a custom texture format named .NTX, which contains images slices (1 slice if a single texture, or 6 if cubemap) and their mipmaps. The format will be documented. This move unloads some size from the final nytro.dll/so, makes it smaller.
Also by using this new building system, there is also full static libraries, so you can link engine+game+plugins in one single exe.
Another idea is to make the editor be usable only with one hand a the mouse 
, having alot of gizmos inside the scene will help that, and less toolbar buttons.
News and screenshots coming soon, thanks for all who watch this blog, it keep me walking further with this!
Since eons ago, game editor GUIs was always a problem for me, but in the recent weeks I just said I will not change again and again the editor UI, because it will take, well, forever to finish the engine and editor this way, so lately I am finishing editor features, bearing in mind that I will not modify or delete them again, writing them in stone…
The current (and FINAL!) layout of the editor is based only on old school toolbars, with drop down panels for some buttons, and docking panels for the various editor tools (cinematics track editor, properties, flow graph editor, etc.)
Some small but utilitarian features are in the development, and also the editor’s *final* UI layout and mechanics.
- a Clock class, which will hold some standard timers (gameplay, gui, user) and user defined, used for computing inter-frame delta time, for frame rate independent movements/animations (there was just a central timer, but many timers are useful when you want for example to freeze the game and still use the UI or other system)
- a values smoothing class, used to smooth mouse movement and frame delta time
- speeding up level loading
- new simple icons for editor tools
- FBX support started to be integrated
and many other small and big things.
So, as always, stay tuned for news and screens
Working on HDR testing and stabilizing the code for xml-driven render pipeline, so you can make any kind of pipeline in XML, for rendering the current scene (forward rendering, deferred rendering). The render pipeline XML looks like this sample:
<pipeline name="dx9_HDR">
<maps>
<map name="sceneMap" format="rgba16f"/>
<map name="downsampleMap" scale=".25" format="rgba16f"/>
<map name="blurMap" scale=".25" format="rgba16f"/>
<map name="finalMap" scale=".25" format="rgba16f"/>
<map name="depthMap" format="rgba16f"/>
<map name="randMap" format="rgba32" file="engine:textures/noise.dds"/>
<map name="ssaoMap" scale="0.5" format="rgba32"/>
</maps>
<stages>
<stage name="renderSceneDepth" active="true">
<bindTarget map="depthMap"/>
<mapAlias map="depthMap" alias="#lastTarget"/>
<clearTarget colorValue="1,1,1,1" />
<renderScene material="engine:materials/depth.material.xml"/>
</stage>
<stage name="renderScene" active="true">
<bindTarget map="sceneMap"/>
<mapAlias map="sceneMap" alias="#lastTarget"/>
<clearTarget colorValue="0.6,0.7,1,1" />
<renderScene />
</stage>
<stage name="postprocess_0" active="true">
<bindMap name="tex0" map="#lastTarget" />
<bindMap name="tex1" map="downsampleMap" />
<bindMap name="tex2" map="blurMap" />
<bindMap name="tex3" map="finalMap" />
<bindTarget map="ssaoMap"/>
<bindMap name="tex0" map="depthMap" />
<bindMap name="tex1" map="randMap" />
<renderQuad material="engine:materials/post.material.xml"
technique="SSAO" />
<bindTarget map="sceneMap2" alias=""/>
<bindMap name="tex0" map="ssaoMap" />
<bindMap name="tex1" map="#lastTarget" />
<renderQuad material="engine:materials/post_bloom.material.xml"
technique="BlendSSAO" />
<bindTarget map="downsampleMap" />
<renderQuad material="engine:materials/post_bloom.material.xml"
technique="DownSample" />
<bindTarget map="finalMap" />
<renderQuad material="engine:materials/post_bloom.material.xml"
technique="FilterHdr" />
<bindTarget map="blurMap" />
<renderQuad material="engine:materials/post_bloom.material.xml"
technique="GlowH" />
<bindTarget map="finalMap" />
<renderQuad material="engine:materials/post_bloom.material.xml"
technique="GlowV" />
<bindTarget map="" alias="#lastTarget" />
<bindMap name="tex0" map="sceneMap"/>
<renderQuad material="engine:materials/post_bloom.material.xml"
technique="FinalComp" />
</stage>
<stage name="ssao" active="false">
<!-- remember last target -->
<mapAlias map="#lastTarget" alias="#lastImage"/>
<!-- bind and render SSAO -->
<bindTarget map="ssaoMap" alias="#lastTarget"/>
<bindMap name="tex0" map="depthMap" />
<bindMap name="tex1" map="randMap" />
<renderQuad material="engine:materials/post.material.xml"
technique="SSAO" />
<bindTarget map="downsampleMap" />
<bindMap name="tex0" map="#lastTarget" />
<bindMap name="tex1" map="downsampleMap" />
<bindMap name="tex2" map="blurMap" />
<bindMap name="tex3" map="finalMap" />
<renderQuad material="engine:materials/post_bloom.material.xml"
technique="DownSample" />
<bindTarget map="blurMap" />
<bindMap name="tex0" map="#lastTarget" />
<bindMap name="tex1" map="downsampleMap" />
<bindMap name="tex2" map="blurMap" />
<bindMap name="tex3" map="finalMap" />
<renderQuad material="engine:materials/post_bloom.material.xml"
technique="GlowH" />
<bindMap name="tex0" map="#lastTarget" />
<bindMap name="tex1" map="downsampleMap" />
<bindMap name="tex2" map="blurMap" />
<bindMap name="tex3" map="finalMap" />
<bindTarget map="ssaoMap" alias="#lastTarget"/>
<renderQuad material="engine:materials/post_bloom.material.xml"
technique="GlowV" />
<mapAlias map="#lastImage" alias="#lastTarget"/>
<bindMap name="tex0" map="#lastTarget"/>
<bindMap name="tex1" map="ssaoMap" />
<bindTarget map="sceneMap" alias="#lastTarget"/>
<renderQuad material="engine:materials/post.material.xml"
technique="SSAOComp" />
</stage>
<stage name="final" active="false">
<bindTarget map=""/>
<bindMap name="tex0" map="#lastTarget"/>
<renderQuad material="engine:materials/post.material.xml"
technique="ShowMap" />
</stage>
<stage name="renderScene1" active="false">
<bindTarget map=""/>
</stage>
</stages>
</pipeline>
Working on the editor’s looks, less buttons, less complications, more intuitive and faster usage, also implementing the tools inside the editor as plugins. More work is done on the asset compiler (NAC) and gameplay code (physics hit sounds, sample FPS player movement, game entities)