GMod - What are you working on? September 2017 (#73)

[Darrell]

[QUOTE=Nak;52690726]Took a copy of the screen, rendered the rain and then re-drew the screen with alpha. Damn source limits.
Surprisingly it doesn't take much to render it, only 2-4 FPS on my side.[/QUOTE]

You sir, are genius. Solved my problem with a "death" screen. Props to you!

[Bobblehead]

Someone posted some cool shit about a ragdoll fighting GM a couple months ago and I figured out the other day how they did that thing.

So I, too, have done that thing.

[video=youtube;UN9ZSu9k5U0]http://www.youtube.com/watch?v=UN9ZSu9k5U0[/video]

[Murica]

Working on a VLCC oil tanker no lag.

[IMG]https://steamuserimages-a.akamaihd.net/ugc/856104292500339218/EE456E2EB1DA86C5BF41B9EBDAF8B65530DC2DF6/[/IMG]

[MeepDarknessM]

[url]https://gist.github.com/meepdarknessmeep/5566c9598e0e610e5885d12fad2ec3a8[/url]

Improving hooks, it improves the performance up to 750x the old hook.Call code

I am really looking for owners of huge player count servers to test this on their server
you can add newhook.lua to the base lua folder and replace lua/includes/modules/hook.lua with hook.lua

So far I've got unconfirmed tests on a listen server of improving the fps 16.4% seconds per frame with tons of addons

[FPtje]

[QUOTE=MeepDarknessM;52707999][url]https://gist.github.com/meepdarknessmeep/5566c9598e0e610e5885d12fad2ec3a8[/url]

Improving hooks, it improves the performance up to 750x the old hook.Call code

I am really looking for owners of huge player count servers to test this on their server
you can add newhook.lua to the base lua folder and replace lua/includes/modules/hook.lua with hook.lua

So far I've got unconfirmed tests on a listen server of improving the fps 16.4% seconds per frame with tons of addons[/QUOTE]

Optimizing where it matters. Good job!

[A1steaksa]

[QUOTE=MeepDarknessM;52707999][url]https://gist.github.com/meepdarknessmeep/5566c9598e0e610e5885d12fad2ec3a8[/url]

Improving hooks, it improves the performance up to 750x the old hook.Call code

I am really looking for owners of huge player count servers to test this on their server
you can add newhook.lua to the base lua folder and replace lua/includes/modules/hook.lua with hook.lua

So far I've got unconfirmed tests on a listen server of improving the fps 16.4% seconds per frame with tons of addons[/QUOTE]

Is there some secret method that makes this work? How is it so much more efficient?

[MDave]

[QUOTE=MeepDarknessM;52707999][url]https://gist.github.com/meepdarknessmeep/5566c9598e0e610e5885d12fad2ec3a8[/url]

Improving hooks, it improves the performance up to 750x the old hook.Call code

I am really looking for owners of huge player count servers to test this on their server
you can add newhook.lua to the base lua folder and replace lua/includes/modules/hook.lua with hook.lua

So far I've got unconfirmed tests on a listen server of improving the fps 16.4% seconds per frame with tons of addons

[lua]
local function loadtable(size)
local t = CompileString("return {"..("nil,"):rep(size - 1).."1}", "loadtable")()
t[size] = nil
return t
end
[/lua]
[/QUOTE]

I refuse to believe this hack is faster than letting a table reallocate once in a while..

Otherwise it is a nice idea, but it takes things a bit too far at some places.

[aStonedPenguin]

[QUOTE=a1steaksa;52708239]Is there some secret method that makes this work? How is it so much more efficient?[/QUOTE]

A for loop is faster than pairs in LuaJIT, plus all the micro-optimizations in there.

[bigdogmat]

[QUOTE=MeepDarknessM;52707999][url]https://gist.github.com/meepdarknessmeep/5566c9598e0e610e5885d12fad2ec3a8[/url]

Improving hooks, it improves the performance up to 750x the old hook.Call code

I am really looking for owners of huge player count servers to test this on their server
you can add newhook.lua to the base lua folder and replace lua/includes/modules/hook.lua with hook.lua

So far I've got unconfirmed tests on a listen server of improving the fps 16.4% seconds per frame with tons of addons[/QUOTE]

Very nice. One minor bug though, when overwriting a hook or removing one, it doesn't check which name it's making changes to. This isn't an issue when you're only dealing with string names, but for example if you have multiple entities using the same function, it'll overwrite/remove the one added first. Just check to make sure id_table[i] is the same as name when name is not a string.

[MeepDarknessM]

[QUOTE=MDave;52708321]I refuse to believe this hack is faster than letting a table reallocate once in a while..

Otherwise it is a nice idea, but it takes things a bit too far at some places.[/QUOTE]

the thing is luajit doesn't seem to ever "reallocate" array parts of tables, so we force it to use the array part by doing that. If you remove that it will slow up a *ton*. I have personally tested it and can give you numbers later or you can do it yourself.

[QUOTE=bigdogmat;52708382]Very nice. One minor bug though, when overwriting a hook or removing one, it doesn't check which name it's making changes to. This isn't an issue when you're only dealing with string names, but for example if you have multiple entities using the same function, it'll overwrite/remove the one added first. Just check to make sure id_table[i] is the same as name when name is not a string.[/QUOTE]

Thanks, I hope I fixed it, haven't tested it.

[c👌de_g🎷]

[QUOTE=MeepDarknessM;52708426]the thing is luajit doesn't seem to ever "reallocate" array parts of tables, so we force it to use the array part by doing that. If you remove that it will slow up a *ton*. I have personally tested it and can give you numbers later or you can do it yourself.

Thanks, I hope I fixed it, haven't tested it.[/QUOTE]

Is this something JIT does purposefully?

[CapsAdmin]

Speaking of stupid ways to optimize I was trying to move function calls to Lua which showed some performance benefit. In LuaJIT 2.0 when making a C call the JIT compiler will fallback to interpreter mode. It's difficult to avoid in GLua given all the C calls everywhere but this helps a little bit in some cases. I also believe upgrading to 2.1 will also help a lot as it does something called "trace stitching" instead when making C calls.

[url]https://gist.github.com/CapsAdmin/0d9c1e77d0fc22d910e182bfeb9812e5[/url]

This moves the type and is* functions to lua (so luajit can jit compile code). It moves player.GetAll(), ents.GetAll(), etc to Lua by keeping a list on the lua side.

I didn't test it that much but it seemed to work. Maybe not all of those optimizations will work under some very specific circumstances but you could take some of it maybe. I was working on moving the panel __index functions and whatnot to Lua but I got stuck somewhere.

You have to include this before everything in init.lua and call LUAIFY_POST() at the bottom of init.lua

[editline]22nd September 2017[/editline]

Has anyone gotten the jit utilities working in gmod? (like -jdump and such in luajit.exe) I haven't tried it myself but it should be easy. Maybe you'll have to put everything in one file or something though.

If we have that working we can inspect how things are getting compiled.

[MeepDarknessM]

[QUOTE=CapsAdmin;52708466]Speaking of stupid ways to optimize I was trying to move function calls to Lua which showed some performance benefit. In LuaJIT 2.0 when making a C call the JIT compiler will fallback to interpreter mode. It's difficult to avoid in GLua given all the C calls everywhere but this helps a little bit in some cases. I also believe upgrading to 2.1 will also help a lot as it does something called "trace stitching" instead when making C calls.

[url]https://gist.github.com/CapsAdmin/0d9c1e77d0fc22d910e182bfeb9812e5[/url]

This moves the type and is* functions to lua (so luajit can jit compile code). It moves player.GetAll(), ents.GetAll(), etc to Lua by keeping a list on the lua side.

I didn't test it that much but it seemed to work. Maybe not all of those optimizations will work under some very specific circumstances but you could take some of it maybe. I was working on moving the panel __index functions and whatnot to Lua but I got stuck somewhere.

You have to include this before everything in init.lua and call LUAIFY_POST() at the bottom of init.lua

[editline]22nd September 2017[/editline]

Has anyone gotten the jit utilities working in gmod? (like -jdump and such in luajit.exe) I haven't tried it myself but it should be easy. Maybe you'll have to put everything in one file or something though.

If we have that working we can inspect how things are getting compiled.[/QUOTE]

I did try to recompile my own luajit into gmod with hooks [url=https://github.com/meepdarknessmeep/gluajit]here[/url] to debug and stuff with. You could try fixing it since it would have the vmdef table so you can natively run the jdump code

[bigdogmat]

[QUOTE=MeepDarknessM;52708426]
Thanks, I hope I fixed it, haven't tested it.[/QUOTE]

Remove needs the same check, otherwise looks good.

[EthanTheGreat]

LuaJIT has it's benefits and it's draw-backs.

Since LuaJIT is a scripting API and an interpreter(string compiler), it makes more sense to me that C++ is the best alternative for game-development over GLUA.
Lua reduces performance, but I can't say exactly tell you by how much. (For arguments sake 50%). But you probably suspected that already!

LuaJit is often single-threaded. Without any adaptation for mutexes(very difficult to multi-thread without C++), or cross thread support.
It's been too long since I've used LuaJit inside gmod, but I remember having huge issues relying on it to do heavy mathematical computations for my vehicle physics.
(I had to loop through the algorthim 4 times every tick, which limits the FPS since I ran it every tick).

So if you're looking for a performance increase, switch to C++. Unfortunately there's a limited amount of things you're capable of when dealing with LuaJIT embeded into C++.
Hooks and calls are what LUA strives greatly for. Infact I can say without a doubt LUA has it's perks when it comes to simplicity.

[QUOTE=StonedPenguin;52708359]A for loop is faster than pairs in LuaJIT, plus all the micro-optimizations in there.[/QUOTE]

Very true, sorted pairs exist in C++, but they're often avoided because of performance draw-backs.
I stick to for loops because it's linear when it comes down to assembly, any sorting algorithm takes longer to swap. [B]Pair loops[/B] are actually 2D array loops.

GLua

local playerTable = player.GetAll();
for I, V in pairs(playerTable ) do...

Compiles inside LuaGit's Validator, then into Assembly using LuaJIT IDE.

C++:

std::vector<PlayerStruct> Players;
for( int I = 0; i < Players.Size(); I++){
auto V = Players[i];
}

Compiles directly into Assembly using an IDE.

Generally, Lua has to be glued together with C++.
Not even just computation and compile time, but run-time issues still play a factor in LuaJits performance. Since it has to be interpreted and ran in the LuaJit Drivers.

If you can wrap your head around C++, you can achieve everything done in lua but with less performance costs. LUA also requires more RAM memory storage.
Stick to C++ if you need high precision calculations done quickly. Lua has simplicity over efficiency, but that's what made Garry's Mod so great. It was the foundation of
programming languages to me. I wouldn't be here without GLUA, but I felt like I needed to speak up about this huge difference.

Please forgive me for being biased, but I wanted to present you with some incite.

[Yashirmare]

Can you tell I've been doing a lot of random stuff with weapons recently?
[vid]https://giant.gfycat.com/AshamedClosedHalicore.webm[/vid]
Incendiary Rounds: Your primary weapon now fires incendiary rounds (Burns for 0.5 secs, so about 3 extra dmg per shot)

[Bobblehead]

[QUOTE=EthanTheGreat;52708746]If you can wrap your head around C++, you can achieve everything done in lua but with less performance costs. LUA also requires more RAM memory storage.
Stick to C++ if you need high precision calculations done quickly. Lua has simplicity over efficiency, but that's what made Garry's Mod so great. It was the foundation of
programming languages to me. I wouldn't be here without GLUA, but I felt like I needed to speak up about this huge difference.[/QUOTE]

Don't forget that C++ being a compiled language without scope limitations (such as OS file management) the potential for viruses and security issues goes through the roof. Lua is great for GMod because it can be limited to do only what the developers allow it to do.

Furthermore, Lua being an interpreted rather than compiled language means joining a server with custom scripts is as easy as downloading some lua text files and interpreting them, rather than downloading .dll files (again, security alert) and including them into the game. The Lua environment is just a lot more malleable.

C++ is great for making games, but you need an interpreted language for modding games.

[FPtje]

Ethan, C++ isn't the solution for all performance problems. Don't jump to C++ the moment you find performance problems. The biggest performance benefits can be achieved through a disciplined approach to optimizing. One that includes profiling, attacking algorithmic complexity, choosing the right data structures and all that stuff.

An O(n) Lua algorithm with big enough input is going to be faster than an O(n^3) C++ algorithm with the same input size, for example.

Consider the move to C++ [I]after[/I] the algorithmic complexity and data structures have already been optimised. You can't just blame all performance problems on the language.

[Bobblehead]

The final product:
[video=youtube;vbFgnHglTFc]http://www.youtube.com/watch?v=vbFgnHglTFc[/video]

[MDave]

[QUOTE=MeepDarknessM;52708426]the thing is luajit doesn't seem to ever "reallocate" array parts of tables[/QUOTE]
I poked a bit around in the source code available on github, but I don't see why that would be the case.

[QUOTE=MeepDarknessM;52708426]If you remove that it will slow up a *ton*. I have personally tested it and can give you numbers later or you can do it yourself.[/QUOTE]
Upon further inspection, I can see why having all values in the array part of the table speed things up significantly.

While your hack is a nice workaround, I think an API to pre/resize the array and hash part of a table should be exposed, why is there none built into Lua in the first place?

[LukeDell]

[QUOTE=bobbleheadbob;52710284]The final product:
[video=youtube;vbFgnHglTFc]http://www.youtube.com/watch?v=vbFgnHglTFc[/video][/QUOTE]

What happens when someone's killed by a shotgun? Are there multiple bullets shown, same with a machine gun?

[MeepDarknessM]

[QUOTE=MDave;52710581]
While your hack is a nice workaround, I think an API to pre/resize the array and hash part of a table should be exposed, why is there none built into Lua in the first place?[/QUOTE]

There was table.setn which did that, but was deprecated and removed in some later lua version
there's also [url=http://pgl.yoyo.org/luai/i/lua_createtable]lua_createtable[/url] which still exists but is not exposed anywhere

[Kevlon]

[QUOTE=bobbleheadbob;52710284]The final product:
[video=youtube;vbFgnHglTFc]http://www.youtube.com/watch?v=vbFgnHglTFc[/video][/QUOTE]

Did you place all the organs and shit manually or is that a different skeleton model that has all of them? Seems like a pain in the ass if you did lol

[Bobblehead]

[QUOTE=Kevlon;52711161]Did you place all the organs and shit manually or is that a different skeleton model that has all of them? Seems like a pain in the ass if you did lol[/QUOTE]

There's a bonemerged skeleton but the organs were placed manually haha

If the skeleton model ported from sniper elite which is on the workshop (which is where I got the organ models) was a playermodel instead of just a ragdoll I could bonemerge it and I wouldn't have to place the organs manually.

As for the shotgun bullets it currently only shows the one pellet which finished them.

[Shidobu]

Inspired by [URL="https://sandbox.facepunch.com/blog/devblog3/"]Sandbox Devblog 3[/URL], decided wanted to do the same with [URL="https://svelte.technology/"]Svelte[/URL] so got it working:
[video=youtube;EzQBXQJK5nY]http://www.youtube.com/watch?v=EzQBXQJK5nY[/video]

[B]svelte_test.lua[/B]:

svelte = include("svelte.lua")

-- Compiler is optional and providers an API aswell, any 'eval' compiled component script is fine
-- compiler = include("svelte.compiler.lua")
-- compiler.compile(string, function)
RunConsoleCommand("svelte_export", "data/component.txt", "component.export")
RunConsoleCommand("svelte_export", "data/component2.txt", "component2.export")

-- Compiler is running in a host Chromium panel, thus compiling is asynchronous
timer.Simple(1, function ()
	local component = file.Read("component.export.txt", "DATA")
	local component2 = file.Read("component2.export.txt", "DATA")

	u = svelte.create(component, {
		Heading = component2
	})

	u:MakePopup()
	u:SetSize(640, 380)
	u:Center()
	u:ParentToHUD()
end)

[B]component.txt[/B]:

<style>
	div {
		width: 100%;
		height: 100%;
		background-color: white;
	}
</style>

<script>
	export default {
		data () {
			return {
				name: "stranger"
			}
		},

		components: {
			Heading
		}
	}
</script>

<div class="test">
	<Heading text="Type your name:" />
	<input bind:value="name">
	<p>Hello {{name}}!</p>
</div>

[B]component2.txt[/B]:

<style>
	h1 {
		background: white;
		color: red;
	}
</style>

<h1>{{text}}</h1>

The API is more-or-less a mirror of svelte's:

--[[
	SveltePanel:
		void dispatch(string name, table data?, function callback?)
			-- Dispatches a event to the main Svelte component
			panel:dispatch("event", {x = 1})

		void get(string name, function callback)
			-- Requests the value of variable 'name' from the main Svelte component
			panel:get("name", function (value)
				print("name", value)
			end)

		function observe(string name)
			-- Any changes of variable 'name' will be replicated on the SveltePanel
			release = panel:observe("name")

			-- After variable changes in eithet Javascript or Lua states
			print(panel.name)

			-- Release the observer
			release()

		function on(string name, function callback)
			-- Any events fired by either Javascript or Lua states is recieved by the callback
			release = panel:on("event", function (data)
				print("event.x", data.x)
			end)

			-- Release the listener
			release()

		void set(table data, function callback?)
			-- Sets the variables to the main component's state
			panel:set({
				y = 1,
				z = 2
			})
]]--

Haven't tried anything serious with it yet, but got a few ideas. You can get and test it [URL="https://github.com/novacbn/svelte-gmod"]here[/URL].

[Dr. Inco]

Early attempt of creating a new ladder movement system w/ animations.
Ladder sounds don't play locally for some reason, but you can still hear other people climb shown later in the video. Bots also don't obey render angles so he sort of flips out when I turn a certain way.

[video=youtube;4LVHh4ecEzg]https://www.youtube.com/watch?v=4LVHh4ecEzg&feature=youtu.be[/video]

[Stiffy360]

[QUOTE=bobbleheadbob;52711348]There's a bonemerged skeleton but the organs were placed manually haha

If the skeleton model ported from sniper elite which is on thr workshop (which is where I got the organ models) was a playermodels instead of just a rag doll I could bonemerge it and I wouldnt have to place the organs manually.

As for the shotgun bullets it currently only shows the one pellet which finished them.[/QUOTE]

I could probably make you a playermodel from it if you'd like.

[Bobblehead]

[QUOTE=Stiffy360;52712113]I could probably make you a playermodel from it if you'd like.[/QUOTE]

I would suck a dick for that.
[url]http://steamcommunity.com/sharedfiles/filedetails/?id=210546397[/url]

[CapsAdmin]

[QUOTE=MeepDarknessM;52710978]There was table.setn which did that, but was deprecated and removed in some later lua version
there's also [url=http://pgl.yoyo.org/luai/i/lua_createtable]lua_createtable[/url] which still exists but is not exposed anywhere[/QUOTE]

In 2.1 there's table.new(narr, nrec) and table.clear(tbl) if you require them. (table.new = require("table.new"))

[MeepDarknessM]

[QUOTE=CapsAdmin;52712558]In 2.1 there's table.new(narr, nrec) and table.clear(tbl) if you require them. (table.new = require("table.new"))[/QUOTE]

too bad gmod will most likely never get luajit 2.1 :(