BackTrak wrote:QUOTE (BackTrak @ Jul 30 2017, 10:58 AM) ...Option 2: I take the build that you have identified that doesn't have the issue, and roll each changeset forward into it, excluding any Dx9 changes, leaving us with a Dx7 based Allegiance. We lose shader capibilty. Total number of Shaders used in the current version of Allegiance: 0. (Not a loss right now, but will prevent someone from using that later, should that mythical beast ever appear).
Are there any other options? Rolling forward a few hundred changes that span 8 years of Allegiance development is not appealing, but I am willing to do that. At this juncture, there is some risk with that. It is possible that I spend weeks doing this, and we end up with a great playing game that won't run for more than five minutes due to all of the bugs I inadvertently add. I would like to focus on Steam integration, but I understand that this issue may take priority.
The fact that you have located the start build makes me optimistic that this issue can be fixed with Option 2 above.
BT, you are a savior
The slew code allowed me to hard code ship turn rates (eliminating the fetching of that data) and also allowed me to update the inputs at that point in the code (wintrek.cpp) even if the ship's turn rate wasn't being slewed. This, forced update of the joystick, eliminated some of the input lag indicating that this problem is timing related. I went further on and started ripping out all sorts of code thinking that it might just be that there is too much in the loop. While I was able to get better response from the inputs, it was still completely out of whack.
I've tried delay timers and hundreds of variations of forced frame rates with monitor frequency changes and custom monitor sizes,...you name it, I've tried it, but nothing works. It's like flying with rubber bands instead of cables managing your control surfaces (airplane talk).
Anyhoo, I took this to Imago who revealed that immediate mode was not available in Dx9 and was likely the cause of this. I did a little research and boy did that make a lot of sense (even to me). That explained why, no matter how stripped down and filled with hard coded values, I could not get the Dx9's inputs to be correct.
Back when Dx9 was being released to the community, the server hosted both the Dx9 and Dx7 versions of the game. This allowed for testing and what not. I tried the Dx9 version back then but it was just as it is now, frustrating as hell to fly, so I continued to use the Dx7 version (as many others did).
Dx9 and Dx7 clients could be built from the same Project up until there was a merge where the Dx7 client was removed from the project. I was able to get contrib 205 to build both the Dx9 version (AllegianceR.exe) and the non dx9 version (Allegiance.exe). FAZR5Contrib@249 8c327b6c-a73e-8745-8738-111f1e176ae1 is where the Merge happend and the Dx7 build was removed from the Project.
If you can crank out builds, I can test the livin' $hit out of them in real time, on multiple platforms, so you won't have to. I already know of a couple issues with the Dx7 compatibility, but they are minor...also the slew formula that is currently in place, is flawed. efimage.cpp has a sensitivity factor that needs changed and a cursor position change (which is why your cursor isn't middle screen when you toggle mouse control on/off)....
I can assist with porting as well but it would have to be minor stuff and would need reviewed.
Thanks again, you made my day/week/year!
