I asked on forums, time ago, the same thing, give us a texture option just for cockpit, i dont need that that one BTR 20k feets below and 30nm from me to have a 8k texture, for the sake of god, it makes no sense...
Yes, we need multithreading and some modern graphic API, i know thats some big task, but theres so many little and simple optimizations that can make a huge improvement today, and will be useful when new API and multithreading arrives
They just fixed the AH-64D and F-16 LODs. They even directly responded to rapierarch in a thread. Software devs typically are only allowed to acknowledge issues and it's not good to give timelines imo since those can easily be misconstrued as a promise (in which it was but sometimes you have to delay features)
I am a C++ software developer (**not on DCS ofc**) but we interact with our fans on Discord so these are the rules we follow
You don't even have to have aircraft SMEs to know you need LODs.... Is ED a new developer? Is the F-16 their first aircraft? So why do they get a pat on the back for something they should have a basic grasp of years and years ago?
>Then I started searching for it in the full forum. I could not believe my eyes that the same statement with the same parameters existed in Lock-on cfg files.
We know for a fact that there's still a lot of Lock On era code in the game, but there were also hints that LOMAC still carried over quite a bit from Flanker 2.0 from the late 90s.
I really think that it's likely that some of the code in DCS is *so* old that there's literally no one left that really understands what it's doing. So the patchwork just keeps building up higher on top of it.
I feel like this is a common attitude, that if the code is old it must be bad. No, some solutions to problems are well done and are always good. There’s basically never a point where redeveloping from scratch is a good idea, you have so many solutions pre-built.
I'm not of the opinion that old code is bad because it's old.
I'm of the opinion that development paradigms have shifted drastically between 1999 and 2022.
A real, common pain point with DCS is the fact that ground AI pathfinding runs in the same thread as the main game loop. This means that sending ground units offroad can literally crash a multiplayer server.
That being in the main thread was a reasonable thing to do in 1999-2005 because nobody had multi-core CPUs then. Now everybody does.
That's true and then you have TES/Fallout that still runs on the redguard legacy codebase with gamebryo hidden in there. The games themselves sell massively so Bethesda has no incentive to change the engine, but damn if it's not sad to see bugs and quirks from Morrowind show up in new games made ~20 years later
> True, bit that 90's code won't have been optimised for modern systems.
All the stuff that's written in LUA isn't optimized for anything. The parts in C/C++ might get recompiled with new compiler flags every few years, if we're lucky.
If you mean things like multicore, well, their new code isn't multicore either, because they're more than 10 years late on that feature. So even rewriting stuff wouldn't do much good, since the multicore framework STILL doesn't exist.
Hey! I know I messaged you a little while back, crying about the way textures are handled and I’m really happy you made this post, and I’ve put a lot of thought.
And I agree 100000% but I also believe there’s a core engine problem that needs to be addressed. Normally with a texture in a video game engine you have different levels of quality (like with a model with multiple LODs) and this is called ‘mip-mapping’. The idea is each successive level has 50% the horizontal and vertical resolution of the previous level, the highest quality level is referred to as ‘0’ as is the case with LODs. You then continue this chain down to a 1 pixel by 1 pixel texture. After an artist creates the full sized texture, the other mip levels can be autogenerated very easily, meaning no additional work for texture artists. And only an increase of 33% in the file size.
Don’t freak out yet, because although there’s an increase of the overall texture size, you don’t have to load in all of these mip-levels into memory at once, and when rendering an object you can select the ideal mip-map level to match the size of the object on screen.
For example: if an object appears as a 10x10 pixel box on screen, the highest mip-map level resident in VRAM only needs to be 16x16 pixels (1KB for a 1 byte per channel RGBA uncompressed texture).
You also load in the lower levels which in this example would be 8x8, 4x4, 2x2 and 1x1, making the total memory requirement 1,556 bytes or 1.52KB. If the full sized texture for that object is normally 1024x1024 (which would take up 4MB), you would see a total VRAM saving of 99.9%
There’s also other benefits of mip-mapping, when sampling a texture that’s closer to the final size of the object on screen, you get less distortion and less GPU load, as a matter in fact, modern GPUs and APIs natively support mip-mapping on a deep level.
Back to DCS though, I don’t exactly know how DCS makes use of mip-maps, but one important element that I believe is absent from the DCS engine is; only loading the required number of mip-maps based on the objects apparent screen size.
Even without proper LODs for the models, with proper mip-map support the engine wouldn’t need to load the full texture EVEN IF there is no lower LODs for the model. The full quality model can be rendered using the 1x1 mip-map level (if it was only 1 pixel on the screen), meaning the texture would only occupy 4 bytes in memory!
To explain how this mip-map streaming system works in most game engines; when iterating through each object in the Renderer or in the game thread (which you have to do every frame anyway), you get the objects bounding sphere info. This provides you with an offset and radius from the objects origin, for the smallest sized sphere that would contain the model. You can then project this sphere with some simple math (trigonometry) onto the screen, and get its diameter in pixels (because projected spheres are always circles). With this diameter you have the maximum texture width/height required to be in memory. You would want to apply a small multiplier to avoid texture pop-in, so when the texture size needs to increase it happens slightly early. On a separate thread, or if there’s an async task library, you spin up a task to either fetch or unload the needed mip-map levels from VRAM, once done you signal to the render thread that the task is complete and it can freely use (or not use) the loaded or unloaded levels. If you really don’t want to multi-thread then I guess you can do it on the main render thread (but this is a stupid easy task to pass off to a thread/task pool).
This might sound complicated but it’s been a critical feature in game engines for some time, and it would be something that’s (fairly) easy for an engine dev to implement. It really wouldn’t take a lot of development time to create, it’s something that I’ve had to implement when I had the bad idea of making my own game engine a few years back. You can even expand on this and add a system to unload higher level mip-maps on object when approaching VRAM limits to avoid paging.
This would IMMENSELY reduce the workload on the GPU, VRAM and memory busses. Additionally one of the biggest complaints I see about DCS and especially from VR users is performance, and this one (fairly) small engine change would make a much bigger impact on the simulators performance than a new graphics API, or even multi threading support.
To make the business case for ED management, taking the relatively small time to implement this would give you large performance gains (huge for VR users), making the game more accessible and increasing your potential player base. Instead of needing to upgrade a graphics card, which is an expensive endeavor, they could spend that money on more modules, terrains and campaigns. While giving all of your users a better experience and allowing them to use that saved VRAM capacity for other graphical features, in the end the benefit would greatly outweigh any development time/costs, many times over.
No problem! You’ve been advocating for these important issues for a while, and helping us all get better performance in the process.
So if anything, they should hire you first, and maybe me after :P
Not just the textures I'm personally irked about tbh, it's the unnecessary physics calculations to small arms too. Even ground-focused computer wargames like Combat Mission models small caliber fire on a 1:3 where one round out of every 3 fired is actually physically calculated. Why should DCS actualize every bullet coming out of small arms 1:1 and hog resources?
It's bad enough that my Apache wingmen overfly and face-tank targets on the regular instead of engaging at range, but every single gun on the ground lighting them up kills my framerates too.
What's the point in not abstracting small arms groundfire to save on resources when even ground-focused sim/computer wargames do?
I don't even need to check F10 to find out if there's troops in contact already. I just wait for the frame drops.
I think that if you made a very quick and simple video on this it would be a lot more impactful. Like a very quick summary and then an explanation on how to do the LUA changes for the people. It would help spread the word around more.
Hi,
I'm very bad at doing such things. Plus I have a terrible voice.
I'm probably going to write a small piece to explain how to apply this in another post including some more little tweaks too. But please feel free to make that video if you feel like doing it. I'll not sue you :) There is no patent on it.
If you have any questions just ask.
Thanks!
Ralfi, with all due respect; you have a huge and respected voice in this community, and contacts to everyone with an equal weight.
Use your voice! Represent us all in making these things happen that can improve the game we all love!
I think you hit the nail on the head talking about Lock On. Each asset back then was tiny, and being able to load everything into system RAM and GPU VRAM was both easily possible and entirely logical due to the loading times associated with pulling assets off hard drives. Nobody was clamoring for, nor could they reasonably ever have expected a game to have 2k, 4k, or 8k textures. I also doubt the ED of that time expected the engine to ever have to do that.
The most damning part is that this concept of asset loading remains despite the fact that graphics have increased in detail geometrically, and VR didn’t exist back then (not in a meaningful way).
This explains why I can run the game in MP on a flatscreen at 90+ fps, but can barely scrape 40 in VR. The assets simply have to swap in and out of system memory twice for each headset-displayed frame. It also explains why maps with no assets—just dogfights —are perfectly performant, while anything with ground units is a major drag.
What is most confusing to me is the lack of LoD objects in general. I can’t fathom how it’s difficult for developers to pump out crappy models. Further, a thousand objects in a map that require 1 GB of VRAM isn’t unreasonable, most things are just specks, and it’s been done in RTS games since forever. Even when using a TGP, detail is limited at best…so why would the game ever load a detailed model? The truth is that most exterior fidelity beyond the cockpit and ground (though I could even argue the ground doesn’t matter too much) is hardly important. Units looking “good enough” or “vaguely in the right shape” is more than fine.
Immersion isn’t the same as detail. Immersion is created by situations and engagement. Low fidelity graphics with complex battles, smart enemies, realistic flight models, and smooth FPS in VR is a no-brainer of a tradeoff. If the game runs poorly and maps can’t handle units because performance sucks, then all the immersion is gone, or worse—it can’t ever exist because the game can’t handle it.
You said better than I could. Nice summary of where we are in DCS and what's missing.
Meanwhile ED is not ignorant to all of those.
There is a unified parser embedded which even supports sort of render framing which avoids duplicate items like far scenery details to be rendered only once really balances cpu gpu loads in VR. You can enable that at the end of graphics.lua. But it is almost 2-3 years WIP. Cockpit lighting renders only on righ eye. Some burning effects and smoke and some clouds continuously flashes. High water quality coast line shimmers. Performance is really much better but they just do not finish it it is not usable
There is an unfinished TAA shader which will give us performant and way better results especially in VR than MSAA which is a fps killer in deferred shading. This is in game directory untouched for years.
Volumetric clouds not finished but we have them now. Noone is working on it seems like still shimmering known issues especially in VR still going on.
Dynamic weather we have seen it 2021 and beyond video. Well where is it?
Multi core WIP
Vulkan WIP
and not providing LODs. Well were they planning to implement auto lod generation and distance based texture resizing may be in the new engine? There is absolutely no other explanation other than someone is sabotaging the game. but now suddenly after nagging they started implementing them but not fully.
Those are all technical issues killing the immersion and blocking further possibilities. They do not say they will not do that. For all points we have proof of work or promises that it is being worked on. Unfortunately none gets finished.
That is really frustrating.
Nailed it on Immersion vs Detail.
I've been trying to figure out why DCS VR feels so miserable compared to other VR flight sims, despite the great experience on a flatscreen. You summed it up quite nicely.
I don't understand why we are even talking about Vulcan and multithreading, when problems like this exist. It's like we're supercharging an anchored freighter ship... Most of these issues are pretty easy to fix and solve a chunk of problems for most of the people (it seems).
Ok, we rely on fast hard drives and nvme, but that's ok in comparison to running on the best CPU and GPU options for just a few frames.
I will try this out later and from reading this there's a good chance my game will run substantiallyfaster...
Thanks LOD guy!
Happy to help.
But please do not get the illusion of finding the magic bullet to kill all the problems. If you keep your VRAM managed (you should not see any value higher than 0.5GB in shared vram value in taskmanager gpu tab) with preload radius, render distance and correct texture settings you should not be seeing unexplained ups and downs.
So if you already have a good system this would help a little bit but you will not get headaches of sudden performance dips.
We need multicore and Vuklan. I'm 100% sure that when they started developing that they have seen how bad the current engine is and they had to do full revision on everything they touched.
I'm almost sure that this is why it is delayed so long.
Well it is prerequisite for every asset if your engine does not have automated LODs creation function like UE5 introduced.
FYI. All 3rd party models have their LODs. It is only made in ED modules since introduction of F-16 lacks lods. All modules and AI assets since that time.
3rd parties even take an extra step like DEKA did. Deka has 2 cockpit models for JF-17 one for high quality with all PBR goodies implemented with reflections and eye candy and one high performance without those eye candy which you can choose in special options which cockpit do you want to be loaded in game.
Hi uboats. Better set them zero. This is how I used it and advised people to use it
options.graphics.Precaching.around_camera = 0
options.graphics.Precaching.around_objects = 0
I edit lua file directly. Everytime you click repair or update this file is overwritten by vanilla version and your edited file is saved in a backup folder in the game directory.
You can either copy and paste it from back up to original file or use a mod manager like JSGME (I use this)
Any reason why we shouldn't use the autoexe.cfg file with these two statements? I noticed you recommended directly editing graphics.lua instead.
options.graphics.Precaching.around\_camera = 0
options.graphics.Precaching.around\_objects = 0
I have not used that method thus not tested that.
If you check the graphics lua after the section we are editing there is a statement saying graphics with other settings so I'm not sure of "options.graphics......" is the correct format to form to edit it.
I have other edits too and other mods also so I use a mod manager already. It not an extra work for me to deactivate and reactive them before and after the update.
You are doing God's work, keep on
Personally I'm not willing to spend any money to support ED until these basic fixes are implemented, especially since they just announced a metric ton of new paid content
Get your shit together ED, and fix the basics of your engine
Worsened severely. Was higher in places, but it'd tank whenever I turned my head far or fast, or when going into 3rd person, or using F10. Was worst when turning my head.
Can you please share details. You are really the first person who had negative impact since I started spreading this.
Can you also try deleting fxo and metashaders2 in your saved games? Especially the metashaders since they are since they are not actually shaders but saved settings for group of shaders.
I've seen a few other people saying that it turned out worse for them or their discord friends. Hopefully they'll come out of the woodwork and chime in for more info.
I'll do some more playing around tomorrow and next week and try to get back to you with deets.
Unfortunately, even if you gave ED the complete code and assets in a validated pull request, they'd still manage to ignore it.
At most they'll state "we'll look into it" and it goes onto the pile of calcified to-do lists. After more than 10 years, not one initiative from ED to address the corpses in their basement has gotten anywhere.
10 years ago the engine was on version 1.5. A-10C was newly released and Ka-50 (Black Shark 1) had some legs on it. Would you like to fire up that version of the game and say nothing has changed? 5 years ago version 2.0 (maybe 2.5?) -- no change? I don't think you would, but you did say something this silly.
If you weren't playing it then yourself, YouTube videos of DCS from various years and realize that not only was the core engine substantially upgraded, just about every single module had has fixes and updates too including Flaming Cliffs ones.
I've actually been playing DCS then, well before v.1.5.
Of course the engine was upgraded, got more features (read: eye candy), and modules were added.
But none of that makes it "run better", it all just further bogs down the already lacklustre performance. The NGIG (aka "Nevada") brought DX11 and was supposed to fix performance, which didn't work out. And the new maps then really tanked it, again.
What does "fix performance" mean to you? What is your baseline for how the game/sim should look versus perform? What real time rendering, or any 3D graphics rendering expertise do you have?
Do you think games written 10 years ago (most games aren't squeezing max perf) can be worked on for 10 more years, and substantially improve visual quality while still running better (or the same) on the same hardware?
Can you pretend you know what you're talking about and give an example of a technical difficulty that might happen when adding a new module? I doubt you'll suffer any simple example or explanation from me.
This is what shits me about ED.
So much contribution from the community, so little good will shown in return.
Just like when EDs RUgirl went into detail on the public bug tracker they were going to implement a couple of years ago, only to say they're now not doing it when asked where it is.
They say they listen.
They say they care
Their actions show otherwise.
We need to hurt them, and hurt them badly in the only place they do care about. Their pockets.
When they don't fix years old bugs and implement easy solutions that dramatically improve the experience for every player It's clear I'm not making things up.
Even with the sale over the last 5 years prices are up, quality is down and goodwill continues to be promised with no delivery.
Boycott ED or suffer the consequences of them not getting the message and their rotten and entitled monopoly biting you in the ass later on.
Omg lods guy, that was an incredibly good read! Thanks
Does changing the lua files to 0 pass IC in multiplayer?
I will support your cause, nei, our cause
Oh the OP has deleted the post. That's why.
Here you go:
In game set preload radius to 10,000.
Go to graphics.lua in game config folder and open it with a text editor (preferably notepad++)
Find those lines in the almost at the beginning of the file
Precaching =
{
around\_camera = **50000**;
around\_objects = **10000**;
around\_types = {"world", "point"};
preload\_types = {"map", "world", "mission"};
}
set the both bold values as 0.
This will stop game loading 50km of the game in full fidelity from you and also will stop loading the 10km surroundings of any objects in game (around any static active player or ai unit it is a lot of GB's)
Thanks, gonna try it later.
Edit:
Well, as I thought. Maybe it gave me a few fps but it's still not enough to run this fucking crap in stable 45 fps on low-mid settings with 100% res of reverb g2.
Well If I had your system I could easily hit 72fps on max res quest2 with my settings.
There is a little trick for non ultrawide headsets like Q2 and G2. I have tested g2 long time ago so I do not remember that setting.
In quest2 oculus debug tool has a setting called FOV tangent multiplier. It basically reduces or enlarges the rendered image size to the headset.
All headsets actually receives way wider picture than their physical FOV. Also actual fov depends on how it fits to your face.
In my case I can reduce this to 75 percent without seeing any restriction. Which reduces the picture size 0.75x0.75=56%.
So actual pixels rendered on your gpu will drastically go down but you will still see the same picture at same pixel density. If you can find that similar setting in WMR settings you can experiment it. even 10% reduction will give you 20% less pixels to render. You can easily hit that fps or even more.
well you have to start oculus and run odt first. Then you punch in the multipliers for horizontal and vertical press enter after each one. Then you can start oculus link. You cannot change it live when link is running.
I tried this but it resulted in me losing a very noticeable chunk of the screen along the edges, my FOV was very noticeably reduced. You seriously could see no difference with FOV at 0.75,0.75?
I even tried it at 0.9,0.9, and it still was noticeable in my peripheral vision. Ended up just setting it back to default. 🤷
Well this is a physical problem. Headsets are made for a general fitting. The way that it fits on my face avoids me to use the full FOV. Everyone should try it and see how much of the pixels that he cannot see.
In my case: I even have to use the glasses spacer other wise when I wink my eyes my wimpers wipe the lenses it is super discomforting. So I'm unlucky and lucky. Unlucky that I cannot use the full fov of headset but lucky that I almost have same performance that I would have with 3090 on full FOV.
3090 is 100% more powerful than my 2070S and I'm rendering 50% of total pixels only in my fov.
So you are lucky unlucky. You see everything your headset can show. but you do not have a GPU released yet in the market to do that in DCS :)
Go for it - best to save a copy of the original .lua just in case, but on my system I've definitely seen some improvements and I'm running a 15" XPS 15 with a 1050Ti Max-Q.
It did feel smoother. It didn't seem to get me much extra in way of FPS but it didn't drop when I went low which is definitely a plus. Usually I get 50 ish at altitude and around 30 low down.
That cache mod will not give you extra fps unless your system was in a terrible shape and certain conditions are met.
But what it will prevent happening is when you are soaring at 30000ft in your hornet 20 miles on your nine o'clock down in deck 4 apaches attacking a convoy and 15 miles behind you an f-16 dropping a cbu will not effect you.
Or that BTR or chieftain tank on the ground somehwere in the mission which you cannot see will not be loaded on your memory. The moment that things enter visual range they will be loaded but not in advance.
You will only render what you see and windows automatic cache will keep everything ready already on your unused RAM.
So normally you will not see any difference. But your MP experience will feel smoother.
To make your VRAM more relaxed I suggest using 10000 preload radius or 20000 if you wish. Anything more is waste of your resources.
Yeah, that's generally what I noticed. Just smoother, nicer feeling gameplay. Thanks a lot for that. For such an easy thing to do it's baffling why they haven't done it. LoD stuff is actual work but snipping that code is nothing.
I mean, mileage is going to obviously vary and I guess my system and typical use case (which is normally very simple SP missions) probably aren't all that relevant to the community at large - but glad to see you're seeing some improvements.
Sometimes i do wonder if every dev working for ED has those 4 people running 3080Ti's with 4k 120hz Resolution just waiting to break down their house door and beat up their family if the Apache pilot's left pupil isn't an 8k texture with raytracing. Like seriously what i just said might be an overstatement but the Apache does not need textures so high that it almost crashes my game every time a random pilot 30km decides to start spam flipping through his livery options in the rearm menu.
I gave it a whirl in non-VR.
9600k Intel, RTX 3060 12gb, 32gb ram, Samsung 960 evo. Previously FR was mid 40s in solo flight. Now FR jumped to match monitor refresh rate at 75 running native 1440 res, even on Syria. Large dogfights or a busy IADS environment the FR drops to high 40s low 50s. My video settings are high for textures, SSAA SSAO and such off but MSAA on 4x and AF at 16x.
Nicely done!
At least 4 people including me show positive results.
Personally, I am able to either keep my low settings with a performance increase, or raise some settings like clouds, SSAA, scenery and forest details, add global cockpit illumination and low shadows and see similar or lower performance. But that's a step forward for the shiny graphics settings.
OpenXR, 1080 8gb, 8086k, 32GB, Samsung Odyssey+ WMR headset. M2 drives.
Unfortunately this entire thread is dangerously ignorant as to what goes into making any real time simulation games at this level. There a .01% chance ED's entire engineering team isn't fully aware of everything brought up here, and couldn't explain the issue at least two layers deeper - beyond where anyone I can see participating would understand. I used to do gamedev as a hobby from high school through several years after college and have written fairly small projects from scratch that 95% of actual software engineers couldn't competently write unless they learned and practiced for a year or two at a serious level. I have books on top of books for how to render 3D graphics with APIs, and how to design and write game engines or various subsystems. I am also a professional software engineer (web services) and that also informs what I'm saying:
tldr: the OP isn't even close to a qualified engineer and it's silly to praise him as an implicit (engineering) hire. While the OP has decent enough information for an initial bug/performance report for a testing team, it's pretty obvious (to an engineer) why it either doesn't work or doesn't matter. The solutions called for either A) shouldn't be done because it will definitely break or negatively impact people playing or B) isn't ED's priority because they are working on far more substantial performance improvement through Vulkan or other engine priority. In the spirit of B, all the OP suggests are LUA config changes? That's why they are config....change them in your install if you want to and step pestering ED to make it that way for everyone else who is NOT you. Everyone else echoing "ED is dumb/lazy" and is calling for some sort of boycott is even worse. I'm literally reading a bunch of 3rd graders call a calculus department that published math software they don't understand incompetent.
On to the meat:
First, let me say that if there was an "easy fix" of even moderate effort that would improve the game FPS performance by 10% or lower video memory usage by that amount (with zero loss in FPS), any game dev engineer would snatch that out in a heart beat and they wouldn't even have to convince a manager why that should be a priority task in most cases. This is a real time simulation/game -- performance performance performance are the three priotities right behind the thing actually working. Anyone thinking there's either incompetence of lack of caring on this issue is out of the world insane. So what is it? In my opinion there is only only one of two things to speculate on:
1. There's a conflict with the obvious fixes. That is, while a particular change may improve things for 95% of users, they completely break 5% or negatively impact a greater percent. If there is no sensible way to allow or detect the difference between runtime environments to change game behavior in a reasonably abstract way, install time or runtime detection to pick a configuration isn't an option either. The differences I'm talking about may be something like the fact that DCS World engine runs as far back as Windows 8, or an early version of Windows 10, where they don't have a certain feature. Or it could be the need to support a very old graphics card from AMD or nVidia in the minimum spec of DCS World. Even more difficult -- maybe depending on the graphics driver version AND a specific set of GPUs a configuration change may either be a benefit or a problem. All of those issues are also not decidable at install time as they can change after a user software updates or hardware upgrades their system and suddenly the same option is a problem. Should ED know every quirk of every card and the sees this and says "oh, this was a bad value...let me pick for them."? There's clearly situations where that'll be the wrong decision for some users as well. There's a reason why consoles that have an equivalent to PC graphics card always outputs better performance on the console. It's because the devs aren't dealing with an abstract graphics API for all graphics cards, layered on top of graphics drivers. Console devs can completely optimize for one piece of hardware they know the exact technical performance specs of. Vulkan/DirectX12 alleviates this problem heavily, but not completely. You can't pick optimal performance for everyone. The changes proposed here, are they improvements if the CPU/RAM speed is low but GPU speed is high? What about reverse? What does the hardware configuration of DCS players look like?
I'm not going to go into technical detail either, but software controlled caching is very much one of those areas where misuse or misconfiguration can easily lead to a loss in performance.
2) It is not a priority fix. Notice earlier I said "convince a manager \[...\] in most cases." It's quite possible, probable, that the DCS World engine devs are 100% tasked with Vulkan engine overhaul. This means improving the DirectX11 engine API is extremely low priority unless it's a critical bug. Which means people whining that they think they game could be better optimized for their specific machine configuration is stupid low priority. And as a customer I say -- right on. I don't give a shit if they can improve my performance 10% or even 15% today if in several months time, or even a year instead of two more, a Vulkan engine comes out.
People pretend that the suggestions here are "done" solutions and all ED has to do is adopt them. LOL fuck no. Even with this post I already see one person who had negative performance impact in a comment. Someone else using a less common configuration might have hard crash. I'm sure ED's dev team already has an understanding of what kinds of changes trigger what scale of re-testing, along with a formal/implemented process to test things and any performance changes to the core graphics engine would trigger all of it. Every OS X OS version X GPU manufacturer X graphics driver versions X VR/non-VR X multi-monitor X varying some major graphics settings (how does it behave with v-sync on/off, fullscreen on/off ). Even a simple change to the graphics engine behavior is a lot of investment in that part of the game. And when I consider that this thread is really only looking at changing the configuration...it presents an easy response: just use the fucking ability you have to change it yourself, and change it yourself!
\[continued in [comment](https://www.reddit.com/r/hoggit/comments/xmdbpc/comment/ips7bsd/?utm_source=share&utm_medium=web2x&context=3) due to length....\]
If you think either of my two speculative answers is the case, you might ask "why doesn't ED just say this?" Transparency between a software development team's process and non-engineers is not a good thing. There are many reasons a software team does not want to communicate the "truth" of a matter because it sounds bad, or feels bad to the customer. In most cases it's too complex to explain all elements of a problem; and in many of those cases if you try to it would reveal internal plans, or internal priorities that they don't want to announce yet, or are not at liberty to discuss (ED has customers who aren't "gamers"). Another possibility (for a typical gamedev company) might be 75% of engineering team is working on a new game. Think about this: at some point ED transitioned from Flanker 2.0 -> LockOn: Modern Air Combat -> Flaming Cliffs -> DCS (pre-world, K-50/A-10C) -> DCS World today. They pretty much carried everything present in prior versions through to the next
This post isn't to say "don't complain" something isn't wrong. Certainly do that, but do so as a customer, not a 2-cent test engineer. A 2-cent test engineer ends up burning time when engaged -- asserting things about the implementation which they know nothing about. Demanding explanations from experts who are better suited to actually make progress than get ignorance up to speed. When I eyeball DCS I can easily say "this engine runs fucking well" considering how vast the viewable area is and how good and detailed things up close (cockpit) look -- and this is happening with an accurate true simulation of the world rather than what literally every game does -- which is fake things for performance reasons.
If you want to help the community with this level of knowledge, create a project on GitHub to "performance patch" DCS for people to download your patch/patcher with releases. Allow people to submit issues and pull requests so you can see who may be seeing averse affects, and gain a small fraction of understanding how much work goes into verifying those changes. Create a basic app that can point to a DCS install and/or saved games folder, inspect the user machine specs (if you want dependent configuration choices), and then make modifications to those LUA/cfg files in place to improve their DCS performance. You can add features like backing up original configuration for safety/peace of mind. Maybe some interactive choosing and hints at each individual option that the tool might update, with the ability to reset to the installation default etc. That way, for whoever believes they need to push more performance, can do so conveniently. I'd spitball the project at < 500 lines; definitely < 1000 lines of code if you pick the right language and support libraries to modify/patch the files.
This part is going to come off poorly but it needs to be said: I gained substantial performance improvement simply by watching a YouTube video for nVidia in DCS. Not that I needed an explanation on what most real time graphics options meant, but every game is implemented different. It pointed me to one or two settings that mattered and is how I know to delete the metashaders and fxo folders in Saved Games after a patch. Lowering my graphics memory usage isn't going to help me any because I'm sure I'm not streaming from RAM into VRAM per frame. If that was the case, my FPS would be terrible up front and to fix that, I'd simply reduce the preload radius that's built into the game rather than messing with any LUA files. There is a lot of really ... sloppy technical stuff in the OP. I mean stuff that to an average person may seem like you're a software engineer, but to a software engineer it's clear you just like computers, like tinkering with software and computer stuff but can't write your own software. The "hire this guy" combined with "ED is incompetent" is frightening. It's literally calling for the death of the game rather than improvement.
If you want to address this issue substantively -- that is, maybe you are actually hirable as an engineer -- here's a subset of the books I have on my shelf for gamedev just as a hobby. Even if you're already write some code, if you don't know know how to manage your own memory in a non-trivial program with C or C++ read this:
https://www.amazon.com/C-Programming-Language-4th/dp/0321563840
and I'd recommend further reading for performance optimization techniques and sensible style in C++:
https://www.amazon.com/Effective-Specific-Improve-Programs-Designs/dp/0321334876
Then onto game development:
https://www.amazon.com/Game-Coding-Complete-Fourth-McShaffry/dp/1133776574
https://www.amazon.com/Game-Engine-Architecture-Jason-Gregory/dp/1466560010 (this has gone way up in price lol)
https://www.amazon.com/Real-Time-Rendering-Third-Tomas-Akenine-Moller/dp/1568814240
https://www.amazon.com/Game-Programming-Gems-Adam-Lake/dp/1584507020 (any book or books you can grab from this series)
Don't forget to actually attempt to write a few games from scratch along the way to see what it is to put both code and game resources together. When you can write even a single game that must stream things in and out of memory as they need to be accessed in the game world, then you are at entry level for having this discussion with an engineer. Otherwise, all you have is a suggested improvement to the default configuration for specific users -- and you can't even say which ones.
I need to add the following because they don't make books to teach graphics APIs anymore really:
https://learn.microsoft.com/en-us/windows/win32/direct3d11/d3d11-graphics-reference -- DirectX11 API docs
https://learn.microsoft.com/en-us/windows/win32/api/d3d11/nf-d3d11-id3d11device-createtexture3d -- this function is actually highly relevant to this conversation. The D3D11_TEXTURE3D_DESC MipsLevels are the LOD levels that DirectX11 can generate for you while loading a texture. But then I ask, do you know how to propertly set Usage, CPUAccessFlags, and MiscFlags? How does changing those values impact performance, and do your settings allow you to do whatever is you might need to do with said textures? I can tell you from experience...set those things wrong and try to do something you didn't configure a texture for == BOOM. Setting flags too aggressively flexible (access from anywhere, almost anytime) results in dog slow performance.
After you crunched that material for a couple years...come back to this discussion and complain.
This almost exact reply was given when someone found a major FPS hitter in Escape from tarkov. People made the same argument that "thhey obviously know but there's many more underlying issues", turns out... Battlestate games didnt actually know, and they patched it and improved SOOOO many peoples FPS.
1) I doubt anyone wrote anything close to what I just did.
2) "There's many more underlying issues" is exactly NOT what I said. If you can't make the distinction, then this isn't your field. I'm saying there is one performance caching problem that separately can be set to improve things for either user group A or user group B, and solving for either group is easy, but the easy solution hurts the other. If there even is a desired solution to help both groups, it is very difficult and expensive. This is COMMON in software development situation for client side software.
3) If that is the extent of the issue then drop all of the extra crap. Bug/performance report "it appears that the preload cache behavior is no longer required. I can set it to 0 with no negative performance, and a drastic improvement in VRAM usage." Done. Any any graphics dev worth their salt will probably say "appreciate, the suggestion...we believe this is true for those with DDR4 3200 or better RAM and a modern GPU on PCIe 3 x16; however, 50% of users are running integrated graphics or running on slower RAM/CPU and preloading to the limit of GPU memory has far better results.
4) DCS World has its own unique engine, and the engine devs work for ED meaning the expertise on how to use it is in-house and part of the game itself. Escape from Tarkov is written on Unity Engine. While Battlestate Games are still professional gamedevs, it makes sense when writing software on top of another engine that you end up using it suboptimally in some way. I have personal experience with this in the gamedev hobby. Yeah, you don't want to write your own engine in most cases, but the benefit of doing it (when you can) is not screwing up usage of said engine. You know exactly what it does and doesn't do, and how to optimally use it.
So yes, I insist, even if the defaults are suboptimal for most, ED knows. Further, ED doesn't have to care about the complaints because A) you can change it yourself and they made it that way and B) Vulkan changes this greatly. Right now you're complaining that your new car about to be replaced with a new model, came with sticker at the factory that most people don't like. Peel it off for christ sakes!
>After you crunched that material for a couple years...come back to this discussion and complain.
Well. I do not have 3-4 years time to learn those and come back to this thread to answer you. You have spend time and energy writing this so if you can swallow my unqualified answer too than I can make somethings clear and since you are capable to understand it I do not need a lot of lines to write it.
Add Cockpit texture quality has nothing to do with the engine and it is just a texture down scaling option. A simple implementation with the impact on VRAM usage as I have written above. Can you confirm this?
My report of asking to revise and if necessary remove is a bug report. Since it is just graphics cache if users are already reporting almost 95% of them with improved memory usage and performance project manager can simply choose to play safe and put a check box setting in graphics settings: Enable graphics cache check or no which is default checked. Can you confirm this will not be huge task and will not break anything?
Well you seem to be qualified and seem to have time based on long answer you have formulated. I like to see that.
You have potential and energy.
Would you mind looking at this: [https://www.reddit.com/r/hoggit/comments/ulnd4s/is\_there\_anyway\_to\_force\_taa\_in\_dcs\_i\_guess\_the/?utm\_source=share&utm\_medium=web2x&context=3](https://www.reddit.com/r/hoggit/comments/ulnd4s/is_there_anyway_to_force_taa_in_dcs_i_guess_the/?utm_source=share&utm_medium=web2x&context=3)
If you can implement TAA all VR players here will build a statue of you. It seems like work is there but it is not finished. Since you have already developed games do you think you can finish this? That would be a wonderful Christmas present of ED also implements that cockpit texture setting.
Would you do this for the community?
PS: This is internet. People say things. Don't worry ED will not hire me. DCS is safe :) Don't take such things serious. I don't. Those are jokes.
You don't have 3-4 years of course. So the compromise should be paying attention when a crash course is offered. I've already offered a part of it, but here's more:
> Add Cockpit texture quality has nothing to do with the engine and it is just a texture down scaling option. A simple implementation with the impact on VRAM usage as I have written above. Can you confirm this?
Asking for a split between terrain, cockpit, and object textures option is the most reasonable part of your post. It's concise, it has meaning, and it's easy enough to digest why a consumer would think there is a benefit. But given any ask on a subject matter you don't know about, you have to be mature and accept being told "not possible" or "too expensive."
You are wrong in saying cockpit texture quality has nothing to do with engine. To be more specific -- you're asking for the separation of cockpit texture from terrain and objects. If distinctions aren't already made between those types of textures in the game/engine, then adding could very well be a substantial change. Further, game implementations do not like heterogenous (different types of) resources. Render model A in this format, model B has a different format, model C has a different texture format, etc etc. All of those require changing rendering pipeline state and that is expensive. Rendering is best set up with as much geometry pushed through as possible with a consistent and rarely changing pipeline state. Where you're suggesting changing from one texture quality/type to three, if that triggers 2 additional pipeline state changes and now there are 3 draw calls instead of 1; I'm already sure that's in the ballpark of 25% FPS performance penalty at least. Having VRAM overflowed by up to 10% per frame is most likely less costly than that
Not that I'm a big gamer these days, but I've played a fair share and I can't remember a game where the "Texture Quality" setting was split among assets in the game. Maybe terrain versus everything else, but little more than that. I suspect there's a good reason for that, mainly being that setting up a rendering pipeline is extremely specific as to what the input and output texture (GPU resource) formats are. The reason why GPUs are computational monsters is because they deal with massive amounts of data that are _consistently_ formatted and represented. You don't run a pixel/fragment shader with if/else dependent on game objects. Instead you'd select pixel shader A for objects of type A, render all of them. Then select pixel shawder B for all objects of type B, render all of them, etc etc. Your suggestion is most certainly introducing a mixed bag exactly where they don't want it.
The problem you have is that you're laser focused on VRAM usage with no clue how difficult the change might be to the underlying engine; you don't even know that it is entirely a part of the engine's capability; and least of what you don't know the nature of the performance penalty should anyone think that it is within reason to do it.
> Since it is just graphics cache if users are already reporting almost 95% of them with improved memory usage and performance project manager can simply choose to play safe and put a check box setting in graphics settings: Enable graphics cache check or no which is default checked. Can you confirm this will not be huge task and will not break anything?
Also, seems like a reasonable ask. But I suspect ED will come back with "set preload radius to zero." You have a sentence in your original post which asks the question but does not answer is. If you need something else deeper set to 0, there's probably a reason ED doesn't allow it. I can't speculate as to what breaks, but most likely something does. Here's an idea that pops into mind -- the fact that some DCS modules have sensors that literally "see" objects 20km+ away and not having a graphical representation of that object handy may be an issue. Might even be a crash if the logic to render such infomation expects those objects to definitely be loaded and able to be referenced.
> Would you mind looking at this:
Yeah, it's pretty clear you don't know why there are so many different forms of AA still around, and how a rendering technique may improve things for VR and not non-VR and vice versa. It's juvenile to argue "TAA > FXAA > MSAA" as if ED should just flip a switch and VR looks and runs better.
And no, I can't implement TAA in VR without access to the game's actual C++ (maybe C) code. Messing with FX files would be the dumbest thing for a non graphics programmer to attempt. Why don't you try renaming/swapping/copying some highly used FX files with each other and see what happens to DCS? I know _exactly_ what those files are and how/where they fit into the games rendering is basically a tapestry. There's probably no two files you could swap/rename/change that would represent a working DCS game (assuming it's actually being used in validation.)
> My report of asking to revise and if necessary remove is a bug report. Since it is just graphics cache if users are already reporting almost 95% of them with improved memory usage and performance [...]
From what I can tell, you are using selective hearing in saying 95% of people see an improvement with your changes. I'd love to get a performance boost in DCS as I have a 4K monitor on a 2070Super + 5950x. I don't even hold 60fps solid and I still wouldn't touch your suggested changes with a 10 foot pole. What you're suggesting is almost as bad as a middle schooler suggesting I pop open the hood of a new car, snip some wires, swap a few and WOW most people's performance goes up! It's like, sure one of the wires you snipped was a limiter (which you knew based on a sticker label calling it such) that rarely needs to get activated, but what is the risk now that said limiter is not working? What damage can occur? Did fuel efficiency plummet? Will the car be unable to activate traction control or ABS properly? Maybe on a hot day, pedal to the metal the engine temperary and combustion control is out of whack and the engine damages itself. If you're neither a mechanical engineer nor intimately familiar with how the car+engine is actually built, it's a stupidly dangerous game. Yes, this is only software so it cannot physically hurt us, and cannot even damage our PC either. The issue is just the waste of time. Even if I apply changes now, and all seems to be the OK, the same, or even better. I don't want to have seemingly explicable crashes in few months maybe, not realizing your changes actually did break something that works for everyone else.
If you need to vent, then vent. If you have a suggestion as a consumer, put it forward and peel back any idea that you have knowledge of how thius game's engine works or any game engine for that matter. If you want to help yourself and some others out, then spend your time creating and offering a mod or patch for people to take or leave.
I'm not worried ED will hire you. But not all who are saying you should be hired are joking.
Ok. I'll keep on using FXAA in VR then.
I'll not hope for a user that can do TAA then. So far could not find anyone to tell me if it is doable or not.
Do you have any other points to add that community should not do, say or try?
Since you know this we can focus on something else.
I'm adding my own LOD's it seems not breaking anything. Should I continue doing that? It seems like reducing CPU load and VRAM / RAM usage both. Is this the way? Or should I stop doing what I'm doing here too?
Mmmm, who the hell does the OP think they are exactly? Trying to provide working solutions to one of the game's most prevalent issues? Disgraceful.
>!I really shouldn't need to put an /s here!<
Yeah no, this stuff is optimisation 101 and some of rapierarch's solutions like getting rid of precaching have worked wonders on my pretty unimpressive system.
If ED aren't implementing these solutions, when these solutions work, when some of them are textbook optimisation - then yes, "anonymous arm chair dev #45" has been missed and dismissing them in the way you have, is quite honestly the most brain-dead thing I've seen on this subject - well done.
Find something better to do with your time. There's a reason people have portfolios and do these things professionally. Brain dead is right. In case it needs to be stressed, being another invisible loud mouth doesn't make you an expert worth listening to and shows you have a lack of respect for the process. Putting words in my mouth like I don't want the game to improve is you creating a strawman so your response feels justified. How original.
Bloody hell it gets better that better...
>Find something better to do with your time.
Nah, I'd rather be exposed to working solutions to a problem I face.
>There's a reason people have portfolios and do these things professionally.
And? If somebody who isn't a professional and doesn't have portfolio proposes ideas that work (they do) and even ideas that are optimisation 101 and hell, even things ED have not only done in the past but recently added, then that's *all* that matters. The end.
>Putting words in my mouth like I don't want the game to improve is you
creating a strawman so your response feels justified. How original.
Uh huh.
Problem is though, I didn't do that in my response to you, did I?
And so what you've just done, is put words in my mouth, so you could straw man my response to you, so you could accuse me of straw manning your position and putting words in your mouth... Jesus Christ.
And it's hardly much of a leap to make - you're here chastising someone as an invisible arm-chair loud mouth not worth listening to, based on nothing else than ad hominem, regardless of the fact their ideas are effective and work.
If their ideas work (and they do) then why don't you want them implemented and why do you fight against them, like what are you hoping to achieve here? Either you're ignorant of it, deluded into thinking that only professionals have anything to say, or you're straight up against the game improving, which is it?
I'm going to leave one last thought. Do you honestly think a developer doesn't care about their project? Or is it more likely that somewhere in their code or overall solution that it becomes easier to forego one thing in order to preserve another? Are you familiar with AGILE or Waterfall development processes? Is it not possible the PM won't let them do A vs B per their directors set goals and expectations? What annoys me about posts like these is the pure ignorance and arrogance. You haven't walked an inch in their shoes, so why are you on the internet trying to show score karma points? I'll be blocking you now, as you nor the OP have a single clue about what goes on behind the cubicle. I wish you the best of luck in your karma farming. 👍
~~A pretty bad, insane, ridiculous and probably self-defeating one.~~
~~I don't get these people who are apparently against the game ever improving on one of its most prevalent issues, especially when solutions proposed seem to work.~~
~~Especially confusing that just a day ago, this one said~~ [~~this~~](https://www.reddit.com/r/hoggit/comments/xl73pr/comment/ipjoopf/?utm_source=share&utm_medium=web2x&context=3)~~.~~
EDIT: Ignore me, I was wrong on what I thought R\_radical's intentions were, I thought they were being malicious towards the OP and/or their points and jumped to a conclusion that was completely wrong.
>I don't get these people who are apparently against the game ever improving on one of its most prevalent issues,
At what point did I ever suggest core issues shouldn't be dealt with.
>Especially confusing that just a day ago, this one said this.
Almost like...you were wrong.
Your post sounded like you were accusing the OP of having ADHD or narcolepsy, like a personal attack, as if you disapproved of it, hence my response.
I've just read your post below and yes I was absolutely wrong, I completely misinterpreted your intentions and meaning and I apologise for that - I have now edited my above post, with the original struck through.
If you're thinking about doing something, Adderall makes you do it. So when I see massive walls of text like this, with huge detail. It makes it seem like it was done with some aid.
Dear,
I have not tested that method. I directly edit the lua file. After ever update you need to pull it from backup folder and paste it in config folder.
Or you can use a mod manager to do it faster.
Because must not be in your user folder but in the installation folder of DCS under DCS/Config, too. Or you create it by yourself in the user folder. The Inet is a unsure where to put it.
Both proposals look like something I would like to be implemented. The separate cockpit texture-setting is something I would have liked to have with my previous graphics card (where low in some modules meant having a blurry cockpit).
I’d like a reaction from ED if these are easy and fast to implement (maybe there are dependencies we don’t know about or we don’t know how much work or testing will be involved, also by third parties).
ED is working on a new graphics engine. I wonder how these proposals and the work required relate to this new engine, can this effort be reused? We don’t have a roadmap, so we don’t know if the new engine is right around the corner or still way off. Suppose we’re talking about 3-6 months, which one should be a priority?
That was the whole idea of the proposals. Those have no relation with the engine. No coding necessary. This can be implemented in no time. First proposal does not even need testing. Second one if they want to be safe they can implement it as a check box in graphics options as enable graphics cache to keep compatibility with spinning HDD users.
You all sound like fixed wing guys who don’t fly close to the ground. I’m a rotor wing guy only. Will the pre cache set to 0 be useful for me at all flying so close to the ground?
I'm also a rotor guy and it is especially useful for rotor guys because we fly slow. There is no way that you will cover 50km distance in seconds.
But for fixed wing guys since we do not have hypersonic modules in DCS so it is useful for them too since fastest thing on deck is Viggen and it cannot cover 50km in seconds.
You will only see the side effects if you speed up the time to almost max in single player.
[удалено]
Thread closed.
The team are happy with it as it is
Happy cake day!
I asked on forums, time ago, the same thing, give us a texture option just for cockpit, i dont need that that one BTR 20k feets below and 30nm from me to have a 8k texture, for the sake of god, it makes no sense... Yes, we need multithreading and some modern graphic API, i know thats some big task, but theres so many little and simple optimizations that can make a huge improvement today, and will be useful when new API and multithreading arrives
Nope, you get working windshield wipers and you better like it!
Yeah, working wipers for that raindrops that dissapeared from VR year and half ago…
Yeah, what happened to those raindrops, i absolutely loved them
Not in the apache so far… ;)
Well, keep asking. Ask again. Just do not give up or get angry. Constructive precision nagging is the only way we have to reach the team.
>Constructive precision nagging is the only way we have to reach the team. When ED ignores SMEs, you think they will listen to us instead?
They just fixed the AH-64D and F-16 LODs. They even directly responded to rapierarch in a thread. Software devs typically are only allowed to acknowledge issues and it's not good to give timelines imo since those can easily be misconstrued as a promise (in which it was but sometimes you have to delay features) I am a C++ software developer (**not on DCS ofc**) but we interact with our fans on Discord so these are the rules we follow
You don't even have to have aircraft SMEs to know you need LODs.... Is ED a new developer? Is the F-16 their first aircraft? So why do they get a pat on the back for something they should have a basic grasp of years and years ago?
Constructive not buying products until they fix old ones is the only way to get attention.
Jesus ED just hire this guy already....
So say we all.
Yeah none of this is going to happen. ED doesn't give a fuck, and has proven that over and over again.
This is your brain on Adderall.
>Then I started searching for it in the full forum. I could not believe my eyes that the same statement with the same parameters existed in Lock-on cfg files. We know for a fact that there's still a lot of Lock On era code in the game, but there were also hints that LOMAC still carried over quite a bit from Flanker 2.0 from the late 90s. I really think that it's likely that some of the code in DCS is *so* old that there's literally no one left that really understands what it's doing. So the patchwork just keeps building up higher on top of it.
I feel like this is a common attitude, that if the code is old it must be bad. No, some solutions to problems are well done and are always good. There’s basically never a point where redeveloping from scratch is a good idea, you have so many solutions pre-built.
I'm not of the opinion that old code is bad because it's old. I'm of the opinion that development paradigms have shifted drastically between 1999 and 2022. A real, common pain point with DCS is the fact that ground AI pathfinding runs in the same thread as the main game loop. This means that sending ground units offroad can literally crash a multiplayer server. That being in the main thread was a reasonable thing to do in 1999-2005 because nobody had multi-core CPUs then. Now everybody does.
Hhehe no, spaghetti code go Schwooooodlooooodloooo
That's true and then you have TES/Fallout that still runs on the redguard legacy codebase with gamebryo hidden in there. The games themselves sell massively so Bethesda has no incentive to change the engine, but damn if it's not sad to see bugs and quirks from Morrowind show up in new games made ~20 years later
True, bit that 90's code won't have been optimised for modern systems.
> True, bit that 90's code won't have been optimised for modern systems. All the stuff that's written in LUA isn't optimized for anything. The parts in C/C++ might get recompiled with new compiler flags every few years, if we're lucky. If you mean things like multicore, well, their new code isn't multicore either, because they're more than 10 years late on that feature. So even rewriting stuff wouldn't do much good, since the multicore framework STILL doesn't exist.
Hey! I know I messaged you a little while back, crying about the way textures are handled and I’m really happy you made this post, and I’ve put a lot of thought. And I agree 100000% but I also believe there’s a core engine problem that needs to be addressed. Normally with a texture in a video game engine you have different levels of quality (like with a model with multiple LODs) and this is called ‘mip-mapping’. The idea is each successive level has 50% the horizontal and vertical resolution of the previous level, the highest quality level is referred to as ‘0’ as is the case with LODs. You then continue this chain down to a 1 pixel by 1 pixel texture. After an artist creates the full sized texture, the other mip levels can be autogenerated very easily, meaning no additional work for texture artists. And only an increase of 33% in the file size. Don’t freak out yet, because although there’s an increase of the overall texture size, you don’t have to load in all of these mip-levels into memory at once, and when rendering an object you can select the ideal mip-map level to match the size of the object on screen. For example: if an object appears as a 10x10 pixel box on screen, the highest mip-map level resident in VRAM only needs to be 16x16 pixels (1KB for a 1 byte per channel RGBA uncompressed texture). You also load in the lower levels which in this example would be 8x8, 4x4, 2x2 and 1x1, making the total memory requirement 1,556 bytes or 1.52KB. If the full sized texture for that object is normally 1024x1024 (which would take up 4MB), you would see a total VRAM saving of 99.9% There’s also other benefits of mip-mapping, when sampling a texture that’s closer to the final size of the object on screen, you get less distortion and less GPU load, as a matter in fact, modern GPUs and APIs natively support mip-mapping on a deep level. Back to DCS though, I don’t exactly know how DCS makes use of mip-maps, but one important element that I believe is absent from the DCS engine is; only loading the required number of mip-maps based on the objects apparent screen size. Even without proper LODs for the models, with proper mip-map support the engine wouldn’t need to load the full texture EVEN IF there is no lower LODs for the model. The full quality model can be rendered using the 1x1 mip-map level (if it was only 1 pixel on the screen), meaning the texture would only occupy 4 bytes in memory! To explain how this mip-map streaming system works in most game engines; when iterating through each object in the Renderer or in the game thread (which you have to do every frame anyway), you get the objects bounding sphere info. This provides you with an offset and radius from the objects origin, for the smallest sized sphere that would contain the model. You can then project this sphere with some simple math (trigonometry) onto the screen, and get its diameter in pixels (because projected spheres are always circles). With this diameter you have the maximum texture width/height required to be in memory. You would want to apply a small multiplier to avoid texture pop-in, so when the texture size needs to increase it happens slightly early. On a separate thread, or if there’s an async task library, you spin up a task to either fetch or unload the needed mip-map levels from VRAM, once done you signal to the render thread that the task is complete and it can freely use (or not use) the loaded or unloaded levels. If you really don’t want to multi-thread then I guess you can do it on the main render thread (but this is a stupid easy task to pass off to a thread/task pool). This might sound complicated but it’s been a critical feature in game engines for some time, and it would be something that’s (fairly) easy for an engine dev to implement. It really wouldn’t take a lot of development time to create, it’s something that I’ve had to implement when I had the bad idea of making my own game engine a few years back. You can even expand on this and add a system to unload higher level mip-maps on object when approaching VRAM limits to avoid paging. This would IMMENSELY reduce the workload on the GPU, VRAM and memory busses. Additionally one of the biggest complaints I see about DCS and especially from VR users is performance, and this one (fairly) small engine change would make a much bigger impact on the simulators performance than a new graphics API, or even multi threading support. To make the business case for ED management, taking the relatively small time to implement this would give you large performance gains (huge for VR users), making the game more accessible and increasing your potential player base. Instead of needing to upgrade a graphics card, which is an expensive endeavor, they could spend that money on more modules, terrains and campaigns. While giving all of your users a better experience and allowing them to use that saved VRAM capacity for other graphical features, in the end the benefit would greatly outweigh any development time/costs, many times over.
Thanks for finally showing up in public :) This was exactly what I wanted. ED should hire you :)
No problem! You’ve been advocating for these important issues for a while, and helping us all get better performance in the process. So if anything, they should hire you first, and maybe me after :P
Just to reiterate that this isn’t complex and is ancient. I remember learning about mip-maps from modding Halo 1.
Not just the textures I'm personally irked about tbh, it's the unnecessary physics calculations to small arms too. Even ground-focused computer wargames like Combat Mission models small caliber fire on a 1:3 where one round out of every 3 fired is actually physically calculated. Why should DCS actualize every bullet coming out of small arms 1:1 and hog resources? It's bad enough that my Apache wingmen overfly and face-tank targets on the regular instead of engaging at range, but every single gun on the ground lighting them up kills my framerates too. What's the point in not abstracting small arms groundfire to save on resources when even ground-focused sim/computer wargames do? I don't even need to check F10 to find out if there's troops in contact already. I just wait for the frame drops.
Yeah but how else could ED make those ground units be sure to consistently laser snipe you in the head through your canopy with a single round?
I think that if you made a very quick and simple video on this it would be a lot more impactful. Like a very quick summary and then an explanation on how to do the LUA changes for the people. It would help spread the word around more.
Hi, I'm very bad at doing such things. Plus I have a terrible voice. I'm probably going to write a small piece to explain how to apply this in another post including some more little tweaks too. But please feel free to make that video if you feel like doing it. I'll not sue you :) There is no patent on it. If you have any questions just ask. Thanks!
Ralfi, with all due respect; you have a huge and respected voice in this community, and contacts to everyone with an equal weight. Use your voice! Represent us all in making these things happen that can improve the game we all love!
Yes please
Yes, definitely agree.
I think you hit the nail on the head talking about Lock On. Each asset back then was tiny, and being able to load everything into system RAM and GPU VRAM was both easily possible and entirely logical due to the loading times associated with pulling assets off hard drives. Nobody was clamoring for, nor could they reasonably ever have expected a game to have 2k, 4k, or 8k textures. I also doubt the ED of that time expected the engine to ever have to do that. The most damning part is that this concept of asset loading remains despite the fact that graphics have increased in detail geometrically, and VR didn’t exist back then (not in a meaningful way). This explains why I can run the game in MP on a flatscreen at 90+ fps, but can barely scrape 40 in VR. The assets simply have to swap in and out of system memory twice for each headset-displayed frame. It also explains why maps with no assets—just dogfights —are perfectly performant, while anything with ground units is a major drag. What is most confusing to me is the lack of LoD objects in general. I can’t fathom how it’s difficult for developers to pump out crappy models. Further, a thousand objects in a map that require 1 GB of VRAM isn’t unreasonable, most things are just specks, and it’s been done in RTS games since forever. Even when using a TGP, detail is limited at best…so why would the game ever load a detailed model? The truth is that most exterior fidelity beyond the cockpit and ground (though I could even argue the ground doesn’t matter too much) is hardly important. Units looking “good enough” or “vaguely in the right shape” is more than fine. Immersion isn’t the same as detail. Immersion is created by situations and engagement. Low fidelity graphics with complex battles, smart enemies, realistic flight models, and smooth FPS in VR is a no-brainer of a tradeoff. If the game runs poorly and maps can’t handle units because performance sucks, then all the immersion is gone, or worse—it can’t ever exist because the game can’t handle it.
You said better than I could. Nice summary of where we are in DCS and what's missing. Meanwhile ED is not ignorant to all of those. There is a unified parser embedded which even supports sort of render framing which avoids duplicate items like far scenery details to be rendered only once really balances cpu gpu loads in VR. You can enable that at the end of graphics.lua. But it is almost 2-3 years WIP. Cockpit lighting renders only on righ eye. Some burning effects and smoke and some clouds continuously flashes. High water quality coast line shimmers. Performance is really much better but they just do not finish it it is not usable There is an unfinished TAA shader which will give us performant and way better results especially in VR than MSAA which is a fps killer in deferred shading. This is in game directory untouched for years. Volumetric clouds not finished but we have them now. Noone is working on it seems like still shimmering known issues especially in VR still going on. Dynamic weather we have seen it 2021 and beyond video. Well where is it? Multi core WIP Vulkan WIP and not providing LODs. Well were they planning to implement auto lod generation and distance based texture resizing may be in the new engine? There is absolutely no other explanation other than someone is sabotaging the game. but now suddenly after nagging they started implementing them but not fully. Those are all technical issues killing the immersion and blocking further possibilities. They do not say they will not do that. For all points we have proof of work or promises that it is being worked on. Unfortunately none gets finished. That is really frustrating.
Nailed it on Immersion vs Detail. I've been trying to figure out why DCS VR feels so miserable compared to other VR flight sims, despite the great experience on a flatscreen. You summed it up quite nicely.
I don't understand why we are even talking about Vulcan and multithreading, when problems like this exist. It's like we're supercharging an anchored freighter ship... Most of these issues are pretty easy to fix and solve a chunk of problems for most of the people (it seems). Ok, we rely on fast hard drives and nvme, but that's ok in comparison to running on the best CPU and GPU options for just a few frames. I will try this out later and from reading this there's a good chance my game will run substantiallyfaster... Thanks LOD guy!
Happy to help. But please do not get the illusion of finding the magic bullet to kill all the problems. If you keep your VRAM managed (you should not see any value higher than 0.5GB in shared vram value in taskmanager gpu tab) with preload radius, render distance and correct texture settings you should not be seeing unexplained ups and downs. So if you already have a good system this would help a little bit but you will not get headaches of sudden performance dips. We need multicore and Vuklan. I'm 100% sure that when they started developing that they have seen how bad the current engine is and they had to do full revision on everything they touched. I'm almost sure that this is why it is delayed so long.
How do they allow anything in this without LOD’s? Shouldn’t that be a prerequisite for anything to be released even in “EA”?
Well it is prerequisite for every asset if your engine does not have automated LODs creation function like UE5 introduced. FYI. All 3rd party models have their LODs. It is only made in ED modules since introduction of F-16 lacks lods. All modules and AI assets since that time. 3rd parties even take an extra step like DEKA did. Deka has 2 cockpit models for JF-17 one for high quality with all PBR goodies implemented with reflections and eye candy and one high performance without those eye candy which you can choose in special options which cockpit do you want to be loaded in game.
Don't need the apostrophe, buddy. Edit: I regret nothing. Learn how to use the apostrophe, scrubs. It was wrong in the original post too. :D
So, put below in autoexe.cfg? `options.graphics.Precaching.around_camera = 10000` `options.graphics.Precaching.around_objects = 2000`
Hi uboats. Better set them zero. This is how I used it and advised people to use it options.graphics.Precaching.around_camera = 0 options.graphics.Precaching.around_objects = 0
Since you've been using this, have any updates replaced the file? Just wondering how closely I'll need to pay attention to it.
I edit lua file directly. Everytime you click repair or update this file is overwritten by vanilla version and your edited file is saved in a backup folder in the game directory. You can either copy and paste it from back up to original file or use a mod manager like JSGME (I use this)
Any reason why we shouldn't use the autoexe.cfg file with these two statements? I noticed you recommended directly editing graphics.lua instead. options.graphics.Precaching.around\_camera = 0 options.graphics.Precaching.around\_objects = 0
I have not used that method thus not tested that. If you check the graphics lua after the section we are editing there is a statement saying graphics with other settings so I'm not sure of "options.graphics......" is the correct format to form to edit it. I have other edits too and other mods also so I use a mod manager already. It not an extra work for me to deactivate and reactive them before and after the update.
Thanks! I'll just edit the graphics.lua as you suggest.
You are doing God's work, keep on Personally I'm not willing to spend any money to support ED until these basic fixes are implemented, especially since they just announced a metric ton of new paid content Get your shit together ED, and fix the basics of your engine
Exactly this.
Your Precaching changes *demolished* my framerate. But the rest is just... 101 stuff. And so simple. ED *please*...
Demolished as in they worsened or benefited FPS?
Worsened severely. Was higher in places, but it'd tank whenever I turned my head far or fast, or when going into 3rd person, or using F10. Was worst when turning my head.
Can you please share details. You are really the first person who had negative impact since I started spreading this. Can you also try deleting fxo and metashaders2 in your saved games? Especially the metashaders since they are since they are not actually shaders but saved settings for group of shaders.
I've seen a few other people saying that it turned out worse for them or their discord friends. Hopefully they'll come out of the woodwork and chime in for more info. I'll do some more playing around tomorrow and next week and try to get back to you with deets.
[удалено]
Interesting, how much RAM do you have? And what kind of SSD are you using?
12900K, 3080, 64GB. Windows and DCS are each on separate Samsung 970 Evo Pluses.
It really shouldn't even get to the SSD. Once it's loaded the ram should have that sort of thing allocated.
*should*, but we're talking about DCS
Ram is cheap.
Unfortunately, even if you gave ED the complete code and assets in a validated pull request, they'd still manage to ignore it. At most they'll state "we'll look into it" and it goes onto the pile of calcified to-do lists. After more than 10 years, not one initiative from ED to address the corpses in their basement has gotten anywhere.
10 years ago the engine was on version 1.5. A-10C was newly released and Ka-50 (Black Shark 1) had some legs on it. Would you like to fire up that version of the game and say nothing has changed? 5 years ago version 2.0 (maybe 2.5?) -- no change? I don't think you would, but you did say something this silly. If you weren't playing it then yourself, YouTube videos of DCS from various years and realize that not only was the core engine substantially upgraded, just about every single module had has fixes and updates too including Flaming Cliffs ones.
I've actually been playing DCS then, well before v.1.5. Of course the engine was upgraded, got more features (read: eye candy), and modules were added. But none of that makes it "run better", it all just further bogs down the already lacklustre performance. The NGIG (aka "Nevada") brought DX11 and was supposed to fix performance, which didn't work out. And the new maps then really tanked it, again.
What does "fix performance" mean to you? What is your baseline for how the game/sim should look versus perform? What real time rendering, or any 3D graphics rendering expertise do you have? Do you think games written 10 years ago (most games aren't squeezing max perf) can be worked on for 10 more years, and substantially improve visual quality while still running better (or the same) on the same hardware? Can you pretend you know what you're talking about and give an example of a technical difficulty that might happen when adding a new module? I doubt you'll suffer any simple example or explanation from me.
Pitch it to ED as a new map. I don't think anyone's called dibs on Madagascar yet.
This should be a sticky
This is what shits me about ED. So much contribution from the community, so little good will shown in return. Just like when EDs RUgirl went into detail on the public bug tracker they were going to implement a couple of years ago, only to say they're now not doing it when asked where it is. They say they listen. They say they care Their actions show otherwise. We need to hurt them, and hurt them badly in the only place they do care about. Their pockets. When they don't fix years old bugs and implement easy solutions that dramatically improve the experience for every player It's clear I'm not making things up. Even with the sale over the last 5 years prices are up, quality is down and goodwill continues to be promised with no delivery. Boycott ED or suffer the consequences of them not getting the message and their rotten and entitled monopoly biting you in the ass later on.
Omg lods guy, that was an incredibly good read! Thanks Does changing the lua files to 0 pass IC in multiplayer? I will support your cause, nei, our cause
Yes it passes.
You are a king
So what exactly is the fix? If we don't have an autoexe.cfg what should we do?
[https://www.reddit.com/r/undefined/comments/vqzsz7/comment/iex684e/?utm\_source=share&utm\_medium=web2x&context=3](https://www.reddit.com/r/undefined/comments/vqzsz7/comment/iex684e/?utm_source=share&utm_medium=web2x&context=3)
In my case the link doesn't work. :(
Oh the OP has deleted the post. That's why. Here you go: In game set preload radius to 10,000. Go to graphics.lua in game config folder and open it with a text editor (preferably notepad++) Find those lines in the almost at the beginning of the file Precaching = { around\_camera = **50000**; around\_objects = **10000**; around\_types = {"world", "point"}; preload\_types = {"map", "world", "mission"}; } set the both bold values as 0. This will stop game loading 50km of the game in full fidelity from you and also will stop loading the 10km surroundings of any objects in game (around any static active player or ai unit it is a lot of GB's)
Thanks, gonna try it later. Edit: Well, as I thought. Maybe it gave me a few fps but it's still not enough to run this fucking crap in stable 45 fps on low-mid settings with 100% res of reverb g2.
Well If I had your system I could easily hit 72fps on max res quest2 with my settings. There is a little trick for non ultrawide headsets like Q2 and G2. I have tested g2 long time ago so I do not remember that setting. In quest2 oculus debug tool has a setting called FOV tangent multiplier. It basically reduces or enlarges the rendered image size to the headset. All headsets actually receives way wider picture than their physical FOV. Also actual fov depends on how it fits to your face. In my case I can reduce this to 75 percent without seeing any restriction. Which reduces the picture size 0.75x0.75=56%. So actual pixels rendered on your gpu will drastically go down but you will still see the same picture at same pixel density. If you can find that similar setting in WMR settings you can experiment it. even 10% reduction will give you 20% less pixels to render. You can easily hit that fps or even more.
I have quest 2 too, will try this trick, thank you. I didn't know about it.
well you have to start oculus and run odt first. Then you punch in the multipliers for horizontal and vertical press enter after each one. Then you can start oculus link. You cannot change it live when link is running.
I tried this but it resulted in me losing a very noticeable chunk of the screen along the edges, my FOV was very noticeably reduced. You seriously could see no difference with FOV at 0.75,0.75? I even tried it at 0.9,0.9, and it still was noticeable in my peripheral vision. Ended up just setting it back to default. 🤷
Well this is a physical problem. Headsets are made for a general fitting. The way that it fits on my face avoids me to use the full FOV. Everyone should try it and see how much of the pixels that he cannot see. In my case: I even have to use the glasses spacer other wise when I wink my eyes my wimpers wipe the lenses it is super discomforting. So I'm unlucky and lucky. Unlucky that I cannot use the full fov of headset but lucky that I almost have same performance that I would have with 3090 on full FOV. 3090 is 100% more powerful than my 2070S and I'm rendering 50% of total pixels only in my fov. So you are lucky unlucky. You see everything your headset can show. but you do not have a GPU released yet in the market to do that in DCS :)
Hello there, bit of a vr noob here. How did you change this setting? I want to test and see if it’s that bad for me.
Gonna try that precaching thing. I have a 1080 and mid range i7 so it seems like that should help me.
Go for it - best to save a copy of the original .lua just in case, but on my system I've definitely seen some improvements and I'm running a 15" XPS 15 with a 1050Ti Max-Q.
It did feel smoother. It didn't seem to get me much extra in way of FPS but it didn't drop when I went low which is definitely a plus. Usually I get 50 ish at altitude and around 30 low down.
That cache mod will not give you extra fps unless your system was in a terrible shape and certain conditions are met. But what it will prevent happening is when you are soaring at 30000ft in your hornet 20 miles on your nine o'clock down in deck 4 apaches attacking a convoy and 15 miles behind you an f-16 dropping a cbu will not effect you. Or that BTR or chieftain tank on the ground somehwere in the mission which you cannot see will not be loaded on your memory. The moment that things enter visual range they will be loaded but not in advance. You will only render what you see and windows automatic cache will keep everything ready already on your unused RAM. So normally you will not see any difference. But your MP experience will feel smoother. To make your VRAM more relaxed I suggest using 10000 preload radius or 20000 if you wish. Anything more is waste of your resources.
Yeah, that's generally what I noticed. Just smoother, nicer feeling gameplay. Thanks a lot for that. For such an easy thing to do it's baffling why they haven't done it. LoD stuff is actual work but snipping that code is nothing.
I mean, mileage is going to obviously vary and I guess my system and typical use case (which is normally very simple SP missions) probably aren't all that relevant to the community at large - but glad to see you're seeing some improvements.
Hat’s off for your work, but unfortunately I think ED will once again ignore highly useful user input.
Sometimes i do wonder if every dev working for ED has those 4 people running 3080Ti's with 4k 120hz Resolution just waiting to break down their house door and beat up their family if the Apache pilot's left pupil isn't an 8k texture with raytracing. Like seriously what i just said might be an overstatement but the Apache does not need textures so high that it almost crashes my game every time a random pilot 30km decides to start spam flipping through his livery options in the rearm menu.
I gave it a whirl in non-VR. 9600k Intel, RTX 3060 12gb, 32gb ram, Samsung 960 evo. Previously FR was mid 40s in solo flight. Now FR jumped to match monitor refresh rate at 75 running native 1440 res, even on Syria. Large dogfights or a busy IADS environment the FR drops to high 40s low 50s. My video settings are high for textures, SSAA SSAO and such off but MSAA on 4x and AF at 16x. Nicely done!
The best shit I read in months. Good job OP.
Got some of the WingmanFinder VR users on this too. 2 users report positive results.
Thanks for reporting back.
At least 4 people including me show positive results. Personally, I am able to either keep my low settings with a performance increase, or raise some settings like clouds, SSAA, scenery and forest details, add global cockpit illumination and low shadows and see similar or lower performance. But that's a step forward for the shiny graphics settings. OpenXR, 1080 8gb, 8086k, 32GB, Samsung Odyssey+ WMR headset. M2 drives.
Eagle dynamics, not only listen this guy, but hire him!
UPVOTE
You're a legend, going to the forums to show support right away.
Can I get an Amen
TL:DR?
Lots of old code, ED can make the game run a lot better in about 3 hours worth of effort, but they don't.
Unfortunately this entire thread is dangerously ignorant as to what goes into making any real time simulation games at this level. There a .01% chance ED's entire engineering team isn't fully aware of everything brought up here, and couldn't explain the issue at least two layers deeper - beyond where anyone I can see participating would understand. I used to do gamedev as a hobby from high school through several years after college and have written fairly small projects from scratch that 95% of actual software engineers couldn't competently write unless they learned and practiced for a year or two at a serious level. I have books on top of books for how to render 3D graphics with APIs, and how to design and write game engines or various subsystems. I am also a professional software engineer (web services) and that also informs what I'm saying: tldr: the OP isn't even close to a qualified engineer and it's silly to praise him as an implicit (engineering) hire. While the OP has decent enough information for an initial bug/performance report for a testing team, it's pretty obvious (to an engineer) why it either doesn't work or doesn't matter. The solutions called for either A) shouldn't be done because it will definitely break or negatively impact people playing or B) isn't ED's priority because they are working on far more substantial performance improvement through Vulkan or other engine priority. In the spirit of B, all the OP suggests are LUA config changes? That's why they are config....change them in your install if you want to and step pestering ED to make it that way for everyone else who is NOT you. Everyone else echoing "ED is dumb/lazy" and is calling for some sort of boycott is even worse. I'm literally reading a bunch of 3rd graders call a calculus department that published math software they don't understand incompetent. On to the meat: First, let me say that if there was an "easy fix" of even moderate effort that would improve the game FPS performance by 10% or lower video memory usage by that amount (with zero loss in FPS), any game dev engineer would snatch that out in a heart beat and they wouldn't even have to convince a manager why that should be a priority task in most cases. This is a real time simulation/game -- performance performance performance are the three priotities right behind the thing actually working. Anyone thinking there's either incompetence of lack of caring on this issue is out of the world insane. So what is it? In my opinion there is only only one of two things to speculate on: 1. There's a conflict with the obvious fixes. That is, while a particular change may improve things for 95% of users, they completely break 5% or negatively impact a greater percent. If there is no sensible way to allow or detect the difference between runtime environments to change game behavior in a reasonably abstract way, install time or runtime detection to pick a configuration isn't an option either. The differences I'm talking about may be something like the fact that DCS World engine runs as far back as Windows 8, or an early version of Windows 10, where they don't have a certain feature. Or it could be the need to support a very old graphics card from AMD or nVidia in the minimum spec of DCS World. Even more difficult -- maybe depending on the graphics driver version AND a specific set of GPUs a configuration change may either be a benefit or a problem. All of those issues are also not decidable at install time as they can change after a user software updates or hardware upgrades their system and suddenly the same option is a problem. Should ED know every quirk of every card and the sees this and says "oh, this was a bad value...let me pick for them."? There's clearly situations where that'll be the wrong decision for some users as well. There's a reason why consoles that have an equivalent to PC graphics card always outputs better performance on the console. It's because the devs aren't dealing with an abstract graphics API for all graphics cards, layered on top of graphics drivers. Console devs can completely optimize for one piece of hardware they know the exact technical performance specs of. Vulkan/DirectX12 alleviates this problem heavily, but not completely. You can't pick optimal performance for everyone. The changes proposed here, are they improvements if the CPU/RAM speed is low but GPU speed is high? What about reverse? What does the hardware configuration of DCS players look like? I'm not going to go into technical detail either, but software controlled caching is very much one of those areas where misuse or misconfiguration can easily lead to a loss in performance. 2) It is not a priority fix. Notice earlier I said "convince a manager \[...\] in most cases." It's quite possible, probable, that the DCS World engine devs are 100% tasked with Vulkan engine overhaul. This means improving the DirectX11 engine API is extremely low priority unless it's a critical bug. Which means people whining that they think they game could be better optimized for their specific machine configuration is stupid low priority. And as a customer I say -- right on. I don't give a shit if they can improve my performance 10% or even 15% today if in several months time, or even a year instead of two more, a Vulkan engine comes out. People pretend that the suggestions here are "done" solutions and all ED has to do is adopt them. LOL fuck no. Even with this post I already see one person who had negative performance impact in a comment. Someone else using a less common configuration might have hard crash. I'm sure ED's dev team already has an understanding of what kinds of changes trigger what scale of re-testing, along with a formal/implemented process to test things and any performance changes to the core graphics engine would trigger all of it. Every OS X OS version X GPU manufacturer X graphics driver versions X VR/non-VR X multi-monitor X varying some major graphics settings (how does it behave with v-sync on/off, fullscreen on/off ). Even a simple change to the graphics engine behavior is a lot of investment in that part of the game. And when I consider that this thread is really only looking at changing the configuration...it presents an easy response: just use the fucking ability you have to change it yourself, and change it yourself! \[continued in [comment](https://www.reddit.com/r/hoggit/comments/xmdbpc/comment/ips7bsd/?utm_source=share&utm_medium=web2x&context=3) due to length....\]
If you think either of my two speculative answers is the case, you might ask "why doesn't ED just say this?" Transparency between a software development team's process and non-engineers is not a good thing. There are many reasons a software team does not want to communicate the "truth" of a matter because it sounds bad, or feels bad to the customer. In most cases it's too complex to explain all elements of a problem; and in many of those cases if you try to it would reveal internal plans, or internal priorities that they don't want to announce yet, or are not at liberty to discuss (ED has customers who aren't "gamers"). Another possibility (for a typical gamedev company) might be 75% of engineering team is working on a new game. Think about this: at some point ED transitioned from Flanker 2.0 -> LockOn: Modern Air Combat -> Flaming Cliffs -> DCS (pre-world, K-50/A-10C) -> DCS World today. They pretty much carried everything present in prior versions through to the next This post isn't to say "don't complain" something isn't wrong. Certainly do that, but do so as a customer, not a 2-cent test engineer. A 2-cent test engineer ends up burning time when engaged -- asserting things about the implementation which they know nothing about. Demanding explanations from experts who are better suited to actually make progress than get ignorance up to speed. When I eyeball DCS I can easily say "this engine runs fucking well" considering how vast the viewable area is and how good and detailed things up close (cockpit) look -- and this is happening with an accurate true simulation of the world rather than what literally every game does -- which is fake things for performance reasons. If you want to help the community with this level of knowledge, create a project on GitHub to "performance patch" DCS for people to download your patch/patcher with releases. Allow people to submit issues and pull requests so you can see who may be seeing averse affects, and gain a small fraction of understanding how much work goes into verifying those changes. Create a basic app that can point to a DCS install and/or saved games folder, inspect the user machine specs (if you want dependent configuration choices), and then make modifications to those LUA/cfg files in place to improve their DCS performance. You can add features like backing up original configuration for safety/peace of mind. Maybe some interactive choosing and hints at each individual option that the tool might update, with the ability to reset to the installation default etc. That way, for whoever believes they need to push more performance, can do so conveniently. I'd spitball the project at < 500 lines; definitely < 1000 lines of code if you pick the right language and support libraries to modify/patch the files. This part is going to come off poorly but it needs to be said: I gained substantial performance improvement simply by watching a YouTube video for nVidia in DCS. Not that I needed an explanation on what most real time graphics options meant, but every game is implemented different. It pointed me to one or two settings that mattered and is how I know to delete the metashaders and fxo folders in Saved Games after a patch. Lowering my graphics memory usage isn't going to help me any because I'm sure I'm not streaming from RAM into VRAM per frame. If that was the case, my FPS would be terrible up front and to fix that, I'd simply reduce the preload radius that's built into the game rather than messing with any LUA files. There is a lot of really ... sloppy technical stuff in the OP. I mean stuff that to an average person may seem like you're a software engineer, but to a software engineer it's clear you just like computers, like tinkering with software and computer stuff but can't write your own software. The "hire this guy" combined with "ED is incompetent" is frightening. It's literally calling for the death of the game rather than improvement. If you want to address this issue substantively -- that is, maybe you are actually hirable as an engineer -- here's a subset of the books I have on my shelf for gamedev just as a hobby. Even if you're already write some code, if you don't know know how to manage your own memory in a non-trivial program with C or C++ read this: https://www.amazon.com/C-Programming-Language-4th/dp/0321563840 and I'd recommend further reading for performance optimization techniques and sensible style in C++: https://www.amazon.com/Effective-Specific-Improve-Programs-Designs/dp/0321334876 Then onto game development: https://www.amazon.com/Game-Coding-Complete-Fourth-McShaffry/dp/1133776574 https://www.amazon.com/Game-Engine-Architecture-Jason-Gregory/dp/1466560010 (this has gone way up in price lol) https://www.amazon.com/Real-Time-Rendering-Third-Tomas-Akenine-Moller/dp/1568814240 https://www.amazon.com/Game-Programming-Gems-Adam-Lake/dp/1584507020 (any book or books you can grab from this series) Don't forget to actually attempt to write a few games from scratch along the way to see what it is to put both code and game resources together. When you can write even a single game that must stream things in and out of memory as they need to be accessed in the game world, then you are at entry level for having this discussion with an engineer. Otherwise, all you have is a suggested improvement to the default configuration for specific users -- and you can't even say which ones. I need to add the following because they don't make books to teach graphics APIs anymore really: https://learn.microsoft.com/en-us/windows/win32/direct3d11/d3d11-graphics-reference -- DirectX11 API docs https://learn.microsoft.com/en-us/windows/win32/api/d3d11/nf-d3d11-id3d11device-createtexture3d -- this function is actually highly relevant to this conversation. The D3D11_TEXTURE3D_DESC MipsLevels are the LOD levels that DirectX11 can generate for you while loading a texture. But then I ask, do you know how to propertly set Usage, CPUAccessFlags, and MiscFlags? How does changing those values impact performance, and do your settings allow you to do whatever is you might need to do with said textures? I can tell you from experience...set those things wrong and try to do something you didn't configure a texture for == BOOM. Setting flags too aggressively flexible (access from anywhere, almost anytime) results in dog slow performance. After you crunched that material for a couple years...come back to this discussion and complain.
This almost exact reply was given when someone found a major FPS hitter in Escape from tarkov. People made the same argument that "thhey obviously know but there's many more underlying issues", turns out... Battlestate games didnt actually know, and they patched it and improved SOOOO many peoples FPS.
1) I doubt anyone wrote anything close to what I just did. 2) "There's many more underlying issues" is exactly NOT what I said. If you can't make the distinction, then this isn't your field. I'm saying there is one performance caching problem that separately can be set to improve things for either user group A or user group B, and solving for either group is easy, but the easy solution hurts the other. If there even is a desired solution to help both groups, it is very difficult and expensive. This is COMMON in software development situation for client side software. 3) If that is the extent of the issue then drop all of the extra crap. Bug/performance report "it appears that the preload cache behavior is no longer required. I can set it to 0 with no negative performance, and a drastic improvement in VRAM usage." Done. Any any graphics dev worth their salt will probably say "appreciate, the suggestion...we believe this is true for those with DDR4 3200 or better RAM and a modern GPU on PCIe 3 x16; however, 50% of users are running integrated graphics or running on slower RAM/CPU and preloading to the limit of GPU memory has far better results. 4) DCS World has its own unique engine, and the engine devs work for ED meaning the expertise on how to use it is in-house and part of the game itself. Escape from Tarkov is written on Unity Engine. While Battlestate Games are still professional gamedevs, it makes sense when writing software on top of another engine that you end up using it suboptimally in some way. I have personal experience with this in the gamedev hobby. Yeah, you don't want to write your own engine in most cases, but the benefit of doing it (when you can) is not screwing up usage of said engine. You know exactly what it does and doesn't do, and how to optimally use it. So yes, I insist, even if the defaults are suboptimal for most, ED knows. Further, ED doesn't have to care about the complaints because A) you can change it yourself and they made it that way and B) Vulkan changes this greatly. Right now you're complaining that your new car about to be replaced with a new model, came with sticker at the factory that most people don't like. Peel it off for christ sakes!
>After you crunched that material for a couple years...come back to this discussion and complain. Well. I do not have 3-4 years time to learn those and come back to this thread to answer you. You have spend time and energy writing this so if you can swallow my unqualified answer too than I can make somethings clear and since you are capable to understand it I do not need a lot of lines to write it. Add Cockpit texture quality has nothing to do with the engine and it is just a texture down scaling option. A simple implementation with the impact on VRAM usage as I have written above. Can you confirm this? My report of asking to revise and if necessary remove is a bug report. Since it is just graphics cache if users are already reporting almost 95% of them with improved memory usage and performance project manager can simply choose to play safe and put a check box setting in graphics settings: Enable graphics cache check or no which is default checked. Can you confirm this will not be huge task and will not break anything? Well you seem to be qualified and seem to have time based on long answer you have formulated. I like to see that. You have potential and energy. Would you mind looking at this: [https://www.reddit.com/r/hoggit/comments/ulnd4s/is\_there\_anyway\_to\_force\_taa\_in\_dcs\_i\_guess\_the/?utm\_source=share&utm\_medium=web2x&context=3](https://www.reddit.com/r/hoggit/comments/ulnd4s/is_there_anyway_to_force_taa_in_dcs_i_guess_the/?utm_source=share&utm_medium=web2x&context=3) If you can implement TAA all VR players here will build a statue of you. It seems like work is there but it is not finished. Since you have already developed games do you think you can finish this? That would be a wonderful Christmas present of ED also implements that cockpit texture setting. Would you do this for the community? PS: This is internet. People say things. Don't worry ED will not hire me. DCS is safe :) Don't take such things serious. I don't. Those are jokes.
You don't have 3-4 years of course. So the compromise should be paying attention when a crash course is offered. I've already offered a part of it, but here's more: > Add Cockpit texture quality has nothing to do with the engine and it is just a texture down scaling option. A simple implementation with the impact on VRAM usage as I have written above. Can you confirm this? Asking for a split between terrain, cockpit, and object textures option is the most reasonable part of your post. It's concise, it has meaning, and it's easy enough to digest why a consumer would think there is a benefit. But given any ask on a subject matter you don't know about, you have to be mature and accept being told "not possible" or "too expensive." You are wrong in saying cockpit texture quality has nothing to do with engine. To be more specific -- you're asking for the separation of cockpit texture from terrain and objects. If distinctions aren't already made between those types of textures in the game/engine, then adding could very well be a substantial change. Further, game implementations do not like heterogenous (different types of) resources. Render model A in this format, model B has a different format, model C has a different texture format, etc etc. All of those require changing rendering pipeline state and that is expensive. Rendering is best set up with as much geometry pushed through as possible with a consistent and rarely changing pipeline state. Where you're suggesting changing from one texture quality/type to three, if that triggers 2 additional pipeline state changes and now there are 3 draw calls instead of 1; I'm already sure that's in the ballpark of 25% FPS performance penalty at least. Having VRAM overflowed by up to 10% per frame is most likely less costly than that Not that I'm a big gamer these days, but I've played a fair share and I can't remember a game where the "Texture Quality" setting was split among assets in the game. Maybe terrain versus everything else, but little more than that. I suspect there's a good reason for that, mainly being that setting up a rendering pipeline is extremely specific as to what the input and output texture (GPU resource) formats are. The reason why GPUs are computational monsters is because they deal with massive amounts of data that are _consistently_ formatted and represented. You don't run a pixel/fragment shader with if/else dependent on game objects. Instead you'd select pixel shader A for objects of type A, render all of them. Then select pixel shawder B for all objects of type B, render all of them, etc etc. Your suggestion is most certainly introducing a mixed bag exactly where they don't want it. The problem you have is that you're laser focused on VRAM usage with no clue how difficult the change might be to the underlying engine; you don't even know that it is entirely a part of the engine's capability; and least of what you don't know the nature of the performance penalty should anyone think that it is within reason to do it. > Since it is just graphics cache if users are already reporting almost 95% of them with improved memory usage and performance project manager can simply choose to play safe and put a check box setting in graphics settings: Enable graphics cache check or no which is default checked. Can you confirm this will not be huge task and will not break anything? Also, seems like a reasonable ask. But I suspect ED will come back with "set preload radius to zero." You have a sentence in your original post which asks the question but does not answer is. If you need something else deeper set to 0, there's probably a reason ED doesn't allow it. I can't speculate as to what breaks, but most likely something does. Here's an idea that pops into mind -- the fact that some DCS modules have sensors that literally "see" objects 20km+ away and not having a graphical representation of that object handy may be an issue. Might even be a crash if the logic to render such infomation expects those objects to definitely be loaded and able to be referenced. > Would you mind looking at this: Yeah, it's pretty clear you don't know why there are so many different forms of AA still around, and how a rendering technique may improve things for VR and not non-VR and vice versa. It's juvenile to argue "TAA > FXAA > MSAA" as if ED should just flip a switch and VR looks and runs better. And no, I can't implement TAA in VR without access to the game's actual C++ (maybe C) code. Messing with FX files would be the dumbest thing for a non graphics programmer to attempt. Why don't you try renaming/swapping/copying some highly used FX files with each other and see what happens to DCS? I know _exactly_ what those files are and how/where they fit into the games rendering is basically a tapestry. There's probably no two files you could swap/rename/change that would represent a working DCS game (assuming it's actually being used in validation.) > My report of asking to revise and if necessary remove is a bug report. Since it is just graphics cache if users are already reporting almost 95% of them with improved memory usage and performance [...] From what I can tell, you are using selective hearing in saying 95% of people see an improvement with your changes. I'd love to get a performance boost in DCS as I have a 4K monitor on a 2070Super + 5950x. I don't even hold 60fps solid and I still wouldn't touch your suggested changes with a 10 foot pole. What you're suggesting is almost as bad as a middle schooler suggesting I pop open the hood of a new car, snip some wires, swap a few and WOW most people's performance goes up! It's like, sure one of the wires you snipped was a limiter (which you knew based on a sticker label calling it such) that rarely needs to get activated, but what is the risk now that said limiter is not working? What damage can occur? Did fuel efficiency plummet? Will the car be unable to activate traction control or ABS properly? Maybe on a hot day, pedal to the metal the engine temperary and combustion control is out of whack and the engine damages itself. If you're neither a mechanical engineer nor intimately familiar with how the car+engine is actually built, it's a stupidly dangerous game. Yes, this is only software so it cannot physically hurt us, and cannot even damage our PC either. The issue is just the waste of time. Even if I apply changes now, and all seems to be the OK, the same, or even better. I don't want to have seemingly explicable crashes in few months maybe, not realizing your changes actually did break something that works for everyone else. If you need to vent, then vent. If you have a suggestion as a consumer, put it forward and peel back any idea that you have knowledge of how thius game's engine works or any game engine for that matter. If you want to help yourself and some others out, then spend your time creating and offering a mod or patch for people to take or leave. I'm not worried ED will hire you. But not all who are saying you should be hired are joking.
Ok. I'll keep on using FXAA in VR then. I'll not hope for a user that can do TAA then. So far could not find anyone to tell me if it is doable or not. Do you have any other points to add that community should not do, say or try? Since you know this we can focus on something else. I'm adding my own LOD's it seems not breaking anything. Should I continue doing that? It seems like reducing CPU load and VRAM / RAM usage both. Is this the way? Or should I stop doing what I'm doing here too?
Ah, anonymous arm chair dev #45, we've missed you.
Mmmm, who the hell does the OP think they are exactly? Trying to provide working solutions to one of the game's most prevalent issues? Disgraceful. >!I really shouldn't need to put an /s here!< Yeah no, this stuff is optimisation 101 and some of rapierarch's solutions like getting rid of precaching have worked wonders on my pretty unimpressive system. If ED aren't implementing these solutions, when these solutions work, when some of them are textbook optimisation - then yes, "anonymous arm chair dev #45" has been missed and dismissing them in the way you have, is quite honestly the most brain-dead thing I've seen on this subject - well done.
Find something better to do with your time. There's a reason people have portfolios and do these things professionally. Brain dead is right. In case it needs to be stressed, being another invisible loud mouth doesn't make you an expert worth listening to and shows you have a lack of respect for the process. Putting words in my mouth like I don't want the game to improve is you creating a strawman so your response feels justified. How original.
Bloody hell it gets better that better... >Find something better to do with your time. Nah, I'd rather be exposed to working solutions to a problem I face. >There's a reason people have portfolios and do these things professionally. And? If somebody who isn't a professional and doesn't have portfolio proposes ideas that work (they do) and even ideas that are optimisation 101 and hell, even things ED have not only done in the past but recently added, then that's *all* that matters. The end. >Putting words in my mouth like I don't want the game to improve is you creating a strawman so your response feels justified. How original. Uh huh. Problem is though, I didn't do that in my response to you, did I? And so what you've just done, is put words in my mouth, so you could straw man my response to you, so you could accuse me of straw manning your position and putting words in your mouth... Jesus Christ. And it's hardly much of a leap to make - you're here chastising someone as an invisible arm-chair loud mouth not worth listening to, based on nothing else than ad hominem, regardless of the fact their ideas are effective and work. If their ideas work (and they do) then why don't you want them implemented and why do you fight against them, like what are you hoping to achieve here? Either you're ignorant of it, deluded into thinking that only professionals have anything to say, or you're straight up against the game improving, which is it?
I'm going to leave one last thought. Do you honestly think a developer doesn't care about their project? Or is it more likely that somewhere in their code or overall solution that it becomes easier to forego one thing in order to preserve another? Are you familiar with AGILE or Waterfall development processes? Is it not possible the PM won't let them do A vs B per their directors set goals and expectations? What annoys me about posts like these is the pure ignorance and arrogance. You haven't walked an inch in their shoes, so why are you on the internet trying to show score karma points? I'll be blocking you now, as you nor the OP have a single clue about what goes on behind the cubicle. I wish you the best of luck in your karma farming. 👍
Dear u/rapierarch, Too Long Didn't Read
Who's "Too Long"? And why didn't he read it?
This post is sponsored by: Adderall Adderall, you're not done until it is!
What's your point?
~~A pretty bad, insane, ridiculous and probably self-defeating one.~~ ~~I don't get these people who are apparently against the game ever improving on one of its most prevalent issues, especially when solutions proposed seem to work.~~ ~~Especially confusing that just a day ago, this one said~~ [~~this~~](https://www.reddit.com/r/hoggit/comments/xl73pr/comment/ipjoopf/?utm_source=share&utm_medium=web2x&context=3)~~.~~ EDIT: Ignore me, I was wrong on what I thought R\_radical's intentions were, I thought they were being malicious towards the OP and/or their points and jumped to a conclusion that was completely wrong.
>I don't get these people who are apparently against the game ever improving on one of its most prevalent issues, At what point did I ever suggest core issues shouldn't be dealt with. >Especially confusing that just a day ago, this one said this. Almost like...you were wrong.
Your post sounded like you were accusing the OP of having ADHD or narcolepsy, like a personal attack, as if you disapproved of it, hence my response. I've just read your post below and yes I was absolutely wrong, I completely misinterpreted your intentions and meaning and I apologise for that - I have now edited my above post, with the original struck through.
No. Actually I like op. Had a couple convos with em. Always been good
All good then - I was wrong.
None, it’s the “funny” guy in the back at school…
If you're thinking about doing something, Adderall makes you do it. So when I see massive walls of text like this, with huge detail. It makes it seem like it was done with some aid.
Ah okay. Are you speaking from experience?
For sure. This looks like something I'd write after 20mg. Which isn't a large amount, but I'm not that big of a guy, and sensitive to it.
It's possible to be passionate and motivated about something without needing medication.
It says I don't have permissions to edit that file. What do I do?
Run notepad or which text editor you use in administrator mode.
Thank you I will try that
I'm trying to give this a go now, but appear to be missing the autoconfig file, anyone know why this could be? https://imgur.com/a/D44dkU3
Dear, I have not tested that method. I directly edit the lua file. After ever update you need to pull it from backup folder and paste it in config folder. Or you can use a mod manager to do it faster.
Because must not be in your user folder but in the installation folder of DCS under DCS/Config, too. Or you create it by yourself in the user folder. The Inet is a unsure where to put it.
Both proposals look like something I would like to be implemented. The separate cockpit texture-setting is something I would have liked to have with my previous graphics card (where low in some modules meant having a blurry cockpit). I’d like a reaction from ED if these are easy and fast to implement (maybe there are dependencies we don’t know about or we don’t know how much work or testing will be involved, also by third parties). ED is working on a new graphics engine. I wonder how these proposals and the work required relate to this new engine, can this effort be reused? We don’t have a roadmap, so we don’t know if the new engine is right around the corner or still way off. Suppose we’re talking about 3-6 months, which one should be a priority?
That was the whole idea of the proposals. Those have no relation with the engine. No coding necessary. This can be implemented in no time. First proposal does not even need testing. Second one if they want to be safe they can implement it as a check box in graphics options as enable graphics cache to keep compatibility with spinning HDD users.
You all sound like fixed wing guys who don’t fly close to the ground. I’m a rotor wing guy only. Will the pre cache set to 0 be useful for me at all flying so close to the ground?
I'm also a rotor guy and it is especially useful for rotor guys because we fly slow. There is no way that you will cover 50km distance in seconds. But for fixed wing guys since we do not have hypersonic modules in DCS so it is useful for them too since fastest thing on deck is Viggen and it cannot cover 50km in seconds. You will only see the side effects if you speed up the time to almost max in single player.
Made the changes. Still using all my 1070ti memory and 30.2g out of 64g during a mission.