sk000tch

For all our complaints, DCS must be a pretty deep game given the size of the manuals that come with each module. That said, for every word in the Hornet game manual, the US Navy has produced thousands. If you are truly interested in study, send a PM or something and I will be happy to point you in the right direction or fly with you. There's no peer review scientific study that is going to say a particular piece of software runs better on one api over the other. There's too many variables, particularly with the new lightweight APIs as so much comes down to implementation. They are actually very comparable technically, and arguments can be made for both. I don't pretend to know what ED's internal deliberations were but running a proprietary engine as DCS does tends to incentivize devs to prefer open source solutions. Many devs, especially non-AAA studios that don't get custom driver updates for their launches, are eager to get out from under MS lock-in, less driver surprises, and for games like DCS where, relative to the FPS flavor of the month, much more time is spent on the engine and graphics relative to gave development, an open source API where you can build what you want (rather than beg MS) would be pretty attractive. Again, I am not privy to their internal discussion and am just guessing here. It's worth noting that by and large most sims (and other open world games) are going vulkan. Some of the reasons explained below... First though, I am not sure you're asking the right question. What we should be comparing is Vulkan to DX11, and how those APIs perform using physically based rendering techniques. I don't know my audience here, so I am not sure how technical to be. I am shooting for middle of the road but apologies if I miss the mark. Rather than DSX12, what we are really interested in the difference between what we have now, and what we will have next - right? So not DX12 vs Vulkan? But rather, Vulkan vs. DX11. Again, not knowing my audience here... GPU's have matured from dedicated shader calculators to programmable devices - first CUDA, parallel processing, now tensor and RT cores... At the same time, drivers have become enormously bloated. Every time a new AAA is released there's a driver update. That's a lot of CPU overhead just to tell the GPU what to do, which is made worse by the poor multi-thread support. This is obviously an issue for DCS. So to start with, by requiring devs to clearly define how operations will be executed, CPU overhead is decreased by a substantially lower overhead driver and much improved multitcore utilization. Almost everything in Vulkan is premised on the concept of queues. Everything from drawing a unit, compute functions like AI, weather, and flight models, even memory operations. For many graphics operations assigning a queue family to a logical device (CPU/GPU) means the CPU doesn't have to do it, and as operations are sent to the command buffer, or some variation of primary/secondary buffer depending on how the developer chooses, but either way the command buffer can be built across theoretically (I think?) infinite cores. I don't pretend to be an expert on the topic, and I don't fully understand semaphores/fences aspect - basically devs handle app level threading and synchronization issues, but allowing multiple threads to create and submit commands in parallel is much more efficient in multi-core CPU. I will leave it at that because, again, I'm not read up on the tools devs have to manage the asynchronous computation issues, but I think we all agree that better multi-core utilization is good. While the biggest advantage is CPU utilization, for flight sims it may/should be better GPU efficiency as well. Flight sims tend to draw a lot of very similar objects, where loads consists of a large number of objects that do not require complex shading. Vulkan allows devs to adjust the number of worker threads and move rendering off the main thread for what hopefully will be a big performance boost for flight sims. If interested, here is a demo on vulkan rendering dozens of high poly helicopters with very low CPU overhead (hit v to disable v-sync). https://nvidia.app.box.com/s/rj9nzxkpz21qu34h8zew301kray9urbf The threaded fish demo allows you to change the number of schools displayed, and the number of worker threads to give a more interactive feel of the difference: http://developer.download.nvidia.com/mobile/shield/assets/ThreadedRenderingVk/ThreadedRenderingVk_20160707.zip I haven't heard ED say anything on point, but ray tracing is almost certainly in the long term plan. All ray tracing is, fundamentally, is simulating light exactly as it behaves. Landscapes are all about light, and a given DCS draw may have multiple tens of thousands of light sources. Not all light is visible, either. I've wondered if ray tracing wouldn't solve some of the challenges related to air to ground radar implementation - it is, essentially, built in real beam, and evidently pretty easy to add in Vulcan (supported down to 1070 cards now, I believe), and can be toggled on and off for those that do not have compatible cards. As they are meshing everything already, I suspect its in the plan, though probably not right away. We can hope though. Mesh demo here for those unfamiliar: ). My last point is VR. In addition to the above, games must move to either DX12 or Vulkan if they want to support variable rate shading. Unfortunately it is RTX only, so it to is probably a couple years aways, but VRS is the foundation for next gen VR. VRS allows developers to increase processing power/image quality applied to different areas of an image very quickly. This tech is a prerequisite of foveated rendering, which is simply eye tracking combined with VRS, maximizing image quality where you are looking, and decreasing quality where you are not. Reasonable expectations are key, we won't see double fps overnight. Its a change they will have to eventually make to keep up with the industry and be ready for next gen VR, and there is good reason to expect improved performance particularly for systems bottlenecked at the CPU. It should also free up resources to add more complexity elsewhere given the additional computation resources available. Last I heard the engine was done, or mostly done, and they were redoing textures and shaders. I don't know if they can just re-export objects or if everything must be rebuilt. Note also how all the cockpits/maps are being upgraded to mesh. It's been a while since I heard an ETA, so I hesitate to even say anything, but last i heard was early 2020. That said, not hating on ED, but the big downside to Vulkan is that with all the control it gives devs, its offers a ton of opportunity to screw things up. Development has been slow for everyone, and the No Man's Sky launch performance issues are probably going to be pretty common. So while it will be a good change, particularly in long run, I'd expect some rocky betas. Still, if you've had the chance to play NMS on a good system, you can extrapolate what's coming, which I think is worth being excited for.

