Is There a Way to Disable V-Sync, Let the Game Use My GPU and Play SC4 Smoothly?

[mawendir 53]

Hello everyone, it's been a long time since I've not been around here. I got a problem. My FPS locked at 60 FPS and whenever I zoom in/out, FPS drops huge, like to 1 or 5 FPS and it's quite bothering. I changed my "Graphics Rules" and "Video Cards" files properly. I switched integrated GPU to high performanced GPU in NVidia Control Panel. I set launch options properly either, like -CPUCount:1 -CPUPriority:high -d:DirectX etc. and I chose hardware rendering in game options. All I want is to play SC4 smoothly with my GPU but without V-Sync, without huge FPS drops, without having any freezing and slowing issues. And lastly, I've noticed that when I save graphic options in game and then restart the game, it doesn't take any effect, it resets to old options. Any help would be just perfect. Thank you already!

[Fantozzi 4,067]

I'm no expert on this but modern graphic cards can do great work on modern 3D-Game as they can take most of the rendering work from the cpu and do it on specialized cores for rendering. Those cores can do almost nothing on SC4 as it deals with already rendered pictures. I'm even in doubt if SC4 can make much use of the gpu's memory because of that. I would doubt you can speed up SC4 with gpu power. I played SC4 on a laptop with shared memory grahics, a business laptop with almost no gaming capability. I didn't notice any difference in speed regarding my PC with an upper class nvidia geforce.  Mostly if I had issues - they were related to drivers and graphical errors. 

If you zooming in and out that means a refreshing of all the pictures contained in the model files. I would guess - most of the work isn't done by the gpu on this but by the hard drive. Or how those three work together: hard drive/interface and cpu. And not access speed is the key factor but the thruput. There is no much rendering work to do - just loading hundreds of new pictures into the memory. So maybe you should check the thruput of your storage.

At least what I can tell from my experience: zooming speed is about the plugin-folder organisation (disk defragmentation too) and data throughput of the system.

[mawendir 53]

My SC4 is in my Steam account and I had to install Steam and all of my Steam games to my HDD, because my SSD's storage is only 128 GB. I'd like to try to move SC4 to SSD and see if there're any improvements but sadly, I have 400 GB of games, so it's impossible to move all of the games or just one game to another location, to SSD.

[rsc204 21,855]

18 hours ago, Fantozzi said:

If you zooming in and out that means a refreshing of all the pictures contained in the model files. I would guess - most of the work isn't done by the gpu on this but by the hard drive. Or how those three work together: hard drive/interface and cpu. And not access speed is the key factor but the thruput. There is no much rendering work to do - just loading hundreds of new pictures into the memory. So maybe you should check the thruput of your storage.

That pretty much sums up the issue. SC4 is not a GPU-intensive game, it's a CPU-intensive one. Honestly, FPS is simply not something you should be concerned about with a city building simulation. You will never see perfect 60FPS gameplay in SC4, but you don't need it either. It's not a fast action First Person Shooter, and it wasn't designed (coded) to work like one either.

Even on the latest high-end rigs, it can take some time to refresh the display when zooming/scrolling. But, the faster your computer can access the files in question, the quicker this process will happen. There is a noticeable in-game difference for me, when my plugins are loaded from my SSD over a regular HDD. Similarly if you are using a lot of custom content, you may find having the game itself on SSD isn't necessary, it's these plugins files that are what the game is accessing. You can modify where the game will look for your plugins folder, allowing you to move it onto faster storage. If you are mostly using the vanilla content this won't help so much, since the files you will be loading will be in the game's install dir instead. Here's how to do that though.

But for the most part, so long as the game is smooth when you are looking at a static screen, you needn't concern yourself with it.

[APSMS 1,893]

Given that zoom changes only happen in strict stages (1 through 6) and each new zoom forces a redraw if not already stored in memory, I'm hesitant to suggest that SC4 is even attempting to use Vsync unless you've manually enabled it for SC4 in your GPU app-specific settings. Like, changing zoom will almost always be a 1 or 2 frame operation because it's not continuous (only set levels), and redrawing, as others have already stated, is more a matter of loading in the correct pre-rendered images in the right order/arrangement.

