More than 32,768 sidedefs
Andre Majorel
levels exist that use more than 32,768 sidedefs.
This is not supposed to work as the sidedef-number field is a
signed 16-bit integer (0..32,767 = valid sidedef number, -1 = no
sidedef, -2..-32,768 = invalid value). Guess they treat it as
unsigned, giving 0..65,534 = valid sidedef number, 65,535 = no
sidedef. Good guess ? :->
Apart from PrBoom, many engines and utilities support this ?
--
André Majorel <URL:http://www.teaser.fr/~amajorel/>
"Cette supposition rappelle assez celle de ce prédicateur qui, en
pleine chaire, faisait remarquer à ses fidèles la bonté de Dieu qui
avait placé les rivières auprès des villes." -- Alexandre Dumas
RjY
>Apparently, it's been done for years but I just discovered that
>levels exist that use more than 32,768 sidedefs.
Yes, as far back as 2004 (Deus Vult map05)
A few months back I tried to hack Yadex to load a side-limit-breaking
map from Deus Vult's sequel. I didn't get past the stage of constant
segfaults but it ran just long enough under GDB to find the secret
areas I'd missed, which was the point of the exercise. Nevertheless I
look forward to a version that works properly :)
>This is not supposed to work as the sidedef-number field is a
>signed 16-bit integer (0..32,767 = valid sidedef number, -1 = no
>sidedef, -2..-32,768 = invalid value). Guess they treat it as
>unsigned, giving 0..65,534 = valid sidedef number, 65,535 = no
>sidedef. Good guess ? :->
Yes, with the addition that you need to check for sidedef references
which exceed the number of sidedefs, and map them to 65535. For
example GANYMEDE.WAD has linedefs that reference sidedef -2, but
doesn't actually have 65534 sidedefs :)
>Apart from PrBoom, many engines and utilities support this ?
I'm tempted to say "pretty much everything that's still being actively
developed", at least with the qualifier "and is popular enough to be
mentioned fairly regularly on Doomworld". In particular, ZDoom and its
derivatives GZDoom and Skulltag, Eternity Engine, all the derivatives
of PrBoom. Chocolate Doom is an obvious exception; I'm not sure about
Legacy or ZDaemon.
As for editors, Doom Builder and I think Deepsea. Not too sure about
all the Windows editors.
Andre Majorel
> Andre Majorel said:
>>Apparently, it's been done for years but I just discovered that
>>levels exist that use more than 32,768 sidedefs.
>
> Yes, as far back as 2004 (Deus Vult map05)
>
> A few months back I tried to hack Yadex to load a side-limit-breaking
> map from Deus Vult's sequel. I didn't get past the stage of constant
> segfaults but it ran just long enough under GDB to find the secret
> areas I'd missed, which was the point of the exercise. Nevertheless I
> look forward to a version that works properly :)
The change seems conceptually simple (make the sidedef number
unsigned, test for != 65535 instead of != -1, test for < 65535
instead of >= 0, etc.) but tedious (you have to make sure you
don't miss anything).
When I turn the level data into a class, which I pretty much
have to do if Yadex is to ever support undo, I'll probably have
to review every use of Sidedefs[] and friends so it'll be the
time to make that sort of change. It could even happen before
2020 !
>>This is not supposed to work as the sidedef-number field is a
>>signed 16-bit integer (0..32,767 = valid sidedef number, -1 = no
>>sidedef, -2..-32,768 = invalid value). Guess they treat it as
>>unsigned, giving 0..65,534 = valid sidedef number, 65,535 = no
>>sidedef. Good guess ? :->
>
> Yes, with the addition that you need to check for sidedef references
> which exceed the number of sidedefs, and map them to 65535. For
> example GANYMEDE.WAD has linedefs that reference sidedef -2, but
> doesn't actually have 65534 sidedefs :)
Have to see if it's practical to load the level and just draw
the linedef in red if either of its sidedefs is >= NumSidedefs.
I like that idea better than #define SDMAX 65534 /* ganymede.wad */
(or refusing to load the level like Yadex does now, for that
matter).
The minus side is that EVERY use of a sidedef number in the code
has to be preceded by a bounds check. Another reason to turn the
level data into a class.
>>Apart from PrBoom, many engines and utilities support this ?
>
> I'm tempted to say "pretty much everything that's still being actively
> developed", at least with the qualifier "and is popular enough to be
> mentioned fairly regularly on Doomworld". In particular, ZDoom and its
> derivatives GZDoom and Skulltag, Eternity Engine, all the derivatives
> of PrBoom. Chocolate Doom is an obvious exception; I'm not sure about
> Legacy or ZDaemon.
>
> As for editors, Doom Builder and I think Deepsea. Not too sure about
> all the Windows editors.
Without looking at the code, I'm pretty sure that neither DeuTex
nor anything in Xwadtools do.
But every problem has a solution. If someone has the name and
address of the lad who made this stunt popular, some strychnine
and a time machine...