Ya I’ve been curious since your comment about 3D printing what alternative process you would use. What did you end up doing?

As one with two in college rn, it makes me giggle that you think you will have more money when they leave

I liked the "we all suck" line personally...

Not sure where to start, but will try hard to be nice... As a general rule we are terrible pilots. We fly solo, employ atrocious intercept tactics, and rely on terrible AI to survive. I reckon 99% of players have no idea about what intercept quadrants and positional advantage are, how to plan an intercept for desired lateral separation, the relationship between aspect, ATA, cut, HCA, etc., much less how to plan an intercept to hit a desired employment point. No real pilot would commit against multiple bandits head on, allowing themselves to get within WEZ. FWIW there are exceptions. If you take the time to learn section BFM/SEM tactics, know first/second fighter roles, comm brevity, know the difference in your responsibility as the engaged fighter vs. free fighter, know how to keep your lift vector out of phase to set up a forward quarter shot if the engaged fighter can't employ after the first turn, there are groups with ex-pilots that fly that way... but it's a small group. To some extent you are correct, recent conflicts have involved unchallenged air dominance, strategic JDAM strikes and CAS missions. A-G is not the primary sensor in such missions but hardly irrelevant. Its hugely important for ship strikes, without radar the harpoon is basically useless. Even GT and GMT are likely more useful in DCS given the lack of civilian traffic. Ground radar is very good at picking up large metal things hidden in foliage that a tpod would miss. But with one exception, recent conflicts have not been large scale ground engagements with unprotected tank columns in the desert. That isn't really due to doctrine so much as the relative force capabilities, but i digress. A-G radar has a few other uses besides picking up 30000 ground units though. DBS and SAR are good examples given the types of missions we fly. We love tpods around here, even the gimped versions we have are nice for finding that JSOW target from 10nm out :lol:. SAR produces a lower resolution image than optical sensor, but it is all weather, limited in range only by the curvature of the earth and your altitude. And, as I said before, foliage that obscures hardened targets is penetrated by radar, making it particularly useful for producing an image from standoff range that can be shared via datalink for coordinated attack with SLAM-ERs without ever coming within range of that SA-10. Everyone seems to forget about AGR and CCIP accuracy, or TA for night low altitude. Neither of which suck. But honestly dude I don't know where to start on the psare 6-8 cores for ground unit AI. I am not going to drone on about the limitations of DX11, high overhead drivers, or the fact that the majority of DCS players don't have a "spare 8 cores." To wit I will just say that the devs will soon have the ability to better utilize multi core processors, it is among the principal drivers for the move to vulcan api. Be careful what you wish for, however. I hate to drone on about how bad we are, but we are. Given the lack of coordination, knowledge and skill, my confidence in our ability to engage and suppress a modern integrated air defense is approximately 0%. Are you volunteering to be the guy who spends his afternoon getting a few dozen guys organized, taking off, lining up to top off, launching four TALD decoys, spending 20 min in the stack, landing, then maybe launching to help refuel inbound? We can't all lob aim-54's from 40 miles out, for every strike mission there's 10 dudes launching decoys, and 5 or 6 refueling other Hornets. I'm not going to get into the development feasibility, I think is beyond the level of this thread. But your average DCS player would be pretty happy to have a 6700k. Good CPU, mine hit 4.9ghz and was damn near as good for gaming as my 9900k. Unfortunately, like most chips until very recently, it had only 4-cores... so that spare 6-8 might be an issue. Also, I seriously question your assertion that 1 core is enough for everything so use all the other cores for AI, but it's an irrelevant point. It also ignores the fact that you still have to draw those units, so its GPU resources are well. But again, irrelevant point. AG radar is taking a while, I'll give you that. So is TWS, AZ/EL, scan centering, bump acquisition, SCAN RAID, EXP modes, L&S stepping, spotlight, among others. We'd all like it faster but it is what it is, bitching isn't going to help, especially when we don't have a clue what we're talking about :music_whistling:

