The online racing simulator
Searching in All forums
(948 results)
AndroidXP
S3 licensed
Holy crap! Never thought I'd actually get to use the £12 I prepaid ages ago. Guess I was wrong. Smile

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.
AndroidXP
S3 licensed
Quote from Papa :Not systematically. But my first try to get some "driveable" frame rate back was lowering all settings including AA to very low or even lowest values. The frame rate increased only by around 15-20 FPS. Not sure about toggling vertical sync on/off either. I might test it again though.

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. Shrug

But even more important, are you sure this is caused by 0.6H? What does your fullscreen framerate look like in 0.6G?
AndroidXP
S3 licensed
New Westhill is looking good Tilt
AndroidXP
S3 licensed
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.
AndroidXP
S3 licensed
Quote from MAGGOT :Has a patch for the Xbox come out allowing use of a G25?

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:
AndroidXP
S3 licensed
Quote from JJ72 :a patch has just come out that fixed the 900 sterring aid issue, it feels entirely different while oversteering !

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, .
AndroidXP
S3 licensed
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.
AndroidXP
S3 licensed
Just as a sidenote, Managed DirectX is pretty much completely obsolete and has been discontinued by Microsoft years ago.

I'd recommend either using the XNA Framework or SlimDX for a modern take on DirectX via C#
AndroidXP
S3 licensed
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.
AndroidXP
S3 licensed
Quote from Hyperactive :Better than eating gold plated bacon! Very positively impressed. My first impressions are really really good!

Only things needing fixing is the steering and the lack of look left/right buttons.

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.
AndroidXP
S3 licensed
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
AndroidXP
S3 licensed
AndroidXP
S3 licensed
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, .
AndroidXP
S3 licensed
Quote from Scawen :You mean as it is displayed on the replay selection screen when you click on the replay? I think that has always showed the length of the replay, not the race time of anyone who was in the race.

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
AndroidXP
S3 licensed
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.
AndroidXP
S3 licensed
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.
AndroidXP
S3 licensed
Read. Comprehend. Post.
AndroidXP
S3 licensed
Just make a copy of temp.mpr and check that.
AndroidXP
S3 licensed
Looks all normal to me.
AndroidXP
S3 licensed
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.
AndroidXP
S3 licensed
Go to a hospital. They have lots.
AndroidXP
S3 licensed
The forum's fine. What's up with you?
AndroidXP
S3 licensed
Quote from legoflamb :I don't mean to turn this into a setups thread, but if the rear suspension is stiff, the rear end will not squat enough to supply more grip to the rear tires. This is caused by the linear gain of the spring constant over the distance of travel.

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