mabster

In most games I would suspect the tree doesn't fall. Philosophy bypassed!

I still use C++ because of constexpr, templates, etc. But I've long given up on OOP (unless I have to).

Terms like "range reduction" will definitely be loaded differently in different fields, so my bad.

Yeah, maybe they don't by the sounds.

I don't do much on GPUs nowadays, but I still find this stuff interesting. I'm definitely going have to do a deeper dive.

Thanks heaps for the info!

Just for your information: when calculating trig functions, you first modulo by 2 pi (this is called range reduction). Then you calculate the function, usually as a polynomial approximation, maybe piecewise.

But if it supports larger floats it must be doing range reduction which is impressive for low cycle ops. It must be done in hardware.

It doesn't surprise me regarding denorms. They're really nice numerically but always disabled when looking for performance!

I couldn't find much information on those. I assume that they don't include range reduction?

I still picture them as expensive. Things like trig functions are still very expensive.

Our previous apartment was listed under the wrong postcode. Annoying for Uber Eats because they would get lost.

Our current building is one of those 56-66 style buildings. Different service use a different number (e.g. postal is 56, gas is 58). We've had a few cases where our address doesn't match so the system rejects us. And when I vote I have to read which number they have upside down!

I don't code in JS very often, so there's that.

Both sets of code were fine, but I understood the loop variant instantly, while it took me a bit longer with the FP code.

As a side note: The only real JS I did was optimising some performance critical code, and I did have to refactor a number of FP chains back to loops. This was because the FP way keeps constructing a new list for each step which was slow.

The BBC used to call out the government, but yeah that has clearly changed.

Australian ABC still does call out the government. In fact they were raided for reporting on the Afghan files. The politicians have threatened revoking the charter multiple times.

The ABC generally leans socially liberal which means it's usually the conservatives complaining though.

I've always felt this is fine, just as long as there are API calls to preload. Then on one screen you start preloading the next screens while the user is navigating your menus to hide all this latency as much as possible.

In the "you're still going to have to wait for something" sense, sure. But the reason ECS exists is because the industry had to change our architecture when we moved to many core CPUs to take advantage.

I'm battling to understand what you want then, sorry. The systems that you say you would like to use (discrete jobs with dependencies) are the kind of systems the industry has been using since the advent of data-oriented architecture, which includes ECS. That is, a job worker process per core plucking off work and doing it.

In the engines I've dealt with, we don't usually have write locks, instead preferring copies of "last frame data" and "next frame data". And all our "read locks" are waits for jobs. Our game code is generally single threaded, but the main loop pretty much just kicks off and waits for jobs.

I guess what is a good threading model to you?

(As a side note I've worked on projects that use ECS on a single core and they still confer benefits there even though that's not what they were invented for)

It doesn't sound to me like the engines you dealt with use ECS, which are usually resolved with a job system (your work units and functors), but correct me if I'm wrong.

The good job systems I've dealt with have their dependencies in the functors. So you "wait" on a job to finish, which is really a while loop that plucks and executes other jobs while the dependency job hasn't finished. This kind of job system is nice to deal with as they are generally low overhead which means all threads (processes really) are generally saturated with work at all times.

I don't really remember any global state with contention because that's generally very very slow, but maybe there were bits of our gameplay code I'm not aware of.

I missed that generation of consoles, so no hands on experience, but yeah it looks like they did the sorting for you on the GPU end. Nice!

The game engines I've dealt with separate opaque and transparent geometry.

It is generally good to render opaque geometry back to front to reduce overdraw, but not going so far as sorting the objects. We would do stuff like render the hands first in an FPS or render the skybox last in most games.

Now for the transparent layer: First occlusion is handled by the z-buffer as usual. If you render from front to back I assume you render to another buffer first and then composite to the framebuffer? If you render from back to front you don't need alpha in your framebuffer and can assume each rendered pixel is opaque, not needing that composite.

There's also order independent transparency stuff though which IIRC does need another buffer, which requires a composite but then saves you having to sort the objects.