I've never tried an XTAL, I did receive a demo of a VR-1 earlier this year, though I didn't get to try their flight sim demo. IIRC XTAL is slightly less vertical resolution but huge FOV right? Anyway, as I said, I haven't tried it. I was floored by the VR-1 however. The resolution is the same as the index for the main screen, but there is another panel that's extremely high res. I don't recall the number, but they referred to it as human eye resolution... its thousands of DPI, which somehow is able to move with your eye via eye tracking (this wasn't perfect, it worked better if you moved your head). Anyway, it was pretty unreal - I mean, I don't know how to quantify "How much" better it was, but it's fair to say that its damn close to human eye level. This was before rift s, index, reverb, etc were announced. They won't sell them to consumers (they actually do a yearly licensing thing or you can buy it outright). I concocted an elaborate line of BS on how I was going to incorporate it into my business. I do beginner aerobatics training (err... stall and spin recovery training in case my insurance is reading this), and argued that sim time before actual unusual attitude training... anyway, i'm rambling. The point is I was ****ing impressed and wanted one. Stupid expensive, but i've worked hard right? Eventually came to my senses, probably good as I have no idea how I would have run it, and i was concerned about compatibility (its supposed to be fine in unity/unreal, DCS as we all know is different). Anyway - congrats man. I am jealous, i eventually talked myself out of it but you friggin dropped 5k on a HMD! I hope it turns out to be everything you hope it is! Pay no mind to the negative, we all spend money on stupid shit... its just a question of what your particular vice is. I own a money pit airplane that is the most impractical thing ever built. Some guys like cars or boats, other strippers and cocaine. To each their own btw - why the xtal over a VR-1 or one of the other pro level HMDs? Not suggesting one over the other, I honestly don't know all the differences

Yes, sorry, wasn't clear on that. Certainly contact your credit card company, report to authorities with jurisdiction, let others know what has happened, etc. I was merely addressing formal legal action. Without an attorney fees clause an international commercial dispute of $300 isn't plausible. Neither would $5 or $10k, for that matter. Fees add up fast. Certainly, though substantially more complex due to international jurisdiction issues. And, of course, a judgement is worth nothing if you cannot collect either because no local court has jurisdiction for a supplemental action or because the company is broke. I'm not saying it doesn't sting, it does. And I am certainly sympathetic - how far I took the thrustmaster thing is proof that I am just as susceptible as everyone. In fact, it's almost worse as I know better. In my defense, generally a threatening letter from the 1st named partner in the name of the firm makes most companies behave. I won't go into the backstory here, but a big part of my motivation was that if they were willing to handle my issue that way, presumably others would be treated worse. Regardless, I am sorry it happened to you. If you'd like, feel free to PM me. Perhaps I can offer some guidance with more detail.

What? Me? All I did was say Facebook sucks. How’s that fake news?

Well, I do not have all the facts to be fair, but what I would say is that unless there were some very extraordinary circumstances- a statute that was clearly violated that provided for attorney fees, punitive damage availability, or a large number of purchasers in the same circumstance to warrant class status then ya... you’re likely limited to what you can do by sending letters, lodging complains with local gov/bus. Authorities, regulators and review cites, and generally doing whatever legal things you can do to let potential customers know what’s going on. This is a small community and a niche product, a destroyed reputation will destroy the company. Perhaps if you’ve been ripped off, although you likely won’t get your money back, there is some solace in k owing you prevent the same from happening to others?

