A small problem regarding rendering custom textures in OpenGL/Software Mode

Hello. For over a month I've been working on some seperate projects. I've run into a significant problem involving how my custom patches/textures are rendering in both Software and OpenGL. The first issue I've come across is in regard to a custom sky texture I made, which doesn't render correctly in software mode -- in OpenGL, however, it looks just fine. The second (and rather the one that's of greater concern) problem involves a patch I'm using for a Metropolis Zone-style piston. The side of the piston's texture looks fine in OpenGL, yet looks like a complete mess in software mode. I'm providing images of the two problems below.

Click to expand...

I haven't poked around too much with the first map and the skybox issue, and that's mainly because I use OpenGL in SRB2 for just about everything. I only came across the issue by accident when attempting to record a GIF of the second map with the piston. I fiddled around and replaced the piston texture with one of the default textures, and that looked just fine. Chances are it has something to do with the transparent part of the side texture, who knows.

Now, I'm still rather inexperienced when it comes to map-making, and I don't have any extensive knowledge of the SRB2/Doom engine, and I'm not even sure if this a problem related to editing -- let alone one I can solve. Is there anything I can do to fix this, or is this just how SRB2 goes about handling this sort of thing? Any help would be appreciated.

The first problem is in the map design, not the sky. Something about the way you have your thok barrier set up is creating a hall of mirrors effect in Software, and OpenGL is technically in the wrong here by not being 1:1 with the software renderer.

The second is a bug in how Software handles blank pixels on the side of FOFs. It assumes that the first column of opaque pixels in a given X coordinate will extend all the way to the bottom of the FOF, so when your custom texture cuts off before it reaches the bottom, Software keeps reading the texture lump and ends up rendering the header information for the next column of pixels (that's the black and white garbage) and eventually the next column of pixels itself.

The only way to avoid this is to ensure that all the opaque pixels on your FOF textures are arranged in single, contiguous columns, ie. no holes in them, and that they're all aligned to the bottom. In the example you've shown, I assume you want the FOF to bob up and down and close the shape, so what I would recommend is to do the floating part with middle textures, which don't have any such problem, and use an FOF for the bottom static part instead.

The first one may be an issue with the skybox viewpoint going outside of the actual skybox. Maybe try figuring out where the viewpoint's going and add a couple sectors there to make it render properly?

The second issue's a problem with how Software renders FOF sides. You could get around it by using extra linedefs on the inner edges of the sector and applying midtextures to those, but that's a really hacky way to do it and will take a lot of setup to get the effect you want.

edit: fak u neo

RedEnchilada said:

The first one may be an issue with the skybox viewpoint going outside of the actual skybox. Maybe try figuring out where the viewpoint's going and add a couple sectors there to make it render properly?

Click to expand...

Upon removing the skybox waypoints, that fixed the issue. I think it may have been because at an earlier point in development, I was attempting to figure out how to set up a skybox that made the map look like it extended into the distance. But that's something I'll have to figure out in due time.

As for Neo, could you elaborate as to what I need to be doing? I adjusted the side texture so that the image itself isn't drooping and maintains its shape, but the black/white garbage still remains.

And are you referring to the small upside-down trapezoid-like shape as the floating part? Or the piston texture entirely? I think I'm reading too far into what you're telling me to do, and if so, forgive me.

I'm assuming the bottom part of the piston shell is a middle texture, and the top part is an FOF. Basically, the trapezoid shape in the middle texture is FOF-friendly, but the upside-down trapezoid shape on the FOF is not.

What you need to do is switch it around, have an FOF right on top of the floor with the upright shape and then use middle textures with the appropriate Y offsets to put the upside-down shape up in the air. It's a bit of a complicated mess, but it's the only way to keep those shapes in that particular configuration and have it display correctly in Software.