Doom2 Map 13 "Downtown" slow-down

psyren

This is a weird one. Since I haven't played the original Doom2 levels for probably 6 years, I decided to give them a go again. I am having a problem with massive slow-down in only this level, map 13. Using Beta 6.6, but posting here as I can't say it is version specific.

It runs fine until I teleport up to sector 240 (near the centre, R of blue key, N of blue door). From that point, the game slows to a stop except for the music/sounds. (Well almost a stop. Took almost a minute for the tab key to bring up the map, or the escape key to bring up the exit menu.)

I had to make quicksaves and loads to finish. Strangely, those keys worked fine. F6, Y, F9, Y and it returns to normal for 10-20 seconds. Got through and started map 14, and no problems at all. Restart the computer and it does it again in Map 13 though, even restarting the level.

So I've never seen a slow-down like this, and wondering what could cause it, and if someone else can confirm it. I could send somebody a saved game to check if that would help. It does it consistently.

System:

Windows XP SP2
Pentium dual core E5200@ 2.50GHz
Gigabyte G31M-ES2C
1GB RAM
ATI Radeon HD 4650 video
RealTek High Definition Audio (on Motherboard)

No add-ons except jDRP

JonusC

Sounds like a memory leak (

Let me install the new 6.6 and give it a go, thanks for describing in much detail. I'll edit this post with my results.

psyren

Thank you, Jonas.

I knew someone would eventually see this. Probably we all play PWADs since the old maps are to familiar to be much fun. (Although, playing the original was the first thing I did after discovering JDoom. It was almost like a completely new game.)

Well I had to look up 'memory leak' and found that to be way over my head. That certainly sounds like the symptoms. I didn't have FPS on to see, but could see when it started and then quickly get worse. It never bogged down totally though. No crash, and I never had to ctrl+alt+del to get out.

I can't remember now, but when I was learning to map I read that there is some trick used with the sky in that map. Found it, scroll down to "Buildings of Different Height" at this page.

Where I teleported to is a shorter building that must use this trick, as the doorway in/out actually has 2 floors and ceilings over each other, and maybe beta 6.6 is having a problem with it.

I don't believe I have ever tried using this in a map, so maybe I will start up Wad-Author and make a test level.

edit:
I guess that area is not using 2 floors/ceilings, so trying to find where in this map the trick is used. Maybe this is not the trouble...

edit 2:
As a test, I separated map13 from the IWAD and played it as map01. I only extracted it and changed the map number with XWE, and it ran perfectly, so whatever the problem was, it must have had nothing to do with this map at all.

JonusC

I havn't tried it yet, but I should of asked instead of assuming... you have tried it without the jDRP, havn't you? It might be something silly like a particle death being too high.

psyren

I believe that may have been the problem, Jonas C.

I had not tried it without jDRP, but that fixed it. Loaded my save without it and played through perfectly. Enable it again, load my save, and it starts the slow-down within 30 seconds.

So, what would explain why other test games with the same map did not reproduce the error? Not having the exact same 'partical death' timing - one death still occuring as I stepped onto the teleporter and immediately caused another at a higher location?

JonusC

Sorry, I was just speculating. By particle 'death' all i ment was, the technicals of the jDRP might have the lifetime of each particle to be too high, I was just babbling as I don't even know what things use the particle engine (Lights I suppose?) but we'll have to find out whether its the definition code in the jDRP addon, or if it's the Doomsday engine doing something wrong.

I was speaking program code, but it isn't even educated so don't worry too much about it ) I suppose we'll have to try individual things from the jDRP and also look at max-verbose logging...

psyren

Well, I know you are not the expert in Doomsday, Jonas, but more knowledgable and logical than I am. I had not even considered that the jDRP might have anything to do with the problem, so that was what I was commending you for.

Now I can take a more scientific approach, checking one box at a time and playing that 'corrupted' save until I find the one that causes it. Of course, once that item is found it will need to be tested by itself, and may prove to be a combination of resources together rather than a single part.

