Quote from: Sensei on December 10, 2017, 01:25 PMWill 3.8 remove input lag while using d3d9wnd

Mu.

Quote from: Sensei on December 10, 2017, 01:25 PMand wk_SuperFrontendHD modules?

Yes.

Quote from: gentoo on December 10, 2017, 12:32 AMNothing to do with Vulkan is it (your hint)?

Nope, you're not close at all

The OmniKey Ultra is a great keyboard for WA, with function keys on the left, where all 12 are within quick reach by touch. The version I have also has a non-inverted-T cursor pad (i.e. it's just like the numpad, except Ins and Del are the same size). Due to these two things, I have no choices for replacement with any newer keyboard, and have had to do many repairs to the keycaps over the years. I haven't tried the HHKB but I know I would really miss having function keys, a cursor pad and a numpad.

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.

Quote from: Jengu on December 08, 2017, 09:04 AM
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.

Quote from: skunk3 on October 10, 2017, 12:17 AMRead DC's post on page 3

Quote from: skunk3 on October 10, 2017, 12:17 AMif instead of 4.0 you were referencing 3.8 in your post near the bottom of page 8

Could you please link to posts by URL instead of referencing them in this way? The forum software lets you set 5, 10, 15, 25, or 50 posts per page, and this is a per-user setting. With >=10 posts/page there isn't even a page 8. With 5 posts/page there's no post by me near the bottom of page 8. So I don't know what posts you were referring to...

Quote from: skunk3 on October 10, 2017, 12:17 AMif "almost everyone" agrees that it should have been released long ago (and therefore, presumably finished) then why hasn't it been released yet?

I'm sorry, I can't be specific. Basically, I feel it would hurt the long-term future of the game to release it at this point, with certain features unfinished. But whether or not I manage to finish these things, you will be getting a release by the end of the year.

After releasing 3.8, I want to go back to a much more frequent release schedule, like it used to be before 3.6.28.0.

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.

Quote from: Nonentity on October 09, 2017, 03:28 PMNo, thank you. I know a lot of people who will be happy to see this bug gone. You and CS are the best, man.
And sorry about the wrongful assumptions and generally just being too overconfident in this thread.

Thanks, and apology accepted!

Quote from: Nonentity on October 09, 2017, 02:11 PM
[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.)

Quote from: Nonentity on July 18, 2017, 11:04 AM
Any chance this bug will be fixed? https://www.tus-wa.com/files/file-699/
The freezing rope bug is especially annoying in Big Rope Race. https://youtube.com/watch?v=l9OSh08exAs

QuoteThe bug froze the rope at 90° so yes the rope was released at 90°, but the fail is not deserved. In this case you can not visually see the rope freezing. The angle of the subsequent rope shot is calculated at the frame of the rope releasing and here the rope freeze bug occurs at the same frame the rope releases.

The bug replay you linked to (with its accompanying discussion thread) and YouTube video look completely unrelated. Without seeing the original replay file I can't be 100% sure, but it looks to me like the rope was indeed released pointing straight up.

W:A's rope and projectile physics both have many calculations happen between frames. The last rope angle rendered before releasing the rope is never the same as the angle at which the next rope will be shot, unless the rope is perfectly still when released. This is because the rope internally undergoes a frame worth of motion before being released. If you had actually done a quick test under normal circumstances, instead of making assumptions on how the game works, you would have seen this.

It looks like you took those screenshots from the original replay file, not the YouTube video, as I see no compression artifacts. In any case, screenshots and video are of very limited usefulness for analysis. The replay file is needed.

If you really think there's a bug going on, then post a replay file, not a video, and I will analyze it. But I think what is going on here is just bad timing by the player, resulting in a well-deserved fail.

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.

That's a bug. It's fixed in the alpha:
[00:01:03.26] ••• Espada (UC`Triad`cR) starts turn
[00:01:06.20] [UC`Triad`cR] muz yok
[00:01:06.76] [UC`Triad`cR] heee
[00:01:08.26] ••• Espada (UC`Triad`cR) fires Ninja Rope
[00:01:29.44] ••• Alien Glitch
[00:01:30.10] ••• Espada (UC`Triad`cR) uses Parachute
[00:01:31.04] ••• Espada (UC`Triad`cR) fires Ninja Rope
[00:01:37.04] ••• Espada (UC`Triad`cR) fires Surrender
[00:01:37.06] ••• Espada (UC`Triad`cR) ends turn; time used: 29.32 sec turn, 0.00 sec retreat
[00:01:38.76] [UC`Triad`cR] lan
[00:01:39.74] ••• Game Ends - End of file

Team time totals:
Espada (UC`Triad`cR):      Turn: 00:00:39.72, Retreat: 00:00:00.00, Total: 00:00:39.72, Turn count: 2
CAKMA TRIAD (UC`AsiLL`cR): Turn: 00:00:30.00, Retreat: 00:00:00.00, Total: 00:00:30.00, Turn count: 1

End of round 1

Round time: 0:01:39
Total game time elapsed: 0:01:39

The round was drawn.

Why the "End of file" happened during writing of the replay file, I don't know. Normally it should be "Game Ends - User Quit" or "Game Ends - User Quit with Alt+F4". Possible causes:

• The game crashed on Triad's end.
• Triad killed the WA.exe process.
• Triad turned off his computer using the power button or by yanking the power cord.
• Triad had a sudden power outage.

Because both teams were Red, the surrender didn't end the round. Here's what would have happened if it had not crashed:
[00:01:39.72] ••• CAKMA TRIAD (UC`AsiLL`cR) starts turn
Network lag is currently not recorded, so even if it stuck at that point for a while, it would appear the same. So I'm guessing the network connection to AsiLL dropped without sending a TCP RST packet, the game lagged for a while, and then Triad either killed the WA.exe process or ended it some other way without properly quitting, without waiting for the automatic 150 second timeout to happen.

If the connection had not dropped and no further user input happened, it would have gone on and on:
[00:01:39.72] ••• CAKMA TRIAD (UC`AsiLL`cR) starts turn
[00:02:14.70] ••• CAKMA TRIAD (UC`AsiLL`cR) ends turn; time used: 30.00 sec turn, 0.00 sec retreat
[00:02:16.72] ••• CAKMA TRIAD (UC`AsiLL`cR) starts turn
[00:02:51.70] ••• CAKMA TRIAD (UC`AsiLL`cR) ends turn; time used: 30.00 sec turn, 0.00 sec retreat
[00:02:53.72] ••• CAKMA TRIAD (UC`AsiLL`cR) starts turn
[00:03:28.70] ••• CAKMA TRIAD (UC`AsiLL`cR) ends turn; time used: 30.00 sec turn, 0.00 sec retreat
[00:03:30.72] ••• CAKMA TRIAD (UC`AsiLL`cR) starts turn
[00:04:05.70] ••• CAKMA TRIAD (UC`AsiLL`cR) ends turn; time used: 30.00 sec turn, 0.00 sec retreat
and eventually,
[00:25:05.70] ••• CAKMA TRIAD (UC`AsiLL`cR) starts turn
[00:25:40.68] ••• CAKMA TRIAD (UC`AsiLL`cR) ends turn; time used: 30.00 sec turn, 0.00 sec retreat
[00:25:42.68] ••• Sudden Death
[00:25:43.90] ••• CAKMA TRIAD (UC`AsiLL`cR) starts turn
[00:26:18.88] ••• CAKMA TRIAD (UC`AsiLL`cR) ends turn; time used: 30.00 sec turn, 0.00 sec retreat
[00:26:20.90] ••• CAKMA TRIAD (UC`AsiLL`cR) starts turn
[00:26:55.88] ••• CAKMA TRIAD (UC`AsiLL`cR) ends turn; time used: 30.00 sec turn, 0.00 sec retreat
[00:26:57.90] ••• CAKMA TRIAD (UC`AsiLL`cR) starts turn
after which it would just keep going like that.

Quote from: j0e on October 23, 2016, 02:32 PM

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

Well the repeat rate itself is not the problem. I have a keyboard with a hardware repeat rate of 125 characters per second (quadruple the standard, not just double) and it works fine with W:A. I have it plugged in as a PS/2 keyboard though, not USB.

A USB keyboard should not be messing with the repeat rate; key repeat on USB keyboards is handled by the OS. So a keyboard that does somehow change its repeat rate is probably doing it in a weird and bug-prone way, which even in apps that seem to support it fine are probably clumping the repeats on a smaller time scale.

I recommend turning off your keyboard's 2x repeat mode, and instead use something like CyberShadow's KeyboardEmperor.
If you can't build KeyboardEmperor from source yourself, here is a prebuilt binary: keyboardemperor-objfre_win7_amd64.7z - this is built for Windows 7 64-bit, and is hard-coded to a repeat-rate of 100 characters per second and repeat delay of 200 ms. It is an unsigned driver, so you will need to boot Windows in test mode to install and use it (see here). It may or may not work in Windows 10.

Edit: An easier way is to use keyrate.exe.

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.

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.

Quote from: j0e on October 23, 2016, 10:03 AM
-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).

Quote from: TheWalrus on August 29, 2016, 08:04 PMdid BRsolver always skipwalk, DC?  I thought it used to walk normally in the earlier build.

It is actually flipwalking, which is a bit faster than skipwalking. It has always done this... in fact BRSolver discovered flipwalking the very first time a working build outputted a solution.

I would actually REALLY like to make BRSolver able to walk at 1x speed. It currently is not even capable of this. It's a bit complicated because the normal 1x walk doesn't have a short repeating pattern (if you extend it to the point that it does, it is very long, longer than the width of any BR map), but CS and I have discussed this and have a plan for how to do it.

Edit: Perhaps you are remembering the BR TAS replays I made before BRSolver existed? All of those used normal-speed walking and were manually made.

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: Wyvern - Tranquility - 308.78 second solution by BRSolver.WAgame
I am releasing this with Wyvern's permission.