Just want to mention that the antialias settings finally are working in my linux / wine setup using the nvidia driver. It seems that the dx9 change caused this. Before the patch I had to set antialias settings globally; the in-game settings had no visible effect...
Technically, with the /me command, the whole line (including the name) is the actual text/message, whereas with normal messages the name just tells others who is speaking. The "player name" doesn't really exist in the same way in /me messages - it's treated like any other word (colours removed).
I guess the "after player name" bit could be confusing, but InSim itself is behaving as expected IMO.
Fraps is notoriously delicate when it comes to games going in and out of fullscreen/changing resolution/alt-tabbing. I've heard many cases of it crashing/causing games to crash/stopping or corrupting the recording when you try it, or even when some games/engines (*cough*unity*cough*) change scenes.
It probably didn't happen in older versions of LFS because Fraps uses software capture for DX8 rather than directx hooks.
It may be possible for LFS to work around some of Fraps' failings, but I dunno if it's worth the bother - I guess Scawen can decide that one.
FWIW, OBS can handle LFS going in and out of fullscreen, changing resolutions, changing monitors or even completely closing down and starting again with no problems at all. Even when using Game Capture mode (DX hooks, not software mode).
Starting grid Blackwood GP, 20th position, 20 AI
36fps using LFS 06E, all settings max, mip bias defaults.
33fps using LFS_6E14 same settings.
32fps using LFS_6E14 Mirror AA enabled.
Starting grid South City Classic, 20th position, 20 AI
28 fps using LFS 06E, all settings max, mip bias defaults.
27 fps using LFS_06E14 same settings.
26 fps using LFS_06E14 Mirror AA enabled.
So, about a 10% frame rate drop in low FPS conditions. Mirrors look great though!
I should point out, my rig appears to be CPU limited, not GPU. One core maxes out during LFS. So Dx9 might take more CPU than DX8. For GPU limited rigs, maybe DX9 is faster?
I've looked in the code because the crash address is in LFS. It seems to be where it is getting the surface of a non-antialiased render target texture (e.g. dash texture or mirrors if aa is off) ready to set it as the current render target.
Why that could crash, I don't know. LFS releases the render target textures before resizing, and recreates them after the resize is complete (and always has done so, also in DX8).
I'm not certain but it looks as if this bug is happening after the resize has occurred, which means that the pointer to a D3D texture that LFS holds is no longer valid. Could it be that Fraps interferes with LFS's textures in some unexpected way? I don't really have a reason to blame Fraps other than that LFS doesn't seems to be crashing without it, and what Degats said.
I cannot run E14 at all, as soon as i try to open it i get.
"The program can't start because d3dx9_43.dll is missing form your computer. Try reinstalling the program to fix this problem."
Im on a fresh install of win7x64 ultimate, directx is fully upto date (dx11.1) and ive tried to manually install the newest update from the MS website but it says the update is already installed.
Scawen, what about checker if adequate DX runtime is installed?
Dialog like "Looks like you should update DX...". And buttons update (brings you to MS page with download), run LFS anyway, ...
all i can find to do is ensure that my directx is fully up to date, which it is, i have dx11 which is 2 versions never than dx9, so why would i need 9? and to make sure that video card drivers are up to date, which they also are.
Ahh ok, my bad, i was presuming that a newer version would automatically include aspects and features of the older versions by default, as that seems logical, but i see it doesnt, thanks guys, all working now
AFAIK, the jumpyness of keyboard drivers is because of the low packet rate. LFS uses prediction to make movement seem smooth, which works pretty well for analog inputs, as it takes time for the inputs to change.
Keyboard (especially Kn) inputs tend to be much faster and at any one time don't really represent where the driver intends the car to go. By the time the next packet arrives 167 - 250ms plus network latency later, the prediction can be quite far out.
These files may be available here:
C:\Users\petern\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_LFS_6E14.exe_b433b06a805affd6a3de7a089527ae0d4dfcb9e_1b86c502
Other than the exception code (which is rather generic) I don't see a connection, and the fault offset is different. However I just enabled dx9 debugging (apparently it is doing something on Windows 7 now... what the heck?) and got this:
[5716] Direct3D9: (ERROR) :Lost due to display uniqueness change
[5716] Direct3D9: (INFO) DI threading stopped
[5716] Direct3D9: oneExclusiveMode
[5716] Direct3D9: (ERROR) :Exclusive Mode has been taken by other app or other device on the same adapter. SetCooperativeLevel returns D3DERR_DEVICELOST.
[5716] Direct3D9: (ERROR) :SetCooperativeLevel returned failure. CreateDevice/Reset Failed
[5716] Direct3D9: (ERROR) :ResetEx failed and ResetEx/TestCooperativeLevel/Release are the only legal APIs to be called subsequently
[5716] Direct3D9: (ERROR) evice is in an invalid state. Only Reset, TestCooperativeLevel, CheckDeviceState or Release could be called
... Lots of the last message repeated then ...
[5716] Direct3D9: :====> ENTER: DLLMAIN(583dd9a0): Process Detach 00001654, tid=000017dc
Thanks for the detailed debug info about that crash. I guess with that I should be able to sort it out. If needed, I'll come back to ask for more info. I wonder if anyone can enable DX9 debugging and get an error log with the Fraps crash?
I did try that before in Windows 7 but was unable to get any kind of debug output. Selecting the debug version as shown in those instructions had no effect. Also, closing that control panel and opening it again, it was always switched back to the retail version. Other people tested and got the same result. So it is amazing that PeterN has now got debug output. Was there a Windows 7 patch that enabled DX9 debugging again? Peter, which version of Windows were you using?
I think it had something to do with running 32 vs 64bit versions of Windows 7, as I'm on 64bit and you were on 32bit. On the other hand, LFS wasn't DX9-native then either.
Some might say it uses much more GPU, I agree on that, but if my 2-3y GPU can handle it... why not? Setting MSAA in drivers is quite buggy when using SHIFT+F4, official would be better
The reason for no D3D debug output in Windows 7 is the Platform Update which had been released via Windows Update some months ago. It lifted the DirectX Graphics Infrastructure and DirectWrite to Windows 8 level, but sadly it disabled debug output for any D3D 9 version before the current Windows 8 SDK (which I suspect is useless for you because there is no XP compatibility). If you want to get your debug output back without moving to Windows 8, either try to uninstall the platform update or reformat your system and install Windows 7 SP1 without Updates. There may be a way to remove the Update, but that's a risky thing always.
I'm having the same issue here For more information, see http://support.microsoft.com/kb/2670838/en-us : "If you are a Windows 7 DirectX developer who uses the June 2010 DirectX Software Development Kit (SDK), you'll have to update your development environments after you install this platform update."
(I didn't have the time to read through the whole two threads, so sorry if I'm repeating something here.)
For more information, see http://support.microsoft.com/kb/2670838/en-us : "If you are a Windows 7 DirectX developer who uses the June 2010 DirectX Software Development Kit (SDK), you'll have to update your development environments after you install this platform update."