I just come back from the big mistake of running ring atoll in a multiplayer game on this computer, which isnt that good.... And ti lagged to hell.
One thign I noticed is that my computer lags when I switch to a different part of the map or move the screen and when I do this I notice the detail texture and that it's usually changing to a higher or lwoer res as I do this being re-applied. This was true of my other computer before spring got faster and I upgraded it.
So please could we have the option to disable the application of this and just have the texture darkened some more instead of reapplying this detail texture on low end PC's as we zoom in and out and around the map???
PS :: Ring atoll (20x20) ran much slower than aGorms supcom map (28x28) on my computer whcih can be expected since noizes map has more detail
Detail Texture and the lower end
Moderator: Moderators
I don't think it is the detail texture, I think it is the terrain usint LOD. The detail texture and everything else blurring is because of mip map levels, An older rendering trick to save memory when rendering textures. It works by rendering textures smaller at a distance, turn it off and your game will run slower.
It is the terrain LOD that slows you down. Because it is adding a lot of polies and hiding others. That is a much newer technology.
It is the terrain LOD that slows you down. Because it is adding a lot of polies and hiding others. That is a much newer technology.
wrong.
gpu doesn't really use cache in the way a pu uses it.
all of the texture (or of the mipap, wich is a smaller pre antialiased texture) need to be readed to be put on screen. the cache is used to local pixel/vertex/texel operation, but you could usually assume that the texture is readed from the main memory and each texel processed in cache so mipmap doens't affect cache in this way.
sure having a mipmap for distant area means that smaller texture are fetched from card memory to gpu, thus resulting in increased performances.
but pixel processing is a complicated matter, with the never superscalar architecture.
also notice that branching shaders instructions are up to 50 times slower than others... but I don't know how the trees are implemented. Only looked at the water shader (Hoping to find a way to make it work on ati... sigh)
gpu doesn't really use cache in the way a pu uses it.
all of the texture (or of the mipap, wich is a smaller pre antialiased texture) need to be readed to be put on screen. the cache is used to local pixel/vertex/texel operation, but you could usually assume that the texture is readed from the main memory and each texel processed in cache so mipmap doens't affect cache in this way.
sure having a mipmap for distant area means that smaller texture are fetched from card memory to gpu, thus resulting in increased performances.
but pixel processing is a complicated matter, with the never superscalar architecture.
also notice that branching shaders instructions are up to 50 times slower than others... but I don't know how the trees are implemented. Only looked at the water shader (Hoping to find a way to make it work on ati... sigh)
I clearly noticed a lot slower rendering in my map renderer...
And for theory, I am guessing the GPU does standard things like reading ahead when reading texels. If the texels are further ahead, the chances are bigger that the GPU can't use its cached data but has to read it from the main memory.
But I already confirmed this in practice, guess I will have to finish my map renderer before you people believe me :)
And for theory, I am guessing the GPU does standard things like reading ahead when reading texels. If the texels are further ahead, the chances are bigger that the GPU can't use its cached data but has to read it from the main memory.
But I already confirmed this in practice, guess I will have to finish my map renderer before you people believe me :)
Don't know if this contributes anything, but:
Anglo-saxon starfish isle runs quite slow (frames per second-wise)compared with most other maps.
For instance, Altored Divide runs smooth as silk on even very low end and mobile chips I've tried it on or seen it played on.
I don't know what the difference is. Both are roughly the same size if I remember right, and the only thing I can think of is that AD has very little texture compression. I don't know if that would have an effect on anything though.
Anglo-saxon starfish isle runs quite slow (frames per second-wise)compared with most other maps.
For instance, Altored Divide runs smooth as silk on even very low end and mobile chips I've tried it on or seen it played on.
I don't know what the difference is. Both are roughly the same size if I remember right, and the only thing I can think of is that AD has very little texture compression. I don't know if that would have an effect on anything though.
-
Drone_Fragger
- Posts: 1341
- Joined: 04 Dec 2005, 15:49
Talking from the rectum is bad, it smells equally distastefull.Drone_Fragger wrote:Could be. Might be trying to uncompress textures as soon as you look at them or somethign crazy like that.
There is no compression it is a simple image swap.
When caydr said compression he meant compression of the map. Not true texture compression. Mapconv when told to use higher compression uses less tiles. That is heavy loss compression. There is no real time compression of the map. After compile it is set with those tiles. Which all have their own mipmap levels.
Mipmapping is just a simple image swap you render a smaller texture(that is stored in the DDS) in the distance. If you do not use mipmapping it will be rendering the full sized tile at all distances. Which means that out of the 100s of 1000s of tiles they will all be entirely composed of thier base tile. That is a lot to render vs rendering a simple smaller tile with less information.
In a fps when you are dealing with one or two textures it is no big deal but spring's maps are composed of 100s of 1000s of tiles(depending on the map it may be less) those tiles each have a smaller version of themselves in order to put less strain on the render.
As opposed to terrain lod with is a matter of removing/adding/aligning/texturing/show/hiding vertices...
That is why I say it is the LOD for the terrain.
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
The main problem with the mipmaps is that, in theory, they're much faster than using a static map... except for the fact that very little in Spring is being precached properly. IOW, a mipmap is great if we're telling the GPU to fetch and render a bunch of 32/32 textures for things that are way far away, but not so good if every time a mip level is needed, the GPU has to make a request to the much-slower system RAM, have that information delivered across the bus, etc. before executing.
Spring isn't precaching any content, other than the bitmaps that are reserved, including the 3DO bitmaps that are combined into the final "sheet" come game time. This is a huge problem, and it's a big part of why S3O performance, to date, is surprisingly bad, I suspect.
Spring isn't precaching any content, other than the bitmaps that are reserved, including the 3DO bitmaps that are combined into the final "sheet" come game time. This is a huge problem, and it's a big part of why S3O performance, to date, is surprisingly bad, I suspect.
My point was that whenever i move the camera ro use the minimap theis detail texture is changed to the appropriate new size or 'mipmap' and reapplied tot he texture, which causes a lto fo lag ony my computer.
What i was askign was that a single tiny texture with no detail on it, say a 1x1 pixel image with a medium gray colour be applied everywhere regardless of camera height and terrain proximity, and that the whole re-application need never happen at all.
Or better yet the terrain gets darkened at startup then no detail texture is ever applied to begin with.
To have such an option would ease things a lot for certain maps on lower end computers if enabled..
There are lots of people with computers that just breach the lower limits of spring requirements, and will run small maps ok with all the settings at their lowest at a low resolution, but this problem makes some maps a nogo zone, especially large and detailed maps....
What i was askign was that a single tiny texture with no detail on it, say a 1x1 pixel image with a medium gray colour be applied everywhere regardless of camera height and terrain proximity, and that the whole re-application need never happen at all.
Or better yet the terrain gets darkened at startup then no detail texture is ever applied to begin with.
To have such an option would ease things a lot for certain maps on lower end computers if enabled..
There are lots of people with computers that just breach the lower limits of spring requirements, and will run small maps ok with all the settings at their lowest at a low resolution, but this problem makes some maps a nogo zone, especially large and detailed maps....
It does it when i zoom in and out too.
When on maps bigger than 10x10 on my stepdads crappy computer I have the viewradius slightly larger than what i can see and I never zoom out fully because it lags when i do so, and I try to keep to the same zoom level all the time.....
For now I'm replacing my detail texture with a 1x1 medium gray bitmap to see what happens....(I know it wont make a difference for maps that deifne there own texture unless I repack them tho)
When on maps bigger than 10x10 on my stepdads crappy computer I have the viewradius slightly larger than what i can see and I never zoom out fully because it lags when i do so, and I try to keep to the same zoom level all the time.....
For now I'm replacing my detail texture with a 1x1 medium gray bitmap to see what happens....(I know it wont make a difference for maps that deifne there own texture unless I repack them tho)