What state do u live in and where are they located? When was the order charged? What were the terms of purchase? Arb clauses or disclaimers that state delays are not tantamount to breach? Anything like that? How many people have been Ripped off? Does realtus have any money? Seems like they might be broke, and it’s day 1 of law school level stuff to not sue poor people/companies. I got real pissed at thrustmaster before, threatened to sue, letters on letterhead (I’m a named partner), more importantly I was 100% in the right and they were wrong. Even with opportunity cost as my only cost (no legal fees) once I cooled down it just wasn’t worth the time. I bought and returned a few to cover the time I didn’t have my throttle, sent a pithy letter to their board mocking their intent to target high end VR simulation players in the US by making best and most lifelike peripherals bavailable” and mocking the costs of reverse supply chain in e-commerce, and how that is made worse by shitty French customer support Rl;dr probably not real good

Word I’ll drop $800 on that beast of a throttle but I won’t use Facebook to do it!

Maybe that little birdy could post a quick "hey this is really nice" or "don't buy its crap" before taking the time to create a more typical thorough and well produced review. PMs are cool too tho

No worries sounds like we are on same page now. If you guys need more specific citation to how it works, what the controls are, how the symbology changes and such let me know.

This for me as well, this is the ‘critical clarity level,’ so to speak, for me where increased center screen resolution becomes less important relative to other factors (uniformity and FOV). I had a reverb here for about 5-days to compare side by side with index. The reverb is better in the center, for sure. However, index FOV is very noticeably better (vertically as well), and that clarity you describes extends nearly to the edge. That’s huge for me. It makes spotting better, it allows me to keep my head up outside the cockpit, and just glance down with my eyes to read a gauge. It’s not quite RL, where instrument rotations can be very fast, but it’s getting closer... and certainly the closest of the HMDs. IMHO of course

Perhaps its a sensor so that it can measure/report position to allow the in-game lever position to be updated? Completely guessing, seems unnecessary to me as well.... Thanks for the info, I’m sure their pcb will be properly designed and not l2c like the warthog. Deltasim did a great job working with the tools provided, but if you look at the output smoothness (and update frequency) of a VKB analogue on a MCG Pro, for instance, vs a modded warthog, it’s quite striking. You can see the steps on the WH output, it’s like really bad aliasing of a diagonal line. Even then though I wonder if they recognize how much demand their is on the throttle. If we could drop a $500 FS slew in there they’d literally sell dozens! Perhaps hundreds!

aight... I have unclean thoughts about that throttle but really do not need another stick. Have they released any technical info on the throttle besides the 20cm travel/hall sensor and swapable grips thing? Specifically -- Winwing Guy -- lots of us are going to probably but the preorder just for the throttle, please provide some detail. What sensor is used for slew? Radar altitude? I am curious about the texture as well given they are metal. But most importantly is that slew, and whether its user upgradeable, etc.

I scaled back my gpu, but haven’t the cpu. I got real lucky in the lottery though, I can game at 5.3 (prime95 will crash), at 5.1 I’m stable at stock. Plus, this only happens with DCS. Tried a bunch of different launching options and doesn’t seem to help. It does seem to come and go so I can play through it, but it’s definitely super annoying.