That's why I've always liked Java's take on this. Throw an InterruptedException and the thread is considered terminated once that has dropped all the way through. You can also defer the exception for some time if it takes time to clean something up.

The only issue there is that sometimes library code will incorrectly defer the exception (i.e. suppress it) but otherwise it's pretty good.

My Japanese partner was saying that small businesses are complaining about these because apparently some machines that process banknotes are unable to detect them.

I think we will get there in the end but it will be slow.

When I was doing performances stuff: Intel was our main platform and memory consistency was stronger there. We would try to write platform-agnostic multi threading code (in our case, typically spin-locks) but without testing properly on the other platforms, we would make mistakes and end up with race conditions, accessing unsynchronized data, etc.

I think Python will be the same deal. With Python being GIL'd through most of its life cycle bits and pieces won't work properly, multi-threaded until we fix them.

Seconded on Princess Mononoke. TBH, I haven't really enjoyed any of Ghibli's modern stuff since they moved from stories with morals to essentially dream sequences.

Ah, misunderstood you. Thanks for clarifying.

I don't recall the coprocessor having either reciprocal or reciprocal square root? I didn't do much Intel until later in my career though, so I might be missing something though.

Both _mm_rcp_ps (rcpps) and _mm_rsqrt_ps (rsqrtps) are only good for about half the bits.

Agreed on multiplying the top 64 bits rather than dividing: if the hash is calculated via prime multiplications, the top bits are "more random" than the bottom bits.

But we don't really know the hash table type. It could be doing something like hash table -> linked list -> items, in which case they might still be utilising the full 128-bit hash (I'd usually just store the lower 64 bits TBH).

I wouldn't be surprised if _mm_rsqrt_ps is actually implemented using the same bit level trick.

Same as Carmack's, we did a single step of Newton's method and it was definitely good enough.

Yeah, that's what I meant. I would like per column type-hinting so that data frames are type-checked along with the rest of our stuff and everything is explicit.

I don't have anything I can show because the stuff I was working on was commercial and I don't code Pandas for fun at home ;)

The code I was maintaining / updating had long pipelines, had lots of folding, and would drift in and out of numpy quite a bit.

Part of the issue was my unfamiliarity with Pandas, for sure. But if I just picked a random function in the code, I would have no idea as to the shape of the data flowing in and out, without reading up and down the callstack to see what columns are in play.

Breakpoint and then look at the data, every time!

Also, my grief with DF is they aren't typed (typing module) by column. Maybe that's changed though? It's been a while.

The only way to understand what's going on with DF code is to step it in a debugger. I know they can be much faster, but man you pay a maintainability price!

All the places I've worked for had some balance here, but it would definitely be on the very few tests end.

We would write tests to catch a bug in a low level system, and keep the test after. We had lots of Design by Contract, including Invariants that were enabled in debug mode.

But the reality was that we couldn't test gameplay code very well. That changed so dramatically over the course of a project that if we did test we would just end up commenting tests by the end of a project.

And as an optimisation guy, I would often have to change the "feel" of gameplay code to get performance out of code, which is checked by a Quality Assurance team, because it's subjective. That kind of stuff would make gameplay tests very brittle.

The pace of game Dev was incredibly fast. We were struggling to get all our stuff in, never mind adding any scaffolding that would slow us down.

Thanks! I've used the trick and derived why it works a few times, but always forget.

I battled to understand the post. Your explanation got me there very quickly.

That should totally become the norm. It looks so efficient. Way better than vertical writing systems, etc.

I've seen a few Famicom games do the clause spacing though, so it's easier to read. You can almost hear the emphasis tone on all the particles haha.

And yeah in Japanese it's fine, there's a clear visual situation between the Kanji and Kana.

My favourite is a production team spending millions on something trying to make it look like a home movie, etc.

It's fine nowadays but there was a time when "git pull --rebase" worked slightly differently to "git fetch" and "git rebase". I'd get conflicts with the former that I didn't get with the latter.