Re: [Hack Tool] Denjuu Editor SP

Discuss anything related to hacking ROMs of the Telefang games here.
swampert22(imported)
Posts: 54
Joined: Sun Dec 23, 2007 4:04 am

Re: [Hack Tool] Denjuu Editor SP

Post by swampert22(imported) »

Blaziken257 wrote: Does it make the file size large even if you just rip the images from the ROM? They're uncompressed, you know.
No, it wouldn't but as I had already discussed earlier in the thread, I do not know how to read images from a ROM in VB. Its very complicated. :(

As for the update for palette editing, its pretty damn good. I'm just adding in the save function for it, then I'm done! :lol: I think you'll like it. Its very easy to edit the colours.
swampert22(imported)
Posts: 54
Joined: Sun Dec 23, 2007 4:04 am

Re: [Hack Tool] Denjuu Editor SP

Post by swampert22(imported) »

Right, I have finished the update and you can now download it! I do work fast don't I? ;)

Here is a modified in game screenshot that I changed using Denjuu Editor SP:

Image

Proof! It works! :D

There is also a colour chooser and you can simply hit copy after selecting which of the four colours you want to overwrite! It's really simple to use, and effective! B)

The best way for you to see, is to download it, so what are you waiting for? Go!
Blaziken257
Posts: 984
Joined: Fri Dec 22, 2006 11:52 am

Re: [Hack Tool] Denjuu Editor SP

Post by Blaziken257 »

Very nice! Now it's a lot easier (and faster) to edit colors. I tried it out and it worked nicely... I made Crypto look a little better than the annoying orange color that was there before.

Just a few things that I need to mention, though:

- The color picker does not currently load Denjuu colors at all. I think that if you open the color picker, pick a new color in the color picker, or pick a new Denjuu, it should load the color of the Denjuu that you currently have selected. This would make it useful if you want to make slight tweaks to a Denjuu's color (especially when some Denjuu are oddly colored in this game, like the aforementioned Crypto).

- The text box for the first color on the main window is slightly larger than the other text boxes. Here's a closeup to see it easier:

Image

- The text box for the red value is misaligned when compared with the green and blue text boxes -- it's a little lower than it should be. Here's another closeup:

Image

- This one is minor, but if you input a hex value where the third nibble is 8 or higher (for example, FFFF), the color below it will incorrectly show up as black. If you save this value, the game (or any other game for that matter) will subtract 8 from this value, which will become FF7F (which is pure white). This is because the first bit in the second byte is always ignored. So, the editor should display the color like the game does (in this case, white).

As a side note, I noticed it's only possible to input a number or a letter A-F. That was a smart move :)

Sorry if I sound like I'm pushing you too hard here. That's not my intention...
User avatar
andwhyisit
Site Admin
Posts: 1199
Joined: Fri Dec 14, 2007 9:24 pm

Re: [Hack Tool] Denjuu Editor SP

Post by andwhyisit »

swampert22 wrote:
Blaziken257 wrote: Does it make the file size large even if you just rip the images from the ROM? They're uncompressed, you know.
No, it wouldn't but as I had already discussed earlier in the thread, I do not know how to read images from a ROM in VB. Its very complicated. :(
Well at 4 colours (2-bit) per pixel, uncompressed, and no palette information that would leave you with 4 pixels per byte and a total of 16 bytes per 8x8 tile. This is in theory though, I haven't tested this yet, but I would seriously doubt that it would be structured differently. Or is drawing it to the screen the hard part?

From Data Crystal:
1AC000-1AFEFF (03F00) = Denjuu #1-18
1B0000-1B3EFF (03F00) = Denjuu #19-36
1B4000-1B7EFF (03F00) = Denjuu #37-54
1B8000-1BBEFF (03F00) = Denjuu #55-72
1BC000-1BFEFF (03F00) = Denjuu #73-90
1C0000-1C3EFF (03F00) = Denjuu #91-108
1C4000-1C7EFF (03F00) = Denjuu #109-126
1C8000-1CBEFF (03F00) = Denjuu #127-144
1CC000-1CFEFF (03F00) = Denjuu #145-162
1D0000-1D29FF (03A00) = Denjuu #163-174
Milnivri(imported)
Posts: 351
Joined: Wed Dec 27, 2006 10:14 pm

Re: [Hack Tool] Denjuu Editor SP

Post by Milnivri(imported) »

andwhyisit wrote: Well at 4 colours (2-bit) per pixel, uncompressed, and no palette information that would leave you with 4 pixels per byte and a total of 16 bytes per 8x8 tile. This is in theory though, I haven't tested this yet, but I would seriously doubt that it would be structured differently. Or is drawing it to the screen the hard part?
I guess it is the drawing to the screen. I dunno how those tools manage to do it.. (like unLZ or AdvanceMap [the reading of the tilesets])

EDIT: Whoops, got gbSP mixed up with unLZ (probably the unique capitalisation XD)
swampert22(imported)
Posts: 54
Joined: Sun Dec 23, 2007 4:04 am

Re: [Hack Tool] Denjuu Editor SP

Post by swampert22(imported) »

Right, I have yet again, finished an update! :D

@Blaziken257 - I have fixed everything you suggested, except the fact that the 3rd nibble displays incorrectly. It's not really that big a problem, I think. The main think is that you can no load the colours that are in the pallete into the colour picker and slightly edit them, and copy them back. It works well B)

Image

I have added the update to the main post. Try it out!

@ andwhyisit - It is the drawing to the screen that is hard, but when the images are uncompressed in TLP, why not just edit them in there? It's easy enough!

