When the work to have a configurable render pipeline started, it had 2 goals.

1. More flexibility for rendering, by allowing different objects to be rendered by their own rules
2. Better optimization through automatic calculations/heuristics

Release of 0.7 is in the last stretch, and I would like to give a high leve explanation of how the rendering is handled within Limon now. All hard coded parts of the render pipeline has been removed. Instead, we now have a fully configurable render pipeline, as well as a plugin system for rendering backend, meaning OpenGL can be swapped with OpenGL ES, or Vulkan.

Its been 10 months after the release of 0.6, and there is no release or update, and main branch didn’t get far since, and I am not happy about it. The thing is, I was actually working on a new release, but it turns out the functionality I undertook was not as small as I anticipated. I am trying to make rendering extensible, you can see the work on generalizeGraphics branch.

With more than 6 months of work, and more than 550 commits later, version 0.6 is released. This is the first release that enables shooter logic to be implemented solely using the engine provided facilities. Most important change is addition of “Player Extension” and “AI Actor” customisation points. With these, it is possible to implement shooting, being hit, chases etc. in a unique manner as you wish your game to be. Of course to enable wide variety of possibilities, API had to be improved, and it has tripled in size since 0.5 release.

TL;DR version: I won’t remove the branch, you can check out all code changes step by step on “ssao” branch.

I released the 0.5 at the beginning of August. This release is important because it is the first time Limon can be used to build a game. It adds GUI, sound and extensibility. With graphics and I/O already present, you have all the basics needed. It doesn’t mean the engine has reached some sort of maturity, the goal for 1.0 is supporting first person shooters, and we have still work to do for that.

The last couple of weeks I was thinking about how to approach extensibility of the Limon Engine. I worked on a prototype that loads python code into the engine, but skipping c++ plugins didn’t feel right. I knew the basics, a library might be compiled for dynamic linking or static linking, I need to provide a header etc. But when I tried to implement it, I quickly realized, to create a shared library (.dll or .so), I will need to compile a whole lot of the engine itself within the library, or linker won’t be able to create a binary.

Hi,

Hi,