Hacker News new | ask | show | jobs
by sylware 1286 days ago
A modern 3D engine, written in conservative C, fully libdl-ized (100% of system dependencies are dynamically loaded, "libc" included). Proper compile-time(OS abstraction) and runtime(fallbacks) tables of functions. The hard part is the discipline to stick to c89 with benign bits of c99/c11/etc to avoid planned obsolescence via C syntax and/or the compilers.
1 comments
krapp 1285 days ago
I feel like this subthread is less about what would make a good game engine and more about aesthetics and personal itches.

That said, make SDL2 the core and use Lua with LuaJIT for the scripting language and consider me sold.

Also something something Webassembly, I don't know. There's a reason the road to Hell is paved with game engine implementations.

link
sylware 1285 days ago
That would be the technical core only and, of course, the 3D game engine (or 2D), could be "bad" (and that's a big word), even with a clean technical core, and the other way can be true too, a game engine can be "good" (still a big word) with an horrible code base.

SDL2 is only a part of the OS abstraction, it is way below the game engine layer. I don't know if SDL2 is properly "libdl-ing" everything (its "libc" dependencies included). On elf/linux platform, it means there is no C runtime "main()" function but the SYSV ABI entry point (which is basically a main() anyway), and the build products should be pure and simple(aka with the least amount of relocation _types_) ELF64 shared libraries. This has to be inspected with tools like readelf: namely, there would be only libdl in the DT_NEEDED ELF section. That said, even with clean libdl-ing, care must be provided on the used symbols with their versions (they must freaking old, and I mean REALLY old since there is a manic abuse of versioning from the glibc devs, probably msft grade planned obsolescence). Ofc, some peculiar libs (libm?) should be statically linked into binaries directly.

On top of SDL2, some runtime and compile-time tables of functions are still required though, and this is a process which must be started right at the beginning, and NOT on the main platform (then probably NOT doz), that to be sure those runtime and compile-time tables of functions are designed right from the start. I am talking about the OSes, but the hard part is 3D APIs: vulkan/metal/console, to please all those APIs and make they work on many drivers... oooof!

The devs of "drag" (steam), did the right thing: code and dev on elf/linux, test on elf/linux, and also build for doz and test on doz. Basically, seeing doz as on embedded platform. Weirdly enough those guys were quickly hired by a doz-only game company :( . Those guys were making a good game and it was technically amazing.

link