@Milnivri - I'll tell you how those tools work: they're made by programmers that are a damn sight better than me! :lol:
Blaziken257
Posts: 984
Joined: Fri Dec 22, 2006 11:52 am

Re: [Hack Tool] Denjuu Editor SP

Post by Blaziken257 »

Nice! Now the text boxes look far neater :)

Also, I'd like to mention this. Yesterday, I spent about 2-3 hours trying to find the data for mod (reform) evolutions, but I was unable to find it! Here is how I attempted to find it:

I made a save state right near one of the marts (I picked one of the ones in Freesia, but any mart where you can do mod evolution will work). In this save state, I had an R-Gun (I think the real version calls it a bazooka), and I had Cryptoride, which evolves with it (though anything that mod evolves would have worked, if you have the appropriate item). Then, I ran Corrupt, a program that corrupts ROMs. I kept corrupting the ROM, ran the corrupted ROM, kept loading the save state I created, and kept using an R-Gun on Cryptoride to see if there was anything different. After 2-3 hours, I couldn't find anything different with it, so I wasted my time.

Though, the corruptor has helped me a LOT in the past with different things, including the base stats and movesets. For example, when I corrupted the ROM and found that the Denjuu had weird movesets and stats, I knew I found the right place. :)

Although, when I corrupted bytes in the $02E5C5-$02E651 range, it caused the game to freeze when I tried to give Cryptoride an R-Gun, so this had some kind of response. Even when I would corrupt one byte in this range, it would usually make the game freeze (sometimes it would freeze when it loaded the screen where you pick the item, sometimes it would freeze when I gave Cryptoride the R-Gun, and this would depend on which bytes I would corrupt). However, I could not find any pattern in here, so it looks more like assembly code than mod evolution data. I cannot read assembly code, though, so this doesn't really help me at all...
User avatar
andwhyisit
Site Admin
Posts: 1199
Joined: Fri Dec 14, 2007 9:24 pm

Re: [Hack Tool] Denjuu Editor SP

Post by andwhyisit »

swampert22 wrote: @ andwhyisit - It is the drawing to the screen that is hard, but when the images are uncompressed in TLP, why not just edit them in there? It's easy enough!
The idea isn't to edit them, but to show palette changes on the denjuu itself.

Isn't it possible to just structure the tile and palette information into 2-bit bmp format and then try to find a way to change the palette on-the-fly without redrawing the image?

Or maybe:
- Load palettes.
- Add palette information to boxes.
- Assign an id (0-3) for each palette entry.
- Draw the individual pixels to the screen.
- You will need a way to reference these pixels by number without adding an extra byte of information.
- Create an array of base-4 (hopefully) numbers from the tile information and order to fit the order of pixels.
- Assign the colours (from the palettes) to the pixels using the array.
- Reassign colours upon change to the palette boxes.
- Change array and palette upon changing denjuu.

This is theoretical since I have never used Visual Basic, but I am pretty sure this would work. No idea about how much memory or speed it requires though.
Kid Sonic(imported)
Posts: 304
Joined: Mon Dec 24, 2007 2:31 am

Re: [Hack Tool] Denjuu Editor SP

Post by Kid Sonic(imported) »

I still think it possible to hack some more features. Just not to any of our ability.
Blaziken257
Posts: 984
Joined: Fri Dec 22, 2006 11:52 am

Re: [Hack Tool] Denjuu Editor SP

Post by Blaziken257 »

If this helps anything at all... here is how the Game Boy and Game Boy Color (but not Game Boy Advance, since it can hold more colors to a tile) stores tiles. Uncompressed tiles use two bytes for each horizontal line. And there are two bits to each pixel. What a Game Boy (Color) game does is read one bit from the first byte and then the corresponding bit for the second byte. For example, for the first pixel on a given line, the game would read the first bit in the first byte and then the first bit in the second byte. Then it would read the bits after that to determine the pixels in the rest of the line.

Then, the format is like this:

If the bit for the first byte is 0 and the bit for the second byte is 0, then the pixel uses color #1.
If the bit for the first byte is 1 and the bit for the second byte is 0, then the pixel uses color #2.
If the bit for the first byte is 0 and the bit for the second byte is 1, then the pixel uses color #3.
If the bit for the first byte is 1 and the bit for the second byte is 1, then the pixel uses color #4.

The brightness of the colors tend to vary from game to game. In Telefang, color #1 is generally the brightest color, color #2 is the second brightest, color #3 is the second darkest, and color #4 is the darkest. I think some other games are like this too.

This gets confusing, so here's one example. For this whole example, we'll assume that color #1 is the brightest, and color #4 is the darkest, like Telefang.

Let's say the bytes are like this:

01010101
00110011

Now, to determine the first pixel, you would look at the first bit in the first byte (in this case, it's a 0), then look at the first bit in the second byte (also a 0). Since both of these are 0, then the first pixel in this row is color #1. If it's like Telefang, then it would be the brightest color.

For the second pixel, you would look at the second bit in the first byte (this time, it's a 1), then the second bit in the second byte (a 0). Since it's 1, then 0, then the pixel is color #2 (for simplicity's sake, the second brightest color).

Now for the third pixel. Look at the third bits in the first and second bytes. This is a 0, then a 1. This will make this pixel color #3, the second darkest color.

And the fourth pixel. Do the same thing, with the fourth bits in each one. It's a 1, then a 1. This pixel is -- you guessed it -- color #4, the darkest one.

I think you get the point by now. When the game tries to read these bytes as a row of a tile, it will will show up something like this in the game (I enlarged the pixels so that you can see them more easily):

Image
Post Reply