Copy Link
Add to Bookmark
Report
Doom Editing Digest Vol. 01 Nr. 587
From: owner-doom-editing-digest
To: doom-editing-digest@nvg.unit.no
Subject: doom-editing-digest V1 #587
Reply-To: doom-editing
Errors-To: owner-doom-editing-digest
Precedence: bulk
doom-editing-digest Friday, 23 February 1996 Volume 01 : Number 587
The final word (I hope) on thing limits
Re: Flame thrower patch now online
DISproof of gettable
Re: Flame thrower patch now online
145imp.wad followup
Re: New WadAuthor Release!
TC looking for level designers
DeHAcKeD patches...
Re: 145imp.wad followup
----------------------------------------------------------------------
From: LummoxJR@aol.com
Date: Wed, 21 Feb 1996 22:01:43 -0500
Subject: The final word (I hope) on thing limits
As much as I hate to go on here, I think there's more to say in reply to that
last letter.
And hopefully, the debate ends here.
Please, don't reply here in defense of your position, unless you have
something new and constructive to say. I know all of us have had theories
shot down, some which seemed plausible, but we're all sick of the topic and
we've heard the defenses. I wouldn't have replied to this one myself except
that the matter needs clearing up, and new information has come in lately,
along with a new theory.
> My point was that having a thing limit would be consistent with
>having all these other limits. Anyway, id's programming abilities and the
>merits of various ways of implementing concepts don't really matter. The
>DOOM engine does what it does regardless of how good or bad we think its
>methods are. The goal is to find out what it does, how it does it, and
>what the limits are.
Thing limits are NOT consistent with the other types of limits.
In programming, fixed-length arrays are used generally only for temporary
purposes, like calculating what gets hit by a BFG shot, or scaling graphics,
or projecting walls from linedefs (hence the 256 limit), or the like. For
objects like the player, monsters, projectiles, etc., however, logic demands
nothing less than a flexible, dynamic list. This is a programming technique I
use in game programming and many games would just about be useless without
it.
Again, fixed-length arrays and dynamic lists are completely different
concepts and have completely different uses.
Spawned objects would be no different from regular objects here- it's a
dynamic list, so they can be (and quite obviously are) tacked onto it, and
removed when necessary (as with projectiles). The game will not care whether
an object was created when the level started or when it was underway, as long
as it knows what the object is up to and how to take care of its memory
management.
The merits of programming methods are not the issue here, and never were; the
question of which methods are being used is. I'm not holding a seminar on why
one or the other is preferable at certain times, I'm saying that one IS being
used in this case because it's the only possible choice. I'll say it a
million times if I have to: No one would used a fixed array here, even for
spawned objects- which includes projectiles, as they are part of the problem
that sparked the debate. The answer to this particular question of technique
is more than obvious, it's a given.
(As I said, no need to defend your position here. We've heard it all already-
even the stuff I just said is mostly nothing new. This part of the discussion
has gotten into a "Oh yeah?" - "Yeah!" kind of mode; please allow me the
final "yeah" here, but my position on this part is indeed correct.)
> As I see it, there's been mostly speculation (including mine) about
>possible thing limits and if they exist do they contribute to the
instability
>of the patches. Of course speculation leads to testable hypotheses--it's
>just there hasn't been much specific testing reported, other than Drake's
>Imp Mobs (which I think are pointing to a different limit(s) since his test
>haven't been with spawned things).
Drake's imp mobs and Mike's ammo clips are one in the same problem. Drake
reported that the limit exists at around 148, but has since discovered that
it's a little more uncertain than that, leading me to believe that although
this could be handled with a fixed-length array, Doom probably sets up a
quick, temporary list of items (or references to those items in another list)
in a bullet's path; when that list overflows past certain limits (most likely
the length of the program stack), the game crashes.
Spawned things truly have nothing to do with this. Doom is fine with all
kinds of normal projectiles, and they won't overflow the game simply by
existing. All the crash reports directly linked with having too many items
are all about having too many items in the same spot, when either a crash or
a walkover occurs.
Although I only just thought of it, this seems like the most rational answer:
The program stack is being pushed past its limit by overflowing a list set up
by the game (the list could even be as simple as pushing item numbers onto
the stack and then removing them!). Program stacks are tricky, but working
with them at a low level is a necessity for an advanced game; in fact, stack
overflows probably account for most of the crashes we've all observed.
All right, I believe this officially closes the discussion. Keep your fingers
crossed, though, and carry around a rabbit's foot (or just hold an entire
rabbit for four times the effect).
Conclusions:
1. There are no actual "thing limits", except of course when we see Z-malloc
failures from having too little memory; but that's not so much a fixed limit
as it is an inability of the system itself.
2. The crashes caused by Mike's patch- in Doom II that is, where it works-
are caused by bullets or the player interacting with a whole mess of objects
in the same place- which is why Mike even changed the patch to make the ammo
clips disappear after awhile.
3. I too have observed the kind of things Drake described. When I tested
Mike's (original) patch in Doom II, I intentionally tried to put as many ammo
clips in the same place as I possibly could (without my mind going numb from
shooting at a steady pace). The result, after continually shooting at the
imps I encountered (I used the double-barrel on two that were pretty well
lined up), was that the foremost imp died (it must have had about a zillion
hit points left, too!), and the one in the back eventually became
unshootable.
4. Game slowdowns are unrelated to this type of thing, and are the result of
having more objects in play at the same time than the system can handle. This
same type of thing has happened to me in my games; by having too many game
objects, you have to spend more time to process them all.
All of that (well, 1-3 anyway) points to an assumption- a rather reasonable
one- made by the game that more than 100 or so objects would normally not be
lined up in the path of a bullet. This is not as much a limit as it is a
fault of ours, by putting so many objects in the same place when it would
logically stress the game a bit.
So, unless you can speculate on whether the length of the stack itself is
actually the problem, or if it's some other memory technique- in which case
we'll have drifted way off-topic- I don't see anything else that can be said
here.
Lummox JR
please no more! no more!
------------------------------
From: Michael Gummelt <gummelt@pegasus.montclair.edu>
Date: Wed, 21 Feb 1996 22:16:23 -0500 (EST)
Subject: Re: Flame thrower patch now online
Lee,
On Wed, 21 Feb 1996 LummoxJR@aol.com wrote:
> Announcement:
>
> A new, totally cool flame thrower graphics/DHE patch for Doom I & II is now
> available at:
>
> http://members.aol.com/LummoxJR/doomfile.html
>
> Check it out- it's great!
>
> Lummox JR
> now I do graphics
>
Cool, I'll have to check it out. I assume you used the 801
code pointer you've been playing with to make this, right?
Did you give the flamehrower a delay time in the beginning
so you don't get hit by the explosion as soon as you fire?
By the way, Lummox, have you taken a look at my Flamethrower
in Aliens Doom? It fires flames that have a certain range.
The flames also start real fires that injure the player and
monsters. The flames somtimes spread and die out eventually.
Check it out if you get the time.
Mike Gummelt
------------------------------
From: Damien.Wellman@Narrows.Kendra.Com (Damien Wellman)
Date: 21 Feb 96 20:40:29 -0800
Subject: DISproof of gettable
:: From: Albert Alcoceba To: Damien Wellman Subj: DISproof of gettable ::
DD> Actually, Mike is quite correct. Doom's engine has several limitations...
DD> for example, if a level is too big, Doom will crash when trying to load it.
AA> Come on, this thread is not getting us anywhere. If a level is too
AA> big such that Doom won't run it then the level is useless. End of
AA> story, back to the drawing board.
Yes, but if you have more memory, then Doom *will* run the level. But you're
right, this is getting kinda pointless.
... "Portal to another dimension there on the wall..." -- Tom Servo
- ---
* TLX v4.00 *
- --- Blue Wave/DOS v2.30 [NR]
- --
|Fidonet: Damien Wellman 1:262/31
|Internet: Damien.Wellman@narrows.kendra.com
|
| Kendra Communications - FTS <=> Internet Gateway
| When Fido's all ya got, make the best of it.....
| Via-COPLINK 1:343/304 (206)397-6021 Everett WA
------------------------------
From: Yugo Nakai <ynakai@midway.uchicago.edu>
Date: Thu, 22 Feb 1996 02:52:36 -0600 (CST)
Subject: Re: Flame thrower patch now online
For those of you who have (hopefully) stopped the debate about arrays, thank
you -- I was REALLY getting sick of all those useless messages cluttering up
my mailbox.
Maybe my questions have already been addressed here, but while we're on the
subject of 'flames'... <G>
I seem to remember the creator of the flamethrower patch mentioning
that the explosions triggered by the 801 code pointer merely create
explosions at random heights until they hit the ceiling, then die. In my
limited testing, this seems wrong. Being one for total carnage, I warped to
Map 30 of D2, then started firing with reckless abandon with the
flamethrower. Fitting the hit-ceiling theory, the explosions stopped in a
short time when fired in a low-ceilinged area and continued longer in higher
areas. However, when I hit the bottom floor and fired some flames, the 801
explosions didn't seem to diminish at all... the game slowed to maybe 1/3 or
1/2 speed, but no matter how long I waited, the number of explosions seemed
the same. (Although I had so many going that it was hard to tell.) I
noticed that after a certain point, many of the monsters became totally
invisible -- but could still attack. (Needless to say, I was on God Mode.)
I'm not certain, but it didn't seem that the continuous columns of
explosions hurt the monsters -- but it did seem to hurt me if I turned off
God Mode. (Hard to tell on 30.) Eventually, the game didn't crash... but
even on God Mode, the game killed me.
Any thoughts on the elusive 801 code pointer? (And please... don't
fight over it!)
------------------------------
From: "Drake O'Brien" <a13231@mindlink.bc.ca>
Date: Thu, 22 Feb 96 01:36 PST
Subject: 145imp.wad followup
Lummox:
>All of that (well, 1-3 anyway) points to an assumption- a rather reasonable
>one- made by the game that more than 100 or so objects would normally not be
>lined up in the path of a bullet. This is not as much a limit as it is a
>fault of ours, by putting so many objects in the same place when it would
>logically stress the game a bit.
>So, unless you can speculate on whether the length of the stack itself is
>actually the problem, or if it's some other memory technique- in which case
>we'll have drifted way off-topic- I don't see anything else that can be said
>here.
>
>Lummox JR
>please no more! no more!
Why no more? And why circumscribe the topic? I posted a question "answer
this gurus" which introduced a distinct topic, and so far no answer has been
satisfactory. None even comes close to giving a reason why the 'shootable'
bit acts different than the 'gettable' and 'obstacle' bits, that is, why
walking over a clump of 1000 gettable non-obstacles causes no problem, but
shooting the same clump crashes doom.
I think a clue is in my yesterday post when I said how in a couple cases
doom didn't freeze or go into no-clipping but instead crashed to dos with
the error message:
R_subsector: ss 2147450878 with numss = 4
Take 145imp.wad and play it and check out the result when you shoot the
imps, to verify it. Shooting the imps from any angle produces the same
result - you pop into a noclipping mode. The level is a rectangle with main
lines 584x400 (horiz. x vert.). Drag the eastern & southern lines to
lengthen the horizontal to approx 4000 & vertical to approx 2700, and center
the Imp Mob. I found that, taking the Mob as origin then the player
shooting from approx WNW --> W --> WSW produced only a 'pain' reaction in
the mob, but when the player shot from SW --> S -->E -->N -->NW you popped
into noclipping.
I haven't enough knowledge of internal wad mechanics to interpret this (tho'
I can read the signs).
------------------------------
From: Robert Forsman <thoth@cis.ufl.edu>
Date: Thu, 22 Feb 1996 10:19:53 EST
Subject: Re: New WadAuthor Release!
matt.tagliaferri@pcohio.com (Matt Tagliaferri) ,in message <24.33739.5@pcohio.c
om>, wrote:
> WadAuthor Question: how do you handle sector references using cut&paste?
> I believe we've had this discussion before, but consider the example of
> wanting to copy one teleporter sitting inside sector x and pasting it
> inside sector x. You would want all the RIGHT sidedefs to remain sector
> x, but all the LEFT sidedefs to become a NEW sector (number
> CurrentMaxSectors +1). Is this possible, or does WadAuthor assume ALL
> sector references will be new?
My approach with pfme was to ignore the hard problems (such as this) instead
concentrating on creating predictable, robust primitives which could be
manipulated in a cookbook fashion by an intelligent user to perform the more
complex tasks.
The way you would do this in PFME is to copy the sector from sector mode,
paste it where you wanted the new one (It would create a new sector, one-sided
sidedefs, linedefs, and vertices), and then select all the new linedefs and
perform a guess_sidedefs operation on them.
Guess_sidedefs does a topological analysis of the level to figure out all
the "faces" (in a graph sense) and adjusts sector references on sidedefs,
perhaps creating sidedefs at the same time.
This operation would notice that the other side of the linedefs actually
belonged to the enclosing sector and would create generic sidedefs for them.
------------------------------
From: jh32322@ltec.net (Joel Huenink)
Date: Thu, 22 Feb 1996 12:33:52 -0600
Subject: TC looking for level designers
D**M III TC latest info 2/22/96
All Hell is Breaking Loose!
Your Favorite TC D**M3 now has a name.
The All_hell Tc now features:
Weapons
1. Punch kick combo/two bladed bigger chainsaw 3xdamage
2. 4. two desert eagle .50 cal automatic pistols -new 3d rendered graphics
3a. We now have a fully functional auto shotgun with a new 3d rendered graphic.
3b. super shotgun -slightly faster than original
4. M16 Automatic rifle -new 3d graphic
5. New shoulder mounted rocket launcher that fires new rockets with smoke
trails -new 3d graphic
6. Flame thrower with new flames
Monsters
two headed chaingunners
flying barons with lower half of body engulfed in green flames
huge cyberdenons with rocket launcher on both arms
arachnotrons are now rode by chaingunners. when you kill the arachnotron
the chaingunner jumps to the ground and begins attacking you until killed.
Demons are fire red with yellow flames surrounding them.
new monster***
The Pit fiend
A huge muscalar flying demon -new 3d rendered powerhouse!
New trees, Armor,helmet bonuses
Lots of other cool stuff
I will need level designers soon. If you know any good interested level
authors please send me name, e-mail address and location where I can review
their work.
*****************************************************************************
PLEASE REPLY TO ME AT jh32322@ltec.net if you are a interested level designer.
DO NOT REPLY TO THIS LIST!!!
******************************************************************************
I would like to thank the list for this post.
Joel Huenink
jh32322@ltec.net
------------------------------
From: LoCo LikE a PoLLo! <loco@aurora.nscee.edu>
Date: Thu, 22 Feb 1996 15:51:43 -0800
Subject: DeHAcKeD patches...
Hi,
I sent some DeHaCKeD patches on this editing list, but I found
out yesterday that I wasn't subscribed to here. Did you guys get them?
If you did, good. If you didn't, then I'll send it here again.
Later.
_.-~^~-._.-~^~-._.-~^~-._.-~^~-._.-~^~-._.-~^~-._.-~^~-._.-~^~-._.-~^~-._.-~^~
OOOOOOOOO
OOOOOOOOO
_Oooo.____.oooO-- "Hey, at least the hat looks nice!"
O O O -CoOlMAn <loco@aurora.nscee.edu>
O `O O _\
O O ___\
O O \_
/ /~~~
^~-._.-~^~-._.-~^~-._.-~^~-._.-~^~-._.-~^~-._.-~^~-._.-~^~-._.-~^~-._.-~^~-._
------------------------------
From: LummoxJR@aol.com
Date: Thu, 22 Feb 1996 19:24:34 -0500
Subject: Re: 145imp.wad followup
>Why no more? And why circumscribe the topic? I posted a question "answer
>this gurus" which introduced a distinct topic, and so far no answer has been
>satisfactory. None even comes close to giving a reason why the 'shootable'
>bit acts different than the 'gettable' and 'obstacle' bits, that is, why
>walking over a clump of 1000 gettable non-obstacles causes no problem, but
>shooting the same clump crashes doom.
I thought we'd pretty much cleared this up, but as long as it's not about the
other stuff....
Basically there are different things that happen with each of those bits.
For the obstacle bit, this is used when a monster or player is moving, most
likely running a collision test to interpret who's going to walk through
whom, and whether they can or not.
For the gettable bit, a collision test tells the game that if one object that
can pick up items (i.e., the player) is moving onto another object that is
gettable, the gettable thing needs to be checked to see if it can be picked
up. I don't know whether walking over a clump of 1000 items would crash the
game or not, then, since it all depends on how Doom handles the collision
list.
For the shootable bit, though, this is used to see if items that have already
been determined to be in the line of fire are actually hittable, and if so
which one should be the main target, and how high or low the shot should be
made to hit the target. The reason for the crashes and the weird behavior is
that the first step, determining what items are in the line of fire, fails
when too many items qualify; the items in question need not have the
shootable bit on to be included in the list, they merely have to be in the
way.
Those are, of course, all educated guesses. Based on the evidence, they're
the best possible theories as to what's going on right now.
Lummox JR
why yes, I am a programmer
------------------------------
End of doom-editing-digest V1 #587
**********************************
