Nash wrote:
So I can't help but wonder... what was it EXACTLY that kgsws-CZ managed to figure out that neither Randy nor Graf couldn't figure out for past several years?
As far as I understand it he used the brute force method: Split the entire map into horizontal slices for each visible 3D floor. Obviously such a method creates quite a bit of overhead and as some recently split off discussion indicated the slowdowns are evident.
Graf Zahl wrote:As far as I understand it he used the brute force method: Split the entire map into horizontal slices for each visible 3D floor. Obviously such a method creates quite a bit of overhead and as some recently split off discussion indicated the slowdowns are evident.
Ah! If multiple 3D floors cause a split for each, that could explain the observed slowdown. In that case one could solve it by ensuring that any number of floors at the same Z height lead to only one split.
koverhbarc wrote:
Ah! If multiple 3D floors cause a split for each, that could explain the observed slowdown. In that case one could solve it by ensuring that any number of floors at the same Z height lead to only one split.
Well, obviously same z coordinates can only produce one split.
randy wrote:
The sprites behind the railing are drawn in front of it.
The code seems to get totally confused if a sprite has to clip into the floor but there's several splits due to other 3D floors. It starts to clip into all of them which effectively makes the whole sprite appear in front of all of them.
Ok, problem fixed. It's not 100% glitch free but I think that's not possible with how sprites are handled by the software renderer. The mess that has been there from the start can't be undone.
koverhbarc wrote:
Ah! If multiple 3D floors cause a split for each, that could explain the observed slowdown. In that case one could solve it by ensuring that any number of floors at the same Z height lead to only one split.
Well, obviously same z coordinates can only produce one split.
I can't figure it out by looking at the source but this seems to be true based on a test level I created. I made a 8*8 grid of 3D floors and found them to be substantially slower when all heights were different than with all heights the same. The slowest speed I got was 20 fps, though, so I don't know what it is about the Inca HQ level that maks it ridiculously slow (there are fewer than 64 3D floors there, I'm sure).
It's probably not just about the 3D floors. The level also (ab)uses a situation that Doom isn't very happy with: the 3D floors are set in a pretty large open area with quite a few lindefs visible and, of course, there are textures that Zdoom has to force into the Doom palette ( some are hi-res), there are scripts running and there is generally a lot going on with enemies etc much of the time too.
I suspect that all of these things coming together with the large number of 3D floors leads to a situation that Zdoom is struggling to cope with. The 3D floors could well be the major slow down but other things will be adding to the problem.
The textures only need to be processed once and the scripts are not relevant.
The wide open area though, that's a different matter. But it's mostly the 3D floors that cause the slowdown. The problem is actually quite simple. There is absolutely no view blocking geometry around the house so everything in it needs to be processed by the renderer, even if it is not visible. Essentially the map is a showcase example of what you should NOT do when you want to get good 3D floor performance.
That it works reasonably well with modern 3D hardware is another matter. It's more a testament to the processing power than to the map's layout. On my old computer (3.2 GHz P4, Geforce 6800) it also gets quite slow around the house.
Does it make sense to wait, and wait, and wait until he finds time to do it? If he manages to do it better the code can always be replaced later but putting it on hold indefinitely is stupid, if you ask me.
