First thing that comes to mind is to check if it's a problem with your local network. How is the latency if you ping your router or another device inside your LAN? Ping inside a small LAN should be 10 ms tops. You can also try rebooting your router...
It turns out that this is probably another bug in WINE because I can reproduce it even with a patched WINE where sudden jumps of time returned by timeGetTime() should not be a possibility.
However I found a bit more worrying behavior regarding time jumps. When such a jump occurs on a client's machine during online game, LFS appears to be frozen from the client's point of view for quite a while. From server's perspective the client's looks like it's lagging. When LFS copes with the jump, player's car is "released" in a more or less unpredictable state which could cause all sorts of accidents. The difference between this and a classic network lag is that in this case player has no control over his car, so the chances of him "respawning" on a very unfortunate place are much higher.
I realize that odds of this happening on Windows machines are rather remote, but perhaps the client should notify the server when it detects a time jump, giving the server a chance to spectate the client or something?
"Timer binding" seems to be working fine. LFS no longer freezes on abrupt time jumps backwards and InSim apps don't timeout when time jumps forward. However, all sounds go silent when such a jump takes place and the only way to get it back is to switch the sound off and on again with SHIFT+N (sound buffer reset?).
I can't find any list of FFB effects supported by the Rumblepad 2, perhaps the Logitech drivers somehow emulated the "constant force" effect (what LFS uses) with "rumble" effect (what the Rumblepad 2 certainly can do)...
I think it's very likely that your gamepad supports just a rumble FFB effect. LFS uses a more sophisticated way to generate FFB which I've never seen supported by a gamepad.
Perhaps instead of writing your own driver you could use PPJoy and create a virtual joystick that way. Alternatively you could use a proxy dinput8.dll, override GetDeviceState() and adjust input from mouse on the fly - this would be a rather obnoxious way to do this though.
As much as I love the idea of an open gaming console built on Android, I don't think this device qualifies as a gaming console. Why would I want a device that can play games designed to run on cell phones? The fact that it's powered by Tegra 3 doesn't seem to give programmers much breathing room.
Anyway, I wish them good luck, maybe we will get some actually competitive open console in the future...
You could make two Chrome launchers, one for your wife's profile and another for you. It's actually not that difficult.
- Add a new user profile in Wrench->Settings->Settings->Users/Add new user
- Create a new shortcut on the desktop pointing to something like "C:\Program Files (x86)\Google Chrome\chrome.exe --profile-directory="PROFILE_NAME"
Getting the profile name right is a bit tricky as Chrome expects its internal profile name here. You can find the profile name by looking into Chrome's configuration directory (I guess that on Windows its in C:\Users\username\Application Data\Chrome). You'll probably see directories named "Default" and "Profile 1" assuming that you added just one user. The "Default" profile should be the newly added one.
(BTW you might want to backup the config directory before you start experimenting with this just in case.)
CometBird is just another clone of Firefox and Maxthon 3 uses WebKit rendering engine so in its core its similar to Safari, reKonq or Chromium.
Isn't it kinda sad that when it comes to browsing the last bastion of freedom that has left you don't have much of a choice as to what you'll browse it with?
You could try deleting your FF profile and maybe do a clean install of FF 15. FF is arguably the least resource efficient browser out there, but despite that it's been working fine for me.
Unfortunately the is only a handful of "actual" browsers. Chrome (Chromium, Iron), Firefox (Waterfox, Palemoon), Opera and IE. Opera used to be a good browser back in the day, mainly because of its fast JavaScript interpreter and concurrent content downloading. Since other browsers have gotten better at these things too, its popularity has fallen because there's nothing special about it anymore.
I don't have any first hand experience with DFGT, but all the bits are there in the driver, so at least the native mode and FFB should work out of the box. I'm not sure about the separated pedals. I'd have to take a look at DFGT's HID descriptor, but even if it doesn't work right away, it should be fairly possible to fix it with a simple kernel patch.
Unfortunately I can't comment on GPL, but we've had no problems with WINE or games picking the tested wheels up.
The Z4 linked in the article appears to be a 2007 E85 with a 3.0 engine and its current price on eBay is 26k USD. 6k is not exactly a "little more" money than 20k, but if there were a 2.0 version for ~20k, I'd still take it over the Porsche. The Z4 is an every day sport(ish) car, whereas the 912E is something you'd drive to a high school reunion only to piss off your ex-GF's fianceé. +Z4 from me.
As an Arch Linux user you have the latest kernel 3.5 available (unless you're using some -lts version). Kernel 3.2 and above have support for Logitech gaming wheels (DFP, DFGT, G2x), kernel 3.5 even supports the LEDs on G27. If you're running such a kernel, you should not need LTWC anymore. If you run into any trouble, feel free to post it here...
I can't help you with the Lapper specifics, but the general idea is to calculate "sqrt( (Car1.X - Car2.X)^2 + (Car1.Y - Car2.Y)^2 )" - this is the distance between two points in 2D space.
I only skimmed over that article, but it looks like it was written by some kind of chimp who has no idea what he's actually doing.
To successfully overclock a CPU it is paramount to have an adequate cooling and a motherboard that supplies sufficient power to the CPU. Cheapo motherboards with no overclocking possibilities are not designed to do the latter. You'll very likely be pushing the limits of your MB's CPU power circuitry if you manage to overclock your CPU by more than a few MHz. This may cause the capacitors in the circuitry to age prematurely an - especially on an older motherboard - to fail altogether.
Your CPU had never been exactly a top-notch model. Even if you OC'ed it to 4 GHz or something it would be a no match for say i5-2500K, not to mention latest gen of i7's. I suggest you don't stress your HW for a doubtful benefit and rather plan to get a new rig at some point. OC'ing makes sense if you have a brand new machine and you want to squeeze every single bit of performance out of it, OC'ing a CPU in a 2+ years old machine won't make any meaningful difference.
This has been my plan all along, bans have to be categorized by the type of server where the user was banned (race, cruise, drag, ...) and the kind of offense (wrecking, spamming, foul language or comments, cheating, ...). Some custom data like a short comment or a link to a replay might be useful too in case someone would like to review a ban by hand. I'd certainly appreciate some input from the server admins here.
(BTW, there's also another thing to consider and that's the programmer's interest. Everybody has done some sort of client-server application, there's nothing new to it, it's all been explored and done. A custom peer-to-peer network is much more challenging to imagine and implement.)
Sure. As far as I understand it, GetTickCount() returns number of milliseconds since Windows booted. This is done by counting TSC (or another time source) ticks. According to MS documentation, it's safe do to (timeNow - timeBefore) which suggests that the time returned by this function can never go backwards.
All WINE implementations of GetTickCount() rely on NtQuerySystemTime(), so WINE simply stores the time when the wineserver started and returns (now - server_started_time). NtQuerySystemTime() in WINE uses gettimeofday() to get current time. The time returned by gettimeofday() is subject to adjustments by the user, so when you (or ntp client for instance) set the clock backwards, GetTickCount() returns a lower value than it's previous call. This is obviously incorrect and IMHO LFS shouldn't compensate for that.
I modified GetTickCount() implementation to use clock_gettime(CLOCK_MONOTONIC) which is guaranteed to never go backwards.
- I know that LFS probably uses timeGetTime(), but WINE doesn't make a difference between these two.
- GetTickCount() returns it's value as 32bit unsigned integer so it eventually loops each ~49,7 days. LFS dedi must probably deal with this somehow.