Any ways making Vis Range High usable?

[Squid]

over the past few years I have managed to upgrade my pc twice before i had the chance to fly LOCKON again as sad as it sounds ... :(

 

So, going from XP 2700+, 2x512 DDR333, AGP 6600 GT 128, and LO 1.02, I tried the other day FC 1.12a on the current X2 4400+ @ 2.5, 2x1Gb DDR450, PCIE 7800GTX 256 @ 470/1300 to find out that i still cant use high visibility range which was one of the annoyances of my relationship with LO due to its engine drawing the objects (and targets) too late for me to spot without the disturbing labels and to align properly on time for a weapons release

 

Although the situation improved somehow using high range visibility, its still droping the fps to like 13 over urban areas (and keeping all other settings to medium, not even civilian traffic activated, basic haze, medium scenery density etc)

 

I was hoping this wouldn't be a case anymore with my latest rig .... :(

It seems that although in terms of Graphics there have been cards up to the dx8 lockon engine challenge since even the 6600GT (or 9800XT) level generations but in terms of CPU power LockOn is still a challenge for todays maistream (single core i guess*) CPUs?

 

(*) from what i understand multi core CPUs arent any beneffit for LockOn?

[britgliderpilot]

It's all about CPU power.

 

Lomac won't strictly make use of dual core CPUs, but the new Intel Core 2 Duos still stand head and shoulders above anything else.

 

I'm running an E6400 at 2.5GHz (up from 2.13GHz as standard), and it's coping very well - an overclocked E6700 or X6800 might crack Lomac :)

 

 

However . . . . just as the AFM and high detail 3D model of the Su25T decreased performance in Flaming Cliffs, so the more complex helicopter AFM and even more detailed Ka50 model will affect performance in Black Shark.

[zorlac]

multi-cores do help a bit, but not strictly how you would imagine. I upgraded from an AMD 3200+ to a AMD X2 4800+ and nearly doubled my frame rate... took me a good couple of hours to work out that the core that wasnt running lockon was being used by the graphics drivers (90-95% on one core with lockon, 50-65% on the other core for gfx drivers).

[Squid]

multi-cores do help a bit, but not strictly how you would imagine. I upgraded from an AMD 3200+ to a AMD X2 4800+ and nearly doubled my frame rate... took me a good couple of hours to work out that the core that wasnt running lockon was being used by the graphics drivers (90-95% on one core with lockon, 50-65% on the other core for gfx drivers).

 

what exactly are you saying you did here? were you able to edit the way LockOn is using the multicore CPU? how?

[zorlac]

I ran lockon on a single core using the procaff application, but that was only to remove the online network stutter you can get on some systems when running on multi-core machines. If my system didnt have this problem, then what I said above would still be true. With multi-core, when an application is hammering the system but is NOT properly multi-core aware, it will only use one core at a time, allowing other applications to choose the next core than is currently "idle". In this case, the graphics drivers end up using the spare CPU cycles on the other core.

 

So, in short, even though lockon itself is not multi-core aware, the rest of the system services and programs will use any CPU that is available, including the graphics drivers.

[Squid]

and what nearly doubled your framerate?

[zorlac]

Pretty much

[Squid]

lol :) "what" not "that" :) i would appreciate any clarification more on this. My apologies for being slow this morning :) Thanks again

[zorlac]

Slow indeed :)

 

OK, how can I explain this.... if you have multiple cores, then you can have two applications running at any one time, one on each core. With multitasking, the system will generally make a task that wants to run be process on the next available core/cpu that is ready. So if Lockon is running pretty much flat out, but can ONLY run on one Coreat a time (whichever one that may be), then the rest of the system will be able to use CPU time on the other core.

 

On my system, I used the procaff application to ensure that lockon only ran on core #1 (but only to remove the online stutter)

 

Core #1 - Lockon

Core #2 - everything else

 

So when lockon hands off its graphics calls, the graphics drivers can use core #2 without taking any clock cycles away from core #1.

[Squid]

