betatrash

graphics.lua > camera > extreme (or whatever your visibility range is set to) > structures, districts, districtobjects, objects, etc??? can crank them up to 150000. extreme.lua (or whatever your visibility range is set to) > distance > townneardistance, townfardistance??? or the section called 'district'. Not sure, those are the only options I could find, untested. Might kill your FPS though.

https://forums.eagle.ru/showthread.php?t=116893 + RAZBAM -F-15E (in progress) (2020?) I was actually one of those who requested F/A-18 before it was even a thing. Bit I still don't own it cuz I'm saving for new hardware and Track IR. :)

Actually, just confirmed this too. It may not have been the case in the past, but now DCS.exe is spread across all 4 cores. It is the top process on each core, using 25-50% of its cycles. Affinity is also set on the process by default for all 4 cores. DCS.exe is also executing 31-34 threads; multi-instance (TIL), multi-threaded.

Just for reference: There's no way it's all page file, because DCS.exe only read 1.6GB from disk, which may be compressed assets, so the 4GB RAM I'm seeing is believable, but not the 22GB virtual being page file. They must all be memory mapped files, although I've never discovered a method to determine that. Ah ok, yes, in Process Explorer, show Lower Pane, and the memory mapped files will all be listed there, pretty much includes all of the game assets. They're essentially files that are not in use, but can be paged into memory at any time. Essentially, when the assets are preloaded by the game at the preload distance. More assets = more RAM+VRAM, or at least more 'allocated' RAM (which isn't necessarily in use at the time). Higher resolutions = more VRAM. The highest RAM usage I've seen in SP 1920x1080 thus far is 5GB, with 23GB virtual size (which include all of those assets 'allocated' but not in use). Hmmm, something else I found odd. The internal game FPS counter reports video mem increasing from 3GB to ~8GB, as if it's not being cleared, or simply cached/paged. However, Process Explorer only reports 1.2-1.8 GB dedicated GPU memory and 500MB-3GB committed (with low res terrain textures). So the in-game counter isn't exactly reliable in terms of memory actually in use at the time. Basically, when loading a new map, it is not clearing whatever assets it had preloaded? This seems to be the cause in my case, as when it's at 3GB I get nearly no stutter, but after loading 3-4 maps it creeps up to 7GB I get constant FPS drops (although Process Explorer still reports only ~3GB max usage). With high resolution terrain textures, that occurs immediately. inb4; this is only a 2GB card. For reference (high res terrain textures): Begins at 4GB VRAM usage (where the stutter begins on a 2GB card), and creeps up to 9GB and beyond (after loading 3/4 maps and aircraft). These numbers may vary for higher resolution maps, which I don't own and can't test. These were tested in Flaming Cliffs 3 Instant Action missions. As a temporary fix/workaround: Just restart the game to clear the assets from RAM/VRAM. Although that will increase mission load times. Still odd that the system is paging to disk at 1MB/sec though (writing to pagefile.sys), while there are 2-4GB RAM remaining. It does this constantly, even while the game is paused. I can't come up with a valid explanation for this phenomenon... DCS.exe continues to utilize 25% CPU while paused (mainly rendering). I can also confirm it's DCS causing the page faults via its Page Fault Delta.

Are you sure that's RAM usage though? or 'virtual size', which includes pages on disk? I can only see DCS using 4GB max, but the virtual size is indeed 22GB, which are mostly memory-mapped game asset files I am assuming, although that would require verification. I doubt the 22-4=18GB are related to the page file because my page file is only 16GB. Hmm, I'm seeing other reports of RAM creeping up to 8-12 GB, but then usually leading to bad performance or crashes, maybe those are just leaks? Not sure.

You should never run without a page file present. The size of your page file can be set to a minimum of 1x your physical RAM +257MB (for crash dumps). Technically, GiB in RAM terms, multiply by 1024 (ie: 16GBx1024=16384MB+257MB=16641MB page file). There are several reasons for this: A. Most applications will simply fail when they hit their 4GB addressing limit or the OS decides to page it to disk, because it cannot, and will throw an unhandled exception (crash) for object (page) does not exist, since it was disposed of and is no longer referenced (instanced). B. Some applications will assume a page file exists, and will simply refuse to run without one, returning 'insufficient memory', due to the above concerns. C. Without a page file, any cached pages are simply flushed from RAM, and must be reloaded from disk, which increases overhead as all the objects need to be rebuilt. D. Memory crash dumps cannot be performed for BSODs. E. Unable to Sleep/Hibernate the PC without a page file. F. The page file will rarely be used, assuming at least 20% free RAM is available. In fact, running without a page file can only decrease the performance of applications. As for DCS, it apparently needs lots of VRAM. All other concerns are secondary. I'm running it on an i5-3570k @3.4GHz and it's using 25-50% CPU. Also running 55-65 FPS on an ancient video card, but it lacks the VRAM for high resolution textures. Still runs them at 45-60 FPS though (with stutter due to VRAM preloading/unloading). Hmmm, this is awkward. Did a bit of profiling, and DCS is writing to the page file at 1MB/sec, with 4GB RAM remaining, using a virtual size of 22GB??? Not all of that is necessarily page file though, they could be memory mapped asset files, but it's still hitting pagefile.sys for 1MB/sec. ;\

