Thank you for reading this post.

M$ released a game http://www.microsoft.com/games/allegiance/home.htm around the turn of the century and stopped supporting it. They have since released the source code and it has been kept alive by a volunteer community of devs.

Recently there was a change from the previous Dx version used, to Dx9. I believe this change is causing widespread controller input issues in our gaming community. I'm not a coder and don't have enough experience to really get to the core of this problem, but from what I've gathered from my prodding/probing is that Dx9 is faster? than the previous Dx version and because of this change, controller inputs are now increased?.

For example, the throttle of ships can be changed by the +/- keyboard keys but now with the Dx9 version change, the slightest touch of those keys yield huge changes in throttle. I first noticed this in my joystick. It is more sensitive than before and feels mushy. When launching the game, the mouse sensitivity increases considerably and thus far, I can't get a clear answer from our devs as to what the hell happened.

I apologize for this vague description of a problem I cannot fix. I am simply looking for a laymans explanation as to what the likely cause of this is. Our dev team is being very hush hush about this subject and have avoided direct questioning from our gaming community. I believe they're trying to create workarounds to a problem so great that it would require a re-write of the software from ground up, to fix.

There have been mentions that the increased framerate or "optimizations" of Dx9 is responsible, but I haven't enough of my head wrapped around that concept to understand. I am crusading for the game community to get to the bottom of this so we can force a revert to a previous version of this game instead of letting it continue with an irreversable flaw.

Any insight into this would be greatly appreciated. The site where development is managed is TRAC http://trac.alleg.net

Thanks in advance for your reply.

If a developer investigated the problem and posted technical details here, maybe someone could help.

Changing which APIs a game uses is not something to be done lightly. You have to re-test everything thoroughly and fix anything that breaks. Different APIs have different underlying behavior for a wide variety of reasons. Developers should understand and expect this.

As tgrand said if a developer is willing to post here we would do our best to help fixing this issue.

The problem sounds like a common “bug” of many old game engines that processes one input state per frame. When the frame rate increased it will execute more input states at the same time. Therefore pressing something for the same time will give you a larger change. In general it is not that hard to fix such an issue.

I wish I could elaborate in detail, but as I mentioned earlier, I'm no coder.

Thank you for your quick response. I was kinda looking for laymans understanding of the framerate concept since this is what's being blamed.

I understand framerate as being the clock cycle of the game. If this were increased and the times to check the input values from devices were increased, would that have an affect such as what I'm describing? I know I can't expect some solution from you folks, but any explanation of the concept would greatly help.

I realize I may be asking a question that cannot be so easily answered in such a general way, so again, I apologize for my ignorance. :)

Thanks Demirug,

Very helpful. You seem to have the grasp on the problem already. I think that may be where the problem lies. The dev is having trouble understanding how to compensate for the increased rate or how to lock it to the update rate the game was originally designed for.


http://alleg.scarybugs.net/changeset/526
This was supposed to be the change made to fix the update rate. The change showed no positive results with controller/keyboard input rate. The ticket has been closed as "fixed", however the problem still exists and our dev seems reluctant to investigate it further.

Again, thanks for any input.

What Demirug is saying makes sense, but I kinda doubt it's that simple. The game engine was working fine before the code was changed, so what actually changed?

Also, there are lots of ways to deal with timing in a game. First of all, let's be clear about terminology. Frame rate typically refers to the rate at which you redraw the screen. You can tie input processing to this in a number of ways. If you perform a fixed amount of processing every frame, like Demirug described, you'll get the behavior you described. It's a serious rookie mistake for any modern PC game including one of Allegiance's era to assume or require a fixed frame rate. I doubt Allegiance originally ran at a fixed frame rate, given that it supported a wide variety of hardware and rendering options. So I'm not sure how this becoming broken upon later code changes could be the fault of a poor original design.

Then there's update rate. Update rate refers to how often something gets updated. It's common to use a fixed update rate for things like input processing and game physics, with the update rate being independent of the frame rate. If the update rate is fixed, then you can perform the same fixed amount of processing every tick (update).

The two methods I just described involve fixed processing. For example, if you see the + key is down, you increase the throttle by a fixed amount. It's also possible to use variable processing. Then you don't need any fixed frame rate or update rate. With this approach, if you see the + key is down, you increase the throttle by a constant amount multiplied by the amount of time that has passed since the last opportunity to perform this type of processing.

