PC-98 (PC-9821 / PC98)

[Norbert]

When I modify a single tile, using the custom tile functionality on the tiles screen, levels seem to no longer save correctly.

I tried it. I could add two floors just fine: [image]

Well, as I wrote...

I've had instances that it still works, but mostly it no longer does.

Playtesting (once?) after adding two of the same tile isn't thorough enough to run into the bug.

Here is an example of replicable steps to mess up level 1:
1. In the starting room, change the 4th tile (upper row) to 06.
2. Save
3. Playtest (you can immediately close the emulator)
4. Change the same tile to 26.
5. Save
6. Playtest
The in-game level is now messed up.
After restarting the editor, so is the in-editor level.

I think maybe the problem is with ModifyForPlaytest()...
[Edit 1: No, it's not. If I comment it (and 'modify back') out, the problem's still there.]
[Edit 2: Also not fixed when I end ModifyForPlaytest() with "close (iFdA);" and start ModifyBack() with "iFdA = open (DISKA, O_RDWR|O_BINARY);".]
[Edit 3: Neither commenting out 0x11/0x21 or 0x91 compression, nor commenting out both, fixes it. I will try commenting out everything else one by one, and will report back later. Edit: It's not the compression, it looks like.]

[David]

Playtesting (once?) after adding two of the same tile isn't thorough enough to run into the bug.

Yes, sorry, I saved only once.

Here is an example of replicable steps to mess up level 1:
1. In the starting room, change the 4th tile (upper row) to 06.
2. Save
3. Playtest (you can immediately close the emulator)
4. Change the same tile to 26.
5. Save
6. Playtest
The in-game level is now messed up.
After restarting the editor, so is the in-editor level.

I tried this and indeed the level is messed up.
At this point, files/LEV01.MAP is smaller than it should be: it's 3068 bytes instead of 5120.
(3068 is the size of ENDING6.DAT, the last file on the disk.)

In SaveLevel(), before you call SaveFileDecom(), you need to set iSizeDecom:

Code: Select all

	iSizeDecom = 5120;

or:

Code: Select all

	iPos+=17;
	iSizeDecom = iPos;

When I compared the saved level file with the original, I noticed that certain bytes change from 0 to random values for no reason.

You can add a line here to fix it:

Code: Select all

	for (iLoopBlock = 0; iLoopBlock < BLOCKS; iLoopBlock++)
	{
		iFlag = arBlockFlag[iLoopBlock];
		iObject = arBlockObject[iLoopBlock];
		iFlagObject = iObject + iFlag;
		sFileDecom[iPos + (iLoopBlock * 2)] = iFlagObject;
		sFileDecom[iPos + (iLoopBlock * 2) + 1] = 0; // added
	}

[Norbert]

Thanks a bunch David.
Your contributions are a lifesaver.

[Norbert]

Attached is a new alpha. I've modified both the tile images and the tiles screen. All tiles are now 160x160 pixels, and include data beyond the 64x128 base, such as gate bars, level exit doors, etc. The tiles screen now processes custom tiles as a block+modif combo instead of just the block.

There's a new 'obstacle'. I've noticed that, even in levels with the same environments (e.g. levels 0-3), not all resources are available in all levels. Not only that; even in levels with the same environments (again, e.g. levels 0-3), some block+modif combos show completely different tiles! A striking example is the chomper in the room to the left of the level 3 starting room. Its block+modif combo is 0x7C+0x00. That very same combo is the top left of the level entry door in level 2. A completely different tile... And when used in level 1, the combo displays nothing (just black). I fear the tile images' filenames will have to also include the object byte.

[David]

Not only that; even in levels with the same environments (again, e.g. levels 0-3), some block+modif combos show completely different tiles!

Yes, unfortunately the block number does not directly determine the graphics.
The logic for drawing a level is about as complex as in SNES PoP. (Arsys made both ports, I think?)

The appearance of each block is defined by the parts which you call sBytesA, sBytesB, and sBytesC.

Given a block number iBlock:
* sBytesB[iBlock*2] and sBytesB[iBlock*2 + 1] tell which halfblocks are drawn at the top and the bottom half of the block in the back layer.
* sBytesC tells the same for the front layer.
And, given an iHalfblock value from one of the previous arrays:
* sBytesA[iHalfblock*16] .. sBytesA[iHalfblock*16 + 15] tell which tiles to draw from the CHR file. They are arranged in a 4×4 square.

[Norbert]

To check if I understand you correctly:

* sBytesC tells the same for the front layer.

Which is layer iModif, in my code.

And, given an iHalfblock value from one of the previous arrays:
* sBytesA[iHalfblock*16] .. sBytesA[iHalfblock*16 + 15] tell which tiles to draw from the CHR file. They are arranged in a 4×4 square.

Similarly, I work with iBlock1A-iBlock4A in apoplexy, to give me, for example, png/green/g_00_01_10_01.png for a crusher, where 00 01 10 01 is essentially the 'tile to draw'. For PC-98, I'll get filenames such as d_HH_HH_HH_HH_HH_HH_HH_HH_HH_HH_HH_HH_HH_HH_HH_HH.png, because each half-block (2 of which I get from iBlock, 2 from iModif) consists of 16 bytes. Or.... even 16x4 times HH for one tile image?

[Norbert]

David, is there any chance you have time and energy to answer my above question? To be honest, most likely I won't find the motivation to continue this PC-98 project unless someone can give me verification that, with the above thinking, I'm on the right track. It's labor-intensive work to create all these PNG images, and I've started+failed that process twice now, because I misjudged the format/drawing complexity.

[David]

For PC-98, I'll get filenames such as d_HH_HH_HH_HH_HH_HH_HH_HH_HH_HH_HH_HH_HH_HH_HH_HH.png, because each half-block (2 of which I get from iBlock, 2 from iModif) consists of 16 bytes. Or.... even 16x4 times HH for one tile image?

It's labor-intensive work to create all these PNG images, and I've started+failed that process twice now, because I misjudged the format/drawing complexity.

I say it would be easier (require less work and fewer files) if the editor drew the room using the 16×16 tiles from the *.CHR files.
(Similarly to how Pr1SnesLevEd uses the graphics data in the game itself, instead of pre-rendered PNG images for every combination.)

If you prefer not to process the CHR files directly, you can convert the CHR files into BMP using chrconv.exe from the toolset.
(Note that this tool needs a compressed CHR file, not an uncompressed one.)

[Norbert]

[...], you can convert the CHR files into BMP using chrconv.exe from the toolset.

Okay, that's probably the route I'm most likely to successfully take.

[Shauing]

Question. Can this Prince bunny hop in this version? I tried to do bunny hops at the start of Level 1 and couldn't do them.

[David]

Question. Can this Prince bunny hop in this version? I tried to do bunny hops at the start of Level 1 and couldn't do them.

I'm afraid he can't.
Here are two earlier posts about it: viewtopic.php?f=63&t=3510&p=20661&hilit ... -98#p20637

[_Zaphod_]

I'd like to see 2 tile running jump and ground creep fixed in this version of the game (and fm towns version as well, for that matter). anyone up for the task?