PDA

View Full Version : [Tutorial] 1st Gen Hacking: Useful Links


Sawakita
July 9th, 2011, 3:05 PM
1ST GEN HACKING: USEFUL LINKS

This is a list of links to documents and tools; it aims to help people solving the "hard" task of finding information about 1st gen hacking, which means Pokemon Red/Blue (and sometimes Yellow) versions. At the end of the post you'll also find some really useful documents about Game Boy hardware specifications.


PREMISE
Bits and Bytes[link (http://web.njit.edu/~walsh/powers/bits.vs.bytes.html)]
The link contains a fast explanation of bits and bytes, and binary/hexadecimal format conversions.

Hex Editing [link (http://www.romhacking.net/docs/40/)] [tool-list link (http://www.romhacking.net/?category=13&Platform=&game=&author=&os=&level=&perpage=50&page=utilities&utilsearch=Go&title=&desc=)]
I know all the misconceptions that exist around hex editing, but you've got to understand that getting used to it is really easy (after all, you learned decimal numbers when you were, like, 5-6 years old). I can't think of linking any page about learning hex editing. Ok, try THIS (http://www.romhacking.net/docs/40/), if you really can't handle a simply different way of counting numbers. If it helps you, you can think of a hex editor as if it's a book, but instead of reading words, formed by letters, you find organized data (and code, of course), formed by numbers. The hard thing could be figuring out what the formats of the various data structures are, but many of them (and the most important ones), are documented and explained, so, it's not that bad really.

Game Boy Pointers [link (http://www.pokecommunity.com/showpost.php?p=3846940&imz_)]
A very clear explanation of GB pointers, since they can be hard to understand for some people.


GENERAL DATA LOCATION
Red ROM Map [link (http://datacrystal.romhacking.net/wiki/Pokemon_Red/Blue:ROM_map)]
This document helps you orientate in the ROM, listing where many things are located (be it graphics, texts or other data-tables). Certainly a doc to keep an eye on, during your hacking sessions.
Notice that it's for Red version, although Blue offsets are almost identical. Yellow has, instead, completely different addresses (even though it's important to say that general data-structure are the same, as well as the game engine, except obviously for some added features)

Red/Blue RAM Map [link (http://datacrystal.romhacking.net/wiki/Pok%C3%A9mon_Red/Blue:RAM_map)]
Similar to the ROM Map, but this lists several RAM locations used by the game. It's especially useful, when you're trying to figure out a certain part of code, since most of what ASM code does is moving values between ROM and RAM, and between RAM and RAM. So, once you know what is a certain RAM location used for, figuring out the code is an easy task.
Yellow RAM Map is pretty similar to this: the order of data is almost the same, but the location seems to be shifted by 1-2 bytes, compared to the R/B RAM Map.

RBY Text Table [link (http://www.snakeyes.org/tbl/files/pokemon.txt)][alt. link (http://datacrystal.romhacking.net/wiki/Pokemon_Red/Blue:TBL)]
If you apply the text table to a hex editor that supports it (I can suggest WindHex or Hexeccute; with some work you can get HexWorkshop to be a useful text editor too), you can localize and edit text, in almost no time! (especially if the hex editor supports relative search, which most likely should)

Giegue's Master Guide... [link (http://www.romhacking.net/docs/75/)]
...to Hacking Pokemon Games Red-Crystal is an old, incomplete document, filled with errors. Nonetheless, it's a somehow acceptable answer to many questions about editing specific things in the game (wild pokemon, mapping, base stats, evolutions,...)


SPECIFIC DATA STRUCTURES
RGBY Map Headers... [link (http://datacrystal.romhacking.net/wiki/Pokemon_Red/Blue:Notes)]
...& Stuff That Goes With It. In my opinion this is the most important, helpful and instructive 1st-gen-specific document (for things that can be modified just by hex editing). If you want to get confident with the ROM, read this doc. Then read it again, and again.

Base Stats [link (http://bulbapedia.bulbagarden.net/wiki/Pok%C3%A9mon_base_stats_data_structure_in_Generation_I)]
A clear explanation of the Base Stats' structure, byte by byte, and its location in ROM. Notice that the Base Stats follow the same order of the Pokedex.

Maps' Indexes And Names [link (http://hax.iimarck.us/post/1541/#p1541)]
A list of maps' IDs and their corresponent name to help orientate you through the maps.

Pokemon Indexes And Names [link (http://bulbapedia.bulbagarden.net/wiki/List_of_Pok%C3%A9mon_by_index_number_(Generation_I))]
One of the things that annoy people about 1st gen Pokemon is that there are two different orders: Pokemon can be ordered by Pokedex, or by their index (or ID) number. The second order can be confusing since it doesn't seem to follow any logic, so having a list of pokemon by their internal ID along with the Dex ID can help.

Wild Pokemon Data [link (http://iimarck.us/etc/wild.html)] [link (http://www.romhacking.net/docs/[73]changewildpokemon.htm)]
Thanks to IIMarckus for saving this conversation where you can figure out how and where wild pokemon data is stored. Check the second link too, it might help you understanding how to edit this data.

Pokedex Data Structure [link (http://www.romhacking.net/docs/522)]
In this doc you can find a dump of the pokedex info (name of species, height & weight, dex's text entry pointer).

Attacks Data Structure [link (http://hax.iimarck.us/files/rbymoveinfo.txt)]
A good documentation of each attack's specifics, including a description of what each effect-of-move byte means.

Town Map Editing [link (http://hax.iimarck.us/topic/5/)] [tool's link (http://hax.iimarck.us/topic/244/)]
Town Map layout consists of a RLE-compressed data which can use only 16 (=0x10) different tiles. Read the linked document to make your own Town Map for your 1st-gen hack. If you don't want to compress the data by hand, IIMarckus wrote a C program that can both compress or decompress RLE files (notice that the file must contain only the town map data, you still need a hex editor to create the uncompressed map and insert it in the game's ROM).


GRAPHICS
Game Boy graphics format [link (http://www.romhacking.net/docs/457)]
Game Boy's GFX format is 2BPP (two bit per plane), which means that 2 bits are required to display a single pixel in the screen.

Tile Layer Pro [tool link (http://www.romhacking.net/utils/108/)][fix-patch link (http://www.romhacking.net/utils/361/)]
You can use this cool tool (no pun intended) to edit uncompressed graphics: tilesets, OWs, attacks' graphics, titlescreen's title. Fonts and "red version" text are uncompressed too, but are stored in 1BPP format, so make sure you choose the correct format in TLP's menu.
TLP also can import Bitmap images.

Compression Tool [link (http://romendo.net/stag019/pokedex/reverse.php)]
This tool, written by stag019, compresses pictures from 2BPP (Game Boy) format into the format which is compatible with Red, Blue, Green and Yellow versions.

Decompression Algorithm [link (http://magicstone.de/rhwiki/article/Grafikkomprimierung_PKMN_RGBY)] [rbgfx.c (http://www.upokecenter.com/data/rbgfx.c)][sprites.c (https://github.com/ubitux/pokanalysis/blob/master/libpokerom/sprites.c)][disasm (https://docs.google.com/leaf?id=0Bwlg4esouXa-YjA5YmIwZmUtMDkwYi00YTI5LWE3MWItZDM3MDhiNTJlNTcw&hl=en_US)]
This document written by Tauwasser (both in german and in english) explains the "complex" algorithm that compress in a such efficient way all the in-battle sprites (trainers' and pokemon'). There are a couple of C programs that perform the decompression:
- rbgfx.c (http://www.upokecenter.com/data/rbgfx.c) (IIMarckus said: "a C program that rips the front‐ and back‐pics of all 151 Pokémon and converts them to bitmaps. (The code is written badly and is buggy on 64‐bit compilers, though.)").
- sprites.c (https://github.com/ubitux/pokanalysis/blob/master/libpokerom/sprites.c) (wrote by Ubitux for his great program Pokanalysis (http://pokanalysis.ubitux.fr/); I'm not sure it can be compiled as a stand-alone).
I've also linked my incomplete disassembly (https://docs.google.com/leaf?id=0Bwlg4esouXa-YjA5YmIwZmUtMDkwYi00YTI5LWE3MWItZDM3MDhiNTJlNTcw&hl=en_US) of the decompression routine.


MUSIC
RBY Music Doc [link (http://www.pokecommunity.com/showthread.php?t=194801)]
This doc was made to explain GSC music structure, but was expanded to explain RBY's as well.

RBY Music Importer [link (http://www.pokecommunity.com/showthread.php?t=231436)]
This tool is supposed to convert music previously composed with FamiTracker.


SCRIPTING
R/B Text-Scripting Commands [link (http://hax.iimarck.us/topic/160/)]
Several text-commands are listed with a short description. There might be some ASM reference, so you might want to give a look at the Assembly Zone, first (not necessarily, though).

R/B Scripting Guidelines [link (http://hax.iimarck.us/topic/390/)]
An overview of the level-scripts, the way are built in a 1st gen game (no scripting commands like newer generations, sorry). This document pre-requires ASM knowledge.


ASSEMBLY: DOCS
The ASM School [link (http://gameboy.mongenel.com/asmschool.html)]
This is a list of lessons for newbies that attempt to learn Assembly. It is a very good starting point, for people who don't know anything about GB-z80 ASM.

GameBoy Opcode Summary [link (http://www.devrs.com/gb/files/GBCPU_Instr.html)]
Here you can find listed all the opcodes along with a schematic explanation of their meaning/function.

Game Boy Official Programming Manual [link (http://www.romhacking.net/docs/544/)]
This is the official programming manual. It simply explains everything about GB/GBC/SGB hardware. The only thing I couldn't find is the SGB border arrangement, so I'm putting it here:
SGB-Border Tile Arrangement:
1st byte = tile ID
2nd byte:
| bit | meaning |
[7] Horizontal flipping [|]
[6] Vertical flipping [-]
[5] Unused
[4] Unused
[3] Unused
[2][1][0]: %000 = Pal 0, %010 = Pal 1, %100 = Pal 2


Gameboy Unofficial Programming Manual [link (http://www.romhacking.net/docs/396/)]
This doc doesn't cover everything, unlike the previous link; anyway it might help you since it's less challenging if you're trying to get your first grasp of the GB hardware.

Pandocs [link (http://nocash.emubase.de/pandocs.htm)]
Another link to GB hardware documentation. Since it has an index at its beginning, it might help you trying orientate in this great amount of info.

Gameboy Cribsheet [link (http://www.romhacking.net/docs/285/)]
This well-packed .pdf file is a great fast reference when you have to look for the meaning of a register or anything hardware-related, in few seconds. IIMarckus pointed out that it has some wrong values for opcodes, so for the correct hex correspondencies you should read THIS (http://www.pastraiser.com/cpu/gameboy/gameboy_opcodes.html).

THE Disassembly [link (https://bitbucket.org/iimarckus/pokered/src)]
This is a disassembly of Pokemon Red, work in progress by IIMarckus. It holds tons of information about almost all the things that have been listed in this post, so far. So if you don't understand or don't find something you're interested in in the previous links, you can give a look here, even if you still don't know assembly. This disassembly really contains some pieces of information that you won't find anywhere else.


ASSEMBLY: TOOLS
BGB [link (http://bgb.bircd.org/)]
This is an excellent Game Boy Emulator/Debugger that I suggest to anyone's working on a GB/C hack, instead of using other inaccurate emulators like VBA (that could lead to bugs in your hacks: example (http://www.pokecommunity.com/showthread.php?t=241348)). Some useful debugging features are:
- code/RAM/stack/registers viewer, that helps you keeping an eye on everything is happening on run-time;
- a (dis)assembler, that allows you to inject code directly;
- a VRAM/OAM/Palette viewer;
- an ASM dumper;
But there is much more: you can put breakpoints on code-access or on data-access, and you can also put conditional breakpoints. That's not all, so the best thing is starting using this debugger.
Other accurate emulators are Gambatte (http://sourceforge.net/projects/gambatte/) and KiGB (http://kigb.emuunlim.com/), which are multi-platform (BGB runs only on Windows, if I'm not wrong), but they seem to lack a debugger. KiGB's home site declares it's the most accurate emulator around.

Assembly Editor [link (http://www.romhacking.net/utils/282/)]
This tool made by Jigglypuff works almost like a hex editor but allows you to read/write the code both in bytecode (hex) and in mnemonics' form. Doesn't support labeling.

RGBDS [Linux: tool (git://github.com/bentley/rgbds-linux.git)][Linux: guide (http://anthony.bentley.name/rgbds/manual/rgbds/)] [Win: tool (http://mltreq.alwaysdata.net/etc/rgbds-lmod00.zip)][Win: guide (http://otakunozoku.com/RGBDSdocs/index.htm)]
My favorite assembler/linker. This is actually best to be used for large-project, rather than for small ASM hacks, probably. Anyway it's a very powerful toolkit: great macro language, supports labeling (of course!), and also includes a program to fix the ROM header. It might take a while to understand how everything works, but once you get used to it, it's the best tool you can use to build your Game Boy hack (especially if you have an already started disassembly, which link you can find in the previous section).


CONCLUSION
I hope I'm not forgetting anything. Oh well, I'll update it in the future, in case there's something I left out. Have a nice hacking time!

miksy91
July 9th, 2011, 9:12 PM
Great job andthanks for the link to ASM School ;)

Sawakita
July 10th, 2011, 2:45 AM
Thanks and you're welcome.

I've added an "ASM tools" section (debugger, assembler/linker). Also fixed some layout errors.

Mephodicus
July 10th, 2011, 3:11 AM
This is very useful. I've never really got into R/B hacking and I've only dabbled with it so it's useful for those who really need it.

IIMarckus
July 10th, 2011, 4:27 PM
Decompression Algorithm [link (http://magicstone.de/rhwiki/article/Grafikkomprimierung_PKMN_RGBY)]
This document written by Tauwasser (both in german and in english) explains the "complex" algorithm that compress in a such efficient way all the in-battle sprites (trainers' and pokemon'). No compressing tool exists, so far, to insert new sprites, so you'd have to compress sprites by hand (I've never seen it done before) or ASM-hack the game engine (already done before).If you want to see the decompression algorithm in action, rbgfx.c (http://www.upokecenter.com/data/rbgfx.c) is a C program that rips the front‐ and back‐pics of all 151 Pokémon and converts them to bitmaps. (The code is written badly and is buggy on 64‐bit compilers, though.)Gameboy Cribsheet [link (http://www.romhacking.net/docs/285/)]
This well-packed .pdf file is a great fast reference when you have to look for the meaning of a register or anything hardware-related, in few seconds.As I recall, it has some wrong values for opcodes, so keep that in mind.

psyxe
July 10th, 2011, 7:09 PM
If you want to see the decompression algorithm in action, rbgfx.c (http://www.upokecenter.com/data/rbgfx.c) is a C program that rips the front‐ and back‐pics of all 151 Pokémon and converts them to bitmaps. (The code is written badly and is buggy on 64‐bit compilers, though.)As I recall, it has some wrong values for opcodes, so keep that in mind.



im quite confused. i read through it as well as i could, but... xD i got nothing. would the rbgfx.c be something that could make changing the sprites easier? or is there another way to do it?

:) ive been researching how to hack red for a while now so this was EXTREMELY helpful info.

Sawakita
July 11th, 2011, 5:10 AM
If you want to see the decompression algorithm in action, rbgfx.c (http://www.upokecenter.com/data/rbgfx.c) is a C program that rips the front‐ and back‐pics of all 151 Pokémon and converts them to bitmaps. (The code is written badly and is buggy on 64‐bit compilers, though.)As I recall, it has some wrong values for opcodes, so keep that in mind.
Thank you, I'll fix the first post.
im quite confused. i read through it as well as i could, but... xD i got nothing. would the rbgfx.c be something that could make changing the sprites easier? or is there another way to do it?

:) ive been researching how to hack red for a while now so this was EXTREMELY helpful info.
Considering that it's a program that decompress sprites from ROM it's obvious that it doesn't help inserting edited sprites into the ROM. It might help figuring out how the algorithm works. As it has already been said you have some options:
- compress your sprites by hand;
- build a compressing tool;
- ASM hack the game engine so that it allows the support for uncompressed sprites.

Anyway I've added the source code of the C program written by Ubitux, if it helps.
And also added my partial disassembly of the decompression routine.

Check first post for everything.

psyxe
July 11th, 2011, 7:04 AM
well, i meant changing sprites easier as in being able to use it, edit them, and throw em back in somehow... i read through, its just being new to hacking pokemon, its hard to grasp some of this.

im going to look through and try to read through every step required to edit graphics of any kind... if any of you have time, i would greatly appreciate a slightly "dumbed down" explanation for sprite editing on it :) if not ill suffer through.. im not giving up :)

Sawakita
July 12th, 2011, 6:52 AM
I know, understanding the compression algorithm isn't easy, but I don't think it can be explained in a clearer way than how it is in the document written by Tauwasser.

Too bad, currently, there are just two options: figuring out the algorithm, or learning ASM.

psyxe
July 12th, 2011, 11:58 AM
okay... *sigh* i knew it wouldnt be easy anyways.. well, if theres anything you could do to help me i would really appreciate it... otherwise it looks like im in for a lot of studying...


------edit----------
ive looked through stuff... i know the basics of how to change stats ect... using the hex....

so i assume the pokemon's sprites are stored in there too... is there a way to edit the sprites through hex?

IIMarckus
July 12th, 2011, 8:20 PM
ive looked through stuff... i know the basics of how to change stats ect... using the hex....

so i assume the pokemon's sprites are stored in there too... is there a way to edit the sprites through hex?Editing the pics in hex still requires them to be compressed.

psyxe
July 12th, 2011, 9:02 PM
well, ive learnt quite a bit through this... but im still no closer to changing the sprites...

i read through everything i saw that had to do with the asm.....

Decompression Algorithm [link]
This document written by Tauwasser (both in german and in english) explains the "complex" algorithm that compress in a such efficient way all the in-battle sprites (trainers' and pokemon'). No compressing tool exists, so far, to insert new sprites, so you'd have to compress sprites by hand (I've never seen it done before) or ASM-hack the game engine (already done before).

- ASM hack the game engine so that it allows the support for uncompressed sprites.

how exactly is this done? im sorry if these seem really noobish but im sincerely trying... :)

Sawakita
August 7th, 2011, 8:21 AM
I've added a link about bits and bytes (http://web.njit.edu/~walsh/powers/bits.vs.bytes.html). Thanks to kkj1116 for suggesting it.

well, ive learnt quite a bit through this... but im still no closer to changing the sprites...
i read through everything i saw that had to do with the asm.....
how exactly is this done? im sorry if these seem really noobish but im sincerely trying... :)
You do it through an assembler or a hex editor, if you mean the program. If you meant how you do it technically, you can start by disassembling the routine using a debugger (the decompression routine is at $251A in a Red/Blue ROM, while in Yellow should be located at $2410).

giradialkia
August 17th, 2011, 4:30 AM
This seems extremely useful, so stickying :)

jvpski3
September 2nd, 2011, 10:45 AM
Dude, you are the best! Thank you Thank you Thank you! THANK YOU! You are the king of Gen I-II hacking!! Woo!

stag019
September 4th, 2011, 11:23 AM
Decompression Algorithm
No compressing tool exists, so far, to insert new sprites, so you'd have to compress sprites by hand (I've never seen it done before)
This has been done now. I'd show you the link, but "You are only allowed to post URLs to other sites after you have made 15 posts or more." So therefore, you lose out. :) Unless of course, you visit Skeetendo, in the Devamp Pokemon thread.

I will post the tool when I work out all the bugs/when I'm allowed to post links (see also, March of 2028 at the current rate I'm going).

hi sir tomato my password is syvniti
September 4th, 2011, 11:28 AM
the Bits and Bytes link doesn't work, please fix it.

Sawakita
September 5th, 2011, 5:25 AM
This has been done now.
So, did you actually compressed it by hand, one bit at a time? Kudos to you for the patience.
So therefore, you lose out.
I already can put sprites in RBY. I also never lose.
I will post the tool when I work out all the bugs/when I'm allowed to post links (see also, March of 2028 at the current rate I'm going).
You might not know that they've invented something called post attachment. Just for your information.

the Bits and Bytes link doesn't work, please fix it.
Fixed, thanks for pointing it out.

stag019
September 6th, 2011, 1:01 PM
You might not know that they've invented something called post attachment. Just for your information.
Really? I had no idea such technology existed!

However, the biggest problem with that is that because I'm much better at scripting languages (PHP) than programming languages (C, C++, although I'm getting better at it), the current form of the tool is an online tool: a PHP script. And while I could release the source and allow anyone to upload it themselves (or run on their localhost) it would be much more advantageous to simply link to the one I've already uploaded (when I'm finished with it).

At some point I do plan to port it to C or C++ though.

IIMarckus
September 6th, 2011, 5:14 PM
Really? I had no idea such technology existed!

However, the biggest problem with that is that because I'm much better at scripting languages (PHP) than programming languages (C, C++, although I'm getting better at it), the current form of the tool is an online tool: a PHP script. And while I could release the source and allow anyone to upload it themselves (or run on their localhost) it would be much more advantageous to simply link to the one I've already uploaded (when I'm finished with it).

At some point I do plan to port it to C or C++ though.If you release the source code, maybe someone else will port it to C for you ;)

stag019
September 7th, 2011, 2:31 AM
While I do like your thought process there, keep this is mind:
"If Tauwasser documents the decompression routine, maybe someone else will create a tool to recompress graphics for him ;)"

He posted the documentation on the wiki in German on March 25th, 2006. He did a rough English translation on June 12th, 2010. It's September 7th, 2011, and only now are we getting close to a compression tool.

Because I already know what I'm doing (for the most part), I feel obligated, I feel it's my duty to finish this out.

...hopefully before Christmas.

Sawakita
September 8th, 2011, 9:10 AM
I've added the link to my sprite compression tool (see first post).

stag019
September 8th, 2011, 10:54 AM
Okay good then. Then I don't feel obligated to show my tool, since this works almost the exact same way mine does.

IIMarckus
September 8th, 2011, 4:38 PM
While I do like your thought process there, keep this is mind:
"If Tauwasser documents the decompression routine, maybe someone else will create a tool to recompress graphics for him ;)"And sure enough, it is happening. Barely a year after he translated it, too. Can you imagine how long it would have taken if he hadn’t released his doc?

My hacking time has been epsilon (http://mathworld.wolfram.com/Epsilon.html) for many months now, but since I released much of my work (https://bitbucket.org/iimarckus/pokered/) while I was working on it, it has been able to help others (and get improved by others), and will continue to do so long after I stop hacking completely. I heartily encourage this practice wherever possible.Because I already know what I'm doing (for the most part), I feel obligated, I feel it's my duty to finish this out.

...hopefully before Christmas.This is exactly what I’m talking about!

Sawakita
September 9th, 2011, 4:01 AM
Okay good then. Then I don't feel obligated to show my tool, since this works almost the exact same way mine does.
Why not? If yours is multiplatform and performs interpretations 2 and 3 too, it's certainly more efficient than the one I posted. Feel free to post it so people can have a better choice, if you want.

stag019
September 10th, 2011, 8:05 PM
Why not? If yours is multiplatform and performs interpretations 2 and 3 too, it's certainly more efficient than the one I posted. Feel free to post it so people can have a better choice, if you want.Well, it didn't perform interpretations 2 and 3 correctly until about 5 minutes ago.

And I guess you could call it multiplatform. It'll work on anything that can connect to the internet, parses basic HTML, and allows you to upload files and save downloadable files.

I'd post it here, but again, "[I am] only allowed to post URLs to other sites after [I] have made 15 posts or more." I will post it at Skeetendo though.

Sawakita
September 11th, 2011, 3:40 AM
Well, it didn't perform interpretations 2 and 3 correctly until about 5 minutes ago.

And I guess you could call it multiplatform. It'll work on anything that can connect to the internet, parses basic HTML, and allows you to upload files and save downloadable files.

I'd post it here, but again, "[I am] only allowed to post URLs to other sites after [I] have made 15 posts or more." I will post it at Skeetendo though.
I'm glad you got it sorted. I'll add the link in the first post.

supersoursky
June 25th, 2013, 8:31 AM
thanks! this thread helped me alot!!

WAFFAHOUSE
July 23rd, 2015, 6:32 AM
man I wish we had more info on hacking pokemon yellow version..... im working on a yellow hack now and im so lost lol it seems to be the most difficult of all pokemon games to hack (ranging from gen1-gen3 is what my experience is lol) if you have any additional info on hacking yellow, please update this for me man. I know a lot of us are in the dark about yellow version hacking lol




thanks waffa




ps
great post!!!!! almost makes me wanna do a red or blue hack hahahahahaha I just love the fact in yellow a poke follows lol that's why im hell bent on hacking yellow version hahahahaha

RaidenRaider
March 2nd, 2016, 10:23 AM
I'm trying to edit the title screen on Red/Blue using the disassembly, so that when the game starts it says "Red 251 Version", "Blue 251 Version" and "Green 251 Version", but it's not working for me. Pleas help me someone.

Thisis what I've put at the bottom of engine/titlescreen.asm.

VersionOnTitleScreenText: ; 45a1 (1:45a1)
IF DEF(_RED)
db $60,$61,$7F,$65,$66,$67,$68,$69,"@" ; "Red Version"
ENDC
IF DEF(_GREEN)
db $62,$63,$64,$7F,$65,$66,$67,$68,$69,$70,"@" ; "Green Version"
ENDC
IF DEF(_BLUE)
db $61,$62,$63,$64,$65,$66,$67,$68,"@" ; "Blue Version"
ENDC

Lost
March 2nd, 2016, 11:22 AM
I'm trying to edit the title screen on Red/Blue using the disassembly, so that when the game starts it says "Red 251 Version", "Blue 251 Version" and "Green 251 Version", but it's not working for me. Pleas help me someone.

Thisis what I've put at the bottom of engine/titlescreen.asm.

VersionOnTitleScreenText: ; 45a1 (1:45a1)
IF DEF(_RED)
db $60,$61,$7F,$65,$66,$67,$68,$69,"@" ; "Red Version"
ENDC
IF DEF(_GREEN)
db $62,$63,$64,$7F,$65,$66,$67,$68,$69,$70,"@" ; "Green Version"
ENDC
IF DEF(_BLUE)
db $61,$62,$63,$64,$65,$66,$67,$68,"@" ; "Blue Version"
ENDC

If you read through the comment above that bit, it says this:
; these point to special tiles specifically loaded for that purpose and are not usual text

This means that you have to edit a special image file first which contains a tileset for the text. In this case, the image you'll want to edit is found at "gfx/red/redgreenversion.png" (there is also "gfx/blue/blueversion.png"). Once you've done that you can edit the data to display the desired text based on the tileset.

RaidenRaider
March 2nd, 2016, 11:39 AM
If you read through the comment above that bit, it says this:
; these point to special tiles specifically loaded for that purpose and are not usual textThis means that you have to edit a special image file first which contains a tileset for the text. In this case, the image you'll want to edit is found at "gfx/red/redgreenversion.png" (there is also "gfx/blue/blueversion.png"). Once you've done that you can edit the data to display the desired text based on the tileset.

Okay, the first part I can do, I can edit the specific .png files to say "Red 251 Version", "Blue 251 Version" and "Green 251 Version, but the numbers 251 don't display at all in-game because I think the font is wrong, and secondly, I don't know how to edit the data to display the desired text based on the tileset in engine/titlescreen.asm.

The text is either flowing offscreen on the left or right, the 251 doesn't show up instead being replaced by big blocks of red/blue/green, depending on the version, or even see's the whole text being severly centered to the right of the screen.

Lost
March 2nd, 2016, 2:05 PM
Okay, the first part I can do, I can edit the specific .png files to say "Red 251 Version", "Blue 251 Version" and "Green 251 Version, but the numbers 251 don't display at all in-game because I think the font is wrong, and secondly, I don't know how to edit the data to display the desired text based on the tileset in engine/titlescreen.asm.

The text is either flowing offscreen on the left or right, the 251 doesn't show up instead being replaced by big blocks of red/blue/green, depending on the version, or even see's the whole text being severly centered to the right of the screen.

(before you read this, know this is mostly what I'm figuring out as I go... RBY hacking is not my forte)

So when you edit a tileset like this, you need to find the code where it is loaded and ensure that the entire size of the image is loaded into memory. In this case, in engine/titlescreen.asm you'll want to find this code (I found it at line 59):

...
ld hl, Version_GFX ; $402f
IF DEF(_RED)
ld de,vChars2 + $600
ld bc,$50
ENDC
IF DEF(_BLUE)
ld de,vChars2 + $600 + $10
ld bc,$50 - $10
ENDC
ld a, BANK(Version_GFX)
...


This code is interesting because of the value being loaded into bc in the instruction "ld bc,$50" and "ld bc,$50-$10" because $50 is 80 in decimal while $50 - $10 = $40 which is 64 in decimal, which you might realize is the size of our version text in pixels. So in order to load a larger image, we want to change this value. Say for example I ended up expanding the new text for Red version to 96 pixels in width, then I would it like so:
IF DEF(_RED)
ld de,vChars2 + $600
ld bc,$60 ; note here that $60 is 96 in hexadecimal
ENDC

By doing this we should hopefully be allocating 96 pixels of space for our image instead of the original 80 that was there.

As for editing data, well, what we do is break our logo into small squares ("tiles") that are 8 pixels by 8 pixels in size, like so:
http://i.imgur.com/w4sdCpk.png

Now, based on this line of data and our image, we can figure out how this tilemap is laid out:
db $60,$61,$7F,$65,$66,$67,$68,$69,"@" ; "Red Version"

As we can see, $60 corresponds to the first block in the image (which shows "Re"). Knowing this, the rest of the layout becomes clear, and we can map the blocks of the tileset as follows:
http://i.imgur.com/YRQeN2E.png
Where $60 is the first tile, and every subsequent tile increases by one. It is important to note that this is in hexadecimal, so a tile to the right of $69 would be $6A. Also, you'll see that $7F is not present on our tileset. This is OK! Because it simply maps to a part of the memory that would essentially be $16 tiles beyond our image, which would be "blank" data because no other images were loaded in that spot. Because it's blank, it will display as all white on the titlescreen and is used as a space character here. Finally, we can assume that "@" refers to an "end of tilemap" character or something similar.

So when you make your new tileset, break it apart into 8x8 tiles and map as I have done here. You can even fit multiple logos onto one image, as has been done with the original "RedGreenVersion" image and through clever use of the data you can only display the specific parts you want the player to see for a specific version. The important part in this specific case is that your tile starts at $60 instead of $0 like we might normally think when programming. If you look at the code for the Copyright string tilemap, you'll see it follows this same convention.

I hope this works for you, as I am partially guessing on the code editing part. :)

RaidenRaider
March 2nd, 2016, 4:55 PM
(before you read this, know this is mostly what I'm figuring out as I go... RBY hacking is not my forte)

So when you edit a tileset like this, you need to find the code where it is loaded and ensure that the entire size of the image is loaded into memory. In this case, in engine/titlescreen.asm you'll want to find this code (I found it at line 59):

...
ld hl, Version_GFX ; $402f
IF DEF(_RED)
ld de,vChars2 + $600
ld bc,$50
ENDC
IF DEF(_BLUE)
ld de,vChars2 + $600 + $10
ld bc,$50 - $10
ENDC
ld a, BANK(Version_GFX)
...
This code is interesting because of the value being loaded into bc in the instruction "ld bc,$50" and "ld bc,$50-$10" because $50 is 80 in decimal while $50 - $10 = $40 which is 64 in decimal, which you might realize is the size of our version text in pixels. So in order to load a larger image, we want to change this value. Say for example I ended up expanding the new text for Red version to 96 pixels in width, then I would it like so:
IF DEF(_RED)
ld de,vChars2 + $600
ld bc,$60 ; note here that $60 is 96 in hexadecimal
ENDCBy doing this we should hopefully be allocating 96 pixels of space for our image instead of the original 80 that was there.

As for editing data, well, what we do is break our logo into small squares ("tiles") that are 8 pixels by 8 pixels in size, like so:
http://i.imgur.com/w4sdCpk.png

Now, based on this line of data and our image, we can figure out how this tilemap is laid out:
db $60,$61,$7F,$65,$66,$67,$68,$69,"@" ; "Red Version"As we can see, $60 corresponds to the first block in the image (which shows "Re"). Knowing this, the rest of the layout becomes clear, and we can map the blocks of the tileset as follows:
http://i.imgur.com/YRQeN2E.png
Where $60 is the first tile, and every subsequent tile increases by one. It is important to note that this is in hexadecimal, so a tile to the right of $69 would be $6A. Also, you'll see that $7F is not present on our tileset. This is OK! Because it simply maps to a part of the memory that would essentially be $16 tiles beyond our image, which would be "blank" data because no other images were loaded in that spot. Because it's blank, it will display as all white on the titlescreen and is used as a space character here. Finally, we can assume that "@" refers to an "end of tilemap" character or something similar.

So when you make your new tileset, break it apart into 8x8 tiles and map as I have done here. You can even fit multiple logos onto one image, as has been done with the original "RedGreenVersion" image and through clever use of the data you can only display the specific parts you want the player to see for a specific version. The important part in this specific case is that your tile starts at $60 instead of $0 like we might normally think when programming. If you look at the code for the Copyright string tilemap, you'll see it follows this same convention.

I hope this works for you, as I am partially guessing on the code editing part. :)

Okay thank you so much. That was a very detailed and helpful tutorial. I have now got a Red version, Green version and Blue version on the titlescreen, with each in their respective colours. It looks amazing. Thank you very much. It's greatly appreciated. I do have one more favour/request if you're willing to help me out further? I'll even list you as one of my Special Thanks credits when this ROM Hack goes live, alongside Mateo, to show my appreciation for your help.

On the titlescreen, you get a selection of Pokemon that scrolls across the screen, in the respective Red and Blue versions, with each of the Pokemon having respective Red and Blue colour palettes, but I was wondering how I create a green palette for each of the Pokemon on the titlescreen in my Green version. I know the answer is in data/super_palettes.asm somewhere.

Lost
March 2nd, 2016, 9:57 PM
Okay thank you so much. That was a very detailed and helpful tutorial. I have now got a Red version, Green version and Blue version on the titlescreen, with each in their respective colours. It looks amazing. Thank you very much. It's greatly appreciated. I do have one more favour/request if you're willing to help me out further? I'll even list you as one of my Special Thanks credits when this ROM Hack goes live, alongside Mateo, to show my appreciation for your help.

On the titlescreen, you get a selection of Pokemon that scrolls across the screen, in the respective Red and Blue versions, with each of the Pokemon having respective Red and Blue colour palettes, but I was wondering how I create a green palette for each of the Pokemon on the titlescreen in my Green version. I know the answer is in data/super_palettes.asm somewhere.

I'm glad I was able to help! Now for your next question, I took a peek in data/super_palettes.asm and found this code at line 55:
IF DEF(_RED)
RGB 31,29,31 ; PAL_LOGO1
RGB 30,30,17
RGB 17,23,10
RGB 21,0,4
ENDC
IF DEF(_BLUE)
RGB 31,29,31 ; PAL_LOGO1
RGB 30,30,17
RGB 21,0,4
RGB 14,19,29
ENDC

I have a hunch that these are the palettes we want to edit for the title screen (the comment of "PAL_LOGO1" makes it stand out to me). On the GameBoy, colors are stored in a 16 bit word, using 5 bits for each color with 1 extra left over in this order: [extra (1)][blue (5)][green (5)][red (5)]. This is simply called 15-bit RGB (https://en.wikipedia.org/wiki/List_of_monochrome_and_RGB_palettes#15-bit_RGB) and Nintendo loves this format, as it is also used on the GBC, GBA and NDS. Since each color is only allowed 5 bits per color, this means that each color component will have a value between 0 and 31. To turn this into a normal color value, which ranges from 0 to 255, the value is multiplied by 8.

Here, the "RGB #,#,#" format refers to a macro (https://en.wikipedia.org/wiki/Macro_(computer_science)), which is a piece of code defined in macros.asm that makes it easier for a programmer to write specialized code while the assembler will translate it into a more specific format (in this case the word holding color data).

This is what the values of the RED palette would thus be:
IF DEF(_RED)
RGB 31,29,31 ; 248, 232, 248 (this color)
RGB 30,30,17 ; 240, 240, 136 (this color)
RGB 17,23,10 ; 136, 184, 80 (this color)
RGB 21,0,4 ; 168, 0, 32 (this color)
ENDC

Looks strange, right? I was a bit worried I had gone the wrong way. So just to make sure, I dug a bit deeper. First, I found the code that handles sending palette data when the titlescreen is loaded. It is found on line 113 of engine/palettes.asm (labeled "SenPalPacket_Titlescreen"). From there, I found the palette "packet" sent to the titlescreen in data/sgb_packets.asm, specificially at line 208, which shows:
PalPacket_Titlescreen: PAL_SET PAL_LOGO2, PAL_LOGO1, PAL_MEWMON, PAL_PURPLEMON

What this tells us is that in the data/super_palettes.asm file, the palettes labeled as PAL_LOGO2, PAL_LOGO1, PAL_MEWMON, and PAL_PURPLEMON are all sent to the titlescreen when it loads its palettes. So we are on the right track!

For this, look for the comments denoting those palettes and mess around with the values. It'll take some trial and error but it should work out. You can even try adding some of your own IF DEF sections for custom palettes depending on game version.

RaidenRaider
March 3rd, 2016, 4:33 AM
I'm glad I was able to help! Now for your next question, I took a peek in data/super_palettes.asm and found this code at line 55:
IF DEF(_RED)
RGB 31,29,31 ; PAL_LOGO1
RGB 30,30,17
RGB 17,23,10
RGB 21,0,4
ENDC
IF DEF(_BLUE)
RGB 31,29,31 ; PAL_LOGO1
RGB 30,30,17
RGB 21,0,4
RGB 14,19,29
ENDCI have a hunch that these are the palettes we want to edit for the title screen (the comment of "PAL_LOGO1" makes it stand out to me). On the GameBoy, colors are stored in a 16 bit word, using 5 bits for each color with 1 extra left over in this order: [extra (1)][blue (5)][green (5)][red (5)]. This is simply called 15-bit RGB (https://en.wikipedia.org/wiki/List_of_monochrome_and_RGB_palettes#15-bit_RGB) and Nintendo loves this format, as it is also used on the GBC, GBA and NDS. Since each color is only allowed 5 bits per color, this means that each color component will have a value between 0 and 31. To turn this into a normal color value, which ranges from 0 to 255, the value is multiplied by 8.

Here, the "RGB #,#,#" format refers to a macro (https://en.wikipedia.org/wiki/Macro_(computer_science)), which is a piece of code defined in macros.asm that makes it easier for a programmer to write specialized code while the assembler will translate it into a more specific format (in this case the word holding color data).

This is what the values of the RED palette would thus be:
IF DEF(_RED)
RGB 31,29,31 ; 248, 232, 248 (this color)
RGB 30,30,17 ; 240, 240, 136 (this color)
RGB 17,23,10 ; 136, 184, 80 (this color)
RGB 21,0,4 ; 168, 0, 32 (this color)
ENDCLooks strange, right? I was a bit worried I had gone the wrong way. So just to make sure, I dug a bit deeper. First, I found the code that handles sending palette data when the titlescreen is loaded. It is found on line 113 of engine/palettes.asm (labeled "SenPalPacket_Titlescreen"). From there, I found the palette "packet" sent to the titlescreen in data/sgb_packets.asm, specificially at line 208, which shows:
PalPacket_Titlescreen: PAL_SET PAL_LOGO2, PAL_LOGO1, PAL_MEWMON, PAL_PURPLEMONWhat this tells us is that in the data/super_palettes.asm file, the palettes labeled as PAL_LOGO2, PAL_LOGO1, PAL_MEWMON, and PAL_PURPLEMON are all sent to the titlescreen when it loads its palettes. So we are on the right track!

For this, look for the comments denoting those palettes and mess around with the values. It'll take some trial and error but it should work out. You can even try adding some of your own IF DEF sections for custom palettes depending on game version.

Wow, this is so detailed. You really know what you're talking about. Your help it so appreciated on this. I'm definitely putting you down on my Special Thanks section as a contributor to my hack once I launch it, because you've been so incredibly helpful to me. It's taught me some new things that I never knew before as I'm new to ASM editing.

I've actually been working with Mateo on a version on his Red++ ROM Hack, but instead of his extra Pokemon (from 152 to 205), I've added all of the monsters from Gen II (Chikorita to Celebi), on top of the original 151 (Bulbasaur to Mew). When I launch it, I plan to have a Normal version (Red 251), a Hard version (Blue 251) and an Extreme version (Green 251), with each one having an increased level curve in Trainer and Gym battles, as well as Wild encounters).

All I need to do now is edit some of the splashscreens that Mateo put in place (he's going to help me with that), add the four new maps for Raikou, Entei, Suicune and Unown (so that there is only one of each in the game), add the Shiny versions of all 251 Pokemon (I have a few ideas on how to add them thanks to studying the Red/Blue Deluxe Disassembly on Github), and then when Mateo adds the Battle Tower, the Pokegear Pouches, the TM Cases, Dive Areas, Move Tutors/Deleters/Relearners, Special Attack/Special Defense split into two stats, and other content to Red++, then I'll be adding them to my hack too.

Would you like to see the titlescreens I've edited? I can even give you the link to the Github source (that I'm updating later on today), so that you can test it out yourself.