Performance overhead for running boom maps in zdoom?

[Graf Zahl]

What you remember there is the drawsegs limit. If that list gets exhausted all further away linedefs won't be drawn.

[drfrag]

I see, it was just a complex map then.

[drfrag]

I see what you did with the sprite draw distance, but would such a thing be possible for lines too?

Method #1 is by far the easiest to implement, but has the drawback that you can't do large structures in the distance.

I actually think this would be a good idea, after all walls dissapeared in old ports when the drawsegs list got exhausted.
Of course in an optioned and controlled way, disabled by default and not happening when the ceiling is a sky?
It's some sort of low detail mode after all, i'd happily include it in ZDoom32 (that poor man's engine) but i don't know how.
@dpJudas: Any suggestions would be welcome (and on ZDoom32 as well), i know you're very busy right now.

[Rachael]

Sprites are your biggest killer. You might be able to translate this into your child ports. (Yes, it's reverting a revert)

[dpJudas]

I actually think this would be a good idea, after all walls dissapeared in old ports when the drawsegs list got exhausted.
Of course in an optioned and controlled way, disabled by default and not happening when the ceiling is a sky?
It's some sort of low detail mode after all, i'd happily include it in ZDoom32 (that poor man's engine) but i don't know how.
@dpJudas: Any suggestions would be welcome (and on ZDoom32 as well), i know you're very busy right now.

I would do the following, if I were to implement this:

• In RenderOpaquePass::CheckBBox (R_CheckBBox in in ZDoom) I would add a range test. If the bounding box is further than the far clipping distance then return false in this function. This will make it stop walking the BSP deeper than what is to be rendered.
• In FWallCoords::Init clip the line against the far clipping plane. Return false when this results in the entire line being clipped. This will make it stop drawing walls exactly at the clip boundary.
• The two first steps will leave unfilled holes in the distance. The clipper knows the ranges that are unfilled. Walk the solidsegs list (RenderClipSegment in GZD, global variable in ZDoom). Fill those ranges with black.

It probably will look better if the black fill is done with the sky if it is outside. I'm not sure how to detect this situation in an easy way as walking the solidsegs list won't contain the information required. Perhaps instead of walking the solidsegs it could draw a fake second line if the real line was clipped against the far clipping plane. That fake line would either draw a sky or black depending on the sector.

[drfrag]

Sprites are your biggest killer. You might be able to translate this into your child ports. (Yes, it's reverting a revert)

Thanks, as i mentioned in the previous page i already ported it to ZDoom32 and added a menu option for it, it's in the release. You can have a look at what i did here:
https://github.com/drfrag666/gzdoom/commits/zdoom32
BTW i applied your fix for multilayer skies but it didn't work, i don't know why.

I would do the following, if I were to implement this:

Thanks very much, easier said than done. I'll have a look into it but my knowledge of the internals of the engine is close to zero. I think it's better to always fill with the sky then but i wonder how.
If someone is willing to help and experiment the repo is there.
Edit: seems like it was the real Killough after all but he hasn't come back.

[Rachael]

The problem with the multi layer skies is there are only 4 column buffers being used to render the sky, and the drawing is all queued up until after the BSP is walked. Basically, you need to expand the number of buffers available, or find some way to make the sky drawing execute immediately, or write a separate sky drawer that does its own sky layering, itself.

[drfrag]

I see, i thought the LLVM drawers were not still being used. Thanks.
Then i wonder if multithreading was working properly back then (this version of the 32 bit renderer dates from september 08 with later fixes) or the crashing problem appeared later. I've disabled it by default.

[Rachael]

LLVM drawers are not being used at the merge point I suggested - the problem is a very old one and was there since multithreading support.

At any rate, if you go through my early QZDoom history (~Oct-Nov 2016) it should be pretty easy to find when I fixed bugs related to skies.

Disabling multithreading is probably the best solution for your intended audience, though - they certainly will not benefit from using it. Anyone with a multicore processor is going to benefit more from running GZDoom at this point anyway.

[drfrag]

It's fixed now, i don't know what happened. There is no need to increase the number of buffers, this time i just applied the previous change to r_clearbuffer. I already had reviewed the full history of both QZDoom and ZDoom. Thanks again.
Yes, you suggested merging @AUG 14 but i forked QZDoom @SEP 08 and then merged a later ZDoom into it instead of GZDoom. C++ drawers were removed on OCT 04.

[drfrag]

Now that sprite culling is back into QZDoom (i think) with the recent dpJudas changes to sprite drawing i'd suggest increasing the default distance to 8000.0 since it's the render limit (tested with nuts.wad). I've changed the Infinite option to Maximum in ZDoom32.

On wall culling as i expected i'm not capable of doing it. Looks like chinese to me.

Return false when this results in the entire line being clipped

Did you actually mean return true? I think i'm going to ask for help in the doomworld forums.

[dpJudas]

I tried implementing this in GZDoom - here's the diff from the line_distance_cull feature branch.

It essentially works like this: if both vertices for a line is past the far clipping distance then it fills the area covered by the line with the top ceiling (the sky when outside) and tells the clipper it was a solid line.

In Planisphere 2 it works very well - combined with r_scene_multithreaded I get a FPS around 90. For Frozen Time the castle is within the 8000 culling distance, so here it doesn't help at all.

[drfrag]

Thanks very much, i'll look into it in order to port this to ZDoom. For Frozen Time it should help with some aggresive menu option.

[drfrag]

Okay, i've tried to port this to ZDoom and this time it's not being easy, i got it mostly working but i'm getting some HOMS.
As i stated i don't know the internals of the engine and i'm missing something.

@dpJudas: could you please have a look at what i've done when you have time? Thanks in advance.
The full r_bsp.cpp file if needed is at https://github.com/drfrag666/gzdoom/blo ... /r_bsp.cpp

Edit: removed obsolete wrong code. See next page.

[dpJudas]

From what I can tell, what you are doing here should be how it is done in ZDoom. Are you only getting those HOMS with ZDoom and not with what I did in QZD?