Forum Replies Created
-
Posts
-
This is the best version I know of. It's unabridged, four tightly-bound volumes with thin pages and compact text. IIRC the online translation is the Brewitt-Taylor translation which is a little harder to read. Moss Roberts' is as readable as any science fiction or fantasy novel without losing any of the gravitas or style.
Lots of great historical footnotes, too. Let us know what you think once you start reading.
Unfortunately the value I'm looking for in 1 is the code that the map uses for the tiles in question. So if we know where those maps are stored, that might give us a good start.
Both these sound possible if you can find where in the ROM the corresponding stuff is.
I think 1 -> Need to figure out what the tile code is. There may be a different tileset for caves than there is for world map stuff, unfortunately.
2-> Need to figure out where these sprites are stored… if we're lucky they're sorta like generals and we can reuse the color stuff
Hey sonic,
I'm afraid I'm on vacation and may not be able to troubleshoot it all that quickly, but I'll help when I can.
I took a look at the broken rom, and nothing seems that unusual in the hex. My guess would be a pointer gets misaligned when it tries to save.
Any chance MiDKnighT could help us debug the freeze somehow? That would narrow down the problem.
Yeah, I needed to increase a value by one in the DoaEditor code.
http://www.niahak.org/images/DOAE/DoaEdv098f.zip – not updating front of topic for reasons stated below.
This is a bit sad, because my text editor always assumed that each line was denoted by two pointers: start, and end (beginning of next line). Pretty much what you said MiDKnighT – it lays all the lines end to end and that's how it can do its nifty compression.
So you can edit the last line, but it doesn't have a preset 'end' pointer… so to get more space in the 2nd text bank, you'll have to delete something. You can always delete the 0s at the end of the last line.
I'll consider this a bug, though. Lines should parse until they hit the first [end]… but that's a hefty refactor I don't think I can tackle tonight.
Quote:Hi Niahak, which pointer are you referring to? I obviously want to the IPS patch to play nicely with DoaEditor. I can fix the IPS patch if you show me what to fix.Actually, I'm not sure why the line in question doesn't already cause an issue with DoaEditor on a vanilla ROM. You can see it at 0x2f1ab in the ROM. I'll look into it after the weekend's over and update.
sonic – I took a look at the ROM and I don't see anything actually incorrect in the text. It looks like you changed the line normally filled with 0s to be much shorter (which makes sense – saves a lot of space). Best guess at this point is that it is something to do with the way the duel lines are referenced? I actually can't even find the line that it's grabbing the end from ("er[line] than you!").
Re: an even larger ROM, I can make DoaEditor can do that… but it will take some time to implement.
Quote:No problem, glad to be of help in you learning something new.That's sort of the unfortunate part of all this – it was code written probably three years ago (probably some of the first text editing code). I've learned this several times, but I hadn't gone over this code in a very long time.
Also, I finally got my act together and put Destiny of an Editor in a source control system.
In case anyone wants to take a look at any source code, it's available at
http://www.dev.niahak.org/DoaEditor/
Of course, it's difficult to read from a website. If anyone wants to seriously look at / help develop the code, I can get you set up with the SVN :)
OK, looks like I've figured it out.
Not only was it a relevant issue, it was also something that should've been noticed and fixed a long time ago :oops: In fact, it might've been what was causing other "corruption" issues earlier.
Here is a revised version that will work with the IPS. It'll even only show the "4D" issue only once before it self-fixes (open and save). The 4D pop-up is sort of an artifact of the IPS/game combo and not something I can really control :( However if MiDKnighT wants to 'fix' it, it could be done by incrementing the pointer up by two for that last line before the new content.
Soooo on to the details, which I'm sure everyone wants to know.
DoaE is a fairly wordy game for its time, but lines are generally fairly short in length (~400 bytes at the most). So the following code was sufficient to handle any line in DoaE (and indeed in most ROMs):
Code:if(lineLength / 256 > 0)
{
linePageLength++;
}More experienced code monkeys (like myself now, not so much when I wrote this I suppose) will probably be banging their heads on the table at the sight of this; if a line is longer than 256 bytes, it correctly increments the 'page byte' (indicating how many increments of 256 it contains). However… if the line is longer than 512 bytes, it still only increments that page byte once (cutting off the line at an arbitrary point past 256, and shifting all lines up to compensate).
tl/dr; I screwed up your stuff. I'm sorry!
If I can get steps to reproduce, I can probably put together something tonight. I'm going to be super busy over the weekend though :/
Quote:I didn't edit your new text at all, just used DOAEditor and my mod got all borked up. I believe that I am going to have to re-apply your IPS EVERY time I make adjustments via DOAEditor atm… I think we really need to get Niahaks help on this one.Can you give me a sample before/after DoaEditor borks it?
I will try and discover the borking-cause.
Well… unfortunately, it's not that easy. Right now it keeps track of exactly how many bytes to read out, and doesn't automatically end a line at a 0xFF or other corresponding [END] tag (I'm not even sure what happens in-game if an [END] is midway through a line).
I could potentially prototype it… but I'll have to think about it. It seems better to make DoaEditor configurable in some way so it won't stomp all over any lines you add.
Actually – for that matter – why not just use one of those unused empty lines at the end of the bank? That way there's no dud, and you can edit the text in DoaEditor.
I think what's happening is a pointer error of some kind.
It's trying to parse line 0x5f of bank 3, specifically a line that's 0xa39 bytes long starting at 0x2ed57.
Pointers 14c to 15f for the second pair of banks all have the same value, then there's suddenly a huge leap (that 0xa39 bytes).
In the actual ROM, it looks like that text is just an [END] (0xFF), but the text editor's trying to read the following bunch of bytes and it's choking on some of the contents.
If you look at the difference between the pointers at 0x2c16f and 0x2c170 with their corresponding companions at 0x2c36f and 0x2c370 (call them A: 0xAD47 and B: 0xB780) you can actually see exactly where that 0xa39 came from. It thinks there's a line at A of length 0xa39 – when the pointer for A is probably never actually referenced in code. Basically, you have a "dud" line that isn't being used, and DoaEditor is choking when it tries to parse it.
