Pannoniae

It's basically "you can't make a mod inspired by the other mod we're hugging the rights for"

Completely missing the part they didn't ask for permission to mod the base game either..... and that Thaumcraft (the original mod) had assets consisting mostly of random images copied off google images. Yes you can't make that up. "You can't steal what I've rightfully stolen!"

There's an element to that, but also, the more QoL you have and the smarter unit AI is, the less you have to do that. Yes, unit AI obviously won't ever play as good as you do but if you control a few units at key locations you'll outperform someone who's trying to control everything and do a mediocre job at it. You might say "how about they control every unit then" - works in games with a few units, way less so when you've got unit counts in the hundreds.

What's wrong with that? Yes you can less around with strictmath and fixed-point and all that stuff, and if you have cross-platform determinism needs then you kind of have to.

But it's much easier and makes the game faster to just not bother, compile the windows version and let people play under Proton/Crossover :)

imo the better question is whether it will actually get to court, and the precedent on that is mostly no. so it doesn't really matter i think

Even with 5.0 I could get through stuff with like approx 60k functions and ~15MB of executable code in a few weeks.

5.5 is even better. It's so glorious. I've got some modern game. I don't have the source. I'm curious how it works. After a day and a half it's already 5% bytematched ;)

>Licensing/copyrighting encouraged people to think up of new things

I don't think it did... think about it for a second. If you have to recreate something from scratch every time vs. being able to/being allowed to take something existing and improve it, which regime results in more innovation? Probably the second, because progress builds on each other. I might have a better idea to implement more features, you might be able to optimise it, someone else might make it more polished, someone else might add a nifty UX trick, someone else might refine the art, etc. etc.

Traditionally, this was only done on open source projects and even there, the barriers to contribute have been historically high. (Have to open merge request, get through the gatekeeping, document your stuff, etc.)

Now it's much easier, point agent into code (or binary), change stuff, have fun;)

That sounds very abstract... while I can't deny the social stuff / the art is important for many people but most players just want to play the output. Before you say you can pirate things or emulate them yes you can but not if you want to fix bugs, add 4K support, make it run better, improve things, etc.

Actually, you'd be surprised! For something relatively modern, it's MSVC or GCC, you only need to pin the version. Which you can do by bruteforcing a few functions with different compiler versions / flags until they match.

For very modern stuff it might even be clang. Also easy to detect. For really old stuff (90s and older) there's a lot of diversity yes but the programs are so small it isn't a real challenge. By the time programs got so big as to make manual reversing infeasible, the compiler landscape has consolidated;)

I'm calling doubt on that one. Yes you can do it, it's possible but not with Total War fidelity and mechanics.

Definitely, TW can "cheat" a lot with using sprites/very low LOD at distance, only streaming the corresponding units on battle load, and it's turn-based so performance isn't critical. Although obviously you won't be doing those 50000 unit battles on the web.

Off-topic sidenote: what's with all these new projects targeting WASM instead of native, even if packaged for desktop anyway?

Sure, but the LLM can either 1. recreate the assets from the good old "view it from multiple angles" trick 2. exfil the running game from the servers :P

And why do you think people won't be able to rip the streamed games too?

Stricter NDAs protect against insiders, not outsiders.

More security restrictions yes, that will work, but unless you actually go airgap all the code, there's an access point somewhere which can be vulnerable, either through the network or through the human init?

How would cloud-only prevent this? Do you think LLMs can't exfil the game from the server? They're incredibly persistent and are willing to try many things. Random credentials, vulnerabilities in the game servers / dev machines, or even social engineering the devs/the deployment.

No I'm dead serious. I've seen a whole a bunch of talk about "omg they'll move to cloud gaming and you'll own nothing anymore". Putting aside the obvious barriers everyone is talking about (latency, lack of uptake by consumers, etc.), there's also the elephant in the room - if you can point an LLM to a binary, it's not that much a stretch to point an LLM to try to hack or social engineer its way into where the game is hosted. Or a random dev machine. Every script kiddie will be doing that...

and why do you think it's safe in the cloud / in a TPM?

I've seen the bug with my very eyes because I wrote that renderer and I did test on all three vendors:P

Zero debuginfo-related warnings on any driver (except the usual "buffer location is VIDMEM" spam), NV is fine, intel is fine, my (RDNA) AMD card is fine on both Windows and Linux, user with a Vega 64 isn't fine.

We dug into it together and it literally swaps the colours somewhere, and the user said that it crashes randomly on games (confirmed by others, not one-off HW failure), does the same colourswap or have very glitched rendering.

I guess the only salvation is that people usually play DX games under Windows and the bug didn't happen over DX11. But the same rendering restricted to even standard GL3.3 just got BGRA-swapped.

JIT and SMC are two different things because JIT is write-once-then-execute, SMC is write-many-then-execute-many. Even with reoptimisation like the JVM, you're not modifying the existing code but writing it onto a new page. That is the key difference, you're not modifying existing written-out instructions, you're creating new ones.

"We’d like to initialise our Vec in parallel, otherwise we’d have to wait for the main thread to fill the entire Vec with a placeholder value only to then have our threads overwrite those placeholder values."

Talk about overengineering :P Multithreaded vector initialisation instead of just...skipping it?

Self-modifying code is a meme unless you're writing an obfuscator... (but even then you can hook the execution so it's a pretty low-tier anti-reversing effort ngl)

For perf reasons it's the equivalent of shooting your leg off to lose weight. You're flushing the instruction cache and breaking prefetch, leading to a huge stall. Then you do it again. And again. It hasn't been in vogue since the 80s...

1. Better memory locality by knowing what you load and when, exactly.

2. The ability to "cheat" on calling conventions.

3. The ability for techniques like threaded code, and in general, better cache-awareness.

4. Less mov's.

5. Guaranteeing no spilling in important loops.

6. Compilers don't do well with flags registers and you can't read/write them in high level languages. You're hoping your `if (result < a) { carry = 1; }` becomes a direct flag test. Especially important in bignum, you can't really utilise adcx/adox directly from high-level code.

7. Hot/cold layout without PGO. Yes PGO is good but sometimes you know better and PGO isn't very suitable for "configurable" code.

8. Computed goto. See https://github.com/python/cpython/issues/128563 , who doesn't like 10% free performance?

9. Exploiting uninitialised memory for classic party tricks like not initialising a buffer fully (let's say you have a library function with a return buffer. You don't want dynamic allocations for some reason. You can simulate this with a pointer return into a let's say a static 4KB buffer and a count return, you only initialise it until the count. Caller has the responsibility not to overread.)

Yeah, that's what MSVC and GCC did on x86, called "custom calling conventions" on MSVC and the regparm attribute on GCC.

All of these were dropped on x64, on x64 (and ARM) you get standard calling conventions for just about everything with proper unwind tables for functions.

It doesn't really "cheat" on the registers unless it inlines a function entirely. LLVM has support for custom calling conventions and pragmas to specify them, this is used by GHC on Haskell and other things, but it's practically unheard of in "normal" C/C++ code.

on older (read: older than RDNA) AMD GPUs the OpenGL drivers are so poor that half the games just either crash outright or have colourswap bugs (RGBA -> BGRA i.e. your game turns blue and orange)

On Linux at least you can use Mesa to fix it up. On Windows you're.... out of luck I guess unless someone writes a binarypatch or something?

I wouldn't call it great support, NV "just works"

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...