Submitting the Background Color
Within cExampleGame.h owns a Color type variable titled bgColor. This variable is then initialized with the appropriate RGB values to construct a color in the Initialize() function of the game code. Than, it is submitted along with other data to the Graphics Library within the SubmitDataToBeRendered() function of the game class.
Submitting Renderable Objects: Sprites and Effects
Sprites, or the representation of the polygons on screen, are created by specifying the height, width, and center of their representation (centerX and centerY). As the programmer, you can initialize these objects as pointers in your header file, for example, making sure to keep them as nullptr. Then, in the Initialize() function of your game you can factory load them with the Load() function.
Effects are the visual effects like color and transformation of a given Sprite in the game. These are initialized similarly to Sprites via their declaration as nullptrs and then loaded via a factory Load() function. Effects require a path to the location of the Fragment and Vertex .shdfiles. The initial render state must also be specified.
Packaging Sprites and Effects for Submission to the Graphics Library
In the main loop of the game application, the programmer must submit this data to Graphics in order to be rendered. To combine Sprites with their appropriate Effects, we use the std::pair<> collection. Which takes both the Sprite and Effect as pointers. This can be seen on line 9 of the Snippet2.cpp sample posted above.
Submission and Note about Cleanup
The actual submission call is quite simple! You can do this simply within the SubmitDataToBeRendered function of your game loop with a SubmitRenderableToRender() call with your pertinent pair(s). NOTE:The programmer is responsible for taking care of Decrementing the Reference Count of these pairs. This is done like so:
You’re probably wondering why you have to cache all of the data for a single frame rather than immediately sending over the objects as they’re initialized. For our purposes, in a simple game such as this, we want to make sure that we are ready with all the required render data for a given frame before actually beginning the render process. It makes sense that if we wanted something to show on screen together that we also would like to ensure that all of the required data is ready to go at the same time.
On the topic of Multiple Sprites and/or Effects for a Given Frame
This is made possible via how the Graphics library handles the data, or std::pair<>’s that we used to package up our Sprite and Effect. Briefly, the collection used to store this data is a std::Vector behind the scenes, they are rendered in order of their placement into said vector.
sizeof(Sprite) and sizeof(Effect)
Below are the results of a sizeof() call on the two classes prior to improvements:
Concerning the topic of how to make either classes “Smaller” in their byte size. This can be done in a few ways:
With this stage we began to move away from hardcoded objects from within the Graphics library and moving them to the more sensible location of within the game code. I found this assignment actually interesting and satisfying not just because it’s working towards a sensible goal, but it was structured in such a way that made sense.
You can try out these games via the below links. The only difference is that Direct3D will be used in the x64 version, with OpenGL in the other. They have been built and verified to work on Windows.