When you extract the packed reject table into a file, using a program like DETH, it pads the hex output to the next highest multiple of 16 bytes. For instance, the table for E1M1 is 968 = 16 × 60.5 bytes long, so 8 extra bytes are added to the dump. I managed to figure out (using RMB) that they were all at the end. They aren't zero. They don't duplicate the first 8 bytes. What are they? Are they, for example, the first 8 bytes of the next lump? (If so, does that mean that some of the padding occurs at the beginning of the list for other levels, depending on the absolute starting address of the reject lump? Sheesh.) Ryan W 21:16, 25 August 2007 (UTC)
- Loading of reject from file is in lxdoom-1.10 p_setup.c:660
rejectmatrix = W_CacheLumpNum (lumpnum+ML_REJECT,PU_LEVEL);
- W_CacheLumpNum allocates memory for a lump equal to the size of the lump as specified in the wad, and loads the lump into that memory. So this code doesn't care how much padding is on reject, or even if the reject table is at all properly sized for the wad.
- Using of reject is in p_sight.c:294-348. excerpt:
s1 = (t1->subsector->sector - sectors);
s2 = (t2->subsector->sector - sectors);
pnum = s1*numsectors + s2;
bytenum = pnum>>3;
bitnum = 1 << (pnum&7);
// Check in REJECT table.
if (rejectmatrix[bytenum]&bitnum)
{
sightcounts[0]++;
// can't possibly be connected
return false;
}
- This code simply calculates which which bit the desired reject result ought to be in, and reads that far into the table for the result. No padding anywhere inside the table is allowed. Padding at the end is ignored. If the reject table is too short, the function will simply read off the end into whatever garbage is in memory next. So the only nessecary padding is to fill up the last byte if numsect * numsect is not divisible by 8.
- ZenNode 1.21 does the following. ZenReject.cpp:248-252
int noSectors = level->SectorCount ();
int rejectSize = (( noSectors * noSectors ) + 7 ) / 8;
UINT8 *reject = new UINT8 [ rejectSize ];
memset ( reject, 0, rejectSize );
- The code then proceeds to fill all bits corresponding to sector lookups with the calculated reject data, while leaving all other bits zero. The only padding ZenNode applies is the + 7, which simply rounds up to the next byte; if numsect * numsect is not divisible by 8, the division by 8 would truncate and leave no room for the spillovers into the last byte.
- As far as your example case goes, I'd have to chalk it up to an error in Deth (which uses an earlier version of zennode I believe). The idbsp generated rejects in the original iwad also don't contain any extra padding. 71.58.109.233 21:53, 18 September 2007 (UTC)
- Wow!
- I only understand about a third of that, but I think it means "the padding is at the end", which is what I asked. :> The nodes I used are the OEM nodes, not built by DETH or any other program after the fact — sorry if that was unclear, and hopefully that doesn't change your whole line of reasoning (although IMHO this is a valuable posting and should be kept here in any case).
- Sorry about the verbosity; my idea is with a lot of code references, anyone who is inclined can pick this up and try to figure out something from where I left off. The short version is that if there is any padding in a reject lump, it MUST be at the end, and that the one example node builder I looked at, ZenNode 1.21, inserts no padding other than to the nearest byte (which is the minimun nessecary). When you say "The nodes I used are the OEM nodes" though, I don't quite get you; I'm showing the following numbers for ultimate doom e1m1 (my iwad matches the md5 given somewhere else at this site): NumSectors = 88; RejectSize = 968. This fits exactly with zero padding. 71.58.109.233 00:12, 19 September 2007 (UTC)