i got the process , what i didn't get is if thats the default multi core handling profile of Lockon (practicaly a lack of one) or you set up something yourself to have it work this way. I am not familiar with the procaff, what is it ? *blush*

 

So if i got my english in a decent shape:

 

• you used the procaff application to fix the network (lockon online gaming?) stutter issue and it was then when you noticed that lockon is using one core and most of the second core is occupied by the graphics card drivers (and other background services) and its not that you did something to force this kind of CPU handling.
   
  
• moving from a single core 3200+ to X2 4800+ it nearly doubled your framerates just by that alone (without you doing somethinig else to achieve this)
  

 

am i getting it right?

thanks for your patience :D lol

[zorlac]

that pretty much sums it up. I changed motherboard and CPU, but the rest of the system was the same (drives, memory, graphics card, etc)

[Squid]

I ran lockon on a single core using the procaff application, but that was only to remove the online network stutter you can get on some systems when running on multi-core machines. If my system didnt have this problem, then what I said above would still be true. With multi-core, when an application is hammering the system but is NOT properly multi-core aware, it will only use one core at a time, allowing other applications to choose the next core than is currently "idle". In this case, the graphics drivers end up using the spare CPU cycles on the other core.

 

So, in short, even though lockon itself is not multi-core aware, the rest of the system services and programs will use any CPU that is available, including the graphics drivers.

 

So this is how LockOn will be functioning by default without the user having to force (by task manager affinity options? or procaff?) LockOn to stay on one core?

 

Having one core dedicated completely to LockOn and having everything else using the other core (next available) sounds like a decent behavior scheme. If i am getting it right, if it was a single core, something like a 50% of it would be occupied by graphics drivers and other services leaving about half of the CPUs potential available for LockOn?

 

And if LockOn was written to recognize and address both cores it would actually add the utilization of the rest of free potential of the second core, something like an additional 30%? Would that have a worthwhile effect on performance or would be nearly negligible?

[zorlac]

Windows multitasking defines which CPU or core an application is assigned to (unless the program itself is forced to run on a specific CPU/Core). If a task is ready to be run, the system will hand off CPU time to whichever CPU/Core is next ready to run something. By default, Lockon will run on whatever CPU/Core is ready to run something, and hence lockon itself can swap between CPU/Cores.... it doesnt care which one, it just wants to run, and the system happily passes it to the next available CPU/Core that can run it.

 

Using procaff to start an application just tells the system that the named application (lockon in this case) can only run on Core #1. It doesnt mean that other tasks cannot run on Core #1.... if a task needs to run, and the next core that is ready to run something happens to be core #1, it will run on it, but with lockon running almost all the time, core #1 tends to onloy run lockon.

 

Most applications run then sleep until they need to do something. Only when they wake up do they get run. Games on the other hands tend to never sleep.... they want to run flat out 100% of the time. So telling procaff to run a game on one core means that the game will only run on that specific core, and will mostly use all of the CPU cycles it can get.

 

Now, the other "normal" applications will sleep until they are requested to do something. In the case of the graphics drivers, they sleep until something tells it to draw/process something. It will then request CPU time from the system. With the game running as much as it can on core #1, the system will hand out CPU cycles on whichever CPU/Core is "free" to run something, which would mostly be core #2 in this case.

 

As games become more and more multicore aware, they should be able to use ~100% of all the cores. The game will want to run 100% on as many cores as you have, and the system applications will wake up and do their work as well, taking CPU cycles away from the game but only when they need to. The two combined should be able to use 100% of all the cores (or as close to it as you can get).

[VMFA-Blaze]

Zorlac that was very informative... Thanks for explaining this CPU work related idea in such detail...

 

I'm actually running an intel e6600 and its really handling Lock On well..

 

I'm actually able to somethings now that I had only dreamed about a few years ago... A2G is very realistic for example... I can hold the piper on target with minimum effort and get some very clean kills... I'm also running everything on high and I can even see cloud reflections on water just to name 2...

 

 

~S~

 

Blaze