Could be rather time consuming with 115 items in the box. My algebra is not good enough to calculate how many possible combinations there are, but at least I can help to narrow it down a bit.

JonusC

psyren wrote:

Well, I know you are not the expert in Doomsday, Jonas, but more knowledgable and logical than I am. I had not even considered that the jDRP might have anything to do with the problem, so that was what I was commending you for.

In that case, thank you :P

psyren wrote:

Now I can take a more scientific approach, checking one box at a time and playing that 'corrupted' save until I find the one that causes it. Of course, once that item is found it will need to be tested by itself, and may prove to be a combination of resources together rather than a single part.

My algebra sucks too, but instead of trying one at a time it is technically quicker to do it like so:
a) Enable 50% (half) of them and the other half unchecked, and test your savegame
b) If the slowdown does not occur, go back to a) and do it for the other half, otherwise continue
c) You already eliminated half of the possible culprits. Of the half you now have selected that made the slowdown occur, uncheck half of THEM. Now you only have 25%, one quarter of the full 155 selected that could be the possible culprit. And etcetera...

However, there may be more than 1 specific option causing it. That makes above method tricky. So try to do it in chunks by the "type" of resource instead. I would do it, but i've been busy. I'll give it a go tomorrow though

It might also be specific to ATi cards, I didn't realise that. I have a 9600GT so it'll be worth me to test it anyway.

psyren

Jonas C wrote:

It might also be specific to ATi cards, I didn't realise that. I have a 9600GT so it'll be worth me to test it anyway.

Another thing I hadn't considered. It did cross my mind that a memory leak might be able to affect the video card buffer and not just RAM. I wasn't thinking that different hardware would process applications differently, but they must. I hope it is not another ATI issue.

I cannot duplicate what happened in any new game, so if you want to experiment also, then you'll need the save where I broke it: http://numerometria.com/doom/66bad13.zip (47KB 'DoomSav1.dsg')

And, I just posted a general suggestion for a Snowberry GUI improvement, after finding this checkbox ticking to be a royal pain in the arse.

sonicdoommario

When the game started to slow down, did it start when the floors around you were lowering?

I've had similar problems (no add-ons). In Plutonia Map02, when you hit the switch at the start to lower the floor you're on, the game slows down big time, even if I change it to the smallest resolution possible. In Plutonia 2 Map30, when the floor in the final room lowers to the final boss, the game slows down.

3.4 GHZ Pentium 4
2.25 GB RAM
ATI X700 (256MB PCI-Express)

JonusC

It only happens in that savegame? And doesn't occur when you start a new game and warp to the map? OK that's odd. Was the savegame from a previous version of Doomsday engine or something like that?

sonicdoommario, I believe the slowdown you're experiencing may be related to something else - since psyren already concluded it was the jDRP causing it yet you don't have it enabled.

I can confirm this bug/issue on my machine too. See below for the codebox of my original post after this, it was a rant and is completely irrelevant [see next post].

- Windows 7 Ultimate x64 [MSDN Final Build 7600]
- Doomsday Engine v1.9.0 Beta 6.6
- jDRP v1.0 Enabled
- Doom 2 Map 13
- Athlon X2 5200+, 2GB of DDR2-1000, nVidia GeForce 9600GT

When I run this map with the jDRP at my monitor's native res of 1680x1050, it just runs like absolute garbage all the time. Well not THAT bad, it probably ranges between 15-20fps. So i ran this test in a 1024x768 window which was smooth.

As soon as I loaded the savegame psyren shared in this post, I didn't even have to move (I just mlooked around) and the framerate exponentially decreased over a period of about 12 to 15 seconds, after which the game was virtually at standstill (0.1 FPS I would guesstimate).

There is obviously some problem with either 3D models or another aspect of the jDRP pack, since i can't even play the game at 1680x1050 at all in any level with it enabled, and it's causing this massive slowdown in this particular map. Level 2 Logging did not shine any light on it, but i've attatched the log just incase (it's 476KB, zipped to 38KB).

