Zeldix Magic

Page 7 of 8 Previous  1, 2, 3, 4, 5, 6, 7, 8  Next

View previous topic View next topic Go down

Re: Zeldix Magic

Post by Trovsky on 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.

Trovsky
                             
                             

Since : 2014-04-10

Back to top Go down

Re: Zeldix Magic

Post by Puzzledude on 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.

Puzzledude
   
   

Since : 2012-06-20

Back to top Go down

Re: Zeldix Magic

Post by Trovsky on 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.

Trovsky
                             
                             

Since : 2014-04-10

Back to top Go down

Re: Zeldix Magic

Post by Puzzledude on 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.


Last edited by Puzzledude on Wed 22 Feb 2017 - 12:02; edited 1 time in total

Puzzledude
   
   

Since : 2012-06-20

Back to top Go down

Re: Zeldix Magic

Post by Puzzledude on 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
***********************************

Puzzledude
   
   

Since : 2012-06-20

Back to top Go down

Re: Zeldix Magic

Post by zarby89 on 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

zarby89
Rank: Bee
Rank: Bee

Since : 2016-10-30

Back to top Go down

Re: Zeldix Magic

Post by Trovsky on Thu 23 Feb 2017 - 14:53

Thank you, both of you!

Trovsky
                             
                             

Since : 2014-04-10

Back to top Go down

Re: Zeldix Magic

Post by Trovsky on 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.

Trovsky
                             
                             

Since : 2014-04-10

Back to top Go down

Re: Zeldix Magic

Post by Trovsky on 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.

Trovsky
                             
                             

Since : 2014-04-10

Back to top Go down

Re: Zeldix Magic

Post by Euclid on 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.
avatar
Euclid
                        
                        

Since : 2012-06-21

Back to top Go down

Re: Zeldix Magic

Post by Trovsky on 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.

Trovsky
                             
                             

Since : 2014-04-10

Back to top Go down

Re: Zeldix Magic

Post by Euclid on 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=
avatar
Euclid
                        
                        

Since : 2012-06-21

Back to top Go down

Re: Zeldix Magic

Post by Trovsky on Fri 10 Mar 2017 - 9:09

Thanks for this.

Trovsky
                             
                             

Since : 2014-04-10

Back to top Go down

Re: Zeldix Magic

Post by Puzzledude on 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


Puzzledude
   
   

Since : 2012-06-20

Back to top Go down

Re: Zeldix Magic

Post by Trovsky on 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.

Trovsky
                             
                             

Since : 2014-04-10

Back to top Go down

Re: Zeldix Magic

Post by Trovsky on 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

Trovsky
                             
                             

Since : 2014-04-10

Back to top Go down

Re: Zeldix Magic

Post by Puzzledude on 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.

Puzzledude
   
   

Since : 2012-06-20

Back to top Go down

Re: Zeldix Magic

Post by Trovsky on 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

Trovsky
                             
                             

Since : 2014-04-10

Back to top Go down

Re: Zeldix Magic

Post by Trovsky on 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.

Trovsky
                             
                             

Since : 2014-04-10

Back to top Go down

Re: Zeldix Magic

Post by Trovsky on Mon 13 Mar 2017 - 12:39

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



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.

Trovsky
                             
                             

Since : 2014-04-10

Back to top Go down

Re: Zeldix Magic

Post by Trovsky on 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.

Trovsky
                             
                             

Since : 2014-04-10

Back to top Go down

Re: Zeldix Magic

Post by Euclid on 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.
avatar
Euclid
                        
                        

Since : 2012-06-21

Back to top Go down

Re: Zeldix Magic

Post by Euclid on 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.
avatar
Euclid
                        
                        

Since : 2012-06-21

Back to top Go down

Re: Zeldix Magic

Post by Trovsky on 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.

Trovsky
                             
                             

Since : 2014-04-10

Back to top Go down

Re: Zeldix Magic

Post by Trovsky on 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.



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.

Trovsky
                             
                             

Since : 2014-04-10

Back to top Go down

Page 7 of 8 Previous  1, 2, 3, 4, 5, 6, 7, 8  Next

View previous topic View next topic Back to top


 
Permissions in this forum:
You cannot reply to topics in this forum