Pannoniae

Tbh I'm not very concerned. Unlike chess, which has very finite state, the "build something appealing" kind of game has a very vast amount of state. And the current architecture of LLMs doesn't make them very "creative" (whatever you define it as). If given a scoped task, they'll relentlessly try to complete it but the design, as we speak, is still your job. You can get AI to clone something already existing, which does decrease moats, yes. Making it do something new is way harder.

All those one-shot games and product demos are clones of existing things, and while they're very impressive, they aren't exactly new ideas, you know?

Of course all this might change and the labs might figure out the secret to creativity, but as things stand today, humans can keep "moving up" the value stack to just make more complex things.

Same. I do use blueprints (I usually make copypasteable smelters, circuit factories and whatnot) but only in the same save, all of them get chucked when I start a new save. And of course no copying blueprints from the internet at all.

So the first iteration of the design is always slightly wonky, so it remains fun :)

>that's what AAA games do

yeah where the pixel work and the vert count is magnitudes higher. I forgot to mention in my comment that I was talking about low-poly / pixel stuff like this, with a very simple PS and being pretty much API bound or memory-bound in perf

FYI the prev comment is also clanker stuff, it's just purposefully prompted to inject grammatical errors. It's obvious from the word choice and the sentence structure, it's very stilted in an inhuman way. The wrong commas aren't a common error (unless you're 70+ yo) but LLMs keep doing "word ,another" and "word,another" to appear quirky

esp when all the caps are missing but all the punctuation are perfectly present

"And as far as I understand, this means that so long as you stay short of decompilation - you can reimplement as much as you want."

Yes, but my point is that.... go on github, you'll find tons of decomps. And many more done just privately too. One of the No Man's Sky devtalks start with "yeah we decompiled the terrain generation from this other game, implemented it in our prototype, it didn't work okay, here's how we've learnt from it to make something better". This was in 2016. More recently, this has been going on way more openly, even full AI-assisted decomps thrown up onto GitHub casually. It might be the letter of law or included in Terms of Service but no one cares really.

Nice article :) Yeah this is basically a tradeoff between CPU and GPU power. There are different types of culling. There's the basic stuff like backface culling (supported in hardware, don't render triangles facing away from you) and frustum culling (don't render objects which your camera doesn't see). These are used in just about every game.

For occlusion culling it's a bit more tricky because you can either do it on the CPU in broadly two ways, either do low-res raycasting / software rendering like in the article on the CPU and cull based on that. This is an adaptive workload, you can give it more threads or CPU power and it scales for better culling which results in less pixels rendered on the GPU.

You can also use GPU culling but that's more complicated to do and that uses the GPU which creates a catch-22 - you want to use GPU culling to reduce GPU load but integrated GPUs don't cope well with compute shaders and memory bandwidth in general, so doing a culling pass might wipe out any culling gains you might have.

And dedicated GPUs have the raw power and memory bandwidth to just submit everything in your frustum and get most of it depth-rejected.

I wonder if it would be even faster to create a connectivity graph on the CPU, like each chunk knows whether a neighbour is visible and vice versa. On rendering the chunk graph is walked and the visible chunks are submitted, kind of like a primitive garbage collector to determine liveness. The culling would be worse but I presume traversing a fairly small (few thousand elements) list is quite a bit cheaper than rendering the "mipped" occlusion boxes, but do let me know if this is wrong.

Most products do in fact have an anti-reverse engineering clause in their EULA, to be fair, it's been a standard EULA term for a long while. It's just that no one cares anymore...

1. I'm not familiar with the hardened stdlib stuff except for the msvc debug runtime but if you have a solution for this, skip this one. You presumably want boundschecking (and throwing/failing hard) or at the very least, logging out of bounds accesses.

2. A non-inlined grow. If you have large collections you modify often, you want a vector implementation where the reallocation is out of line and the rare case. All the STLs treat it as a normal method and have inlined by codegen.

3. Trivial relocation support so you don't need to destruct objects where there are no pointers inside or external objects pointing to them.

In your case it's probably not as relevant/important, yes

No I'm not. And it's not just MSVC-specific either, they're just not very good.

