Inertial navigation can be used to know your location, that is using gyroscopes to measure acceleration from which you know where you are if you know where you started. Such systems get drift over time so they aren't perfectly accurate, but you usually dont steer that much, the spacecraft is launched with such a course that it will reach it's destination without much (or any) "steering".
Sounds like acceleration wouldn't be working on that card, I guess it's up to the drivers... Check the hardware acceleration slider from windows display properties on that card though, I think I once had that defaulted to none for some reason.
Yet another fantastic descriptive Microsoft error
It seems the right monitor device creation fails, you could check if games work with that device alone (Disable SoftTH and try a game which lets you select the display device, and see if it runs on that card).
I dont have a 8800 to test it with so I dont know... I suspect the 4096 pixel limitation is a Direct3D maximum too, but the only hardware I have to test it with is my 7900GT + 6200LE setup.
I guess that should work, SoftTH doesnt care(or even know) what kind of setup you have, as long as the displays and devices work in windows and support Direct3D with the features needed by SoftTH then any kind of setup should work.
A likely reason for the D3DERR_INVALIDCALL would be the resolution and refresh rate being not supported, but it could also mean a whole bunch of other things... If nothing seems to help you can get a better error description from direct3D by enabling the debug runtime & debug output. Unfortunately the only way I know to enable this is to install the DirectX SDK, the prodecure would go something like this:
- Download the DirectX Software Development Kit from microsoft and install it (~500MB download)
- After installing, go to start/microsoft directx sdk/directx utilities/direct3D control panel
- From the Direct3D tab set the debug output level to maximum and select to use the debug D3D runtime
- Get SysInternals DebugView and run it
- Run the game and let it fail, then look at the DebugView capture for the exact D3D error
If you do this, remember to set the retail runtime back and disable the debug output when you're done or you will get a quite large performance hit in D3D games.
- Download the DirectX Software Development Kit from microsoft and install it (~500MB download)
- After installing, go to start/microsoft directx sdk/directx utilities/direct3D control panel
- From the Direct3D tab set the debug output level to maximum and select to use the debug D3D runtime
- Get SysInternals DebugView and run it
- Run the game and let it fail, then look at the DebugView capture for the exact D3D error
If you do this, remember to set the retail runtime back and disable the debug output when you're done or you will get a quite large performance hit in D3D games.
I'd like a frozen lake track with snow in which you could plow your own track with the autocross editor
I dont think RBR even has any kind of cd check. No staforce or securom at least.
The rules were, if I remember right, that only problems that can be reproduced on any hardware setup are accepted. The problems SF causes are very hardware specific so it was just a rigged PR stunt. They even increased the prize money a week before the end of the "competition" to 10 000 dollars (before that it was 1000 I think), so they could say they offered 10 000.
The rules were, if I remember right, that only problems that can be reproduced on any hardware setup are accepted. The problems SF causes are very hardware specific so it was just a rigged PR stunt. They even increased the prize money a week before the end of the "competition" to 10 000 dollars (before that it was 1000 I think), so they could say they offered 10 000.
You cannot use a H-shifter on a properly simulated sequential gearbox. A sequential gearbox can only change one gear up or down at a time, with a H-shifter you can jump "over" gears like go directly from 6th to first gear. This is not possible with a sequential gearbox so you cannot use a H-shifter with a properly simulated sequential gearbox. And this should be coming soon so even if the H-shifter could be allowed right now (no proper gearbox simulation yet), you'd have to switch in the (near) future anyway when the improvement is made, so you might as well get used to it now.
Using different aspect ratios is not currently possible, it shouldn't be too hard to add but currently I'm more worried about compatibility with different games. Also, as mentioned already the maximum texture size limit of 4096 pixels is propably going to cause problems with a widescreen monitor as the middle one.
At least theoretically that should be enough for quite good framerates. PCI doesn't do good since it has both limited bandwidth (133MB/s theoretical) and it is a parallel bus meaning devices share the bandwidth with each other. AGP as the primary card is bad also since AGP is quite slow when moving data from the card to the system RAM - Something SoftTH needs to do alot. PCI express is a serial bus (All slots have their own bus), plus it is full duplex so even if the raw numbers might not seem much different, even at 1x speed on the secondary card it sould still be a major difference to a AGP+PCI combo, especially if the primary card is in a 16x slot.
I personally have both cards at 8x PCI-e slots, and this is the only setup I have tried it with so I dont know how it performs with lower speeds, but at least theoretically it should be ok - But if it doesn't work, not blame me but the people who wrote the specs
I paid 29e for the secondary GF6200LE I use, so its not a huge investment to try it out.This would also depend on video card settings, at least with nvidia drivers there is a setting to force triple buffering on/off and a 'max frames to render ahead' setting. Both of these should affect the 'lag', and games can request triple buffering too so the driver settings might affect one game but not another... Plus if a game uses OpenGL then the 'max frames to render ahead' setting for example does not do anything.
I just recently made something similar too, though my LEDs are just directly connected to the parallel port data pins with resistors in between. Since there's eight data pins you can have eight LEDs with this method, but it can be a bit risky if you dont have specifications for how much current your parallel port can source.
Here's a video of mine, I have it connected to my linux system with which controlling the parallel port is easy (And if it fries the motherboard it will be cheap to replace :P).
Here's a video of mine, I have it connected to my linux system with which controlling the parallel port is easy (And if it fries the motherboard it will be cheap to replace :P).
I mean it just opens a file handle to the HID device and writes 8 bytes of data to it. I guess the packet written is the 'raw' low-level method of doing the output reports, I found it by debugging the Momo racing centering fix utility - It does the same thing to set the LED states to defaults (for whatever reason).
If you are familiar with C, you could check out my MOMO LEDs source code, it has code for initializing a HID device (though it only uses filewrite to write data to it, but it should be easy to modify to your needs) and receiving data from OutGauge.
You can use the /B parameter with start.exe to run them all in the same terminal window, I use:
start /B LFSmomoLeds.exe
start /B s2smokemod.exe /autoquit
start /B s2slickmod.exe /autoquit
start /B LFS5DOF.exe
start /B LFSspotter.exe
Version for 0.5V has been on the site since yesterday
No they aren't, there is a certain level of 'animation' in it, done with a mipmap trick.
Only change I noticed when going from 4.40 to 5.0 with Momo Racing that the global 'combined pedals' option doesn't stay off. I have to now make a profile for every game to get it to stay off :slap:
And my Wingman Force is no longer supported by the profiler :slap:
And my Wingman Force is no longer supported by the profiler :slap:
It is the proper way, the way NFS etc. games do it is wrong (by blending the new frame over the previous one). For it to work properly though the FPS would need to be very high (think something like 200-1000fps maybe), and since LFS has an FPS limit of 100 it wont ever work very well.
Thats why the support for other codepages was added, plenty of letters there to use 
A bit of an old thread but I'll poss anyway...
While games, including LFS, do usually have multiple threads created, about 99% of games today only use one thread to do anything meaningful in terms of cpu usage.
In case of LFS for example, there's 11 threads created for me. But if you'll look at the CPU time taken by those threads, you'll see that over 99% of the CPU time is used by only one thread. This one thread does the physics, graphics, sound, input, etc. one after another. With this kind of setup you are not going to get anything useful out of a multi-core/SMP/SMT system for the game alone. While that single thread is, by default, switching between the cores/processors by the windows scheduler it will still never be executing in both cores in parallel because it is only one thread.
For a game to take advantage of multi-core, you'd need to separate major chunks of the game. For example in LFS you could separate the physics code from the graphics code, or handle the physics of each car in their own thread. But coding this to work (well) in a game is rather difficult, especially if the engine was not originally designed with this in mind.
While games, including LFS, do usually have multiple threads created, about 99% of games today only use one thread to do anything meaningful in terms of cpu usage.
In case of LFS for example, there's 11 threads created for me. But if you'll look at the CPU time taken by those threads, you'll see that over 99% of the CPU time is used by only one thread. This one thread does the physics, graphics, sound, input, etc. one after another. With this kind of setup you are not going to get anything useful out of a multi-core/SMP/SMT system for the game alone. While that single thread is, by default, switching between the cores/processors by the windows scheduler it will still never be executing in both cores in parallel because it is only one thread.
For a game to take advantage of multi-core, you'd need to separate major chunks of the game. For example in LFS you could separate the physics code from the graphics code, or handle the physics of each car in their own thread. But coding this to work (well) in a game is rather difficult, especially if the engine was not originally designed with this in mind.
FGED GREDG RDFGDR GSFDG