Re: Zeldix Magic

by Mr.x Tue 21 Feb 2017 - 3:13

Update! You can now read compressed graphics in the GUI. I merged the compressed and uncompressed graphics windows into one, just use the checkbox to switch between the two modes. I have plans to let you easily scroll through the compressed data.

@Zarby Now that I implemented your decompression code, how do you feel about doing compression code?

@Everyone It would be nice to know the pointers for the graphics. For example, what if I want to move the graphic data for the dungeon doors? What pointers do I have to modify?

Side note: There's a bug with the palette in NES 2BPP mode. It's trivial.

by **Puzzledude** Tue 21 Feb 2017 - 6:24

I must ask you all, how do you feel about these minor updates? I just like to keep you all informed. Should I only announce major comits?

I think any update is welcome.

@Everyone It would be nice to know the pointers for the graphics. For example, what if I want to move the graphic data for the dungeon doors? What pointers do I have to modify?

Unfortunately it seems that the game will not allow moving GFX data at all. If you move the GFX, it will make display bugs for some unknown reason.

Otherwise if you want to know, you can recompress the data back into the Rom with zcompress, while not selecting 87200 (hwhich is 87000 if no header) but for instance 187200 (while having a 2MB Rom). When you then hex compare, you can see all pointers for gfx at around 17000 onward, having around 2000 block in hex. Not sure if this can be separated at all, as it seems the entire gfx is modified with all pointers even if you just change 1 dot in the gfx using YYchr.

So basically the zcompress does it correctly, but then you can clearly see gfx problems if any other address but 87200 is selected.

by Mr.x Tue 21 Feb 2017 - 21:14

Puzzledude wrote:Unfortunately it seems that the game will not allow moving GFX data at all. If you move the GFX, it will make display bugs for some unknown reason.
[...]
So basically the zcompress does it correctly, but then you can clearly see gfx problems if any other address but 87200 is selected.

If you find the cause or make a patch to allow moving beyond 0x87200, inform me, I'll try to add support. I'm more curious about the pointers when compressing modified graphics back into the ROM. I suppose reverse engineering zcompress is the best way at this point. Thank you for the tip.

by **Puzzledude** Wed 22 Feb 2017 - 11:58

I'm more curious about the pointers when compressing modified graphics back into the ROM. I suppose reverse engineering zcompress is the best way at this point. Thank you for the tip.

To give you a clue (achieved with hex comparing):
seems like the pointers for GFX start at 004F80 and go to 00521C, at least this section was changed when zcompressing back and forth. However this is for all the GFX.

by **Puzzledude** Wed 22 Feb 2017 - 12:00

Doh,... this is from MoN's ROM map:
he calls this "table" don't know why, as these are pointers. Also not sure what 29Dh is for size.

***********************************
$4FF3-$528F - indexed (long) table to compressed graphics packets

size = 29Dh

Each of these packets is treated differently:

$0A - Dungeon sprite
***********************************

by **zarby89** Wed 22 Feb 2017 - 15:51

Puzzledude wrote:Doh,... this is from MoN's ROM map:
he calls this "table" don't know why, as these are pointers. Also not sure what 29Dh is for size.

they are the pointers "interlaced" of all gfx in the game in order and they can be changed to put an higher value to have gfx in bank 20+ , all pointers return a bunch of compressed gfx tiles of 8x8 (64 tiles) the 29D size is the lenght total of the pointers divide it by 3 because they are LONG to get numbers of pointers total : 223(decimal)

For the compression code you should look at smallhacker code i don't plan on doing compression code
https://github.com/Smallhacker/TerraCompress/blob/master/src/Lz2.cs

what you'll have to do is what ZCompress is doing recompress all the gfx and assign them new pointers or you'll overwrite current existing data of the next gfx block

by Mr.x Thu 23 Feb 2017 - 14:53

Thank you, both of you!

by Mr.x Tue 28 Feb 2017 - 1:48

Thanks to zarby and puzzledude's help you can now navigate through all the compressed graphics. I am noticing that some are giving me errors regardless of the BPP format I select.

The dungeon palettes (the palette selections for 3BPP mode in Zeldix Magic) may or may not be displaying correctly. Nintendo decided it was a good idea to have a white palette in the middle of the dungeon palettes for some reason, so I have no idea how I am to interpret the dungeon palettes.

