Chobbes @ Chobbes @lemmy.world

Posts

0

Comments

465

Joined

2 yr. ago

Soy paste sounds would absolutely trigger misophonia for me, so you’re not wrong! Haha.

I have misophonia and kids are definitely a big trigger in a lot of ways… Screaming, crying, chewing, coughing. It’s anecdotal, but yeah the high pitch sounds don’t play nice with my brain. Misophonia suuuuuuuuuucks.

I also don’t particularly like kids, but that’s not really about the sound. Just not my cup of tea.

I get that, but for what it’s worth… You really can kind of just dump it on them. They’re not allowed to share it, and they’re often happy to just get to the point sometimes. Though it does feel more transactional that way.

They’re nice. I wouldn’t be surprised if you liked Superliminal more because I think it’s a more unique concept than either. It’s been a while since I played either, but I think Lightmatter was a more unique concept for puzzles than Turing Test, but Turing Test had some reasonably interesting stuff going on story wise (not amazing, but I have a bit of a soft spot for the kind of Chinese Room philosophy stuff). Either way, they’re worth a look, I think! Sometimes you just want something to scratch the first person puzzle itch and there aren’t thaaaat many games in the category!

I was a little disappointed with Superliminal. Really short and I didn’t think the puzzles got very interesting. I was excited about the concept, but it really didn’t live up to my expectations. Glad you liked it, though! I think it was maybe just a little overhyped for me.

If you’re looking for other games in this style… The Turing Test was decent and short, and Lightmatter is pretty unknown and decent. They’re not as polished as Portal, obviously, but they’re both relatively short puzzle games. I think the puzzles in Turing Test were pretty straightforward. The Lightmatter puzzles were a bit more interesting, I think.

Journey is one of my favourite short games.

I just want Logan Cunningham to whisper me to sleep every night.

God. Sword of Truth was one of the first books I read when I was trying to get back into reading (I think I got it in some bundle)… And at first it was like, cool, I like wizards, great… and then it got really fucking weird and rapey and I was embarrassed to have read that book. I didn’t look into the author at all, but I would be so incredibly unsurprised for them to turn out to be a terrible person.

But it all happens at compile time. That’s the difference.

No, when you have a library like SDL you will have functions that wrap lower level libraries for interacting with the screen and devices. At SDL's compile time you may have preprocessor macros or whatever which select the implementation of these functions based on the platform, but at run time you still have the extra overhead of these SDL function calls when using the library. The definitions won't be inlined, and there will be extra overhead to provide a consistent higher level interface, as it won't exactly match the lower level APIs. It doesn't matter if it's compiled, there's still overhead.

C is just a language, it’s not native. Native means the binary that will execute on hardware is decided at compile time, in other words, it’s not jitted for the platform it’s running on.

Wine doesn't really involve any jitting, though, it's just an implementation of the Windows APIs in the Linux userspace... So, arguably it's as native as anything else. The main place where JIT will occur is for shader compilation in DXVK, where the results will be cached, and there is still JIT going on on the "native windows" side anyway.

If you don't consider C code compiled to native assembly to be native, then this is all moot, and pretty much nothing is native! I agree that C is just a language so it's not necessarily compiled down to native assembly, but if you don't consider it native code when it is... Then what does it mean to be native?

the binary that will execute on hardware is decided at compile time

This is true for interpreted languages. The interpreter is a fixed binary that executes on hardware, and you can even bake in the program being interpreted into an executable! You could argue that control flow is determined dynamically by data stored in memory, so maybe that's what makes it "non-native", but this is technically true for any natively compiled binary program too :). There's a sense in which every program that manipulates data is really just an interpreter, so why consider one to be native and not the other? Even native assembly code isn't really what's running on the processor due to things like microcode, and arguably speculative execution is a fancy kind of JIT that happens in hardware which essentially dynamically performs optimizations like loop unrolling... It's more of a grey area than you might think, and nailing down a precise mathematical definition of "native code" is tricky!

I assume you’re not talking about a compiler that generates C code here, right? If it’s outputting C, then no, it’s not native code yet.

But it will be native code :). Pretty much all compilers go through several translation steps between intermediate languages, and it's not uncommon for compilers to use C as an intermediate language, Vala does this for instance, and even compilers for languages like Haskell have done this in the past. C is a less common target these days, as many compiler front ends will spit out LLVM instead, but it's still around. Plus, there's often more restricted C-like languages in the middle. Haskell's GHC still uses Cmm which is a C-like language for compilation, for example.

Well first off, games don’t ship with their HLSL (unlike OGL where older games DID have to ship with GLSL), they ship with DXBC/DXIL, which is the DX analog to spir-v (or, more accurately, vice versa).

Sure, and arguably it's a little different to ship a lower level representation, but there will still be a compilation step for this, so you're arguably not really introducing a new compilation step anyway, just a different one for a different backend. If you consider a binary that you get from a C compiler to be native code, why shouldn't we consider this to be native code :)? It might not be as optimized as it could have been otherwise, but there's plenty of native programs where that's the case anyway, so why consider this to be any different?

