Oh dear. We can't ship this. I get some other folks, including some folks who worked on HL2 originally, and yep - it's broken. And it's broken when you're not in VR either - so it's not something Joe and I broke. But nobody knows why - none of the relevant code has changed.
Someone even goes back in the source history and compiles the original game as it shipped - nope, that original version is also broken. How can this possibly be? At this point people are freaking out - this isn't a normal bug - it appears to have traveled backwards in time and infected the original!
If you watch the video, when the door unlocks and then opens, there's a second guard standing inside the room to the left of the opening door. That guard is actually standing very slightly too close - the very corner of his bounding box intersects the door's path as it opens. So what's happening is the door starts to open, slightly nudges into the guard's toe, bounces back, closes, and then automatically locks. And because there's no script to deal with this and re-open the door, you're stuck.
Recent discussion about the perils of doors in gamedev reminded me of a bug caused by a door in a game you may have heard of called "Half Life 2". Are you sitting comfortably? Then I shall begin.
Repeating my occasional and yet desperate plea to all my nerdy friends - DO NOT PLAY WITH COMPILERS. It is a trap. You will write it forever, and it will never do what you want, nobody will ever use it, it will not be fulfilling, and you will waste your precious life. Please, for the love of the gods, find something more satisfying to do than scream at a parser and SSA/ASTs.
@fatlimey We already have two different float16 formats. Feels like you could add a whole bunch more pretty easily and fine-tune for your use cases. It's not quite per-app-specific compression (because you need a fast & cheap encode from f24ish to whatever 16 bit format you choose), but seems like hardware could easily support 8 different ones.
@fatlimey The paper then goes on to talk about different fp8 formats, but now we truly are just in LUT territory. Convert to the most appropriate fp16, then just look up whatever mapping you want. Whatever makes sense for your app.
@mcc IIRC a lot of the extended syntax was defined by MASM, sometimes to make life simpler for their extremely powerful macros. I don't know how much of that was also adopted by NASM. So well worth checking with both MASM and NASM. But yes - lots of oral tradition here...
@mcc I added a whole bunch of instructions to x86 (what became AVX512), including new syntax for the mask registers. I remember trying to find out who "owned" that, and whether we should use v0(k1), v0[k1] or v0{k1} or some other syntax.
Sadly I don't have my notes from that time, but my vague recollection is that the answer was "nobody cares - pick one". Which was very alarming! I did have some feedback from our internal assembler team, but they stressed that they were NOT a public authority.
@mcc The official tools Intel provides are the C intrinsics - and they are of course C syntax, so have no bearing on the assembly.
So yeah, my recollection is we picked what seemed sensible and went with it. BUT - that was just for the purposes of ISA documentation - there was no hard link to the actual syntax accepted by the assemblers (dramatically so in the case of AT&T syntax).
So it really does seem like a thing nobody owns, except for each specific tool vendor!
@sinbad It's an extremely mature "EA" - we're at 60 hours so far and from the size of the map we have not uncovered, but has quest markers, we're maybe a third of the way through? We are being fairly completist though.
We're playing Enshrouded (good co-op PvE game BTW!) and my wife was talking about the "hoefahray". The... what now? She said "you know - the bunny animals?"
Ohhhhh, well yes I can see how you could parse it that way, but I suspect...
Still boggles my mind that DaVinci Resolve is free. Such an awesome bit of kit - I don't use half of it, and yet... free! I have no idea how they plan to make money, but could every other company in the world please adopt that business plan?
@sinbad You can still clearly see the limits, and that's the "retro" part - grappling with those.
SNES/MegaDrive had less CPU power, but more hardware, and for some of those games I think they got to "good enough" graphics to lose some of that "retro" feel. But I am absolutely open to debate on this.
Of course, as soon as you want to go 3D it all looks terrible again. 3D stays "retro" all the way up to the N64/Saturn/PS1 - all of which look eye-scorchingly bad in their own ways.