this is a description of a program I would like to write (get help writing) for the suse linux OS, I could use some help getting started…
the program will be a video game emulator/ sprite editor/translator (I know it’s sounds like a lot but it’s not) focused on the GB (gameboy), GBC (gameboy color), GBA (gameboy advanced) formats.
the goal; unlike other sprite editors, tile editors ETC. this utility aims to work natively on a linux OS, and support writing to the actual .gb, .gbc, .gba files without the need of attaching a patch. also other sprite editing utilities I’ve run across have listed the GBC and GBA formats with incorrect color depths (I plan to make a utility that fixes this);
EX (the following color depths are from the windows program YY-CHR):
GB:4 colors (correct)
GBC:4colors (incorrect, correct= 8 colors)
GBA:16colors (incorrect, correct= 32 colors)
functionality; most sprite editors attempt a form of pixel editing in themselves, my program aims to instead to do the following;
load GBX games into emulator mode and extract the game’s sprite-sheet, whereby as different sprites are encountered in game-play (character(s) foreground, background, scenery, enemies, bosses and unkown); a sprite location log is written detailing the locations of the individual sprites on said sprite sheet (this log is used to A; extract the sprites individually (line by line) to a .png for external editing in programs such as the GIMP. B; write the edited sprites back into place from the .png replacing the old color values with the new ones.) it will automatically adjust the game’s saved format for the amount of different colors you used. for example you might start with a “.GB” file and color it (as they are in gray-scale) and end up with 32 different colors, so when saving it will automatically export it to a “.GBA”.
naturally there some limitations to this; for example:
1: you can’t use more than 32 different colors on the .png file other wise it wont be accepted.
2: you can’t enlarge the sprites or draw outside the bounds of each sprite, otherwise they will overlap on the game’s sprite-sheet (causing either the game to be confused or give a strange appearance)EX: if the sprite sheet is exported to a 300X300 image you cannot lengthen it in any direction.
3: emulator modes that smooth the pixels such as “super eagle” mode (as it’s named in most emulators) will not be able to be used during sprite extraction (for the sole reason that it could confuse the log reading script when you go back and try to re-save the new sprites to the game)
4: changing the name or location of the .png will cause the log reading script to “draw a blank”.
5: adding “extra” sprites will be impossible without confusing the log file for the time being.
so where do I begin?