TheSniperFan

It's impossible to tell, because we don't know what exactly makes DCS run the way it does. It could be any number of things. What we can say with a reasonably high degree of confidence is that it's CPU-side. The CPU appears to be the bottleneck. Multithreading is exactly how one would address that, except there are some problems. Writing an all-new engine from scratch isn't reasonable. It would be an unfathomable amount of work. Therefore some of the old, sub-optimal code is going to stay. How much of an impact is that going to have? Impossible to tell (see my first sentence of this post). There's more than one way of doing multithreading. Some of them are relatively simple (e.g. offloading long-running calculations to their own thread), others are more sophisticated (e.g. task graph based on a DAG). The former can be worked into existing code relatively easily, but doesn't have the same potential as the latter. However, the latter can't be just added easily. Algorithms have to be programmed in an entirely different way to make use of it. The missions use lua scripting, which isn't exactly the fastest way of doing things. It does have its benefits, but performance isn't one of them. It can be reasonably fast for some things and maybe ED has already done a stellar job of making that part of the engine fast. We don't know. Besides, changing stuff about how missions are made; is that going to break all existing missions? And speaking of breaking existing things... What about modules and campaigns from third party developers? There's a limit to how much you can improve bad designs while still maintaining backwards compatibility. How is ED going to handle situations in which an improvement would make existing content/modules incompatible? Do third party developers have a contractual obligation to update their modules in such a case? Can ED update third party modules themselves? Will ED leave the old code in and provide the new, faster code for developers going forward? (This would mean third parties would have to update their existing modules at their own discretion for there to be performance benefits.) Or are they just going to not touch such things, leaving more opportunities for optimization on the table? We don't know. It all comes down to the same issue: We don't know why DCS runs the way it does. Which parts are slow? Which are optimized to hell and back? Which can be improved with a reasonable amount of work? Which would open a can of worms that ED isn't willing to deal with? We don't know. I won't speculate on how big the performance uplift is going to be. There are too many things we simply don't know for me to make an educated guess.

You're confusing a bunch of stuff. I'll try to explain some terminology here. I'll have to simplify a lot, because some of these things are terribly complicated. A process is an operating system thing. It has nothing to do with your physical hardware. Your OS has to manage programs and their data, so they don't get mixed up. Think of taking a program, the data that belongs to it and stuffing them both in a box. This box is your process. Inside each box is at least one thread. Like processes, threads aren't a physical hardware thing. They, too, are provided by your OS for management reasons. You can think of a thread the way you'd think of a secretary. She takes the part of the program that needs to be executed, the data that belongs to it and hands it over to a worker. Threads, like secretaries, fill a managerial role; the actual work is done elsewhere. That elsewhere is a processor core. That's your worker in this analogy. Unlike processes and threads, cores are a hardware thing. They're a physical part of a processor. It's here that the actual work is done. Your OS can hire extra secretaries for your programs on-demand, but the number of workers is fixed (you'd need to upgrade your processor). Which worker a secretary turns to is usually handled automatically by your OS. It spreads them out intelligently so you get to make the most out of your workers. If you have more threads (secretaries) than cores (workers), they'll have to make queues. The cores then work through their queue one by one. They usually cycle through them, doing a bit of work for each of them. That way, no thread has to wait for too long. This is how you could run multiple programs at once back in the old days, where your CPU had only one core. So if you write a program that has multiple threads, it's automatically spread across cores by your OS. However, you only get a performance benefit from that if your CPU has multiple cores. Without multiple cores, it can only do one thing at a time.

The point of what was doing is that this post was posted just after I posted my post here. I heard that the A-10 would get a makeover, but I didn't know it was that high up their priorities list, so I figured I may as well use SD to do it myself. ¯\_(ツ)_/¯ That being said: Awesome! Can't wait!

It would certainly suck for people like myself, who got DCS with the A-10C only just now, but it wouldn't be too bad. That being said, I'm working on something you guys will probably like. I've got the original models and textures from DCS imported into Substance Designer and am giving them the PBR treatment. Here is a small before/after: No, it's not done yet and I don't know when it'll be ready. It's very much something I just mess with every now & then when I have some time to kill. And yes, I'm looking into reworking the cockpit, too. (And I think I'll make the cockpit a higher priority, because that's what you spend most of your time looking at.) If you're interested, I'm not creating new textures from scratch, but using SD to generate PBR maps with the information from the old texture maps. It gives you a great deal of control and is certainly more intuitive than using Photoshop or similar software for that purpose. However, you don't higher resolution or new details that weren't there before. All you get is a nicer and less uniform lighting response of the surfaces. Could make a tutorial, if there's interest and there are SD users here.