
Experimental C++11 multi-platform 3D engine - cfrs
https://github.com/floooh/oryol
======
BruceM
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.

~~~
georgemcbay
BruceM(itchener), I presume?

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

~~~
BruceM
That's me!

------
flohofwoe
I've spent the last few weeks to move the python build scripts into its own
project ([https://github.com/floooh/fips](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).

~~~
mrec
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?

~~~
flohofwoe
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.

~~~
mrec
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.

~~~
kibwen
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.

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

~~~
kibwen
As source I cite this PR that just landed today:

[https://github.com/rust-lang/rust/pull/20218](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!"_

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

------
doomlaser
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](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!

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

------
fit2rule
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 ...

