Next up: Modifying the SEND functions of the FX Shader class to allow dynamic naming of handles for engine specific data. This is necessary as it allows the shader author to name shader parameters anything ( and make multiple instances of objects) rather than needing to follow a strict set of parameter naming rules for engine specific data. Should be fun and it is a necessary step to implementing the new parameter semantics and annotation naming conventions mentioned on the 28th.
🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
I optimized two functions in the core graphics class. These functions get either the nearest active light (NAL1) or the second nearest active light (NAL2) in relation to a vector parameter. The optimized part is that now each function stores the previous nearest light found and the previous vector parameter. Now each time one of the two functions are called they check to see if the vector parameter is the same as the previously stored vector and also if the lighting state has not changed. If both are true then the function skips all redundant calculations are returns the previously calculated nearest active light (NAL). This adjustment should make rendering position-static objects, which use material shaders that depend on engine lighting information, more efficient.
Next up: Modifying the SEND functions of the FX Shader class to allow dynamic naming of handles for engine specific data. This is necessary as it allows the shader author to name shader parameters anything ( and make multiple instances of objects) rather than needing to follow a strict set of parameter naming rules for engine specific data. Should be fun and it is a necessary step to implementing the new parameter semantics and annotation naming conventions mentioned on the 28th.
Next up: Modifying the SEND functions of the FX Shader class to allow dynamic naming of handles for engine specific data. This is necessary as it allows the shader author to name shader parameters anything ( and make multiple instances of objects) rather than needing to follow a strict set of parameter naming rules for engine specific data. Should be fun and it is a necessary step to implementing the new parameter semantics and annotation naming conventions mentioned on the 28th.
Previous Entry
Morning Coffee
Next Entry
Still Working on Materials
Advertisement
Latest Entries
OpenGL Indexed Geometry Buffer
1813 views
Cult of Gameplay
1377 views
Cross Platform Is Working
1465 views
Start up the engine
1413 views
Gathering some art
1337 views
Making a game
1286 views
ImageMagick Magick++ to HBITMAP using C++
2562 views
Problems != Good Sleep
1292 views
Cylindrical Texture Mapping
1580 views
Daemon (novel)
1388 views
Advertisement