Vega Strike Forums

Two people have reported frame-rate slowdowns when flying the Centurion in PU.
Now there's another ship causing the same effect (Galaxy HQ I think).
These ships haven't been touched. (Well, the Centurion cockpit I DDS's it, but that was *after* the problem was reported; and going back to jpg doesn't solve the problem.)
This all started since the last executable.
Problem goes away in cockpitless mode.
Sometimes it goes away on its own, but changing to external view and
then back to cockpit brings the problem back.
Removing the .pu folder, updating, and starting a new game doesn't fix it.
Here's the thread:
http://wcjunction.com/phpBB2/viewtopic.php?p=7342#7342

i'm almost positive this is the same issue as having a unit take up your field of vision. I can also almost guarantee that it is size bound. Meaning, the size of the texture you're viewing determines how much of a load it will be to display. Be it a unit or the cockpit, it seems to be treated the same.


To me, this screams a per-texture option being set that does some kind of modification to the texture (thus larger ones hurt more). Also note that changing resolution decreases the effect, which would just corroberate that, since whether it's the image size, or the screen resolution, both minimize the texture and thus whatever it's doing to it.

This _HAS_ to be a gl option, becuase DDS files dont get manipulated out of GL.

Either we're hitting the physical limitations of the cards that experience the slowdowns, or we have a problem option being set. It's very possible that these large amounts of textures are overloading the memory capabilities of these cards. (if i overclock my video ram, the problem lessens). I'm not saying that that is it, but it could be. Most games dont use such large textures. It's more likely a bad option being set though.

Your theory makes sense; in fact, the Centurion, and I'm pretty sure the Galaxy too, have larger cockpit textures than most other ships.
Maybe I'll try using a mipmapped dds texture, tonight; just to see what happens.

I would try a non mipmapped dxt1 texture.

Basically, i think making the texture a smaller size, or reducing screen resolution will decrease the issue, but it doesn't fix the problem (assuming hardware constraints aren't the problem).


we need to look at _ALL_ the gl options we set and enable, something is being enabled that is very intensive when displaying textures. It's probably set for all textures, and we only notice it being detrimental on large textures.

I already tried with non-mip-mapped DXT1; I was just having a hunch that maybe WITH a mip-map it might work better; but it's probably a false hunch

Where are the GL options set? I wouldn't mind having a look.

all over gldrv/ but I wouldn't guarantee that that is the only place.

Have you tried different shaders or detail (maximum texture size) settings yet?

Frankly, I don't know where the shaders are; so I'm not totally sure we got them. I assumed so; I set the shader to nicest in setup. I'd take a look right now but I'm at work.
What's max texture size? Never seen that.
Detail settings don't make a difference in pu; we haven't got details, yet (Seriously; what detail affects is at what size in the screen the LOD changes; and we ain't got any LOD's.)

turning shaders on and off doesn't do anything for this problem.

already tried it.

(NEW, BEFUDDLING DEVELOPMENTS...)

Not one, but TWO users report the slowdowns in the Centurion don't happen if they have no armor. As soon as they buy armor, the slowdown commences.

I KNOW... It makes absolutely no sense.

But they insist. I'm just the messenger; don't shoot me!

I can't, for the life of me, imagine what having or not having armor has got to do with the videocard.
The only thing I can think of is that maybe when you have no armor, the armor indicator texture overlay perhaps is removed from the display list; but it's a smallish texture...

For the record:

Centurion cockpit:

Ehm... it was larger than I thought... I think I'll try and bring it down a notch, and let you know...

Armor:

I dont see how that could effect anything. But just to be safe, have everyone experiencing the slowdown to do it. if it's the cause, they'll all report that it works. If anyone says it doesn't change anything, then it's not the cause, and it's likely that we're hitting the hardware maximums as far as texture capacity and processing and that one less texture helps those cards teetering on the edge.

safemode wrote:I dont see how that could effect anything. But just to be safe, have everyone experiencing the slowdown to do it.
if it's the cause, they'll all report that it works.
If anyone says it doesn't change anything, then it's not the cause, and it's likely that we're hitting the hardware maximums
as far as texture capacity and processing and that one less texture helps those cards teetering on the edge.

Thing is, there's only two users experiencing the slowdown, and they both report that it goes away without the armor.
Very puzzling.
I'm going to ask them to rename the armor textures in the cockpit folder, and see if that makes any difference.
Meanwhile, I'll make a smaller cockpit texture. 2k x 2k is insane...

Yehr are you sure all video cards will cope well with such big textures?

No; I'm definitely NOT sure; however, I just learned that the texture in trunk was already 1024 x 1024.

Now, for the BIG NEWS ....

