Summon Night Swordcraft Story: Beginnings Stone

Discussion in 'GBA - Game Development, ROM Hacks and Translations' started by Pablitox, Jun 1, 2015.

  1. kirito1215

    kirito1215 GBAtemp Regular

    Member
    169
    35
    May 15, 2016
    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
     
    mikeprado30 likes this.
  2. Pablitox
    OP

    Pablitox GBAtemp Advanced Fan

    Member
    764
    404
    Oct 18, 2011
    Argentina
    We use crystaltile for the graphics of the game. The rest are custom-made tools.
     
    kirito1215 likes this.
  3. EdenLegaia

    EdenLegaia Member

    Newcomer
    17
    13
    Oct 1, 2013
    France
    Oh wow, each progress makes me even more impatient to finally play it in english.
    You guys rock!
     
    Pablitox likes this.
  4. Pablitox
    OP

    Pablitox GBAtemp Advanced Fan

    Member
    764
    404
    Oct 18, 2011
    Argentina
    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:



    [​IMG]

    [​IMG]

    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, Feb 14, 2018 at 12:27 PM
  5. Lizari Drakiby

    Lizari Drakiby Member

    Newcomer
    38
    36
    Apr 8, 2016
    Mexico
    San luis potosi
    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 ^ - ^
     
  6. kirito1215

    kirito1215 GBAtemp Regular

    Member
    169
    35
    May 15, 2016
    What's the 8 at the end of ritchburn? and will the final product support Mulitplayer?
     
  7. Pablitox
    OP

    Pablitox GBAtemp Advanced Fan

    Member
    764
    404
    Oct 18, 2011
    Argentina
    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.
     
  8. kirito1215

    kirito1215 GBAtemp Regular

    Member
    169
    35
    May 15, 2016
    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?
     
  9. Pablitox
    OP

    Pablitox GBAtemp Advanced Fan

    Member
    764
    404
    Oct 18, 2011
    Argentina
    encoders? don't you mean proofreader?

    I don't remember Anniethegamer really :/
     
    kirito1215 likes this.
  10. Jayro

    Jayro MediCat USB and Mini Windows 10 Developer

    Member
    GBAtemp Patron
    Jayro is a Patron of GBAtemp and is helping us stay independent!

    Our Patreon
    5,482
    3,111
    Jul 23, 2012
    United States
    Octo Canyon
    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.
     
  11. Pablitox
    OP

    Pablitox GBAtemp Advanced Fan

    Member
    764
    404
    Oct 18, 2011
    Argentina
    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.
     
    Jayro likes this.
  12. Shadow#1

    Shadow#1 Wii & 3DS Softmod Expert

    Member
    4,338
    1,244
    Nov 21, 2005
    United States
    Nice keep up the good work guys
     
  13. Jayro

    Jayro MediCat USB and Mini Windows 10 Developer

    Member
    GBAtemp Patron
    Jayro is a Patron of GBAtemp and is helping us stay independent!

    Our Patreon
    5,482
    3,111
    Jul 23, 2012
    United States
    Octo Canyon
    Sounds great, glad you guys are still rocking away! :grog:
     
  14. Mylon_The_Cat

    Mylon_The_Cat Newbie

    Newcomer
    3
    1
    Oct 31, 2017
    United States
    We're almost there, hopefully. Holy jeez, how long has it been since this project started again?
     
    Pablitox likes this.
  15. Pablitox
    OP

    Pablitox GBAtemp Advanced Fan

    Member
    764
    404
    Oct 18, 2011
    Argentina
    More than ten years ago If I'm not mistaken!
     
    zfreeman and Jayro like this.
  16. Jayro

    Jayro MediCat USB and Mini Windows 10 Developer

    Member
    GBAtemp Patron
    Jayro is a Patron of GBAtemp and is helping us stay independent!

    Our Patreon
    5,482
    3,111
    Jul 23, 2012
    United States
    Octo Canyon
    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. ^^;
     
    EarthDarkness likes this.
  17. EarthDarkness

    EarthDarkness Member

    Newcomer
    14
    45
    May 29, 2015
    United States
    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.
     
    Pablitox likes this.
  18. Pablitox
    OP

    Pablitox GBAtemp Advanced Fan

    Member
    764
    404
    Oct 18, 2011
    Argentina
    That's quite the message! :blink: 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?
     
  19. EarthDarkness

    EarthDarkness Member

    Newcomer
    14
    45
    May 29, 2015
    United States
    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.
     
    Dodain47 likes this.
  20. Fishmalk

    Fishmalk Newbie

    Newcomer
    8
    0
    Feb 12, 2018
    United States
    Just wanted to add to the chorus that I am very grateful for everyone's work in finally completing this project.