Blue_Pill

I tried it on a Pentium M 725 notebook with 855GM chipset graphics and a whopping 512MB of DDR RAM but it only supports OpenGL 1.3. On Windows XP, TDM shows an initialization error and on Linux (antiX), it reaches the main menu with a black screen due to shader compilation errors. According to the console output, it does seem to support GLSL 1.1 and 1.2 but TDM requires 1.3 even with glsl shaders disabled. Didn't really expect it to run properly though. Anyway, I also have an Atom x5-Z8350 board with 4GB RAM. It isn't quite old but it is quite slow. The last time I tried, it had <=15fps iirc but I will take a look at other maps and settings.

Great work! I've really liked the secrets and scattered bits of lore that reward exploring the map and make the surroundings vivid.

That firm seems quite suspicious, so I'd hold my breath for a bit longer and wait for more details. All the exploits mentioned require admin privileges, which also allows you to modify signed drivers without Windows noticing (which is what the Pixel Clock Patcher does) or flash manipulated hard drive firmware. I doubt that many of these devices have proper validity/certificate checks, at least my DVD drive has none. Since I have an unpatched 7200U Intel laptop, I think I should really take a deeper look at those Management Engine exploits. I wonder if these flaws have rendered Software Guard Extensions useless Of course, every additional security issue makes it easier to find viable attack vectors, especially for attacks targeting larger groups of persons/organisations. And with encrypted and undocumented code running with such privileges (and hardware in general as Spectre and Meltdown have showed), users become more and more dependant on the 'goodwill' and competence of a couple of firms.

Uploaded a svn diff file in the movement stutter issue that removes the movement frame lock and fixes moving onto the curb in TD4: Alchemist by adding a 250ms delay to sliding after a step up. Frametimes >= 16ms (up to 62.5fps) will be untouched by the curb workaround. I could not reproduce the head getting stuck issue in Swing mentioned here, but that doesn't have to mean it's fixed. Report back if this resolves the stutter, and of course if there are more frame rate related bugs.

The 63fps (~ 15.9ms) shown might be slightly above (below) the 62.5fps (16ms) of USERCMD_MSEC, causing it to skip a movement frame. //idPhysics_Player::WalkMove (Physics_Player.cpp) : 906 moveTimeAccum += frametime; while ( moveTimeAccum < MS2SEC( USERCMD_MSEC ) ) { return; }

The current movement code seems to work good in 60FPS (besides the stutter, which probably is caused by the workaround for curbs on high framerates). I've done some testing without the movement frame limit. In fact, after commenting out the slope detection (search for "%i:steep\n" in Physics_Player.cpp), I did not longer slide off the curb in TD4:Alchemist. A tiny delay in the slope code after a step up (search for "performing step up" in Physics_Player.cpp) might fix the issue without affecting gameplay (ideally leaving normal framerates completely untouched). I suspect the problem is that since the step up velocity is smaller at higher framerates, it takes more frames to get up the curb. Once the player has reached the edge of the curb, the ground check thinks the player is on a slope and slides off the curb again. The relevant console and log messages can be enabled with g_debugMove on 1 and LogClass_Movement (Info).

Occasionally skipped movement updates (if I understood the bugtracker comment correctly) could indeed cause stuttering. Since it seems to be a workaround for sliding down curbs, I'll see if I can find another option. A simple one might be adding a tiny 'mercy' delay (e.g. 16ms) to the slope check, but I'll take a more extensive look at it on Monday.

I've tested it for 2-5 hours (maybe even 5-10 but not sure), and couldn't find any major issues.