Gunrunner

Oh by the way, another way to solve the AA quality with 10x0 nVidia cards, unless you already run at high resolutions, you could use Dynamic Super Resolution, in effect it renders the frame at a much higher resolution then downsample them to the screen resolution, offering better AA, better details. In my experience with a 1060 and 1070, it does so while offering better performance than fixed resolution and "classic" AA up to twice the native resolution. The reason the 10x0 have a problem with AA and some shaders on older games is simply that they are DX12 optimised, with some DX11 heritage but are starting to drop DX9/10 support, going as far as not supporting some DX9/10 functions in hardware anymore and emulating them in software in the drivers instead (which is not specific to nVidia or this generation of GPU, it's been the case for everyone for quite some time).

If it is a question of sharpness, it's more probably a question of settings than hardware performance, maybe try to contact these people to know which graphic settings they are using and whether or not they are using custom shaders and environment/flightengine.inis Optimising your hardware choice to get the best ouf of SF2 is becoming hard, but a lot is still a matter of configuration.

It won't benefit from it, at heart the SF2 series is a monolithic game, the latest patches do offload some minor tasks to other cores but at least 90% of the work is still done on only one. You would benefit more from having the best single-core performance you can afford. Keep in mind that many modern CPU get increased performances through optimised path and instructions that would not benefit to SF2 because it never was compiled for it and relies on API versions that do not benefit from them either. Considering the same principle applies to GPU, you might end up in a situation where older, "slower" hardware might get you better results than newer, faster one (or require high-end parts to see significant improvements over what was middle of the road hardware). If you look at benchmarks, compare DirectX9 (eg. 3DMark 06) or DirectX10 (eg. 3DMark Vantage) ones, anything above that is not an indicator of how useful it will be to SF2.

Translation : "We have so much riding on that thing that we are fine with lying a bit to ensure the program goes on as expected." Seriously, it's so over-the-top it could be a Trump speech, that's how you know it's bullshit.

Welcome aboard and sorry that I'll have to be a smart ass for your first post but... You do realize that the real thing probably never reached that speed at sea level, right ? Most aircrafts top speed, unless otherwise stated, are given "at altitude", never at sea level by default. I would suggest getting back to the stock ini and trying, let's say, around 15000/20000ft which is probably the altitude for the documented top speed. Lower is unlikely and would mean a far higher top speed speed at altitude. Higher is also unlikely as, starting at 30000ft it would make it supersonic, which the Yak-25 was definitely not in level flight. As a rule of thumb for planes of that era, at low altitude you reach lower speeds than at medium altitude due to atmospheric density (meaning higher drag, in part due to far from perfect aerodynamics), at high altitude you reach lower speeds than at medium altitude due to underperforming engines in a less dense atmosphere. Also keep in mind that the higher the altitude, the lower in km/h the Mach number. At sea level in a standard atmosphere, Mach 1 is about 1225km/h. At 20,000ft, it's about 1138km/h. At 30,000ft, it's about 1090km/h. From 40,000ft and, for all practical purposes, above, it's about 1060km/h. So, did 850km/h at sea level for a Yak-25 sound right ? Yeah, definitely... Does 1000+km/h at sea level seem entirely unrealistic ? Definitely.

Whoever wins the election, the only thing sure is that the US "democracy" and US citizens will lose, as will the rest of the world.

Title says it all, I was trying to identify a freeze crash my father was having when free flying, turns out he was running into The Wall and, instead of the usual song and dance, the game freezes with audio stutter. I've reproduced it with a few modded installs on 3 different computers so far (except the audio stutter on one), but not stock installs, anyone else can confirm ? P.S. : Apparently it's tied to custom FLIGHTENGINE.INIs.

Hi back then, sorry I snapped at you earlier, but in the last few years we've had our share of indelicate modders and scam artists, so some of us are more suspicious than others, but I was wrong and I'm glad.

Proving me right once more, I quote, starting from 4:44 : "Games such as Wing Commander or Test Drive III however run way too fast. To turn the machine into a 386 we access the BIOS and disable both the processor cache as well as the motherboard cache; Now Wing Commander and Test Drive III will run just fine.[...]To turn the machine into a 486 we disable only the processor cache but leave the motherboard cache enabled; This is a great settings for games that run too slow on a 386 but too fast on a Pentium; Theme Park is such a game." At no point is it suggested it's a problem with cache, but with execution speed. It's not a cache architecture incompatibility, it's an instructions-per-second problem. I'll admit it makes it not truly a clock speed problem either though, but since some games are actually clock-speed sensitive, it's a better bet to use underclocking than cache starvation to tailor performance for old games, it's also a much more fine-grained solution, provided your hardware supports it of course.

For early DOS games (from the 8088 to the early 486 era), the issue is very much clock speed as many just assume a clock speed and don't compensate, making them stupidly fast on modern hardware (they were already too fast at the time). When it comes to cache architecture I'm not aware of any game having problems with that but I'd be interested if you have the time to give me a few examples.

Nope, no problem at all with old games (most emulators allow you to adjust clock speed and CPU identifiers to suit your needs), emulation and virtual machines have come a long way lately. It's really only a handful of titles from between 1999 and 2006 which are problematic because they expect direct access to GPU functions no longer present in modern hardware, but even that is becoming less of a problem, some have already been updated for Steam or GOG re-releases, others have wrappers in the work. I'm no stranger to replacing components but it's just not worth the time and effort, especially considering capacitors might be only the most obvious problems. If anything else fails, you are up for hours to days of figuring out the problem, sourcing the replacement, nah, it's not worth the hassle anymore unless that part is what you find enjoyable, which is perfectly fine but no longer my cup of tea, and I have enough hardware around already.

Yes, "conductive" dust is mostly bullshit but in my experience that happens under two conditions : - Industrial / workshop environments, but even then I've seen it only twice in over twenty years. - In homes where people both smoke and have pets, but not because the dust is conductive per se, but because the combination of cigarette smoke and pet hairs make it clump and stick and acquire enough static electricity charge under some circumstances, if that happens in the right place, it can do damage. My sister used to kill a motherboard a year that way (that one was fun to figure out and led to my practice of favouring multiple low-power fans over single high power fans). By the way, the later is the only case of damage by static electricity I've had; In my experience, unless you go out of your way to demonstrate it or are very careless, it doesn't happen in the real world and grounding yourself is mostly a ritual inherited from when you dealt with individual electronic components rather than complex hardware. I favour low-power vacuum cleaning with a plastic end and brush not building up static electricity myself (just in case, because there is potential for real damage... get it, potential), it removes the dust just as well and doesn't send it flying to make everything else dusty and it takes barely longer for a much cleaner overall job.

Suspects a problem with conductive dusts shorting something; Proceeds to blow the dust around. Utterly brilliant. Oh, I forgot, suspects the problem is with the PSU, but doesn't remove and clean it... The way it's mounted, it's sucking air from below, with pets it's a recipe for disaster, at the very least the filter needs to be cleaned, at worst it's not filtered and the PSU needs to be cleaned.

Especially considering that most legacy had - by modern standards - crappy components (capacitors notably), making it difficult to find legacy components being cheap, stable and reliable at least for a few years. Nowadays, with the exception of a few titles from the late Windows 98 to early Windows Vista, everything works acceptably through emulators and virtual machines.

Don't worry, I didn't feel attacked or offended, I perfectly understood where that came from and entirely respect it (even though I'm suspecting I missed a post before the thread was closed, but hey, I'm no stranger to being abrasive). In fact my initial response came from the exact same place, because what the community doesn't need is more drama and modders with shady ethics; Fortunately it wasn't the case here as far as I've been able to determine, everything seems clean and legit, and I've said so after checking. The main problem is that the code was not particularly optimised and modern at the time of release but there were enough hardware bottlenecks that it wasn't showing much but we reached the point where the code has become the bottleneck.

Fubar512, and ? nothing in your copy-pasta actually proves your point... Before the advent of hardware 2D acceleration were all 2D games "faking" it ? Were they truly 1D games, despite using 2D coordinates and 2D sprites ? Are you also suggesting that 3D Studio, released in 1990, was not "really" 3D ? What makes a game "true" 3D is a positive answer to both these questions : - Does the game manage the position of the player and objects in the game world in three dimensions ? - Are the objects in the game world dynamically created from a mathematical/algorithmic three dimensional representation ? Let's consider the implications : - A game where the world is built in pre-rendered 3D, and actual 3D objects move and are scaled around it (e.g. Grim Fandango, Little Big Adventure, Total Annihilation) ? "Fake" 3D - A game where the world is built in true 3D, but where objects are 2D sprites, either classical or pre-rendered 3D (e.g. Wing Commander I, II and Privateer) ? "Fake" 3D - A game where the world is built in true 3D and where objects are dynamically rendered 3D objects (e.g. any of the games I cite, including Elite and its primitive wireframe system, but also the original Battlezone) ? "True" 3D Whether the game also include sprites for effects, or a 2D foreground for instruments, cockpit (unless you really want to argue that early DCS games were not true 3D games due to their 2D cockpits), weapons etc, is irrelevant. What is even more irrelevant is whether or not the objects are textured or shaded; a simple transparent wireframe (1980's Battlezone) is enough to qualify as 3D. Even more irrelevant is whether the calculations are the result of software executed on the CPU, low-level calls to the GPU, API calls offloading it to a GPU, or a combination of the two. It could be run by an army of monkeys and inputed back through punch cards, that wouldn't change the nature of the algorithms. Does 3D acceleration hardware allow for better and better looking 3D games ? Certainly. Are they a requirement ? Hell no.

