[Danukem]

It has been like this since 2006, and probably since the first eduke32. It has happened to me on every OS and every system I have used in the last 5 years, and only in eduke32.

When eduke32 gets overwhelmed (usually by a large number of sprites spawning at once), the screen stops updating. You can still hear the action going on, and when the screen finally unfreezes you can see that time has passed and the game world has been updating at the usual rate. Depending on the severity, the halt to screen updates can last anywhere from half a second to a full minute.

Any ideas?

[The Dukenator]

And you're bitching about this now?

[Danukem]

Yes, I'm bitching about it now. I complain about things when they cause problems for me, and right now it is causing a problem for me.


I know that the total number of sprites in the map is not an issue. Maps can run smoothly when near the 16384 limit. In the map where this problem is currently manifesting, there are only about 1600 sprites at start. With all the effects going in game that spawn sprites, the total reaches a peak of about 8100, still only half the limit.

My perception is that something is getting overloaded due to too much going on at once, and then the renderer ends up spinning its wheels and producing nothing while in gameland things go on as usual.

EDIT: I just did a test where I made every sprite in the game invisible (cstator 32768 in EVENT_GAME). The rendering stoppage still occured, but it wasn't quite as severe. The fact that it occurred at all when there was almost nothing being rendered (it's a simple area of the map with hundreds of monsters) makes me think that the problem does not originate with the renderer. I have been using Polymost.

[Danukem]

Now here's an interesting tidbit, although I don't know what it means. Polymer actually performs better with all the sprites invisible than Polymost does. There were still freeze-ups, but they were shorter. But with sprites visible (normal) Polymer was significantly worse than Polymost.

[Plagman]

If you send me a case that does that, I can easily profile it and tell you what exactly causes the lag. I suspect it's just an operation in gameland (eg. spawning all the sprites) that takes _very_ long for some reason, and then gameland has to catch up all the tics it missed before it can afford to send one frame to the renderer.

[TerminX]

When this happens, it's usually (always?) caused by just too much CON code running at once. The renderer produces nothing because the game loop doesn't make it back to the point at which a frame is drawn often enough. The sounds keep playing because they tend to just be buffered data that's accessed by another thread.

When whatever condition is causing the lag is over, it just looks like the game was running normally while it was happening because the time between the last execution of the main loop is compared with the current time and any missed cycles through it happen then.

[Danukem]

That seems plausible, except that I can hear that things have resumed in gameland and are going on normally looong before anything gets rendered again. The gameland halt only lasts for a moment as far as I can tell. I'm thinking that frames could be sent to the renderer much sooner than they are if it were handled better.

Anyway, as an admin you have access to the private wgr2 forum. You can download the TC and the latest patch in the downloads thread there, then I can post the map with the player start in the right position. All you have to do at that point is use "god" and "give all" in the console to beef up, then run out there and wake up as many monsters as possible while spamming flamethrower, or rpg or some other nasty weapon. Of course, your computer may be so powerful that it won't happen for you.

EDIT: I was writing my reply to Plagman and TX's post had not appeared yet.

[Danukem]

On my current system, when it gets to 1000+ active actors (monsters, projectiles, jibs, etc.) I'm at risk for a lag out. I imagine on other systems the danger zone is higher or lower.

So what is the best way to handle it, other than insisting on maps that don't have 500 monsters attacking at once? Here are some ideas that occur to me:

-Forcing some monsters to stay asleep (statnum 2) if too many are active. The trouble is deciding which ones have to nap so it doesn't look too ridiculous.

-Making monsters take turns. Like, monsters 0-100 are statnum 1 this tic, next tic it is monsters 101-200, and so on.

-Using inittimer to literally slow the game down in response to intense conditions. IF that would help, which it might not.

[Plagman]

DT, rev 1817 should be better in that regard. However in the test scene I'm still seeing some tics that take _seconds_ to be computed, with 99% of the time being spent inside neartag. Could it be that there's a bug in your code that causes a lot more calls to this than it should? Keep in mind it can be a very expensive operation.

[Danukem]

 Plagman, on Mar 2 2011, 10:59 PM, said:

DT, rev 1817 should be better in that regard. However in the test scene I'm still seeing some tics that take _seconds_ to be computed, with 99% of the time being spent inside neartag. Could it be that there's a bug in your code that causes a lot more calls to this than it should? Keep in mind it can be a very expensive operation.

Thank you.

I'm using neartag to make every non flying monster check for lotag 1 sectors in front of them and not enter those sectors, because I want them to avoid water but I don't want to confine the monsters to a single sector (not stayput).

I could reduce the use of that command by a huge amount since they all use it every tic. It's not cool to have 600 undead warriors halting the game because they are all obsessing about water in an area where there isn't any.

EDIT: Instead of using neartag, what I'll do is check a certain number of units in front of the monster and see if that point is in a lotag 1 sector. If I'm checking for just that one thing with my own algorithm I'm guessing it will be a lot less expensive than doing all the stuff that neartag does.

[Plagman]

That sounds good, though if you're saying every skeleton uses neartag every tic no matter what happens, it's weird that it's causing such spikes. There must be something that triggers a pathological case, probably in the implementation of neartag() in the engine or possibly in your code.

