mellinoe

You can compile .NET to native statically linked binaries, too.

IIRC in the modern .NET runtime, System.Random should come from here, which is updated somewhat regularly: https://github.com/dotnet/runtime/commits/main/src/libraries.... Although, whether any of these is a behavioral breaking change isn't immediately clear; most are just API additions.

How do you accurately resimulate if you don't rollback everything to the previous state? E.g. a giant wall moved from point A to B but it was accurately predicted (no rollback). Don't you need to roll the wall back to accurately simulate everything around it?

EDIT: I misunderstood the previous comment, I think you are rolling back everything that changed, and not rolling back objects which were "static" in that timeframe.

Other than the fact that WebGPU sucks compared to modern Vulkan + extensions, there’s nothing stopping you from just using webgpu even in a native-only project, with no further abstraction

You can expose a C interface from many languages (C++, Rust, C# to name a few that I've personally used). Instead of introducing a new language entirely, it's probably better to write the library in one of the languages you already use.

Presumably because Minecraft is the only application which still uses OpenGL but would use the extension

Not sure about gpt3.5, but this sort of thing is not new. Quite amusing, this one:

https://news.ycombinator.com/item?id=42331013

If your goal is to learn Metal, then just start with Metal. It's a significantly better-designed API. On top of that, if you're developing on an Apple device then you'll have a decent debugging experience with Metal, as opposed to OpenGL where you'll get... nothing last I checked (but it's been a while).

> .NET OTOH is working on its own project to massively reduce async overhead

Where can I read more about that?

IIRC the couriers were invulnerable, making the strategy even stronger as you couldn't kill them to stop the flow of consumables.

Also, according to this Q&A post on reddit (https://www.reddit.com/r/DotA2/comments/bf49yk) the consumable purchasing logic was scripted, not learned.

Even most technically-minded people still use QWERTY on full-size computer keyboards despite it being a terrible layout for a number of reasons. I really doubt a new, nonstandard keyboard would get much if any traction on phones.

> The brewing process helps a bit but you you can just boil water after all.

Was this widely known?

Shattered Pixel Dungeon is incredible, but dangerously addictive. It's the perfect game for a 4-5 hour plane ride -- speaking from experience over the recent holidays.

This is true, but you do have to enroll by day 60 as far as I know. It’s also a royal pain to get hospitals to readjust billing if you retroactively purchase COBRA coverage after receiving care.

Source on that?

The existence of individual vehicles with very high mileage doesn't feel like a good signal for overall reliability or maintenance req's over a lifespan. I did some brief searches and it seems there's a lot of "record-holding" gas vehicles with several million miles on them, some even claiming to be using original engines. Again though, I'm not sure this is a good representation of how reliable the vehicles are in aggregate.

Chrome the browser is a desktop application, websites you visit in it are not.

I've used Colemak primarily for the past 5 or so years. However, the benefit is primarily in typing comfort and hand strain, not quite as much in speed, although it is probably marginally faster at its limits. I'm still fluent in QWERTY (I'm typing this message with qwerty to make sure it still works :)), so I can switch if needed, or if I'm using an unfamiliar computer (or a phone, etc). Moving to Colemak completely solved the frequent wrist and hand pain I got while typing using QWERTY. Others have had the same experience.

This is ignoring the fundamentally-different issue that was raised, which is that the service boundary introduces a new failure point that doesn't exist in a function call. What you're describing could just as easily happen in a service call, IN ADDITION to the service just not being reachable.

> For the probably best known example, Unity used to have an IMGUI [1] but they've actively moved away from it. It's still there in vestigial form, the API is not removed, but game developers don't really use it.

It's true that the newer retained mode GUI has supplanted the older IMGUI for "game UI" (e.g. what users interact with when playing an actual game built with Unity). On the other hand, the Unity editor itself is still built entirely with their immediate-mode GUI library, and I haven't heard of any plan to move away from that. Building "editor-like" tools (including custom user tools) is still significantly easier to accomplish using immediate-mode libraries.

> OpenAI has a list of something like 7 restrictions.

Some of those are very major, though, and I think the word "restriction" is a bit misleading. Having 5 invulnerable couriers is not really a "restriction" in that it limits or simplifies parts of the game -- it's just a fundamentally different mechanic that changes the way the game can be played.

> DotA players are probably the worst to ask, because the AI is already stronger than they are at a subset of the game and they have no insight into how quickly that subset could be generalised into other aspects.

I think that's a little unfair. Most folks have been pointing out that OpenAI's current momentum-based "deathball" strategy seems to fall apart without infinite regen and a limited hero pool, both facilitated by the current set of restrictions.

I'd agree that nobody really knows how well OpenAI will adapt to the full game, but I disagree that the criticisms I've seen are meritless. OpenAI's current level of play is definitely impressive, but I think there's still room for skepticism given the current restrictions. I (and I think a lot of others) would be pretty disappointed if the TI showmatch happened with the turbo mode couriers still enabled.

Indeed. And to explain further: not all hero combinations are equal. Meaning: you cannot select any arbitrary set of 5 heroes and expect them to perform well. Different heroes have different strengths and synergies that make them stronger or weaker depending on the specific teammates and opponents that are present. This is why drafting is considered such an important (and difficult) portion of the game. In match 3, a purposefully-bad team was selected. It would have been VERY impressive if it was able to win.

There are a lot of very successful indie games written in C# (entirely, not just in a scripting layer). It is very popular for game development.

I think https://learnopengl.com/ is pretty good.

In my experience, trying to get OpenGL to behave the same way (and with the same performance) on a bunch of different systems is actually more work than just maintaining multiple backends. Testing OpenGL on Windows does not in any way guarantee that it's going to work on Linux, or macOS, or whatever else -- even if you don't add a crazy OpenGL extension support matrix into the mix. So your QA budget is already going to include testing OpenGL on all those platforms.

I would disagree with that, especially with regards to Metal. It's a very approachable and well-designed API. It might not have the volume of resources that OpenGL does, but the docs themselves are good, and I have seen plenty of intro-level tutorials that are decent enough. Debuggability is also much better than OpenGL, which I think is important for newcomers. Debugging OpenGL issues is very, very painful, especially with macOS's lack of debug extensions. Metal is described as "low-level", but it's not quite at the level of Vulkan -- things are simpler and more "streamlined".

There's also the problem that a large chunk of OpenGL learning materials out there are hopelessly outdated, and IMO actively detrimental to learning modern graphics techniques. Judging from the types of questions I see around various forums, it seems to be VERY hard for newcomers to distinguish between "bad" and "good" OpenGL tutorials. In general, there's too much cruft for learners to focus in on the stuff that is actually part of "good OpenGL".

> No game developer in the world will write both an OpenGL/DirectX/Vulcan and Metal renderer for the purpose of staying up to date with Apple's "deprecations".

Actually, most game developers do that. Pretty much every game (even ones with a custom, "non-AAA" engine) will have some kind of abstraction layer for dealing with graphics API's. Writing an additional backend for Metal is not a monumental undertaking -- it's a tiny fraction of the overall code you will end up writing. Also game consoles, for the most part, use their own graphics API's which are not portable to desktop PC's.

> How long did it take you to learn colemac?

Not the guy you replied to, but I switched to Colemak last year. It took me about 3 weeks to get to a "usable" state, and maybe 2 months to get within 75% of my previous speed with qwerty. My progression was roughly:

0-1 weeks: Can't type anything without looking at the key map. I would switch back to Qwerty if I needed to type something long out (emails mainly).

1-2 weeks: Weird phase. I can't effectively type in either qwerty or Colemak unless I really "focus" on it. It's hard to describe, but this week was terrible for productivity :)

3+ weeks: Forced myself to use Colemak exclusively. During this time I started doing real typing exercises, and turned off autocomplete in my IDE, since I found that was detrimental to learning. I also wrote a ton of documentation for a couple of my projects, which involved a lot of typing.

Before I switched, I would get intermittent pain in my wrist (maybe twice a month), which has since completely disappeared. When I need to type in Qwerty now, it is very uncomfortable, in a way that Colemak never was.

> The desktop is pretty high-end and should just obliterate that Macbook

I was also a little surprised at how well the MacBook performed, but it's quite reproducible for me. To be fair, this desktop is actually about 5 years old, and it wasn't really "top of the line" when I built it.

> Great write-up! Your speedups look like they line up as expected. Would you happen to know why Aras's look a bit weird, is it the devices he's using? I'm referring to his Metal timings being more than 10x slower than D3D, and being almost comparable to C++.

Thanks for reading! Since Aras is using a GTX 1080 TI on Windows, and an Intel Iris Pro on Mac, I think the numbers make sense. In my case, my GTX 770 is pretty old, and my 2017 MacBook is pretty new, so the numbers line up better.

> It's a fun exercise in ShaderToy to write a recursive ray tracer. Here's mine: https://www.shadertoy.com/view/XllBRf

> And here's a much better one: https://www.shadertoy.com/view/4scfz4

Nice! I should add accumulation to mine -- it'd look much better for barely any effort.