This is a VERY experimental project to port the godot engine to C, mostly to satisfy my curiosity.
Yes, this is probably a very bad and dumb idea. However:
1. I want to learn C.
2. I noticed a while ago that it would not be too difficult to convert simple / clean / [orthodox](https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b) c++ code to c, (except for virtuals / inheritance it's mostly simple text editing - and even that system is mostly only a one time setup -) and godot's source base is super good in this regard. Also godot is only using single inheritance, which makes things a lot easier. Also a possible solution: https://www.cs.rit.edu/%7Eats/books/ooc.pdf .
3. There is also this paper https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf . Where they compare the energy efficiency of a bunch of languages. However what caught my attention is the run speed performace: C 1.00, C++: 1.56. Yes I know that what they tested is a bit different than a game, where you have virtuals, and constant cache misses due to the program execution going all over the place, however if even half of that can be achieved, it's might worth the time and effort.
As a first step I think I'll just start by removing unnecessary things from godot, that I don't personally use / need.\
Making the list below made me realize that just doing this should probably improve my life by quite a bit.
Also I'll probably change things over time to a form where just switching to a C compiler is possible (kind of the list below, but in a lot more incremental fashion.), if I end up going as far as C.
This repo might end up being a just a test bed, if I end up doing these they will probably happen here: https://github.com/Relintai/pandemonium_engine .
If the ClassDB is extended to handle engine side virtuals, then there is no need to implement them in C.
I think the simplest way might be to:
0. make engine side virtuals implemented in classdb.
1. Make a tool that creates global functions for every class methods, copy paste class method content to that, and amke the class methods call the global one.
like:
Class Vector2 {
void normalize() {
vector2_normalize(this);
}
}
vector2_normalize(Vector2 self) {
//normalize;
}
2. then change the binding api to only take the global methods, and not the instance methods.
3. Then the class methods can be removed. (except for operators.)
4. somehow unroll the operators into new global methods.
Vector2 a, b;
a = a + a + b * a;
-> turn these into normal method calls;
5. Get rid of references in mthod arguments, turn them into pointers. (Or rather move the & symbols to where a method is called.)
6. Turn templates into macros. They also need to become c-like.
7. Turn destructors and constructors into globals aswell.
8. Get rid of contructors.
9. Get rid of destructors, but somehow calls need to be inserted everyewhere where c++ just calls them.
10. Set up c struct "inheritance". If classdb handles engine side virtuals this should be almost trivial to do using the GDCLSSS macro. Also casting will only need to be implemented in Object::cast_to, and Ref<>.
11. Switch to an actual c compiler.
12. Could actually do this with some of the modules. For example Bullet. Also MAkeing an alternative physics engine from bullet that is simplified, might not be a bad idea.
12. ????
13. Profit?
Most of these (the transformations) might be doable with clang complete and maybe with simple vscode extensions.
Also they wouldn't even take that much time to do.
Now the only question that reamins is that would this worth it.
Pros:
- Code completion for C is a lot simpler. (And a LOT less resource intensive.)
- Syntax highlighting for c is a lot simpler. More tools can do it well.
- Lower level. You can optimize the code more, because it's easier to notice inefficiencies when working closer to metal. (Like unecessary type conversions.)
- I'll get to know godot internals even better. Like 2d rendering.
- Less bloat: I'll probably remove things that I personally don't use. Like GLES3, Lightmapping (shadows would stay), VisualScipt, GDNative, more arcane asset loaders, probably assimp (stuff can be imported in vanilla godot and transferred. Maybe I could have a custom tool for it), etc.
- I'll probably remove things that I personally don't use. Others might needs those. Less interest from others. -> I can just hack whatever I want. Like I can have simplified physics engines that only do collision detection and kinematic body moves, no dynamic physics objects, also can experiment with software rendering (really good to have for tools) etc.
- Will likely never have RenderingDevice and Vulkan, and multiple window support. However based on what is going on in the world right now, vulkan is probably not worth having for quite a while. Only high end phones can use it righ now, and I don't expect adoption to increase anytime soon. In fact I think we might actually see adoption go down, as people will just go back to using their older devices if the new ones break (because of both price, and stupid - kind of orwellian - decisions on the behalf of the manufacturers.). (Also on the desktop we have gpu shortages, and higer prices (even laptops) etc). Also I kind of like to mess with vertex color a lot more, so I don't really need to many advanced features anyway.