[Danukem]

 Plagman, on Mar 2 2011, 11:31 PM, said:

That sounds good, though if you're saying every skeleton uses neartag every tic no matter what happens, it's weird that it's causing such spikes. There must be something that triggers a pathological case, probably in the implementation of neartag() in the engine or possibly in your code.

I'm about as sure as can be that it is not my code. The command is used exactly once, in a state called "avoidwater". That state is called by another state, "monsterai", which is called exactly once per tic by every monster. I double checked to make sure that the states aren't being called multiple times with loops or redundancies.

[Plagman]

Yeah, looks like that case sometimes triggers a bug inside neartag() that makes it take insanely long to finish. I'm worried that even if you're making the calls to neartag() less frequent, the bug might still happen. However given the general chaos I'm not sure how to make it happen reliably and how to debug it. When neartag() isn't doing the insane thing, the general slowness seems to be caused by more reasonable stuff like clipmove() taking like 9% of the time, etc. In this case the above change to EDuke32 should kick in and allow the display to still update while the game slows down a little.

[Danukem]

As I was saying in the edit to my last post, I will not be using neartag any more. I will simply use rotatepoint to find a point 1000 units in front of the monster and check the tag at that coordinate.

[Danukem]

I just tried the problem map using my new method without neartag and deliberately using the older eduke before your revision. There were still halts, but on the average they ended much sooner. Combined with the new eduke revision the situation should be very much improved.

[bullerbullerseven]

In my map i simply make the sprites go invisible when they are out of player sight. That makes it possible for me to put in much more sprites.

Just a suggestion.

[Danukem]

 Jhect, on Mar 3 2011, 04:56 PM, said:

In my map i simply make the sprites go invisible when they are out of player sight. That makes it possible for me to put in much more sprites.

Just a suggestion.

That doesn't make sense. If the sprites are out of sight then they aren't being rendered anyway, so how would making them invisible help?

[bullerbullerseven]

The sight i am talking about is the player visibility. Keep in mind that this is a trick for BIG levels. So if you can't even see the end of the room because of visibility making the room darker, then why not just make them invisible so it won't lag any more. Tested it, and it works very good.

[Danukem]

 Jhect, on Mar 4 2011, 04:34 AM, said:

The sight i am talking about is the player visibility. Keep in mind that this is a trick for BIG levels. So if you can't even see the end of the room because of visibility making the room darker, then why not just make them invisible so it won't lag any more. Tested it, and it works very good.

OK, that makes sense now.

[bullerbullerseven]

I still like mapping effects better as it doesn't make me lag i wish i could make good looking plants and stuff without massive lag :S anyway, this makes it possible without too many problems I am building a massive grass area level with hills and stuff, the trees really makes it look nice!

[Scott_AW]

I'm thinking about making my grass and rocks vanish after a certain distance, since I use a lot of them and there is some lag, mostly due to the grass. I'll keep the trees showing, because they show up nice against the backdrop and would look funny suddenly appearing, where as the short stuff gets blended with fog.

Well, only on my Netbook and weaker computers it lags, but I like the idea. I already have emitters spawn and cannons shoot depending on the player's distance from them to save from lag.

Personally I get lag in Polymost when you are in a room with a window outlooking a valley or something, don't know why that is, but its not like a lot of sprites are in the area when it happens either. Usually I have a transparent window.

[bullerbullerseven]

Do you know how to do it scott? I don't know if you are interrested in .con

[Scott_AW]

I know how to make them go invisible, so its pretty much a simple con code for them

It's already an actor for rocks and grass, so that shouldn't be a problem.

Would be something like

ifpdistl #
cstat whatever
else
cstat invisble

[bullerbullerseven]

Yea, but for some reaon, the ifpdistl command gave me problems, i didn't know why, so i just used the dist command instead, this takes the 3d distance, you can take distl instead, that only takes the 2d distance, a distance of 50000 fits very good for a visibility of 2.00

state distfade
dist actordist THISACTOR playerid
ifvarl actordist 40001 { cstat 0 }
ifvarg actordist 40000 { ifvarl actordist 40601 { cstat 2 } }
ifvarg actordist 40600 { ifvarl actordist 41201 { cstat 514 } }
ifvarg actordist 41200 { cstat 32768 }
ends

get players id into playerid. make actordist a gamevar per actor.

If you want an actor to go invisible when at long distance, just type state distfade in their actor code. the cstat 2 and 514 are just for better looking effects xD

[Scott_AW]

I found my grass vanishs best at 12k, 16k for rocks.

I use a bit more fog and less visibility, plus after 12k the grass's smallest LOD is practicly invisible so it helps just to remove it.

It helped some of the performance, this is in Classic mode mind you. So maybe its just the presence of the actors slowing things down. I haven't tried making them useractors instead of actors yet.

I got my method to work, but I"ll try that 2 and 514 to see what it looks like.

[bullerbullerseven]

It just makes them disappear more smoothly. I just like it better

[Scott_AW]

Maybe I'll try it out on things like trees and enemies, see how that goes.

My dumbass forgot that you can't make voxels transparent in the first <.<

[Stabs]

You could try using 2d sprites for trees at certain distances

[Scott_AW]

That could work too, have to update the original sprites to match the newer voxel ones. The originals were without shading.