-
Notifications
You must be signed in to change notification settings - Fork 3
/
Copy pathWMSave.txt
74 lines (57 loc) · 3.29 KB
/
WMSave.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
WM data is at FE8U:03005280 and is layed out as follows:
+00 | byte | flags
+01 | byte | "display cursor"?
+02 | short | camera x (in what units?)
+04 | short | camera y (in what units?)
+08 | word | cursor x (pixels, increments by 0x10)
+0C | word | cursor y (pixels, increments by 0x10)
+10 | units[7], struct:
+00 | byte | flags (&1 = enabled?, &2 = use class instead of char)
+01 | byte | location id
+02 | short | character/class id
+30 | nodes[0x1C], struct:
+00 | word | flags (&1 = enabled, &2 = is next story location)
+A4 | byte[0x20] | enabled paths
+C4 | word | path count
+C8 | byte | entry node id?
+C9 | byte[3] | List of active world map skirmishes
+CC | byte | used to determine which skirmish enemy block to load
+CD | byte | used for shops on the world map
Flags at byte 00:
&01h = set if currently on world map (used with shop screens and item management screens to determine where to kick the player back to when backing out)
&02h = enable player control (unset when moving to the next story location and the cutscene plays)
&04h = minimap enabled (press Select to toggle)
&08h = hide map sprites
&10h = when set, moves the minimap to right of screen instead of left (used so that the minimap doesn't overlap the cursor, automatically set by the MoveCursor functions)
&20h = unknown
&40h = set by EventC1_SkipWM, probably skips drawing world map
&80h = unknown, set by EventC2_
Nodes are saved as words, but only 2 bits are ever used. You could restructure these to be saved as shorts or even bytes with no ill effects, simply by changing the arguments of a few `lsl` and `add` opcodes.
referencing FE8U:080A70B0 ("SaveWMStuff"), load func is FE8U:080A7138 ("LoadWMStuff")
saves 0x24 bytes (writes to sp before calling the save writing function)
bytes 0x00 to 0x07 are location/node data:
080A6DA0 saves for each location/node two bits of info, packed
Since there's room for 0x1C nodes, this means 0x38 bits = 7 bytes are used (one unused?)
load func is 080A6E24
bytes 0x08 to 0x0B are route/path data:
080A6EB0 saves a bitmap. Each bit represents a route id.
for ex: if route 2 and 3 are active, it will save (binary) 0...0110
there's 4 bytes, so max route id is 32
load func is 080A6F0C
bytes 0x0C to 0x19 are actor/unit data: (this is what's at 03005280+$10)
080A6F50 saves for each actor/unit a short (2 bytes), packed as follows:
+00bit | 1bit | flag 0 at actor+00 (enabled?)
+01bit | 6bit | location/node (actor+01)
+07bit | 1bit | flag 1 at actor+00 (use class instead of char)
+08bit | 8bit | character or class id (actor+02)
there's 14 bytes for 7 actors/units
load func is 080A6FBC
bytes 0x1A and 0x1B are saved cursor x and y, respectively
byte 0x1C is as follows:
+00bit | 1bit | flag 1 (&2) of data+00
+01bit | 1bit | flag 2 (&4) of data+00
+02bit | 2bit | flags 4&5 (&0x30) of data+00
I think, math is hard (I'm referencing 080A70F0~080A7124 if u don't trust me (you shouldn't))
bytes 0x1D to 0x1F is the skirmish array at data+C9, copied verbatim (func 080A7034 saves, 080A7054 loads)
byte 0x20 is skirmish state byte at data+CC copied verbatim
the last 3 bytes seem unused (padding?)