Well, it goes a little bit like this, if USB is being polled instead of being interrupt driven, the USB bus line is an extension of the CPU essentially, it doesn’t have a secondary processor to handle the overhead, transferring data to and from main memory. This can be done one of two ways, to continuously do a polling sequence (asking for data whether it’s there or not from a specific device) or wait for an interrupt driven event when you move the mouse or click it’s buttons, which is a more efficient way of doing things.
The problems I see on cross platform games coming from Microsoft Windows is that, either you get targeting lag, like we have here or the focus of the mouse gets lost and you lose control of the screen and pointer, often times making your view port look straight up. When you do regain control, you only get limited functionality on one plane, usually X, versus that of Y and Z. When you have X only your view will rotate in Y and Z space but can’t look away from where you’re stuck.
This is a glitch in the 3rd installed support libraries but not the actual GNU install libraries that come with your Linux system.
There is a difference between OpenGL and DirectX in the way they capture events with the input devices, such as the mouse and keyboard, especially that of the USB ports and device sitting on those ports, let alone if you’re using external hubs.
This bug only applies to 3-D space mind you, you might notice that it doesn’t affect you when logging into and when in hangar mode no how close or far your ships are away from you, whether or not you have Depth of Field (DOF) turned on or not.
The reason for this is simple, the interface you’re using is a 2-D overlaying 3-D models but the movement is in a locked format, not moving around freely in 3-D, the control is technically 2-D when in that.
The problem is when you have 2-D options, active modules for example, and you’re controlling both, 2-D and 3-D. If targeting is done correctly and you use interrupt driven USB calls, it shouldn’t freeze like this.
Put it this way, the CPU has enough to do; service all the different applications and operating system, handle data transfers that aren’t DMA based (there are quite a few of these on the main bus), of course service the game’s scheduler in a timely basis to make it appear that the game is reacting in real-time, which it technically isn’t but it’s more obvious to us with this problem.
Not all games use more than one CPU core, so having more than one core and not using a good smart threading model can cause lag like this. I am not blaming Star Gems, Inc., at all. Just stating there are alternatives to consider.
To Star Gems, Inc., please look into using OpenCL kernels instead for physics, this can be used on CPU but it can also be used in conjunction with the GP-GPU if your scheduler is written correctly for the game, it can share and throttle the performance on the card, making it a more smooth operation. Keeping the collision detection, correction (ping awareness) and accreditation (blow up ships) should be integer based and try to avoid using floating point operations for this.
Note about TCP/IP communications:
The most expensive, meaning more CPU cycles and time will be a TCP packet, good for trade, stores, and anything that needs to be accounted for.
UDP packets, are considered connectionless, come in two main flavors; order and unordered.
Ordered, has a bit of overhead but not nearly as much as a TCP connection, this is good to send this type of communication to the server at Star Gem, Inc., to update your location in 3-D space and for chat (including voice chat). You can actually salt or mark each packet going up to the server so it knows what client it’s coming from, to also prevent people from hacking you so easily (if there is a will, there is a way).
Unordered, is even less overhead than Ordered, same thing here, you can salt / mark these packets as to whom is supposed to receive and use them. Unordered is great for a server that has to deal with a lot of data coming in but needs to blast the packets out as soon as their processed, instead of trying to put them in a logical order like Ordered, it just marks the packets in such a way, that the intended client receives it, knows what other packets to look for and then assembles and uses them when they come in.
This can make the network connections to the server a bit snappier if it’s done right, also you in theory can have more users connected to a server if you select the traffic priority correctly. Login on TCP can be the lowest / queued priority, purchases can be in the queued as well, next is text based chat; low priority but not queued, voice chat can be set for normal priority (as it’s bursty in nature), the only thing that should have higher and highest priority is the 3-D positioning logic and communication, the absolute highest should be the DNS server resolution (finding the correct computer / server).
Want to know the logic here?
The threads and applications that send the most data should have the lowest amount of priority, then items that send the least amount of data should be a lot faster, as they do it more often in minimal bursts.
Of course you can run the UDP packets as encrypted on both sides of the client and server. This also makes it harder for ISPs to throttle traffic (also know as bandwidth shaping with limiting), so you would be doing people a favor putting this in.
Just take all of what I’ve said as a suggestion, Star Gems, Inc., it’s not a demand.
