Input has now become incredibly smooth. I've multithreaded the DirectInput code and cleaned up a lot of subtle little problems in it, some of which I was aware of and some of which I wasn't. I'm debating whether or not to provide an option to run non-multithreaded; right now it attempts to create the extra thread but falls back on non-multithreaded if it can't. Still fine-tuning aspects of it, in other words.
One of the problems with ID's original DirectInput code that I guess people should know about is that it also fires the regular Windows mouse messaging events even if DirectInput is enabled. You can verify this by commenting out the Key_Event calls in IN_MouseMove and running with -dinput.
I've also totally gutted the joystick and XBox 360 controller code. Decision isn't final, so let's see how many people howl to have them back. I guess something like enabling force feedback on a joystick would be a cool novelty effect, but is it actually an essential feature or is it chrome? Is it something you'd play with for 5 minutes, think "that's neat" and then turn off, or would you use it all the time?
I'm slowly working my way through the code doing something of an overhaul of the timers. I've posted on Inside 3D about the problems with floating point timers, specifically problems caused by loss of floating point precision. Switching absolutely everything to integer millisecond timers means that there is no precision loss, and timing totally tightens up and becomes rock solid, even at ultra-high framerates where precision errors accumulate really fast with floating point.
There are a handful of areas where the interface needs to be kept at floating point for legacy compatibility. One of them might be QC, although I suspect that it may be possible to change the relevant struct members to unions and fool the progs. The critical one is the svc_time message - with (most?) current protocols there is absolutely no way whatsoever around that one so you do need to degrade things there. The new protocol I'm working on for RMQ is going to use integer milliseconds for svc_time instead of floats, so it won't be an issue there.
clc_move uses floats too, but that's only used for sending ping times back to the server. I'll probably change it anyway as it seems to make sense and will give an accurate time back at the server in case it ever needs to use it.
Timing is a bitch.
There are also some problems in cases where r_wateralpha is set to less than 1; framerates can become quite jerky and uneven. I'm aware of it and it's on my list, but I haven't investigated in any real detail yet.
About to dive into MDL code soon. There are ways and means of accelerating this quite a bit by offloading some calculations from the CPU to the GPU. I've already got this working in a test engine and have confirmed that the full implementation, incorporating static vertex buffers for MDL data that doesn't change per frame (like indexes and texcoords) can go at about 4 times the speed of the current code. That's not going to happen now though as it doesn't play nice with the structure of the current code, and would actually slow things down instead pending a rewrite of some other things. I'll see how much extra performance I can get out of it though.
Overall things are looking a whole heap in better shape than 1.8.666b did. stay tuned.
Friday, October 15, 2010
Updates for Friday 15th October 2010
Posted by
mhquake
at
11:18 PM
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment