[GZDoom]Flat, Wall, and Roll Sprites v2

[The Zombie Killer]

I agree with the above. The basic flags should probably be properties, with stuff like PITCHFLATSPRITE remaining a flag (+PITCHSPRITE maybe?)

[Graf Zahl]

Think it might be worthwhile to just leave the rotation behavior as-is,

No, because it looks like a bug if a wall sprite looks different, depending from where you look at it.
I think the feature as such is a good addition, but if I see it overloaded with unintuitive crap I'd rather decide to leave it out or strip it down.

[The Zombie Killer]

I was just thinking it might be useful for say, a painting on a wall where the eyes follow the player (although there are better ways to do that I guess, especially considering that you can only have a maximum of 16 rotations).

[Major Cooke]

I feel like these would be better as a property (a la RenderStyle, BounceType) than a full-fledged set of Cookeflags™. Their being flags makes it seem you can combine them when logically you shouldn't be able to (a sprite can't be flat- and wall- aligned at the same time). Other than that, I'm all for this!

1. I did not develop this submission. Several others did. I'm just maintaining it because I don't want to see this go to waste, thus my knowledge on how some of this stuff works is still limited. That's more like fgsfds/nash/marrub flags for you.
2. FORCE(X)YBILLBOARDS is already a set of flags and so is WALLSPRITE. Same goes for VOXELSPRITE and quite a few more. Those were implemented long ago, so I'm going to keep it as flags. Bonus of it being a render flag, one can toggle it on and off whenever they desire with A_ChangeFlag.

1. Why are FLATSPRITE and PITCHFLATSPRITE different types? Why not use the pitch in a flat sprite to make the difference?

Done. PITCHFLATSPRITE functionality merged into FLATSPRITE and is no more.

2. Why the FlatAngle? I absolutely cannot see why this is needed and what purpose it serves.

I removed it already.

3. There need to be clear semantics how rotations are to be applied to these different sprite types. Just leaving everything as-is is not going to work for rotated sprites.

• ROLLSPRITE - Changes the rotation of any sprite regardless of type based on roll property. Affects WALLSPRITE and FLATSPRITE as well. Roll is applied last over all to ensure sprites maintain their tilt.
• WALLSPRITE - Flattens the actor like a decal. Does not combine with FLATSPRITE due to its behaviors relied upon in decal form. Use either one or the other, NOT BOTH.
• FLATSPRITE - Flattens the actor while factoring in pitch. A pitch of 90 or -90, for example, will tilt the flatness up or down to behave like a decal on the ground or ceiling. A pitch of 0 will be completely horizontal. Roll is applied on top of pitch, allowing sprites to maintain their tilt and spin in place. Does not combine with WALLSPRITE.

Is that better?

[The Zombie Killer]

Is there still a way to make +FLATSPRITE ignore pitch?

[Major Cooke]

Is there still a way to make +FLATSPRITE ignore pitch?

Why are FLATSPRITE and PITCHFLATSPRITE different types? Why not use the pitch in a flat sprite to make the difference?

Graf wanted it gone, or so I take it.
Wallsprite would be too if it wasn't being used for decals.

If that is indeed what Graf wanted, spawn another actor that sets a certain pitch. That's all I can tell you. Have it call A_Warp if necessary to the moving actor that changes its pitch. To be fair, Graf has a point. It serves no other purpose than 90 and -90 pitch, and if people want to preserve pitch regardless that isn't 90, 0 or -90, they'd have to spawn an external actor that called A_Warp anyway.

If that's not what he meant, I'll revert that change.
However...

if I see it overloaded with unintuitive crap I'd rather decide to leave it out or strip it down.

[The Zombie Killer]

That's hacky though, and very much not ideal. If that is indeed what Graf meant, then I think it should be reconsidered, since I don't think it's unintuitive, but rather expected behavior from a flag called +FLATSPRITE (especially when pitch doesn't normally have an effect on a sprite).

[Major Cooke]

You know I would have thrown out Wallsprite as well had it not been for the fact that it's actually being used for decals, right?

To top it off, if you have an actor with a pitch of [-89.9..., 89.9...] you're going to need a secondary actor regardless and to use the hack I mentioned. Also try not to rely too heavily on them being floor decals, because they still stick out over ledges. From the sounds of it, it almost seems like you want something of a FlatPitch property but, as clearly shown with FlatAngle... Because that's the only thing I could do to make it not-hacky IMO.

[NeuralStunner]

I don't think it's unintuitive, but rather expected behavior from a flag called +FLATSPRITE (especially when pitch doesn't normally have an effect on a sprite).

I think "flat" is meant here literally, rather than as a reference to floor/ceiling. Since apparently a flatsprite can be vertical, but won't be subject to whatever decal-like quirks a wallsprite has.

Also, I don't know why you would/should need an extra actor to set the pitch. It's more than a little silly if you can't directly use an arbitrary pitch.

Not all decals are dynamic: See the manhole covers (etc.) in Duke Nukem 3D, or ground junk in Half-Life 2. Though I do still wonder about the possibility of retrieving a floor/ceiling slope. That would make visual pitch several times more useful (outside of pre-placed things, which is the only other way you'd align the sprite to a slope).

[The Zombie Killer]

My usage case isn't for decals, it's for top-down player sprites. See Hotline 666 for an example.
I'm not sure if I'm misunderstanding the implementation here

Though I do still wonder about the possibility of retrieving a floor/ceiling slope.

I actually have some code from Nash that can do that, works quite well.

[Graf Zahl]

See, that's the problem here. Everybody has different ideas what this is supposed to be.
As I see it, wall sprites and flat sprites should be what they are in the Build engine - graphics that are either aligned with a wall or with a flat plane. And in case of flat sprites it's normally the pitch that specifies the plane tilt. If your specific use case is something different you have to explain in more detail. If we try to shoehorn every possibility into the same feature it's bound to become a mess.

[Nash]

^ I agree with everything Graf said in this post, let's just use an already-established idea (BUILD) and keep it simple!

[The Zombie Killer]

I agree as well, and as for more detail, it doesn't really go beyond setting a "static" pitch for the flat sprite to remain at, independent of the actor's pitch.

[Major Cooke]

As I see it, wall sprites and flat sprites should be what they are in the Build engine - graphics that are either aligned with a wall or with a flat plane. And in case of flat sprites it's normally the pitch that specifies the plane tilt.

Do I really need to worry about that? I just really want to get the rolling and flat tilted sprites in first if you don't mind. I'd very much like to worry about aligning to a plane in another pull request if possible mainly because I have absolutely no idea how to orient to a plane at all.

Let's get this in first so at least people can start using them, and we can worry about the rest right after it, yes? I think that sounds reasonable enough.

(Also, for 'sticking to planes', please bear in mind there will be times which I won't want sprites to align themselves against walls or anything. Think of sprites sliding into thin cracks. Like putting a disc in a car radio. So there should be some exceptions where it requires another flag to orient against a plane.)

it doesn't really go beyond setting a "static" pitch for the flat sprite to remain at, independent of the actor's pitch.

Look at FlatAngle's result. I just don't see it happening. There will not be a static pitch setting from what Graf has said, IMO.

[arookas]

I think Graf is saying FLATSPRITE should render the sprite on a flat, horizontal plane. The actor's pitch would tilt it up and down like the INHERITACTORPITCH MODELDEF flag does to models. The slope of the actor's sector wouldn't affect the sprite in any way. The WALLSPRITE flag would render the sprite on a vertical plane. It wouldn't be affected by the angles of any nearby walls, either.