Godot Fantasy Console

This devlog, I pretty much just tried to fix the stop bug as well as try to figure out why the inputs were not working for the really, really basic moving forward demo that I created. At the beginning of the project, I used bitmaps on the input byte, so I couldn’t use the original IF statement that I wrote as an instruction for the assembly language. So I switched to just setting the input_byte to a specific int.(This took me WAY too long to figure out that this was the cause). There were also lots of other bugs that had to do with the assembly language that I will not cover right now.(Caused me too much frustration atp.) I did all of this in 1 day, so as you can probably tell, I am very tired. Other than that, I also worked on generally trying to polish the project up a little. I updated the cartridge ui alittle. When you are loading from a cartridge you now can actually edit the assembly file without it putting abunch of STOP instructions down. This unfortunately still happens when you are making a fresh assembly file though. The video is a demo on how to open a cartridge and the image is the moving up cartridge also found in the demo folder of the repo.

In this devlog, I worked on fixing the color shifting. It turns out I was still adding a footer to the end of the cartridge, so when I went back to load it again, the RAM was shifted by 4 bytes. I also worked on creating a decompiler so that when you load a cartridge, you can edit the sprites and the assembly file associated with the cartridge.(Unfortunately, there is a massive string of stops that shows up if you load it in. This is because the “blank” RAM value is the same as the stop. As shown in the second image.) Next, I will be trying to make it so that certain instructions adjust automatically if you input a register versus a static value or an address in the RAM. I also added some more color to the sprite editor(First image).

In this devlog, I refined the cartridge system further. The cartridges now come out in random colors when you save them. However, the color palette gets shifted once you load a cartridge, so that is an error that I must fix soon. The second image that is being devlogged is what the cartridge should have loaded. The third image is what was loaded instead. I think it is the way that I am packing the Globals.ram into the png is causing this.

This devlog, I worked on making the cartridge system and trying to make this into more of a playable product/demo rather than a basic experiment, pretty much. Right now, the cartridge system works by appending the packed byte array (RAM) to the end of a .png file. Right now, the .png is just a red square. I also plan on switching away from using files to load sprites and instead either using RAM directly or using a seperate packedbytearray to store the sprite data. I really feel like this will help clear some clutter, as well as make it easier for me to load/unload data using the current cartridge system. The image is the PNG that the current cartridge is based on. There is not a lot to show for it right now, though.

I mostly worked on trying to fix a weird bug where I could not draw sprites using the SPR instruction. This was solved because I chose the wrong start point to start reading the instructions from. I also worked on adding the undo and redo features to the sprite editor. Next, I will work on adding something so that when you input the sprite index, the hardware.gd script will automatically load it.

Ok, this is going to be a long one:
The main thing that I worked on in these 6 hours was getting a custom assembly language “working.” So far, there are 9 main instructions to manipulate the registers(R0-R7)/Ram and to do things like stop the program altogether. One of these instructions also allows you to draw a sprite directly(I like the looks of this one!). Next for this is to get a working editor. At some point, I would like to add an option to use an adapted version of GDScript so that the user does not have to use assembly.

Along with this, I also did some work on the sprite editor. It can now export the sprite to a specific file in user://, depending on a pop-up that appears after saving the sprite. Next, for the sprite editor, I will add loading back sprites into the editor. I also want to add more features to the sprite editor itself, such as undo, redo, and a fill tool.

Just as an explanation of all the images: The first image with the two colorful cubes is some random sprites that I created using the sprite editor after creating the file-saving feature. The second image is the new ui for the sprite editor(I know not much has changed). The last image is of the beginning of the code editor.

I hope that all makes sense. Thank you for bearing with this long devlog :)

I worked on the sprite editor and further refined the palette.
Todo: Add a way to export the sprite from the editor to the actual console.

I added some basic rendering capabilities. I also worked on adding all the memory and getting that set up. The image is a test of the rendering.