Copy Link
Add to Bookmark
Report
Doom Editing Digest Vol. 01 Nr. 582
From: owner-doom-editing-digest
To: doom-editing-digest@nvg.unit.no
Subject: doom-editing-digest V1 #582
Reply-To: doom-editing
Errors-To: owner-doom-editing-digest
Precedence: bulk
doom-editing-digest Monday, 19 February 1996 Volume 01 : Number 582
DISproof of gettable
DISproof of gettable
Re: More on code pointer 801
Thing limits- A programmer's perspective...
Re: Sector Tags 666 and 667
Re: Thing limits- A programmer's perspective...
----------------------------------------------------------------------
From: Albert Alcoceba <alberta@zip.com.au>
Date: Sun, 18 Feb 1996 22:59:11 +1100
Subject: DISproof of gettable
To: doom-editing@nvg.unit.no
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.
Come on, this thread is not getting us anywhere. If a level is too big
such that Doom won't run it then the level is useless. End of story, back
to the drawing board.
Regards,
Albert
... He who dies with the most TAGLINES wins!
* RM 1.31 * Albert! alberta@zip.com.au http://www.zip.com.au/~alberta/
------------------------------
From: Albert Alcoceba <alberta@zip.com.au>
Date: Sun, 18 Feb 1996 22:59:11 +1100
Subject: DISproof of gettable
To: doom-editing@nvg.unit.no
GG> Play Doom ][ map 30 in god mode long enough so that
GG> there are about 200 monsters running around- crash. No mods, but it will
GG> happen.
I have asked a few people to try this... and I've got reports back saying
that for some the game crashed but for others monsters just dissapeared
randomly and no crash occurred.
I have not been able to verify these reports myself but could the result be
dependent on things such as system RAM or Doom][ version?
Regards,
Albert
... I know a good tagline when I steal one.
* RM 1.31 * Albert! alberta@zip.com.au http://www.zip.com.au/~alberta/
------------------------------
From: LummoxJR@AOL.COM
Date: Sun, 18 Feb 1996 12:57:48 -0500
Subject: Re: More on code pointer 801
>One problem with this code pointer seems to be that if used "outside", the
>exploions never stop. So if you make too many, it will slow down the game
>to a crawl, and perhaps even crash it (if you get to 200 things I suppose).
>When designing levels, be sure to keep in mind that continuous explosions
>created with this code pointer will never die out if created "outside".
This
>could be really bad for Deathmatch (and in your patch, if there are a lot
>of barrels outside). Not too big of a problem, but a minor concern to keep
>in mind.
So, Mike, did you actually READ the letter? :D
I said that code pointer 801 does this if used in a rocket explosion, but is
otherwise fine. Whether or not you're in a room with sky texture is
irrelevant. I've used this extensively outside (Doom I, E1M2) with my new
flamethrower patch, with no ill effects. In rooms with high ceilings (often
the case in "outside" rooms), you might have them stick around longer, but
that's it.
I have more notes on this, too:
1. Explosions aren't simply created above the point of origin, as I thought.
They are created randomly until the ceiling is hit (the sky counts too), at
which point a rocket death is used.
2. Explosions created using code pointer 801 do not, as I thought, call frame
799. These secondary explosions seem to be entirely internal, using frames
that don't exist in the table (it's true- only 127, 359, and 799 have the
explosion "look", and altering them has no effect on secondary explosions).
Well, I'm still learning.
Lummox JR
working on new information
------------------------------
From: LummoxJR@AOL.COM
Date: Sun, 18 Feb 1996 12:57:22 -0500
Subject: Thing limits- A programmer's perspective...
The thread on thing limits has gotten huge in my absence, so let me put in my
two bucks' worth. I'm an experienced programmer, and have some important
insights here.
1. The gettable thing patch crashes on my system, even with my new 486DX2-80
(I was running a 486DX-33), but it has nothing to do with thing limits. It
has to do with bit 4. Though I have yet to check Doom II for this (I will
today, I hope), I'm quite convinced of what is not the problem.
2. There may or may not be some kind of limit, but around 200 sounds a bit
moronic. I've played levels with a lot more than that.
3. Pain elemental attacks were mentioned here, that after a while no more
lost souls are spawned. This is true, but it's entirely unrelated to the
discussion at hand. I think it has to do with how death frames are handled,
and perhaps a limit set within the Doom engine to keep too many lost souls
from being spawned, creating a Z-malloc failure or game slowdown.
>Well, I think that there is an item table created at startup, and then there
>are x number of empty spaces for things that spawn onto the map (changes
from
>alive to dead, and dead to alive too?) If the list grows too big, it would
>do a Win95 (ie: overwrite the program code in memory), and it crashes.
4. This is total rubbish (flame not intended), despite a lot of people
supporting its logic. Doom is an advanced game, programmed to make the best
possible use of available memory. It would not use a fixed-length array for
spawned objects. Not only is that fifth-rate programming, but nobody would be
fool enough to let the program overfill the buffer. Why, if Doom knew exactly
how many items it could spawn, would it not refuse to spawn objects beyond
the limit? If I made an array of 200 slots, I'd make sure my program didn't
fill more than 200 slots. Trust me, the guys at ID are not stupid. Nobody is
that bad a programmer if they can create something like Doom.
As I said, the whole idea of a fixed array is dumb itself- I've been playing
the game long enough, and writing games of my own, to be convinced that
nobody would do that in a game of this caliber (the BFG effect of only
hitting 20 people, though, is quite a different problem- a fixed array seems
logical there, since there need be only a few targets, something has to keep
track of them, and variable-length lists are hard to maintain).
5. Someone needs to define "crash" here. When I say crash, I mean that
everything stopped dead (except possibly sounds and music), or that the video
got screwed up and made a horrifying sound on the sound card (it happens), or
some other lock-up. But the rest of you, Mike especially: Are you talking
about a Z-malloc failure, another kind of spontaneous exit from the program,
or a lock-up? Please be specific.
6. Many of you have mentioned failures of Z-malloc here, and that only makes
sense. Or something similar like the game just kicking you out. This does
happen with too many items, or when too much is going on. And it's entirely
related to memory.
7. Mike, your problem is odd, with 16M of memory. Considering that some
people have reported limits and others haven't, regardless of large memory
size, my best guess is that you don't have enough conventional memory (i.e.
under 640K), or for that matter extended memory (above standard 640K, up to
1M).
That's my expertise here, and it's good. We can spend weeks poring over
details of whose game locks up and whose doesn't, but for the most part it
seems to be a system-specific thing. And without clarification on whether
Z-malloc is always involved, nothing further can be said constructively,
anyway.
As for gettable projectiles, I hope to have an answer soon by installing Doom
II.
Lummox JR
right for a change
------------------------------
From: "jco@io.org" <jco@io.org>
Date: Sun, 18 Feb 1996 13:18:09 -0500 (EST)
Subject: Re: Sector Tags 666 and 667
On Wed, 14 Feb 1996, Jim Elson wrote:
> >I tried using the tags 666 and 667 but the sector would not move I was able
> >to use a switch to lower the sector so I guess the sector is Ok.
>
> >Can anybody suggest what I might be doing wrong or better can point me to
> >some documentation re special sector tags and how they work.
>
> They only work on map07 with those functions/monsters.
In case anyone is wondering, these special tags work in conjunction with
code-pointers. For example, in the Baron's death sequence, there is a
code-pointer which lowers the special sectors. I believe that the same
is true for the rest of the enemies that work this way.
John Orazem <jco@io.org>
------------------------------
From: David Damerell <djsd100@hermes.cam.ac.uk>
Date: Sun, 18 Feb 1996 18:55:23 +0000 (GMT)
Subject: Re: Thing limits- A programmer's perspective...
On Sun, 18 Feb 1996 LummoxJR@AOL.COM wrote:
> 3. Pain elemental attacks were mentioned here, that after a while no more
> lost souls are spawned. This is true, but it's entirely unrelated to the
> discussion at hand. I think it has to do with how death frames are handled,
> and perhaps a limit set within the Doom engine to keep too many lost souls
> from being spawned, creating a Z-malloc failure or game slowdown.
ISTR there is a separate hard limit on the number of lost souls on a
level - something like 30 - levels can start with more, but if they do,
no more will be spawned.
> 4. This is total rubbish (flame not intended), despite a lot of people
> supporting its logic. Doom is an advanced game, programmed to make the best
> possible use of available memory. It would not use a fixed-length array for
> spawned objects. Not only is that fifth-rate programming, but nobody would be
> fool enough to let the program overfill the buffer. Why, if Doom knew exactly
> how many items it could spawn, would it not refuse to spawn objects beyond
> the limit? If I made an array of 200 slots, I'd make sure my program didn't
> fill more than 200 slots. Trust me, the guys at ID are not stupid. Nobody is
> that bad a programmer if they can create something like Doom.
I'm sure you're right, _but_ it's worth remembering everyone has brain
failures.
- --
David 'Gotterdammerung' Damerell, GCV Sauricon. djsd100@hermes.cam.ac.uk.
Trinity College, Cambridge University. CUWoCS President. All Hail Discordia!
|___| Thousands of people would be willing to die for their religion. |___|
| | | Think of it as evolution in action. | | |
------------------------------
End of doom-editing-digest V1 #582
**********************************