Just checked, my DCS is using 4GB. Although, that's in 1920x1080 SP. I'd imagine VR only uses more VRAM not system RAM. I tried Low/High resolution textures and it didn't make a difference. DCS.exe still uses only 4GB RAM, while I have 4GB free (12GB system commit, which includes 8GB OS/apps and 4GB DCS).

Only had 1 Raid0 array break, due to a faulty disk, setup over 10-12 of them. Easy enough to fix with a system image though. Also keep documents on a Raid1 file server with backups, too cheap to build a Raid5/10 array for documents.

32GB RAM doesn't give you much these days, maybe in some games, which actually make use of the 64-bit address space. Most 64-bit games though, still address only 4GB of RAM, using a 32-bit address space translated to 64. Not sure what the case for DCS is though, but is simple enough to profile. I have 16GB in this rig, used mostly for video/sound editing, otherwise 4GB gets used by games, 8GB by windows, and 4GB remains free. I think I once found a game that used 8GB. ;\ Wrong about what? 300MB/s being 86% of 350MB/s? Close enough... we're not talking about top of the line SSDs here, but you could just Raid0 two cheaper SSDs, paying half price for capacity, so who cares.

Lol, still runs all games on High graphics settings at 45-60 FPS, without stuttering. ;o Well, if the price isn't good enough, they'll probably cause a price drop on Vega GPUs anyways, so it's always better to wait a few months. ;p

Nah, I run Raid0, which is like 90% read speed of an SSD at 1/10th the price for capacity, sequential not random though. Ought to try Raid0 SSDs though. Furthermore, an SSD may reduce the preload times, and thus the amount of stutter but will not eliminate it completely, especially if the GPU doesn't have sufficient memory. In fact, even if it does have sufficient memory, you'll probably get some stuttering when the texture is first preloaded at the preload distance, assuming it is never flushed, doesn't matter how good your PC is, due to the way it's blocking the graphics thread. Although, in a high performance scenario, it would be best to max out preload distance, to minimize the amount of preloading, as long as memory permits.

Well, I think I've figured out what the issue is. The GPU has 2GB vram. Unfortunately, I don't plan on upgrading it before AMD Navi core cards are out. Setting Terrain Texture Resolution to Low seems to fix the problem, but looks horrible. Unfortunately, there is no 'medium' graphics option, and reducing the preload distance below 50/60k is not realistic. Thus, the thread blocking every 4 seconds is probably the one doing the preloading. Maybe that can be improved somewhat.

Still experiencing FPS drops every 4 seconds exactly to 30/40 FPS temporarily, otherwise the game remains at a solid 55-65 FPS. This is an issue which also existed in previous versions 1.0 and 1.5. I've tried literally everything on forums, and various options to no effect. I am able to increase FPS by reducing graphical options, but the drops to 30/40 FPS occur every 4 seconds regardless, which causes a noticeable stuttering effect. It's obviously a multi-threading issue, since all 4 CPU cores are running at 25-50%, while it occurs regularly every 4 secs, suggesting threads are being blocked. Side note: Attempting to alter shadow options in v2.5.4.29167 causes the game to crash once while loading, but it does not crash again after restarting. Also note: VR options were enabled by default, and had to be disabled because they were causing cockpit mouse view issues (stuttering).

see: http://forums.eagle.ru/showthread.php?t=101491 or my thread: http://forums.eagle.ru/showthread.php?t=122703 it's an engine problem (pre-190 engine). isn't designed for directx. hopefully EDGE (eagle dynamic graphics engine) will fix that.... or not... it's true you can be sitting on the ground and get 20 fps (because there is no z-culling), so the engine draws everthing in your view port: behind mountains, tress, buildinds, etc.. even 80km away, with what appears to be broken lod.

hmm yea, this was a good read. it seems that indeed there are optimizations/errors with the models. A. too many objects, way more complexity than is needed B. bad lod data / no lod / max lod at all distances C. animations lack lod for their framecount i think D. no z-culling, or it's broken for whatever reason dx11 might help alleviate some of them but not all. the files need to be optimized, and core optimizations made.

honestly, this isn't a user or hardware problem. inb4; this is an optimization problem. but when everything looks like a nail... use a bigger hammer? <- close enough. i don't have 150$ for a trackir + 300$ for a gpu + 250$ for a hotas stick currently... i also don't see the need to buy another gpu as the 7850 works fine on med-high settings 60+ fps in every single game ;\ meh, i don't mean to turn this into a rant. i'll just leave it at where i left it at before: specs on EDGE optimizations please, thanks. :helpsmilie: sorry, us developers are very demanding people. edit: here's some vtune data. only other thing i can think of is some bandwidth bottleneck either ram/vram, or threading issues (most likely). for some reason that i can't explain either (shows in the vtune data) is that lua.dll will consume 40% cpu when the game is alt-tabbed to desktop... it basically saturates the 4th core, while the 3rd goes idle.

