Janet

@Janet

22/9/22

log inask
Janet
@Janet
erysdren
@erysdren
adorablesergal
@adorablesergal

Gamedev circles are gonna hear about jumping from Unity to Godot Engine right now

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

A few helpful links:

id Tech 1:

id Tech 2:

https://github.com/andrei-drexler/ironwail
https://github.com/darkplacesengine/darkplaces
https://www.yamagi.org/quake2/
https://github.com/NVIDIA/Q2RTX
https://www.fteqw.org

id Tech 3:

id Tech 4:

https://dhewm3.org/
https://github.com/RobertBeckebans/RBDOOM-3-BFG

Editing tools:

https://slade.mancubus.net
https://trenchbroom.github.io
https://netradiant.gitlab.io
https://github.com/Garux/netradiant-custom
https://www.darkradiant.net

(I'm sure there's way more but I'm actually kinda tired rn and i want to curl up and be soft. pet me, you nerds)

You must log in to comment.

in reply to @adorablesergal's post:

sirocyl
@sirocyl

I'd explored this for game dev with @8rium in the past. It's a bit of work:

  • first, you define a "platform closure" or "envelope" - what your game needs to interface with, in order to function. This can be files, input, display, network.
  • then, you write a "platform enclosure" around the specifications of this envelope - essentially a virtual machine. It will implement the parts defined in the envelope, and load a compiled program into its VM. this part is independent of your game, but it is the "OS" that your game is now targeting. you make this part open-source, but under license rights that allow you to distribute proprietary copies (so, Apache, MIT, BSD et al).
  • then, you fork your "platform enclosure" and make a native binary for your proprietary/console target. it is closed-source, and under the necessary proprietary rights to allow the necessary console libraries and NDA code/function call names to be included as needed.

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.

tl;dr: you make a VM for it

(I'm not a lawyer, and this is just a hypothetical proof of concept for now.)

login to reply
sirocyl
@sirocyl

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.

login to reply
sirocyl
@sirocyl

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.)

login to reply
adorablesergal
@adorablesergal

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?

login to reply