Welcome to the ZDoom Forums!

Here's another idea:

if distance is > desired threshold then if monster count is more than 10 per 9 blockmap cells, then treat them all like 1 monster (object) so that calculations are made just once and reused for the rest "pack"?

What do you guys think about this odea? After certain distance, do function "P_TryMove" for 1 monster per blockmap cell per 1 tick, then switch between them randomly. Reuse the results for all the monsters (objects) in the blockmap with some random delay? Idk, maybe even reuse the results for other ...

My bad then. Yeah, maybe that would be nice to have such a feature but it seems like it's really hard to implement, like what's about merging errors like overlapping vertices, linedefs and etc, something very error prone.

I’m creating a level in Ultimate Doom Builder and I can’t find a way to merge two designs on top of each other. I have Sector A, where I only designed the floor. It has various textures, height differences, actions (like tags), etc. The ceiling is still empty and just a basic square. Then I dup ...

Might be a nice idea for people with lots of RAM so that GZDoom refers to disk less often? Why not get stuff like mods, wads, resources in RAM then? If so, there must be an option for people with lots of RAM. I've seen some sampler software that has options to choose be it streaming from disk and ...

an offset of 0.6 was a conscious decision. Without access to vertex data in the shader there is no way to prevent parallax overdraw and the best you can do if you find overdraw intolerable is in fact to set bias to 0.5, which is an intended feature at the cost of destroying parallax detail. All ...

A really nice attempt but it doesn't work in GZDoom due to how warp shaders are made. As soon as you remove the gldefs definitions with them it's going to work... I'll tell you what's wrong with parallax textures - it's the parallax offset value set at 0.6 instead of 0.5. That's gonna push your ...

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 ...

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

So with this technique is most likely impossible to speed up the rendering. 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 ...

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

That's why I told about a workaround that works and it does so even with the older hardware, the speedup is about 3-4 times. It's like a trick to circumvent the engine. Sure there are problems to solve but seems like it's worth it to me. That's how Map15 was optimized: 1) Discriminate between static ...

I'm pretty sure there's an alternative way to perform optimization without too much gzdoom source modifications involved. Map15 proved to work pretty well with that approach - dump the static map geometry into a set of 3D models a surface by surface per texture but this also can involve a process of ...

So some other "strategies": Tested: 1. Use distance flickering instead of distance culling - works but looks bad not just due to the fact it flickers but also the normal geometry adapts to that update frequency and game becomes a bit more choppier; 2. Along with gl_bsp.cpp update gl_scene.cpp ...

Nah, I tested it again with MSI Afterburner overlay, comparing both versions, didn't happen indeed. It's like a FPS can slightly differ time to time, seems like a statistical error, sorry