Addaadah Core Decisions #3

Introducing serious changes since the last in the core decisions series.

Since PRODUCTIVITY is a major concern, in this iteration of the core decisions I’ll restrict the scope of the engine a lot. We’ll be throwing several practically useless goals out of the window. Stuff like:

  • Self hosting.
  • Supporting multiple scripting languages from day 1.
  • Sticking to C language for maximum portability.
  • Allowing engine hot-updates (changing engine parts at run-time).

I’d love to be able to use Addaadah as soon as possible. While having Addaadah reach a mature state might take a few years, having it capable of making games should take from weeks to months if Allah wills. I also doubt that Addaadah will be the last engine that I make. It should be vastly superior to NONGL (which I’m very proud of), but I don’t think it would be my last take at making an engine. So, let’s make this learning experience as useful as possible. Enough talking, I hereby present you with:

Addaadah Core Decisions #3

  • Compiled, no VM. The Bite VM is a wonderful idea that we can implement LATER as an additional scripting language. Sure, having the engine itself running in a VM would allow some very nice tricks, but is hardly necessary for developing good games/apps. I would rather spare all the time I can and use existing tools to reach a working state quickly. Also, the performance gains from being native are more than welcome. So, no… no self-hosting.
  • Javascript for scripting, nothing else (for now). We have Duktape. As long as it works, it’s fine. After some basic tests, it’s evident that it’s more than a 1000 times slower than native code. However, since only the game logic should ever reside in the scripts, it shouldn’t be a problem. Most of the heavy lifting should be done in the native parts of the engine. And if a game/app is too expensive to be done in Duktape, it can always be written in C++, with only minor parts/hooks written in Javascript. And we can always add more scripting languages later.
  • Modern C++. I have hardly written any C++ code in the last 2 years. And -as usual- C++ evolves the most when you are not using it :D. We can use this opportunity to learn more about more recent C++ revisions (like C++14 and C++17). Since we are going to be compiled anyway, I find no reason not to.
  • NO STATIC VARIABLES! The engine shouldn’t assume that only a single instance of the engine is running at any given time. The engine should be encapsulated enough to allow multiple instances to run side-by-side. Also, the engine shouldn’t assume the ownership of the entire app window. It should render to a framebuffer with configurable dimensions. This framebuffer can then be blitted/stretched to the appropriate location in the application window.
  • Use Emscripten to provide the WebAssembly port of Addaadah. It’s been in development for about 8 years now, it should be better than anything I can come up with in a few months.
  • Wrap Duktape. Provide a class with function pointers that point to the correct functions. When compiling with Emscripten, we can substitute for these functions with others that just run the Javascript code directly.
  • Design for Entity-Component-System architecture. The entire architecture should reside on the native side of the engine, but can still be accessible from within the scripts.
  • OpenGL ES 3.0 and WebGL 2.0. There’s no longer a point in supporting the older OpenGL ES 2.0/WebGL 1.0. Besides, supporting both of them is a lot of work, so let’s be practical and drop the older ones now.
  • A text view shouldn’t measure the text everytime it’s drawn. Instead, it should keep a modified copy with the appropriate layouting applied aside from the original text. This is also quite useful when doing bidirection text, glyph-shaping and text animations.
  • The engine is 3D, and uses a node hierarchy to maintain the drawables structure. Nodes could be 2D, but they still belong to the 3D node system. Hence, they can be transformed in 3D.
  • The engine performs drawing on a 2-pass basis, with depth buffering enabled. The opaque structures should be drawn first, followed by the transparent parts. This should add a nice performance boost to apps/games that use transparency a lot.

That’s all that comes to my mind at the moment. Now I’ll have to go and do some major refactoring! Peace be upon you :)

Leave a Reply

Your email address will not be published. Required fields are marked *