I've been spoiled by engines with simpler code but this looks promising. Good luck with it.

I generally like the code I saw. It was clean, simple, easy to read. But...

1. Why are you using exceptions to handle errors? That is the most ugly and inefficient method I can imagine. Callback stacks work much better since they preserve the call stack on error. They also use only as much resources as you want them to. Exceptions are generally undefined in terms of performance, often coming with lots of unjustified overhead.

2. Why is there access to code that serves no purpose for the user?

Importer::instance().import<Mesh>("C:\Dragon.fbx");

Why not 'ImportMesh("C:\Dragon.fbx");'? Same goes for all singletons you have there. Unnatural complexity is not helpful.

3. Would be great if you wrote somewhere that this is not a game engine. Just a basic rendering engine with input handling. Didn't see 3D sound playback support, for example. But what about occlusion culling? It's a must-have rendering feature. Skinned meshes? Any kind of culling at all?


So I'm sure it's good for what you say it does. But unfortunately that's far from enough to ship a game.


As for your future plans, some advice: "Play-in-editor" is a bad idea, especially for C++ games. If the game crashes or corrupts memory, it will bring down the whole editor. Not a pretty sight. I suggest implementing playing in a separate process which can be launched by pressing a button in the editor.

Thanks for your input. The whole thing is a work in progress, I hoped I made that clear in the article - many high level features are still upcoming. I agree with you about exceptions but it's not something I have gotten around to replacing yet.

Why are you using exceptions to handle errors? That is the most ugly and inefficient method I can imagine. Callback stacks work much better since they preserve the call stack on error. They also use only as much resources as you want them to.

I've never heard of using callbacks for error handling before. Return results and 'error' pointer/reference parameters, certainly, but never callbacks.

That sounds interesting. Do you know of any articles discussing that method? I can't find anything on google.

I've never heard of using callbacks for error handling before. Return results and 'error' pointer/reference parameters, certainly, but never callbacks.

That sounds interesting. Do you know of any articles discussing that method? I can't find anything on google.

No idea about articles, I was implementing the approach in my scripting engine. It's kind of like how a debugger works, setting special callbacks that should be called on certain system events. Like the Windows SEH system (SetUnhandledExceptionFilter) or signal handlers in other operating systems.

It's perfect with scripting engines because they free resources automatically in any case, even after skipping code execution. It takes a bit more work to support skipping code execution with usual C++ code, however, the callback still allows you to do introspective debugging and continuing execution after the error/warning. And it blends in nicely with logging systems, allowing the use of error severity codes and error messages. So all kinds of messages can go through the system and their severity can be elevated or reduced via callback overrides.

The typical use case is to simply log all data about the error/warning, perhaps even generate a stack dump file. The other most common one is to ignore a specific error/warning completely because it's expected and the default handling method is sufficient to proceed. Callbacks handle both very well.

And for those few moments when a catch-all handler is necessary near the entry point to continue execution regardless of errors (more common for GUI apps that are not games), there are the regular exceptions.

As for the code, there are two ways, both of which can be hidden in the implementation of a special class.
- method 1:

callbackStack.push( my_new_handler );
<code>
callbackStack.pop();

- method 2:

old_callback = currentCallback;
currentCallback = my_new_handler;
<code>
currentCallback = old_callback;

- with the special class:

CallbackScope cs( my_new_handler );
<code>

The second one requires a bit less resources but you'll have to deal with the old callback manually if you intend to call it from the new one.

Callbacks for error handling is also popular in web development (i.e.: node.js and Javascript in general).

1. Why are you using exceptions to handle errors? That is the most ugly and inefficient method I can imagine. Callback stacks work much better since they preserve the call stack on error. They also use only as much resources as you want them to. Exceptions are generally undefined in terms of performance, often coming with lots of unjustified overhead.

I don't know what turned your opinion against exceptions that much, but they are, I believe not just in my opinion, the cleanest, safest and most readable way of handling errors.

Exceptions preserve the call stack, too. Any connected debugger can be told to break when an exception is thrown, or just when an exception is left unhandled. Getting the callstack when the application crashes at the end user is possible, too.

With exceptions, you also don't have to write tons of boilerplate code pushing and popping cleanup callbacks onto stacks. And you don't have the runtime overhead of a dynamically allocated container (you seem to be using std::vector). Plus you don't have to provide a thread local global "callback stack" to any and all of your engine's systems (creating a monolithic piece of code forcing anyone into this scheme of doing things).

