linux native GB GBX sprite editor project

[joshex]

I already posted this on some linux forums, but havn't gotten any responses yet.

my introduction; hello I'm joshex an allround artist, I do everything from pixel shading to 3D modelling. I also do a bit a programming (a small bit)

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 how do I start this process?

[Lillymon]

This sounds like a Rom Hack topic to me. Also, if this is going to be designed for Linux, will it be open source too?

[InVerse]

Maybe I'm missing something here, but I don't get it.

It sounds like you're intending to extract the sprites from RAM but reinsert them to ROM. I could be wrong, but that would pretty much require specific information for each individual game you wish to be editable, which would defeat the purpose of the logging format you describe.

Also, you do realize that the colors of a particular graphic aren't actually stored within each graphic, right? In order to change the colors of a graphic, you either have to stick to the colors already contained in the particular palette assigned to said graphic or else modify the palette itself, which will also modify the colors of all other graphics assigned to that palette.

I really don't see the benefit of the method you describe over simply using Tile Molester. Tile Molester is written in Java and runs fine in Linux without the need for WINE or the like and it writes directly to the ROM. I'm really not sure what you mean by "without the need of attaching a patch". I've never encountered a graphics editor that created patches instead of directly editing the ROM. As for the color depths, I don't know enough about that to comment on it, but as Tile Molester's "codecs" are user editable, if they are wrong, you could easily correct them by editing the config file.

Again, maybe I'm misunderstanding something. If so, please correct me, but again, I don't see the point in what you're trying to do.

[joshex]

Maybe I'm missing something here, but I don't get it.

It sounds like you're intending to extract the sprites from RAM but reinsert them to ROM. I could be wrong, but that would pretty much require specific information for each individual game you wish to be editable, which would defeat the purpose of the logging format you describe.

Also, you do realize that the colors of a particular graphic aren't actually stored within each graphic, right? In order to change the colors of a graphic, you either have to stick to the colors already contained in the particular palette assigned to said graphic or else modify the palette itself, which will also modify the colors of all other graphics assigned to that palette.

I really don't see the benefit of the method you describe over simply using Tile Molester. Tile Molester is written in Java and runs fine in Linux without the need for WINE or the like and it writes directly to the ROM. I'm really not sure what you mean by "without the need of attaching a patch". I've never encountered a graphics editor that created patches instead of directly editing the ROM. As for the color depths, I don't know enough about that to comment on it, but as Tile Molester's "codecs" are user editable, if they are wrong, you could easily correct them by editing the config file.

Again, maybe I'm misunderstanding something. If so, please correct me, but again, I don't see the point in what you're trying to do.

ow, sorry I've been off for a while, I got the flu and have been bedridden.. my back is hurting quite alot so I'll make this breif;

tried tilemolester but for some reason it won't run. (I get a picture that pops up saying tile molester with some characters on it, but then after it goes away nothing happens.

I would be looking at making this editor completely opensource.

I got the Idea a patch was needed in most tile editors because after editing a GB into a GBA in yychr I got an error in my emulator's shell saying "Unsupported BIOS function e0 called from 08000088. A BIOS file is needed in order to get correct behaviour."

anyways,

It sounds like you're intending to extract the sprites from RAM but reinsert them to ROM. I could be wrong, but that would pretty much require specific information for each individual game you wish to be editable, which would defeat the purpose of the logging format you describe.

