Applying rendertypes/alpha to overlays?

Advanced OpenGL source port fork from ZDoom, picking up where ZDoomGL left off.
[Home] [Download] [Git builds (Win)] [Git builds (Mac)] [Wiki] [Repo] [Bugs&Suggestions]

Moderator: Graf Zahl

Locked
Major Cooke
Developer
Developer
Posts: 240
Joined: Wed Mar 04, 2009 19:25

Applying rendertypes/alpha to overlays?

Post by Major Cooke » Thu Sep 29, 2016 0:17

As seen here, it's perfectly capable to set a rendertype for ZDoom on overlays, that's all good and well because vis is used for each and every layer, allowing more than one rendertype to apply along with alpha.

However, GZDoom, I'm not seeing it. What do I do to make this work in a similar manner with the GL renderer?

And while we're on the topic, I'm having extreme difficulty making sprites scale in on the middle of themselves instead of the center of the screen. No idea what to do there on ZDoom's side.

User avatar
Rachael
Developer
Developer
Posts: 3617
Joined: Sat May 13, 2006 10:30

Re: Applying rendertypes/alpha to overlays?

Post by Rachael » Thu Sep 29, 2016 2:12

Your code is in r_things.cpp - what do you think r_* deals with? You're right in the middle of the wrong code to make anything work in GZDoom.

I'm not sure what files deal with player sprites in GZDoom - Graf might know about that, but it shouldn't be far from where you were playing with your +FLATSPRITE submissions.

Also, you cannot/should not make sprites scale on "themselves" - that works good for monsters and stuff but not for overlays such as weapons. As we discussed before, first of all the sprite's offset will always be in the upper right corner of Doom's 320x200 screen when the player viewing them is not running. That means your offsets will be negative and way off from any conceivable center the image may have.

That leaves you only one other option beyond the sprite's own definition and that's defining a center by the sprite itself - which also is not a good idea because you may want non-symmetrical additions to the sprite and you're blatantly making an assumption that the sprite's served pixels represent the "weight" of the entire sprite - that will lead to disastrous results unless someone intentionally puts in blank space off to the side of their sprite - a hack they should not have to perform.

That being said - you may have to just extend overlay sprites to have a "focal point" center. How you do that is the hardest part because then everyone has to agree with you for a new standard - does it go on the sprite itself? If that's the case, obviously only png sprites will support that. Does it go in a special sprites.txt definition? I think at the very least we should wait until Randi is a bit more active because this goes right into the mechanations of the engine itself and it challenges assumptions that it already makes.

Which leads me to a final question - why did you need overlay scaling so bad?
Spoiler: Zen Sarcasm

Major Cooke
Developer
Developer
Posts: 240
Joined: Wed Mar 04, 2009 19:25

Re: Applying rendertypes/alpha to overlays?

Post by Major Cooke » Thu Sep 29, 2016 2:26

Eruanna wrote:Your code is in r_things.cpp - what do you think r_* deals with? You're right in the middle of the wrong code to make anything work in GZDoom.
I'm fully aware, that's why I was pointing out how the two render codes work differently. In zdoom, it's as simple as changing the vissprite. In GL, it's not the same way. They're all rendered by one call to the GL renderer in unison and so far, the only thing I can see that's interchangeable is the sprite offsetting.
Eruanna wrote:I'm not sure what files deal with player sprites in GZDoom - Graf might know about that, but it shouldn't be far from where you were playing with your +FLATSPRITE submissions.
I already do, and I've been studying them. That's why I made this thread to ask more about finding a way to apply the rendering to how
Eruanna wrote:Also, you cannot/should not make sprites scale on "themselves" - that works good for monsters and stuff but not for overlays such as weapons. As we discussed before, first of all the sprite's offset will always be in the upper right corner of Doom's 320x200 screen when the sprite is idle. That means your offsets will be negative and way off from any conceivable center the image may have.

That leaves you only one other option beyond the sprite's own definition and that's defining a center by the sprite itself - which also is not a good idea because you may want non-symmetrical additions to the sprite and you're blatantly making an assumption that the sprite's served pixels represent the "weight" of the entire sprite - that will lead to disastrous results unless someone intentionally puts in blank space off to the side of their sprite - a hack they should not have to perform.

That being said - you may have to just extend overlay sprites to have a "focal point" center. How you do that is the hardest part because then everyone has to agree with you for a new standard - does it go on the sprite itself? If that's the case, obviously only png sprites will support that. Does it go in a special sprites.txt definition? I think at the very least we should wait until Randi is a bit more active because this goes right into the mechanations of the engine itself and it challenges assumptions that it already makes.
I can finally give the people who keep poking me about this a reason why it won't happen. Thank you for that.
Eruanna wrote:Which leads me to a final question - why did you need overlay scaling so bad?
I don't. And I'm more than happy to start trashing it right this second. Some will be disappointed but I was clearly not prepared for this.

