Conversation Between Coolboyman and Danny-E 33
Showing Visitor Messages 1 to 8 of 8
January 13th, 2013 8:57 PMDanny-E 33Hey Coolboyman! I know it's been a while since we've last spoken. Rereading what I've asked you before, I think I sounded like quite the noob..
Well I'd like you to know I've become very fluent in ASM!
I would appreciate it if you wouldn't mind taking a look at what I've done with my knowledge with my Pokémon Red - Gen. II Graphics Patch!
I think its publicity would benefit greatly if it had the support of the greatest gen I and II pioneer!
I would like to personally thank you for being my inspiration. I don't think I've said it to you before, but my passion to learn all I can about rom hacking has come from you.
Believe it or not, I'm going to be graduating high school this spring and I'm very excited to go to college knowing exactly what I want to do. When I got my first TI Voyage 200 calculator and began programming on that 3 years ago, I knew that's what I wanted to do. And this experience of learning a real programming language to use my own creativity and put it into a game has only further reassured me that this is what I want to do with my life.
Now I need to learn Java and C!
So thank you for everything.
July 10th, 2012 3:56 PMDanny-E 33Hello Coolboyman! I want to thank you for taking a look at my thread at Skeetendo and giving me some much needed encouragement! So I will definitely not give up on this until I successfully write a new routine for loading the backsprites, but I don't think I can attempt this until I have a better understanding of what I'm doing.
So this new routine, that is replacing the routine at 0x3F103, should first load the bank of the backsprite into register a. But the bank is already in register a because RAM 0xD0D3 is the last byte of the current Pokemon's base stats and contains the byte of the sprite. And that was the last thing loaded into register a, right?
Then it needs to uncompress the image found by the pointer that is the 14th and 15th bytes of that Pokemon id's base stats by calling routine 0x24FD, and the uncompressed image is then stored at 0xA188.
Then the length of the uncompressed image (in bytes) needs to be loaded to register pair BC. And that number of bytes needs to be copied from the address in register HL (0xA188?) to the address in register pair DE (0x9310?) by calling routine 0x009D, right?
So I think I understand the gist of the process using words, but what would this look like in asm code? And are there any key details that I'm missing that are needed to make this possible?
Also, how do I determine the value to load to register pair BC when each sprite is a different size?
And how should I end the routine? (calling another routine perhaps?)
I would really really greatly appreciate your help with this problem. I'm so much closer than I was when I first messaged you. I feel like I'm so close. But I still need some more assistance until I'll be able to fully understand. Thank you so much for considering my request.
June 14th, 2012 11:35 AMDanny-E 33Hello Coolboyman!
I've made a ton of progress since we last talked, and I've solved most of my problems with putting GSC sprites into Red. I feel dumb for asking some of the questions that I did.. But I still have two problems. I know you're busy, but I could really use your help!
I ended up compressing the sprites with RBY compression, and frontsprites are all right about the same size and they all work great, which I'm very pleased with. But back sprites are originaly 4 tiles x 4 tiles, and GSC backsprites are 6x6. When I insert a new backsprite ontop of the old one, the image does not look like what it should even though the first byte of the image is 66 instead of 44 originally. I'm assuming this is because there is no byte describing the size in the Pokemon's base stats (starting at 383DE) because there is no need to state the size if every sprite is 4x4, unlike the frontsprite which has a byte (55, 66, 77) right before the pointer which matches the first byte of the sprite image data itself. Is there a way for the game to know it's decompressing a 6x6 sprite rather than a 4x4 sprite? There obviously is a way, since you have 6x6 backsprites in Brown, but I can't seem to figure this one out on my own...
My other issue is one I mentioned before. Since I'm replacing every sprite, and they are compressed, the frontsprites take up about just as much space as they did originally. But since the backsprites were 4x4 images and now they're 6x6 images they take up alot more room. Once I replace enough of the sprites of a certain bank, and the data has been shifted down, I'm sure I will run out of room for the 50+ sprites per bank because of the extra needed room for the backsprites. So my problem is that once I move a sprite to a new bank, there is no byte in the base stats immediately by the pointers to the sprites to determine which bank the sprites are in. I have a very good understanding of pointers now, but I am unsure how to modify which bank is loaded to $4000-$7FFF of RAM memory to fit the new sprites location.
*EDIT: Alright, this second problem has been cleared up, but I would still like your advice with my first problem on how to stop the game from zooming the 3.5x3.5 used tiles of a 4x4 tile image and displaying it as a 7x7 tile image so that unzoomed 6x6 images will display appropriately. Thanks for reading(: *
I would love your help right now, as there is no one with a better understanding of RBY and GSC sprites than you, or any subject of rom hacking for that matter. I appreciate all the help you have to offer!
May 17th, 2012 6:34 AMDanny-E 33Coolboyman,
Thank you for your response! I already increased the ROM size to 2MB a long time ago, so that's taken care of. So, knowing you did option 3 leaves me with a couple questions, if you don't mind.
Once I locate the front or back sprite of a Pokemon in Gold -which I trust that I won't have too hard of a time doing that on my own- the code I see is the image compressed using GSC compression. I don't know if this is a stupid question, but how am I supposed to obtain the code of the image in its uncompressed form?
Also, once I have the uncompressed code of the image and I've inserted it into blank space and I've changed the pointers from the 12th-15th byte of the Pokemon's data, I'm confused as to how the game knows which bank to go to. To my understanding, 2 byte pointers are used for offsets that are in the same bank, and if the offset is in a different bank, then a 3 byte pointer has to be used. But the Pokemon image data is spread across several different banks, right? So how does each pointer work correctly if a bank is not specified in the pointers to the images to begin with? And how would I modify it to make sure it points to a new bank if I only have the 2 byte pointers to work with?
Lastly, if I have the uncompressed data inserted and the pointers are repointed correctly, is there anything I have to change about the decompression routine, or will it recognize that it is an uncompressed image and read it directly on its own without me doing anything to it? I know I have a lot of questions, and it took me a long time to fully explain them, but I would greatly appreciate all the advice you have. Thank you!
May 15th, 2012 8:24 PMCoolboymanThat's cool you made some progress!
I did three for Brown which also enabled the game to load the images faster. I increased the ROM size to 2MB so it could hold all the new images. If you want to use the RBY compression that's fine then, it's up to you.
May 3rd, 2012 3:38 PMDanny-E 33Hello again Coolboyman,
I've made alot of progress with rom hacking since I last spoke to you, but I still have plenty of questions, if you are willing to take the time to read this. For the purpose of the hack im making of Pokemon Red, I want to replace every front and back sprite with sprites from a mix of Gold/Silver/Crystal spites. From what I've learned since I last talked to you, the compression in GSC is different than RBY. So my question is: What is the best way you suggest to simply replace every red sprite (front and back) with GSC sprites?
1) Should the GSC sprites be located in the GSC rom and then decompressed from the GSC type of compression and then recompressed with the RBY type of compression and then be inserted in the red rom so that the RBY decompression routine can accurately read the image?
2) Or should the RBY decompression routine be modified so that it decompresses the same way as GSC so that all sprites can be inserted as they are compressed in the GSC roms?
3) Or do you think the best way is to remove/bypass the decompression routine and insert all GSC spites in blank space (in a rom with double the size for plenty of room) as uncompressed images?
I'm not sure which of these solutions is most logical and perhaps you have an even better idea. I would like your opinion on what to do and I would appreciate all the advice you are willing to provide on whatever you think is best, because whatever you suggest, I'm sure I wouln't know how to do it entirely on my own, or where to learn. It's so hard to find new sources of information because 1st generation hackers are hard to come by now. I'm so glad you're still around and I hope you can help me with my hack and help me learn as much as I can. I have one year left in high school and then I'm off to college for computer science. Learning all I can about programing is my passion, and I hope you would like to help me gain all the knowledge I can.
January 12th, 2012 2:58 PMCoolboymanHello.
In order to do that, you'll need to learn the assembly language that gameboy uses. Here is a link to help you get started:
Once you can learn that, you can do sprite decompression and several other things with Pokemon and any gameboy game.
January 4th, 2012 9:06 PMDanny-E 33Hello Coolboyman,
Im very new to the PokeCommunity, but not so new to rom hacking, although im no expert! I only have a few questions about the sprite decompression routine to do similar to what was done for Pokemon Brown. Ive read in a few different places that the best way to use nicer gold/silver sprites in red/blue for front and backsprites, would be to remove the sprite decompression routine and place the new sprites in blank space of the rom and have the sprites repointed to the new offset of the uncompressed sprite. But what/where is the sprite decompression routine exactly? And how can it be removed or ignored? Also, how exactly is an uncompressed sprite added to blank space? And how are the pointers changed to point to the new sprites? I understand hex editing fairly well, so i dont need any beginner things, which im sure you dont want to waste your time with, but i have only founded a few places talking about the sprite decompression routine and nothing talks about it in depth enough for me to understand what to do. Any sort of advice to help me understand would be soo appreciated! Thank you for taking the time to read this!
All times are UTC -8. The time now is 12:35 PM.