Talk:Reject

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 &times; 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


 * 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:


 * 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


 * 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 &mdash; 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).


 * Realistically, if the padding were anywhere except the end, whereas my spreadsheet assumes that it is at the end, the unpacked file would be overflowing with garbage which was flatly contradicted by playtesting. After 4 levels, so far so good, however.    Ryan W 00:00, 19 September 2007 (UTC)


 * 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)


 * Nothing wrong with verbosity if you're trying to help someone out, especially when it's plaintext and someone you don't know (therefore very easy to misinterpret terseness as an insult. :>   The E1M1 lump in my IWAD is 968 bytes as well; however, DETH exports the following.


 * See, 8 extra bytes.   Ryan W 02:40, 19 September 2007 (UTC)


 * Found it. Deth 4.24, wads.c:569+; as best as I can tell this should occur when using the dump feature for any lump; it will always round up to the next 16 bytes.  Extra bytes read will be whatever comes right after the entry in the wad file; if it was the end of the wad file, the program should crash gracefully with a read error. 71.58.109.233 03:06, 19 September 2007 (UTC)


 * Wow again!


 * if it was the end of the wad file, the program should crash gracefully  Which is probably a bug if it doesn't actually dump anything first (DETH seems not to be under development anymore, however, so we'll have to live with that one).


 * If the reject table is too short, the function will simply read off the end  Which, as even I know, can have some of the most bizarre and convoluted side effects known to man.  I remember this being discussed on the Doomworld forums also: there are apparently established WADs with faulty REJECT tables, and the question was, can Chocolate Doom emulate all the crashes and so forth, as well as not desyncing whenever DOS would unethically have allowed some demo to play correctly?


 * In any case, I'm now quite satisfied that my unpacking procedure was correct, and now I just have to wait a few years until Wikia decides whether my hex post should be deleted as a copyvio.  :>     Ryan W 14:15, 19 September 2007 (UTC)