• FEATURED

View more

View more

View more

### Image of the Day Submit

IOTD | Top Screenshots

### The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

# Programming origin of (bug? feature?) in old game ("Duke Nukem 3D")

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

6 replies to this topic

### #1mike3  Members

Posted 17 August 2013 - 10:59 PM

Hi.

(I'm posting this here because to me it seems game-programming related, but if you think it should be elsewhere, you can move it)

I saw this on Wikipedia:

http://en.wikipedia.org/wiki/Noclip_mode

No-clipping can conflict with other elements of the game. For instance, in Duke Nukem 3D, and the Commander Keen series, having no-clip and walking outside the level area causes death, and if the player has god mode activated the game will be left in an infinite loop or crash due to the way god mode was implemented. In most source ports for Duke Nukem 3D, this problem is corrected and it instead behaves more like Doom.

I'm curious about this. Now, Duke Nukem 3D's source code has apparently been released under free license (GPL), so I suppose one could dig through it and/or run experiments, though I don't feel like doing it right now. What would cause this phenomenon (namely that going out of the level in "noclip" mode kills you), from a programming point of view? As it doesn't seem at first obvious that this kind of thing would occur.

Edited by mike3, 17 August 2013 - 11:00 PM.

### #2DekuTree64  Members

Posted 17 August 2013 - 11:57 PM

Probably a failsafe check, to kill you incase of collision bugs. Better than getting stuck and having to manually restart the game.

I usually check for a deep-below-the-earth Y position, incase you fall through the ground. Also catches going through walls, since there's usually no ground under them,

Maybe Duke Nukem has an infinite ground plane so you can't fall forever, but checks if you get outside the bounding box of the level model. Although the only way you could really get yourself stuck in a situation like that is by walking so far out into nothingness that you can't find your way back... in which case you arguably deserve having to restart manually

### #3mike3  Members

Posted 18 August 2013 - 12:07 AM

Well, if it's a feature, I suppose then one could find it by searching the source code for calls to the player death routine, no?

Edited by mike3, 18 August 2013 - 12:12 AM.

### #4mike3  Members

Posted 18 August 2013 - 12:28 AM

I just got the code from the 3D Realms website and had a look. I believe your hypothesis is in fact correct.

I discovered the following code segment in the routine "processinput" in PLAYER.C:

    psect = p->cursectnum;
if(psect == -1) /* hypothesis: this means "out of range" sector */
{
if(s->extra > 0 && ud.clipping == 0) /* "clipping == 0" = no clipping? I note this variable is modified by the noclip cheat */
{
quickkill(p); /* kill the player */
spritesound(SQUISHED,pi);
}
psect = 0;
}


It looks to be exactly what you said. To check if the player is out of range, and kill them if that is the case. A failsafe, just as you thought.

There also appear to be a few other checks that look like this one.

Thanks for the suggestion!

Edited by mike3, 18 August 2013 - 12:32 AM.

### #5mike3  Members

Posted 18 August 2013 - 12:59 AM

Apparently, I discovered something that said the kill-on-noclip was removed in version 1.4 and 1.5, the last of which is the version for which the released source code is for. So now I'm not so sure as to the meaning of the above code.

### #6Hodgman  Moderators

Posted 18 August 2013 - 03:06 AM

POPULAR

Duke3D's world isn't quite a real 3d cartesian world, because two rooms can exist independently at the same location. It's "portal based", where you're in a room, and the doorways are "portals" to other rooms. You can only see the room you're currently in, and you can see through portals into other rooms.

This lets you construct impossible spaces,

e.g. starting in the red room, you can only see the red room and out into the orange coridoor (and again out into the green room), you can't see the blue room.

If you walk into the green room, you can see back into the orange/red rooms, and into the blue room.

If you walk into the blue room, you can only see it, and back into the green room, but you can't see the red room.

The red and blue rooms exist in the same space, but aren't connected!

In a normal game, given a 3d position, you can ask "which room am I in". This doesn't quite work in this strange portal room -- it has to track your movements from one room to the next through portals, because there are a set of positions that are in both the red and blue rooms, but the player can only be in one of them at a time.

I'm not sure if this is the reason behind the bug/feature, but it could be... maybe... Because the game has to track your movement through portals, if you leave a room via a wall, it would have no way of ever getting you back into a room (as you have to exit/leave via portals).