
Oryol: A small, portable and extensible C++ 3D coding framework - severine
https://github.com/floooh/oryol
======
rl3
Orthodox style argument aside, this project uses a build system written by the
same author called _fips_ [0]. I've tried it myself, and it's an absolute joy
to use. A few simple commands will get you up and running on any supported
platform, and it does an excellent job of telling you what went wrong if
there's a failure. It also has a system for compiling the same shaders to
multiple platform targets.

Oryol's demos[1] are impressive as well. Especially the ones that showcase
emulation and various integrations of immediate-mode GUI frameworks.

The entire project is underrated in my opinion. With web assembly slowly
coming alive, there's a distinct lack of small, multi-platform engines
designed with the web in mind. I only wish Oryol's ecosystem was larger, it
could be a realistic alternative to Three.js perhaps—if it isn't already.

Keep up the good work floeofwoe. :)

[0] [https://github.com/floooh/fips](https://github.com/floooh/fips)

[1] [https://floooh.github.io/oryol/](https://floooh.github.io/oryol/)

~~~
rl3
_flohofwoe_ *, sorry.

Curse the two-hour edit window.

------
sdegutis
I'd love to know what people who work full-time with C++ think of the
"Orthodox C++" concept (link in the article) that this project adheres to.

~~~
Animats
It's a reaction to the Boost crowd, who took C++ into template la-la land. For
realistic programing:

* Avoid multiple inheritance. It seldom helps and there are lots of confusing cases. Putting one object inside another is fine. If your inheritance tree is more than two or three deep, you're probably doing it wrong.

* RTTI is better than unchecked downcasting.

* STL collections are fine and should be used in preference to built-in arrays.

* Avoid Boost. If anything goes wrong, you'll spend days to weeks figuring it out.

* Exceptions are not that bad. Go and Rust now have de-facto exceptions, with all the complicated unwinding machinery, but they're called "panic" and "recover". Just make sure that anything you pass in an exception is a self-contained copyable object with no pointers to anything, because that's where ownership and allocation trouble appear.

* Don't do anything in a destructor that can fail or block. Like closing files opened for writing. Destructors are for releasing memory. Raising an exception in a destructor is not a good thing.

* Don't overload operators for anything other than math. It just confuses people.

* Streams are more cool than useful. But mostly harmless.

* unique_ptr and move semantics have promise, but it may be too soon for those features. If you have complex ownership issues, consider Rust, which has compile-time checking for that stuff.

~~~
vvanders
Small nit but Rust's panic is not an exception mechanism:

[https://doc.rust-lang.org/std/panic/fn.catch_unwind.html](https://doc.rust-
lang.org/std/panic/fn.catch_unwind.html)

Particularly you may not be able to catch all panics. Result<T,E> is the
canonical way to handle errors in Rust.

Also in gamedev(where this looks like this comes from) we generally avoid
RTTI(for size reasons) and STL(for allocation control reasons, see EASTL,
etc).

~~~
Animats
For both Go and Rust, it's not _supposed_ to be exception handling. But both
languages have acquired proper unwinding, so people can and do use it that
way. The original idea in Go was that if you caught a panic, the program was
in a bad state, and all you should do is report the problem and maybe restart
the program. Like "longjmp" in C. Now, people are doing recovery without re-
launching the program. That's effectively exception handling.

