More like 4% on DX9 hardware or lower.*
Targeting DX11 (and not 9) would probably still mean the game should work on DX10 hardware, just without the DX11 pretty (or some of it running in software, I dunno how DX fallback works these days).
Either way, there's not a lot of point aiming for optional DX11 components in the near future. DX9c/Shader Model 3 would be a much bigger step than tessellation IMO, and should take a lot less effort to target. Also, you are correct in that 37% can't run the DX11 specific features anyway (but the game would still run for 90-96% if those features are optional).
*Legend:
63.45% - DX11 GPU; Win8/7/Vista
26.31% - DX10 GPU; Win8/7/Vista
6.38% - DX10/11; WinXP
1.57/.99/.28%; DX9b+9c/DX9+9a/DX<=8
If you add up the legend, you get 89.76% fully DX10/11 capable, a further 6.38% are running DX10/11 hardware on XP (which is most of the XP userbase).
That leaves <4% on DX9 or lower hardware.
Yeah, I wasn't suggesting Scawen rushed into DX11, I was just making some (hopefully useful) points if he, or anyone else, decides to do it at some point.
As far as LFS goes - it's amazing what DX9 shaders can do...
As far as LFS goes - it's amazing what DX9 shaders can do...
AFAIK (from random Internet research - I could be wrong) you can target/fall back to a reduced D3D9 feature set in D3D11 for hardware compatibility (albeit limited - shader model 2? probably targeting the original D3D9 rather than 9c which had newer shaders).
However, I believe that's still actually running DX11 software and you'll have the OS/driver requirements/restrictions associated with it - ie still no XP.
AFAIK to run on XP, the program itself needs to link to D3D9 instead (D3D11 can't fall back to anything if D3D11 can't even run) and only link to D3D11 if it's present for the shiny new features.
From what I've read, you only need link (at runtime) to whichever version; there's no need to have two separate compiles.
As Becky Rose said, if you design for D3D9 by default and only in D3D11 for specific features to give an (optional) extra level of pretty, it should be much more straightforward to maintain compatibility.
However, I believe that's still actually running DX11 software and you'll have the OS/driver requirements/restrictions associated with it - ie still no XP.
AFAIK to run on XP, the program itself needs to link to D3D9 instead (D3D11 can't fall back to anything if D3D11 can't even run) and only link to D3D11 if it's present for the shiny new features.
From what I've read, you only need link (at runtime) to whichever version; there's no need to have two separate compiles.
As Becky Rose said, if you design for D3D9 by default and only in D3D11 for specific features to give an (optional) extra level of pretty, it should be much more straightforward to maintain compatibility.
80, Chris McElroy, Degats, [TC] Racing
Last edited by Degats, .
The latest development version is the 'HD' Rift, with a much more useful resolution (probably 1080p).
80, Chris McElroy, Degats, [TC] Racing
80, Chris McElroy, Degats, [TC] Racing
insim.txt:
Bold+underline'd is the info you need to send.
In InSim.NET, SubT is implemented as an enum in ButtonFunction.cs
Again, I've never used InSim.NET before, but from a quick glance at the code and documentation, I assume you'd do something like this:
// To delete one button or clear all buttons, send this packet :
struct IS_BFN // Button FunctioN - delete buttons / receive button requests
{
byte Size; // 8
byte Type; // ISP_BFN
byte ReqI; // 0
[U][B]byte SubT;[/B][/U] // subtype, from BFN_ enumeration (see below)
[U][B]byte UCID;[/B][/U] // connection to send to or from (0 = local / 255 = all)
[B] [U]byte ClickID;[/U][/B] // ID of button to delete (if SubT is BFN_DEL_BTN)
byte Inst; // used internally by InSim
byte Sp3;
};
enum // the fourth byte of IS_BFN packets is one of these
{
[B][U]BFN_DEL_BTN[/U][/B], // 0 - instruction : delete one button (must set ClickID)
BFN_CLEAR, // 1 - instruction : clear all buttons made by this insim instance
BFN_USER_CLEAR, // 2 - info : user cleared this insim instance's buttons
BFN_REQUEST, // 3 - user request : SHIFT+B or SHIFT+I - request for buttons
};Bold+underline'd is the info you need to send.
In InSim.NET, SubT is implemented as an enum in ButtonFunction.cs
Again, I've never used InSim.NET before, but from a quick glance at the code and documentation, I assume you'd do something like this:
insim.Send(new IS_BFN{
UCID = <ucid>,
ClickID = <clickid>,
SubT = ButtonFunction.BFN_DEL_BTN,
});Since InSim v5 if you set the UCID to 255 in a IS_MTC (Message To Connection) packet, it will send the message to all players. No need to use foreach etc, it can be done with one packet.
I've never used this library before, but I assume this would work:
I've never used this library before, but I assume this would work:
void MessageToAll(string Message)
{
MessageToUCID(255, Message);
}
In the race results, some of the finishing positions are wrong (two people shown as 18th, no-one shown as 21st), as are the points from 18th/19th and below (120pts was skipped).
Looks like this has also affected the championship standings spreadsheet.
Looks like this has also affected the championship standings spreadsheet.
80, Chris McElroy, Degats, [TC] Racing
Agreed, the setup can make a big difference to how easy it is to get lift-off oversteer.
I have a few FXO sets where, if you get the timing right, you can pretty easily get round mid-high speed corners with almost zero steering input.
Some other setups have so much understeer, you've almost got to give it a Scandinavian Flick to get round some corners.
I have a few FXO sets where, if you get the timing right, you can pretty easily get round mid-high speed corners with almost zero steering input.
Some other setups have so much understeer, you've almost got to give it a Scandinavian Flick to get round some corners.
Also, GMT is the same as UTC (give or take a couple of seconds)
080, Chris McElroy, Degats, [TC] Racing
Your Name: Chris McElroy
Your LFS Username: Degats
Team Name: [TC] Racing
Driver Number: 80
Car Selection: XRG
Nationality: England
Your LFS Username: Degats
Team Name: [TC] Racing
Driver Number: 80
Car Selection: XRG
Nationality: England
083, Chris McElroy, Degats, [TC] Racing
Withdrawing, Pete's net is still acting up :/
"N.6
... For these incidents the same procedure as described in Rule M.1.1 will be applied."
Presumably this should be "N.1.1"?
... For these incidents the same procedure as described in Rule M.1.1 will be applied."
Presumably this should be "N.1.1"?
Thanks for the clarification.
I guess Rifo's ISP must be treating the new networking code differently to before or something - something, somewhere seems to have changed as a result of the new version to prevent him from sending position packets.
He's tried disabling all firewalls and setting DMZ on the router, so it seems the problem is definitely at the ISP end.
For me, at least, I know that the problem is my router.
Is that still the case while the temporary master/web server is running? (I can't remember what the exact error message was while the temporary servers were running a few weeks ago)
In which case, I'd appreciate it if you take a look into this problem: http://www.lfsforum.net/showthread.php?t=81519
I'm not sure if it's strictly speaking a bug, but it's certainly unintended and/or unexpected behaviour, which is preventing at least two people from playing online.
I'll summarise the issue here:
When the client enables TCP mode for position updates, the positions of other cars are received over TCP as expected. However the client still sends its own position packets over UDP. This means that if there are UDP transmission problems, while the player can connect and stay connected to a server, his/her position packets never reach the server.
I've been able to confirm this issue myself when my iffy router occasionally decides to drop UDP for a few minutes.
I'm told that in previous versions, position packets were correctly sent both ways over TCP when in TCP mode.
FGED GREDG RDFGDR GSFDG