By the sound of it the new KITT actually morphs from a stock GT500 to the all black, stupid looking thing... through a vague "nanotech" apparently. Any excuse to use some expensive CGI and technobabble that adds absolutely nothing to the story, right? :rolleyes:
Tried changing it and that's only the selection colour. What I'm after is the colour behind toolbars and on menus in "legacy" windows applications. (see attachment)
Okay, how about this? An airplane is easier to get "roughly right" than a car physics wise. That's why you saw reasonably accurate flight simulators appear before you saw the same in racing simulators. Once you start going into that kind of detail though, none of them are easy problems.
Wireless really isn't very good for gaming. If possible, try to plug your computer in while playing. Turning off any downloading and other stuff using bandwidth is also the best thing to do.
You can usually see if you're lagging though. If all other players look like they are jumping around, it's probably you that's the problem. If you only see one player lagging on the server, he/she is probably the problem. You can also check the lag bars in the lower left corner. If your bar (green) is taller than all the others you're probably lagging.
Yeah, reading that paragraph as a rule against passing on a license to another user seems like a somewhat creative interpretation. That's certainly not how I read it, though IANAL.
Sounds good. I'm currently downloading it via Bittorrent (why couldn't they just release it on WU? It's already gone out for manufacturing...) and most of what you mentioned is what currently annoys me about Vista. A few more driver revisions from ATI and it might actually become somewhat decent.
The only thing missing now is an option for changing that damn baby-blue toolbar/menu colour in Aero. Why on earth would they hard-code something like that?
Yeah, we have one of those too. Not that it actually works or anything. The bastards sure call me all the time regardless. I've just stopped answering the phone when I recognise one of their numbers. I really should start doing some pranks instead.
Yeah, I do like the grittyness of the FFB. I can't help but think it's just a bit of noise added to the "real" output from the physics engine though. The tracks can't really be modelled with that kind of fidelity, so I just have to assume the grittyness is added after the fact. Either that, or there's some noise added at the tyre physics stage to simulate the roughness of the tarmack, which would be a good thing I guess.
Core 2 Q6600 @ 3GHz, 4GB memory and a Radeon HD3850... Could be an ATI thing. I get these strange FPS drops when for instance crossing the first hill at Aviano. It's big enough to annoy me, but still playable. Steering lag is also a lot more prominent than in LFS and gets worse when the above mentioned FPS drop happens, but still a lot better than on my old computer.
EDIT: Upon further inspection the FPS drop happens at random intervals as I drive. It's not at a specific point around the track. FPS drops from a steady 300+ down to ~40 (according to FRAPS) for a few seconds and then goes back up.
Quite possible. Never did try to turn them off as FPS was okay once it stopped fluctuating. Anyway, that computer is in a box in the basement so it doesn't really matter any more. Not that it's running shockingly well on my new one...
I guess that's where the sticking point is for me. Having another dependency to modify when I change something around. Even if I just end up throwing the test away I've in a way wasted the time I spent writing it.
I know it's just me being lazy, but maintaining tests does feel like a bit of a chore for the majority of the projects I work on (mostly simple web work these days). I'm considering if for one of my larger hobby projects though (game engine), but I'm still not sure it's worth it there as the entire thing gets rewired every couple of months.
Having seen the other end of the stick, yes you probably are. I can't describe how poorly nK ran on my old rig (Athlon XP 3000+, 1GB memory and a Radeon 9800 PRO, well within minimum requirements). I had in the region of 0.3 seconds of steering lag, which made any kind of driving more of less impossible. Add to that unstable FPS, crashing and the horrible online experience and you start to get the picture.
But don't you find yourself running around adapting your tests if you need to refactor some class hierarchies or something high level like that. It's easy enough when the overall design is more or less locked down and you have to refactor the implementations of functions and classes, but I sometimes find myself changing both design and implementation around and that's when I feel the tests are in my way more that helping me.
To be a little bit more explicit than Wikipedia; if you have a function doing addition for instance, you write a unit test to make sure the function does indeed return 5 if you pass 2 and 3 to it.
So that's how it works. All the spam posts on slashdot suddenly start to make sense. This is basically a site tailor made to encourage link spamming (all the while filling the pockets of the guys behind it with ad money)?
The idea is so utterly brilliant and enragingly annoying, all at the same time. I'm torn...
Yeah it does seem a bit cold, but I totally believe him when he says he was in control. He saw the guy, calculated his and his own speed, and then turned over juuust enough that he didn't hit him or lose too much time.
The likes of Colin McRae would probably have done a huuge powerslide around the gendarme, scaring him into a ball, all the while looking awesomely spectacular. Loeb is efficient.
Yep. I find I'm having a hard time doing it when the project is a bit more fluid. When the overall design isn't obvious from the start and when the requirements change during development (which is most of the time ). In these cases you end up having to change both the code and the tests every time you make a change and that feels wasteful.
Used Boost.Test when working on a Unicode library i did for my Bachelor's degree. When working against a spec like that unit testing is invaluable. When implementing some of the algorithms outlined in the spec we basically wrote the tests first and then started writing the algorithms. Being able to quickly throw something together and then just test to see if we got it right saved us so much time and effort. It's quite a motivational factor too as you have a clear cut goal to work against, and you always see yourself progressing as more and more test cases come out valid. The tests also helped us a lot in identifying a few strange bugs only apparent on one platform.
These days I don't unit test as much as I used to. I keep telling myself it's a waste of time, even though I know it really isn't. It's too easy to get lazy about stuff like that.
If you're thinking of Team Fortress 2 (which isn't really similar CS BTW), it has nothing of the sort. It has randomised starting positions on one of the bigger maps. The map itself is completely static and modelled by hand.