This project is close to an end now...
I will never forget you guys.
Ahaha XD
What I mean is do you still use crystaltile at this part and also the color of the game looks darker
This project is close to an end now...
I will never forget you guys.
Ahaha XD
What I mean is do you still use crystaltile at this part and also the color of the game looks darker
We use crystaltile for the graphics of the game. The rest are custom-made tools.
Hello everyone! I bring great news
Thanks to @EarthDarkness the game fully supports single byte reading with limited ASCII support. Now you can input whatever name you wanted to the MC. This will greatly speed up the text insertion progress, as the code is much cleaner and easier to understand. The downside to it is that all the text inserted so far won't work, so it will have to be repeated. extended ASCII is being considered (this will help in SPA translations, for starters).
Here are some pictures which were shown in the Discord public chat server:
As you can notice, we still have to deal with the spacing between R and i, i and t. That's because the font has fixed witdh spacing. With a variable width font, this problem won't be an issue anymore.
Thanks to @EarthDarkness the game fully supports single byte reading with limited ASCII support. Now you can input whatever name you wanted to the MC. This will greatly speed up the text insertion progress, as the code is much cleaner and easier to understand. The downside to it is that all the text inserted so far won't work, so it will have to be repeated. extended ASCII is being considered (this will help in SPA translations, for starters).
Here are some pictures which were shown in the Discord public chat server:
As you can notice, we still have to deal with the spacing between R and i, i and t. That's because the font has fixed witdh spacing. With a variable width font, this problem won't be an issue anymore.
Last edited by Pablitox,
At last he managed to return and I am very happy to see that everything and everyone is still alive in this
I admire you for continuing ^ - ^
I admire you for continuing ^ - ^
Hello everyone! I bring great news
Thanks to @EarthDarkness the game fully supports single byte reading with limited ASCII support. Now you can input whatever name you wanted to the MC. This will greatly speed up the text insertion progress, as the code is much cleaner and easier to understand. The downside to it is that all the text inserted so far won't work, so it will have to be repeated. extended ASCII is being considered (this will help in SPA translations, for starters).
Here are some pictures which were shown in the Discord public chat server:
As you can notice, we still have to deal with the spacing between R and i, i and t. That's because the font has fixed witdh spacing. With a variable width font, this problem won't be an issue anymore.
What's the 8 at the end of ritchburn? and will the final product support Mulitplayer?
Ritchburn
I'm not sure, that depends on the game working on the current emulators/flashcarts. The patch shouldn't affect the link option.
oh, just a cursor of sorts, it will not be presente in the final version, so don't worry about it
I'm not sure, that depends on the game working on the current emulators/flashcarts. The patch shouldn't affect the link option.
Ritchburn
oh, just a cursor of sorts, it will not be presente in the final version, so don't worry about it
I'm not sure, that depends on the game working on the current emulators/flashcarts. The patch shouldn't affect the link option.
Thats good news some patches disable link options. Will the link be wireless adapter or Link Cable?
Who are the current encoders for now? Is Anniethegamer still present?
How's this coming along with the new ASCII injection? I'm looking forwards to this release, but the lack of progress updates makes me sad.
it's not like we are gonna have daily updates everyday, just consider it a lucky streak. Anyway, so far Earth has decided that we'll be supporting the first 48 chars from the extended ascii table (numbers: 128-175 included). But the 80 left will be used for wide chars which leaves us with 40 wide chars. These will be used for special characters like the hearth, music and for 6x6 text like what we did with the disassemble text to fit it into a 24x12 (2 wide chars). But for the english release these 48 extended chars will not be used except for player names.
More than ten years ago If I'm not mistaken!
I'm eagerly waiting for this to drop before I start playing the trilogy, I've never played, and don't want to be bored after finishing part 2. ^^;
As promised I'll do more in depth about how I enabled support for ascii.
First I'll explain how we did this previously, then I'll talk about the problem I faced, then I'll show my solution, and finally will discuss about possible issues and limitations.
---background info
The game has native support for the sjis or shift jis (Shift Japanese Industrial Standards) encoding which consists of a base table with 256 entries. Most of these entries are straight characters but a dozen or so are the ids of secondary tables with 256 entries as well. Those secondary tables contain only characters (tertiary tables),and these are the characters the game uses. So for the game to describe 1 character it need 1byte(256 values) for the table id and another byte for the character in that table.
The game does not store the entire table on the cartridge as it would taka too much space. It instead only stores the useful characters using tables and pointer(basically a memory address of anything the developer wants). I'll not go in detail on how these table work.
The visual representation of each character is stores as a literal bitmap (1 byte is composed 8 bits, each bit can be 0 or 1). So if the bit is 1 the game paints the pixel and if not it don't. the sjis characters use 12x12 pixels so to store a bitmap of that we need 12*2*byte. 2 bytes for the width (2*8bits = 16 bits, we use the first 12 and ignore the last 4) and 1 pair of bytes for each of the 12 pixels of the height.
---old way we did ascii
The original translator that basically started this project eon ago (that goes by the user Ritchburn) created a font of 6x12 (6 wide by 12 tall) ascii characters and stored the most used combinations of these (he couldn't do all possible combinations because the isn't enough space on the cartridge). After overwriting the previous bitmap with a combination of 2 ascii bitmaps he stored the value of the previously overwritten sjis in a table. This was a 2D table that was indexed with each ascii of the pair representing to each dimension. Then to patch the strings he simply parsed the desired string dividing it into pairs of ascii characters and used the table to loop up the corresponding value for that combination. This if how up till now things where done.
---the asm problem
The game has many types of text, from uncompressed, to menus, to stylized, to regular text.
The main types of text are displayed using gba tilemaps, these can be on 2 colors (depending on the background type: black/beige), but the stylized text we refer as "bigtext" (that not only can be double size, but also can be of increasing/ decreasing size, and placed at any coordinate on the screen) uses sprites just like the playable character, npcs among other things. Clearly if I were to change the game to read 1 byte and display a 6x12 character I would need to change more that 1 assembly function. Previously a hacked that went by the game of Aent created a patch that read 1 byte instead of 2 but he used the 12x12 western characters on the sjis table. This was great but the number of characters that would fit in each line was 18, which is not so nice. I'm not sure why he left but I guess he found out that type of challenge was to create a the ascii support previously mentioned.
---my solution
First A little background on my skills. I'm a programmer focused on graphics, GPU and high performance programming. I work as a R&D for a laboratory that develops solution for processing and visualization of huge data sets.
Despite not knowing the background of Aent I'm clearly not much better at asm hack than him. So how did I solve this problem of enabling support to ascii? Well I didn't.
At least not the way I described above. Instead of trying to change the game to display each 6x12 character individually I instead run with it and kept using the original display system. Basically I went around the problem. I found a function that take as input the sjis character code (2 bytes) and calculates the position in memory where its bitmap is stored. I then proceeded to change this function to do 2 things combine 2 6x12 bitmaps on-the-fly and return the position on memory that I stored it. So now the function reads 2 ascii characters, combines them into a 12x12 bitmap and return the address to it.
To support my hack the original sjis table and bitmaps is overwritten with a straight ascii bitmap for each of the supported characters (codes 32 to 175 included).
This breaks all non image text in the game and completely removes the original sjis characters.
--discussion
Now we support all possible combinations of the supported ascii characters (letters, numbers, and special characters).
Some things still need to be aligned to even bytes like the player/partner names. For these in some cases we need to pad the strings with one additional space.
I use a area in memory that as far as I tested is not used, but there is still the possibility that it might conflict with another assembly routine on the future. This can create crashes and freezes. The good thing is that I can easily change the location if it indeed conflicts.
This make debugging much easier as now I can know that the f is written on that opcode I'm trying to patch.
For the uncompressed text it is as simple patch to the tools we are already using. So no work will be lost.
Not all is great. We get a little bit more space as we can combine '~' with letters, numbers are 1 byte and such, but uncompressed text is still limited to the previous lengths we already knew.
I hope this was clear enough despite being this large of a post.
I still going to take some more time to isolate the needed modification to the tools we are using so that the state of art translation can use the new ascii support.
First I'll explain how we did this previously, then I'll talk about the problem I faced, then I'll show my solution, and finally will discuss about possible issues and limitations.
---background info
The game has native support for the sjis or shift jis (Shift Japanese Industrial Standards) encoding which consists of a base table with 256 entries. Most of these entries are straight characters but a dozen or so are the ids of secondary tables with 256 entries as well. Those secondary tables contain only characters (tertiary tables),and these are the characters the game uses. So for the game to describe 1 character it need 1byte(256 values) for the table id and another byte for the character in that table.
The game does not store the entire table on the cartridge as it would taka too much space. It instead only stores the useful characters using tables and pointer(basically a memory address of anything the developer wants). I'll not go in detail on how these table work.
The visual representation of each character is stores as a literal bitmap (1 byte is composed 8 bits, each bit can be 0 or 1). So if the bit is 1 the game paints the pixel and if not it don't. the sjis characters use 12x12 pixels so to store a bitmap of that we need 12*2*byte. 2 bytes for the width (2*8bits = 16 bits, we use the first 12 and ignore the last 4) and 1 pair of bytes for each of the 12 pixels of the height.
---old way we did ascii
The original translator that basically started this project eon ago (that goes by the user Ritchburn) created a font of 6x12 (6 wide by 12 tall) ascii characters and stored the most used combinations of these (he couldn't do all possible combinations because the isn't enough space on the cartridge). After overwriting the previous bitmap with a combination of 2 ascii bitmaps he stored the value of the previously overwritten sjis in a table. This was a 2D table that was indexed with each ascii of the pair representing to each dimension. Then to patch the strings he simply parsed the desired string dividing it into pairs of ascii characters and used the table to loop up the corresponding value for that combination. This if how up till now things where done.
---the asm problem
The game has many types of text, from uncompressed, to menus, to stylized, to regular text.
The main types of text are displayed using gba tilemaps, these can be on 2 colors (depending on the background type: black/beige), but the stylized text we refer as "bigtext" (that not only can be double size, but also can be of increasing/ decreasing size, and placed at any coordinate on the screen) uses sprites just like the playable character, npcs among other things. Clearly if I were to change the game to read 1 byte and display a 6x12 character I would need to change more that 1 assembly function. Previously a hacked that went by the game of Aent created a patch that read 1 byte instead of 2 but he used the 12x12 western characters on the sjis table. This was great but the number of characters that would fit in each line was 18, which is not so nice. I'm not sure why he left but I guess he found out that type of challenge was to create a the ascii support previously mentioned.
---my solution
First A little background on my skills. I'm a programmer focused on graphics, GPU and high performance programming. I work as a R&D for a laboratory that develops solution for processing and visualization of huge data sets.
Despite not knowing the background of Aent I'm clearly not much better at asm hack than him. So how did I solve this problem of enabling support to ascii? Well I didn't.
At least not the way I described above. Instead of trying to change the game to display each 6x12 character individually I instead run with it and kept using the original display system. Basically I went around the problem. I found a function that take as input the sjis character code (2 bytes) and calculates the position in memory where its bitmap is stored. I then proceeded to change this function to do 2 things combine 2 6x12 bitmaps on-the-fly and return the position on memory that I stored it. So now the function reads 2 ascii characters, combines them into a 12x12 bitmap and return the address to it.
To support my hack the original sjis table and bitmaps is overwritten with a straight ascii bitmap for each of the supported characters (codes 32 to 175 included).
This breaks all non image text in the game and completely removes the original sjis characters.
--discussion
Now we support all possible combinations of the supported ascii characters (letters, numbers, and special characters).
Some things still need to be aligned to even bytes like the player/partner names. For these in some cases we need to pad the strings with one additional space.
I use a area in memory that as far as I tested is not used, but there is still the possibility that it might conflict with another assembly routine on the future. This can create crashes and freezes. The good thing is that I can easily change the location if it indeed conflicts.
This make debugging much easier as now I can know that the f is written on that opcode I'm trying to patch.
For the uncompressed text it is as simple patch to the tools we are already using. So no work will be lost.
Not all is great. We get a little bit more space as we can combine '~' with letters, numbers are 1 byte and such, but uncompressed text is still limited to the previous lengths we already knew.
I hope this was clear enough despite being this large of a post.
I still going to take some more time to isolate the needed modification to the tools we are using so that the state of art translation can use the new ascii support.
That's quite the message! But very informative! Thank you Earth
A few things:
So the stylized text has the same amount of characters right? that hasn't changed?
I see, so you found another way to implement ascii instead of the usual, ASM hacking. Now I know what you meant about the VWF. That's such a shame, I think it'd be hard too add, but I'm not sure enough of this.
This one's a relief! But I guess the line limitation will be a problem in certain parts, like equip (short for equipment) and WpnMat (short for weapon material). If I remember well these system message had a hardcoded space available. Could it be changed in the near future? It's not a priority but I just wanted to know.
But very informative! Thank you Earth A few things:
So the stylized text has the same amount of characters right? that hasn't changed?
I see, so you found another way to implement ascii instead of the usual, ASM hacking. Now I know what you meant about the VWF. That's such a shame, I think it'd be hard too add, but I'm not sure enough of this.
This one's a relief! But I guess the line limitation will be a problem in certain parts, like equip (short for equipment) and WpnMat (short for weapon material). If I remember well these system message had a hardcoded space available. Could it be changed in the near future? It's not a priority but I just wanted to know.
Will this limitation be a problem, knowing that the english script will perhaps be a bit longer?
That's quite the message!
A few things:
So the stylized text has the same amount of characters right? that hasn't changed?
I see, so you found another way to implement ascii instead of the usual, ASM hacking. Now I know what you meant about the VWF. That's such a shame, I think it'd be hard too add, but I'm not sure enough of this.
This one's a relief! But I guess the line limitation will be a problem in certain parts, like equip (short for equipment) and WpnMat (short for weapon material). If I remember well these system message had a hardcoded space available. Could it be changed in the near future? It's not a priority but I just wanted to know.
Will this limitation be a problem, knowing that the english script will perhaps be a bit longer?
As mentioned my changes affect all types of text equally. It's about the same limit.
Yeah, VWF would need to tackle the areas I avoided. So I won't be the one doing it, nether it think it is really needed, for me 36 char per line is a good number.
I think the strings like weapon material can be solved using the 24x12 bitmap trick we used previously. When We have the insertion tool working I'll take a look a that again.
It is not like we have more space, it is still 36 per line, it is more like we are able to pack our text better.
Similar threads
-
@
SylverReZ:
@Veho, Sounds and smells like bullshit. They don't give you cancer, and California should know that. I don't get why they stick labels that say "may or may not cause reproductive harm or cancer". -
-
-
-
-
-
-
-
-
@
Psionic Roshambo:
Mame should be two sets one for preservation of everything and one set for people who just want to play and enjoy the old old ganes -
-
-
-
@
SylverReZ:
@Psionic Roshambo, Believe Japan was going to make it legal at some point, according to a Kotaku story.+1
-
@
Psionic Roshambo:
I swear like 99% of arcade games wouldn't even exist these days outside of MAME the arcade machines are old and busted very few ever saw any sort of home conversion
-
-
@
SylverReZ:
@Psionic Roshambo, There's a lot of obscure Japanese arcade titles that are either lost to time or dumped.+1
-
-
@
Psionic Roshambo:
I mean if a company could use AI to do the work of a home conversion for essentially free why not? The rights for some games are completely lost though
-
-
-
-
-
-
