Discussion about software development for the old-school Gameboys, ranging from the "Gray brick" to Gameboy Color
(Launched in 2008)
You are not logged in.
I created a new thread to update my games development.
Thanks to Zalo who updated the ZGB engine, I decided to continue developing two games I had abandoned. Now the source can be compiled with the last sdcc, that makes the program a bit faster and also makes the code smaller. The games work on both DMG and CGB, and use a slightly modified ZGB, to add a parallax effect for CGB, and the carillon music player.
So I'm working on a platformer (LUNA) and a puzzle game (FUZZYS WORLD).
LUNA: Will have 12 stages, for the moment it has menu, select level map, and 4 levels.
FUZZYS WORLD: Nothing new, for the moment only 2 levels.
Last edited by Mills (2019-04-10 10:55:18)
Offline
Awesome! Glad to see continuing progress on these titles!
Offline
Cool!
I remember seing the previous version of those game, it's cool that you are resuming working on them (especially LUNA!)
I really love the graphics style, be it the DMG version or the GBC version (beautiful palettes).
By-the-way, now that you use the latest SDCC, may I ask you how long your program takes to get compiled?
Because for my current project, I've made the switch from lcc to sdcc too, and the compile time increased a lot.
I don't use ZGB yet (it's a 32kb game), but I did follow Zalo wonderful guidelines and makefile to use sdcc with "vanilla" gbdk.
At first, with few lines of code, the program was compiled in a few seconds. But now that my code reached about 4000 lines, it takes SDCC more than 5-6 minutes to comile it!
Is it normal, or is there something wrong with my setup or my coding style?
All the game code is in a single .c file, and to get as many CPU cycles as possible I limited the use of functions, so my "main" is quite heavy (about 2500 lines)
Offline
drludos wrote:
Cool!
I remember seing the previous version of those game, it's cool that you are resuming working on them (especially LUNA!)
I really love the graphics style, be it the DMG version or the GBC version (beautiful palettes).
By-the-way, now that you use the latest SDCC, may I ask you how long your program takes to get compiled?
Because for my current project, I've made the switch from lcc to sdcc too, and the compile time increased a lot.
I don't use ZGB yet (it's a 32kb game), but I did follow Zalo wonderful guidelines and makefile to use sdcc with "vanilla" gbdk.
At first, with few lines of code, the program was compiled in a few seconds. But now that my code reached about 4000 lines, it takes SDCC more than 5-6 minutes to comile it!
Is it normal, or is there something wrong with my setup or my coding style?
All the game code is in a single .c file, and to get as many CPU cycles as possible I limited the use of functions, so my "main" is quite heavy (about 2500 lines)
Maybe yo used a big array like this:
unsigned char map[20*18] = {.....};
The sdcc compiler is also very slow on my PC if I use that, and also it will set the map to be stored in ram.
If you use const arrays the problem is solved, and you store them at ROM.
const unsigned char map[20*18] = {.....};
Offline
Thanks a lot for your help Mills!
I'm not using any large tilemap for now in my current project (the levels are built dynamically to stay within the tiny 32kb space!), but I'll look into my code with more details to see if I can find some parts that are responsible for the loooong compile time.
Maybe I should also try to split my code into smaller .c files so SDCC doesn't have to recompile everthing each time.
Anyway, I didn't want to derail this thread, so good luck with your two projects, and I'm eager to see the new demos you'll release!
Offline
drludos wrote:
Thanks a lot for your help Mills!
I'm not using any large tilemap for now in my current project (the levels are built dynamically to stay within the tiny 32kb space!), but I'll look into my code with more details to see if I can find some parts that are responsible for the loooong compile time.
Maybe I should also try to split my code into smaller .c files so SDCC doesn't have to recompile everthing each time.
Anyway, I didn't want to derail this thread, so good luck with your two projects, and I'm eager to see the new demos you'll release!
Today I discovered that "switch case" slows the compiler a lot. I hope the resulting code is smaller and more optimized.
Offline