yea, i've seen those threads lol. not the page count tho. 470 :D attached screenshots show this isn't a performance issue, but more of an optimization issue. keep in mind, this is when it's running at 15-20fps. (i max out at 60-90 in some areas), but otherwise = 30-50, with battles at 15-20. pausing it has no effect on cpu/gpu usage. my guess as to why nvidia might work slightly better: more pixel shader units as opposed to ati's vertex shaders... dcs makes some use of pixel shaders, probably unoptimized. still, leaves 40-50% of your cpu/unused (dunno, would need to see some nvidia reports). meaning you need a card twice as powerful than what is stated in the minimum/recommended requirements. :\ the engine looks REALLY nice btw, but no word on specific optimizations, which is what we really wanna hear :\ ie: z-culling another thing that irks me is some objects are WAY more complex than they need to be. some radio towers, etc have full-poly models... a simple light (12 polys) can be represented as a flat surface or a sprite. a tower is at least 50-100+ polys... could just simplify them, make them brushes with alpha and turn a 100-poly tower into 10 :\ or lights can be triangualr instead of rectangular. currently 12 polys, triangular = 8... 50% polygon savings per light fixture ;o flood lights can just be a sprite... currently it looks like a set of those is also 50-100 polys... edit: in the screenshot 31.69% average cpu usage on DCS.exe is actually 62%, since it's only using 2 of 4 cores. also, found a partial answer to this here: http://forums.eagle.ru/showthread.php?p=1850004 i'm guessing dcs is in the former category (pixel shaders), which is indicative of the 1990s period, and would explain slightly better performance (maybe 15-20%) on nvidia gpus perfectly.

did some further testing and this low fps is not cpu-related def. find a spot to floor your fps, then pause the game. theoretically/technically, all processing will stop, all animations cease, etc.. fps remains the the same. in several instances i've seen the fps jump up slightly, but it's rare, and only a minimal 5fps. so, basically the graphics engine is not optimized to handle dx9, let alone dx11. not the other way around (dx9 is not optimized for the engine). was able to get a more acceptable 20-30 fps instead of 15-20 in more general areas, still dips to 15-20 in engagements however, of a terrestrial nature. this is after tweaking some more settings in options.lua, like lights, fog, haze, etc...

these flashy things still exist in 1.2.7 on a hd7850. ;o

well, found this in some of the shader files, not sure how relevant it is. technique PFXSmoke2Material{ technique PFXSmoke2MaterialOP{ CULLMODE = NONE; //STENCILENABLE = FALSE; ZWRITEENABLE = FALSE; they're all like that btw. seems z-culling was never implemented? or is being implemented?

hey, one thing i noticed that could use a MAJOR improvement is z-culling. all those shaders are basically visible through mountains and the cockpit (even when the cockpit covers the entire viewport)... basically, nothing is being culled even 50-100km out. i tested with smoke. the fps drops even through mountains and cockpit floor. no gains to be had there. is z-culling in EDGE?... basically... also, i don't think those animations have proper lod applied, since they cause the same amount of fps drop even at 50km, when zoomed out. get about 30-40 fps normally looking at planes, buildings and clutter, about 50-80 at the sky. about 15-20 when looking at a mass of explosions and planes and buildings. this seems to be the cause of the performance issues imo. thread locking aside... (due to video+logic being on the same thread)... cpu stay at 60-70%, gpu fan barely hits 40-50%, some 60% load as well. no dpc latency issues either. tried disabling smoke/explosions, but apparently that doesn't work. btw, i found this in the 'edge' files.. lol? ;p - {"SmallShit2.0", "Land"}; win7-64, i5-3570k @3.4, z77, 8gb ram, radeon 7850 (ghz ed). almost like a 7870 except less shader units so less gtexels.

if only the handle position moved, but it doesn't. if that's the way it is, then so be it. but give us some indication like the handle position ;p

one bird. went in one engine, out the other.

a-10a no airbrake indicator. used to be on the flaps panel in lomac. now gone. not sure if by design. have to look out the cockpit at the wing to get indication ;o

well, it looks like it may be part of the panel, but the graphics look improperly aligned/clipped at a minimum. in any case, it's not a big deal, looked to be worse than it is, if it is in fact intentional. well i'll backup and try that, cuz i hate rebinding hundreds of custom keys. lol, more like turbotruck engine. incidentally used on commercial airliners as well... handles worse than a 747. EAC check. it's the first A-10A mission, running start. i checked the laste panel, eac armed. tried toggling it to no effect. assuming the a-10a doesn't have any other requirements for eac. but what does that have to do with handling? kinda confused ;o