If there's one thing I will keep, however, is the ability to flip the X over with a flag. I don't see the need to make a new texture entry just for that, honestly.

EDIT: And I just found my answer. Nevermind!

User avatar
Rachael
Developer
Developer
Posts: 3617
Joined: Sat May 13, 2006 10:30

Re: Applying rendertypes/alpha to overlays?

Post by Rachael » Thu Sep 29, 2016 2:36

Major Cooke wrote:I can finally give the people who keep poking me about this a reason why it won't happen. Thank you for that.
You're welcome - there's one other thing to consider, too, though - the screen already defines the center of the sprite just by being what it is. Since it's an overlay meant to represent the player's interaction with the world he is in, obviously there is a clearly defined vanishing point that cannot be changed. That is the absolute center of the viewport. By this definition alone, the center of the screen is always going to be the center of the sprite - though if I were to do Y-scaling I'd scale from the bottom to avoid exposing the clip-ends of the sprite.
Major Cooke wrote:I don't. And I'm more than happy to start trashing it right this second. Some will be disappointed but I was clearly not prepared for this.
Don't trash it until you've determined with absolute certainty that it has too little merit and is a waste of time. My post isn't to trash your feature or try to tell you it is useless. But what I did type was mainly to get you thinking about how this all would benefit ZDoom as a whole. To me, it seems like a whole lot of work for a very very niche feature. (You could argue that QZDoom is extremely niche too - however I will point out that QZDoom is not currently merged into ZDoom's main branch, nor is that its purpose for existing. :P) If you have this much work now, imagine how much work will be left for Graf and Randi when it gets accepted as a pull request. If there's some justification for it, it serves its own right to exist and they will tolerate that. Unfortunately, from my perspective (and I may be wrong) - I do not see what that is.
Major Cooke wrote:If there's one thing I will keep, however, is the ability to flip the X over with a flag. I don't see the need to make a new texture entry just for that, honestly.
I see nothing wrong with that. :)
Spoiler: Zen Sarcasm

Major Cooke
Developer
Developer
Posts: 240
Joined: Wed Mar 04, 2009 19:25

Re: Applying rendertypes/alpha to overlays?

Post by Major Cooke » Thu Sep 29, 2016 2:43

Eruanna wrote:You're welcome - there's one other thing to consider, too, though - the screen already defines the center of the sprite just by being what it is. Since it's an overlay meant to represent the player's interaction with the world he is in, obviously there is a clearly defined vanishing point that cannot be changed. That is the absolute center of the viewport. By this definition alone, the center of the screen is always going to be the center of the sprite - though if I were to do Y-scaling I'd scale from the bottom to avoid exposing the clip-ends of the sprite.
Y scaling is a whole 'nother monster. I don't even want to think about that one for a while until I get my foot in the door and fix this damnable X scaling first.
Eruanna wrote:Don't trash it until you've determined with absolute certainty that it has no merit and is a waste of time. My post isn't to trash your feature or try to tell you it is useless. But what I did type was mainly to get you thinking about how this all would benefit ZDoom as a whole. To me, it seems like a whole lot of work for a very very niche feature. (You could argue that QZDoom is extremely niche too - however I will point out that QZDoom is not currently merged into ZDoom's main branch. :P) If you have this much work now, imagine how much work will be left for Graf and Randi when it gets accepted as a pull request. If there's some justification for it, it serves its own right to exist and they will tolerate that. Unfortunately, from my perspective (and I may be wrong) - I do not see what that is.
I made very little progress in the scale category and honestly, I thought it was all hacked together for the most part (on my end). It's nothing I can't reimplement easily enough. I could keep the functions and such around if that's what you meant so it's there and available.

User avatar
Rachael
Developer
Developer
Posts: 3617
Joined: Sat May 13, 2006 10:30

Re: Applying rendertypes/alpha to overlays?

Post by Rachael » Thu Sep 29, 2016 2:50

Major Cooke wrote:I made very little progress in the scale category and honestly, I thought it was all hacked together for the most part (on my end). It's nothing I can't reimplement easily enough. I could keep the functions and such around if that's what you meant so it's there and available.
I understand - and no, that's not what I meant, but regardless, it's good that something good came out of all that. :)
Spoiler: Zen Sarcasm

User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: Applying rendertypes/alpha to overlays?

Post by Graf Zahl » Thu Sep 29, 2016 7:25

All the weapon rendering in GZDoom is done in a file named gl_weapon.cpp. It can be found right in the same subfolder (Scene) as all the other rendering stuff.

User avatar
Gez
Developer
Developer
Posts: 1396
Joined: Mon Oct 22, 2007 16:47