For what it's worth, I am still using zarby's decompression code, I never got smallhacker's decompression code to work for me. I never tested smallhacker's compression code.

by Mr.x Thu 9 Mar 2017 - 8:28

I'm in the progress of creating the indexed bitmap creator. I've been a bit busy, but it has made progress.

by **Euclid** Fri 10 Mar 2017 - 6:36

Sorry having been paying too much attention to threads too much, do you still need help on these?

Monologue dictionary pointers
Credits text pointers

I'm not too sure how you guys are coding this thing at the moment - do you guys mind rewriting the game engine (i.e. rewrite some of the assembly to achieve the same result) so the above is like 10x easier to edit? The only downside is needing extra space in the rom.

by Mr.x Fri 10 Mar 2017 - 8:04

Euclid wrote:Sorry having been paying too much attention to threads too much, do you still need help on these?

Monologue dictionary pointers
Credits text pointers

Yeah, I just don't know the locations. If you could provide both, that'd make me happy.

Euclid wrote:
I'm not too sure how you guys are coding this thing at the moment - do you guys mind rewriting the game engine (i.e. rewrite some of the assembly to achieve the same result) so the above is like 10x easier to edit? The only downside is needing extra space in the rom.

I sort of do mind. I'm admittedly a purist when it comes to this, but I'd rather not replace code in the ROM to make editing easier.

by **Euclid** Fri 10 Mar 2017 - 9:03

Dictionary I'll go through a bit later, I don't actually have the offset with me handy so I'll have to dig it up for you. It's a lot easier than you expect.

The biggest issue you'll have to deal with on the credits are the hardcoded lines like the death counts, there's custom ASM to state, between lines X and Y, execute this code, the code will check what line you're on and write the top half and bottom half of death count numbers as an example.

If you're not too fussed about changing the actual lines, but just changing the text before that, then it should be ok - that's something to keep in mind.

Here's my notes from PW, addresses are hex addreses (unheadered I believe):

Code:: text start 74150: (THE RETURN OF THE KING, HYRULE CASTLE). Not compressed, not dictionary-ed can be edited with a appropriate table file. 7337A (EXECUTIVE PRODUCER) Layout: 73B3D onwards. Pointers to starting addrs, length captured in the format, can double dip line if text matches. 7338F (HIROSHI YAMAUCHI) (top half of the letter) 733A1 (HIROSHI YAMAUCHI) (bottom half of the letter) Format: <8 bytes> - how much to shift right from the left of the screen <8 bytes, LENGTH> determines length by this formula - (byte + 1) >> 1, then it'll load the next <number> of letters into the "buffer" <text> FF is end of string, each line should end with this, can be in the middle of the line but anything past the length will be loaded into the ram and not displayed (waste of CPU cycles)

Byte to letter map:

Code:: REDISH TEXT 00=A 01=B 02=C 03=D 04=E 05=F 06=G 07=H 08=I 09=J 0A=K 0B=L 0C=M 0D=N 0E=O 0F=P 10=Q 11=R 12=S 13=T 14=U 15=V 16=W 17=X 18=Y 19=Z GOLDISH TEXT 1A=A 1B=B 1C=C 1D=D 1E=E 1F=F 20=G 21=H 22=I 23=J 24=K 25=L 26=M 27=N 28=O 29=P 2A=Q 2B=R 2C=S 2D=T 2E=U 2F=V 30=W 31=X 32=Y 33=Z 35=' 36=- 37=. GREEN TEXT 38=A 39=B 3A=C 3B=D 3C=E 3D=F 3E=G 3F=H 40=I 41=J 42=K 43=L 44=M 45=N 46=O 47=P 48=Q 49=R 4A=S 4B=T 4C=U 4D=V 4E=W 4F=X 50=Y 51=Z 52=. UPPER HALF WHITE TEXT 53=0 54=1 55=2 56=3 57=4 58=5 59=6 5A=7 5B=8 5C=9 5D=a 5E=b 5F=c 60=d 61=e 62=f 63=g 64=h 65=i 66=j 67=k 68=l 69=m 6A=n 6B=o 6C=p 6D=q 6E=r 6F=s 70=t 71=u 72=v 73=w 74=x 75=y 76=z 77=' 78=| LOWER HALF WHITE TEXT 79=0 7A=1 7B=2 7C=3 7D=4 7E=5 7F=6 80=7 81=8 82=9 83=a 84=b 85=c 86=d 87=e 88=f 89=g 8A=h 8B=i 8C=j 8D=k 8E=l 8F=m 90=n 91=o 92=p 93=q 94=r 95=s 96=t 97=u 98=v 99=w 9A=x 9B=y 9C=z 9D=' 9E=, 9F=

