Re: PC-98 (PC-9821 / PC98)
Posted: January 22nd, 2022, 5:59 pm
Because if you encode (for example) xx xx yy zz as 44 xx yy zz, that's one byte shorter than the fallback encoding, 00 xx xx yy zz.
Page 2 of 4
Re: PC-98 (PC-9821 / PC98)
Posted: January 22nd, 2022, 6:47 pm
Oh, yeah. I forgot about the 00.
Re: PC-98 (PC-9821 / PC98)
Posted: January 23rd, 2022, 4:43 pm
I suggest adding parentheses in
offset = 0x400 + current_sector * 2
While it's clear that, per the order of operations convention, it is...
offset = 0x400 + (current_sector * 2)
...I think emphasis is useful, because it's easier to read, particularly given the expression starts with "+".
offset = 0x400 + current_sector * 2
While it's clear that, per the order of operations convention, it is...
offset = 0x400 + (current_sector * 2)
...I think emphasis is useful, because it's easier to read, particularly given the expression starts with "+".
Re: PC-98 (PC-9821 / PC98)
Posted: January 23rd, 2022, 5:47 pm
David, maybe you can tell me why my code (attached) ends with:
[FAILED] Invalid compression. Head byte at pos. 0/2908: 0xE1!
[FAILED] Invalid compression. Head byte at pos. 0/2908: 0xE1!
Re: PC-98 (PC-9821 / PC98)
Posted: January 23rd, 2022, 11:46 pm
There are two bugs:
1.
Code: Select all
iOffset = iCurrentSector * 0x400;
ReadFromFile (iFd, "Sector Data", 0x400, sSectorData);
2. (Two occurences!)
Code: Select all
for (iLoopByte = 0; iLoopByte < iSize; iLoopByte++)
{
sFileCom[iSizeCom + iLoopByte] = sSectorData[iLoopByte];
iSizeCom++;
}
Either:
a) use just sFileCom[iSizeCom], or
b) don't increment iSizeCom within the loop, only do iSizeCom += iSize; after it.
You could also use memcpy().
After these changes, the extracted LEV01.MAP matches what the datacut.exe of persia-toolset extracts.
(At the end of LoadFileCom I added some code to save sFileCom into a file, so I could see what data was read.)
Re: PC-98 (PC-9821 / PC98)
Posted: January 24th, 2022, 12:40 pm
Re: PC-98 (PC-9821 / PC98)
Posted: February 15th, 2022, 3:55 pm
I have a question. In LEV01.MAP, at 0x5F, 5A 11 42 should become 00 xx 00 yy but with the value from 8 bytes before instead of 00. However, the output is 00 11 75 42, so the first 00 stays unchanged then?
Re: PC-98 (PC-9821 / PC98)
Posted: February 19th, 2022, 6:53 pm
At that point, the previous 8 bytes are: 00 33 75 51 00 07 63 61
If you count 8 bytes back from the first byte you're about to append, it's the 00 byte before 33.
Or, to explain it (somewhat) visually:
Code: Select all
output offsets 0x64-0x67: 00 33 75 51 (8 bytes before each byte to be appended)
output offsets 0x68-0x6B (are not important for this explanation)
output offsets 0x6C-0x6F: ^^ 11 ^^ 42 (the appended bytes, ^^ means use what is in the first row in the same column)
Re: PC-98 (PC-9821 / PC98)
Posted: February 19th, 2022, 7:19 pm
Ah, now I get it; thanks.
Re: PC-98 (PC-9821 / PC98)
Posted: February 20th, 2022, 2:14 pm
Progress. 
Now includes full, working decompression code.
Now includes full, working decompression code.
Re: PC-98 (PC-9821 / PC98)
Posted: March 2nd, 2022, 9:13 pm
Progress. Simple beginnings of a GUI. Still very incomplete.
Loads/displays room links, some blocks, flags/objects, starting position.
By the way, I noticed that in level 10, while in room 5, the top left ceiling is open. In other words, they removed the loose floor from the room above (11). Probably to prevent the player from thinking they are stuck.
Loads/displays room links, some blocks, flags/objects, starting position.
By the way, I noticed that in level 10, while in room 5, the top left ceiling is open. In other words, they removed the loose floor from the room above (11). Probably to prevent the player from thinking they are stuck.
Re: PC-98 (PC-9821 / PC98)
Posted: March 5th, 2022, 6:54 pm
Nice.
I think these lines in ShowTile():
Code: Select all
iFlag = arBlockFlag[iBlock];
iObject = arBlockObject[iBlock];
Code: Select all
iFlag = arBlockFlag[iBlock & 0x7F];
iObject = arBlockObject[iBlock & 0x7F];
Without this fix, some tiles display wrong flag and object names.
Some even display hex codes using the default branch in GetObjectName().
Yeah, I noticed this recently, when I played this version from the beginning to the end.
I noticed another small difference from the DOS version, on level 8.
The first potion (to the right from where you start) is a heal potion instead of a hurt potion.
On level 11, after you drank the big potion, there is another difference, though this one is not in the level data itself.
When you jump over to the level door and land on the edge, the prince slips in both the DOS and the PC-98 version.
But he also loses a HP in the PC-98 version!
Re: PC-98 (PC-9821 / PC98)
Posted: March 5th, 2022, 10:51 pm
Yes, thanks.
You know what's funny. In a recent playthrough I also picked up that LP and lost the hit point. I remember subconsciously thinking "Huh..." but it wasn't enough of a surprise to trigger the realization that it doesn't happen under DOS. And if I'm not mistaken, in the same time frame of a second or so, I also thought: "That's okay. Got one bar, lost one bar. We're even, but I got the extra health next level."
Re: PC-98 (PC-9821 / PC98)
Posted: March 9th, 2022, 10:45 pm
Oh, and what I also noticed, and you perhaps did as well, is the following. In level 6, when entering the shadow room, the game stops the character. This only happens when entering the room with a running jump, that has its liftoff right before the gap in the previous room.
Re: PC-98 (PC-9821 / PC98)
Posted: March 12th, 2022, 7:49 pm
It happens no matter how do I enter, but only the first time.Norbert wrote: ↑March 9th, 2022, 10:45 pm Oh, and what I also noticed, and you perhaps did as well, is the following. In level 6, when entering the shadow room, the game stops the character. This only happens when entering the room with a running jump, that has its liftoff right before the gap in the previous room.
The game plays music when you first enter that room, and the prince is stopped until the music ends.
In SNES PoP, the music of special events similarly stop the prince.