I’ve been fortunate and had no issues with Index/DCS thus far, other than never ending pursuit of perfect settings. Trying a few different approaches suggested here I suddenly had an unusual flicker, almost looks like black boxes shown for a single frame at different size and screen positions. As I was changing settings I assumed it was something I did, so I reinstalled steamvr, rolled back settings, etc... but it’s still there. Took a while to find someone with same problem but I found this hoggit post with video of the same issue: Responses aren’t encouraging other than it being a DCS issue (doesn’t happen in other games for me either. That post is old and I don’t see it being discussed, so I’m hoping this is a solved problem... so, anyone have a fix?

I am aware Santi, thanks. Not sure what you’re referring to about slew? The statement I was pointing out as in accurate related to scan centering in modes other than TWS (quoted below). Also note that the source I suggested is a US Navy website with public training material, generally not what most would consider dabbling in questionable info.

Well I think they got this one wrong. TDC depress short will center scan if azimuth is less than 140, TDC over .5s enters spotlight. The challenge, as always, is how to prove it without getting anyone in trouble. Radar operations is a lot easier than weapons though... I assume you guys are familiar with Virtual Mission Training System (VMTS)? It is a training system that emulates the APG-73. It’s training materials and syllabus are online (navy hosted), and might be helpful for anyone modeling the 73. Perhaps someone might look into pat pub p-820. Azimuth scan volume is adjusted at PB14 the same as in A/G mode. In addition to the azimuth indication above the pushbutton, the B-sweep, which is an indication of antenna position, will change as it travels across the display based on this selection, with 140 degrees providing full azimuth coverage. Anytime the azimuth selection is less than 140 degrees, the azimuth of the scan volume can be moved, as in the air-to-ground modes, by placing the cursor and the new desired center point and depressing TDC. The cursor in VS displays altitude coverage based analogous to an 80 NM display range. Scan volume options for bar scan, azimuth and scan centering via TDC action are similar to those in RWS. When the cursor is placed over a contact, the contact’s closing rate is displayed.

You should edit and take that down dude. Tried to pm but you have it disabled?

Are you sure 9line? I don’t have anything I can post handy but I believe all Cs and early supers have manual scan centering in all A/A modes, as well as map, sea, and gmt in the A/G suite. TWS is the only search mode with auto and bias options but is limited in search volume, whereas RWS scan center can’t be changed if azimuth is set to 140, but otherwise there are no scan volume/azimuth restriction. I haven’t looked but pretty sure there’s good public documentation on this, if not for the 72 then at least VMTS.

I don’t need another stick (sure I’ll figure out some way to use), but the few sources for a 11” travel hall sensor throttle are 2-3 times the full hotas price. Im considering picking this up mostly for the throttle, but I haven’t been following this thread or the developments. What’s going on? Looks like preorder still open but about to close, first units near ready to ship? Did they provide any technical details on the ministick? Like mfg or any detail? What about other buttons & toggles, or hall sensors? Is there a video of throttle mechanism similar to the gimbal one? *edit- also, what’s up with the panels? The one shown makes sense, but landing and combat ready? Are these replacements for the ops one? Or is landing the panel with anti skid/flaps/jettison controls and combat maybe master arm and AA/AG mode buttons? As in they can be used togaether?

hah sorry, i am wordy... in fairness, half the posts here are "how do i use autopilot?" so I try to explain things clearly. I will try to be less Bonanni-ish So, ironically, I think everyone is right. F-pole is just shooter to target range at weapon impact. F-pole maneuver is a thing I see on sim forums that describes a maneuver useful in a 1v1 head on engagement, of which cranking is a key element. DCS BVR is far too frequently 1v1 head on at 30nm. For various reasons (risk tolerance and mission design being foremost), these encounters generally proceed with both aircraft heading straight for each other, employing weapons, perhaps one for effect and another in range, with various attempts to evade. In RL, the other side has a mission and usually prefers not to engage you (dropping something that blows up). Similarly, if you're CAP or escort, you commit as a section, evaluate the intercept and maneuver to employ your weapons from outside bandits WEZ, to the extent you have time to do so. Tactical intercept is a far more interesting topic in these circumstances, but when that is not the case and you are a Navy of one, you've got the f-pole maneuver. As I have seen it is used here, it involves turning to increase Antenna Train Angle (ATA) to near max. Vc will decrease, and, if bandit turns to pursue, aspect will stay at or near 0. Change course as necessary are maintain ATA. You should have designated a L&S so you can monitor aspect (*tip - the points of the star represent different aspect angles, you should be able to quickly estimate to within 10 degrees). If target aspect increases then pause go read up on lateral separation and try to grab 40k or so, at 10-15nm change course to collision bearing (read about that too) and shoot. However, assuming he did turn, there are several videos describing how to do it in DCS better that I can write out. A quick search on youtube comes up with several examples, Jabbers has one .

Ray tracing and variable rate shading are not proprietary technologies. Ray tracing (aka ray casting) is just a rendering technique and has been around forever. Until recently it was limited to CGI but Nvidia turing architecture introduced real time ray tracing using the dedicated RT core but it's not proprietary. Next gen Radeon apparently has improved ray tracing performance. As an open world with hundreds of thousands of light sources where every surface is defined by how it interacts with light, that currently uses a aging deferred shading process that consumes disproportionate resources, they might want to look into it. Doom 2016 pipeline is the most well known vulkan/RT implementation, if you are curious and want to read up Variable Rate Shading is not optional at this point, not for a game with an emphasis on VR. Foveated rendering can't exist without dynamic shading rates. Unless a huge leap in GPU tech shows up in the next 12 months, devs had best be prepared to transition from DX11 style rasterizing. I haven't seen the quote you are referring to, but I assume they are talking APIs like unreal/unity, or to emphasize why they chose vulkan over dx12.