Mara
@maraneshi.bsky.social
Sometimes works on game engines. She/Her. More tired than you could ever imagine. 🏳️⚧️🏳️🌈
@Maraneshi@mastodon.gamedev.place
https://x.com/Maraneshi
@Maraneshi@mastodon.gamedev.place
https://x.com/Maraneshi
Killing or knocking out or avoiding enemies was a true choice in DX, but in DXHR everything *must* be wholly systemized and every action within that system *must* have an immediate reward, making you think about that instead of the action itself. Same with pretty much every other mechanic.
November 9, 2025 at 11:18 PM
Killing or knocking out or avoiding enemies was a true choice in DX, but in DXHR everything *must* be wholly systemized and every action within that system *must* have an immediate reward, making you think about that instead of the action itself. Same with pretty much every other mechanic.
You *can* make good games that way and I certainly enjoy systems-oriented games, but I miss a more world/goal oriented design in some ways. IIRC the original Deus Ex mostly gave you rewards for meeting goals, not the individual actions that lead to them, so you actually felt free in your choices.
November 9, 2025 at 11:18 PM
You *can* make good games that way and I certainly enjoy systems-oriented games, but I miss a more world/goal oriented design in some ways. IIRC the original Deus Ex mostly gave you rewards for meeting goals, not the individual actions that lead to them, so you actually felt free in your choices.
I'm not a designer but I've been thinking this a lot lately, where especially newer games are entirely action/system oriented in their rewards and the overall design and how it turns everything into an instant-gratification numbers game and reduces the world to pretty set-dressing over those systems
November 9, 2025 at 11:18 PM
I'm not a designer but I've been thinking this a lot lately, where especially newer games are entirely action/system oriented in their rewards and the overall design and how it turns everything into an instant-gratification numbers game and reduces the world to pretty set-dressing over those systems
What is lighting? Also the original lipsync was bugged so we slapped slow interpolation on it and made it look like a bad cartoon animated for another language instead.
September 25, 2025 at 12:03 AM
What is lighting? Also the original lipsync was bugged so we slapped slow interpolation on it and made it look like a bad cartoon animated for another language instead.
Unity documents that it does apply the factors even for min/max, but it can't actually do that since no graphics API supports that (I checked OpenGL, Vulkan and D3D). What's likely happening is that not specifying blend factors in Unity means blending is *disabled entirely*.
August 21, 2025 at 10:10 PM
Unity documents that it does apply the factors even for min/max, but it can't actually do that since no graphics API supports that (I checked OpenGL, Vulkan and D3D). What's likely happening is that not specifying blend factors in Unity means blending is *disabled entirely*.
Since not all possible byte values even *make sense* for UTF-8 (unlike UTF-16), as in they are not even code units at all, there's no way to make a "messed up" encoding like WTF-16/8 out of this and you either have to actually support arbitrary byte sequences or assume UTF-8 and hope for the best.
July 29, 2025 at 5:07 PM
Since not all possible byte values even *make sense* for UTF-8 (unlike UTF-16), as in they are not even code units at all, there's no way to make a "messed up" encoding like WTF-16/8 out of this and you either have to actually support arbitrary byte sequences or assume UTF-8 and hope for the best.
they can still fit the general idea because all code units [0x0000, 0xFFFF] *can* be used in a legal encoding.
On Linux, the situation is hopeless because technically file names have no encoding whatsoever (may depend on file system), only the byte values for ASCII nul and slash are illegal.
On Linux, the situation is hopeless because technically file names have no encoding whatsoever (may depend on file system), only the byte values for ASCII nul and slash are illegal.
July 29, 2025 at 5:07 PM
they can still fit the general idea because all code units [0x0000, 0xFFFF] *can* be used in a legal encoding.
On Linux, the situation is hopeless because technically file names have no encoding whatsoever (may depend on file system), only the byte values for ASCII nul and slash are illegal.
On Linux, the situation is hopeless because technically file names have no encoding whatsoever (may depend on file system), only the byte values for ASCII nul and slash are illegal.
Windows filenames are mostly arbitrary bytes and thus WTF-16 can have those "surrogates" as individual values instead of pairs. This can then still be encoded in an extended form of UTF-8. So even though we have arbitrary bytes and some of them are not legal code *points*,
July 29, 2025 at 5:07 PM
Windows filenames are mostly arbitrary bytes and thus WTF-16 can have those "surrogates" as individual values instead of pairs. This can then still be encoded in an extended form of UTF-8. So even though we have arbitrary bytes and some of them are not legal code *points*,
Summary as far as I understand:
In UTF-16, all 16-bit values from 0x0000 to 0xFFFF are used and legal, but [0xD800, 0xDC00) and [0xDC00, 0xE000) are supposed to come as pairs to encode larger code points using the lower bits in each value (two 16-bit "code units" to make one "code point").
In UTF-16, all 16-bit values from 0x0000 to 0xFFFF are used and legal, but [0xD800, 0xDC00) and [0xDC00, 0xE000) are supposed to come as pairs to encode larger code points using the lower bits in each value (two 16-bit "code units" to make one "code point").
July 29, 2025 at 5:07 PM
Summary as far as I understand:
In UTF-16, all 16-bit values from 0x0000 to 0xFFFF are used and legal, but [0xD800, 0xDC00) and [0xDC00, 0xE000) are supposed to come as pairs to encode larger code points using the lower bits in each value (two 16-bit "code units" to make one "code point").
In UTF-16, all 16-bit values from 0x0000 to 0xFFFF are used and legal, but [0xD800, 0xDC00) and [0xDC00, 0xE000) are supposed to come as pairs to encode larger code points using the lower bits in each value (two 16-bit "code units" to make one "code point").
Yes. Basically, OSes like treating file names as just bags of bytes, so you can create filenames that are not valid UTF sequences. This has been dubbed the Wobbly Transformation Format (WTF). It's usually used with regard to Windows, but I believe Linux has the same issue
simonsapin.github.io/wtf-8/
simonsapin.github.io/wtf-8/
The WTF-8 encoding
simonsapin.github.io
July 29, 2025 at 4:23 PM
Yes. Basically, OSes like treating file names as just bags of bytes, so you can create filenames that are not valid UTF sequences. This has been dubbed the Wobbly Transformation Format (WTF). It's usually used with regard to Windows, but I believe Linux has the same issue
simonsapin.github.io/wtf-8/
simonsapin.github.io/wtf-8/
Make sure to also learn about WTF-16!
July 29, 2025 at 4:09 PM
Make sure to also learn about WTF-16!
Ugh, scratch that, I was blind. Both compilers insert the prefetch loop at the end, which makes a lot of sense because the "else" case is universal and only refers to the second "if", so it will always execute even if the first if condition is true when you don't chain them with "else if" correctly.
July 29, 2025 at 2:00 PM
Ugh, scratch that, I was blind. Both compilers insert the prefetch loop at the end, which makes a lot of sense because the "else" case is universal and only refers to the second "if", so it will always execute even if the first if condition is true when you don't chain them with "else if" correctly.
Both. Unfortunately it seems the problem is quite a lot more mysterious because I'm getting the exact same codegen for the measured section on MSVC, but the perf difference is consistently measurable. On Clang there is at least a slight difference in how the loop is unrolled (MSVC doesn't unroll).
July 29, 2025 at 1:53 PM
Both. Unfortunately it seems the problem is quite a lot more mysterious because I'm getting the exact same codegen for the measured section on MSVC, but the perf difference is consistently measurable. On Clang there is at least a slight difference in how the loop is unrolled (MSVC doesn't unroll).
Also, I propose the "pipeline" mode optimization should be called "loop unrolling but I went too far".
July 29, 2025 at 12:46 PM
Also, I propose the "pipeline" mode optimization should be called "loop unrolling but I went too far".
My initial instinct was that the pointers should be pre-sorted, but of course that only helps if there is some actual data locality, so I had to reduce the test set to <32kB to get any actual benefits. The sorting would have to take place whenever the pointers get modified, not when you query them.
July 29, 2025 at 12:45 PM
My initial instinct was that the pointers should be pre-sorted, but of course that only helps if there is some actual data locality, so I had to reduce the test set to <32kB to get any actual benefits. The sorting would have to take place whenever the pointers get modified, not when you query them.
In another case of "benchmarks are hard", the "original" becomes a bit faster (~15% for me) if you change "if (Mode == kPipeline)" to "else if". Since Mode is a template parameter anyways, upgrading to "if constexpr" should absolutely ensure no weird side effects on code gen from the branch.
July 29, 2025 at 12:41 PM
In another case of "benchmarks are hard", the "original" becomes a bit faster (~15% for me) if you change "if (Mode == kPipeline)" to "else if". Since Mode is a template parameter anyways, upgrading to "if constexpr" should absolutely ensure no weird side effects on code gen from the branch.
There may be some edge cases where you can do horrible things in 11 (e.g. OOB access on a local array, unaligned access, wrong resource type) and of course you never know what the driver does under the hood (it could try to optimize your resource bindings to something not possible in the API).
February 26, 2025 at 4:58 PM
There may be some edge cases where you can do horrible things in 11 (e.g. OOB access on a local array, unaligned access, wrong resource type) and of course you never know what the driver does under the hood (it could try to optimize your resource bindings to something not possible in the API).
In 11 OOB is always defined bc it binds resources as full descriptors, which contain a pointer but also bounds, texel formats, etc. and bounds checks are required. In 12 this is mandatory for anything needing format conversion, but for other buffers it's also possible to only supply a GPU address.
February 26, 2025 at 4:54 PM
In 11 OOB is always defined bc it binds resources as full descriptors, which contain a pointer but also bounds, texel formats, etc. and bounds checks are required. In 12 this is mandatory for anything needing format conversion, but for other buffers it's also possible to only supply a GPU address.
Depends on the API and how you bind the resource. E.g. D3D12 allows you to bind (non-typed) buffers as simple pointers to memory, so the shader has no idea what is in or out of bounds and you can get fun stuff like this too.
February 26, 2025 at 4:36 PM
Depends on the API and how you bind the resource. E.g. D3D12 allows you to bind (non-typed) buffers as simple pointers to memory, so the shader has no idea what is in or out of bounds and you can get fun stuff like this too.
Correction, it's 300x180 resolution for the large model, 128x128 for the small model. The A6000 numbers are for the latter, no idea which one they use in the video. In any case *at least* 3 orders of magnitude away from something "shippable to consumers" even if it was usable for a game.
February 19, 2025 at 9:09 PM
Correction, it's 300x180 resolution for the large model, 128x128 for the small model. The A6000 numbers are for the latter, no idea which one they use in the video. In any case *at least* 3 orders of magnitude away from something "shippable to consumers" even if it was usable for a game.
It's just completely absurd nonsense. None of this is real and it would take more effort than actually just porting the game even if it was remotely possible computationally.
February 19, 2025 at 8:22 PM
It's just completely absurd nonsense. None of this is real and it would take more effort than actually just porting the game even if it was remotely possible computationally.
You *cannot* make a functional game with this. You would need an actual game engine keeping track of the mechanics, and then train the model on what the game state means by feeding it an absurd amount of footage of the existing game plus the entire serialized game state for every frame.
February 19, 2025 at 8:22 PM
You *cannot* make a functional game with this. You would need an actual game engine keeping track of the mechanics, and then train the model on what the game state means by feeding it an absurd amount of footage of the existing game plus the entire serialized game state for every frame.
Lastly, it does not generate "gameplay". It generates correlated images with a context length of *one second*. Nevermind the hallucinated dream stuff, this cannot model actual game mechanics. If you pick up a key and then go to a door it will not know what a key is or whether you've picked it up.
February 19, 2025 at 8:22 PM
Lastly, it does not generate "gameplay". It generates correlated images with a context length of *one second*. Nevermind the hallucinated dream stuff, this cannot model actual game mechanics. If you pick up a key and then go to a door it will not know what a key is or whether you've picked it up.
We also need substantially higher res to even have many of the gameplay elements visible at all in the training data, nevermind output fidelity. This will quickly explode the size of the training data past the largest machine learning models that have ever been trained to date, *for a single game*.
February 19, 2025 at 8:22 PM
We also need substantially higher res to even have many of the gameplay elements visible at all in the training data, nevermind output fidelity. This will quickly explode the size of the training data past the largest machine learning models that have ever been trained to date, *for a single game*.
They also needed 8 years of gameplay to train this model, harvested by recording replays from real players over two years and then running them back on a modified engine that generates 300x128x10Hz video footage and associated serialized controller inputs. Where are you gonna get all this data from?
February 19, 2025 at 8:22 PM
They also needed 8 years of gameplay to train this model, harvested by recording replays from real players over two years and then running them back on a modified engine that generates 300x128x10Hz video footage and associated serialized controller inputs. Where are you gonna get all this data from?