std::vector doesn't have trivial relocation so any type with a destructor ends up doing elementwise destruct+construct instead of a memcpy.

std::map and std::list are memes and if you use them you're giving your CPU the 1995 treatment with all that pointer chasing.

You thought std::unordered_map is better? Well, actually not because node stability, so it's still chained-bucket, you almost always want to use a flat map like boost::unordered_flat_map or the abseil/eastl version.

<random> is hard-to-use and isn't very performant, std::regex is "you might as well write it in Python and it'd be faster", <iostreams> is virtual calls galore, both the formatting and the stdio functionality are slow.

The conveniently-named std::function is a very general device resulting in a heap allocation and usually a virtual call, there's specific optimisations but don't rely on it.

The STL string manipulation functions are also usually slow, they check the locale for string manipulation rules.

The floating-point functions set errno preventing vectorisation and emitting branches in your straight-line float code unless you use fastmath (the thing people tell you never to do) or one of the more fine-grained compiler-specific switches to turn it off.

std::shared_ptr is Arc<T>, not Rc<T> and eating the cost of atomics can add up in many situations especially with all the other memory traffic going on.

std::variant and std::visit are also not very fast either.

std::filesystem as a whole also has several pain points like iteration which is like a magnitude slower than the native APIs, std::chrono isn't much better either

std::error_code sounds like a simple integer or even a struct.... lol no guess what, more virtual calls

1. Compilers barely do even basic optimisations such as interprocedural register allocation when faced with non-trivial code. You often also need the most aggressive optimisation settings, LTO or even PGO enabled for many of these.

2. Virtuals are, with the exception of PGO, mostly a black box i.e. you get a hard optimisation boundary, no inlining at all.

3. The C++ standard library is usually comically slow (yes, even compared to Java/C#/the likes) so if your project uses std::vector and the such instead of specialised libraries, you've already lost at the beginning.

4. If you don't pay attention to performance from the get-go, the approximate amount of autovectorisation you'll get is close to zero. Some compilers are better than others (Clang>MSVC for example) but I've seen codebases with 8 figures of LoC where the number of vectorised divides/multiplys was like less than ten when you dumped the object listing. In the whole program.

5. Since aliasing and other optimisation barriers (you didn't use restrict or manually hoist, did ya?), it's not uncommon for large C++ programs to spend a third of their runtime doing atomic increments because shared_ptr is supposedly cheap and who cares about lifetimes anyway.

6. If you're targeting Windows, the default new operator / malloc is also comically slow. Luckily that one is fairly easy to fix with installing mimalloc and deploying the hijack dll, but the negative effects on cache by the fragmented allocations is also significant.

No it's not because it sucks the air out from the actual solution. ISPC more than a decade ago managed to demonstrate close-to-linear speedups for increasing vector sizes, even for branchy code.

Nowadays you can even get AI to write intristics and it works just fine, the portable libraries/autovec aren't really a serious player here.

Portability is also overstated - see the recent shift where Spotify decided to make native Android/iOS apps again instead of React Native. Usually, the number of relevant platforms is somewhere between 2 and 3, so portability concerns are more theoretical than real.

I'm a pro-AI midwit and I've upvoted you, but please don't solicit upvotes, it's against the site rules...

Great job! 32-to-64-bit conversions are always fun :) One question though. If this is intended for desktop, why bother with WASM at all? Do you gain anything other than less performance?

"No" is also an answer. Sadly one which isn't considered by many people :)

No but almost all good ideas can be reduced down to a few sentences if you're good at explaining things. It's a different kind of intelligence than what's commonly called IQ but it's something like that regardless.

Sure the explanation will oversimplify a lot but then you can expand it recursively if needed, you gotta start somewhere.

Most musicians in history didn't know how to read music, yeah. Less so in the present day but just about every folk song has spread by the word of mouth, and even in pop music many genres have a strong oral tradition (jazz, blues, rock, you name it), they play by ear and not by sheet.

Yuuuup exactly. I guess this is masked because old 90s games are often more culturally significant so people haven't found these problems yet but yes, these are serious challenges.

Yeah IMO the next big thing will be a way of verifying equivalence while filtering out the "noise" differences in optimisation. Otherwise you can't really decide whether you got it correct or not.

Correct me if I'm wrong (I'm not very well-versed in game decomp scenes) but aren't all those bytematched decomps from 90s or at the latest early 2000s games? They didn't have global optimisation (MSVC introduced it in VS .NET or 2003 I think and many games didn't use it until later)

So these are mostly problems with more advanced compilers yk

Hey I'm not working in matching something with LTCG atm :) I'm just saying in general.

And yes if you have a pdb / an Od build then things are much easier, I was assuming arbitrary game i.e. release binaries.

The "knowledge laundering" approach you describe might help in reconstructing headers, class layouts and function names which is a godsend although I don't think it would be enough to get a match. Getting functionally equivalent code is muuuch easier (although there's the problem of "how do you verify that without running every function")