yes specific information that is obtained in emulaor mode as the rom is running by ..oh say a trojan. (a program that monitors exactly what and how the RAM and/or ROM is being read then outputs that info to the log file.

Also, you do realize that the colors of a particular graphic aren't actually stored within each graphic, right? In order to change the colors of a graphic, you either have to stick to the colors already contained in the particular palette assigned to said graphic or else modify the palette itself, which will also modify the colors of all other graphics assigned to that palette.

the palette will be edited by a script automatically upon submission of your .png back into rom (less hassle by the user)

EX: you start off with a grayscale file from a GB game that has been exported as .png, you take it into an external editor and use for example a total of 23 different colors as you please to color the sprites, you then submitt it to the editor with the rom opened whereby a script will log the colors you used as the new palette (along with in that case 9 blank opaque colors to fill up to 32) then it inserts the edited sprites and the new palette over the old.

the main goal of this is to supply the absolute BEST editing utility by allowing the actual graphic editing to be done in a professional picture editor like the GIMP. thus allowing people to choose colors and place colors on the sprites pixel by pixel if need be.. as well as make partially transparent colors EX: erasing a certain pixel on the sprites at 50% opacity, this would also allow changing sprites (so long as they are in the same bounds or less) EX; you could replace a character with a pixelated skeleton fitting thier form as the "impact/hit/damaged" sprite set. making it look like they got shocked by electricity

but yes I must get offline, still not feeling well

[joshex]

hmm, the edit post option is refusing to save the edits...

edit to previous post: real quick, I'd like to state just how I know what each GB systems colors are, I litterally took screenshots of games in an emulator (multiple for each game every time I saw a new or what I thought was a new color) and checked the colors on said screens in the gimp, GB games no matter what colors they are there are always the same 4 colors. GBC games use 8 colors (after studying LOZ link's awakening's color rom) and GBA uses 32 different colors (after studying Fire Emblem GBA)

some games don't use the full color potential of the format though.

[InVerse]

I got the Idea a patch was needed in most tile editors because after editing a GB into a GBA in yychr I got an error in my emulator's shell saying "Unsupported BIOS function e0 called from 08000088. A BIOS file is needed in order to get correct behaviour."


How can you possibly "edit" a GB ROM into a GBA ROM using a tile editor? The Gameboy (Color) uses a custom z80 processor, whereas the Gameboy Advance uses an ARM7 processor. In order to convert a Gameboy game into a Gameboy Advance game, you'd basically have to rewrite the entire thing...

[joshex]

How can you possibly "edit" a GB ROM into a GBA ROM using a tile editor? The Gameboy (Color) uses a custom z80 processor, whereas the Gameboy Advance uses an ARM7 processor. In order to convert a Gameboy game into a Gameboy Advance game, you'd basically have to rewrite the entire thing...

ah yes, well that would explain why it wasn't working and why it was requesting special bios..

but yeah then that would be a definite point of this Idea for a graphic editor, the first one to be able to convert lower quality .GB's and .GBC's into .GBA's. (EX;as previously stated a GB game's sprites could be colored with 32 colors, this editor would then have to be programmed to automatically convert the file to .gba format using the full 32 color depths before saving..)

so it's more over a sprite exporter/rewriter + GBX game format conversion program.

so any Ideas on what programs I could use to write this thing, and or what scripts are needed to access and or write to GB, GBC, GBA formats?

[InVerse]

As I said, you can't simply convert a GB/GBC game into a GBA game. You would have to disassemble the game and rewrite it for an ARM7 processor. This wouldn't be an automated process, you'd have to do it manually, and you'd have to do each game individually. In other words, it would probably take you a few hundred years to accomplish what you're trying to do.

[joshex]

well if you go the long and hard way, yeah it'll take 100's of years.

theres a quick and effective way to do everything, especially in programing.

in this case all I'd need access to is the specific way each format is coded, from where a script could be written to translate. when it comes to programs all that counts is how they are written.

processors are harware, and no doubt GB games have been emulated on tons of different processors.. maybe I'm misunderstanding your usage of the word "processor"?

all the program would have to do in order to automate the process is this;
have access to all the commands and programming statements from each language
have an intermediary script that equates these commands/statements, and/ or makes neccesary changes to the math.

from where the game could be dissasembled by it's particular script, assinged to the new script and translated.

it's all in the coding, and how you look at it, I'm willing to bet the file formats are only a hair different anyways..

[InVerse]

If you can find a quick and effective way to automatically convert GB games to GBA games, I'm willing to guarantee you'll be a multi-millionaire within two weeks time. Have you *ever* seen a GB game converted to a GBA game? No, and I guarantee you that it's not because nobody else has ever thought of the idea. And it's not because the people who have thought of the idea weren't good programmers. The fact of the matter is that what you're proposing is completely unfeasible. If it were even remotely simple to accomplish such a conversion with even a *single* game, you'd have seen it done. Translating assembly code from one processor to another isn't like translating Japanese text into English. It would be more akin to translating the thoughts of an autistic Canadian child into language that a Burmese python could understand.

[The 9th Sage]

It would be more akin to translating the thoughts of an autistic Canadian child into language that a Burmese python could understand.

Not to break into the conversation here, but this is one of the best comparisons of anything to anything I have ever seen.

[joshex]

LOL! extra lol, thats the kind of comment kryten would make on red dwarf!

but anyways I see your burmese python and I raise you a bablefish;

show me how to decompile all three formats and I'll see what I can/can't do in translating them..

I mean so long as I have them in a source format that I can easily edit in kate or kwrite I'm good..

[InVerse]