by Mr.x Fri 10 Mar 2017 - 9:09

Thanks for this.

by **Puzzledude** Fri 10 Mar 2017 - 9:48

Reminds me of this document I wrote for some reason:

Code:: *ENDING SEQUENCE* 1.) FIRST PART correct values (found by PuzzleDude) NO HEADER WITH HEADER Ganon entrance to 15E26 = 89 16026 = 89 the triforce shrine 15E27 = 01 16027 = 01 (HM destroys this all the time) GFX in triforce shrine 15E76 = 88 16076 = 88 15F14 = 00 16114 = 00 scroll up-down 15FB1 = 00 161B1 = 00 in triforce shrine 15FB2 = 00 161B2 = 00 scroll left-right 1604F = 00 1624F = 00 in triforce shrine 2.)A) SECOND PART TEXT EXAMPLE: First text is: the return of the king (small text) HYRULE CASTLE (BIG TEXT) Go to WinHex32, go to relative search and type: return, it will tell you, that the return is 2B 1E 2D 2E 2B 27 THE RETURN... = 2D 21 1E 9F 2B 1E 2D 2E 2B 27 ... now you have the location Go to WinHex32, go to relative search and type: Castle it will tell you, that the castle is 5F 5D 6F 70 68 61 and 85 83 95 96 8E 87 now you have the locations ----------- ALPHABET SMALL TEXT COLOUR1 SMALL TEXT COLOUR2 SMALL TEXT COLOUR3 A=1A A=38 A=00 B=1B B=39 B=01 C=1C C=3A C=02 D=1D D=3B D=03 E=1E E=3C E=04 F=1F F=3D F=05 G=20 G=3E G=06 H=21 H=3F H=07 I=22 I=40 I=08 J=23 J=41 J=09 K=24 K=42 K=0A L=25 L=43 L=0B M=26 M=44 M=0C N=27 N=45 N=0D O=28 O=46 O=0E P=29 P=47 P=0F Q=2A Q=48 Q=10 R=2B R=49 R=11 S=2C S=4A S=12 T=2D T=4B T=13 U=2E U=4C U=14 V=2F V=4D V=15 W=30 W=4E W=16 X=31 X=4F X=17 Y=32 Y=50 Y=18 Z=33 Z=51 Z=19 APOSTROPH=34 EMPTY=9F EMPTY=9F EMPTY=9F BIG TEXT (2 VALUES, UPPER ROW, LOWER ROW, BUT UPPER ROW ALWAYS TOGETHER AND LOWER ROW ALWAYS TOGETHER) UP LOW A=5D, 83 B=5E, 84 C=5F, 85 D=60, 86 E=61, 87 F=62, 88 G=63, 89 H=64, 8A I=65, 8B J=66, 8C K=67, 8D L=68, 8E M=69, 8F N=6A, 90 O=6B, 91 P=6C, 92 Q=6D, 93 R=6E, 94 S=6F, 95 T=70, 96 U=71, 97 V=72, 98 W=73, 99 X=74, 9A Y=75, 9B Z=76, 9C EMPTY= 9F ----------- Lets say you want to change: the return of the king (22 letters) to this: the evil is vanishing (21 letters) 22 is 21+1 With relative search find the starting byte and replace the 22 old bytes with this: 2D 21 1E, 9F, 1E 2F 22 25, 9F, 22 2C, 9F, 2F 1A 27 22 2C 21 22 27 29, 9F ----------- Lets say you want to change: HYRULE CASTLE (13 letters) to this: DARK TEMPLE (11 letters) 13 is 1+11+1 (first and second value must be empty because of the centering) With relative search find the starting byte of the First row and replace the 13 old bytes with this: 9F, 60 5D 6E 67, 9F, 70 61 69 6C 68 61, 9F With relative search find the starting byte of the Second row and replace the 13 old bytes with this: 9F, 86 83 94 8D, 9F, 96 87 8F 92 8E 87, 9F 2.)B) SECOND PART, SPECIAL EXITS (found by PuzzleDude) (this is not the door but the location of the frames of the ending) 01.) EXIT 1000 (place it in big area, lower middle position of the exit, picture travels up, place it so that the sprites are not seen) 02.) room 18 (automatic) 03.) EXIT 1002 (place it in big area, upper right, travels down and left) 04.) EXIT 1012 (big area, lower middle, travels up) 05.) EXIT 1004 (big area, middle up, travels down) 06.) EXIT 1006 (small area, upper right, travels down left) 07.) EXIT 1010 (big area = zora domain, upper left, travels right) 08.) EXIT 1014 (small area, upper middle, travels down) 09.) EXIT 100A (small area, middle right, travels left) 10.) EXIT 1016 (big area, middle low, travels up) 11.) room 277 (must be fountain, automatic) 12.) toom 289 (must be smith, automatic) 13.) EXIT 100E (big area, upper left, travels right) 14.) EXIT 1008 (big area, upper right, travels left) 15.) EXIT 1018 (big area, upper left, travels down right) 16.) EXIT 0180 (master sword, automatic) ps = exit of the small area can be placed in a big area to avoid the sprites Texts: 01.) the return of the king, HYRULE CASTLE 02.) the loyal sage, SANCTUARY 03.) sahasrahla's homecoming, KAKARIKO TOWN 04.) vultures rule the desert, DESERT PALACE 05.) the bully makes a friend, DEATH MOUNTAIN 06.) your uncle recovers, YOUR HOUSE 07.) flippers for sale, ZORA'S WATERFALL 08.) the witch and assistant, MAGIC SHOP 09.) twin lumberjacks, WOODSMEN'S HUT 10.) flute boy plays again, HOUNTED GROVE 11.) venus. queen of faeries, WISHING WELL 12.) the dwarven swordsmiths, SMITHERY 13.) the bug-catching kid, KAKARIKO TOWN 14.) the lost old man, DEATH MOUNTAIN 15.) the forest thief, LOST WOODS 16.) and the master sword, sleeps again..., FOREVER 3.) THIRD PART, CREDITS AND DUNGEON NAMES (all editable in hex) Some things to type in the relative search, because they are are subject to change -executive producer - HIROSHI YAMAUCHI -producer - SHIGERU MIYAMOTO -director - TAKASHI TEZUKA -script writer - KENSUKE TANABE -assistant directors - YASUHISA YAMAMURA, YOICHI YAMADA -QUEST HISTORY -castle of hyrule -castle dungeon -east palace -desert palace -mountain tower -level 1 DARK PALACE -level 2 SWAMP PALACE -level 3 SKULL WOODS -level 4 THIEVES' TOWN -level 5 ICE PALACE -level 6 MISERY MIRE -level 7 TURTLE ROCK -level 8 GANON'S TOWER

