Rotated wall textures

[RockstarRaccoon]

I'll note that I know rotations would be easier in GL, just because I've seen that in GL, but I suppose I just don't think about the software renderer.

And to be fair, I am looking into expanding (as in, adding scaling to) the image editing capabilities of SLADE, which would be far more appropriate as a place to put a texture rotation algorithm, but keep in mind, it's not as simple as simply rotating the textures on a matrix, Because unless you use other tricks you not only lose fidelity, but what do you do about the edges?

When I make my rotated textures for diagonal geometry, I have to play with the scaling and a few other things to make them work properly. It starts with scaling them up to 4X using an xbrz plugin, then tiling them to another 3x, then rotating by a multiple of 15 degrees with the noHalo algorithm, then cropping them back down, then putting in the vertical and horizontal version next to it, then carefully scaling using another noHalo algorithm until I get the features to line up properly, because that's not how rotational math works. Then I finally crop out the rest of it and I have a diagonal version of the texture. This is a time-consuming process that doesn't look as good as simply having the graphics card rotate it, that's why I asked. But as Rachael said, it's apparently not as simple as I was thinking because of the need to support Legacy renderers.

[Pixel Eater]

Can other variables than the timer be passed to a texture-mounted shader? Maybe it could be warped and tiled that way. It would mean duplicates of textures presumably and it'd be preferable if Slade generated a GLDefs file from the transformations made in the map editor. But having never made a map (for DooM) I could just be talking out my ass here

[zrrion the insect]

You might be able to pass custom udmf field data into a shader, and have a function that runs once over every side and then passes the info from that field to the shader. Idk enough about shaders to know if that would work but it sounds close.

Better to either do it by hand or wait for a feature to do it properly.

[Pixel Eater]

You might be able to pass custom udmf field data into a shader, and have a function that runs once over every side and then passes the info from that field to the shader. Idk enough about shaders to know if that would work but it sounds close.

Better to either do it by hand or wait for a feature to do it properly.

Yeah I only know as much about shaders as what I've learned here and I've done very little with non PP ones.
I would make the graphics externally if I were mapping too but I can see how it would be convenient to adjust it live in the map editor. Wouldn't it look better calculated by the game's rendering too?

[RockstarRaccoon]

Can other variables than the timer be passed to a texture-mounted shader?

...This might actually work, seeing as Blade of Agony used spinning textures from a GL shader at some point...

[Pixel Eater]

You could have multiple shader files preset to common angles I guess, which ignore the timer altogether. I wonder if offsets need to be considered though...

Edit: And scaling. So there could be two versions of a 45deg shader, one that scales to root2 and another to root.5 that doesn't?

[Rachael]

I've never tried it before but does the texel coordinate system in the material shaders recognize coordinates beyond 0.0 to 1.0? You might not be able to create a 45 degree rotation shader without the root2 scaling, if not, because otherwise there would be no way to recognize if you're on the main texture face or on a repeat face.

[Graf Zahl]

Wall texture slanting shouldn't be done in the shader but in the preparation code. And yes, shaders can access any valid texture coordinate. Don't forget what happens with those values that get put in a vertex buffer.

[Rachael]

I'll agree with you from the perspective of an engine feature - I think the shader was simply being proposed as a band-aid until it's implemented.

[RockstarRaccoon]

You know, it just occurred to me, would 90° implementations be easy to implement? Perhaps those could be implemented in the short term in the same format that a more robust rotation setup would be implemented with? That way, we could have the one thing done as an example for later...

Just spitballing at this point, really, I'm aware that we will have to do all of these by hand.

[Gez]

90° rotations are already supported in TEXTURES.

[RockstarRaccoon]

Oh yeeaaah, I always forget about that....

[Darkcrafter]

Hrm... as to me, it would be much more simpler to do all these manipulations within doom builder? So it would bake the textures.

[simc]

(One idea) How about camera textures? By setting the camera pitch directly down or up (89, 255) you are free to set the camera's own angle what ever you want and you'll get the camera view of the "rotated" floor or ceiling. Rescaling makes the texture compare better to Doom original textures resolution.

I tried this with GZDoom 3.2.5 and 3.4.1 and two computers (AMD, NVidia) and the scaling and offsets seemed to be the same in both. Wonder if this method would be safe or sound to try?

https://i.imgur.com/dBZscI1.jpg

Pros: Decals.
Cons: Doesn't work with software renderer. The camera pitch (89, 255) isn't exact directly up or down so there's a minor clitch in texture repeating. This method might not suit for large or hires textures anyway (effect on fps?).

Setting up the camera angles and the texture offsets is from hell at first but it gets easier soon.

[Nash]

No more hacks and workarounds, people. Just wait for it to be done right at the engine level.