Copying from my post in the Next Update thread because the page numbers are getting on my nerves.
So it's about time to try out the 64-bit builds. I hit some road-bumps on the macOS stuff, so the only builds available for now are clients for: Windows 32-bit, Windows 64-bit, Linux 64-bit.
To try it out you need to enter the exclusive code 'z8MvH7F6OW3HExir' and select the 'x86-64' branch in Steam's beta branch selection. If you are on Windows, you've got to select either 32-bit or 64-bit when launching the game.
It's a little bit outdated compared to the dev branch. I'm mostly interested in hearing about any issues people run in to that specifically don't already happen in GMod.
I'm aware that AI is pretty fucked.
Post whatever you want here as long as it's related to these builds. I just want to hear whether it's working ok or not.
Just so it doesn't get lost, also copying from the other thread:
An issue/maybe not an issue that I noticed: CSoundEmitterSystemBase::GetParametersForSound: No such sound 'sound name here' shows in console after a sound from a script is not found and wants to be played. This happens on both 32 and 64 bit build, but not on the Dev branch or the regular branch. Also looks like custom type ContentIcons are fucked (they work fine on Dev and Regular, but seem not to on the 64 bit branch)
Does this mean Gmod could work ALOT better now? 64 > 32 so..
This sounds dope, already running the branch now and gonna attempt to test stuff I've made.
I can uselessly confirm that I managed to successfully boot into a singleplayer sandbox game and nothing caught fire - well, nothing that wasn't supposed to!
I also tested some extremely basic lua autorefresh (just from GarrysMod/garrysmod/lua/autorun/some_file.lua) and it worked just as expected. Really the only hint that I wasn't on the live branch was the notice at the top-right corner of the main menu. Fantastic job!
Of course, not a very good test, but I'm going to stay on this branch for as long as I can. I was about to start messing around with GetRenderTargetEx, ProjectedTexture and other such stuff soon anyway, so there's a chance I'll catch something.
I tried compiling with my custom compilers, since the update I get the error:
vbsp.exe - Entry Point Not Found
The procedure entry point GetSpewOutputColor could not be located in the dynamic link library
[path to vbsp.exe]
Compiled from the Source SDK 2013? It's not surprise that it'd fail. Maybe you'd have luck building against Alien Swarm's SDK but that's probably quite unlikely to work as well.
You're probably having issues because vstdlib & tier0 are radically different from before.
I'll go back to the dev branch for now.
Performance will probably be similar but this will probably stop kids complaining about crashing at sending client info on bloated DarkRP servers
..no it wont. the kids wont even notice it being different now. darkrp servers will still be loaded way too hard
Interested in seeing how this affects the performance of my voxel shit.
any chance of fixed hlmv? kind of important for making new content
Are there any guesses as to how the performance will be affected? My guess is that obviously it'll be better, but I'd personally be surprised to gain more than, say, 20 FPS.
only if it got past initializing VGUI
I will post a much more detailed analysis later, but preliminary results are exciting.
This graph just shows the time to generate my test world, which really just involves calling a jit-friendly function 65 million times. Smaller is obviously better.
The "2.1.0" are this new build, "2.0.4" is the current stable build.
To be clear this is not even the kind of code I was hoping to see improvements on, but it's cool nonetheless.
My further tests are far less conclusive. I had hoped that LuaJIT 2.1.0's trace stitching would improve the performance of the parts of my code that rely on the glua API. The documentation does note that this still requires the jit to stop, switch to the interpreter, and start a new jit trace.
It seems my jit-friendly <-> jit-unfriendly buffering strategy is probably still the way to go. I was going to test my mesh generation without the buffering but I couldn't really be bothered by that point.
As before, smaller is better. Units are seconds to complete the operation for the same 65 million block map as before. I added the no-jit case because I was getting suspicous as-to whether my code was being jitted at all. I kept it because it shows how dramatic the difference can be.
Regardless of my sketchy tests, this is still super cool. At the very least I hope the newer LuaJIT build will behave better than the current one, which I've seen randomly blacklist functions.
Really happy with it, everything seems to be working without a issue. Can't wait for it be a full release.
I noticed on the 64bit build, npc animations were very sluggish as if the game was running at 15-20 frames a second
Waiting for release
Runs fine for me so far.
Can i play with the x64 builds on servers without suffering any anomalies?
I just encountered this oddity: rotating objects with the physgun and pressing shift will snap to 45-degree angles, but not 90-degree angles, in some of the axes. I don't have this issue when picking 32-bit when launching Garry's Mod.
Here's a video of it:
Kinda dumb question, is it a 64bit build just to fix the ~4gb allocation limit or does it also introduce a 64bit position system ?
It's for macos support actually
does it also introduce a 64bit position system (Fixing the z-fighting, for example)
Highly doubt it. Floating point precision is an entirely different issue. I would imagine changing it would require changes to nearly everything in the engine (vphysics, rendering, shader code, networking, god knows what else).
There's a new voice codec on this branch now. It might still need some tweaking.
If you guys actually get to implementing Chromium I will literally owe all of you BJs for life.
Understood, what about the precision loss with CurTime() ?
I don't know shit about how the Lua VM works, does it raise some limits (Int Limits, float precision etc ?)
Is there any other unlisted changes like @cogg showed ?
floats are the same size between 32-bit and 64-bit implementations.
The less I change, the sooner we'll have 64-bit builds on the default branch. Think of this as a project to port to 64-bit without anybody noticing.
Sorry, you need to Log In to post a reply to this thread.