STARWARS1.WAD, why is it superslow?
Benjamin Hackney
I have a 486 66 I think that should be enough?
bye
-BH
Tom Neff
Benjamin Hackney <bhac...@picard.infonet.net> wrote:
>Has anyone else noticed that STARWAR1.wad is really slow, for doom standards.
>I have a 486 66 I think that should be enough?
It is superslow because it has (a) enormous non-convex sectors, (b) many
lifts which all operate at once, (c) a trillion two-sided lines
separating everything, (d) a quintillion monsters scattered throughout,
and (e) no good REJECT structure to let DOOM avoid checking every
monster on every frame. The miracle is not that it runs slowly, but
that it creaks along as FAST as it does considering the incredible
amount of work the DOOM engine is being asked to do.
--
Tom Neff tn...@panix.com ...!panix!tneff
Public Image
: Has anyone else noticed that STARWAR1.wad is really slow, for doom standards.
: bye
: -BH
It never seemed too slow to me, and then I re-build the .WAD with the
IDBSP (IDBSP10.ZIP on infant2) and it runs a bit faster.
-Scott
David Garry BIGGS - Dave
>From: bhac...@picard.infonet.net (Benjamin Hackney)
>Subject: STARWARS1.WAD, why is it superslow?
>Date: 6 Jun 1994 01:28:10 GMT
>bye
>-BH
It seems fine to me on mty 486/dx50.....But it's got a 1` meg gfx card
which does help a bit....only 4 meg ram tho.
Keith Wilkins
than IDBSP because of the method of generateing the resource. You
can find REJECT10 in infant2 /pub/doom/incoming
Keith
--
" The light at the end of the tunnel just might be an express train . "
Keith Wilkins Voice: (+44) 0952-299000 x 2321
NEC Technologies(UK) Ltd Fax: (+44) 0952-299001
Cal Lott
>Try using REJECT10 to build the REJECT resource it gives a faster WAD
>than IDBSP because of the method of generateing the resource. You
>can find REJECT10 in infant2 /pub/doom/incoming
Why doesn't somebody do this and upload the new level to
infant2 as starwar1b.wad (or whatever) so that a bunch of different
people don't have to waste time doing it themselves?
Just an idea,
-Cal
P.S. I'd do it myself but I'm just starting to learn about PWADs, DEU,
etc., etc., and have never used REJECT10.
--
----------------------------------------------------------------------
"From all us Slackers to all you Boomers ... HAHAHAHAHAHA! WE HAVE
SATELLITE MOUNTED RAIL-GUNS! HEH HEH. Who's laughing now?"-- S. Lang
----------------------------------------------------------------------
Christopher Shamis
: sp...@nectech.demon.co.uk (Keith Wilkins) writes:
: >Try using REJECT10 to build the REJECT resource it gives a faster WAD
: >than IDBSP because of the method of generateing the resource. You
: >can find REJECT10 in infant2 /pub/doom/incoming
: Why doesn't somebody do this and upload the new level to
: infant2 as starwar1b.wad (or whatever) so that a bunch of different
: people don't have to waste time doing it themselves?
I've taken care of it in STARWAR2.WAD
Matt Falk
Eric Fisher
: sp...@nectech.demon.co.uk (Keith Wilkins) writes:
: >Try using REJECT10 to build the REJECT resource it gives a faster WAD
: >than IDBSP because of the method of generateing the resource. You
: >can find REJECT10 in infant2 /pub/doom/incoming
: Why doesn't somebody do this and upload the new level to
: infant2 as starwar1b.wad (or whatever) so that a bunch of different
: people don't have to waste time doing it themselves?
: Just an idea,
Just get starwar2.zip. This includes another star wars level along
with the original and they've been through the reject program
: P.S. I'd do it myself but I'm just starting to learn about PWADs, DEU,
: etc., etc., and have never used REJECT10.
: --
: ----------------------------------------------------------------------
: "From all us Slackers to all you Boomers ... HAHAHAHAHAHA! WE HAVE
: SATELLITE MOUNTED RAIL-GUNS! HEH HEH. Who's laughing now?"-- S. Lang
: ----------------------------------------------------------------------
--
----------------------------------------------------------------
Eric Fisher efi...@moose.uvm.edu
Computer Engineer fis...@emba.uvm.edu
UVM Army ROTC / RANGER Challenge bhv...@prodigy.com
Phone: (802) 862-8082
----------------------------------------------------------------
Cal Lott
Cool! Thanks!
Regards,
-Cal
Richard Ward
>Try using REJECT10 to build the REJECT resource it gives a faster WAD
>than IDBSP because of the method of generateing the resource. You
>can find REJECT10 in infant2 /pub/doom/incoming
>
>Keith
But does REJECT10 create _valid_ (ID compliant) REJECT tables? How are ID's
REJECT tables calculated? As far as I know, IDBSP10 uses the _same_ code for
REJECTS as ID does. Shouldn't we use the resource closest to ID's so that out
maps will behave the same as the regulation maps?
Richard
D.J.S. Damerell
Richard Ward <rrw...@netcom.com> wrote:
>In article <Cr0pH...@nectech-uk.com> sp...@nectech.demon.co.uk (Keith Wilkins) writes:
>>Try using REJECT10 to build the REJECT resource it gives a faster WAD
>>than IDBSP because of the method of generateing the resource. You
>>can find REJECT10 in infant2 /pub/doom/incoming
>
>REJECT tables calculated? As far as I know, IDBSP10 uses the _same_ code for
>REJECTS as ID does. Shouldn't we use the resource closest to ID's so that out
>maps will behave the same as the regulation maps?
No. This is bogus. The REJECT resource merely serves to inform DooM of
when it is not necessary to check line of sight for a given monster. Any
REJECT resource builder which is not actually flawed (flawed == says no
need to make check when the monster could see you were the check made)
will behave exactly the same but at different speeds: IDREJECT is faster
than the obvious kludge (all monsters have LoS checked always) and the next
obvious patch (designer enters maximum possible line of sight, and all
monsters further away than that are unchecked) is midway between (I was
writing it but then out pops IDBSP), but all three give exactly the same
monster behaviour.
--
David Damerell, GCV Sauricon. Green Card flames to: lca...@win.net
djs...@hermes.cam.ac.uk djs...@cus.cam.ac.uk Use hermes before cus, please.
RL: Trinity College, Cambridge. Have you ssaid 'hisss' today? - S'Relss
Michael Olson
>>Try using REJECT10 to build the REJECT resource it gives a faster WAD
>>than IDBSP because of the method of generateing the resource. You
>>can find REJECT10 in infant2 /pub/doom/incoming
>>
>>Keith
rrw...@netcom.com (Richard Ward) writes:
>But does REJECT10 create _valid_ (ID compliant) REJECT tables? How are ID's
>REJECT tables calculated? As far as I know, IDBSP10 uses the _same_ code for >REJECTS as ID does. Shouldn't we use the resource closest to ID's so that our
>maps will behave the same as the regulation maps?
>
>Richard
REJECT10 Turns off Line of sight calculations on sectors within a certain
range (ie. 600 units).
Advantages : Generates a lot less line of site calcuations.
Disadvantages : Line of Site Calculations that are not nessesary.
Monsters you can see but cant see you.
IDBSP Redoes everything then generates line of site calculations based on
what it thinks might be within line of sight. (Not sure of the algorythm
but it could stand some improvement to)
Advantages : Sectors can see farther than a certain distance.
Unnesesary Line of Sight calculations are avoided.
Disadvantages : It can move things around on your map.
It can mess up and make monsters you can see but
they can't see you. (Although not as often)
What I would like to see is an addition mode in DEU where we can edit
which sectors can see which. I am sick of calcuating which bit in which
byte needs to be changed and then going in with a hex editor to change
it. I only wish I was skilled enough to add it myself.
Later,
Michael Olson
<ol...@cs.odu.edu>
She's dead Jim. But still warm.... Do you want to flip a coin for her?
Andrew Lynch
>In article <2stu3a$a...@insosf1.infonet.net>,
>Benjamin Hackney <bhac...@picard.infonet.net> wrote:
>>Has anyone else noticed that STARWAR1.wad is really slow, for doom standards.
>>I have a 486 66 I think that should be enough?
>
>that it creaks along as FAST as it does considering the incredible
>amount of work the DOOM engine is being asked to do.
I too have a DX2/66 and I think it runs at an OK speed... :-)
Of course it is slower than the standard levels, but as mentioned there
is a hell of a lot more in it! Together with the sound patches it is
absolutely awesome!
If you want to see the performance go down the drain, play network DOOM
with a friend who has a slow machine! A 2-player game between my DX2/66
and a DX/33 is perfectly ok, but a 3-player game with the addition of a
486SX/25 really drags performance down into the pits of hell! :-(
Andrew.
Richard Ward
>In article <rrwardCr...@netcom.com>,
>Richard Ward <rrw...@netcom.com> wrote:
>>In article <Cr0pH...@nectech-uk.com> sp...@nectech.demon.co.uk (Keith Wilkins) writes:
>>>Try using REJECT10 to build the REJECT resource it gives a faster WAD
>>>than IDBSP because of the method of generateing the resource. You
>>>can find REJECT10 in infant2 /pub/doom/incoming
>>
>>But does REJECT10 create _valid_ (ID compliant) REJECT tables? How are ID's
>>REJECT tables calculated? As far as I know, IDBSP10 uses the _same_ code for
>>REJECTS as ID does. Shouldn't we use the resource closest to ID's so that out
>>maps will behave the same as the regulation maps?
>
>No. This is bogus. The REJECT resource merely serves to inform DooM of
>when it is not necessary to check line of sight for a given monster. Any
>REJECT resource builder which is not actually flawed (flawed == says no
>need to make check when the monster could see you were the check made)
>will behave exactly the same but at different speeds: IDREJECT is faster
>than the obvious kludge (all monsters have LoS checked always) and the next
>obvious patch (designer enters maximum possible line of sight, and all
>monsters further away than that are unchecked) is midway between (I was
>writing it but then out pops IDBSP), but all three give exactly the same
>monster behaviour.
What is bogus? My question or REJECT10? I was asking if REJECT10 generates
valid REJECT resources. I don't think it does. From what I read in the docs
it just assigns values based on the distance from the center of Sector x and
Sector y, and does not calculate any LOS calculations.
Richard
Lee Witek
> What is bogus? My question or REJECT10? I was asking if REJECT10 generates
> valid REJECT resources. I don't think it does. From what I read in the docs
> it just assigns values based on the distance from the center of Sector x and
> Sector y, and does not calculate any LOS calculations.
REJECT10 *DOES* generate valid REJECT resources is as much as they have the
required effect of reducing the amount of work (ie line of sight calculations)
which has to be done by the DOOM engine therefore making the game faster.
Just because it does not use the same algorithm as id used to create their
levels does not (IMHO) make REJECT10 invalid.
The method REJECT10 uses IS simplistic, I must admit, but it is also
effective on most levels. There are some levels on which it is not suitable
such as those with large open courtyard type arrangements, but no one is
forcing you to use it.
I wrote REJECT10 originally for one purpose: to speed up starwar1.wad which
ran too slowly on my machine to be playable. After processing the wad
with REJECT10 it plays at a decent speed. This is something that IDBSP does
not do (I'm not convinced IDBSP uses true LoS calclations either).
Since last sunday (when I first posted REJECT10 at infant2) I have seen
quite a few new levels (and old ones) that have used REJECT10 and its even
been mentioned in the level editing FAQ which I dont think is too bad
for a utility which (allegedly) generates invalid data :-).
*************************************************************************
Comming Soon to an FTP site near you:
REJECT.EXE version 2.0
Which uses the new "trying to please everyone all the time" Algorithm.
:-)
*************************************************************************
=====================================================
____/|
L.M.Witek \ o.O| ACK!
l...@trousers.demon.co.uk =(_)= THPHTH!
U
=====================================================