15,333 karma · joined June 7, 2009
The way LINQ currently works by default makes aggressive use of interfaces like IEnumerable to hide the actual types being iterated over. This has performance consequences (which is part of why ZLinq can beat it) but it has advantages - for example, the same implementation of Where<T>(seq) can be used for various T's instead of having to JIT or AOT-compile a unique body for every distinct class you iterate over.
From looking at ZLinq it seems like it would potentially have an explosion of unique generic struct types as your queries get more complex, since for it to work you potentially end up with types vaguely resembling Query3<Query2<Query1<T>>>>. But it might not actually be that bad in practice.
But for websites? Can't think of anything.
It's true that Google 'got there first' on a lot of stuff and that groups like Project Zero do incredible work but the idea that we'd be nowhere without Google is a bit silly.
If you know you're engineering for 16-byte vectors you can 'just' align all your data to 16 bytes. And if you know you have 8 vector registers where 4 of them are non-volatile you can design around that too. But without information like that you have to be defensive, like aligning all your data to 128 bytes instead Just In Case (heaven forbid native vectors get bigger than that), minimizing the number of registers you use to try and avoid stack spills, etc. (I mention this because WASM also doesn't expose any of this information.)
It's true that you could just design for a static size on a system with variable-length vectors. I suspect you'd see a lot of people do that, and potentially under-utilize the hardware's capabilities. Better than nothing, at least!
So variable width SIMD solves this by making any module using it valid regardless of whether the target supports 512-bit vectors, and the VM 'just' has to solve the problem of generating good code.
Personally I think this is a terrible way to do things and there should have just been a feature detection system, but the horse fled the barn on that one like a decade ago.
1. Public Domain Fonts
2. Fonts that cost money
The set of public domain fonts is pretty small and most of them are low quality - not all, thankfully - and out of the ones that don't suck a lot of them only support the latin character set.
As for fonts that cost money, just to give you one example, I recently asked a foundry what it would cost to license a font for my indie game. Their quote was $1100/yr with a ceiling of 300k copies sold (so I'd need to come back and pay them more on a yearly basis and the cost would go up if I was successful). This was only for 3 variants - regular, italic and medium - and only for the latin character set. For one typeface.
Certainly if I was throwing around millions of dollars I could pay that without blinking, but it's far out of reach for independent developers (and they know I'm independent)
Lots of games distribute "baked fonts", where the ttf/otf is statically rendered into a bunch of texture atlases and they ship the atlases instead of the font. Many font licenses I've seen don't permit this kind of use, so I suspect a lot of games are actually in violation of their font licenses, if they paid to license their fonts at all.
Hell, just the other day I prepared a PowerPoint presentation for work using one of the stock Office fonts and then I opened it in Office on another machine and the font was missing...
loader_uninitialized would hopefully address the zeroes in the module at least...
This is a tricky one when writing games using async APIs. The game I've been working on is written in C# but I occasionally hit the same issue when game code ends up needing async, where I have to carefully ensure that I don't kick off two asynchronous operations at once if they're going to interact with the same game state. In the old days all the APIs you're using would have been synchronous, but these days lots of libraries use async/await and/or promises and it kind of infects all the code around it.
It does depend on the sort of game you're building though. Some games end up naturally having a single 'main loop' you spend most of your time in, i.e. Doom where you spend all your time either navigating around the game world or looking at a pause/end-of-stage menu - in that case you can basically just have an is_menu_open bool in your update and draw routines, and if you load all your assets during your loading screen(s), nothing ever needs to be async.
Other games are more modal, and might have a dozen different menus/scenes (if not hundreds), i.e. something like Skyrim. And sometimes you have modals that can appear in multiple scenarios, like a settings menu, so you need to be able to start a modal loop in different contexts. You might have the player in a conversation with an NPC, and then during the conversation you show a popup menu asking them to choose what to say to the NPC, and they decide while the conversation menu is open they want to consult the conversation log, so you're opening a modal on top of a modal, and any modal might need to load some assets asynchronously before it appears...
In the old days you could solve a lot of this by starting a new main loop inside of the current one that would exit when the modal went away. Win32 modal dialogs work this way, for example (which can cause unpleasant re-entrant execution surprises if you trigger a modal in the wrong place). I'm still uncertain whether async/await is a good modern replacement for it.
Intel and AMD are both big players with a vested interest in promoting the capability of CPUs and promoting the capability of non-NVIDIA GPUs, since they sell both. They're big and well-capitalized, so if they wanted to they could be operating big graphics research teams (whether they are is unclear to me, and it's obviously not a 'snap your fingers and you have a big graphics research team' situation, but they have the resources)
In some cases if you see CUDA being used for a demo or a research project it's just because the alternative stacks kinda suck, not because only NVIDIA hardware is capable of doing the thing. Researchers aren't necessarily concerned with shipping on 99% of consumer machines, so they can reach for the most convenient approach even if it's vendor-locked.
I won't be surprised if we see some researchers start targeting Apple's platform-locked Metal API in the future since they have compelling unified memory offerings with capacities exceeding everybody else's.
For one example, Ultima 1 was developed by a couple people, sold for ~$40 USD, and eventually sold over 1.5m copies according to https://www.newspapers.com/article/austin-american-statesman... and other sources. So that alone probably made everyone involved in the game's development millionaires, even if the publisher took a huge cut.
See https://www.theguardian.com/us-news/2025/mar/17/defense-depa... for one example where it's particularly blatant.