Author Topic: Servers With Bad Textures (Read 7022 times)

BASEBALLDUDE · « **on:** September 22, 2013, 09:56:04 AM »

That's it, I'm officially pissed off. I absolutely hate it when servers think that they can get away with having the wrong textures. Just today I discovered that EV1-Alt Beta Map server has the incorrect texture for "black". The oil slick is supposed to be black, but whoever runs that server decided that it would be perfectly fine and dandy to have a ridiculously non-black texture in place of that.

But this server is not alone. I have been unfortunate enough to play on many a server that depict London's oil slick as a sandpaper slick. This is absolute bulls hit, and something needs to be done about this problem because it is pissing me off to see servers making a mockery of maps by altering the textures.

Attached is a screenshot so you can see what I'm talking about.

ViciouZ · « **Reply #1 on:** September 22, 2013, 03:33:22 PM »

I'm guessing that that's just a very scaled up sand texture in that one too. Can you see if there is a file called black in your pball/textures/pball/hr4 folder?

Rick · « **Reply #2 on:** September 22, 2013, 03:58:57 PM »

Haha. Isn't that Jitspoe's server?

BASEBALLDUDE · « **Reply #3 on:** September 22, 2013, 05:32:53 PM »

It's not my fug king problem. When I play locally my texture is as black as your sight will become if you don't fix this problem.

Edit: That server's textures are correct now.

ic3y · « **Reply #4 on:** September 23, 2013, 01:58:12 AM »

Quote from: BASEBALLDUDE on September 22, 2013, 05:32:53 PM

It's not my fug king problem. When I play locally my texture is as black as your sight will become if you don't fix this problem.

Edit: That server's textures are correct now.

Not a server prob. Do vid_restart next time.

jitspoe · « **Reply #5 on:** September 23, 2013, 08:48:42 AM »

There's a bug where, every once in a while, .wal files will be replaced with some other seemingly random texture. I still haven't tracked down what's causing it. It doesn't really make sense that it would be exclusive to .wal files. vid_restart will fix it. If anybody knows how to consistently reproduce it, let me know.

ViciouZ · « **Reply #6 on:** September 23, 2013, 09:45:51 AM »

Quote from: BASEBALLDUDE on September 22, 2013, 05:32:53 PM

my texture is as black as your sight will become if you don't fix this problem

wow rude

not_payl_obviously · « **Reply #7 on:** September 23, 2013, 10:22:31 AM »

Quote from: jitspoe on September 23, 2013, 08:48:42 AM

If anybody knows how to consistently reproduce it, let me know.

Go play some ariejumps in a row, it will show up.
I was recently even able to intercourse up all console fonts with playing ariejumps & other jumps...

cusoman · « **Reply #8 on:** September 23, 2013, 11:55:45 AM »

I used to be able to reproduce this problem. It happens with any of the pure color light textures as well as the black one. I rarely see it now, and thought it was fixed in a previous build. I used to get it to come up almost 100% by going to Carpathian twice in a row with the map command, and the pure white lights in the caves would have the player model texture sheet. Can't even get the glitch to show up now. Maybe someone else can get it to work?

- Cusoman

jitspoe · « **Reply #9 on:** September 23, 2013, 02:12:08 PM »

BASEBALLDUDE: Which build were you using?

Narga · « **Reply #10 on:** September 23, 2013, 02:33:00 PM »

Quote from: jitspoe on September 23, 2013, 08:48:42 AM

There's a bug where, every once in a while, .wal files will be replaced with some other seemingly random texture. I still haven't tracked down what's causing it. It doesn't really make sense that it would be exclusive to .wal files. vid_restart will fix it. If anybody knows how to consistently reproduce it, let me know.

I always wondered what causes those "models-get-random-textures" bugs like this one. I experienced one of those "models-get-random-textures" bugs in the Sims 2 and it came with lagging.

Are the textures given a memory address or something? Maybe it's displaying textures from the wrong addresses?

not_payl_obviously · « **Reply #11 on:** September 23, 2013, 02:54:12 PM »

Quote from: Narga on September 23, 2013, 02:33:00 PM

I always wondered what causes those "models-get-random-textures" bugs like this one. I experienced one of those "models-get-random-textures" bugs in the Sims 2 and it came with lagging.