Anyway, the only change in that changeset you linked to that actually does anything is this:

if (dtime < 0.017f) //Imago 6/10
return;

Which probably means: don't continue to do various things until enough time has passed. Specifically, 0.017 seconds, which means an update rate of about 58.82 updates per second.

This looks like it's probably a terrible hack but I can't say for sure, not being familiar with the code.

[Edited by - tgrand on July 15, 2010 12:17:33 PM]

I can't tell you how grateful I am for that thorough explanation. I've been dying to find someone who could translate this concept to a layman such as myself.

I'm not sure I can answer your question tgrand,

The original release of the game had a video framerate fixed to the monitor refresh rate (we could see this by pressing alt-f) and the controller input update rate I recall hearing was locked at 60/s.

Then came a release to the community "Dx9 version", which allowed unlocking vsync. Some problems were discovered and then this was posted by the devs:

"This is caused by the new R5 DX advanced options to turn off vertical sync.
This increased the number of times the code iterated per second to set values to variables such as throttle/zoom.
I've put a limiter in, don't know if it's the right thing to do. See http://alleg.scarybugs.net/changeset/525 for the mistake, fixed then the limiter in, http://alleg.scarybugs.net/changeset/526"

Even with my limited understanding, I became immediately suspicious about that rookie move you described earlier having been made in our game. I think they may have made some alteration to things that were fixed values at first, and the devs turned them variables or visa versa, I just don't know quite honestly. But my gutt tells me they're in way over their head on this one and are compensating with what you called, terrible hacks.

I think I would like to hire one of you to get to the bottom of this. :)

[Edited by - GluteusMaximus on July 15, 2010 1:01:58 PM]

That's some helpful info. But please note that even if a game always uses vsync, this doesn't mean its framerate will always match the monitor's refresh rate. It will only match if the CPU and GPU are fast enough. It's unlikely that Allegiance was able to make its burden so light that even on its max settings and highest display resolution, it was able to reach the monitor's refresh rate on every system out there at the time of its release.

It's possible that in cases when the frame rate was below the refresh rate, input would be processed too infrequently and the player would have a poor experience, but again, I would hope the original team wouldn't have released it in such a state.

Anyway, if disabling vsync is the supposed cause of the problem, why not try re-enabling it? You should be able to do this without having to modify the code, either by changing an option in the game, or by forcing vsync to be enabled in your graphics card driver settings.

Even if you don't want to always have to apply this workaround, it would be good to know if the game in its current state works fine with vsync on, but screws up with vsync off.

By the way, if your framerate never drops below the monitor's refresh rate, you should really have vsync on. There's no good reason to have vsync off in such a case, EXCEPT if you're trying to do performance benchmarking or debugging. Under normal gameplay conditions, the extra frames will never be visible, you may experience tearing, and you're probably causing extra power consumption, heat generation, and possibly noise.

Man, you guys really know your stuff.

I have vsync on and even with it forced on by drivers, the joystick still seems "loose" in this newer version of the game. Because there are so many controller input bugs reported, I may be on a wild goose chase pointing at the wrong problem.

My specific concern is with the feel of the joystick under this newer version of the game. Is it possible that my specific joystick and the newer version of dx is the culprit? I'm using a MS Sidewinder 3d Pro http://en.wikipedia.org/wiki/File:Sidewinder_3D_Pro.jpg which worked perfectly with the game when it used an earlier dx version. Not sure either but I recall hearing from the devs about a difference in direct input and direct play....but that's something that fell on my ears and no clue if it's of any value getting me to the cause.

Here's another little memory from long ago...Way back when, long before this updated game, I recall having this same experience (loose feel) and it went away just as quickly as it appeared (different machine btw). As I recall it was right around the time I purchased a newer video card or maybe it appeared when I forced off vsync thru the drivers but I just can't remember. I'm going to try to force off the vsync on the older version of the game and find out if that creates the same anomaly. I'll also try to load this game up on a real old machine with the newer version of the game and see if the feel of the joystick changes.

The best way I can describe this joystick "feeling" is: imagine flying a small aircraft where the flight controls are managed by cables...if someone just barely loosened those cables to such a small degree where it was barely detectable, there would be no way for you to distinguish whether the problem was in the cabling or the pulleys or the flight control surfaces themselves. Because of how the plane responds, it could even be ice on non control surfaces.

It's like I just can't put my finger on the cause of this.

Thanks again