Good one Gepard, the first plane I made for it was a Mirage 2000. It was 1993 and it was very much 3D. @ Blaze95, true but some voxel games were weird, which one I can't remember but they weren't using a true 3D world representation but 3D objects, I remember an action RPG but not its name.

@Fubar, oh, thanks, I forgot Falcon 3.0 in that list, and by the way, you couldn't be more wrong. Let me see, according to your conception of a "true" 3D game, if you played Mechwarrior 2 in its software-rendered version the game was 2D, but play it in its Mystique or 3Dfx version, only adding effects and not using a rewritten engine, and suddenly it is a true 3D game ? I know, you'll pretend that since they were different versions they weren't the same game thus making your point, regardless of the actual nature of the code. Let's take Unreal then... Are you suggesting that in software mode it is a 2D game, but activate Glide and it suddenly is a 3D game. You are trolling me, right ? You have stupid ideas at time, but I've not known you to be that out of touch with reality. 3D game doesn't mean it is using hardware accelerated 3D, just the way it manages spatial positions of objects and the generation of polygonal objects (excluding some "sprite in a 3D world" games - early Wing Commanders and LucasArts sims - as well as some voxel based games which weren't really 3D). Come on, even Julhelm pointed out your mistake. Oh, and let me add yet another example : Elite, 1984

Gunship, 1986 F-19 Stealth Fighter, 1988 A-10 Tank Killer, 1989 M1 Tank Platoon, 1989 F-15 Strike Eagle II, 1989 MiG-29 Fulcrum, 1990 Red Baron, 1990 Birds of Prey, 1991 Chuck Yeager's Air Combat, 1991 F-117A Nighthawk, 1991 Gunship 2000, 1991 Harrier Jump Jet, 1992 Task Force 1942, 1992 F-15 Strike Eagle III, 1992 Dogfight, 1993 Strike Commander, 1993 (first game to offer both Gouraud shading and texture-mapping in software, as far as I remember) TFX, 1993 Star Wars : X-Wing, 1993 Dawn Patrol, 1994 Pacific Strike, 1994 1942: The Pacific Air, 1994 F-14 Fleet Defender, 1994 Star Wars : TIE Fighter, 1994 Wing Commander III, 1994 EF2000, 1995 Su-27 Flanker, 1995 Mechwarrior 2, 1995 Wing Commander IV, 1995 Star Wars : Dark Forces, 1995 And that's only those I can cite off the top of my head... So yes, 3D games were definitely not a thing prior to 1996 and 3DFX... PS : Added a few more, and that's not even counting the games using 2D sprites for planes in a 3D world.

My, what a click-baity title that was... Have you ever noticed that, beyond the known bug of engine sound playing only when the game feels like it, there are some planes which simply refuse to play their engine sounds ? I've recently had the problem with some F4U/AU-1 and couldn't figure it out, the engine sound worked fine on another plane and other engine sounds known to work simply refused to play. After an hour of testing (mostly waiting for the game to load), here's the solution I found for the Corsairs. The Corsairs use two engineIDs, one for the actual engine, the other for additional exhaust effects, which is a perfectly valid technique but which prevents the sound from playing. The Data ini looks something like : [Fuselage] ModelNodeName=Fuselage [...] SystemName[001]=CenterlineStation SystemName[002]=FuselageFuelCell SystemName[003]=TopRedLight SystemName[004]=Pilot SystemName[005]=BottomRedLight SystemName[006]=TailGear SystemName[007]=Canopy SystemName[008]=Tailhook SystemName[009]=WingFold [Nose] ParentComponentName=Fuselage ModelNodeName=Nose [...] SystemName[001]=Engine SystemName[002]=Nozzle SystemName[003]=ExhaustEngine <- This is the problem The solution is simple, move the "fake" engines to the [Fuselage] or other relevant parent and suddenly you will have engine sounds without losing the additional effects. [Fuselage] ModelNodeName=Fuselage [...] SystemName[001]=CenterlineStation SystemName[002]=FuselageFuelCell SystemName[003]=TopRedLight SystemName[004]=Pilot SystemName[005]=BottomRedLight SystemName[006]=TailGear SystemName[007]=Canopy SystemName[008]=Tailhook SystemName[009]=WingFold SystemName[010]=ExhaustEngine <- ExhaustEngine has a new home, notice the SystemName number changed to fit the sequence [Nose] ParentComponentName=Fuselage ModelNodeName=Nose [...] SystemName[001]=Engine SystemName[002]=Nozzle In case you wondered, changing the EngineID doesn't work (and yes, it works on some planes with other types of fake engines, specifically those are set as 0 thrust engines, while all the problematic fake engines are set up as pure effect emitters).

It's not the GPU guys, it's the code, I'm having the same problem but considering that : - I'm between 12 and 15 percent total CPU usage when allowing the use of all cores. - When dedicating a single core to SF2, I'm never above 70% core usage and lose a maximum of 5 FPS over allowing all cores to be used. - I'm well below in total memory usage, as well as below the memory allocation for a 32 bits process and data transfers are not reaching any bottleneck. - Even at full load, I'm at most at 50% GPU usage. - Even at full load, memory usage, memory controller load and bus interface load are never above 40%. - With my configuration and settings, below 1680x1050 the lower the resolution, the higher the max and average FPS, above 1680x1050 average and max FPS are about the same until at least 2560x1440, but the higher the resolution, the lower the minimum FPS. The only possible conclusion is that the code/engine is the limiting factor. You can grab a handful of FPS with a beefier GPU, but this has quickly diminishing returns. You can grab a handful of FPS with a CPU with higher single core performance, but once again, it has quickly diminishing returns (and in your case, an i7 3770, the improvements would be in the single digits realm, all other things being equal). You can avoid FPS drops by replacing some image formats. You can increase your FPS by going for lower AA and AF settings or removing custom shaders and configs. The only true benefit of a GPU upgrade is the ability to increase the resolution and have better AA and AF settings (in fact, curiously, with the GTX 970 I have almost the same performance - within the margin of error - whether I play at 1920x1200 or 2560x1440). We are dealing with a 14 years old game engine last seriously updated 4 years ago.

You had the right idea with your pylons trick, now... just put the gunner and your doors in the same weapons group... (and make sure your dummy weapons have the same SpecificStationCode as your gunner). That should do the trick... Alternatively you could use dummy, empty, lodless, non-jettissonable fuel tanks for the doors, it's way less messy than fake pylons and inert, invisible weapons.

What the Brexit and proud Brexiters inspire me

The first and only comment yet on that article is hilarious : "A feat like this has not been achieved since Charles Lindbergh in the Spirit of St. Louis!" MiGBuster, well that also depends whether you're paying in dollars or sterlings. Also, off the top of my head, that's the largest attrition reserve the RAF planned in recent history for any type, I think you'd have to go back to the 60's to have anything near it. That might mean 3 things, a) they are expected to operate for a long time/have a very active operational career, b) a high loss rate is expected and/or c) they are expected to be hangar queens.