by Mr.x Fri 10 Mar 2017 - 10:19

Thanks Puzzledude. The ending sequence is very different from the monologues that I think it would require a different editor window with new code. I would probably have the ability to edit the text like the monologue editor but then have another control area to set the colors.

Here's a primitive mockup:

Edit text: [T  E  X  T  G  O  E  S     H  E  R  E]
Color:     [r][r][r][r][r][g][g][g][g][g][g][g][g]

There's a textbox for each character. The user's cursor "tabs" to the next textbox once a character is typed. A color box is underneath each character. Clicking the color box cycles through different colors.

Also in the back of mind, I'm thinking of a preview graphic that displays how the graphics look like in the game. The window would need to be displayed. I could hardcode the hex values for the textbox unless someone has the specific tile attributes for the game's textbox.

I'll be open and say that the project hasn't had much progress because I'm busy in real life.

by Mr.x Fri 10 Mar 2017 - 11:27

I did it... I created an indexed 8BPP bitmap. I wish I found this stackoverflow post earlier, unfortunately the title doesn't advertise that it allows to write to indexed formats.

https://stackoverflow.com/questions/6782489/create-bitmap-from-a-byte-array-of-pixel-data

by **Puzzledude** Fri 10 Mar 2017 - 12:21

I created an indexed 8BPP bitmap.

