Some ideas on optimizing rendering of big maps

[Chris]

And here's how I'd like it to be done:
1) Discriminate between static and dynamic geometry;
2) Find out about possible changes in dynamic geometry, e.g. scan for how sectors and linedefs are affected in height, texturing and brightness, find out for triggers and scripts referencing them, then approximate the animation (trim their framecount);
...

I'm pretty sure that's the impossible bit. Given the kind of scripting GZDoom allows, it's not easy or possible to know with certainty that any given sector can't be changed at any point during play. If you're dealing with pure vanilla maps, sure, there's a limited number of ways stuff can be changed and you can make assumptions within those bounds (and it's these maps that would benefit the least, since they tend to be smaller and simpler). But once some of the more advanced GZDoom options come into the picture, those limitations no longer apply and you no longer know ahead of time what can be dynamic until it's changed during play. Even within the bounds of Hexen, hubs exist which makes it possible for completely different maps to have a scripts that affect sectors in other maps, so you can't look at a single map in isolation. Add in the flexibility of ZScript, and good luck figuring out which sectors can be affected by what script or combination of scripts.

[Darkcrafter]

Indeed, it's like constructing another renderer on top of the existing one, this technique has its limits.

[Darkcrafter]

So with this technique is most likely impossible to speed up the rendering.

Code: Select all

if ((level.maptime & 1) != 0)
	{
		return;
	}

But that Map15 style one still works if you know the limits and what to do.

At least I could debug some errors out preventing the source port from crashing.

What I'm wondering now whether this kind of big 3D model optimization is going to work with CPU polyrenderer as you know less time spent on traversal, clipping, setup, drawcalls and such.

[Rachael]

I think you could be onto something with reintroducing the distance culling like you suggested - LZDoom did that and it was extremely helpful, but that is something that is said will never go into GZDoom - luckily we are not restricted by arbitrary rules when it comes to forks so if we wanted a fork that focuses on making GZDoom more viable for weak hardware this would definitely work. LZDoom used to be one such fork and it easily could be again.

LZDoom proved this worked well in Frozen Time because the draw time was consumed not just by the bridges themselves, but by the exterior ice sculptures on the edges of the bridge area with their many many tiny lines for the ice sculptures. Just not rendering those doubled the FPS on some systems.

[Darkcrafter]

For the moment I thought that FPS increases when flickering is there while it doesn't. It gets just as laggy.

[Rachael]

That is because the renderer skips frames anyhow when FPS is below 35. The game regards keeping determinism intact more important than showing you the level, so it can skip a few tic frames per render (I don't know what the limit is, or if there is one, I haven't gone that deep into the code yet). This was code that allowed the game to keep running on trashy 386's despite the abysmal clock speed when putting the game view onto the screen.

[Darkcrafter]

That's interesting, btw, seems like using I_GetTimeNS() also won't help a much and on low values you can see how flicker differs a surface to surface, like one frame it's one half of the level, another - the other part. With this timer flicker doesn't stop when a pause key is pressed too. If there was a magic leverage to switch so that the whole game events were handled less often making it a bit choppier but would also require to process the stuff less often resulting in overhead reduction and actual FPS boost...