A new world for DMUX


Goodbye Irrlicht!

I have been working on a no_irrlicht branch, since the custom scene editor still failed to bring decent lighting/visuals to the game I decided I needed to face the elephant in the room and scrap Irrlicht all together. Irrlicht was easy to get started with but has a lot of limitation that are unavoidable at this point in the game.

Time for a new renderer with SDL2 support

At the time of this writing the biggest 2 candidates for replacing it are OpenSceneGraph and Ogre 2.1. Ogre seems to be not all that well documented and forces a lot of things down your throat, or it wont work or will give me cryptic forms. Both renderers can work on top of SDL2 which gives me the abiltiy to use other GUI libraries other than ImGui, which is the final nail in the coffin for the old codebase and I have to start from main, although some common code has been recycled. I am now going to use a GUi library called Nuklear which is written in C but looks visually much more appealing than ImGui ever did. A lot of libraries are getting trashed and some are here to stay. The build system has already had a major refactor. A big reason to use SDL2 is so you can get support for most GUI libraries, which normally support SDL2 and GLFW.

Some aspects of the current refactor

  • Serialization is now standard, templated, and replaces all structs who’s purpose is to just store data
  • New network architecture (which I will blog about at a future post)
  • OpenSceneGraph as renderer
  • new master server which uses a REST API to communicate with clients
  • Uses C++17 experimental filesystem

Things that are here to stay

  • cpplocate; there is no better way to generate absolute paths for a build and install version of your game
  • tinyxml2
  • Vehicle class (will be ported to use OpenSceneGraph)
  • Cereal, and all uses of serialization
  • RakNet, and all NetCommon functionality (minus the custom data classes)
  • Chaiscript
  • Ogre .scene exporter for Blender

Other than that most components have been thrown out/replaced.

The good parts of the new renderers

Some nice advantages of OpenSceneGraph are:

  • Has some development going
  • Direct integration with the STL
  • The code looks very clean and upholds C++ standards
  • Seems relatively well optimized
  • Very well documented and has plenty of working examples.

Advantages of Ogre2.1 include

  • Lively communtiy
  • Modern renderer, or is at least catching up
  • There are examples out there.
  • Already using Ogre .scene exporter

The bad parts of it

Disadvantages of OpenSceneGraph

  • Plugin system is convoluted, most model formats are not supported without external plugins.
  • Some of the examples are a bit old, there was not an SDL2 example, but porting the SDL1.2 example
  • Custom 3D model format, but has more support via plugins.

Disadvantages of Ogre

  • Abstract framework is aggravating to learn
  • Abstract framework makes it difficult to put the example code in your own game and get started from there
  • Custom 3D model format
  • forces external config files down my throat

A word about “common” frameworks used in tutorials

A big reason I have decided that I would prefer working with OpenSceneGraph is because the learning curve for Ogre2.1 is very high, I had almost 50 lines of code initializing things, and I still had more work to do before the renderer was set up. On top of this the tutorials use a common framework (Bullet physics I am looking at you!) which abstracts the renderer away for the sake of not writing the same code for every example. Except what the developers often do not realize is that this strips the tutorials of any real educational quality they once had as now people have to deal with your abstraction from the library, instead of learning the library directly.

My take on the webp file format

My experience with vscode