Nice. I'm guessing you need this for gfx editing. Not sure why it is 8BPP though (instead of 4BPP).

The ending sequence is very different from the monologues that I think it would require a different editor window with new code.

Yes, it is. Until now this was possible only in hex.

by Mr.x Fri 10 Mar 2017 - 12:39

Puzzledude wrote:
I created an indexed 8BPP bitmap.
Nice. I'm guessing you need this for gfx editing. Not sure why it is 8BPP though (instead of 4BPP)

The difference between 4BPP and 8BPP is not just color but also the bytes per color, as far as I know. In general, the fewer bits you have, the fewer colors that are available.
https://en.wikipedia.org/wiki/List_of_monochrome_and_RGB_palettes#Regular_RGB_palettes

by Mr.x Sun 12 Mar 2017 - 12:01

Added partial multi-language support.
Fixed custom monologue read bug.
Indexed bitmaps are now made. This improves performance significantly.

by Mr.x Mon 13 Mar 2017 - 12:39

Here's what the graphics window looks like right now:

Zeldix Magic - Page 7 267ezh

Unfortunately, reading from an indexed bitmap is hard to figure out, Microsoft's badly coded classes aren't helping. Simply using the Bitmap's constructor to load a file yields a 32-bit non-indexed bitmap.

Importing indexed 8-bit bitmaps correctly needs to be done so you can write uncompressed and compressed graphics to the ROM. Suggestions are appreciated. I just need the pixel data stored in an array, that's it.

by Mr.x Mon 13 Mar 2017 - 17:15

Euclid wrote:Dictionary I'll go through a bit later, I don't actually have the offset with me handy so I'll have to dig it up for you. It's a lot easier than you expect.

The biggest issue you'll have to deal with on the credits are the hardcoded lines like the death counts, there's custom ASM to state, between lines X and Y, execute this code, the code will check what line you're on and write the top half and bottom half of death count numbers as an example.

If you're not too fussed about changing the actual lines, but just changing the text before that, then it should be ok - that's something to keep in mind.

Here's my notes from PW, addresses are hex addreses (unheadered I believe):

I checked it out. Apparently each string is separated by XX YY 00, where XX YY are any arbitrary values. I'm not sure what it does. The 00 could serve as a delimiter if it only wasn't for the fact that it's also the red letter "A". Because of this, I think I have to find out the address for each and every string but that's tedious to do.

Also the "The king" string starts at 0x72F50, with the American unheadered ROM. And the dictionary documentation would be very helpful.

by **Euclid** Tue 14 Mar 2017 - 3:38

its in my notes though i use bytes rather than bits

Format:

<8 bytes> - how much to shift right from the left of the screen

<8 bytes, LENGTH>
determines length by this formula -
(byte + 1) >> 1, then it'll load the next of letters into the "buffer"

8 bits shift and 16 bit length little endian.

Completely forgot about the dictionary I'll get to it when i get home.

by **Euclid** Tue 14 Mar 2017 - 7:12

Monologue Dictionary

If you encounter a hex value 88-EA, then it's a lookup from the dictionary. I'll use CPU addresses so convert them to file offsets yourself.

Technically if you hit 80-FF you're suppose to use the dictionary as per the assembly below, but hopefully nobody uses the invalid ranges as the code definitely doesn't support it! (do let me know if the lttp vanilla rom does it, because I should be able to trace the assembly if you tell me which monologue is doing it)

This code gets executed:

