Hello, just thinking of some random ideas, now, as for retro gaming, it is becoming a lot more popular lately (a plus for me, either way i like stuff from the good-old days though),
I noticed people have made BRR players in Godot, and recently someone made a plugin for Assembly;
Could Atari, C64, NES, SNES, Genesis development be possible with Godot?
If so, would it be a good, or a very bad idea?
It would require basically just an assembler and library for each platform for the console-specific syntax, and could take GDScript and just compile it, or it could be a plugin for each console-specific development in each their own respected languages, with a simple bitmap editor for sprites and tiledata, taking simple music composition via a tracker.
Considering none of these devices could run the engine itself what youâre describing is basically turning Godot editor into some kind of specialized IDE for an entirely different framework. Which could be done, I suppose, but at that point youâre better off either making such an IDE from scratch (possibly with Godot) or making extensions for a more general purpose IDE (VS code, zed, etc.).
If all goes well youâd only need to make a release template for console ports.
If you do not have official dev kit access (which most do not for older generations) you will have to build the engine against homebrew libraries and the target architecture. Sometimes a specific compiler for the console would help.
Godot has a lot of modern features that will not work on older generations, projects that have attempted homebrew ports usually start with an older version of Godot that focuses on OpenGL.
This list doesnât go very far back, it only gets harder to support even slower, less modern consoles. Having OpenGL support is a great first step, otherwise you are basically re-writing the entire rendering pipeline to start; at which point, why use the engine? Theoretically speaking, porting will take expertise you could better spend on making a game, not a game engine, and youâll be cutting feature after feature; if anyone finds your project and wants to port their Godot game to your fork they will be in for a lot of trouble and may request yet more of your time if they have unrealistic expectations.
I suppose you could make a tool using Godot to do this. Rewriting Godot to provide first-party support for these platforms would be a lot like trying to convert a commercial jet liner into a tricycle.
I suggest staying with something like Pico 8 (PICO-8 Fantasy Console) if you want to achieve this and still get the retro feel. If you are determined to get it running on the actual system, consider something like NESMaker.
Technically speaking, the platforms you described are simply too underpowered to support basic features of Godot, like GDScript or the way it renders graphics. Iâm pretty sure even the initialisation logic for Godot is too resource intensive RAM wise to even run.
For a start, GDScript would need to be changed into a compiled language. At that point you would have something that looks like GDScript but works more like assembly (which is what most games were written with - raw machine code). In other words, you would lose most abstractions (classes for a start) and be dealing with raw memory. Not fun to learn or understand things quickly. There are also a lot of platform-specific oddities which would make GDScript less universial.
The graphics also work completley differently from how Godot abstracts things. I wouldnât know where to begin⌠probably from scratch. Probably if you even tried, a new graphics API would have to be created to implement any features. This is not to mention rewriting custom scaffolding for things like openeing a Godot window, networking, audio, disk etc.
Godot technically runs on itself (i.e. the Godot Editor is more or less a Godot game). The tools to build an executable for any of the platforms described probably do not exist, and if they do, they probably do not support the e.g. C++ 17 standard. Even if you got it to run, it would be too big to fit on a cartrige of the time.
To give you an idea of what emulating one of these consoles is like, someone made a video talking about testing correctness of emulators. You can see what strange issues end up coming up when emulating a 40 year old NES: https://www.youtube.com/watch?v=oYjYmSniQyM
So, making a crossplatform devkit for NES, SNES, Atari, etc. would be more ideal?
Emulators usually do have a lot of inconsistencies, depending on which one is used of course,
however i was thinking more like a plugin ROM compiler for each language that allows you to basically code any old retro consoles in GDScript, and i know that you dont always have to use assembly/Basic, and there ARE libraries out there, but it would be pretty cool to utilize the Tilemap layer node as a retro sprite editor/retro tile editor, with different parameters to control the colors and ids for each pixel, etc. and make an easier way to code retro games, i guess this would eliminate a lot of the features of godot though.
Usually the retro community is a lot more spread-out and niche, per say, but having this would mean that devs could go into retro game programming without installing a bunch of different frameworks and languages to their PCs, instead, just a plugin for the software they already use.
I probably wont ever be able to make something like this, but maybe someone out there will make similar? Theres so many possibilities for what can be made in Godot.
Really this was inspired by my curiosity to use binary SRM files as save data, but minor detail.
Compile GDScript to 8-bit platform-specific assembly? Seriously? What would be the equivalent of var foo: float = 0.5 in 6502 or 2A07 assembly?
Those machines cannot even natively handle integers larger than 255. Merely implementing a basic 16 bit floating point arithmetic would eat half the address space on those platforms, not to mention massive amounts of cpu cycles needed for a single fp arithmetic operation.
In order for this to make any sense, youâd need to âdowngradeâ GDScript to almost-assembly level, at which point you might just use assembly on the actual platform.
8 bit machines are not some lowres pixelated versions of todayâs computers. Itâs a whole different universe.
If by devkit you mean game creation software like Godot, then yes. Basically NESMaker but with targets for various retro consoles. It would be cool, donât get me wrong. The fact that NESMaker exists is rather exceptional.
From a Google search, SRM files look like just dumps of the emulated consoleâs memory and CPU/GPU etc. state. Itâs a lot more like pausing your computer, copying the state of everything and saving it to a file. Its a lot more like being able to dehydrate and then rehydrate a fruit perfectly. Unless this was not what you were getting at?
Iâm sure thereâs some weird and wonderful hacks you can do get the Godot running on an emulator (especially if you do away with memory/storage limits). That would involve porting x86 to the specific architecture, however (a lot like what Apple did with Rosetta, or how some person managed to get Mac OSX running on a Wii).
To iterate on my previous post, and to perhaps give slightly better insight as to what it would involve to port GDScript: the main challenge with GDScript is that it has almost no bearing on the internal workings of the computer. The source code is taken into an interpreter, then that converts it into machine code (and creates a lot of assumptions). The interpreter adds quite a bit of overhead. In machine code/assembly it is up to you to define the concept of âŚeverything. Functions basically donât exist, you just have jump operations. Variables also barely exist, you memorise their names by raw memory addresses, and have specific instructions to read/write them to RAM. Types (e.g. float) do not exist, they are just memory addresses you perform instructions on. There are logic limitations, like if statements are just jump operations that check a number. The game TIS-100 by Zachtronics takes a lot of inspiration from assembly. If you get the chance to play it, imagine going from that language to being able to write out GDScript. By getting the logic down to such a fundimental level, is how people are able to make redstone computers and video players in Factorio.
MicroPython kind of achieves what you want to do with GDScript. It cuts Python down to run on microcontrollers by sacrificing quite a bit of functionality.
From there, to port features like sprite maps etc. they would need to take into account platform specific GPUs (I donât think they were called that back then), and somehow universalise all the quirks (e.g. limit pallets).
If what youâre after is the feel of retro computing, I think you are better off taking the comforts of modern game/software dev and trying to replicate the looks/quirks/feel, rather than trying to make a port for a console. An emoji of a smily face is a lot better than trying remember what 0x0001F60A means
None of this is impossible, just not done yet. A devkit like this would be a cool project to see though!
Theoretically itâs possible, sure, but in practice itâs as good as impossible.
Even if you manage to minimize GDScript to some pseudo-assembly form, thatâs only a minor part of the problem. The main thing is translating Godotâs architecture to target 8-bit architectures.
For context, Godotâs plain Node object takes about 1K of memory. Other nodes may take considerably more. The NES had grand total of 2K of memory. If you use Wozniakâs 6502 floating point implementation which takes up 800 bytes, and store one Godot node in there. Youâre left with about 200 bytes for everything else. Thatâs less than what the text of this paragraph had consumed so far. Or you can ditch floating point, store two nodes, and have several bytes left for the rest of your game. From todayâs gigabyte perspective it really boggles the mind how âtinyâ those machines were.
This makes it obvious that you canât just translate Godotâs node architecture to something like NES or Commodore 64, in any straightforward way. Itâd need completely different approach specifically tailored to the platform. But then the whole thing would defeat the purpose of using Godot in the first place.
There are quite a few âenginesâ out there now for game development on older consoles which are pretty good.
For example:
GB Studio - Gameboy
Scorpion Engine Megadrive / Amiga / NeoGeo
And more recently
Pyrite64 for N64 development
I suppose you could in the end have everything under one hood in Godot and have a fork of Godot for each system. That might work rather than having all these different engines, which lets face it pretty much do the same thing anyway.
A better approach might to be to have some sort of framework that uses Godot for the editor, and then âpluginâ the other engines framework , but thats a lot of work.
I am not sure if anyone here has heard of programming SNES games in C versus Assembly, but it barely changes anything, and only makes the stuff more readable.
Basically just a large GDscript plugin that has simple read/write operations and libraries, with different entrees for each supported platform,
the plugin could simply require a configuration for the console, and have docs so you can learn the library easier.
As for this, of course things like Resources and Control Nodes would basically be impossible, i am saying make a plugin WITH godot, it wouldnt use the editor generally, but could utilize the tilemap nodeâs data for sprite maps and tile data. within the plugin interface.
It wouldnt defeat the purpose of Godot if you use Godot to make it
You want to use Godot as a tile map editor for some 8 bit NES thing? Why? There are much more suitable editors that output data that can be used by an 8 bit system. Including editors that run on those actual systems. Whatâs gained from specifically using Godot for this?
I donât think you fully grasp the extents of the problem here.
Yeah, i know very much so that there is. Still, i am saying multiplatform, so NES, SNES, Atari, Genesis, etc.
Sure there is SuperFamicomv, and other platforms for bitmap editing, and for NES i do have gridpaper, nevertheless, using Godot for it would create a new branch of development with Godot.
Using godot with it would just be a cool idea is all, why copy Basic from a magazine into a terminal when theres an editer you already use?
Well making a tool that downscales and packs a tilemap to some 2-bits-per-pixel binary format is certainly doable and would make a neat weekend project. You should attempt it if youâre interested in this stuff.
However, expecting that itâd be possible to export a whole game made in Godot to some 8 bit platform as if you were exporting to Android or something - thatâs a completely different ball game. And it ainât happening.
You can make a game in Godot that looks exactly like a NES game but that doesnât mean the underlying principles are the same. Modern hardware does it in a totally different way that cannot be just âcompiledâ for a machine from 1980s. Even though the games may look identical, the modern version will use literally 100 times the computing resources of the original. And those cannot be simply âdownscaledâ like a bitmap.
The only way to do it is by writing an emulator, which, again, defeats the purpose of doing it in Godot, as you technically wouldnât do it in Godot, but in an emulator made in Godot. And thereâs no need for that since we already have plenty of good emulators for those retro machines.
You get that everything from music to artwork in old games were all coded by hand,
simply making a plugin that uses GDScript as a library for different assembly versions with custom functions is also doable, it would take a while, sure, but obviously i cannot take a PlayerBody2D and convert it to assemblyâthat would take up all the memory on a cartridge most likely.
Its the same exact concept as PVSneslib, which just uses C to code for the Super Nintendo,
its basically just applying it to GDScript is all. Really its not much different than a glorified cross-language library, which actually is exactly the idea, see.
And that is exactly what a simple library would solve, no need to even touch godot nodesâthe interface would be made with nodes and have itâs own interface of itâs own.
Its not like i am saying i could run my game on my poor SNES here, its impossible, but making an easier way to program assembly without messing too much with assemblyâthat is very possible.
Sadly with my current skillsets and interests, making a Super NES port would be the only way to do it, and i am sure there are many other talented individuals that are far more proficient with assembly of many kinds than me that could make a similar project or collaborate for this.
