gentoo, if you've gone to that much trouble to minimize input lag, you're going to like some new features in the upcoming WA 3.8.0.

There is a DirectDraw 8-bit (hardware) mode, which on my Windows XP installation yields framerates upward of 900 fps with a normal (1920×696) map. I have found this to have lower input lag than anything else. I don't use it though, because it makes minimization and unminimization slow. I use Direct3D 9 (shader).

Assisted v-sync now has some configurable parameters (via the registry). Once fine-tuned correctly, it works quite well with vsync disabled, with "vsync off + assisted vsync on" yielding smooth updating with less input lag than "vsync on + assisted vsync off".

And... there is a really big new feature, which among other things, reduces effective input lag in all modes. I'll give a hint: It reduces average input lag by 10 milliseconds.

AFAIK there is no reason to use Direct3D 9 (CPU) unless Direct3D9 (shader) either doesn't work on a particular GPU or has glitches, neither of which has ever been reported. (This applies both to 3.7.2.1 and the upcoming 3.8.0.)

When I did a test with WA a while back using my video camera in 240 fps slowmo, with D3D9 (shader), I found keypresses to have about 42 ms of lag (from pounding a key fast/hard to seeing the effect on-screen), frontend hardware mouse cursor to have about 27 ms of lag (from suddenly shoving the mouse to seeing the effect on-screen), and in-game mouse cursor to have about 40 ms of lag. This is with an Northgate OmniKey Ultra2 keyboard plugged into the PS/2 port, and USB mouse.

CPU rendering resulted in smoother gameplay on an older computer with high DPC latency caused by Nvidia drivers. The difference shouldn't be noticeable on most systems.

That is very interesting. I had never heard of this before.

I never said 4.0 was ready. Work on it hasn't even begun, let alone being ready.

(Edit: BTW, by an alternative definition of what counts as part of 4.0, CyberShadow has done a significant amount of work on the non-W:A-specific API aspects of it. To my way of thinking, though, "beginning work on 4.0" would mean working on W:A-specific aspects.)

There are a ton of finished features and fixes already implemented for 3.8, but release is blocked by some other things that aren't ready. I'm trying my best to make it ready, to meet the end-of-the-year deadline.

[attachment=1]

Thank you! And wow, I am surprised. There actually is some of that bug going on here. The rope froze for about 1/2 a frame.

So, I wasn't planning on fixing this bug before (I thought it to be an obscure glitch that almost never happened, and was fun when it did) but now I see that it definitely needs to be fixed, and will do so!

Edit: However, this will probably be the biggest change I've ever made to the rope physics, in that it may actually alter the feel a little bit. There's a chance some experienced ropers may have subconsciously adapted to this glitch by anticipating how the rope sometimes moves less when it's snagged and vertical.

Edit 2:
On second thought, ropers probably haven't adapted to this glitch, even subconsciously, given that it's apparently such a common choke. I do feel nervous about changing it though! Years ago there was a thread about how people thought the WWP rope felt different than the W:A rope. I then proved that it was identical by patching the WWP EXE to record replay data, and playing it back in W:A with no desynchronization. So it seems the difference in feel, if there was one, was probably from my improvements to the calculation of in-game passage of time – it used to use GetTickCount() and I changed it to use QueryPerformanceCounter(), along with other improvements.