Lets begin with that: This bug is not related to models, it is related to map renderer, which takes other textures for textures on map. It is not related to models in any way.

Quote from: Narga on September 23, 2013, 02:33:00 PM

Are the textures given a memory address or something? Maybe it's displaying textures from the wrong addresses?

memory addresses aka pointers are widely used in C and x86 so it is surely related to pointers.
It could be potentially anything, and i don't think it is displaying textures from the wrong addresses, because "wrong addresses" are not just correct other textures pointers. Must be related to way Q2 handles loading of map and displaying textures. Probably Jitspoe could just put some debug info and trace it within few hours, but it is few hours too much for him...

not_payl_obviously · « **Reply #12 on:** September 23, 2013, 03:09:28 PM »

try this to reproduce, could work (works for me, gives me red shirt as wall textures):

Code: [Select]

map jump\ariejump37
map jump\ariejump32
map jump\ariejump37

jitspoe · « **Reply #13 on:** September 23, 2013, 03:27:13 PM »

I think it's more likely to be something with texture ID's than pointers.

What I suspect is happening is something like this:

Map loads the first time, everything is normal. Paintball2 uploads a bunch of textures to OpenGL and has a list of their ID's.

On the next map load, something is causing the .wal textures to be unloaded (possibly something to do with them being 8 bit). The game still thinks they're loaded, but OpenGL has unloaded the textures and replaced them with something else. The ID Paintball2 was using for Texture A is now actually being used for Texture B.

not_payl_obviously · « **Reply #14 on:** September 23, 2013, 03:33:01 PM »

Quote from: jitspoe on September 23, 2013, 03:27:13 PM

I think it's more likely to be something with texture ID's than pointers.

What I suspect is happening is something like this:

Map loads the first time, everything is normal. Paintball2 uploads a bunch of textures to OpenGL and has a list of their ID's.

On the next map load, something is causing the .wal textures to be unloaded (possibly something to do with them being 8 bit). The game still thinks they're loaded, but OpenGL has unloaded the textures and replaced them with something else. The ID Paintball2 was using for Texture A is now actually being used for Texture B.

Yeah, i noticed that it was hard to reproduce it without loading same map twice, but it is possible (same wal?). You might want to try command i gave, i was able to reproduce it 100%.

BASEBALLDUDE · « **Reply #15 on:** September 23, 2013, 06:48:55 PM »

Maybe you can replace all wals that appear in-game with JPGs so this problem doesn't happen. Of course this wouldn't be necessary should Jits fix this issue in the next build.

And sorry if I got angry, I was just trying to get your attention because this is a serious problem.

jitspoe · « **Reply #16 on:** September 23, 2013, 08:28:11 PM »

Switching the textures to jpg would certainly be the easiest "fix", but I would like to get to the core of the issue.

jitspoe · « **Reply #17 on:** September 23, 2013, 10:20:52 PM »

Well, I wasn't able to reproduce the issue, (alternated between the jump maps payl suggested as well as trying several other maps that have .wal files), but I think I've tracked down what the issue is. It is likely heavily driver dependent, which explains why some people see it more often than others. What video card do you have, payl and BASEBALLDUDE?

The issue is this:

Quake2 never handled texture ID generation properly. The way you're SUPPOSED to do things is call glGenTextures to get a list of texture ID's that can be used. Quake2 simply uses its own hard-coded texture ID's. There are, however, a few instances with newer features where glGenTextures is used, and is likely generating conflicting texture ID's. I'm going to try to make the old code use glGenTextures properly and maybe this problem will go away.

Rick · « **Reply #18 on:** September 23, 2013, 11:21:56 PM »

I've got a GTX670 using the latest drivers available (GeForce 327.23) and can not reproduce the texture bug. I used to experience this on my old card, some ATI Radeon piece of crap

jitspoe · « **Reply #19 on:** September 24, 2013, 12:11:20 AM »

Update: I'm able to reproduce it now. It only happens if gl_free_unused_textures is set to 1. As a workaround, you can set this to 0. It won't free textures that are unused when you switch maps, but that should only be an issue if you have a video card with very little ram.