LoBiSoMeM
-
Posts
69 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by LoBiSoMeM
-
-
Well, IL2 certainly aren't "bordeline arcade". The solutions used in IL2 for make one sim with tons of flyable aircraft, ground units, great graphics (even for today parameters) and massive MP capability are a trade between performance and realistic sim.
It's unfair say that for a sim produced in 2001 and still great in 2009. "Basic stuff" can work in a sim for personal computers. Maybe is better have some "basic stuff" hidden than "complex stuff" hidden in gameplay, for performance issues.
IL2 still a software masterpiece! And with volumetric clouds and great overcast solution...
-
Actually, view distance might very well be CPU-centric. The terrain isn't just pretty pictures, after all, it's actual "hard" ground which must be tracked by a lot of parts in the simulator, like the physics engine etcetera.
Also, changing between medium and far isn't necessarily a small thing either. I don't quite recall the exact distances used in DCS, but compare these:
Short: 5km view distance, that means a 10x10 km grid needs loading. 100km² kept in memory and tracked by the CPU. (Remember, the GPU only shows the textures, it doesn't track whether there's units there, what they're doing and so on.)
Medium: 7.5 km view distance, that means a 15x15 km grid needs loading. 225km² kept in memory.
Long: 10km distance. 20x20 km loaded. 400km² in memory.
Now, again, I don't recall which actual distances were used in dcs, but rest assured that they're bigger than those, and since we are squaring we are actually getting four times the work from just doubling the distance.
Well, the collision meshes are computed whatever the view distance, or not? Maybe it can be "scenary compexity" dependent, but never "view distance dependent". I alway hear "DCS don't have processing bubbles"... So, all the units movement are processed on the fly in any view distance... With the collision meshes of the terrain and static objetcs.
In this scenario, the view distance setting is mostly GPU dependent, not CPU. The graphic engine is outdated. One exaple is the lousy performance in simple overcast conditions. And this drop in performance just for draw simple boxes and simple terrain mesh, I can't understand in 2009, with a 4xxx card with 512+ memory... Maybe some LOD work? I don't know, I can undestand losing performance with Shkval and ABRIS, but with some distant boxes rendered?
Sounds illogic to me. DCS:BS uses or not "bubbles"?
-
I like to fly the Ka-50 just for the amazing FM, for my lonely fun! Don't care so much with large AI groups, view distance, etc...
And fly IL2 for hours online, with great graphics and a lot of action... and with huge FPS!
In 2015, I will fly DCS:BS 1.0 with 200 FPS too! It's the sad life we nerds have: wait some years to have the hardware to run the software in all glory!
And in 2020, SoW: Battle Of Britain... :)
By the way, my GPU can handle much larger view distances. But the LockOn graphic engine maybe isn't so optimized, I don't know... And when I set far view distance, the FPS have a huge drop... And isn't a lot of CPU processing, the graphics ins DCS:BS are really simple, etc...
Need some work in this area for the next modules releases...
-
Possible solution could be some of the timeouts used in many PC DVD programs, perhaps? If cursor is untouched for 1 minute: hide it. As soon as you touch mouse again, make it visible. Though obviously that solution would be one for a future patch.
I think this option will be perfect, for all modes.
-
+1
I use a head tracking device too, and it's anoying have to click twice...
-
Just for Prophet:
http://www.cfar.umd.edu/~daniel/Site_2/Code.html
"All Code is Free for Download, Reuse, and Modification"
When you have pride of your "hard work", maybe you like to spread it with others, not use anti-competitive behavior and illegal commercial practices...
Please, don't post this kind of niilistic "reverse engineering" crap again... 6DOF HT is an available and free technology... it's 2009... the only thing really blocking the use of free and unified API for 6DOF HT in major sim games is the DESIRE to use it.
But in capitalism, money talks...
-
1
-
-
Its such a great day when someone reverse engineers your hard work to give it away for free!
:thumbup:
Again this crap?
People really don't know the meaning of "reverse engineering"...
Let's begin a technical discussion about HT technology, please? Will be really fun...
Please, read all, study, and come back to talk about "reverse engineering"... :thumbup:
Really... FreeTrack devs needed to "reverse engineering" all available free math in the world... Thanks God Descartes, Euler, etc didn't bother if someone used your "hard work" to make the life better...
-
I never undestand the "paradigm" of need to center the joystick after trimming to set the new trim or regain control of the shark.
We don't need to put bigger deadzones or fight against less precise input devices.
Just press the trim button when in the desired stable new trimmed position, and center the joystick with the trim button pressed. It's the best solution for joysticks without FFB: when you release the trim button, regain control and the trimmed position is the FIRST state when you pressed the trim button, not the last. If you are careless, you will have some "jumps" if release trim button far of center controls, but is better than explode on ground...
Ok, the "real Ka-50" meybe uses a logic more similar to the actual trim system, the actual trim system in ideal environment are very precise... But real Ka-50 pilots don't fly with simple joysticks with imprecise deadzones, old pots, loose springs...
This trim logic maybe work better for a lot of people. Deserves a try in my opinion.
-
Sugestion for a trim logic option:
- First position when press and hold trim button: set the new trimmed position for center stick+rudder.
- When release the trim button: regain control, without need to center the stick.
Simple.
-
DCS:BS case:
Infantry = cannon.
All other things = ATGM, rockets and cannon.
The russian and american rockets proved in all major modern conflicts to be weak against spread infantry. Maybe the damage model isn't realistic or precise, but the outcome of rockets attacks against infantry are.
-
... because there's absolutely no requirement for it to have them?
Not sure where you got the idea this was some sort of a requirement ... regardless, I'm sure the devs will look into it as I recall something about alternate APIs.
Never said full-range 6DOF HT APIs support is a "requirement".
But the reasons why this subject cannot be clearly discussed are a little bit obscure to me.
Why can't ED even talk about the POSSIBLE implement in DCS:BS of multiple 6DOF HT APIs? What is the technical problem?
I am one and know a lot of ED customers who will like this kind of support. We don't "require" nothing. We don't even need a flight simulator to live. We like it, we buy it.
ED needs to sell, but we don't need to buy. I think will be a great marketing policy maximize the support for 6DOF HT solutions. I know a lot of simmers with money to buy ED software but not so much to acquire expensive 6DOF solutions. They don't need more respect and support?
What really bothers in these freetrack discussions is the lack of information by the software companies. But I'm tired to discuss this. Just will post a link to some people know about the life beyond TrackIR, a little bit "home-made":
http://code.google.com/p/ehci/
If you like commercial aplications, try FaceAPI... Quad-cores, we can do that:
http://www.youtube.com/watch?v=7P7I7DOJJB0
Implement the "requirements" ED pretends to be necessary, not the customers requests... It's sooooooo dificult to put FreeTrack open-source API support in DCS:BS...
-
Where do you think sarcasm will get you? ;)
To the same utopic and fair place they are going:
http://www.antitrustinstitute.org/
:music_whistling:
Direct, pertinent and clear questions aren't answered by ED about why DCS:BS don't have support for other free-API options for 6DOF HT.
It's all a little bit sarcastic to me...
-
Don't work:(
Great job, ED. Thanks for the suport! :thumbup:
-
Someone using FreeTrack installed 1.01 patch and can do a report?
-
The few times it's hapenned to me I notice it generally tends to be when I am in auto hover, and have (accidentally or otherwise) trimmed in too much rudder, + am using auto-turn to target mode, and the shkval reticle slps out of the shkval fov.
Same here.
Is it an idiosincracy of Ka-50 AP function or some kind of bug? Auto-hover + auto-turn and target lock off shkavl fov sometimes disengage AP channels.
-
Amazing work. Now the manual is complete!
-
To make AP rounds effective, try to shoot closer and use the kinetic energy to (A)rmour (P)iercing the target.
HE rounds are much better far distances. AP and rockets are good, but need to get closer (in AP rounds case, MUCH closer).
-
I usually set the Weapons Mode Selector Switch to HNY (Fixed Cannon, Boresight) when firing unguided rockets and they can be fired with the "Space/Alt" trigger.
No need to do that. Try without change to HNY.
You will always fire unguided rockets to boresight.
-
I had to lower a bit my Y saturation due to older potentiometers and short movement path in my cheap Thrustmaster... It feels much better with 80%.
I really agree to avoid non-linear curves at all! Only must do that in "dying and totally descalibrated joystick" case!
-
ATI 4850 + 2048x1152 = good FPS, but nothing amazing... It's a really big resolution.
I have one X2 6000+ too, with 4GB RAM. In 1680X1050 with a weak 3850 I can get average 25-35 FPS.
Considerable shuttering only when some trigger load units. CPU isn't limiting your performace itself, but the combination 2048x1152 + ATI 4850 + X2 6000+ isn't a really high-end rig for 50+ stable FPS.
-
When I think "finally" myself, it lasts just a glance.
Because I go back to forum and see some new track or video of this guy above, and go back to practice... :D
-
For less money you could probably cobble together a seat-mover and write/repurpose your own software if you don't care about simulating vehicle movement and just want something that will bump you around.
I hope we can have this option for a long time... Because with 6DOF HT... :music_whistling:
Great idea and hardware. I don't think it's overpriced. It's a really cool, nice and complete package!
And with a good site, a lot of info!
-
The rockets are really meant to be used against infantry mostly, and other soft targets (destroying encampments etc).
The S-13 is an anti-bunker weapon and requires more precise operation, but on the other hand the targets also tend to be that much bigger.
Yes! With large and fixed targets, can engage far away and safe. But until S-8OFP2, the best I can do "by the book" against moving or little targets is near 1km "unsafe" distance with S-8 (like the example below)... larger distances = miss... I'll love the new toy!!! :thumbup:
-
Rocket attacks should be strafing attacks. Set'em up like that. 2500m is too close (minimum range for starting a run I would say) - start farther out, around 4km, then establish a normal flight path towards the targets at a controlled, steady airspeed.
500m is too close as well - you should be running in, launching at max range, then going away, not TOWARDS your target. I suppose this is certainly A technique rather than THE technique.
Further, misses with unguided weapons are certainly expected and acceptable.
Against large targets, dangerous targets or large groups of targets, that's the way to go! :thumbup:
But usually I can hit poorly this way. I like to use all my Vikhir, all my gun pods, all my cannon rounds and only use rockets against dangerous targets as last resource... tiny blast radius, need near a direct hit to cause considerably damage, need direct fly for a moment at least... In this kind of "desperate" cenario, or I get closer, try a "lucky shoot" with a bunch of rockets launch or just go away... I usually employ rockets against defenseless targets, and really close range. And it's fun!
Waiting for the patch and the "new rockets" with cool blast to kill some infantry and soft armoured targets! :)
Horrible frame rate with 1.0.1
in Bugs and Problems
Posted
Well, I don't think DCS:BS is so great "simulator" in many aspects, like damage model of ground units, AI aircraft FM, some weapons effects, etc.
I really like the Ka-50 FM, but we can cut the collective and make some "hard" maneuvers, exposing the "not so simulated" reality of the simulated reality. It's the life, we just can't sim all and have a decent performance.
In a combat sim based in real hardware, it's cool to have some realistic behavior in combat, tactics, visuals... and IL2 still great in provide the WWII air warfare feeling. We can use real tactics, and the amout of simulation in FM is enought to provide the need to use a realistic aproach in combat. We can read a book about AA combat in WWII and use it all in IL2.
The objective in IL2 is re-create the air combat dynamic of WWII, not re-create the perfect FM of one specific airplane of WWII. I never will call this "bordeline arcade". In full -real, with experienced human players, we need a lot of discipline, teamwork and real air combat tactics to just survive.
In DCS, we only have one module, with one flyable. And this flyable have a beutifull FM, perfect cockpit, real instruments. But it's not a simple flight sim, its "Digital Combat Simulator". We don't need the perfect FM, we need the "perfect" combat simulator.
And we just have a personal computer, not a mainframe... That's the real beauty of IL2: we can have the needed amout of realism to acomplish the immersive goal with an outstanding performance.
But the discussion is about the performance in BS after the patch. I can understand the problem about the "sim factor" in CPU aspects, FM, etc, not in eye candy, displays, GPU and view distance. DCS:BS uses the LockOn graphics engine, and it can't handle very well the actual needs.
Maybe in the next DCS modules we can have a newer and better graphic engine, DX10-11, etc.