Shantanu Pandey
  • Projects
    • Hard Light Vector
    • Memory Manager
    • Samurai Crusader
    • Dyslexia VR
    • Geriatric Depression Suite
  • Prototypes
    • Game Mechanics
    • Diana's Inferno
    • MakeUp & BreakUp
    • 10Pest
    • Ninja Pinball
  • Blogs
    • Sic Parvis Magna
    • Game Engineering - Week 1
    • Game Engineering - Week 2
    • Game Engineering - Week 3
    • Game Engineering - Week 4
    • Game Engineering - Week 5
    • Game Engineering - Week 6
    • Game Engineering - Week 7
    • Game Engineering - Week 8
    • Game Engineering - Week 9
    • Engine Feature - Audio Subsystem
    • Final Project - GameEngineering III
    • AI Movement Algorithms
    • Pathfinding Algortihms
    • Decision Makiing
  • About

Week 4 - 12/09/2018

9/19/2018

0 Comments

 
This week assignment required us to provide us an interface for gameplay programmer to utilize our graphics engine. In other words, we pass the mesh and effect data from our MyGame class and use that in the graphics to draw shapes.

Taking the analogy of buckets, how graphics work is while the system fills one bucket, it renders the other bucket. We use this two-bucket structure to better utilize our system so that there is minimum waiting time. Two separate threads are used for this purpose. In our program, we have two threads; s_dataBeingSubmittedByApplicationThread and s_dataBeingRenderedByRenderThread, and while the data is submitted by Game in one thread, it is rendered by the other.
​
Reference Counting is another interesting concept we used in this assignment. Instead of keeping track of the objects manually, we pass the pointer to the graphics and increase the reference of that object. If the reference of any object is not 0, it signifies that the object is still in use and we should not destroy that object. Once the object is no longer in use, we simply decrement its reference count and as the reference count reaches 0, it will be automatically destroyed. Important thing to note here was effectively increment and decrement the reference counts so that we avoid any memory leaks.


Game Screenshots
Playable EXE Download
​
Controls: To draw one mesh, use Space key
                 To draw mesh with different effect, use Ctrl key (For this, I am switching the effects used by meshes in their default state, so first mesh will be drawn with second effect and second mesh with first effect) 
Picture
Game running in normal state without any key input - two meshes with two seperate effects
Picture
Game with only one mesh rendered - Space key used in the game
Picture
Meshes drawn with different effects - Ctrl key used in the game
​Interfaces
To submit back buffer color to graphics, we use the below interface. Values of red, green, blue and alpha are passed by the gameplay programmer.
Picture
​To submit mesh effect pair to the graphics, we use the below interface. Gameplay programmer will pass a pointer to mesh and effect and graphics will use these references to render that mesh and effect.
Picture
​Interfaces
To submit back buffer color to graphics, we use the below interface. Values of red, green, blue and alpha are passed by the gameplay programmer.
Picture
​To submit mesh effect pair to the graphics, we use the below interface. Gameplay programmer will pass a pointer to mesh and effect and graphics will use these references to render that mesh and effect.
Picture
We use caching of data so that submitting and rendering can work simultaneously. This is more efficient way to reduce waiting time as the new data will be immediately available to be rendered the next frame once current frame data rendering is complete.

Classes Size
Open GL
Mesh – 16 bytes
Effect – 20 bytes
sDataRequiredToRenderAFrame (struct) – 204 bytes
Picture
The data breakdown for sDataRequiredToRenderAFrame struct is
  • constantData_perFrame  of ConstantBufferFormats::sPerFrame type of = 144 bytes
  • Array of custom struct MeshEffectPair containing two pointers = 8 * size of array(5) = 40 bytes
  • 4 floats  = 4 * 4 = 16 bytes
  • 1 uint8_t = 1 byte
  • 3 bytes are wasted in alignment
​
Direct 3D
Mesh – 32 bytes
Effect – 48 bytes
sDataRequiredToRenderAFrame (struct) – 248 bytes
Picture
The data breakdown for sDataRequiredToRenderAFrame struct is
  • constantData_perFrame  of ConstantBufferFormats::sPerFrame type of = 144 bytes
  • Array of custom struct MeshEffectPair containing two pointers = 16 * size of array(5) = 80 bytes
  • 4 floats  = 4 * 4 = 16 bytes
  • 1 uint8_t = 1 byte
  • 7 bytes are wasted in alignment
 
Sizes are different in in OpenGL and Direct3D because of the difference in their configurations (x86 vs x64) . The member variables are declared in the order of bigger to smaller in Mesh and effect class, so I couldn’t think of any other way to reduce its size. Some memory is wasted due to alignment.
As for sDataRequiredToRenderAFrame, we can reduce its size by decreasing the predefined length of array, but I am using 5 for the sake of this assignment (though we are using only 2). I am using an assert before submitting the data to check if user is submitting more than 5 mesh/effect pair and it will fail if user will try to submit the 6th item.
0 Comments



Leave a Reply.

    Author

    Write something about yourself. No need to be fancy, just an overview.

    Archives

    September 2018

    Categories

    All

    RSS Feed

FOR ANY FURTHER DETAILS


Telephone

801-859-1131

Email

Resume
File Size: 227 kb
File Type: pdf
Download File

Visit Hard Light Vector
[email protected]
Git Hub
  • Projects
    • Hard Light Vector
    • Memory Manager
    • Samurai Crusader
    • Dyslexia VR
    • Geriatric Depression Suite
  • Prototypes
    • Game Mechanics
    • Diana's Inferno
    • MakeUp & BreakUp
    • 10Pest
    • Ninja Pinball
  • Blogs
    • Sic Parvis Magna
    • Game Engineering - Week 1
    • Game Engineering - Week 2
    • Game Engineering - Week 3
    • Game Engineering - Week 4
    • Game Engineering - Week 5
    • Game Engineering - Week 6
    • Game Engineering - Week 7
    • Game Engineering - Week 8
    • Game Engineering - Week 9
    • Engine Feature - Audio Subsystem
    • Final Project - GameEngineering III
    • AI Movement Algorithms
    • Pathfinding Algortihms
    • Decision Makiing
  • About