xitter.cf/mizuki_izuna/status/21… CAPCOM’s next-gen RE ENGINE work is very interesting. They’re basically attacking several pain points at once: C++ complexity, long build/link times, memory corruption and leaks, awkward reflection, duplicated C++/C# type systems, expensive marshaling, IL2CPP debugging, GC pressure, and memory fragmentation. The answer seems to be RE:Runtime + RE:C++. RE:C++ is built around C++23, but with C#-like semantics layered on top: automatic memory management, generics, interfaces, boxing, exceptions, and access to the .NET standard library. The really interesting part is the workflow. CAPCOM is using C# as the frontend language for parts of the runtime. Code is written in C#, compiled into a normal .NET assembly, then RE:Build converts/decompiles that into RE:C++ and builds it into native libraries/executables. So the rough pipeline is: C# → .NET DLL → RE:C++ → native C++ binary That means developers can work with C# syntax, tooling, libraries, reflection, attributes and unit testing, while the final game/runtime code still ends up native. They’re also doing their own memory-management work underneath this. Instances are managed in 64 KB pages, with page reference counting plus cache and GC optimizations. The goal seems to be reducing the cost of managing huge numbers of objects while improving locality and avoiding some of the fragmentation problems they’ve had before. This also makes CAPCOM’s REDox project much more interesting. REDox is their open-source .NET serialization/data library, with JSON, CBOR, MessagePack-style structured data handling, lazy decoding, streaming, compact token storage, etc. At first glance it just looks like a standalone .NET library. In context, it looks much more like the kind of infrastructure they can write and test normally in C#, then feed into this RE:Runtime / RE:C++ pipeline and ship as native engine code. #RE2026CAPCOM #CAPCOM