Since then I did make some subtle changes to the rope physics, like the fix in v3.6.23.0, "In free space, the worm would always be shifted approximately one pixel up and to the left every time the rope caught", and others. This rope freeze fix will be the least subtle so far. (Note, there's also another related glitch, in which the rope "speeds up" upon hitting a snag. I'll preserve that one. If I ever do anything to change it, it'll just be to make it behave more predictably.)

Back in 2008 I did a tool-assisted run of this challenge, and was disappointed to see that it only resulted in a 27 turn run, just like the top non-tool-assisted replays. At the time I thought it was impossible to do better than 27 turns.

When this challenge was hosted here on TUS and there was a 5-way tie for first place at 27 turns, that only confirmed my belief that 27 was the best possible.

I was wrong. Here it is TASed in 23 turns: 2017-02-24 19.39.24 {TA} 2017-02-24 18.27.41 [TCB Challenge 63 - 23 turns] 0xDEADC0DE.WAgame

The trick is

Spoiler! View

to shoot from outside the cat, standing the left or right edge of its long belly. That way, the shotgun crater can be much higher, relative to the highest crater so far, than it could be when only shooting at the top edge of an existing shotgun crater from inside the cat.

Quote from: Deadcode on October 23, 2016, 01:49 PM

Quote from: j0e on October 23, 2016, 10:03 AM

-I sent Deadcode a program I 'wrote' in visual basic which had a hidden freeware component that i downloaded from a website for 'script kiddies'. That free script let you browse a target's hard drive and download things. The visible part that I wrote was a simple form where you click on a gif of a fat kid repeatedly to make him dance. My goal was to steal WA's source code. This was when I had access to various beta builds via the alpha testing group and spoke with DC regularly. DC was too smart to heed my repeated advice to leave the program open (and download winsock dll's), but I am certain he knew (or later discovered) what was up. Good thing I was unsuccessful - probably would have released it and destroyed WA. I never really spoke to DC again after that.

I have no memory of this. I don't remember you sending me any programs, don't remember you asking me repeatedly to keep one open, nor talking about winsock DLLs. I have pretty much always been cautious about such things, though.

Maybe with further details my memory could be jogged. I'd be quite curious to know. Do you remember the approximate date when this happened, and what means you used to send the program to me?

I'm guessing that if you did send me this program, I either ran it under a VM or never got around to running it at all.

A very long time ago on AIM - roughly 2003 or 2004. This was the gif: http://giphy.com/gifs/fat-11pVPEm3W6QS7S. I don't know if you ever opened it, but I definitely sent it. Figured you probably took precautions like that. The script added "|COMPLETE|" to the end of all the files it downloaded. I don't have regular access to my old worms files or I might be able to come up with a more exact date. I don't have the cl2k db anymore.

I found the programs JoE sent me:

Filename	virustotal detection ratio	Timestamp when downloaded
logo_program.exe	0 / 56	2004-06-09 17:30:38 -0700
logo.exe	2 / 56	2004-06-09 18:43:42 -0700
joeaaaachatV3.exe	10 / 56	2004-06-09 20:20:06 -0700

Wow JoE, I never knew about this side of you. I hugely respect that you're finally coming clean about it though. That takes guts.

-I sent Deadcode a program I 'wrote' in visual basic which had a hidden freeware component that i downloaded from a website for 'script kiddies'. That free script let you browse a target's hard drive and download things. The visible part that I wrote was a simple form where you click on a gif of a fat kid repeatedly to make him dance. My goal was to steal WA's source code. This was when I had access to various beta builds via the alpha testing group and spoke with DC regularly. DC was too smart to heed my repeated advice to leave the program open (and download winsock dll's), but I am certain he knew (or later discovered) what was up. Good thing I was unsuccessful - probably would have released it and destroyed WA. I never really spoke to DC again after that.

I have no memory of this. I don't remember you sending me any programs, don't remember you asking me repeatedly to keep one open, nor talking about winsock DLLs. I have pretty much always been cautious about such things, though.

Maybe with further details my memory could be jogged. I'd be quite curious to know. Do you remember the approximate date when this happened, and what means you used to send the program to me?

I'm guessing that if you did send me this program, I either ran it under a VM or never got around to running it at all.

-I extracted the database from my former worms site to get all the hashed passwords. I recovered some of those passwords, using them to gain access to admin accounts on other worms sites, from which i downloaded the databases/hashed passwords. I also stole the databases from a few sites which I hosted on my web server. RRkit, and Syc0's short-lived league called AL, and maybe a small forum or two. Had a list of over 2000 people's decoded passwords at one point. Ultimately gained admin access to cl2k with a friend's help, got the database, and friend deleted the whole site. Cl2k never really came back after that. That sucks - cl2k was a great site. We very nearly did the same thing to blamethepixel.

Wow. I don't want to make you feel more guilty than you do already, but of all the things you've listed, this is probably the worst. The worst part about this is that there was no backup, and all the cl2k forum posts were lost forever. Although I did save some threads on my hard drive (mainly ones where replays were being shared).

This is perhaps the most difficult Battle Race map ever made, and it has taken people years to figure out how to complete every part.

Here is a BRSolver run of this map, one-turning it in 308.78 seconds: [attachment=1]
I am releasing this with Wyvern's permission.