The only thing that was different was that we had a number of platform-specific intrinsics to really shake fast code out. E.g. shuffles on x86 on older SSE editions were terrible and we would have custom x86 code for shuffles or let memory out differently.

The only thing we use from C++ stdlib is unique_ptr. For everything else we had our own much more tailored, much faster, stuff. We had something like 10 different array containers for example.

Yeah what you described with templates is what we are doing re speculative optimisation. We have tuned versions for different workloads. We would inspect before we decide which one to run (only if that wasn't slower then just having one implementation, which was often the case because of instruction cache).

Something to be aware of is that on consoles mmapping a page to be executable was forbidden. So no JIT. And you aim for your slowest target so PC just follows that.

I don't think game developers are more conservative than any other developers. We do have large C++ codebases and so it's hard to change.

All modern engines have a few scripting languages tacked on too.

Something like Lua usually is the sweet spot: most of the people developing scripts are not developers. We even had a Java interpreter for scripting once, but it lost favor for this reason.

There were exceptions, but I found that developers generally preferred C# over Java anyway. Our assets pipelines are generally in C# already.

Any speculative optimisation we were doing by hand. There is the whole deferring allocations / moving allocations, both of which we were already doing (e.g. copying every frame).

A lot of our C++ code is intrinsics (including memory primitives like _mm_stream_ps and barriers) and you HAVE to have good control over how memory is laid out (e.g. knowing that data is split between cache lines so that you you don't get contention). Lots of spin locks too. I just don't see how you can do this kind of low level work in Java.

Games are both high throughput AND low-latency and C++ is still king there

Game engine development is very much about processing of data. The pipeline is long and the tree is wide. Being able to reason about complicated data processing topologies mapped very easily across.

In Melbourne, Australia, Football is again another sport (but it not being called Footy gives it a way).

There's also something about those seats where you get back pain when you try to sleep with your own seat reclined.

I saw interlaced NTSC video in the digital days where the combing was much more obvious and always assumed it was only an NTSC thing!

I've never really experienced it because I've always watched PAL which doesn't have that.

But I would have thought it would be perceived as flashing at 60 Hz with a darker image?

I've worked with a lot of code like this (particularly C libraries and litanies of return codes), and it's fine... But I prefer something like Java-style exceptions. And with Java lambdas or Kotlin the trend is unfortunately away from checked exceptions these days...

I too am interested in your other reasons!

Most functions will just pass on exceptions verbatim so it's better than error return values because with them the entire codebase has to be littered with error handling, compared to fewer try catch blocks.

setjmp, etc. are like unchecked exceptions, so I'm also not a fan, but I use this occasionally in C anyway.

I worked licensed titles for a while and that area the quality of a title and whether it sells were largely uncorrelated haha!