Edward850

Start with the problem you have, not the problem you think. Anyway the Visual Runtime install for 2015, 2017, 2019, and 2022 are all part of the same installer nowadays, you can find it here: https://learn.microsoft.com/en-US/cpp/windows/latest-supported-vc-redist?view=msvc-170 You likely want the x64 version.

Eternity uses C++17 and thus needs a minimum of VS2017 15.8.

You're not using Chocolate Doom, but rather a program called Chocorenderlimits which is specifically designed to debug maps. The flashing is debug related and will not show as such in a traditional port. The reason why it's showing up is too specific of a question to diagnose from a video, but you potentially have a hole in the map from the way the nodes built.

Doom cannot animate anything at 60FPS, 35FPS is the upper limit as that's as fast as the actor ticker can ever go (which controls actor animation). Freedoom cannot be made magically compatible with Smoothdoom. You must by hand create the extra animation frames yourself.

Windows PowerShell.

Doomseeker isn't a server, it's just a server browser for source ports. A meta launcher, in a way. You'll need to be more specific about your issue, especially with what port you're actually using and how you set up your server.

WebAssembly, typically through Emscripten.

Also an additional point: This is not a legal requirement for closing code, heck the law doesn't really care if the code is compiled or not. If you license some code, compile it then decompile it, you still have the same license for what is arguably the same code. There's weird nuance to clean room implementations but that's beyond the scope of the problem. For this same reason, if you release code you can do so under a non-permissive license (i.e, release it for educational use only). For this same reason, making a program under a reversible JIT language such as Java or C# does not entitle you to the ownership of that code just because it's easy to reverse. Machine code is all about the performance, and C/C++ is designed to be compiled into machine code (that's why C was created, to be a crossplatform alternative to assembly which thus needs to have a compiler to turn it into that assembly for a specific platform). And a machine code version of any code base will always run faster and have a smaller memory footprint than an identical JIT counterpart. Then it would help to state them all.

Valve have talked about a hypothetical shutdown and stated they'd release a final client that disables any needed check-in for online credentials, presumably by forcing an offline mode trigger for all apps. Which brings me to my next point: Offline mode, you seem to be running on old information. Steam's offline mode is quite reliable nowadays and they fixed the bug that prevented it from working if you never prepared it in advance (apparently the client credentials cache would become corrupted if Steam launched and first tried to connect to their servers, thus invalidating the mode, which selecting offline mode specifically avoided). In fact in just testing this myself, I curiously found that they've actually improved it recently, it can now seamlessly bring itself back into online mode if started with no internet. It just launches with no connection automatically, didn't even stop. Edit: Actually I now just realized why. Steam goes partially down for maintenance every Wednesday morning, makes sense to (finally) make the client as seamless as possible to the end user while the authentication server is down.

On the fly code changes in compiled C/C++ is something we've had since the 2000s, in Visual Studio it's called edit and continue. In VS2022 it got even faster by introducing hot reload which allows you to iterate code without even pausing the application. The desire to specifically avoid compiled code doesn't really fit your stated intentions. Also decompiling is never a thing you do. That's an advanced computer science concept reserved only for extreme edge cases in software development.

My answer hasn't really changed in that regard. It comes down to the individual about which one is easier, therefor faster for them. This is a question you can only ask yourself or the person you hire to do the work.

They are two different skill sets. Which one is "easier" is entirely subjective and comes down to what you yourself are capable of.

Both 0 and 0.0 are identical values, given 0 * 65536, or frankly 0 multiplied by anything, is still 0.

Third option in https://www.doomworld.com/settings/

I developed Doom64 on a 155Hz monitor and didn't jet any noticeable judder, otherwise I'd have reported that to Kaiser. Additionally while I'm familiar with the reports of it in Quake1, I have not seen anything in-depth for Doom64. We are familiar with a performance judder that occurred in a particular patch, but this was fixed in a subsequent build soon after. Also one game having a problem that another one doesn't isn't really a back-portable concept. Kex doesn't work like that.