Checked this with mech2 until my frame rate stayed below 1 fps. Memory usage didn't go up significantly. Virtual size hovered around 154000K the whole time, working set went from a little under 80000k to a little over 82000k during the capture, and dropped back down to 81832k after turning off …

This happens for me as well, in 0.74 from the main site. Not in any previous releases. I was initially hoping that it was only Magic Carpet 2, but it seems to be happening in X-Com 1.2, as well. I'm running: XP SP2 32-bit 3.4 GHz P4 2GB RAM It takes 2-3 minutes for mine to drop to single digit FPS, …

I'm wondering, might the RANGE constant be directly related to the dosbox cycles setting? Maybe if we can determine the calculation to convert cycles to RANGE, we won't need to add the settings to the configuration file?! No, the calculation is time based, and seems reasonably cycle-independent, …

Absolute Zero doesn't center correctly (regardless of what the range is set to) like it did with 0.65 - it thinks the center point is a little higher on my joystick than it really is. OTOH, it doesn't center correctly on a real system either; at least, not on mine. Metaltech: Earthseige works fine ( …

Dropping RANGE down to 10000 seems to improve things a lot. I only tested WC3 with that before making the change to timer.cpp hal mentioned, but it got rid of the occasional drifting problem completely. After I made that other change, I tried out WC2, WC Priv, and WC Armada. All worked perfectly. I …

Thanks, I'll check into both of those when I get home. I was keeping an eye on my CPU usage, and it didn't seem to get thrown off when it spiked up to max, at least with WC3. It definately worked fine (didn't drift or jump) when I turned up the cycles to a very high value in the calibration program …

Ok, I'll leave that out (of the config) then. Its 24.2 microseconds + some formula. Yes, 24.2 milliseconds would be really, really long. It can get up to about 1.1 milliseconds total with RANGE == 50000, which is still kinda long, which is why I will be trying lower values and testing with a wider …

I just realized I did something really dumb that causes significant precision problems after dosbox is running a while. I'll fix that too. That's what I get for being a game designer instead of an engineer for the past year and a half.

In addition to more testing and playing with the range, I'll probably make RANGE something adjustable in the config file, and if RANGE == 0 use the old method (to guarantee I don't break anything). Unless there's some reason why I shouldn't.

Thanks for the pointer, hal. Here we go - joystick patch. I don't have all that many DOS games to try it with, but it is compatible with Wing Commander 2, Wing Commander Privateer, and fixes Wing Commander 3. It does not work with HCl's hacked version of Armada (that was made to work specifically …

that is probably a working method. We have created our own high resolution timer that way as well. (by scheduling in smaller amount of cycles if a timer event has to happen within that millisecond sdl offers us) Else you might see if you can make that delay function of yours a bit more cycle …

Well, 1 ms isn't good enough either. According to the formula, if the axis is at max it takes about 1.1 ms to count down. If that's the best timer we've got, I'd imagine I'd have to try to determine the number of cycles it should take at the current speed, and use the cycle count. Unless there's …

http://www.hackcanada.com/blackcrawl/elctrnic/gameport.txt seems to have the formula needed: time = 24.2 + ( 0.011 * resistance ) where time is in microseconds and resistance is in Ohms (and 0 < resistance < 100,000 ). I'd put this to the test now, but I really only have a few minutes here and there …

I didn't figure out what would be a correct delay to use, I just hacked something in really fast to make sure I was correct. This would not work for lower or higher cycle counts than I was using. Basically: //up top static Bit32u last_read_dec = 0; //down in read_p201 Bit8u ret=0xff; if (stick[0]. …

Ok, I just found HAL's timerpatch2.txt, and patched it into my build. It definately is what fixes the jumpiness problem (and I wouldn't be surprised if it fixes other stuff too).

There are two joystick problems with WC3. One, is that it jumps all over, but this seems to be fixed with HAL9000's timer fix (I haven't verified that this is exactly what fixed it, but it is in HCl's dosbox build, so that seems most likely. I haven't found a .patch or .diff that includes this …