Ultimately the native vs. non-native distinction doesn't really matter, and arguably this distinction doesn't even really exist --- it's not really easy to settle on a formal definition for this distinction that's satisfying. The only thing that matters is performance, and people often use these things such as "it's a compiled language" and "it has to go through fewer translation layers / layers of indirection" as a rule of thumb to guess whether something is less efficient than it could be, but it doesn't always hold up and it doesn't always matter. Arguably this is a case where it doesn't really matter. There's some overhead with wine and DXVK, but it clearly performs really well (and supposedly better in some cases), and it's hard to truly compare because the platforms are so different in the first place, so maybe it's all close enough anyway :).

Also to be clear, it's not that I don't see your points, and in a sense you're correct! But I don't believe these distinctions are as mathematically precise as you do, which is my main point :). Anyway, I hope you have a happy holidays!

You’re explaining yourself fine, I just don’t necessarily agree with the distinction. It’s like when people say a language is “a compiled language” when that doesn’t really have much to do with the language, it’s more of an implementation detail. It’s a mostly arbitrary distinction that makes sense to talk about sometimes in practice, but it’s not necessarily meaningful philosophically.

That said, SDL isn’t really any different. It’s not translating languages, but you still have additional function calls and overhead wrapping lower level libraries, just the same as wine. DXVK has an additional problem where shaders will have to be converted to SPIR-V or something which arguable makes it “more non-native” but I think that’s not as obvious of a distinction to make too. You probably wouldn’t wouldn’t consider C code non-native, even though it’s translated to several different languages before you get native code, and usually you consider compilers that use C as a backend to be native code compilers too, so why would you consider HLSL -> SPIR-V to be any different? There’s reasons why you might make these distinctions, but my point is just that it’s more arbitrary than you might think.

Lower power usage and smaller and maaaaaaaaybe better reliability. I’d probably do it if it was cost competitive… but it’s not yet.

You’re not wrong, and the translation layers definitely do make a difference for performance. Still, it’s not all that different from a slightly slow slightly odd “native” implementation of the APIs. It’s a more obvious division when it’s something like Rosetta that’s translating between entirely different ISAs.

My understanding is that DXVK implements the Direct3D API using vulkan behind the scenes. So, sure, there might be a bit of overhead versus a more direct implementation. Frankly this doesn’t feel all that different from something like SDL to me. Shaders will have to be compiled into shaders that Vulcan understands, but you could just think of this as part of the front end for shader compilation.

I do agree that it feels less native to me too (particularly over the rest of wine), but it’s sort of an arbitrary distinction.

I think anything that CodeWeavers helped port. I think Bioshock Infinite is one such game. I’m not sure if you’d see wine binaries, though, could all be statically linked in.

There’s a few Linux “native” releases on steam that use compatibility layers based on wine behind the scenes, which I think is probably what they mean.

Also, this feels wrong, but… Is wine native? It’s mostly just the windows api implemented as Linux libraries. What’s the distinction that makes it “non-native” compared to other libraries? Is SDL non-native too?

I feel almost entirely the opposite about this. I feel like adding a display or inputs is fine, but if you want to say you have Doom running on a toaster then it damn well better be running on a chip that's actually in the toaster! If you just stuff a Pi in a toaster then it's not really the toaster running Doom at all, it's a Raspberry Pi in a toaster suit. I feel like "can it run Doom" is interesting when it shows that common devices have more powerful chips in them than you realize and that somebody hacked it to run arbitrary code. It's sort of an interesting metric to show how far we've come with computers, and how optimized Doom can be... I personally don't find it that interesting if you're just shoving a single board computer into a weird form factor, and it always just feels like clickbait to me.

Some of it’s kind of cool and makes sense. Like developers can get heat maps of where players die so they can see which areas need difficulty tuning, and it can also help developers understand where to spend resources on their games in the future, or notice if players aren’t engaging with something so they can figure out how to make that aspect of the game better. I have mixed feelings about it, but I don’t think telemetry has to be evil.

Am I the only one super unimpressed by most “it can run doom” things? It’s either some beefy arm CPU or a total hack where it isn’t really running doom and they shoved a raspberry pi in it or something.

I think it's totally fair that people would want to stick with what they know and would find a new operating system intimidating. But, I think some of this push back is kind of warranted since people act like you can't play any games on Linux or that the Steam Deck is stupid because it has Linux and isn't compatible with absolutely every game, and I think that's sort of misguided. An astonishing amount of stuff just works these days, and while I wouldn't say a Windows user should switch to Linux unless they have a good reason to, I think some people might be doing themselves a disservice if they're avoiding the Steam Deck because they think it won't play their games (with caveats about anti-cheat and multiplayer of course!)