devRant - A fun community for developers to connect over code, tech & life as a programmer

back in the day, by which i mean over a decade ago, i was a pretty big fan of the blender game engine. it was extremely barebones, but really fun because you could quickly make a model (textures, material, animation and all) and then slap some logic into it with python, all inside the same program.

me much liked that for funny brain tickle. but after a few years playing with it i eventually concluded that making a serious game with it was off the table. my reason? it's not all that great when you want to get technical with it, like say:

[dramatization] what? you want to write logic in C++ to speed things up well fuck you that's impossible but actually no it's entirely possible what happens is we have our scalps glued to own asses and the effort of living in this bent over backwards position makes it so the only way to ever meaningfully interact with code that is very much contained within the freaking binary is forking, modifying and recompiling the whole damn thing.

are you kidding me. the fuck were you smoking when you designed this.

but let me explain what i mean so that you can better understand my point ok. i had all necessary headers from blender source, so i could use structs and classes defined within them in my own code. so i compiled that to a shared object, open up blender, and load the *.so through python. worked, remember like it was yesterday.

so surely i could obtain a pointer to anything and pass that to C++? yes, absolutely, but it was entirely useless because i couldn't call any functions. functions that were loaded in memory, because they were all part of blender, but completely invisible to shared objects, so dynamic linking fails if you try to do anything meaningful with them. your only option is recompiling blender and using the statics in the build directory when linking your shared object.

that's stupid, isn't it. so i opened an issue about this on the game engine fork, saying something like:
"hey, i need to add some symbols to the dynamic table to make a public api for C extensions, is that ok? i'll do it myself, just tell me where the linker flags are actually being set, i can't find it in this cmake mess. this is just so one doesn't have to duplicate the entire codebase for every tiny extension."

the answer was this, AND I QUOTE:
"sorry i don't understand anything too technical."

...

anyway what followed was a thorough and painfully long look at alternatives which only left me disappointed. and by that point i already had enough experience with opengl that i said you know what, fuck you all: i'll make my own engine with blackjack and hookers.

but fast forward to today, still no game. sadface.

on the bright side, now i have super compiler utilities that trivialize a lot of problems my younger self had when writing C. cool, i can do much more with way less. code better too. but time? i'll never get that back.

just just just a few more months to go please. avtomat is *almost* there, i'm so close i can taste it. just need to hook the preprocessor into the C building pipeline, and then i can get back on track with... ugh, fuck! fixing the library code my engine depends on!

this is what i get for trying to do things MY way. suffering. but also mystical powers so it evens out.

ok back to you caroline.