Poor performance post- v1.4.

[Garnier]

Wheel,

You should try setting all settings at minimum, and using T in game to disable all the vegetation. If it runs OK like that, then try enabling things one at a time to see what the problem is.

What are your specs?

[Little Powell]

I never like to put things on record without it being at least almost certain that it is causing the problem, so don't quote me on this. But when we went to the packed sprites, the unit textures were packed in 2048x2048 image files. Before, they were packed, the individual files were half that size (1024x1024).

So it's possible that some machines or graphics cards don't like the larger textures, which could be causing the performance issues on some machines, and not on others.

So I think we are going to try reducing the size to see what happens. Stay tuned.

[gunship24]

I didnt notice that much difference in v1.4, if anything there was a slight decrease in performance but i certainly did not get any better fps. I run about 10 fps on the larger scenarios, everything on best and draw distances on 1000. Reducing trees and draw distances in the big winner for me. My pc is 32bit vista, dual core AMD Athlon 6000+, 4 gigs of ram and a modern dx11 HD5770 1 gig gcard. I dont know if that affects anything. I have been upgrading my version since about 1.2 so ive never done a clean install for v1.4 incase thats a possible factor for lower fps.

[Davinci]

I was never under the impression that the latest patch was supposed to speed up the game, only cause the game to use less memory.

Interesting to hear that the 2048x2048 files might be causing a problem, I would have thought that the larger the file, the less demand on the graphics card by not having to continue to switch the files around.

I’ve never had a performance increase with the new png files , jumping topic slightly, my best performance boost came when I converted all of the files to twice their default size. That seemed to work a lot better especially with the crops \ fields.

gunship - nice video card, I was looking at that one a while back, but I would have had to replace my power-supply to get it to work.....so I passed on that idea!

davinci

[Blacklander]

So I think we are going to try reducing the size to see what happens. Stay tuned.

Thanks for this, however it turns out. I quit playing after the release of 1.4 because of the lag that occurs once units reach musket range. I reset the game to 1.3 to play by my lonesome, but it's just not as fun as multiplayer (my group moved on to 1.4 like normal people). If the new "modded mod" works I will definitely purchase Antietam, my "favorite" battle.

And oh yeah, funds for a new computer are in the budget for June.

[2nd Texas Infantry]

I was never under the impression that the latest patch was supposed to speed up the game, only cause the game to use less memory.

Interesting to hear that the 2048x2048 files might be causing a problem, I would have thought that the larger the file, the less demand on the graphics card by not having to continue to switch the files around.

I’ve never had a performance increase with the new png files , jumping topic slightly, my best performance boost came when I converted all of the files to twice their default size. That seemed to work a lot better especially with the crops \ fields.

gunship - nice video card, I was looking at that one a while back, but I would have had to replace my power-supply to get it to work.....so I passed on that idea!

davinci

D, when you make the terrain sprites into a larger file (256,256) vs (64,64) you use less of them to cover the same amount of area (less density level) in the csv files. You know this already.
Its not the size of the sprite file its the number that drags it down.

The packed graphics, save memory for sure, but I think that the compression lessens the quality and crispness of the sprites slightly. I like the PNG format, but since they are compressed into a large DDS file it nulls or voids that format. Although I noticed quite a few people have problems, I suspect its from having a built in graphics processor rather than a dedicated card. That is the only thing that would explain the issues of lag. Its from switching files back and forth, and since everything is active and the tremendous amount of different sprites (units especialy) that the graphics processor has to read...you have to have a decent dedicated card. Thats why Blacklander has lag when he comes into musket range because of the tremendous amount of sprite sheets and the alacrity of movement that is constantly being read back and forth by the graphics processor on his rig.

After saying all that, the requirements listed in the purchase section do list a dedicated graphics card as a requirement.

[Davinci]

D, when you make the terrain sprites into a larger file (256,256) vs (64,64) you use less of them to cover the same amount of area (less density level) in the csv files. You know this already.

Its not the size of the sprite file its the number that drags it down.

2ndTexas – Hey, how is everything going!

This is basically my opinion about the graphics in the game, so bear in mind that this may not be accurate, only how I see it!

The game could probably get better fps if the camera was restricted, or if the camera was pointed down in a sort of angle. A lot of games actually do have the camera angled slightly.

But, Norb has always stated that he would allow the camera to roam freely, so it is this free-roaming-camera that brings down the fps .

When I stated that the units were twice their normal\default size, I didn't alter the dds files, but used the csv files to achieve this.

What this does is reduce the graphics that are shown on the screen at any given time, if the units are twice their default size, then a lot less of them would be viewable.

The same thing in regards to the vegetation. So, I would get better fps due to the fact that the fields density would use a larger number in the mapname.csv file. Instead of using a 1 or 2 , the density could be set at 4 or 5 , thus having less impact on the graphics card.

Basically, to put this another way, if the default size showed five-hundred-men in a screenshot, or on the screen at any given time – the larger-men would only show about two-hundred and fifty men.

In other words, I'm just reducing the amount of men showing on the field at any given-time, which would increase my fps.

This worked for me due to the fact that my graphics card is more than three-years-old. So, I can't really blame the game for that!

davinci

[Saddletank]

D, when you make the terrain sprites into a larger file (256,256) vs (64,64) you use less of them to cover the same amount of area (less density level) in the csv files. You know this already.
Its not the size of the sprite file its the number that drags it down.

My understanding of how most games load textures and use them in memory means the exact opposite is true. It is file size and not the number of files (the number is actually 1 no matter how big an area is covered). If a very large area (such as a basic texture of a battlefield grass) uses one basic texture file it will load that file into memory and then repeat it ad-nauseum until it covers the ground visible. Thus a 64x64 single green texture is more efficient than a single 256x256 texture as the smaller graphic file takes less memory to display.

It should not matter if your battlefield is 1 mile across or 100 miles, if the texture covering it is repeated its just the one file in use.

If a set of textures is not common and only gets used once for one area of the game (such as, say, the green US sharpshooter sprites that never get used except on two units) then this is a good example of extra computer load.

If texturing can be done efficiently so that a users PC has to load the fewest smallest textures that is the most efficient method of design to follow.

Of course the customer wants his game to look good and that means bigger, crisper and more variable textures so that every tree and every farmhouse isn't a carbon copy of every other, so games designers have to balance efficiency of model shape (that is, polygon count) and texture against how good or poor the game looks.

[Gudadantza]

Can anybody run the game with 30 or 40 Fps in great battles?

So, is impossible an angry user play with 11 fps in a modern configuration?

And is possible that the user consider 11 fps very low for his expectations?

low frames are more gameplay tolerable in SoW than in other games but It is not a bad configuration or an infected computer, it is a game limit or issue.

As I said he uses the word unplayable. Ok, for him it is nearly unplayable, but translating it to "bad framerate or unpleasant gameplay" the result is something more common in dual or quad cores.

So it is not needed to be incorrect with an user that is posting performance issues, because if better framerates were achieved in the future everybody would be happy with it.

greetings.

[con20or]

Once the action heats up I am usually less than 20, but thats fine. I play with 60% trees, unit vis 800, obj 700, tree 600 - all objects/uniforms on best.

I usually draw the line if it gets less than 10FPS and start lowering my settings more.