[GZDoom]Flat, Wall, and Roll Sprites v2

[Major Cooke]

With the portals now mostly complete, I'll look into updating this. Oh man, this is going to be painful (handling how to get the GZDoom submission up and going again, anyway).

[Major Cooke]

And updated both. The test.pk3 on the front still works as intended.

[Graf Zahl]

I'm sorry but that was most likely a wasted effort. One of the most important portal related things left in the GL renderer is the splitting of sprites along portal boundaries. And guess what: In order to make this work this rotation matrix stuff that's in there will probably have to be removed completely.

Right now it makes no sense to fiddle around with this because I have no good idea yet how to handle all this. And unless that is done I won't add this.

[Major Cooke]

---

Well, at least the zdoom side won't change much if at all, will it?

[Graf Zahl]

Most likely not.

[Major Cooke]

By the matrices, you mean this stuff?

Code: Select all

v1 = mat * Vector(x1, z1, y1);
v2 = mat * Vector(x2, z1, y2);
v3 = mat * Vector(x1, z2, y1);
v4 = mat * Vector(x2, z2, y2);

[Graf Zahl]

Yes, that. Even though I ultimately decided to use the hardware clip planes to split rendering, be advised that splitting across line portals still needs to be done. I would not advise to work on this until that part is complete.

[Major Cooke]

I thought so myself. Just keeping an eye on the logs for now anyway, I had no intention of proceeding further without your green light.

[Major Cooke]

Wait, why is this closed with [Duplicate]?

[Graf Zahl]

Oops, I think I moved the wrong one...

[Major Cooke]

ZDoom pull request updated. Now working on GZDoom. This is going to get ugly... Biospud, we should place our heads together for this.

For safety, I went ahead and broke the save version. Considering how many times saved games have been broken now... Unless you'd like me not to do that.

[Edward-san]

For safety, I went ahead and broke the save version.

Just my 2 cents, but I don't think there was the need for that, since the change to the serialize code is quite limited to one expression.

[Major Cooke]

I can revert it if Graf wishes to just be a save number bump instead, but I'm going to wait on his reply. Or randi's.

In the mean time, I'm trying to figure out how to deal with converting from a DAngle to a float...

[Graf Zahl]

Don't break savegame compatibility unless unavoidable. The sole reason I had to break it several times in the last few weeks was one persistent problem with data order that required a few attempts to get everything right. But since each time I needed to move around some data there was no way around it. Here this is not the case.

[Major Cooke]

Okay. I changed it back.

Both ZDoom and GZDoom versions are updated. There's only one small pick I'd like to address, but honestly at this point I'd rather just bring it up in a new code submission because it's not worth holding this back for.

---

Right now, there is the matter of sprite being flipped on the opposite side of the flat angle. Normally, this would be a non-issue for things that don't have rotations in them. However, I know for a fact that if I used this with things like monsters which have their own rotations, I would want to get this fixed because when looking at them from behind the flat, their sprite is inverted so the sprite aims in a direction it's not supposed to.

I am working on implementing a flag now that disables copying them over on the flip side. Graf, is there any reasonable way to check if viewing a sprite from the other side? The flag will be responsible for flipping the image horizontally if viewed backwards.