Exceptions are extremely efficient, too. Google "zero cost exception handling" - the days when a try..catch block resulted in a setjmp() instruction are pretty long gone. In fact, you can't create anything remotely as efficient for cleaning up without getting down and dirty with stack frames and the instruction counter.

I don't know what turned your opinion against exceptions that much

The actual cost and lack of debugging options. Should be obvious.

Exceptions preserve the call stack, too. Any connected debugger...

Do you expect the end user or a collaborating artist to have a debugger and the skill to use it? Seriously?

With exceptions, you also don't have to write tons of boilerplate code pushing and popping cleanup callbacks onto stacks.

What "tons"? I count less than 10 per 10000 lines of code.

And you don't have the runtime overhead of a dynamically allocated container (you seem to be using std::vector).

Implementation details. Use a fixed-size array if you wish, makes no difference to the algorithm. In fact, no need to punch strawmen, whatever "seems to be" isn't a fact.

Plus you don't have to provide a thread local global "callback stack" to any and all of your engine's systems (creating a monolithic piece of code forcing anyone into this scheme of doing things).

Make it fully global, use a mutex. It's obviously not expected to be used more than 10 times per frame anyway (usually closer to 0), probably much less than that, code inside lock would be very fast.

As for "forcing", you're confusing callbacks with exceptions there. When you "throw", you force someone to handle it. With callbacks, it's handled at the same place, without any unexpected jumps and making no difference for the calling code - should it be required to disable the system, it can be done, unlike with a "throw" - it will always jump!

Google "zero cost exception handling"

I did and here's what I've found: http://mortoray.com/2013/09/12/the-true-cost-of-zero-cost-exceptions/ (the punchline starts with "The term “zero-cost exception” is a bit of misnomer")


P.S. C++ exceptions don't need an apologist. They're really not working well for most things, their only value being the leak-preventing call stack jump feature.

I don't know if it makes sense to continue this discussion. You seem far too worked up / polarized on this.

• - Only you need a debugger. The "this application needs to be closed..." window you get when an application crashes (or the terminal output you get on Linux for that matter) contains a crash dump. When you user, artist, whatever sends that to you, you obtain the complete callstack from it. Often the sending process is automated with an error reporting wrapper.

• - If you only add that code to 10 out of 10000 lines then you have an incomplete callstack. I don't see how that would help with debugging (you first post talks about being able to get a call stack).

• - If you're using a fixed array you still have overhead. And a limit.

• - A mutex is the wrong choice: you'd mix callbacks between different threads. If you want to use your stack in a multi-threaded application, you need a thread-local container.

• - Yes, throw means "I've encountered an error I can't handle in this scope" thus it's jumping to higher scopes until one can deal with the error. And it can't be swiped under the carpet accidentally, letting the application continue in an invalid state.
  
  And cleanup is still handled locally (see RAII which you demonstrated yourself).

• - Let me quote two more sentences of that punchline:
  
  The term “zero-cost exception” is a bit of misnomer: it refers only to the runtime cost when exceptions are not being thrown. The actual overhead in throwing an exception is quite high.
  
  Zero runtime cost unless an error occurs. Sounds good to me. The article underlines my points, by the way.

You can decide for yourself that you just don't like exceptions, I don't mind. But your arguments here are flawed and strongly opinionated. I think if you manage to take the emotion out of it, you'll find that your concept may have merit for C, but is on very weak footing in C++.

The "this application needs to be closed..." window you get when an application crashes

I'm talking about every kind of error/suspicious situation (memory access errors, assertions, missing resources) imaginable, not just crashes. So it's a strawman from you again. Obviously if the application crashes I can get a dump out of it. I'm merely proposing an extension of this method to any error imaginable, with all of the included benefits. You can even use exceptions inside a callback. Won't work the other way around.

A side note: having dealt with dumps before, I hate them. I prefer full and verbose call stacks to fragile binary data that would lose all value on any mismatch between compiled binaries.

- If you only add that code to 10 out of 10000 lines then you have an incomplete callstack. I don't see how that would help with debugging (you first post talks about being able to get a call stack).

What do callback stacks have to do with call stacks? Strawman (or a major misunderstanding) again? Call stacks are provided by included debug symbols and a helper library that is able to read them. Completely unrelated to what I'm proposing.

- If you're using a fixed array you still have overhead. And a limit.

