As someone who's worked professionally with these engines I'd largely agree.
The other thing to keep in mind is that engines are build towards certain strengths/game-types. Trying to do open-world in UE3 required making some fairly invasive and substantial changes as the engine was built more for somewhat on-rails shooter. It didn't support geometry streaming and a number of other things that are needed to seamlessly transition between large open areas. I remember a number of MMO-style games used UE3 purely as a rendering front-end and mostly built the game tick, physics and netcode back up from scratch.
There are "tells" for engines if they aren't tuned properly(i.e. it was really easy to tell UE3 by the 30s frame hitch as the periodic GC ran) but a fair bit of that can be addressed if the team wants to put in the time to enhance or rework the systems involved.
I'm surprised to see someone putting forth the argument that templates are easier to use than macros. I've found the opposite and in many cases the monomorphization of templates to explode code size which has a fairly material impact on performance in my domains. Debugging macros with cargo expand is infinitely easier than debugging template errors.
While you can write high performance C++ my experience is that many people will reach for shared_ptr and their like while Rust will force them into proper structure/ownership as Arc and their like have a lot higher friction.
Look into dead reckoning vs lock step for networking. Lockstep requires determinism at the simulation layer, dead reckoning can be much more tolerant of differences and latency. Quake and most action games tend to be dead reckoning (with more modern ones including time rewind and some other neat tricks).
Very common that replay/demo uses the network stack of it's present in a game.
Multi app works pretty well too, when I need to cross reference between apps throwing them each up on the split halves is way better than swapping back and forth.
It's dense but the Art of Electronics is the one book I keep coming back too. Better as a reference than a tutorial, once you've played around with an Arduino or the like I found it great to opening up the "what next?" part of EE.
That's really nifty, I've got a Serious Business(DSOX-3014A) scope but could never justify a spectrum analyzer. I've got the signal gen so I've though about rigging up their API to do a simple sweep but never got around to it.
> Visual Studio interprets the volatile keyword differently depending on the target architecture. ... For architectures other than ARM, if no /volatile compiler option is specified, the compiler performs as if /volatile:ms were specified; therefore, for architectures other than ARM we strongly recommend that you specify /volatile:iso, and use explicit synchronization primitives and compiler intrinsics when you are dealing with memory that is shared across threads.
> /volatile:ms
> Selects Microsoft extended volatile semantics, which add memory ordering guarantees beyond the ISO-standard C++ language. Acquire/release semantics are guaranteed on volatile accesses. However, this option also forces the compiler to generate hardware memory barriers, which might add significant overhead on ARM and other weak memory-ordering architectures. If the compiler targets any platform except ARM, this is default interpretation of volatile.
Rust would be fine, biggest hurdle is getting all the various libraries that C/C++ already has access too. I was looking into audio modem stuff a while back for APRS and it seems like most of the linux audio libraries already have Rust equivalent wrappers.
It's meant for reading from hardware registers and nothing else.
There's nothing to prevent the re-ordering of reads/code around your volatile block. This is doubly nasty in that Windows will insert a memory fence which makes everything look like you'd want it. Soon as you port to another platform, boom all sorts of concurrency issues.
Seriously, use atomics. That's what they're built for.
The other thing to keep in mind is that engines are build towards certain strengths/game-types. Trying to do open-world in UE3 required making some fairly invasive and substantial changes as the engine was built more for somewhat on-rails shooter. It didn't support geometry streaming and a number of other things that are needed to seamlessly transition between large open areas. I remember a number of MMO-style games used UE3 purely as a rendering front-end and mostly built the game tick, physics and netcode back up from scratch.
There are "tells" for engines if they aren't tuned properly(i.e. it was really easy to tell UE3 by the 30s frame hitch as the periodic GC ran) but a fair bit of that can be addressed if the team wants to put in the time to enhance or rework the systems involved.