Code:: $8E/C50B B7 04 LDA [$04],y[$42:B101] A:7F7F X:0000 Y:0000 P:envMxdiZc $8E/C50D 30 21 BMI $21 [$C530] A:7F6B X:0000 Y:0000 P:envMxdizc $8E/C530 38 SEC A:008B X:000A Y:000B P:eNvMxdizc $8E/C531 E9 88 SBC #$88 A:008B X:000A Y:000B P:eNvMxdizC $8E/C533 20 DA C6 JSR $C6DA [$8E:C6DA] A:0003 X:000A Y:000B P:envMxdizC $8E/C6DA C2 30 REP #$30 A:0003 X:000A Y:000B P:envMxdizC $8E/C6DC EE DD 1C INC $1CDD [$8E:1CDD] A:0003 X:000A Y:000B P:envmxdizC $8E/C6DF AE D9 1C LDX $1CD9 [$8E:1CD9] A:0003 X:000A Y:000B P:envmxdizC $8E/C6E2 0A ASL A A:0003 X:000A Y:000B P:envmxdizC $8E/C6E3 29 FF 00 AND #$00FF A:0006 X:000A Y:000B P:envmxdizc $8E/C6E6 A8 TAY A:0006 X:000A Y:000B P:envmxdizc $8E/C6E7 B9 05 C7 LDA $C705,y[$8E:C70B] A:0006 X:000A Y:0006 P:envmxdizc $8E/C6EA 85 00 STA $00 [$00:0000] A:C7D3 X:000A Y:0006 P:eNvmxdizc $8E/C6EC B9 03 C7 LDA $C703,y[$8E:C709] A:C7D3 X:000A Y:0006 P:eNvmxdizc $8E/C6EF A8 TAY A:C7D0 X:000A Y:0006 P:eNvmxdizc $8E/C6F0 E2 20 SEP #$20 A:C7D0 X:000A Y:C7D0 P:eNvmxdizc $8E/C6F2 B9 00 00 LDA $0000,y[$8E:C7D0] A:C7D0 X:000A Y:C7D0 P:eNvMxdizc $8E/C6F5 9F 00 12 7F STA $7F1200,x[$7F:120A] A:C751 X:000A Y:C7D0 P:envMxdizc $8E/C6F9 E8 INX A:C751 X:000A Y:C7D0 P:envMxdizc $8E/C6FA C8 INY A:C751 X:000B Y:C7D0 P:envMxdizc $8E/C6FB C4 00 CPY $00 [$00:0000] A:C751 X:000B Y:C7D1 P:eNvMxdizc $8E/C6FD 90 F3 BCC $F3 [$C6F2] A:C751 X:000B Y:C7D1 P:eNvMxdizc $8E/C6FF 8E D9 1C STX $1CD9 [$8E:1CD9] A:C759 X:000D Y:C7D3 P:envMxdiZC $8E/C702 60 RTS A:C759 X:000D Y:C7D3 P:envMxdiZC

$8EC703 is where the 2 byte pointers are at. The end of the pointers (inclusive) is $8EC7C5, 2 byte pointers reference the same bank.

There's absolutely no separators and the code relies on reading the next pointer to determine when to finish reading "this dictionary entry", therefore the dictionary pointers and data must be sequentially written and each pointer must follow the previous.

Data starts after that @ $8EC7C7 (note also where the first value is pointed to) and ends at $8EC8D9 - I believe the text between there uses the same table reference as the monologue itself.

$8EC8D9 is also where other code starts so there's absolutely ZERO space for expansion here, so technically you should only read from this data not write unless someone's brave enough to replace some of the dictionary words to the same sizes.

PS: if there's anything else please ask - I have a tendency to forget stuff if not reminded these days Razz

- work takes priority over disassembling roms. I have a fair idea on music pointers but I would recommend against having a music editor as (most people agree) HM's music editor suck.

by Mr.x Tue 14 Mar 2017 - 11:16

Thank you very much!

Euclid wrote:I have a fair idea on music pointers but I would recommend against having a music editor as (most people agree) HM's music editor suck.

You mean you recommend for having a music editor? Alright, just provide the proper documentation.

by Mr.x Tue 14 Mar 2017 - 13:04

I looked at your document and the in the ROM and I don't understand it all. Here's an image of the hex and the corresponding characters. The image might be cutoff in the forum so try saving the image or something.

Zeldix Magic - Page 7 Ok0l5c

The people credits are on top and the text for the many screens is on the bottom.

Code:: <8 bytes> - how much to shift right from the left of the screen <8 bytes, LENGTH> determines length by this formula - (byte + 1) >> 1, then it'll load the next of letters into the "buffer"

In vanilla ALttP, the credits are separated by two bytes.

The text for the screens are separated by 4 and 8. For the the former, text related to a screen. For the latter, text related to different screens.