MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001952Zandronum[All Projects] Bugpublic2014-10-09 19:432014-12-28 13:39
ReporterTribeam213 
Assigned ToTorr Samaho 
PrioritynormalSeveritycrashReproducibilityalways
StatusassignedResolutionopen 
PlatformMicrosoftOSWindowsOS VersionXP/Vista/7
Product Version1.3 
Target VersionFixed in Version 
Summary0001952: Extreme lag from an old wad
DescriptionSo I've been going through a lot of old mods lately, when I came across this lag problem in supersonicdoom

On Map28 there is a room full of fans, whenever you walk in and the fans activate, the game starts lagging to about... 0 fps...

Tried to figure out why it happens before I posted this report, but couldn't reproduce the problem in my own test map.

This happens in both 1.3 and 2.0
Does not happen in ZDoom or GZDoom
Steps To ReproduceAt the start of the map, turn on noclip, turn 90 degrees to your left, and head straight.
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2014-10-09 19:43Tribeam213New Issue
2014-10-09 19:55DuskNote Added: 0010434
2014-10-09 19:55DuskAssigned To => Dusk
2014-10-09 19:55DuskStatusnew => feedback
2014-10-09 19:55DuskAssigned ToDusk =>
2014-10-09 20:01Tribeam213Note Added: 0010435
2014-10-09 20:01Tribeam213Statusfeedback => new
2014-10-09 21:03DuskAssigned To => Dusk
2014-10-09 21:03DuskStatusnew => assigned
2014-10-09 21:04DuskNote Added: 0010437
2014-10-09 21:05DuskNote Edited: 0010437bug_revision_view_page.php?bugnote_id=10437#r5642
2014-10-09 22:10DuskNote Added: 0010441
2014-10-10 01:24DuskNote Added: 0010444
2014-10-10 01:24DuskStatusassigned => needs review
2014-10-10 01:34DuskNote Edited: 0010444bug_revision_view_page.php?bugnote_id=10444#r5650
2014-10-10 01:34DuskNote Edited: 0010444bug_revision_view_page.php?bugnote_id=10444#r5651
2014-10-11 13:00Torr SamahoNote Added: 0010481
2014-10-11 13:01Torr SamahoStatusneeds review => feedback
2014-10-11 13:24DuskNote Added: 0010482
2014-12-27 16:38Torr SamahoNote Added: 0011093
2014-12-27 23:22DuskAssigned ToDusk => Torr Samaho
2014-12-27 23:22DuskStatusfeedback => assigned
2014-12-28 13:39Torr SamahoNote Added: 0011097

Notes
(0010434)
Dusk   
2014-10-09 19:55   
Without a WAD link this report is pretty much useless.
(0010435)
Tribeam213   
2014-10-09 20:01   
'http://www.gamers.org/pub/idgames/levels/doom2/Ports/megawads/sonic.zip [^]'

Sorry about that, forgot
(0010437)
Dusk   
2014-10-09 21:04   
(edited on: 2014-10-09 21:05)
Debugging says the culprit is the horribly inefficient P_FindFirstFreeFloorID() function. I'll optimize this function (and its twins >_>).
(0010441)
Dusk   
2014-10-09 22:10   
Turns out this function has *seven* different twin functions. This is requiring rather major rework to make into anything sensible. This patch is going to be a teeny bit larger than I first anticipated as I'm going in for a full refactor.
(0010444)
Dusk   
2014-10-10 01:24   
(edited on: 2014-10-10 01:34)
Big one incoming here:'https://bitbucket.org/crimsondusk/zandronum-stable/commits/19fbc48cc324fee30aebe5e19e9783ed8ff9e2fc [^]'

- all movers, ceilings, floors, pillars etc alike now use a single pool of 2^16 mover net IDs instead of 2^13 each (overall this increases the limit somewhat)
- new, linear-complex net ID choosing algorithm doesn't cause lock-ups in less-than-ideal scenarios, sonic map28 has a *lot* of instant movers in the fan hall, which caused the FindFreeFloorID function to spaz out
- a large amount of code duplication removed

No zandronum-history entry yet because I don't consider this changeset complete. I'm expecting something to crop up as this obviously enough needs through testing. Thus also needs a build for testing...
(0010481)
Torr Samaho   
2014-10-11 13:00   
I think it's not worth to make the code more complicated just so save a few kb of memory. If you really want to avoid using more than a bit to store a bool, I suggest to create a bit vector class that completely encapsulated all the bit shifts and index arithmetics.

Also, why do you invent a completely new network index handling algorithm when we already have one (ACTOR_GetNewNetID) and you could generalize that one instead? From a quick glance, I'd say that the existing mechanism is even more efficient. It won't necessarily slow down with the number of already used IDs while yours will go through all IDs starting from the first to find a free one (see how g_ulFirstFreeNetID is used).
(0010482)
Dusk   
2014-10-11 13:24   
So you're saying we should tie the mover net IDs in with actor IDs?
(0011093)
Torr Samaho   
2014-12-27 16:38   
For the record, we discussed this on IRC a while ago. I don't mean to use the same ID list for actors and movers, just the same ID list management code. I converted the actor ID list code to a class locally, to make this possible without code duplication. Still needs some refinement though before I can push it to the stable repository.
(0011097)
Torr Samaho   
2014-12-28 13:39   
I added the ID list code to the stable sandbox. Still almost untested, but should be good enough to try this with the movers.