ZDoom

Huh...
Turns out my suspicions were correct. It was just outright better to add support for flat/wall sprites than to exclude them. That had the added boon of improving performance too.

I guess flag checking certainly does choke the system when done so much. :P

But I agree, Nash, I found a few things that could be improved and did so.

Bear in mind, HW::Process is specifically for OpenGL. This doesn't affect things like software renderer, or softpoly.

Granted, it'll run fine on the software renderer and softpoly because those have fewer things to manage but still...

HOWEVER I just had an idea. I'm going to try something...

Cooke, I think a worthwhile project before moving forward would be the sanitization of HWSprite::Process. I think it's time we cleaned up the mistakes we made* for good...

*coughflatspritescough*

Turns out you were right. This definitely had an affect on AEons of Death pretty hard. A terrible shame really. :(

I've removed it from QZDoom for the time being. This will be merged in later when enough testing is done on the current round of PRs is handled.

The render stuff is not something easily sorted out. I think by now the only option would be a duplicate of HWSprite that only handles base features.

I just meant, did you want to perhaps hold off merging my stuff until the render stuff is sorted out, getting the general concern stuff out of the way first.

It was mainly a general concern and nothing specific to the PR - which by itself is fine. I'm just concerned because this is yet another of these things that adds more overhead in a piece of code that already becomes a problem in maps with lots of actors (10000 or more)

I understand. Did you want to address that first before merging then?

While I have nothing against the feature itself, there's two things that genuinely bug me:

1. This is adding yet another 16 bytes to AActor.
2. This is adding yet more code to HWSprite::Process.

Essentially this means that one of the most critical functions in the engine adds more execution time and added risk of cache misses - and it's already suffering from both too much.
I think one thing that needs to be done eventually is to make a few fields in AActor which are not precision critical single precision floats, and we seriously need to think about how to address the code explosion in HWSprite::Process, because a lot of code in there is for rarely used specialty features - like this one.

No problem. After this PR is merged, hopefully I won't have to touch the SW renderer anymore. I have inserted blockers on all three from wall/flat sprites, so if someone makes that happen on SW renderer it's already taken care of.

The reason I disabled offsets is because it's not worth breaking their behaviors over, not to mention you're dealing with sprites that appear much more third dimensional. It's just far too painful to let them mingle together.

Thank you Cooke!

Alright, it's done. All three renderers.

This submission is now ready.

[quote="Major Cooke"]Last time I tried to touch the Carmack renderer, it exploded. I am never touching that renderer ever again.[/quote]
Such things do tend to occur with that thing. ;)

For a feature like this, from an objective standpoint I would say it should be done, if you can. But I know that thing is scary and tends to explode a lot. The important thing to remember is, though: There are still a significant number of people who use it, even if not full-time, and if there are things that can be accomplished with simple tweaks for hwrenderer compatibility they should be done.

I would ask you consider at least giving it an effort. If you can't do it then fine, you can't, but at least then I'll be happy you tried. But I realize and understand that may be too much to ask - because I don't even know where sprite offsets are managed in that thing. First place I would look, though, is "src\rendering\swrenderer\things\r_sprite.cpp"

Hardware renderer only.

After speaking with dpJudas, he said not all the sprite stuff is working so support might not be worth the effort in softpoly.

Last time I tried to touch the Carmack renderer, it exploded. I am never touching that renderer ever again.

Only for the hardware renderer? What about Carmack and Softpoly?