Killing Time (PC) Monster Randomizer

[BFG]

I had also made a Bodycount and Tekwar 'randomizer'

That sound pretty cool. Someone made an Operation Body count weapons mod a while back, it could go pretty well with it:

nice, I never released it but maybe my next release!

[Ringman]

Theres a few issues.

Cells have multiple types:

With/Without Internal Pallet. This internal pallet gets mapped to an internal colormap within the 3DO hardware, if my reading of the SDK/Docs are correct.

With/Without Compression - Seams like a simple Packedbits scheme (described as Packed/unPacked in docs).

With/Without 'Fill' and 'Masks' -
-FILL marker means that one Cell takes data from a Previous Cell (still testing this)
-a Mask Describes transparency or anti-aliasing of the previous/next Cell (still testing this).

What I have currently is a script that attempts to extract cell images from the disk image via a search, then reading some values and calculating an end off the file. This works for ~60% of the cells.

Last night, I found that some Cells have multiple PDAT sections (Pixel Data). These tend to be animations from what I can tell, but I found these markers outside of animation headers.

The WORD I had assumed was a length of the PDAT field is wrong on these subsequent PDAT sections, so I'm working on figuring out what that means.

All Code is in extremely simple python.

Forgive my ignorance ahead of time if I say anything out of line, or doesn't make sense, I just now started reading about this. I'm just asking some possibly stupid questions to get a better understanding of everything. So you are saying that there are PDAT chunks outside of animation headers, like they are zombie chunks? Are they at least in a PLUT chunk? I assume you are using the ANIMChunk's chunk size to determine where the ANIMChunk ends, and the PLUTChunk size as well. And these PDAT chunks fall well outside of those limits? How did you find the related PDAT's? Also you say the WORD size is wrong, but can you not gleam the size chunksize and numentries from the wrapping PLUTChunk, assuming each PDAT is the same size.

[ect0s]

** Cleaned up and Massively edited**

I'll try to clear a few things up.

The most common format(s) I've seen:

For Enemies:

ANIM->CCB--PLUT-XTRA->PDAT-PDAT-PDAT-PDAT...

However, not all Cells are (within) animations:

CCB-PDAT // CCB-PLUT-PDAT // CCB-PDAT-PLUT (Reverse order?)

I found the issue with the WORD I was using, some cells have data with another marker within them due to an error in an assumption of mine. The hint was me finding lots of JOIN JANMHDR etc markers in the middle of PDAT sections. I had not coded anything to deal with this, and have not (as of yet) written anything that works. As far as I can tell, these JOIN statements mark out sections of the disk, but the issue is the PDAT contained within has a size larger than its position to end of the size of the JOIN statement. Theres a table at the beginning the of the ZStream (MRKRJHDR) that tells me where each JOIN statement starts, itself contained within a JOIN statement.

My current tool:

Scans for Cell Control Blocks, marking offsets into a list.

Seeks to a CCB, reads it length, reads its data into buffer.

Checks for a PLUT or XTRA (found in some cells) and reads them into the buffer.

Checks for PDATS between the current position and the next known CCB.

For each found, it attaches the CCB header/PLUT etc found, then dumps buffer to a file named 'Offset-(Offset into disk)-(length)'

The issue:

The length of a PDAT may overrun into another marker (SNDS/FILL/JOIN) etc.

PDAT-220 bytes -> 110 bytes in theres another control statement (JOIN/FILL/SNDS/CARY etc).

So, wheres my data?

I did try filling the requested space with null padding, but that doesn't seam correct.

I'm currently working on a tool that will jump over the control block, to see what data is after it. Long term, it would be better to walk the disk from control statement to control statement, but this might be a dead end if I still cant find the data I need.

[ect0s]

EDIT:11/6/2016 New dump uploaded, more sprites, but some glaring issues still.

http://www.mediafire.com/file/6rlc1hcxn ... 282%29.zip

http://imgur.com/Y3Klsr7

proof of progress.

Alpha channel and other issues exist, and its far from a complete dump, but I figured I'd share.

Nothing is properly named, as I've resorted to a hack (dumping selected data to a 2ndary file before conversion). The selection step needs refinement, as does the final conversion step.

Textures/Static Sprites:
https://imgur.com/a/gPjGo

These are the same format (ARY/CARY cels) as the wall textures. Not a perfect extraction, but a step closer.