One user just tried my hopeless little experiment of renaming the armor textures, and... lo and behold! ... IT WORKED!
The problem goes away.
So it's those tiny little textures that are causing all the trouble...
Don't ask me how...
http://wcjunction.com/phpBB2/viewtopic.php?p=7428#7428

Here's a question/hypothesis:
Could it be because the little textures already have an alpha channel, AND we're alpha-blending them on top?
(BTW, they SHOULDN'T have an alpha channel; it's not being used. I'm going to try DXT1'ing them.)

EDIT:
DAMN! Just found out another thing: Those little armor images are not powers of two; they are 25 x 100 ...

non pow 2 is a big deal

Okay; they are power-of-two-ized and dxt1'd now and committed. Just waiting for feedback...

Feedback finally arrived. It was indeed the non-power-of-two little textures.
Problem solved.
http://wcjunction.com/phpBB2/viewtopic.php?p=7465#7465

Sorry for the false "bug report".
Even sorrier that this didn't help identify the planet viewing slowdown in vegastrike. BTW, I don't notice planet slowdowns in PU, but I do notice some space station viewing slowdowns. The difference is probably texture sizes; --planets in PU haven't got big textures yet.

yea, texture size there plays a serious role. Though, whatever is going on with the bigger textures, goes on with the smaller ones, it's just that even my crappy Nvidia 6600 can handle the smaller texture operations. I notice much higher gpu use when viewing planets and bases and such, the smaller the texture though, the less of an impact it has on frame-rate, the larger and the more it impacts frame-rate.

It may just be that VS has gotten too intense for crappy video cards like my 6600. We dont pkg low res textures and high res textures, we only got the high res. And we dont currently turn of per-pixel lighting and such either.

Perhaps we need to rethink how we go about altering quality levels, so we dont totally keep people out who have 15 dollar video cards still. Maybe we need to have two repositories for texture data (we'd only need to worry about planets and units and space backgrounds). One repository where nothing is bigger than 512x512 for units and 1024x512 for planets and 512x512 for backgrounds, the other would be the way it is now.


We can test if this will work by setting the max texture size for high quality mode to be 512. We dont need to change any textures. The reason we cant use this for production is that the mipmaps made for DDS, aren't high quality resizes, and so, things aren't gonna look as good as if we used a high quality scaler to resize the images.

In any case, if the slowdown goes away for those experiencing it, the the issue is simply a hardware limitation problem

Would be much less expensive in terms of bandwidth, server space and maintenance, to put a halver routine into the engine. If the user changes the setting to "lo-rez textures" in setup, next time you boot the engine, all textures are scaled down 50% and saved with the same name prepended with an underscore. DDS textures with mipmaps would be the easiest, as all you have to do is throw away the top level.

BTW, for 50% scaling all you have to do is average 4 texels at a time. In the particular case of scaling down by powers of two, simple averaging looks better than bicubic scaling. Bicubic tends to look blurrier for no benefit, when downscaling by powers of two (and any integer ratios, for that matter).

I already have the ability to scale DDS that way.

to check it out, set the max_texture_size in the config file to some small number like 512

Ah, good; so when the LoRez setting is on you can just load from the 2nd mipmap ownards on the fly?
Ok, so that leaves then the non-mip-mapped dds's...
Maybe the best solution would be to mipmap everything and use a single mechanism for lo-rez'ing, come to think...
The size of the un-used, lower mipmap levels is probably much less than the disk space wasted by having two files...
...talking about disk granularity issues.

yea, it's done on the fly. That's how i make retro mode look the way it does. I think if we dont have mipmaps, i dont rescale. Since menus would look unreadable. Basically, i take anything without mipmaps to mean that they would have something you need to read on them, so lower res mipmaps may be unreadable.

I still have to fix it so that when we know ahead of time we dont want to load mipmaps (for when s3tc is not detected), we dont read them in. But that's separate.


Basically, anything without mipmaps, likely isn't something displayed during gameplay, or at least isn't something that is going to singularly affect gpu performance. I think it's safe to not resize mipmap-less files.

Cockpit textures, chances are, are not mipmapped; at least I wouldn't have mipmapped them, since distance doesn't change much; but may need to be.
Are you sure about text not being readable at half-rez? Usually the text on cockpit lights and buttons is pretty big. But, in any case, those textures are small, so it wouldn't make much difference to halve them. Now, if you're talking about text in the poster screens when the game is starting, there's not enough time to read them, anyways But those images are not game-speed critical...

Ok, I get your point, now; so, all you need to do is implement the config variable and load the second map of mipmapped images when LoRez is on. Nice!

half size may be fine, but after that, not so much. test and check. all the code exists already for most things. I'll have to check about mipmap-less stuff.