Cheers, enjoy the rabbithole:)

A small pointer, it's hard to do interpret statistics because most people play on multiple platforms. Roughly 75% of gamers play on mobile, 45% on PC and 40% on console.

I'm not 100% sure about the numbers, just off the top of my head about looking at market research, updated numbers welcome

"assign all these pointers to the correct types, a wrong guess leads to different COMDAT folding"

"get the order of local variables in this function right, otherwise the register allocation doesn't match. Oh and there's 150 local variables just in this function, good luck trying them all"

"Find out the translation unit boundaries exactly (assume there's no pdb otherwise this is trivial) and after doing so, figure out the order they were compiled in, otherwise it won't match"

"brute force the compilation flags for the project and if you're done, also bruteforce it for the CRT or any other middleware which usually came prebuilt so it doesn't match the main game"

Should I continue;)

With /LTCG /GL I don't think it's possible to get matching (or at least it's a very tall order), the codegen is wayy too volatile for an exact match and since inlining and reg alloc work on heuristics with thresholds it really cascades. Even stuff like what order you declare your locals in or the exact frontend syntax can mess things up...

Correct, this is just hacks for stuff you didn't manage to match exactly. Either that or your build environment isn't the same. Sadly, there are things which aren't really possible to reproduce in a byte-identical manner, things like exact file layout or variable declaration order, compilation order and that kinda stuff. And they might cause small but equivalent changes like different inlining/optimisation decisions, so it's really tricky to get it byte-exact.

I said it's not possible to legislate some things away, i.e. unviable legislation. A hard ban on modding / AI reimplementation isn't viable, because you can't really keep data off the internet, evidenced by things like leaks, Anna's Archive etc. remaining online. People can always reupload the remade GTA or whatever onto noname fileshares, code forges, torrent and so on.

TL;DR: You got promoted or you wanted to get promoted. You decide you want to make a bigger project to show ambition, advance your career and whatnot. You embark on making some grand project, disappearing from view. This often leads to you getting stuck with something, falling behind and various negative effects like getting a PIP or becoming depressed.

His prescription to avoid this is to keep checking in and show some progress on something every day so you don't lose touch.

(My analysis: I don't think this is particularly a senior engineer problem, to me it just reads like ADHD-coded problems with time and interests)

In that case, wouldn't piracy shift to hacking the servers and exfiltrating the binaries/code?

You don't have a buffer overflow problem if you read it in a memory-safe way i.e. read it in chunks and realloc when you reach the size of your allocation.

What you will have is a potential denial-of-service attack - although this one isn't particularly great because there's zero amplification (they might as well just send garbage into your firewall)

Sorry, I'm just being realistic. "Whenever there's a will there's a way" and so on. People have tried to legislate all sorts of various things, even stuff like "PI = 3" without much success because they weren't viable.

I don't see how this disproves my point. There's a vast divide between "theoretical" and "applied" software engineering. You don't usually see Google engineers publish their search optimisations in journals. And similarly, you don't see university professors making commercial libraries from their articles' ideas. This isn't the case in every field but in software, it very much is.

And this implies that training on the "theoretical" side of things doesn't give you much insight on the "practical" side. Stuff like cyclomatic complexity, UML diagrams and all that stuff might be well-represented in literature but way less so in real software, so training on the literature will produce completely different software than training on production software code.