about summary refs log tree commit diff stats
path: root/gba/source/serialize.h
Commit message (Collapse)AuthorAgeFilesLines
* Fixed shininess determinationKelly Rauchenberger2017-09-231-3/+1
| | | | | Shininess is determined with the ID of the OT, not the game the Pokémon is currently in.
* Increased stability and added support for non-English namesKelly Rauchenberger2017-09-101-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GameCube side of the program now can convert from the propietary character set to UTF-8. This is useful for representing names of Pokémon and players in a neutral way. The propietary character set is mostly compatible between the six languages supported by the games (as in, the hiragana and katakana characters unique to Japanese occupy spaces not used by the other languages for names, as do the letters with umlauts unique to German). However, six codepoints differ between the Japanese and non-Japanese character sets, and an additional two differ even amongst the non-Japanese sets. Because of this, the function that converts to UTF-8 takes a language as a parameter, and uses the correct characters for that language. From there, the behavior of this function differs slightly to that of the games. In the non-Japanese games, the Japanese encoding is used if the Pokémon in question originated in a Japanese game, and the non-Japanese encoding (disregarding the regional differences in the two codepoints mentioned earlier) otherwise. In the Japanese games, the Japanese encoding is used regardless of the Pokémon's origin. The decoding function I wrote always uses the character set corresponding to the language of the Pokémon's origin, because that most accurately represents the name given to it, and will not change just because the Pokémon was traded to a different game. The character set used for the name of the player is the one corresponding to the language of the cartridge. Additionally, a number of changes were made to the communication protocol between the GameCube and the GBA that appear to have dramatically increased stability. The most significant of these is likely that the transfer delay was increased tenfold. This causes the multiboot image to take slightly longer to download to the GBA, but the difference is not large enough to outweigh the benefits of the increased stability.
* Added copyright info to the top of three new filesKelly Rauchenberger2017-08-181-0/+6
|
* Started working on serializing pokemon dataKelly Rauchenberger2017-08-181-0/+19
The GBA program now sends serialized data about the first pokemon in the player's party over to the Wii. This data doesn't yet include all of the information that we will eventually want. It does, however, not transfer any private data, specifically IVs, EVs, and the personality value. It does this by deriving the public information (stats, nature, gender, shiny) before sending the pokemon over. Because of this, lookup tables for things such as base stats were needed, and given that these are large tables, it was easier to use the tables already existent in the game's ROM. Thus, the addresses of the three lookup tables that are now used are necessary for each ROM that this tool supports. I derived the addresses for version 1 of English Pokemon LeafGreen by dumping my own copy and searching through it with a text editor. Thus, at the current time, that cartridge is the only one that is supported. I will supplement this soon with addresses for the other four gen 3 carts that I have, but that will still not provide a very large amount of coverage. I have not yet decided how to address this issue. There is one current bug with the serialized data: the Wii doesn't seem to see the original trainer ID. Will fix.