Thanks both of you for the tips
I am going to put them to work and share what I find out (it will take me a while, not the fastest guy but I have neither a deadline hehe
The left panel in your screenshot says it's parsing as 4bpp, not 2bpp. But I don't know this program. It could be lying.
My bad, I miswrote 2bpp instead of 4bpp; later, when I edited to add the image, I didn't notice the typo EDIT 18/Apr/2020:
Just sharing what I found out so far:
• First I opened the translation IPS I have (Lukas' one in SPanish and Hexagon's one in Portuguese); just readed how many lines have each one and calculate difference:
B090 - A920 = 770 bytes (1904 in binary); this may be the maximum size of the tiles modifications.
• I noticed Lukas save space translating just a few names, whilst Hexagon do a complete name translation:
(I know both Spanish and Portuguese so is easy to spot the translated names in both languages)
What I deduce from this is that 770 (1904) includes these translations, so the tile modifications are smaller.
• After reading both files I am sure both are vastly just translation, so I focus in the first part of Hexagon's IPS, that is the only great area that looks different:
I am pretty sure, with all the stated, taht this is where the tiles I am looking for are stored.
Since the Portuguese patch is good, use it to identify which parts of the ROM are relevant and narrow your search to those and vicinity. The first few areas touched by the Portuguese patch are:
$002fc8, $000e bytes
$00310f, $000a bytes
$0032f2, $0020 bytes
If I understood you right (I repeat, I have not studied properly programation, just learning by doing) the first lines of the Portuguese IPS (the lines I think are the ones I am looking for) modify Arcana's ROM in spot $002fc8 for 0e (14) bytes; $00310f for 0a (10) bytes; and $0032f2 for 20 (32) bytes, is this right? Sorry if I misunderstood.
Anyway, with this in mind, I firstly made a copy of Arcana (U) (the original ROM) and applied the Portuguese patch, calling it Arcana (P); I also run it to check it did the job fine. And so, I opened both (U) and (P), and went to $002fc8 in both and check if there where any changes...
I found something! At first they looked similar to me, but there is code changed above $002fc8, specificaly line $002f10 for 8 bytes:
Is better in $00310f, where the changes are around this byte:
Now I am not sure what to do next; surely I will run the game in bsnes-accuracy (runs the game 30fps instead of 60fps) and check VRAM, to follow what happens with text loaded and when is unloaded, or what...
This, however, will be later; but I wanted to share what I feel is (imo) a huge improve
Thanks for the tips, have a nice day ^_^EDIT 19/Apr/2020:
• Using bsnes-accuracy I see the letters are displayed in BG3; not only that, they are being writen as they are displayed, AND being removed from BG3 as they disappear from screen; so I believe this is what you @Raeven0 were meaning with "time-wasting wizardry like manually writing a tilemap"
. Also, if this info helps, it is better visible in 2bpp than 4bpp in VRAM.
• Also, names like EFRITE and DARWIN with other letters are loaded in BG1 (4bpp) even if none of these names are displayed on screen.
Unfortunately, I am unable to continue since I do really not understand the debugger and what to do with (or where to focus in) the million commands that are being run every frame...
And now, the meaning of why I upload:
• I decided to open the .smc in HxD, locate where the intro text is stored in ROM and modify it with values from 20 to EF and check what is displayed in screen.
Changing with values 21 to EF (respecting the first "E" as a reference, and the hex values "0D" that seems to be jump of line):
(notice that all that text is not displayed at the same time, I modified the image to show the total length; the real final screen just show this length):
I did this for mainly two reasons:
1) Knowing exactly the tiles that are already converted in Portuguese letters (this is, which ones have been modified); they are:
2a -- from * to ã
3c -- from < to í
57 -- from W to ó
58 -- from X to ê
6b -- from k to ç
67 -- from w to á
69 -- from y to é
2) The other reason was to, if not crashing, display what non-commonly values (like 80, 90, A0 and so on) would display on screen; just curious to think if this can help to spot this glitchy graphics in the ROM if I use the 2bpp codec (since BG3 seems to use it) or not at all.
Anyway, I noticed the numbers from 2 to 8 (the ones in the first line) have a similar width, specifically 8 pixels (or 9, if the space between graphics is included), so applying what I learned in the PDF of Pablo Muñóz I did a search in hex of the values "080808080808" (and after it "090909090909"), in order to find where in ROM is stored the VWF.
It worked! searching "090909090909" I spoted an area with similar values, and finally deduced this being the VWF, starting in $002c34 with the values 04 05 05(this being the width of the space, the ! and the " symbols respectively)
So, in order to be sure, I changed the value I deduced was for the ã (0A) and changed for the one I believe fited better for the symbol size (07), saved and...
So, knowing this information, is it possible to use it to trace where in the ROM are stored the propper tiles that the values in the area $002c34 onwards modify? They must be close, and thinking about it this is pretty close to the $002fc8 that the Portuguese patch start to touch (and the $002f10 I also spoted the ROM really changes)
Also, maybe it is possible to take advantage of values 23, 24, 25, 26, 3d, and 40 (#, $, %, &, = and @) since they do not display any graphic, and store there the tiles I want to create.
So far I am quite happy with the improvements, even if I am just walking around what I really want (modify the propper tiles, not just spot them in ROM).
Have a nice day.