Over the last couple weeks, I’ve been adding several workflow improvements to Shader Foundry. Now that these improvements have been completed, I figured that it would be a good idea to take this opportunity to post some details about our shader export tool.
There is a new page in the Tools section that gives a simple overview: Tools / Shader Foundry.
I also posted an article discussing the history and improvements: Shader Foundry.
Over the past couple weeks, I’ve been working to update Sauce to take advantage of a couple of the features of “modern C++”. While the time investment has been pretty significant, I feel that the new features are substantial improvements.
First, I converted all of our enums to be scoped enums (introduced in C++11). This was more time consuming than I had expected, but well worth the effort.
I wrote up a detailed account in a separate post: Scoped Enums.
NULL with nullptrAlso, I replaced all instances of NULL with nullptr (introduced in C++11).
Similar to many other C++ code bases, our forced include file Core.h defined NULL to 0. Unfortunately, since this is simply an integer and not an actual null pointer, using NULL can hide bugs. In fact, during the transition to nullptr, I found a few silent issues lurking in our code base.
Further discussion can be found in this post: Nullptr.
During the past several months, I’ve been working on overhauling our UI system. As a final step, I wrote a new article comparing the old Interface library (UI 1.0) and the new system (UI 2.0): User Interface 2.0.
This redesign took pretty much all of my coding time since the previous update. Next up on the list is some cleanup and then on to Animation!
It’s been a long while since our last update post. A lot has transpired since then so I’ll try to do my best to outline the highlights.
First and foremost, we re-architected how input is delivered throughout the engine. Previously, the input state was fetched from the devices and packaged into a single data object, which was then passed to whatever systems required input. While simple, this paradigm had many drawbacks, which I hope to discuss at length in a future post.
The new system is event driven. This allows us to employ a layer system, where “higher” layers in the stack can consume input events so that “lower” layers don’t try to handle them as well. A system like this is essential for games that have interactive UI elements overlaid atop the game scene.
This was by far the most significant change we have made in the last year or so, but it is well worth the benefits it affords us.
We added a Compress library. At present, this is a light wrapper around zlib, though it could include other compression algorithms in the future should the need arise.
Our primary use case for compression was our proprietary asset file format: the Sauce Engine Assembly (*.SEASM). Below is a table comparing the results between our uncompressed and compressed file versions:
| Model | SEASM v1 | SEASM v2 | Diff |
|---|---|---|---|
| Pawn | 80.47 KB | 31.66 KB | 39% |
| Bunny | 1.73 MB | 1.14 MB | 66% |
| Dragon | 21.66 MB | 11.94 MB | 55% |
We added a new type of input stream to the Streams library: VolatileInputStream. This allowed us to significantly shorten our file load times. You can read about the details of the VolatileInputStream in the Streams post.
We spent a good amount of time solidifying our FBX model importer. It can now load geometry and basic material data from Blender. Extracting data from the FBX SDK in a robust manner is no easy feat.
Also, a lot of progress was made on extracting animation data as keyframes from FBX, yet, sadly, this is still incomplete.
Thanks to the event driven input system, the Interface library now has keyboard support. We also added a primitive implementation of focus.
Furthermore, we reworked how the Anchor property affects the control placement and added the ability to “dock” controls. The result is that controls can now be arranged in the same way that .NET supports.
We also finally added a TextBox control. This was the last of the “standard control set” we had been hoping to implement. A TextBox has a lot of functionality under the hood to make them work as expected: text input, caret movement, selection, and even Clipboard support (Ctrl+X, Ctrl+C, Ctrl+V).
The most recent addition to the engine is the JSON library. We now use JSON as our config file format (previously they were XML). You can read about the details in the JSON post.
Last but not least, we migrated to from Visual Studio 2010 Express to Visual Studio 2013 Community Edition. This is fantastic! As soon as we found out that the new edition was released and offered the same feature set as the professional versions, we jumped on it.
This required a few changes to our VSGEN tool which generates the project and solution files with our configuration settings.
For the past few weeks, I’ve been working through a pretty big design change. One of the features we’ve always wanted is the ability to allow users to set their own configuration — in essence, the “Options” menu.
I’ve primarily been working on “Display Settings” (resolution, window mode, antialias level). Previously, our Graphics classes provided routines to set these properties individually, but what is really needed is a way to set the entire group at once. This is because there are two common use cases:
In both cases, the settings are passed to the Engine as a group.
I’m happy to report that the “Display Settings” can now be set as a group at both startup and during run-time (tester screenshot above). It seems like such a little thing, but I think it’s really cool to have that capability in our Engine.
I plan on doing a detailed write-up on this subject in the Engine section.
Lots of improvements to the structure and appearance since the last “news” post.
Posted the first non-news post: Assert. This article is a repost of an entry I made on my personal blog back in 2008. The content is still relevant — in fact, we use the same assert code in Sauce. I hope readers find it useful.
Added new pages to the Tool section:
We’re still getting a few things squared away before we begin to fill out the content. But first I wanted to take a moment to introduce ourselves and the site.
No Remorse Games was founded in 2010 by Alex Kozlowski and Joey Hammer.
Since its inception, No Remorse Games has been a side venture where we could have fun, learn, and experiment. In short, it was paramount that we enjoy working on the project.
Originally, we were working with XNA, and eventually that grew into a concentrated effort targeting Windows Phone 7. Ultimately we found that our passion for the project had been drained, and in Spring 2013 we decided to drop the effort in XNA entirely.
After some retrospection, we decided it would be more enjoyable to change direction and concentrate on our strengths: so we set out to write our own game engine and tools from scratch.
Our goal for this website is to provide some insight into our development process and showcase the results.
Over the years we’ve learned a lot writing software for 3D games and tools, and we’d like to share our viewpoints and many of the lessons learned. That said, it should be no surprise that we’re still learning and experimenting, so we hope to document the progress here as well.
We hope that readers will find what we have to say here informative and inspiring.