Since we don't know if this is a legitimate bug in Doomsday or not yet, a opposed to changes required to jDRP definitions, I won't whinge and rant about this quite yet - at least until we can pinpoint the exact culprit, and I try some things to try and remedy it. So if any of the dev's are watching this thread, let us do our part and try as hard as we can to pinpoint it down (I will do so over the next 24 hours and post back here).

I do, however, need to refresh myself on some of the advanced console commands and whatnot. I have tried turning down all the graphic related settings in control panel - particles, halos, lighting, everything was on the lowest possible value or completely disabled where possible (models) - and while it seemed to help, it might have been a placebo (was barely noticeable probably only because I was hoping it to be the cause). Even though the jDRP was still loaded, it looked nearly like original Doom and the grinding-halt effect still took place.

What further suggests this may be an engine bug is that, unlike psyren who had to quickload his game repeatedly as if to "reflush" the game every 10 seconds or so, all I had to do was press ESC to go into the menu - when I went back into the game, FPS went back up to 20 or so then degraded back to <1fps over about 5 seconds. Repeatedly doing this had the same effect over and over again.

doomsday.zip
    Level 2 log dump for slowdown scenario
    (37.01 KiB) Not downloaded yet



EDIT: The log does have many errors similar to this:

Code: Select all
    P_MaterialNumForName: "COMPUTE1" in namespace 0 not found!


...although I don't think it's related.

Hmm...

JonusC

The cause of said slowdown is the Mancubus Fireballs, that is - jdrp-mancfireball.1.01.pk3

psyren, just disable that one item and you're good to go

I have no idea how to fix it though I assume it's something in the DED, the Model or PCX graphics wouldn't cause this kind of thing [right?]

Psychikon

JonusC wrote:

The cause of said slowdown is the Mancubus Fireballs, that is - jdrp-mancfireball.1.01.pk3

psyren, just disable that one item and you're good to go

I have no idea how to fix it though I assume it's something in the DED, the Model or PCX graphics wouldn't cause this kind of thing [right?]

I just looked at the DED for it, and guess what I found!

#------------------------------------------------------------------
# PARTICLE DEFINITIONS

# Vapour Tail

Generator {
  State = "FATSHOT1"
  Flags = blendadd
  Center {0 1 0}
  Speed = 1
  Speed rnd = 3
  Spawn age = -1
  Max age = -1
  Particles = 4
  Spawn rate = 1
  Spawn Rnd = .4
  Vector { 0 0 0 } 
  Vector rnd = 3
  Presim = 20
  Distance = 2048
  Stage {
    	Type = "pt_point" 
	Flags = bright
    	Resistance = 0
    	Radius = .1
	Color { .9 .01 .01 1 }
  	}
  Stage {
    	Type = "pt_point"
	Flags = bright
    	Tics = 1
	Rnd = .4
    	Resistance = .1
    	Radius = 21
	Color { .7 .01 .01 .9 }
  	}
  Stage {
    	Type = "pt_tex07"
    	Tics = 3
    	Resistance = .1
    	Radius = 12
	Color { .6 .01 .01 .6 }
    	Resistance = 0.01
  	}
  Stage {
    	Type = "pt_tex07"
    	Tics = 1
    	Radius = 6
    	Bounce = 0
    	Resistance = 0.1
    	Gravity = 0
    	Color { .5 .1 .1 .3 }
  	}
  Stage { 
    	Type = "pt_tex07"
    	Radius = 2
    	Color { .1 .1 .1 0 }
  	}
}

