Tech Warlock
Weird dude who makes weird things.
Part of the Swamp, Part of the Krewe
Fair enough. Sensible choice, but there's another FOSS option: id Tech engines.
Why id Tech? There's a bunch of 'em!
Is your strength 2D sprites? id Tech 1 will make your art shine
Low-poly style? Ray tracing? id Techs 2 and 3 have solid design tools and oodles of history to help you
PBR? Modern workflow? id Tech 4 can run the gamut of old and new hardware
iโve genuinely been thinking of forking off id Tech 2 as a jumping off point
itโs daunting to me as iโve never really done much work beyond unity, but id Tech 2 goes so hard
I support this adventure. It's just a nice happy little engine to play with <3
only concern i have with the id techs is that idk how gpl code intersects with porting stuff to consoles. i have to wager that platform holders would frown upon the source code for the ports being released
I'd explored this for game dev with @8rium in the past. It's a bit of work:
Your GPLv2 game will now be running, as-is, on both a free platform (the open-source form of your enclosure) and the encumbered platform (which is the same code, closed-source, and with console libraries in it).
It may work with GPLv3 as well, as you can demonstrate the same game binary (which you compiled for the platform enclosure) can run on both the console and outside it, by taking a checksum of the game binary.
(I'm not a lawyer, and this is just a hypothetical proof of concept for now.)
i mean, i guess it's not gonna matter terribly given the orders of magnitude weaker hardware those engines were designed for, but not a literal vm right? more like, a compatibility layer?
i guess the way i'm parsing this is how, like, Virtualbox is GPL licensed VM software but needs a proprietary plugin in order to access paywalled features
depends on how you decide to implement it, or what restrictions guide your development.
You might need to write a VM proper in order to meet e.g., restrictions against loading executable code outside of the main executable or certain DLLs, but that applies more for very modern platforms (like the Nintendo Switch). You may also be able to transclude the compiled VM state directly into the encapsulating platform binary, and compile them together ahead of time.
Regardless of how it's implemented, the "free" part of your game needs to run inside of a "closed" part of your game, which interfaces with the hardware/top-level OS, and it can not be in a "linking" relationship, which means source code-to-code access between functions inside and outside of the encapsulation, both being compiled together.
the way I'm implementing this for my game, is to literally map certain direct I/O - display framebuffer, HID button bitfield, and files - to memory address ranges in a RISC virtual machine based on the static "JIT" code-generation technique used by iSH, but not including the code from it, as it is GPL. (I've called my code reference-generation engine "gadJIT" and it's more generalized.)
Hahaha, Iโm seeing this chost- the chost! -getting passed around in a normie discord of mine.
Figured youโd be amused to know. Your wisdoms know no bounds.
I am but a humble wej of face who knows what she likes, and what this sergal likes is old engines that still do cool stuff.
It's gratifying to see my chost getting some reach tho. Like, I don't expect people to flock to id Tech engines; they're defo from a bygone era of gamedev that predates the whole Nice Chunky IDE That Does Everything. There ain't no node graphs here...
... but at the same time, you can still do things if you have the determination, and people have done things. Some of the most beautiful gamespaces I've ever seen are from Quake 1. So why not try? Do a little experimentation, eh?