You'll notice that the terrain and cars often load in fairly quickly. This is the primary GPU usage, because these are all full 3D, and fairly uncomplicated at that. SC4 is indeed a 3D game; the terrain and actually the buildings are too, except that they are mostly boxes with perspective-drawn sides, even the round buildings, which is like the sphere onto cube projection. The textures take time to load; I'd be interested in seeing how fast SC4 loads when on a PCI-E ssd, but it's not really the kind of game people with that kind of disposable income play (certainly I don't have that kind of money!).

Car/automata motion is limited by the CPU, which is why even though you might see cars appear right away, they may not begin moving properly until that specific part of the city is finished redrawing.

[Fantozzi 4,067]

7 hours ago, APSMS said:

The textures take time to load; I'd be interested in seeing how fast SC4 loads when on a PCI-E ssd, but it's not really the kind of game people with that kind of disposable income play (certainly I don't have that kind of money!).

On my pc I have two separated SATA controllers. On one I have a RAID 0 (a hook up of two disk so they can be used parallel which increases data thruput as data is distributed on both disks parallel). SSD and HDD differ mostly in access time. On thruput - the different storage technologie alone don't make the difference. You have to see how the 'highway' works as a whole. F.e. if I put SC4 plugin folder on the RAID 0 I don't get any noticeable win of speed. And the same it would be - if it wasn't a RAID but a SSD. But why? By speficitation both should be noticeable faster!

The reason is the controller. If the thruput limit of the controller is reached it doesn't matter how fast the disk is I connect to the bus, the overall performance win is zero. My RAID - and the same a SSD - would be much faster if I had a faster controller they sit on. My SATA II controller supports theoretical 3 GBit/s, effectively it's roundabout 2,6 GBit/s. No matter how fast the disk is, I plug in.

But then also the cycles, the timing of the memory would matter - not only how the data is taking from the disk but how it arrives in memory. So also, if your mainboard supports it, using both channels for memory might speed up things (f.e.: having 2x4 gb on both memory channels instead of 1x8 gb on a single channel.

One of the problems is - manufactures data don't mean much if you don't know how they were measured and if the way they measured is relevant on your system. Often they tell you only a theoretical data transfer rate - USB 2.0 f.e. has a nominal transferrate of 480 Mbit/s, in practice its 300 Mbit/s and less).

Data transfer rate on a computer system - one has to consider many factors.

The logic to think "I need a faster disc" isn't very consistent. It's even naive. If you put your new SSD on the same controller (bus) with your HDD and your SATA is busy and you access your SSD parallel - it won't be any faster than the HDD. The reason is: those are shared bus systems. This means, each component sitting on the bus shares bandwith with the other. So the SSD would share the highway with the HDD and the SSD can't 'overtake' the HDD. It's like thinking of a highway - what's the need to change the Fiat with a Ferrari if the ferrari makes a line with another fiat in front of it? That's where PCI-e becomes interesting. It isn't a shared bus system - you would call it a point-to-point bus system. Each component has the full bandwith = the full thruput. That's why graphic cards sits on a PCI-e. No other component shares bandwith with it.

Maybe the thinking should start with the highway, with the question - how many lanes there are, who is sharing the highway. And first is to try to use all the parallel tracks your PC offers - put a disk on this controller put the other disk on that controller, so each disk has it's own highway. If your pc memory has two parallel lanes, why using only one of them for all the traffic?

So on data speed problems, don't think of a SSD first. think of the many other options first. 

I would start with the data organisation on the HD (this isn't relevant for SDD, only for magnetic disks). Access time differs on HD, the more data the HD holds the slower it becomes because data first is written on the inner, then on the outher part. By making partitions you can controll this! The first partition will be on the inner part. That's exactly the reason why system partitions should be the first (think of - how you only repeat this with SSD what with HD already is done). Remember there are two different forms of fragmentation. One can be handled by defragmentation-algorithms. One you have to care yourself as no software can handle it.

Second step: take the mainboards handbook and see what slots there are to plugin storage and what the difference is and how fast they are. Read too what buses these slots are connected to, if there are different busses with different cotrollers that handle the slots. On my mainboard f.e. there are 6 slots for SATA but only two different controllers (first: 4 slots, second: 2 slots). Now, if I put 2 HD on the first controller (slot 1+2) and both become busy, each one may have a transfer rate of ~1,2 GBit/s. If I put them on the different controllers (slot 1+5) they will have a transfer rate of ~4 GBit/s. Look what a difference! Because of how shared Busses work you did more then double the thruput performance.

Third would be to think of memory. Timing (working cycles) isn't that relevant, but frequency (FSB) ... so again: the highway.  For this highway often the word 'northbridge' is used. So that's the highway your PCI'e e and the cpu will use to communicate with the memory. Here's the one thing you would look for: if this bus has two parallel channels (Dual Channel Controller) - do I really use both (two memory banks in the right slots)?

Those were the 3 things I would check first - and then before buying a SSD - again I would check the data of my mainboard. Because mostly you only will have speed advantages from a SSD because you're only changing your system exactly the same way (without much thinking) as you could do it also with two HDDs (= using a separate controller = f.e. PCI-e parallel to SATA). Mostly it isn't the SSD itself that made the difference for you but the different setup of the system, the parallelization.

After reading in my mainboard's handbook (and with the knowledge that only ca. 80% of the theoretical data transfer rate can be used under real conditions) I get the information that my PCI-e 2.0 port will reach 2,5 Gbit/s (gigabits per second). So will I profit putting a SSD with 6 Gbit/s there? No. As my SATA II controller and the disk are specified for 3 Gbit/s.  -20% off).

The advantage of the PCI-e Bus would be another. As it is no shared bus system (see above) you can put a SSD in every free slot without any performance loss. While SATA (if you use it on the same controller) each disk will share the bus and they will share bandwith and if used parallel, data thruput of each disk will go down. So again: mostly you can reach the same improvement you get with a separate SSD also with a separate HDD on a separate controller - the speed effect comes from splitting up the lanes, not from the disk itself.

Still the biggest advantage of SSD cards are faster access and shock resistance. But regarding thruput the configuration of your system is much more important than the different storage technologies. Imho.

 

[rsc204 21,855]

RAID (depending on the configuration) and SSD technologies are faster than a single SATA HDD. Of course its true you need to have the hardware elsewhere (motherboard) to properly support this additional speed. Generally speaking SSDs won't give much performance boost unless you are using a SATA 3 or higher bus (SAS). That said, I put a 60GB SSD into a Core2Duo system running Windows 7 and the boot time and access speeds were much quicker. Heck, I've got an SLC SSD in my Atom (1.3Ghz underclocked) notebook which runs on a PATA ZIF bus (that's the same system the original iPods used for HDDs) and it put the previous HDD to shame. The reason why an SSD will almost always be faster than a HDD is not a limitation of the bus, although that must be considered. It's because an SSD has much faster seek times, i.e. it doesn't have to go looking for the data. This is why defragmenting an SSD is a total no-no, they don't get fragmented, they simply don't need the data stored according the frequency of access, to improve seek times.

Coming back to the Core2Duo system, running on an Intel P45/ICH10R bus, I added to that a special PCI-E controller which gave it both USB 3.0 and SATA 3.0 support, two things which were not supported natively. Despite a system which isn't best designed for such technologies, I did see improvements in the speed of using compatible SSD and USB devices. So it's very possible to improve performance with these technologies, if you have the right hardware to take advantage of them.

One thing I hear a lot, which is based on very outdated wisdom, is the idea that a user should manually defragment or run scandisk on their systems. This information is bunk if you are using a system from WinXP onwards. Why?, well that's because the Operating System is handling all of this for you automatically. Go run a defrag check, your computer will most likely tell you the system is 0% fragmented and does not need to be defragmented. Similarly if there is a need to run scandisk, the computer will initiate this without you needing to worry about it.

Whilst in practise adding a PCI-E card to your system won't cause a bottleneck, in reality it does. This is because your motherboard has a set number of lanes shared between all devices plugged into the PCI-E bus. So for example, with just my Videocard in my 3 PCI-E sockets, it runs with 16 lanes. But add another device and each will only have access to 8 lanes, add a third, then you get 8 for the primary device and 4 for the two remaining devices. The reason this doesn't generally cause a bottleneck is because few devices require the full 16 lane bandwidth in the first place, but it's still a limitation of the system.

Ultimately HDD technology has hardly changed since it's inception, i.e. a basic spinning platter read by a spindle. Think of this like a record player, only the disks are smaller and the data (grooves) are very tightly packed on the discs. Sure the rotation speeds have gotten faster, capacities have grown and the interfaces for data transfer have improved. But for the average system in the last 10 years sans an SSD, the HDD is the bottleneck in your system. Today both WD and Seagate are working on newer technologies to get out of the technological dead end that we've run into with HDDs. In the case of WD, that's using HSGT's Helium Filled HDD tech, Seagate are using Shingled Magnetic Recording to improve theirs. But both these advances are aimed at increasing the capacity of drives, without them being hopelessly unreliable. They provide a minor speed improvement, but SSDs are still way out in front on that score.

Of course the question here is, will any of this make SC4 faster? Well in my experience the answer to that question is yes, it will. However, you have to have reasonable expectations here, is SC4 twice as quick running this way? Maybe not, but there is a considerable improvement in loading times and a much snappier responsiveness in game. Mostly because the SSD can access all that data so much more quickly than any HDD could possibly hope to do. One caveat though, if you DAT pack your Plugins folder, you can mitigate the gap somewhat. This is because most of the speed gains are based on accessing many small files quickly. Something SSDs do really well, but HDDs not so much. However, if everything is in a small number of large files, the speed difference becomes far less noticeable, as the HDD has much less seeking to do. Seeking being the thing where SSDs excel.

[jeffryfisher 2,176]

19 hours ago, rsc204 said:

Go run a defrag check, your computer will most likely tell you the system is 0% fragmented

Hmmm... My XP system never defrags itself, and if there's a simple switch to make it do so, I haven't noticed. It certainly wouldn't do so by default (or I would have noticed). Maybe default auto-defrag came with a later Windoze version?

19 hours ago, rsc204 said:

if you DAT pack your Plugins folder, you can mitigate the gap somewhat

Amen. I need to read up (again) on which parts to pack. Among other things, I have "lots" of CAM-tastic buildings in hundreds of model and dat files that I should probably bundle together.

As for the OP, I think v-sync is controlled by your graphics config software. The card should have come with a control panel of some kind. SC4 is too old to know anything about v-sync, so its effects are purely a function of your card (and its config) and your monitor.

[rsc204 21,855]

4 hours ago, jeffryfisher said:

My XP system never defrags itself, and if there's a simple switch to make it do so, I haven't noticed.

It's part of Windows Scheduler. Perhaps I'm forgetting something, but I was sure it was on by default in XP? Either way it certainly is from Vista onwards, and with a little manual setup, it can be in XP. Set and forget, there is no need to think about it.

[Compdude787 916]

11 hours ago, jeffryfisher said:

 

On 4/30/2017 at 5:39 AM, rsc204 said:

Go run a defrag check, your computer will most likely tell you the system is 0% fragmented

Hmmm... My XP system never defrags itself, and if there's a simple switch to make it do so, I haven't noticed. It certainly wouldn't do so by default (or I would have noticed). Maybe default auto-defrag came with a later Windoze version?

 

Actually, Windows Vista was the first version of Windows to defrag the hard drive automatically.

[jeffryfisher 2,176]

6 hours ago, rsc204 said:

It's part of Windows Scheduler.

Aha... So if one is told how to set it up, then it is possible to schedule defrag as a task. I wonder how many XP users bothered (or were even awareof the scheduler). I mean, I've seen its name, but in 15+ years I never looked into it to see what it could be used for. I just defrag my system disk manually whenever I can't remember the last time I did it (which turns out to be about once per year).

On 4/30/2017 at 5:39 AM, rsc204 said:

SSD has much faster seek times, i.e. it doesn't have to go looking for the data. This is why defragmenting an SSD is a total no-no, they don't get fragmented

I've just done some reading on this (because I might buy one someday), and there are credible articles disagreeing. An SSD can (and will) become fragmented, and there are secondary effects (beyond seek time) for which an SSD should be defragmented. It has to do with the volume of metadata needed to manage great numbers of fragments, especially for any one file that becomes badly fragged. I take that to mean that an SSD will need to be defragmented once or twice during its service life.