For any of you devs that want to see what I've been talking about all of these years. This is the r4 version so goto the steam beta tab and select R4 Old School then drop this into the game folder after you've downloaded.
Allegiance
I have the key to One Eyed Willy
Regarding your discord running in Vista comments:
Have you tried running it in XP Mode?
https://www.microsoft.com/en-ca/downloa ... px?id=8002
That way you might be able to run it in an XP environment within Win10.
Edit: nevermind, I forgot that only works on Win7. Ignore this message.
Have you tried running it in XP Mode?
https://www.microsoft.com/en-ca/downloa ... px?id=8002
That way you might be able to run it in an XP environment within Win10.
Edit: nevermind, I forgot that only works on Win7. Ignore this message.
Last edited by LANS on Fri Mar 02, 2018 8:20 pm, edited 1 time in total.
There are a host of issues regarding Allegiance and pointer behavior that need to be addressed even if your game is working. This game does not like a run away frame rates...it doesn't like acceleration, it doesn't like dx9, it doesn't like anything taking up time in the loop...it certainly doesn't like dinput8, it doesn't like windows > vista
Your abs() -> fabs() bug is real. You're not insane. I wrote the following application as a test:
Output:
QUOTE Elapsed time: if statement 0.00021632s
Elapsed time: fabs 0.00470528s
Press any key to continue . . .[/quote]
fabs() is ~21x slower for each call. Depending on how many times fabs() is called in time-critical code, this could be significant.
Edit: I just want to say WTF microsoft! FLOAT ABSOLUTE VALUE SHOULD BE A $#@!ING 1-CYCLE BITWISE HARDWARE OPERATION. HOW IS IT THIS $#@!ED UP..
Apparently x87 FPU used to have an "fabs" instruction, which was 1-cycle float absolute value. SSE2 doesn't, and does it through whatever @#(! the compiler decides to barf up, which should be stupid simple, but isn't? I don't feel like digging through the generated assembly to see what's going on, but ideally you get something from here:
https://stackoverflow.com/questions/324 ... -using-sse
Code: Select all
#include "stdafx.h"
#include <chrono>
#include <iostream>
#include<math.h>
int main()
{
float test[65536];
int i;
test[0] = -2 ^ 16;
for (i = 1; i < 65536; i++) {
test[i] = test[i - 1] + 1;
}
float test2[65536];
float test3[65536];
auto start = std::chrono::high_resolution_clock::now();
for (i = 0; i < 65536; i++) {
if (test[i] < 0) {
test2[i] = -test[i];
} else {
test2[i] = test[i];
}
}
auto stop = std::chrono::high_resolution_clock::now();
std::chrono::duration<double> elapsed = stop - start;
std::cout << "Elapsed time: if statement " << elapsed.count() << "s\n";
start = std::chrono::high_resolution_clock::now();
for (i = 0; i < 65536; i++) {
test3[i] = fabs(test[i]);
}
stop = std::chrono::high_resolution_clock::now();
elapsed = stop - start;
std::cout << "Elapsed time: fabs" << elapsed.count() << "s\n";
return 0;
}QUOTE Elapsed time: if statement 0.00021632s
Elapsed time: fabs 0.00470528s
Press any key to continue . . .[/quote]
fabs() is ~21x slower for each call. Depending on how many times fabs() is called in time-critical code, this could be significant.
Edit: I just want to say WTF microsoft! FLOAT ABSOLUTE VALUE SHOULD BE A $#@!ING 1-CYCLE BITWISE HARDWARE OPERATION. HOW IS IT THIS $#@!ED UP..
Apparently x87 FPU used to have an "fabs" instruction, which was 1-cycle float absolute value. SSE2 doesn't, and does it through whatever @#(! the compiler decides to barf up, which should be stupid simple, but isn't? I don't feel like digging through the generated assembly to see what's going on, but ideally you get something from here:
https://stackoverflow.com/questions/324 ... -using-sse
Last edited by LANS on Mon Mar 05, 2018 4:39 pm, edited 1 time in total.
Did you compile debug or retail?LANS wrote:QUOTE (LANS @ Mar 5 2018, 08:26 AM) fabs() is ~21x slower for each call. Depending on how many times fabs() is called in time-critical code, this could be significant.
Edit: I just want to say WTF microsoft! FLOAT ABSOLUTE VALUE SHOULD BE A $#@!ING 1-CYCLE BITWISE HARDWARE OPERATION. HOW IS IT THIS $#@!ED UP..
![]()
If debug, congrats, you just proved that unoptimized code is slow and function call overhead dominates.
If retail, congrats again, today is your day to learn about dead store elimination.
Basically I think you just made every code profiling mistake in the book, and then added some chapters of your own.
PS: ^ is the xor operator. -(1 << 16) was what you intended to write.
Amazing. Every word of what you just said was wrong.LANS wrote:QUOTE (LANS @ Mar 5 2018, 08:26 AM) fabs() is ~21x slower for each call. Depending on how many times fabs() is called in time-critical code, this could be significant.
Apparently x87 FPU used to have an "fabs" instruction, which was 1-cycle float absolute value. SSE2 doesn't, and does it through whatever @#(! the compiler decides to barf up, which should be stupid simple, but isn't? I don't feel like digging through the generated assembly to see what's going on, but ideally you get something from here:
https://stackoverflow.com/questions/324 ... -using-sse
Last edited by cashto on Tue Mar 06, 2018 5:20 am, edited 1 time in total.
Globemaster_III wrote:QUOTE (Globemaster_III @ Jan 11 2018, 11:27 PM) as you know i think very little of cashto, cashto alway a flying low pilot, he alway flying a trainer airplane and he rented
EDIT:
Seems that fixing dinput wasn't enough. There appears to be "cursor lag" or maybe "rendering delay" that was introduced into the R4 build that I suspect I have been compensating for by ripping out some time consuming calls elsewhere in the loop.
Dunno if this is something I can find since the commit has so much in it. Imma keep looking anyway.
Seems that fixing dinput wasn't enough. There appears to be "cursor lag" or maybe "rendering delay" that was introduced into the R4 build that I suspect I have been compensating for by ripping out some time consuming calls elsewhere in the loop.
Dunno if this is something I can find since the commit has so much in it. Imma keep looking anyway.
Last edited by Wasp on Wed Mar 07, 2018 6:23 pm, edited 1 time in total.
This R4 client has the original dinput7. There was a Sleep(1) in screen.h (overlooked when forking from main branch) that is now removed. This build also has all of the post-R3 mouse code changes removed, say goodbye to your mouse wheel (for now). The controller normally updates in wintrek when you're zooming, I have it updating there now even if you're not zooming, to reduce input lag.
It "seems" the speedy mouse issue was related to the change in d3d.cpp and d3drm.cpp which have been reverted in this build, HOWEVER, I believe this breaks the game for laptop users. I think this may be why laptop users can't play the original R4 and why we broke the game so they could play it.
My goal, for now, is to remove as much as possible from the code and add it back in (with extensive testing in between). I think time is everything to allegiance and there may be too much to do in the loop. This became evident when BT put the steam callbacks in the main loop, it $#@!ed my joystick up big time and when he fixed it, the joystick response was restored to it's previous "feel". I'm sniffing for those types of changes to see if I can isolate any problems.
Even though there should be no difference between the change from abs to fabs (according to cash, LANS and company,... I'm curious as to why that change had to be made and why we get errors when that is reverted to abs. I left them at fabs (BT's changes) for now and will dork with them later.
Allegiance.exe Don't tell me your $hit ain't broken!
It "seems" the speedy mouse issue was related to the change in d3d.cpp and d3drm.cpp which have been reverted in this build, HOWEVER, I believe this breaks the game for laptop users. I think this may be why laptop users can't play the original R4 and why we broke the game so they could play it.
My goal, for now, is to remove as much as possible from the code and add it back in (with extensive testing in between). I think time is everything to allegiance and there may be too much to do in the loop. This became evident when BT put the steam callbacks in the main loop, it $#@!ed my joystick up big time and when he fixed it, the joystick response was restored to it's previous "feel". I'm sniffing for those types of changes to see if I can isolate any problems.
Even though there should be no difference between the change from abs to fabs (according to cash, LANS and company,... I'm curious as to why that change had to be made and why we get errors when that is reverted to abs. I left them at fabs (BT's changes) for now and will dork with them later.
Allegiance.exe Don't tell me your $hit ain't broken!
Last edited by Wasp on Mon Mar 12, 2018 6:54 pm, edited 1 time in total.