Generator {
  State = "FATSHOT2"
  Flags = blendimul
  Center {0 1 0}
  Speed = 1
  Speed rnd = 4
  Spawn age = -1
  Max age = -1
  Particles = 6
  Spawn rate = .2
  Spawn Rnd = 0.4
  Vector rnd = 10
  Presim = 20
  Distance = 1536
  Stage {
    	Type = "pt_tex07"
    	Tics = 2
    	Resistance = .01
    	Gravity = -.01
    	Radius = 1
	Color { .15 .3 .3 .01 }
    	Resistance = 0.01
  	}
  Stage {
    	Type = "pt_tex07"
    	Tics = 2
    	Resistance = .01
    	Gravity = -.2
    	Radius = 12
	Color { .15 .75 .75 .7 }
    	Resistance = 0.01
  	}
  Stage {
    	Type = "pt_tex07"
    	Tics = 2
    	Radius = 12
    	Bounce = 0
    	Resistance = .1
    	Gravity = -.3
    	Color { .15 .3 .3 .1 }
  	}
  Stage {
    	Type = "pt_tex07"
    	Tics = 8
    	Radius = 12
    	Bounce = 0
    	Resistance = .1
    	Gravity = -.3
    	Color { .15 .3 .3 .01 }
  	}
  Stage { 
    	Type = "pt_tex07"
    	Radius = 12
    	Gravity = -.3
    	Color { .01 .01 .01 .01 }
  	}
}

State-based generator with infinite lifetime! So the mancubus fireballs must be allocating the same amount of particles each state without wiping them clean. This might explain the slowdown with the fireballs...
There's no static flag on either of them, so that it will cause the generators to be replaced when the max generator limit is reached, but it should still leave them allocated until such a time when they are replaced. So it gives the effect that there's nothing wrong, but there may be something wrong... Maybe change them to mobj-type generators and up the particle count appropriately to necessitate 12 or so sources(two mancubi shooting six fireballs at once should be enough, right?)
The smoke may not want to be continuing until the very end of the explosion, in which case the "noptc" flag should be set slightly after the onset of the explosion?

EDIT: A formula for how many particles are needed could go as such:
Particle life * spawn rate * number of sources

So say the most a particle can last is 50 tics, and the most it spits out is 2 per tic, so that's about 100 possible at once in one source. Since the particles allocated are distributed throughout each source in a mobj-type generator, allocate as many as are necessary for as many objects as you want emitting them before it begins to have less particles. Don't forget, though, (I think) that the particles are already alloted once the generator is created, so don't allot like 1,000,000 particles! In this example case, if we have a torch or something looking just right, and you think that the most a level has is 10, then just multiply the 100 by 10. 1,000 must be alloted in this case. Make enough sense?

JonusC

Lol dude, check my second (or third) post in the thread. I think I remember saying "maybe there's a particle with an infinate spawn lifetime" or something like that (too lazy to check). That wa a lucky guess! As soon as I realized it was the jDRP causing it, I assumed this - the exponential drop in framerate is something any particle engine would cause in any game if there was a generator not destroying when it should. That good sir is about as deep as my "basic understanding" of these game engines go.

I'm glad your eagle eye came in to save the day Psych.

Psychikon

OK, now there are two ways to fix it.
If you make them mobj-defined, then it'll only take two generators total to keep it steady.

Change the 'State = "FATSHOT#"' lines on the "FATSHOT1" and "FATSHOT2" generators to

Mobj = "FATSHOT"

(the object name).
Since they're both on the same mobj (not sure if it's necessary for mobj-type or only state-type) change the flags on the second generator to 'Flags = blendimul | extra' so that it's also added in addition to the last one.
Particles for each one:
1-

Particles = 60

which is 5 particles * 2 manc fireballs * 3 manc bursts * 2 mancs firing at the same time which is 12 sources
2-

Particles = 72

which is 12 (sources) * 6, which is how many (like 5) which will be on screen at the same time for each source, depending on the tics each particle lives and how rapidly they're spawned

Because presim is used to think ahead for the state-based ones, I'm not sure it'll look exactly the same for the mobj-type ones, and since I think there are enough states to accomodate so many at a time, PERHAPS ONLY changing the max ages like so would suffice:

1- (4(tics for FATSHOT1) * 1(the spawn rate)) + 5(max particle life) = 9, but you could probably round it up to 10 tics to be safe, so

Max age = 10

2- (same formula) (4*.2) + 26 = 26.8 rounded up to like 27 or 28

Max age = 28

JonusC

you little ripper! Thanks for that Psych, MUCH appreciated. Ill be sure to try them out and report my results. Thanks again!