Here is a GB/GBC disassembler (http://www.tablix.org/~avian/blog/articles/z80dasm/) written for Linux. Both the GB and GBC use a z80, it's just that the GBC's z80 was approximately twice as fast as the original GB's and was able to access more ROM and RAM.

Here is a page with GBA disassemblers (http://www.postbox.javamaster.co.uk/downloads.html), including one for Linux and also one written in Java.

Have at it. If you prove me wrong, I'll provide a YouTube video of myself eating my underwear.

[Lillymon]

Have at it. If you prove me wrong, I'll provide a YouTube video of myself eating my underwear.
I've already seen someone doing this. It originated on the GameFAQs Politics board, after (IIRC) one poster promised to 'eat his boxers' if John McCain lost the US Presidential election. After weeks of bugging, he finally posted a YouTube video of him squeezing some mayonnaise on his boxer shorts and gave them a few good chews. The board populace agreed that was close enough.

[InVerse]

I've already seen someone doing this. It originated on the GameFAQs Politics board, after (IIRC) one poster promised to 'eat his boxers' if John McCain lost the US Presidential election. After weeks of bugging, he finally posted a YouTube video of him squeezing some mayonnaise on his boxer shorts and gave them a few good chews. The board populace agreed that was close enough.

I think it appeared on South Park prior to the election (and I'm sure the bet was made many years prior to that.) However, I will actually cut mine into swallowable pieces and ingest the entire thing.

And the idea of a GameFAQs politics board actually does more to turn my stomach than the thought of eating my own underwear...

[joshex]

fair enough, now lets see if the GB discompiler written for debian will run on suse without hassle in itself..

oh and i don't plan to hold you to eating your underwear if I should be able to do this..

[Sliver-X]

Oh, I'd love to see you do what 60 years of computer scientists and engineers could never accomplish.

The GB and the GBA are fundamentally different architectures. You may say "Yeah, they have different CPUs", but that's only the tip of the iceberg. You also have to take into account differences in peripheral hardware such as the video and sound hardware, how it polls I/O, interrupts, what kind of RAM/ROM address space it has and all kinds of fun things that make them extremely different at the hardware level.

I don't think you really have any concept of how a computer of any kind works at its lowest levels. Porting something between systems is hard enough if you have the source code (Unless you use something high level like C), but for what you're talking about doing you would be working with raw machine code. The code will be so disparate between the original and target platform that there's no way you can just automate conversion of it and expect to get anything close to running after it was done.

What you're basically talking about is creating a high level AI program than can figure out how to alter code like a person hand porting it would do. If you can do that, congratulations on being the next Bill Gates.

(Note: I have a degree in Electronics and Computer Engineering.)

[joshex]

mm, see what I wanted was not the machine code but the programming statments in each format, and yes if they are written for a different processor the information during gameplay is told to go to different places based on processor. (as you are saying, and I agree with that.)

what I'm getting at here is a simple "replace" script. where the information on things like; where certain information is togo undercertain circumstances in GB, the replace script would read those particular statments and merely replace info with GBA style info..

I don't yet know the style of GB or GBA statements so I can't give an adaquet example.

but no AI needed, no fancy programming just basic; IF "gbstatement" THE REPLACE WITH "=GBAstament".

it can all be broken into programming statments at the end of the day.. and thats what I'm looking for..

but alas I wont even be trying to run the decompiler for a while.. I'm quite sick still, and feel horrible today.. and right now my gums are all... whats the word, I feel like I want to chew on something my gums feel tingly and I can't get rid of it.. and my mouth is watering uncontrollably, and no I'm full.. oh this is torture...

[InVerse]

Those weren't decompilers that I linked you to, those were disassemblers. If you want the actual source code for ROMs, you'll have to contact the companies that programmed each game and hope that they actually kept the source code (many don't.) You're not going to be able to decompile a ROM into C++ or some such.

[joshex]

ok.. well then that does it, I can't do it.. I don't know machine code..

but don't emulators have to decompile the ROM's to read them?

if so all we need is a trojan to monitor a decent GBX emulator like visualboyadvanced, see how it reads the files, and dump that info, or the source :D

but I've never programed solo before, I edit scripts, I can only do something if most of the info is already there.. that way I only have to go searching for a couple commands instead of thousands..

[Reaper man]

not only you can't do it, but you don't know your terminology, at all. You don't use a "trojan" to monitor code in an emulator. You use a debugger :rolleyes:

[joshex]

oh my bad, oh well read what you said and remembered visualboyadvanced had a debugger, but it's not working... oh well.. so much for my Idea..

[InVerse]

No, an emulator doesn't "decompile" a ROM. An emulator emulates the processor for which the ROM is programmed.

[Gotgull]

aside from decompiling or well as they said debugging to reverse engineer GB and or GBA roms as none of them have a source file they are all closed source just like Microsoft Windows there is no public available source for any game for any one of those system not for gameboy nor gba. Everything we know about those systems has been hashed out through debugging.

Sure you could change a gameboy graphic over to a 32 color gba one and it'll look fine but you have to then copy The Graphic "not make the rom into gba format" into the existing gba game you want to use it in. then you could do the reverse and take a 32 color gba ghraphic over to a gameboy game but it'll look like crap cause there are only 4 colors. Plus GBA may use 32 colors in it's self but rgb computer graphic programs is 256 or more colors Gimp.. the pixels in gba for sprites use only 16 colors at one time not 32 you can make use of 32 colors onscreen but not at the graphic level, same for game boy color 4 colors at a time except onscreen the editing of graphics and what shows on screen are two different systems.

Edit I'm not sure if the gba use even 16 colors at one time it's probably only groups of 8 colors that you can use at a time up to 32 colors.

[InVerse]

You must really be bored if you're replying to posts that are nearly 2 1/2 years old. You should consider developing a hobby. I would recommend looking into papercrafts.