Holy crap! Never thought I'd actually get to use the £12 I prepaid ages ago. Guess I was wrong. 
Now while I agree that Rockingham by itself is probably not worth that, it's kind of ridiculous just how much people over-exaggerate the actual value of that amount of money respectively undervalue the worth of software in general. That's like a single restaurant visit. Seriously.
Now while I agree that Rockingham by itself is probably not worth that, it's kind of ridiculous just how much people over-exaggerate the actual value of that amount of money respectively undervalue the worth of software in general. That's like a single restaurant visit. Seriously.
Vertical Sync looks like the smoking gun here, as it is turned off when in windowed mode (AFAIK it only works when the application has exclusive access to the display device, i.e. when it's full screen). Are all your monitors the same model or do you run a mix of different monitors? Are your monitors 75Hz by chance? It kinda looks like EyeFinity respectively your graphics card somehow fails to sync across your three monitors, which in non-triple-buffered applications would result in a framerate of roughly 75/2 = 37.5 fps, assuming it fails to sync and skips every second frame (might just be coincidence, though).
That said, I'm not sure if something like that is even supposed to work, since VSync basically synchronizes your application's rendering with the hardware refresh rate of the monitor, which seems kinda impossible if you have multiple pieces of hardware (that are not specifically built for this purpose), especially if they're connected via different connectors (DVI, HDMI, DP, etc.). Maybe you can define the main monitor it should sync for, though, no idea.
But even more important, are you sure this is caused by 0.6H? What does your fullscreen framerate look like in 0.6G?
New Westhill is looking good 
Unfortunately I find it does not exactly counter that - the CSR's linearity setting is much more center focused, so you end up with a weird sensitivity progression over the steering range. But yes, 10-20 linearity does at least take the edge off the weird high-sensitivity center.
No, and it unfortunately never will. The G25 is missing a piece of hardware that is required for XBox controller authentication.
Also, don't be too disappointed. Steering is incredibly twitchy now and I don't like it tbh. Turn10 doesn't understand the word "linear" apparently:
Yessssss, finally! So glad I'm not getting Skyrim until mid next week, so this weekend will be full of FM4 awesomeness
E: Or not. Goddamnit Turn10 :grumpy:
Last edited by AndroidXP, .
It's quite a while since I've done anything with SlimDX to be honest, so I'm not quite sure what the current state of development is and which tutorials/samples there might be, but let's see if there's anything I still remember...
First, of course, you probably want to check the included samples in the SDK - there might not be anything force-feedback related, but it should at least get you started on reading joystick (=wheel) states. The SDK documentation can also be found online.
Then there's also GameDev.net plus the accompanying forums, which should be a good starting point for any searches. A quick Google search also brought up this, which, while not talking about wheels per se, might give you a hint or two on how to approach FF in SlimDX.
Another bookmark I could dig up is this blog of SlimDX' lead developer, which isn't really a tutorial site but might still be an interesting read for anything SlimDX in general.
Most of the time Google will be your best bet to figure things out, and unfortunately more often than not DirectX tutorials will be written for C++, as historically there has just not been that much demand for DX in .NET in the past. However, since SlimDX is, as the name suggests, a rather slim wrapper around the native DirectX calls, most of that code and especially the general methodology on how-to-do-DirectX is very similar to what you'll end up writing in C#. As long as reading C++ doesn't make you convulse uncontrollably, translating from one to the other should be doable without too much pain.
First, of course, you probably want to check the included samples in the SDK - there might not be anything force-feedback related, but it should at least get you started on reading joystick (=wheel) states. The SDK documentation can also be found online.
Then there's also GameDev.net plus the accompanying forums, which should be a good starting point for any searches. A quick Google search also brought up this, which, while not talking about wheels per se, might give you a hint or two on how to approach FF in SlimDX.
Another bookmark I could dig up is this blog of SlimDX' lead developer, which isn't really a tutorial site but might still be an interesting read for anything SlimDX in general.
Most of the time Google will be your best bet to figure things out, and unfortunately more often than not DirectX tutorials will be written for C++, as historically there has just not been that much demand for DX in .NET in the past. However, since SlimDX is, as the name suggests, a rather slim wrapper around the native DirectX calls, most of that code and especially the general methodology on how-to-do-DirectX is very similar to what you'll end up writing in C#. As long as reading C++ doesn't make you convulse uncontrollably, translating from one to the other should be doable without too much pain.
One thing I've always wondered, and I could be wrong, but is it just me or are the metric spring rates in Forza completely ludicrous?
They are supposedly given in kgf/mm, which as far as I understand it is the amount of force in kilograms you have to apply to the spring to compress it one millimetre. Now take the average car, put in the suspension upgrade so you can manipulate the spring strengths and lo and behold, a value of maybe ~80 is considered a somewhat stiff spring. Really?! That spring alone could hold up a 1.5 ton car with just 1.9cm (0.73in) of travel - and there's four of them in the car. Might as well put solid steel blocks inside at that point.
Now if those rates were kgf/10mm, or kgf/cm for that matter, that'd be a lot more realistic, but either I'm blind or I'm just not seeing it pointed out that you're entering values in 1/10th of the displayed unit. If you switch to imperial the values given in lbs/in look completely fine.
They are supposedly given in kgf/mm, which as far as I understand it is the amount of force in kilograms you have to apply to the spring to compress it one millimetre. Now take the average car, put in the suspension upgrade so you can manipulate the spring strengths and lo and behold, a value of maybe ~80 is considered a somewhat stiff spring. Really?! That spring alone could hold up a 1.5 ton car with just 1.9cm (0.73in) of travel - and there's four of them in the car. Might as well put solid steel blocks inside at that point.
Now if those rates were kgf/10mm, or kgf/cm for that matter, that'd be a lot more realistic, but either I'm blind or I'm just not seeing it pointed out that you're entering values in 1/10th of the displayed unit. If you switch to imperial the values given in lbs/in look completely fine.
What wheel settings are you using currently? Also I just recently noticed F3 has a tiny steering deadzone configured for wheels by default, which you should obviously get rid of if that's also the case in F4.
I actually found simulation steering quite pleasant to use
Especially compared to FM3's does-whatever-it-wants autosteer. Sure, it's still speed sensitive and a bit quirky on countersteering, but tbh I don't think you'd really be able to control the car if you'd always had the full wheel rotation mapped to the tiny analogue stick.
E: Current Zonda PB: 1:41.828, no controller aids apart from auto-clutch
Especially compared to FM3's does-whatever-it-wants autosteer. Sure, it's still speed sensitive and a bit quirky on countersteering, but tbh I don't think you'd really be able to control the car if you'd always had the full wheel rotation mapped to the tiny analogue stick.
E: Current Zonda PB: 1:41.828, no controller aids apart from auto-clutch
It's exactly as it should be. A hotter tyre has a bit more air pressure, causing the tyre to bulge (making it more donut-shaped), resulting in more load on the middle section.
Last edited by AndroidXP, .
Ah okay, my mistake.
I kinda figured an autocross stage replay should display the total finish time similar to the fastest time done for hotlap replays, because there can only be one car on track anyway, so displaying the time would make sense there contrary to "normal" replays with multiple participants.
Nevermind then
If you're not totally set on putting up with C++, and as you've mentioned possibly using .NET components, it might be worthwhile to consider using C# in conjunction with SlimDX instead.
In short, SlimDX is a thin wrapper framework for accessing DirectX through C# and is actively supported and updated by its creators to keep up with latest DirectX developments, unlike say, Managed DirectX which has been completely abandoned years ago, or XNA which only supports up to DX9 and has a more limited featureset due to being intended for XBox360 development. There has also been at least one commercial release of a SlimDX based game that I know of, so it's not a complete underdog
Unless using C++ is an integral part of your endeavour (if it is, you may ignore the rest of this post), using C# would allow you to avoid lots of unnecessary hurdles and let you concentrate on actually implementing the features/logic of whatever you're planning to do. Besides that, Visual Studio's support for C++ is, while not bad, certainly nowhere near the level of its support for C#, simply due to how difficult C++'s archaic language design makes things for IDE developers.
Performance shouldn't be a concern either - you're hardly going to be developing the next CryEngine anyway - jitted CLR code is plenty fast, as is the GC. Of course you have to look for different performance gotchas in such an environment, but from my experience with an (admittedly quite simple) 2D space shooter style game it's hardly the language itself causing the problem. With modern CPUs it's not about raw instruction counts anyway, rather it's about getting the data where it needs to be in a timely manner. Cache misses forcing you to access the (in comparison) agonizingly slow RAM are a much bigger concern than not having minute control over the generated assembly; a bad algorithm is going to be slow, no matter whether it's generated through the CLR or by yourself.
So anyway, that's my two slightly off-topic cents on this matter
E: Btw, there's no reason not to have VS 2003 and 2010 installed side by side - you're not breaking anything by doing so.
In short, SlimDX is a thin wrapper framework for accessing DirectX through C# and is actively supported and updated by its creators to keep up with latest DirectX developments, unlike say, Managed DirectX which has been completely abandoned years ago, or XNA which only supports up to DX9 and has a more limited featureset due to being intended for XBox360 development. There has also been at least one commercial release of a SlimDX based game that I know of, so it's not a complete underdog
Unless using C++ is an integral part of your endeavour (if it is, you may ignore the rest of this post), using C# would allow you to avoid lots of unnecessary hurdles and let you concentrate on actually implementing the features/logic of whatever you're planning to do. Besides that, Visual Studio's support for C++ is, while not bad, certainly nowhere near the level of its support for C#, simply due to how difficult C++'s archaic language design makes things for IDE developers.
Performance shouldn't be a concern either - you're hardly going to be developing the next CryEngine anyway - jitted CLR code is plenty fast, as is the GC. Of course you have to look for different performance gotchas in such an environment, but from my experience with an (admittedly quite simple) 2D space shooter style game it's hardly the language itself causing the problem. With modern CPUs it's not about raw instruction counts anyway, rather it's about getting the data where it needs to be in a timely manner. Cache misses forcing you to access the (in comparison) agonizingly slow RAM are a much bigger concern than not having minute control over the generated assembly; a bad algorithm is going to be slow, no matter whether it's generated through the CLR or by yourself.
So anyway, that's my two slightly off-topic cents on this matter
E: Btw, there's no reason not to have VS 2003 and 2010 installed side by side - you're not breaking anything by doing so.
What would probably make a lot more sense than all this MPR-combining would be an option to interpolate / smooth out MP replays during playback by utilizing the fact that you already know what happens in the future. That way you could at least get rid of the position update jumps and maybe even of temporary crashes and spins that didn't actually happen, without requiring you to somehow collect the replays of all players (which aren't 100% accurate for the player in question anyway).
The only downside to this is that the cars would sometimes float around a bit, ignoring actual vehicle physics in order to reach the next packet's position, though whether that is any worse than the current teleporting is debatable. I think at least for "live" streaming a smoothed-out-but-sometimes-a-little-fake display would look a lot better than what we have now.
The only downside to this is that the cars would sometimes float around a bit, ignoring actual vehicle physics in order to reach the next packet's position, though whether that is any worse than the current teleporting is debatable. I think at least for "live" streaming a smoothed-out-but-sometimes-a-little-fake display would look a lot better than what we have now.
Just make a copy of temp.mpr and check that.
Looks all normal to me.
Killercreation.co.uk is a server host, so you just had a normal LFS connection to a server hosted there.
Are you sure it's not Avast starting an update or scheduled scan? I think it should have the option to disable invasive scanning if a fullscreen app is active somewhere...
Maybe you could try running in windowed mode so you can easily see in the taskmanager what program is active/causing the slowdown once it happens.
Are you sure it's not Avast starting an update or scheduled scan? I think it should have the option to disable invasive scanning if a fullscreen app is active somewhere...
Maybe you could try running in windowed mode so you can easily see in the taskmanager what program is active/causing the slowdown once it happens.
Go to a hospital. They have lots.
Yep.
The forum's fine. What's up with you?
What makes you think the squat has anything to do with grip on the rear tyres? The only difference that helps squat vs. no squat would be a tiny CoG change and possibly some negative camber from the suspension compression, but the main factor - the weight - is just as much over the rear tyres, soft suspension or not.
I'd say if anything a stiff rear is causing the car to respond less well to throttle stabilization because it acts as anti-roll, preventing the front wheels to be lifted from the ground.
Last edited by AndroidXP, .
FGED GREDG RDFGDR GSFDG