EAE 6320-001 GameEngII Game Engine Project, Game Dev Adventures!

Assignment 4: Utilizing Game and Render Threads for Improved Performance

NancyNewren_ExampleGame 4

Now we’re getting somewhere! The game can now render an arbitrary amount of sprites per frame. In this instance there are four. I think it’s pretty. 😉 (Simple one-click download. Once downloaded, unzip, play the executable, enjoy!)

About the Project

The simplest part of this project was letting the game submit to the graphics a different background color. This data is cached until the renderer is ready to render.


I moved all the sprites and effects out of the graphics class and created them in the game. Because rendering takes a significant portion of time in games, we utilize threads to render while the game computes data. In this implementation the game submits to the render data it wants rendered, which is then cached by the renderer until it’s ready to render. When the game is done submitting it lets the render thread know. When the renderer has finished rendering all the previously submitted data it cleans up that data and let’s the game know when it can start submitting again. This is the point where the threads sync, which is done each frame. At sync the render thread swaps the submitted cache and the cache it just cleaned. It then uses this data to render, and the game has a clean cache to submit data too. Submitting to the render thread is simple, just send over the sprite with its corresponding effect:

eae6320::Graphics::SubmitToRender(m_sprite[0], m_effect[0]);

Each rectangle needs it’s own sprite, but an effect can be used multiple times. So the second sprite uses the same effect:

eae6320::Graphics::SubmitToRender(m_sprite[1], m_effect[0]);

I am using the stl’s vector to create as many (up to the maximum number that a vector can hold that is) sprites and effects as I want. It’s then fairly trivial to submit sprites and effects to be rendered to the render thread.

Even though we are passing reference pointers around for all the sprites and effects, since we can send an arbitrary amount of sprites and effects to render the memory overhead can get large if we haven’t optimized their size. I had previously optimized the sprite and effect size by ordering member variables from largest to smallest. However when I saw the sEffect size I realized I was passing around unnecessary data. I removed it and the size dropped by the size of the variables I removed.

sizeof(sSprite): 12
sizeof(sEffect): 24, 16

sizeof(sSprite): 24
sizeof(sEffect): 64, 48

I’d only ever looked at the size of objects via code, so it was interesting to me to look at it during compile time. I opened the Debug->Windows->Immediates window in Visual Studio, put in an obvious breakpoint and when the debugger paused, I typed in “sizeof(ObjectName)” and the immediates window printed it out. Thanks to Mark Smith for helping me find the Immediates window.

I am having a recurring Visual Studio run bug. I spent quite some time trying to resolve it. J.P. tried to help as well for a while with no luck. I finally reverted all our changes, closed VS, and rebuilt and the bug went away. The thing is that I’ve done this multiple times and it keeps coming back. Running and building in Visual Studio haunt me and give me terrible nightmares.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s