What overhead? How is there overhead to setting one pointer and in-/decrementing another, twice for every time you need it? As for a limit, sure there is one. Everything has a limit. But not a hard one and it can be removed, depending on implementation.

- A mutex is the wrong choice: you'd mix callbacks between different threads. If you want to use your stack in a multi-threaded application, you need a thread-local container.

Ah yes, sorry about that, you're right here. Not sure how this is a problem though, I'm sure exceptions have the exact same thing in the implementation, one way or another. Oh, and like I said, the actual stack object is unnecessary. You can keep callbacks in the stack, thus removing these threading issues from your code completely.

- Yes, throw means "I've encountered an error I can't handle in this scope" thus it's jumping to higher scopes until one can deal with the error. And it can't be swiped under the carpet accidentally, letting the application continue in an invalid state.

Sure it can be swiped. `try{ bad_code(); } catch( ... ){}`. Exactly the same thing can be done with callbacks, except that the call stack is not lost and everything moves on from that exact spot.

As for "higher scopes can deal with it", it instantly increases complexity of the code. Suddenly you don't know if a line of code after the throw is supposed to be ever reached. The code becomes unreadable. Sure, you know if you read everything. But does everyone ever have time for everything?

Zero runtime cost unless an error occurs.

Not if...

• compile target doesn't support it
• exceptions are expected to happen for each slightly unexpected situation which isn't really an error (file not found, file is found, etc. - examples from boost::filesystem), as is common with exception-happy code, which is when things get really slow

So it's like saying, "use exceptions, love them, but no more than a few in very rare cases". Sounds like a major contradiction to me.

But your arguments here are flawed and strongly opinionated.

Flawed how exactly? I agree about the mutex, that was stupid of me but what have I said that was really wrong here? All I see is nitpicking and strawmen.

I think if you manage to take the emotion out of it, you'll find...

What I have found is coming from experience. Emotions, though sometimes present in my wording, have nothing to do with it. Also, it seems your horse is a bit high. I already know callbacks work, I have been using them for a long long time, haven't stepped aside ever since I designed the implementation for my scripting engine.

Yeah, I'm outta this discussion.

You falsely claim I set up a strawman when my point stands, with or without your std::vector, you dishonestly quote a single sentence from a website to make it say the opposite of what it actually did, you call me an "apologist" for just asking what riled you up against exceptions so much. It seems you consider this a war, not a discourse.

This has turned too toxic for me.

-

Regarding the original topic, this looks like an interesting engine, good work!

The general architecture appears to be inspired by Ogre a bit (the RenderSystem, RenderQueue, SceneManager and so on all look very familiar, down to the method names and coding conventions), but I welcome that, since at its core, Ogre is a very nice engine that only accumulated a lot of cruft over the years :)

Maybe you could add a bit more information about the hows and whys of the engine's architecture. It would be pretty interesting and provide something to learn from, apart from just providing a nice introduction into the engine.

you call me an "apologist" for just asking what riled you up against exceptions so much

Strawman again. I called you an apologist because you defend something that clearly has flaws, without actually proving that anything I mentioned about its flaws was false. You chose instead to attack your incorrect interpretation of an error handling system I proposed, one that has been used in so much software, including operating systems.

with or without your std::vector

No, it's *your* std::vector. That's precisely the problem I'm having here. So-called criticism towards false interpretations. In my second comment here, I clearly mentioned two examples ("Like the Windows SEH system (SetUnhandledExceptionFilter) or signal handlers in other operating systems.") which you clearly haven't bothered to look up, otherwise we wouldn't be having this exchange of words.

---

since at its core, Ogre is a very nice engine that only accumulated a lot of cruft over the years

Ogre has been a horrible engine for a very long time (has it ever been good? doesn't seem like it). I don't know much about the v2.0 rewrite, but the version before that is just horrible. Here, have a look: http://www.bounceapp.com/116414

This is fantastic, I was aiming for a similar goal for a play in editor, but built on top of Urho3d. I had additional goals of my engine being deterministic with mostly automatic networking (All the user would have to do is choose what variables are 'gameplay variables' and then input/events would be synced between clients). Until I realized C++ is an annoying and redundant language, I wanted a clean modular engine built on the best language possible. At which point, I started looking into Scala and other languages.

Nonetheless, I hope your able to get some steam behind your project. Don't be afraid to reiterate unlike most game engines out there. (Don't be afraid to break things)

I will definitely try out your engine once you have C# support integrated.