• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
  • entries
  • comments
  • views

Managing Rendering Parameters

Sign in to follow this  
Followers 0
Jason Z


All rendering frameworks need to define and manage rendering data that is used to configure the rendering pipeline. The simplest example of this is an object supplying its world transform before it is rendered so that it appears in the right place in a render target. Of course, there are many more complex types of rendering data such as resource objects (i.e. textures/buffers) matrix arrays, samplers and so on. This is a non-trivial task if you want to make your framework flexible enough to handle data driven rendering configurations, since the engine won't know in advance which specific rendering parameters are going to be needed or used.

Hieroglyph 3: The Current System
Hieroglyph 3 uses a ParameterManagerDX11 class to provide a way to communicate rendering parameters from many sources to the rendering system. The data can come from the application object itself, a 3D entity that is being drawn, a material, or a render view (a render view is just a scene level rendering operation in my engine). All of the data that is available from these sources is written into a parameter system instance, which then stores the data for use by the rendering system. When it is time to render, each shader that is being used will request the needed data from the parameter manager and use it accordingly. Resource objects will be bound to the appropriate pipeline locations, vector and matrix data will be written into constant buffers, and so on until all of the needed data is bound to the pipeline. The pipeline can then be executed (with an appropriate draw call) to render the current object. Multiple instances of the ParameterManagerDX11 class can be created and chained together to allow for a complex system of parameters that is used across multiple threads - meaning that any changes to the classes have to be carefully considered in the grand scheme of things...

During the development of some of the samples for our book, we found that there was lots of time being spent in the parameter manager classes. In fact, in some scenes there was up to 60% of the frame time was spent in these functions. This can be a bit misleading since samples typically don't do much else besides rendering, but it is still something to be improved upon. The existing implementation basically just uses a std::map to store all of the parameters, where the string is the name of the parameter. This is clearly less than efficient, since using a string as the key to a map will be doing lots of string comparisons.

In addition, the filling of constant buffers is performed every frame regardless of if any data has actually been updated or not. This is of course dependent on what type of rendering is being performed at any given moment, but could potentially reduce the number of interactions needed with the API - so I will be investigating my options for how to improve the situation and only update buffers when they need to be.

Because of these points, I had made some notes about what to change after the book was completed - that's what I will be writing about in this entry...

Hieroglyph 3: The New System
The first step to improving the parameter system was to change the engine over to using an interface instead of an implementation reference. This will make it much easier to try out new implementations without completely hacking up the whole rendering system. This was fairly painless since it didn't involve any real new code, just creating a stub interface and doing some search and replace.

The task at hand can be thought of as two different parts. First I want to reduce the cost of looking up and using a parameter. Most likely it will involve creating a small structure to use for referencing parameters similar to the D3DHANDLE methods used by the Effects framework to directly get to the needed data instead of having to do a string based map lookup for every parameter. This is actually a little lower on the priority list than the second part of the task at hand: reducing the number of times that parameters need to be looked up in the first place. As mentioned above, I am currently naively filling the constant buffers every frame, which I think is introducing lots of unneeded work. Potential solutions will be to use a time stamp on the parameter data to see when it was last updated, or possibly using an actual system memory copy of the contents of the buffer so that I can do CPU side checks of the data.

So over the next couple of days I will be trying out some of these options and seeing what works for each of the two problems. Hopefully I can come away with a leaner system that still accommodates multithreaded rendering...

Sign in to follow this  
Followers 0


This is the kind of perf tuning that becomes fun and painful at the same time but there's no better motivator than watching a frame rate go up, up, up. Good luck. :)

Share this comment

Link to comment
Thank you for the encouragement :) I'm actually looking forward to the challenge since I have been waiting a good long while to take a whack at this topic... After working through some thought experiments earlier today, I have an initial plan of attack in mind. However, I just received the copy edited version of the book, and I now have a bunch more work to do on it now - d'oh!

Anyways, it won't be too long before I can get things straightened out a little...

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now