Here’s the deal: this used to be the SpriteBake thread. I am now overhauling the idea, merging it into my engine’s repo, and writing an entire game logic and animation managing thing that I’ll be using for it. Turns out, making it a “prototyping” tool for upbge 0.2.5 that you can straight-up use to make entire games in sounds exactly like what’s been on my mind since forever.
So, why not? I’ll just pack everything together and wrangle it with Blender. Find a way to expose my C libraries to python or something and take legacy upbge to unprecedented glory!
Gigantic undertaking, but what else would I do. This will be my life’s work. My grand opus, a momentous burst of insanity manifested into the game making toolset I always wanted. Strap on your belts because I’m going in full force!!!111one!!
Right now I’m announcing my intent to spam this thread with what I’m working on as to give people who don’t want to read my code the abridged version of what’s been going on. Once I’m done “getting my bearings” I’ll update this again to give a more formal presentation.
As for now, here’s some links for those that DO read code. The Blender bits be at src/BlackMagic and src/DarkAge. Everything else is codewalls of data-oriented C (for now).
First off the list, I don’t like the logic panel and dealing with properties there. Limited only to basic types, for one, no lists, lots of clutter, and components don’t quite cut it.
So, I’m making my own logic panel and shoving it up object properties.
From this panel I’ll manage properties, what happens during each state, and when one transitions into another. So basically a proper object behaviour editor you can use to make stuff happen without drowning in spaghetti.
Next up: simple property evaluation-driven triggers and setting up game properties to calculate their values from another prop. Kind of, damage = (base + str_bonus) * stamina_left or something funky along those lines.
Alright, so previously lists could only hold up to eight values. Boooring! Now I’ve rewritten the system to hold as many values as python will allow you. UNLIMITED POWER!!!
Also added dictionaries! It’s the same system, but with keys. ARENT YOU EXCITED?!
Disclaimer: I cuss in this video. Not loudly, but softly, gently. Just the right amount of effs.
Properties and list/dict items as expressions next up, and then finally getting around to doing actual logic. Exciting!
I’m organizing the files as not to have everything on the same folder, and stuck rewritting major sections of code to do away with bpy.props as much as possible; it’s just terrible and I will die on this hill.
So now I’ll just write my own bins like I always do instead of dealing with Blender’s effedup sense of humor. How does the new system work? You define a data folder and all your stuff is saved there. And when you open a .blend that’s using DarkAge, it looks for that data folder you set. Simple, innit?
I suppose I should also write some additional functionality to mark certain files as being part of a larger project, so that global settings like the datapath remain the same for all .blends within that multitude of files. Eh, they wouldn’t be global if I didn’t do that now, would they?
So yeah, luts of work here. The final result should be worth it, as without the restrictions of bpy I can just do whatever I want. Oh it’s gonna be neat, bucko.
Taking a short break from doing UI so right now I’m shoving a lot of stuff back to C because I really, really want to handle as much as I can at the ‘low’ level. Not just for speed, I actually enjoy it more that way. Hopefully I can make it so python is only necessary for interfacing, i.e. to communicate every now and then with the code that’s doing the heavy lifting.
I’ve had a lot of crazy ideas since I started this py to c mambo but I don’t want to share any of that insanity yet. Eh, gimmie a few days till I’m done testing out what the limits are here.
I can make attributes of a python class accessible from both python and C without having to directly extend the BGE module and recompile Blender so great, I can do whatever I want and it doesn’t require creating a new fork. There’s some more stress-testing to be done but so far things are looking good.
A lot of stuff could be sped up by a metric ton. Now I’m actually excited.
I’m writting a shell and designing a programming language, that’s what.
WHY?!
I’ve been using Visual Studio for years and I’m fed up with it, so I switched to doing all of my coding in Notepad++ and then compiling with GCC. I had some problems with Makefiles that annoyed me enough to push me into rolling out my own build system.
So, since I already wrote a build system and also need a way to manage projects I said okay, let’s do that as well.
I have a working prototype in python, which is ultimately useful for compiling the actual program, and I’m busy sketching out how I’m going to handle some messy operations in pure C. Well, I know how to do these things but they are so ugly and verbose it drives me crazy.
What to do? Define my own syntax and interpreter, of course. I can do that just fine, input fancy statements through a beep-boop machine to get C files as output, then compile that. Drawback is this obviously can take me a while, but what the heck.
And just look at the UI, man. It’s ALL text. I’m crazy like that.
Alright, done and done. My manager can now automate builds.
Now that I’m not dependant on Visual Studio for compilation and replicating the build environment I can breathe a little easier.
Next up is rewritting Zajec, my general-purpose library that’s at the core of DSM. I will slowly convert the entire project to pure C (well, my own flavor of C, called PE$O) and resume work on Blender tools once the file converters and data managers are up to date with the new system.
