I had the repo setup wrong. It should allow forking now.Sorry, I got confused by Gitlab!
I use it all the time at work and by default "Code" is before "Plan" (in french it's much more different), making me think it wasn't there!
An IDE would be great, even an enhanced editor able to launch tools would be amazing!
Another way would be to have something like Pico-8 or TIC-80 environments: text editor, sprites/tiles drawing and organizing tool and an music editor, too.
PS: protected branches like master are not usable for project forks, I just cloned it for now.
Since you can see the code now, I've tried to make the build into modules and not a monolithic build. Should make it easier to work on each part of the project.
I have a PT52 Sound Repo I haven't integrated the sound into the test build yet I still up in the air as to how that should work.
There are two more programs that I haven't brought into the project yet. The original project was a serial terminal and that code is actual still compatible for the most part and there is also the Hex viewer that code isn't as useful since we can replicate it with Lua. The only functions missing are the reading flash.
I've tried to work up some tools to help development but they are not exactly the best. I use this maze game to test everything and when I need something I first try it with lua and when it works and I can hey that would be better if it was in a library I add it. So right now you can open PPM files and use them a tiles the issue are
1. PPM files are in RGB888 format and the PT52 is not so it has to convert on the fly.
2. PPM support is only working for tiles or full screen images.
3. The easiest image library I've found and know how to use needs a code from a pull that hasn't been merged into the SDK yet and it's been around for a while
The idea was to make it so you could open different format images and then convert them to a bin format the PT52 can use without converting. I've done this with images for the title screen of my game. I used Lua to open and paint the image to the framebuffer then I use the VRAM function to copy the frame buffer to disk. now when the game starts it just loads that bin file back to the frame buffer and it takes no time at all or processing overhead. So it makes sense. Tiles were tricky because RAM is limited I decided to you a file and just calculate the tiles from the file then draw them from file to screen. This again is slower than ram copies but the image is still in RGB888 format and needs to be converted. But it saves memory and being slow is acceptable.
Really this project just keeps evolving the first foundations were laid more than 3 years ago and I had text only interface, now there are graphics,a programming language that works and it can do so much.
Statistics: Posted by DarkElvenAngel — Sun Mar 02, 2025 2:56 pm