Experimental C++11 multi-platform 3D engine | Hacker News Reader

Experimental C++11 multi-platform 3D engine

github.com

87 pointscfrs16 comments

This is by the same person that was behind "The Nebula Device" and "Nebula 2" and "Nebula 3" at Radon Labs.

Oryol is a great new take on some of the core concepts of Nebula 3, but in a C++11 environment and being able to rely upon more modern compilers, libraries, etc.

BruceM(itchener), I presume?

If so, I remember you from my nebula hacking days 10-15 years ago. Man, I'm so old.

That's me!

Thanks for the perspective, this info made me go from 'groan another game engine who cares' to 'Oh yeah the nebula device, that was cool back in the day, wonder what this is about?' :)

I've spent the last few weeks to move the python build scripts into its own project (https://github.com/floooh/fips), that's why the Oryol master branch is a bit quiet at the moment, the build system stuff happens on the 'fips' branch (but this is only tested on OSX so far).

I was intrigued by the bullet in your manifesto about using C++ "because Rust is not yet ready to replace C++".

Obviously not disagreeing given that Rust is still pre-1.0, but I'd be interested in hearing what you see as the big stumbling blocks; is it just library/tooling/ecosystem maturity, or do you have major reservations about the language as it stands?

Rust is currently developing so fast that this bullet point in the manifesto is nearly obsolete. C/C++ currently still has the edge for multiplatform-support (emscripten, PNaCl, iOS, Android(?), game consoles), but that's about the only remaining point. With Rust it is also easy to integrate existing C libraries (e.g. middleware libraries for game development), which is usually the main problem when choosing a language other them C/C++ for game development.

Yeah, I'm not sure what the current outlook is for Rust+Emscripten. I'd hoped that the recent runtime removal might put that back on the table, but haven't seen any explicit confirmation of that.

Rust programs also seem to produce big binaries, even with LTO, which would be another strike against it for web delivery.

Rust's big binaries (these days, about 500kb for hello world) are due to the combination of two factors: 1) it statically-links by default (if you opt for dynamic linking, you get the typical C-esque 10kb binaries) and 2) it ships jemalloc as a custom allocator rather than relying on the system allocator. Considering that jemalloc would be unnecessary for any program targeting a web-based platform, you'd be able to strip down the compiled size considerably.

Is jemalloc's footprint really in the hundreds of kilobytes?

As source I cite this PR that just landed today:

https://github.com/rust-lang/rust/pull/20218

"It's quite possible that small programs don't use all of jemalloc, and building with -ffunction-sections and -fdata-sections allows the linker (via --gc-sections) to strip out all unused code at link time. This decreases the size of a "hello world" executable for me from 716K to 482K with no measurable impact on link time. After this patch jemalloc is still the largest portion of our hello world executables, but this helps cut down on the size at least somewhat!"

on Rust+Emscripten:

http://www.reddit.com/r/rust_gamedev/comments/2n0x08/emscrip...

That'sa some nice code you've got there! You should share this over at http://www.reddit.com/r/gamedev They might appreciate it more than the HN crowd.

This looks nice. I'd like to try it out. Seems to be taking a sort of opposite approach to Polycode's maximalism. But if you're interested in this lib, I'd say, give Polycode a look over too.

It runs and builds on OS X/Windows/Linux, and includes a built-in content IDE, and full lua integration, with a lua script editor built in the IDE— theoretically you can make whole games from within Polycode's IDE, but I personally prefer to work with it in raw C++, and use the IDE for creating and importing content for a game.

https://github.com/ivansafrin/Polycode

Polycode is currently lacking support for web, iOS, and Android, but it's on the roadmap.

Anyway, nice engine you've got going! Gonna have to try out the demos and see how it works!

This looks super cool, I love that it works with both emscripten AND pnacl.

Being a fan of things such as MOAI and openresty/luvit, which are essentially C/C++ engines within a Lua body, I am of the opinion that C/C++ frameworks still have a lot of life in them. And there is something very fresh about oryol .. its indeed a very usable framework as well as a decent code base, from the perspective of contributing ...

Reply on news.ycombinator.com