So, for about a year some people started having problems with newer GPU or drivers and there's little coordinated effort so far, this will be an attempt to do so. The idea is simple, everyone will report what they have tested and if it works or not, so others can benefit from it. I'll only take reports from moderately to heavily modded installs, not stock or lightly modded ones. I'll only take reports from DX10 running versions, no DX9. Reports must follow the following format : GPU / VRAM / OS / Driver / SF2PatchLevel / DetailLevel / CustomShaders / Reporter / Outcome GPU is the model of your graphic card. VRAM is the amount of RAM your graphic card has. OS is the version of Windows you use. Driver is the version of the driver you tested SF2PatchLevel is the patch level of SF2 you run. DetailLevel is the detail level you're running at, it can be High, Unlimited or Custom (I'm not interested in Low or Medium, Custom is only for settings better than the stock Unlimited through the use of modified INIs). CustomShaders, whether or not you are using custom shaders. Reporter is who made the report. Outcome is the result of your test, Occasional means it happens less than once per mission, Frequent means it happens around once per mission but for only a small part of it, Constant means it's almost always present. Yes, a lot of it is subjective and relative, but it's better than nothing. In addition you can give your driver settings and performance tweaks if you feel so inclined. I've left out my results designed especially to break things, only installs as I play them. Ok, now it's up to you to report your own findings and I'll add them to the table. Due to the limitations of the forums, the table is now a Google doc (link : https://docs.google.com/spreadsheets/d/1iOzDXda8uDCByqq5CbNQHAz3JJfYy15gwcV8CW47ECk/edit?usp=sharing ) Latest nVidia driver known to work for everyone : 353.62 Latest nVidia driver known to work for GTX970 + Windows 7 : 364.72 Latest AMD driver known to work for everyone : 15.7.1 Latest AMD driver known to work for Radeon R7/9 series : 16.03 Known problems and solutions : Problem: Anti-aliasing not working properly on Windows 10 (aka, the jaggies) Solution: Set [GraphicsOptions] AntiAliasing=0 in OPTIONS.INI and set anti-aliasing as a per-game setting using nVidia Control Panel. Problem: Video stutter in certain situations Solution: Set "Maximum pre-rendered frames" to 1 as a per-game setting using nVidia Control Panel Problem: Framerate stuck to 60FPS on AMD cards even with VSync Off Solution: None yet