1) I, once again, was only able to test the GTC.exe file in the sub-folder 0_5_2_1, the setup.exe and GTC.application file both told me that the program was installed elsewhere and thus could not be executed. 2) In the Open Menu, you only can open .smc files. Please add .sfc files, because of the reasons I mentioned in my last bug report. Furthermore, the .sfc file ending gets more popular. 3) The Zoom is still titled "-1" to "4". Is it possible to change this to the correct percentage values in the info box? 4) The "Lower Layer" and "Upper Layer" stuff - is this renamed since the last time? I don't remember what the plan was with that caption. 5) The "Lower Layer" and "Upper Layer" stuff is for EDITING. I think it would make more sense if you use that option to the right in the map editor tab (to the right), since it looks like some option for viewing/hiding the layers if it is shown directly beneath the Map. Furthermore, that stuff isn't relevant for editing Events or the map properties, right? 6) If I edit a map and go on "Save Project", the "Save Map" button stays green. 7) Whats the point for editing the name under "Map Properties"? When I tested that for South Cape, it at least didn't change the name in the Map List to the left, if that is the planned function. 8) Again, if I edit the map, save the project, close the project, and open the project, the map is horribly butchered (as it can be seen here: https://twitter.com/pantalytron/status/1050074563239923713 ). 9) The New Project function only works on start up. When you already have opened a project - regardless if you close it or not! - there is that project's name with the entire path ("C:/...") in the textbox where you have to enter the new file name. After that, the new project file isn't properly/entirely generated. 10) If you create a new project when you already have an project opened, and you are in the map editing window, the window still shows the old map even after (unsuccessfully) creating a new project 11) If you edit Tilesets, you have a dropdown box to select "Palette Sets". In the Dropdown-Box, you have "Palette 1", "Palette 2" and so on. You should copy and paste that whole thing so it is "Palette Set 1", "Palette Set 2" and so on, since you distinguish between both, and here, you use one term for another. 12) At least on my PC, the program has a LONG loading time when changing the Zoom. Especially on 4 (500% zoom?), which I clicked on accidentally. 13) When I click on Map 19, it shows me the water layer of map 18?! As can be seen here: https://twitter.com/pantalytron/status/1050074607540195328 14) Clicking on Map 20 doesn't do anything, clicking on another map afterwards gets me some error messages in the message box, something of an Array Index out of bound.
And this is it, I'm excited to bugreport the next version, too! ^_~
1) The setup wants you to uninstall the old editor first. I'm not happy with this either maybe I can find a workaround.
2) Added .sfc files
3) I will change it to percent values
4) Renamed it to BG1 and BG2 layer acording to the filter options
5) You're right. I moved it to the map editor where it belongs ;)
6) Will be fixed for the next version
7) The name in the list is only for the internal map representation in the editor. The name in Map Properties is the name which is displayed in the game. Both names can be different though since they aren't connected in the editor.
8) 9) 10) Will be fixed for the next version
11) Renamed it everywhere to "Paletteset"
12) I will try to make the map loading more efficient. But not for the next version.
13) I'm familiar with this but couldn't figure out the reason yet
I've found the source of some of the corruption that happens when I export a ROM. Here are some notes.
1. GTC seems to be making some mistakes when parsing the table at $0d8000. This is the table that contains memory addresses of assets to load for each map. I can't see a pattern in the mistakes, so I can't guess about what kind of bug might cause them. Here are three examples:
(a) The title screen ($0daf30) contains the card "04 00 60 a0 00 12 df", so it should load a palette from $1f1200. GTC is setting the palette address to $1f11c0 instead. This causes the globe on the title screen to be all black. A similar problem happens in the Inca ruins, which should load a palette from $1e770c but instead is loading $1e76cc. Both incorrect addresses are off by #$40, which could suggest a problem involving an offset of #$40 somewhere.
(b) The school ($0d81bd) contains the card "15 03" that should include assets from the seaside cave, specifically including the card "10 63 14 00 1D 54 D3" that loads a sprite set from $13541d. I think you're calling this sprite set "15 - Main Characters". GTC is reading/writing this card to load the South Cape sprite set instead, $17b3a6. The Freejia hotel has a similar problem, loading the Freejia sprite set instead of going back to the seaside cave to load the Main Characters sprite set.
(c) Entering Will's house crashes the game in an exported ROM. The immediate cause is a "14 24" card followed by a "15 24" card, which causes the game to loop forever between the two. The real cause is that GTC re-orders the room resource cards to be in increasing numeric order. In most cases this doesn't matter, but in Will's house it does, because this map uses the order of its cards to load different assets depending on what stage of the game we're in.
2. When changing map movements, GTC extends the appropriate table in the $03 bank. In doing so, it overwrites the data at $03b1d4 instead of offsetting the data forward. This can cause a crash when selecting a destination on the map. On the same note, I think $03a69e "lda $b1d4,x" might need to point to the byte after the map movement table, which will no longer be $b1d4 if you expand the table.
Figuring all of this out was a fun puzzle. I hope it helps!
Your answers contain the positions in the ROM where something went wrong, so I think this will help him more than my list! ;) I think we ruined his weekend! >;D
By the way, what do you mean with "card"? Do you mean "map"? ;)
I'm referring to punched cards https://en.wikipedia.org/wiki/Punched_card since I'm imagining that table as a stack of cards punched with $02, $03, etc. that we feed to the parser. Maybe this is a silly name. I don't want to call them "entries", though, because I would think all of the map's bytes together are a single "entry". Maybe I should call them "sub-entries" or "directives"?
Dunno. Naming them is a bit difficult, and calling them "entries" would make everything even more confusing, because, well, how many things might be in this game that might deserve that name! ;)
What I do is pretty silly: find some bytes that are probably relevant to what I'm investigating, then try to map out the code paths by hand, or corrupt individual bytes if either I feel lazy or I can't figure out how the code works. Sorry to disappoint. :)
I use bsnes-plus and a diff tool. That's about it.
Usually I have no idea where the code or data I'm interested in will be in the ROM. I can think of two ways to guess. First make a savestate a few frames before the target bytes will probably be read/executed. Then:
1) From the savestate, make one cpu trace where I do an action that would read the target bytes, and another trace where I do something different (probably stay idle). Instructions that are in one trace but not the other are potentially related to the target. Example: to find the Psycho Dash code, charge Will up, save the state, then make one trace where I keep holding the button and one where I release it. (Even better: make traces that will read related bytes but branch before the target bytes. Example: charge Freedan and make a trace where I release the button. Code that's in both the Friar trace the Dash trace can't be Dash-specific.)
2) Only works if I think the target bytes will change RAM. From the savestate, use the Cheat Finder in bsnes to narrow down what RAM is different if I do or do not activate the target bytes, i.e., activate the target bytes, use "Not equal to - Previous value" to find what's changed, reload the savestate and use "Not equal to - Previous value" again, idle for a few seconds and use "Equal to - Previous value", over and over, until the list of affected RAM converges to a reasonably small size. Any RAM still in my list is potentially related to the target bytes. Example: go to a map screen, save the state, then check the RAM before and after selecting a destination.
Now I have suspect bytes that could be the target, so I set breakpoints on a few of them. Relevant bytes will break whenever I perform the triggering action, and not at any other time. This reduces my list of suspect bytes down to those that only break on the triggering action.
What happens next is really just a combination of mapping out the code plus clumsy ROM corruption. Starting from any of my breakpoints, I just step through the code.
I can usually tell if I'm stepping through the reading of a table, because the code will read several bytes sequentially. I can get a sense of how the table is formatted by watching what the code does with each byte (copy to RAM, copy to a register, treat as an address, etc.). Sometimes it's obvious what a byte is for if I follow the code for it. If it's not obvious, or if I just feel lazy, I change a byte to a few different values and watch how my changes affect the game. The map assets table is pretty easy to map out by hand.
If I'm not looking at a table, things are more difficult. Usually I'll just corrupt a byte in the code path, to see how this path affects the game. Immediate values are a good choice for corruption, as are jsr/rts pairs (just change the jsr to nops), and values in RAM. If this corruption changes how the game responds to my action, then these bytes are part of the code that handles the action.
Finding code becomes easier if you can compare multiple traces under different circumstances. I found the special attack code by comparing an idle trace, a Dash trace, and a Friar trace. At some point I found a pointer in RAM that was being used by both the Dash and the Friar, but with a different value between the two. I stepped through the Dash until it tried to read that pointer, then I changed the pointer's value to what it would be using the Friar. This caused Will to use the Friar instead of the Dash. My eyes were opened.
Thank you very much for your detailed description :) Your approaches sound promising I will try them out for myself ;) I'm currently completely rewriting the map data handling so Therme will soon be an update :)
MY BUG REPORT
AntwortenLöschen1) I, once again, was only able to test the GTC.exe file in the sub-folder 0_5_2_1, the setup.exe and GTC.application file both told me that the program was installed elsewhere and thus could not be executed.
2) In the Open Menu, you only can open .smc files. Please add .sfc files, because of the reasons I mentioned in my last bug report. Furthermore, the .sfc file ending gets more popular.
3) The Zoom is still titled "-1" to "4". Is it possible to change this to the correct percentage values in the info box?
4) The "Lower Layer" and "Upper Layer" stuff - is this renamed since the last time? I don't remember what the plan was with that caption.
5) The "Lower Layer" and "Upper Layer" stuff is for EDITING. I think it would make more sense if you use that option to the right in the map editor tab (to the right), since it looks like some option for viewing/hiding the layers if it is shown directly beneath the Map. Furthermore, that stuff isn't relevant for editing Events or the map properties, right?
6) If I edit a map and go on "Save Project", the "Save Map" button stays green.
7) Whats the point for editing the name under "Map Properties"? When I tested that for South Cape, it at least didn't change the name in the Map List to the left, if that is the planned function.
8) Again, if I edit the map, save the project, close the project, and open the project, the map is horribly butchered (as it can be seen here: https://twitter.com/pantalytron/status/1050074563239923713 ).
9) The New Project function only works on start up. When you already have opened a project - regardless if you close it or not! - there is that project's name with the entire path ("C:/...") in the textbox where you have to enter the new file name. After that, the new project file isn't properly/entirely generated.
10) If you create a new project when you already have an project opened, and you are in the map editing window, the window still shows the old map even after (unsuccessfully) creating a new project
11) If you edit Tilesets, you have a dropdown box to select "Palette Sets". In the Dropdown-Box, you have "Palette 1", "Palette 2" and so on. You should copy and paste that whole thing so it is "Palette Set 1", "Palette Set 2" and so on, since you distinguish between both, and here, you use one term for another.
12) At least on my PC, the program has a LONG loading time when changing the Zoom. Especially on 4 (500% zoom?), which I clicked on accidentally.
13) When I click on Map 19, it shows me the water layer of map 18?! As can be seen here: https://twitter.com/pantalytron/status/1050074607540195328
14) Clicking on Map 20 doesn't do anything, clicking on another map afterwards gets me some error messages in the message box, something of an Array Index out of bound.
And this is it, I'm excited to bugreport the next version, too! ^_~
Hi Lytron,
Löschenthanks for your feedback :)
1) The setup wants you to uninstall the old editor first. I'm not happy with this either maybe I can find a workaround.
2) Added .sfc files
3) I will change it to percent values
4) Renamed it to BG1 and BG2 layer acording to the filter options
5) You're right. I moved it to the map editor where it belongs ;)
6) Will be fixed for the next version
7) The name in the list is only for the internal map representation in the editor. The name in Map Properties is the name which is displayed in the game. Both names can be different though since they aren't connected in the editor.
8) 9) 10) Will be fixed for the next version
11) Renamed it everywhere to "Paletteset"
12) I will try to make the map loading more efficient. But not for the next version.
13) I'm familiar with this but couldn't figure out the reason yet
14) I will check it ;)
I've found the source of some of the corruption that happens when I export a ROM. Here are some notes.
AntwortenLöschen1. GTC seems to be making some mistakes when parsing the table at $0d8000. This is the table that contains memory addresses of assets to load for each map. I can't see a pattern in the mistakes, so I can't guess about what kind of bug might cause them. Here are three examples:
(a) The title screen ($0daf30) contains the card "04 00 60 a0 00 12 df", so it should load a palette from $1f1200. GTC is setting the palette address to $1f11c0 instead. This causes the globe on the title screen to be all black. A similar problem happens in the Inca ruins, which should load a palette from $1e770c but instead is loading $1e76cc. Both incorrect addresses are off by #$40, which could suggest a problem involving an offset of #$40 somewhere.
(b) The school ($0d81bd) contains the card "15 03" that should include assets from the seaside cave, specifically including the card "10 63 14 00 1D 54 D3" that loads a sprite set from $13541d. I think you're calling this sprite set "15 - Main Characters". GTC is reading/writing this card to load the South Cape sprite set instead, $17b3a6. The Freejia hotel has a similar problem, loading the Freejia sprite set instead of going back to the seaside cave to load the Main Characters sprite set.
(c) Entering Will's house crashes the game in an exported ROM. The immediate cause is a "14 24" card followed by a "15 24" card, which causes the game to loop forever between the two. The real cause is that GTC re-orders the room resource cards to be in increasing numeric order. In most cases this doesn't matter, but in Will's house it does, because this map uses the order of its cards to load different assets depending on what stage of the game we're in.
2. When changing map movements, GTC extends the appropriate table in the $03 bank. In doing so, it overwrites the data at $03b1d4 instead of offsetting the data forward. This can cause a crash when selecting a destination on the map. On the same note, I think $03a69e "lda $b1d4,x" might need to point to the byte after the map movement table, which will no longer be $b1d4 if you expand the table.
Figuring all of this out was a fun puzzle. I hope it helps!
Your answers contain the positions in the ROM where something went wrong, so I think this will help him more than my list! ;)
LöschenI think we ruined his weekend! >;D
By the way, what do you mean with "card"? Do you mean "map"? ;)
I'm referring to punched cards https://en.wikipedia.org/wiki/Punched_card since I'm imagining that table as a stack of cards punched with $02, $03, etc. that we feed to the parser. Maybe this is a silly name. I don't want to call them "entries", though, because I would think all of the map's bytes together are a single "entry". Maybe I should call them "sub-entries" or "directives"?
LöschenDunno. Naming them is a bit difficult, and calling them "entries" would make everything even more confusing, because, well, how many things might be in this game that might deserve that name! ;)
LöschenWow, once again thank you very much for your detailed analysis :)
LöschenI think I have to rework the map data handling at several points but your hints will help me a lot.
A general question: Can you describe your analysis procedure a little bit (steps/tools). Maybe I can improve my own analysis methods ;)
What I do is pretty silly: find some bytes that are probably relevant to what I'm investigating, then try to map out the code paths by hand, or corrupt individual bytes if either I feel lazy or I can't figure out how the code works. Sorry to disappoint. :)
LöschenI use bsnes-plus and a diff tool. That's about it.
Usually I have no idea where the code or data I'm interested in will be in the ROM. I can think of two ways to guess. First make a savestate a few frames before the target bytes will probably be read/executed. Then:
1) From the savestate, make one cpu trace where I do an action that would read the target bytes, and another trace where I do something different (probably stay idle). Instructions that are in one trace but not the other are potentially related to the target. Example: to find the Psycho Dash code, charge Will up, save the state, then make one trace where I keep holding the button and one where I release it. (Even better: make traces that will read related bytes but branch before the target bytes. Example: charge Freedan and make a trace where I release the button. Code that's in both the Friar trace the Dash trace can't be Dash-specific.)
2) Only works if I think the target bytes will change RAM. From the savestate, use the Cheat Finder in bsnes to narrow down what RAM is different if I do or do not activate the target bytes, i.e., activate the target bytes, use "Not equal to - Previous value" to find what's changed, reload the savestate and use "Not equal to - Previous value" again, idle for a few seconds and use "Equal to - Previous value", over and over, until the list of affected RAM converges to a reasonably small size. Any RAM still in my list is potentially related to the target bytes. Example: go to a map screen, save the state, then check the RAM before and after selecting a destination.
Now I have suspect bytes that could be the target, so I set breakpoints on a few of them. Relevant bytes will break whenever I perform the triggering action, and not at any other time. This reduces my list of suspect bytes down to those that only break on the triggering action.
What happens next is really just a combination of mapping out the code plus clumsy ROM corruption. Starting from any of my breakpoints, I just step through the code.
I can usually tell if I'm stepping through the reading of a table, because the code will read several bytes sequentially. I can get a sense of how the table is formatted by watching what the code does with each byte (copy to RAM, copy to a register, treat as an address, etc.). Sometimes it's obvious what a byte is for if I follow the code for it. If it's not obvious, or if I just feel lazy, I change a byte to a few different values and watch how my changes affect the game. The map assets table is pretty easy to map out by hand.
If I'm not looking at a table, things are more difficult. Usually I'll just corrupt a byte in the code path, to see how this path affects the game. Immediate values are a good choice for corruption, as are jsr/rts pairs (just change the jsr to nops), and values in RAM. If this corruption changes how the game responds to my action, then these bytes are part of the code that handles the action.
Finding code becomes easier if you can compare multiple traces under different circumstances. I found the special attack code by comparing an idle trace, a Dash trace, and a Friar trace. At some point I found a pointer in RAM that was being used by both the Dash and the Friar, but with a different value between the two. I stepped through the Dash until it tried to read that pointer, then I changed the pointer's value to what it would be using the Friar. This caused Will to use the Friar instead of the Dash. My eyes were opened.
Thank you very much for your detailed description :) Your approaches sound promising I will try them out for myself ;)
AntwortenLöschenI'm currently completely rewriting the map data handling so Therme will soon be an update :)