+ALWAYSDRAW flag important for models

[Dethernal]

This flag causes the paint thing is always, without reference to the sector. It is important for large objects - rooftops, domes over the bases, the trees, a few other things. Now they are disappearing, forcing or simplify the architecture, or use a 3d floors, that slow and difficult (especially for slopped 3d floors).
I think it's easier to do so by putting these objects in a separate list and draw the them (taking into account the z buffer).
Thank you for your attention.

[Rachael]

I'm not Graf so I can't answer for him, but I'm seeing a likely [No] here.

And the main reason why I say that is because I vaguely remember this being brought up before and it was met with a similar response.

I think his reasoning was that it would cause too much work for the engine and would slow things down unreasonably, or something along those lines. Either that, or it was one of those too much work for little gain things. Either way, if I'm not mistaken, I wouldn't be surprised if this gets a similar response.

Then again, I could be obliviously wrong and have a bad memory and he might prove me wrong.

[Enjay]

or use a 3d floors, that slow

How much do 3D floors slow things down? I've seen this mentioned a number of times but I can't say that I have ever noticed a significant slowdown on any map that is definitely 100% due to 3D floors alone.

Anyway, I would imagine that always drawing certain actors could easily have as much of a performance hit as using a 3D floor, depending on how the level was set up of course.

Another thing to keep in mind - collisions. Given that models have no specific collision detection, a lot of the time you need some kind of underlying architecture to allow projectiles to seem to impact on the roof or whatever you are trying to make. Using 3D floors for that is common.

[Graf Zahl]

or use a 3d floors, that slow

How much do 3D floors slow things down? I've seen this mentioned a number of times but I can't say that I have ever noticed a significant slowdown on any map that is definitely 100% due to 3D floors alone.

Phobia MAP05 (the savegame from my benchmarks.) But that requires several hundreds of 3D floors to have such an effect.

Anyway, I would imagine that always drawing certain actors could easily have as much of a performance hit as using a 3D floor, depending on how the level was set up of course.

Much more, in fact.

In the end it's the fact that this would require a costly additional pass through all the actors in a map that makes it a 'no'.

[Dethernal]

In the end it's the fact that this would require a costly additional pass through all the actors in a map that makes it a 'no'.

Why all? just when you create things with such a flag is placed in the std:: list <actor*> (or something like that), which should read somewhere during rendering.

one model ~ 5 minutes.

for create this ~50 3d floors needed (include 32 sloped 3d floors) and some hours.
----
I have slightly modified the source, now I have this flag is. But since I do not know very well Zdoom project structure, I do not know how to do it "clean." STL is not used for some important reasons? And I'm a little hurt include logic.
Diff you need?

[Gez]

Use the TArray class, not STL things.

[Dethernal]

Gez, List and arrays is VERY different things, and for this task array is not prefer. Or Tarray is list?
And Tarray may save automatic when game is saved (?), but it's not needed (because list must collect a POINTERS to actors)
----
current implementation does not spend any resources at all (except for overhead costs from Std:: List). Save/load works fine

[Gez]

TArray is not a normal array. It's dynamic (has Push() and Pop() functions). It's what's used in ZDoom for just about everything.

[Dethernal]

Sorry, I'm inexperienced in the SVN and Diff.
Unzip archive and replace files of 805 revision. It uses TArray, but delete operations is uneffective for TArray. But they are quite rare, so that's OK.
This is only for GL rendering, for the software is not implemented, because it is practically useless (and will cause problems due to lack of Z buffer)
-------
I thought for a moment and came to the conclusion that such models will risovatsya 2 times. To prevent this, you must add a check in ProcessSprites
If (actor->flags & RF_ALWAYSDRAW) return;

[Nash]

Whoa wait a minute, isn't that screenshot from the demo file I posted pertaining to my complaint that big models will disappear from the viewport if the sector that the model is located in is out of view? Did you actually come up with a flag that fixes the problem?

This would be an awesome feature to have!

[Dethernal]

Nash
Yes, It fixes this problem, but Graf do not want include flag without reason.

[Graf Zahl]

He has come up with a half-baked idea, not a solution. That's a major difference.

Furthermore, I don't like this kind of developer harassment over a decision to implement something or not so this thread gets closed now.