Re: Applying rendertypes/alpha to overlays?

Post by Gez » Thu Sep 29, 2016 15:00

Applying renderstyles and alphas to overlays is a good thing with a good reason to exist. After all, actors in worldspace have renderstyles and alpha, so why couldn't "actors" in HUDspace get them? Since it concerns interaction of HUD graphic with the world, it's something that cannot be done during texture composition. And additive muzzle flashes make so much sense it hurts.

Scaling, flipping, mirroring, etc., though, all those can be done in TEXTURES and I don't see any strong reason to shoehorn them in elsewhere.

User avatar
Rachael
Developer
Developer
Posts: 3617
Joined: Sat May 13, 2006 10:30

Re: Applying rendertypes/alpha to overlays?

Post by Rachael » Thu Sep 29, 2016 15:07

Gez wrote:Applying renderstyles and alphas to overlays is a good thing with a good reason to exist.
That is not even the least bit in question, on my part, it was the scaling that I was having trouble with.

Unfortunately, the current implementation is supported by a hack that I created that may or may not even be necessary now that blending modes are now available to the overlays themselves and do not require inheriting from their owner. The hack that I created is in the pull request's r_things.cpp line 1435. Basically when Alpha falls below 1.0, the "normal" blending mode is no longer allowed, it switches to translucent (albeit internally only) automatically.
Spoiler: Zen Sarcasm

Major Cooke
Developer
Developer
Posts: 240
Joined: Wed Mar 04, 2009 19:25

Re: Applying rendertypes/alpha to overlays?

Post by Major Cooke » Thu Sep 29, 2016 17:05

Graf Zahl wrote:All the weapon rendering in GZDoom is done in a file named gl_weapon.cpp. It can be found right in the same subfolder (Scene) as all the other rendering stuff.
The vis sprites are handled quite a bit differently and alpha/renderstyle is handled all 'at once' instead of 'per DPSprite' like how ZDoom does it. So I'm unsure of how to proceed with it.

Code: Select all

// store information in a vissprite
	vis = &avis[vispspindex];

User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: Applying rendertypes/alpha to overlays?

Post by Graf Zahl » Thu Sep 29, 2016 18:16

You'll have to move the renderstyle code inside the loop. Right now it's only done once before the first iteration, but if each layer can have a different style it needs to be moved.

Major Cooke
Developer
Developer
Posts: 240
Joined: Wed Mar 04, 2009 19:25

Re: Applying rendertypes/alpha to overlays?

Post by Major Cooke » Thu Sep 29, 2016 19:11

Graf Zahl wrote:You'll have to move the renderstyle code inside the loop. Right now it's only done once before the first iteration, but if each layer can have a different style it needs to be moved.
Alright, but before I go too far I'd like you to check my recent changes so I can ensure I don't repeat any mistakes made.
Gez wrote:Applying renderstyles and alphas to overlays is a good thing with a good reason to exist. After all, actors in worldspace have renderstyles and alpha, so why couldn't "actors" in HUDspace get them? Since it concerns interaction of HUD graphic with the world, it's something that cannot be done during texture composition. And additive muzzle flashes make so much sense it hurts.

Scaling, flipping, mirroring, etc., though, all those can be done in TEXTURES and I don't see any strong reason to shoehorn them in elsewhere.
Flipping on the X axis is something that I'm including for the sake of not having to define an extra texture just for it. ESPECIALLY when you have animated graphics. I hate having to second guess myself every time I'm setting up dual wielding systems and it becomes extremely unwieldy when you have multiple weapon sprites requiring flipping, no pun intended. You have to gather offsets and shit of every single graphic along with their dimensions and that just drives me nuts after a while.

The Hell with that. A simple flip flag will be included to resolve this monstrous headache once and for all.

Major Cooke
Developer
Developer
Posts: 240
Joined: Wed Mar 04, 2009 19:25

Re: Applying rendertypes/alpha to overlays?

Post by Major Cooke » Sat Oct 15, 2016 23:23

Thanks to Gez, we've uncovered some side effects on GZDoom's renderer that need squashing. In particular, normal weaponry on some maps flickers in and out of visibility, while on other maps, no weapons render at all.

Trying to find the cause is proving to be problematic. Too much of the code in gl_weapon is extremely alien to me, making this extremely difficult to understand.

https://github.com/coelckers/gzdoom/pull/115

Major Cooke
Developer
Developer
Posts: 240
Joined: Wed Mar 04, 2009 19:25

Re: Applying rendertypes/alpha to overlays?

Post by Major Cooke » Wed Dec 07, 2016 1:31

With the dust settling on zscript for the time being, and considering Leonard's given up on the actor overlays, now's a good time to start working on this again. I still haven't managed to figure out how to properly handle this situation, however.

Locked

Return to “GZDoom”