@tloch14.bsky.social
(Also the part I'm raving about was done by a colleague of mine, not me. So credit to its awesomeness is his.)
May 4, 2025 at 1:11 AM
(Also the part I'm raving about was done by a colleague of mine, not me. So credit to its awesomeness is his.)
In my home engine, we support deferred create/destroy and instant edits. Deferred creation is a limitation of the way they are stored and thread safety. However, we present them as instantly created and inject a move operation before they are ever read from. Its quite sleek.
May 4, 2025 at 1:10 AM
In my home engine, we support deferred create/destroy and instant edits. Deferred creation is a limitation of the way they are stored and thread safety. However, we present them as instantly created and inject a move operation before they are ever read from. Its quite sleek.
Could also have two traversals:
for(auto& e : breadth_first(node))
Or
for(auto& e : depth_first(node))
And then could combine with other adapters, like the c++ enumerate() made popular by Nathan Reed.
for(auto[i, e] : enumerate(depth_first(node)))
With ranges I guess it would compose with | .
for(auto& e : breadth_first(node))
Or
for(auto& e : depth_first(node))
And then could combine with other adapters, like the c++ enumerate() made popular by Nathan Reed.
for(auto[i, e] : enumerate(depth_first(node)))
With ranges I guess it would compose with | .
April 30, 2025 at 4:43 AM
Could also have two traversals:
for(auto& e : breadth_first(node))
Or
for(auto& e : depth_first(node))
And then could combine with other adapters, like the c++ enumerate() made popular by Nathan Reed.
for(auto[i, e] : enumerate(depth_first(node)))
With ranges I guess it would compose with | .
for(auto& e : breadth_first(node))
Or
for(auto& e : depth_first(node))
And then could combine with other adapters, like the c++ enumerate() made popular by Nathan Reed.
for(auto[i, e] : enumerate(depth_first(node)))
With ranges I guess it would compose with | .
It seems like this could just be a normal for loop, with an adapter interface that supports the needed traversal. Ie, if the tree node supports get_parent/first_child/next_sibling(), you could write a normal iterator that lets you do:
for(auto& e : traverse_tree(node))
for(auto& e : traverse_tree(node))
April 30, 2025 at 4:39 AM
It seems like this could just be a normal for loop, with an adapter interface that supports the needed traversal. Ie, if the tree node supports get_parent/first_child/next_sibling(), you could write a normal iterator that lets you do:
for(auto& e : traverse_tree(node))
for(auto& e : traverse_tree(node))
You can use the layout(location=#) qualifier to specify vertex-fragment linkage by index. More info here: www.khronos.org/opengl/wiki/... (see Program Separation Linkage section)
Layout Qualifier (GLSL) - OpenGL Wiki
www.khronos.org
April 15, 2025 at 3:55 AM
You can use the layout(location=#) qualifier to specify vertex-fragment linkage by index. More info here: www.khronos.org/opengl/wiki/... (see Program Separation Linkage section)
It sounds like you are assuming two object oriented classes. Player and PlayerController or something like that.
March 3, 2025 at 1:55 AM
It sounds like you are assuming two object oriented classes. Player and PlayerController or something like that.
I can see it. I guess I just rarely come across that type of thing in my own work. Like I just don't reach for paradigms that require it. This has me curious now. I might do an audit of my projects to better understand.
March 3, 2025 at 12:52 AM
I can see it. I guess I just rarely come across that type of thing in my own work. Like I just don't reach for paradigms that require it. This has me curious now. I might do an audit of my projects to better understand.
Celeste and TLOU2 are well known examples, but I don't know of their specifics. Sorry I don't know more here. You could use the #a11y tag as a good launching point for finding out more.
March 2, 2025 at 5:26 PM
Celeste and TLOU2 are well known examples, but I don't know of their specifics. Sorry I don't know more here. You could use the #a11y tag as a good launching point for finding out more.
Ian is right that a lot of games get it wrong.
This website provides a good list of guidelines. Here is the one about avoiding solid colors only. gameaccessibilityguidelines.com/ensure-no-es...
This website provides a good list of guidelines. Here is the one about avoiding solid colors only. gameaccessibilityguidelines.com/ensure-no-es...
Ensure no essential information is conveyed by a fixed colour alone – Game Accessibility Guidelines
Time and time again I’ve seen games make unnecessary decisions in color usage that outright prevented me from playing the game due to my colorblindness Aerothorn, via Rock Paper Shotgun We estimate th...
gameaccessibilityguidelines.com
March 2, 2025 at 5:11 PM
Ian is right that a lot of games get it wrong.
This website provides a good list of guidelines. Here is the one about avoiding solid colors only. gameaccessibilityguidelines.com/ensure-no-es...
This website provides a good list of guidelines. Here is the one about avoiding solid colors only. gameaccessibilityguidelines.com/ensure-no-es...
If Foo was an impl detail of Bar, I probably wouldn't define it in a public header to begin with, but the fwd declare would then make sense. In such cases, I often use handles instead of pointers. I can see fwd declare being useful here.
March 2, 2025 at 4:59 PM
If Foo was an impl detail of Bar, I probably wouldn't define it in a public header to begin with, but the fwd declare would then make sense. In such cases, I often use handles instead of pointers. I can see fwd declare being useful here.
Looks great! You could try to add some patterned difference so that color blind/deficient people can tell the diff. Some shader math to do checkerboard for good and diagonal striped for bad is easy enough and is an awesome feature for accessibility.
March 2, 2025 at 5:18 AM
Looks great! You could try to add some patterned difference so that color blind/deficient people can tell the diff. Some shader math to do checkerboard for good and diagonal striped for bad is easy enough and is an awesome feature for accessibility.
I think it largely has to do with my own developed paradigms for programming. In my own environment where everything is the way I want, fwd declares just don't come up and compile time is awesome. I think more commonly used patterns (that I don't use) rely on fwd declares.
March 2, 2025 at 5:08 AM
I think it largely has to do with my own developed paradigms for programming. In my own environment where everything is the way I want, fwd declares just don't come up and compile time is awesome. I think more commonly used patterns (that I don't use) rely on fwd declares.
My exp is that if bar.h fwd declares Foo instead of including foo.h, then all includers of bar.h also need to include foo.h to reasonably use whatever is in bar.h. bar.h may as well include foo.h.
I can think of some times thats not true, but its not common. Again, more thought needed for me.
I can think of some times thats not true, but its not common. Again, more thought needed for me.
March 2, 2025 at 5:05 AM
My exp is that if bar.h fwd declares Foo instead of including foo.h, then all includers of bar.h also need to include foo.h to reasonably use whatever is in bar.h. bar.h may as well include foo.h.
I can think of some times thats not true, but its not common. Again, more thought needed for me.
I can think of some times thats not true, but its not common. Again, more thought needed for me.
I'll be honest, I don't know the last time I used a forward declare. Strike that, I used it to break a bad include cycle on a project that had sus coding practices.
I would almost say that needing to forward declare something is a code smell, but I'd have to think about it more.
I would almost say that needing to forward declare something is a code smell, but I'd have to think about it more.
March 2, 2025 at 4:57 AM
I'll be honest, I don't know the last time I used a forward declare. Strike that, I used it to break a bad include cycle on a project that had sus coding practices.
I would almost say that needing to forward declare something is a code smell, but I'd have to think about it more.
I would almost say that needing to forward declare something is a code smell, but I'd have to think about it more.
A variable I can't be bothered to name meaningfully right now? Lolcakes.
A temporary item in the database to test some functionality? Lolcakes.
Dummy new project that just to verify behavior in an otherwise empty environment? Lolcakes.proj
Writing some text to file real quick? Lolcakes.txt
A temporary item in the database to test some functionality? Lolcakes.
Dummy new project that just to verify behavior in an otherwise empty environment? Lolcakes.proj
Writing some text to file real quick? Lolcakes.txt
January 18, 2025 at 5:13 AM
A variable I can't be bothered to name meaningfully right now? Lolcakes.
A temporary item in the database to test some functionality? Lolcakes.
Dummy new project that just to verify behavior in an otherwise empty environment? Lolcakes.proj
Writing some text to file real quick? Lolcakes.txt
A temporary item in the database to test some functionality? Lolcakes.
Dummy new project that just to verify behavior in an otherwise empty environment? Lolcakes.proj
Writing some text to file real quick? Lolcakes.txt
Whenever I need a temporary word, its "Lolcakes". Printf debugging is never "Got here". Its "Lolcakes", "Lolcakes 2", etc. Never "Lolcakes 1" tho, because I never anticipate needing more than 1 until I realize I need more than 1 and then I'm too lazy to go back and change it.
January 18, 2025 at 5:09 AM
Whenever I need a temporary word, its "Lolcakes". Printf debugging is never "Got here". Its "Lolcakes", "Lolcakes 2", etc. Never "Lolcakes 1" tho, because I never anticipate needing more than 1 until I realize I need more than 1 and then I'm too lazy to go back and change it.
I would love go see OSL GI combined with forward or deferred rendering for direct light. The OSL could update at a slower pace, or even decay over 2 or 3 frames, and at reasonably low resolutions to be kinda cheap. But I suppose this isnt far from Lumen's surface cache, if I understand it right.
December 30, 2024 at 12:30 AM
I would love go see OSL GI combined with forward or deferred rendering for direct light. The OSL could update at a slower pace, or even decay over 2 or 3 frames, and at reasonably low resolutions to be kinda cheap. But I suppose this isnt far from Lumen's surface cache, if I understand it right.
I've worked with OSL (object space lighting, as we called it) with Oxide's tech specifically. I think for GI it could be better than temporal techniques, but not at higher frequency shading. Shade texel resolution was always a challenge in OSL.
December 30, 2024 at 12:22 AM
I've worked with OSL (object space lighting, as we called it) with Oxide's tech specifically. I think for GI it could be better than temporal techniques, but not at higher frequency shading. Shade texel resolution was always a challenge in OSL.
I think we are agreeing, and I'm bad at stating my position. Organized by game logic is the primary way. I was talking more about reasons for splitting components any farther that game logic requires.
November 23, 2024 at 1:40 AM
I think we are agreeing, and I'm bad at stating my position. Organized by game logic is the primary way. I was talking more about reasons for splitting components any farther that game logic requires.
To me, splitting component data should always be profile driven or logically necessary. Hot vs cold data or something. Maybe even better cache line hits w/ separate components vs interleaved. Until then, its easier to manage as one, isnt it?
November 22, 2024 at 3:36 AM
To me, splitting component data should always be profile driven or logically necessary. Hot vs cold data or something. Maybe even better cache line hits w/ separate components vs interleaved. Until then, its easier to manage as one, isnt it?