Category Archives: Card Kingdom

PBuffer and Post-Processes

I posted the following on the Card Kingdom development blog.

One neat concept I learned about while researching deferred rendering was the PBuffer. The PBuffer is used for post-process effects and contains at least two screen-sized render targets that are swapped between each other while rendering each post-process effect sequentially. The final image from one effect is used as input for the next, creating a daisy chain of accumulating effects. To expand the number of possible effects the PBuffer can support, half and quarter-sized buffers can be used to scale down the previously rendered effect and used to support other effects (e.g. bloom).

Controlling HTML Without A Keyboard or Mouse

I posted the following on the Card Kingdom development blog.

Since the beginning of the Card Kingdom, we’ve been using XBox controllers as the main sources of input for the game. The controllers afford us preexisting control schemes, analog movement, and support for multiple players at once. What it does not support is a way to interact with HTML in a standard, keyboard and mouse way. To support this, I’ve been working on a UI Paneling System, written in jQuery, that does not rely on a keyboard or mouse for interaction, while still providing a robust framework on which a user interface can be built.

Tool Time – Interactive Wave Editor and Lessons Learned

I posted the following on the Card Kingdom development blog.

Interactive Wave Editor

As the project nears completion, this will be the last Tool Time post, but I’m ending with a bang. A large part of Card Kingdom is its waves and their design. They are our main mechanic to convey progression and are used to teach the player how to play the game. Therefore, the design of these waves are incredibly important. Before how we were designing waves was on a whiteboard. We used different symbols representing each object type, labels for when and where objects would spawn, and tried to convey how the wave should flow through hand-waving and notes. We would then convert all that to fit in the XML Serialization of the wave, not really knowing exactly if the wave would work or the placement of objects were correct. This took time and a lot of guessing on the part of the designers, and was just an unpleasant experience all around.

More Lightning and Shadows

I posted the following on the Card Kingdom development blog.

More Lightning

In a somewhat recent post, I showed off the initial stages of the lightning effect that I’ve been working on. One of the major hurtles that was tripping me up, and the reason why in the old video it is hard to actually see the lightning, was the blend states in DirectX 11. There is a flag in the blend state descriptor called IndependentBlendEnable. If this is set the false, all render targets that are bound only use the first render target blend descriptor. For many applications this works perfectly fine. For others, this breaks everything. Well, not break per-se, but gives unintended, unwanted, and incorrect results. So, the issue that I was running into was when rendering the depth render target, the blend mode was set to additive. It was trying to additively blend the depth with an already existing depth value or zero from the depth render target. The fix was to specify IndependentBlendEnable = true and define the depth render target to use an alpha blend to overwrite any value that was previously rendered.

Transparency in Deferred Rendering: Narrowing Down the Research

I posted the following on the Card Kingdom development blog.

The research topic I am working on as part of the graduate program is adding transparency into a deferred rendering pipeline. If you haven’t noticed, I’ve been posting a lot about deferred rendering. The main reason I wanted to redo our old forward rendering pipeline as a deferred one is because it’s a new and interesting rendering technique. Learning and experiencing new techniques to keep up to date with the latest technology and practices is essential in the software field, let alone the highly volatile games industry.

Deferred Particles and Lightning

I posted the following on the Card Kingdom development blog.

Deferred Particles

As with other parts of the engine, the entire particle system was updated to use a similar deferred rendering method as the regular geometry. This really improves the look of the particles, in particular smoke and dust, as it gives them a more “volumetric” look. All the particles now interact with the lights in the scene just as the regular geometry does.

Tool Time – GDC and New Editor Features

I posted the following on the Card Kingdom development blog.

The Card Kingdom team was lucky enough to attend GDC, Game Developers Conference, in San Francisco a few weeks ago. We showed the game to a new audience that spanned the spectrum of students to industry veterans. The overall feedback we got on the game was incredibly positive. This was a huge boost to our confidence and cemented that our design choices were correct. Any negative feedback we took and plan on addressing in the upcoming build. The most frequently asked questions were “when is this going to be released?” and “what platform is it going to be released on?” We answered that we’re going to try and submit it to some competitions and see how far it gets. Beyond that, we have to decide what the next step for Card Kingdom will be after we finish our capstone.

Justin’s Winter Post-Mortem

I posted the following on the Card Kingdom development blog.

What I did

For this version of Card Kingdom, I worked on updating core engine components with some optimizations and cleaner code, refactored the serialization pipeline to be more robust with prefabricated objects, or prefabs as we called them, added an “editor mode” that supports in-engine particle editor and run-time resource reloading, and replaced the old forward rendering system with a new, more advanced deferred rendering pipeline that supports multiple post-process effects.

Tool Time – Particles, UI, and Resources

I posted the following on the Card Kingdom development blog.

Particle Editor and UI Communication

One of the newest features I’ve been working on was the in-engine particle editor. This was a great test for the communication from the UI to the engine, and back again. In developing, this was the “worst case” scenario for communication as there are many parameters that can be set for the particles. Designing a system that could handle this case, as well as simpler ones was vital in making the UI flexible and extensible.

The solution I came up with an event listener and caller system. Using our internal messaging system, components register themselves as event listeners to one or multiple events and can retrieve the event caller for the UI.

Deferred Rendering In Card Kingdom

I posted the following on the Card Kingdom development blog.

Background

One of the major updates to Card Kingdom going forward is a complete rewrite of the rendering pipeline. In the original version, the alpha version essentially, we used a”forward rendering” style for our rendering process. In a forward rendering system, all lighting information is calculated when the mesh is rendered to the screen. For scenes with multiple lights, the mesh would have to be drawn for each light and blended together to get the final image. For non-complex, low lighting count scenes, forward rendering is straight forward and works well. As the number of lights and the complexity of the geometry that is being rendered increases, the processing time drastically increases. The complexity can be modeled as O( n * m ), where n is number of triangles, meshes, objects to render, and m is the number of lights in the scene. Rendering times drastically increase when more lights and triangles are drown. This is why the number of supported lights is usually around 8.