Blogger Templates

Thursday, October 19, 2017


Graphics (7 of ∞) Platform-independent shaders, handle changes and texture changes.

Posted in ,
EAE 6320-001

In this writeup, I will talk about my experience of converting all of my shader language code to be platform-independent. I will also be doing some architectural changes for the texture implementation in terms of its handle and the pointer usage.

Platform-Independent Shaders
In an earlier write up, I talked about how we managed to club the shader language from two different files hlsl and glsl to one file sl. Having done that, we still ran into an issue where the single shader language(sl) still continued to have two copies of implementation for openGL and D3D. Any change that I intend to do will have to be done twice. Code duplication like this can lead to several maintenance and scalability issue. A quick glimpse into the file gives an idea of how the types and constant buffers are defined based on openGL or D3D and how they are used in the shader language. Following this pattern, I created Macros for TextureObjects and the samplerstate that can be used as a platform independent code in the shader language.

[Texture object and sampler state]

[Sampled color]

The only thing that I left as platform specific implementation inside the shader language is the main function line and its associated input and output params while I managed to make the body of the main function to be platform independent as per the requirement.

For the body, the challenge I had was to map the reserved variable gl_position of openGL in some manner such that it is consistent to its D3D counterpart user defined variable o_position. So I mapped them both ways as shown in the screenshot similar to that of types. Now I can simply use o_position to write a platform independent body implementation. After making all these changes, I really feel the power of all the shared code. Any new changes that I need to make going forward is just once and I don't have to remember to do it at multiple places and multiple times. Code is clean and less error prone ;)

Asset/Texture Changes
We ran lot of architectural issues for the texture implementation by trying to use the handle in its existing design. My professor modified the handle design such that they are decoupled from the standard reference counting done by the asset themselves. This allowed me to keep the Texture pointer consistent with that of effect and sprite in the graphics code. I also wrapped this pointer inside the same SpriteWithEffect class such that the wrapper class can perform related operations on all of its child together. This change made me to remove all the existing handle based logic from the graphics code thus allowing us to maintain a consistent implementation across effect, sprite and textures. For the game code, most of my implementation remained the same for the new handles like the way I load the asset and released them. Only while submitting, I would access the asset through a pointer and pass the pointer directly to the graphics code rather than sending the handles. I also updated the ReferenceCountedAssets.h to include the addional asserts that were missing earlier.

I also enabled the alpha transparency to the sprites by making my defaultRenderState to be 1. Thus my sprites can accept the alpha range from my shader language code.

In the above screenshot, I have made the gideon’s black hole moving image transparency to be 0.5. As a result, you can see a bit of transparency on the moving image compared to the same screenshot in my previous writeup.

Feel free to try this version of game from the following download link.
Space - Sequence of moving images
Shift - Sequence of random images