Next Update v5 - April 2016 Update is out!

[NeatNit]

Hey, it would actually work, like a successful Surgeon Simulator operation.

[c👌de_g🎷]

[QUOTE=Robotboy655;50459192]And fuck up every single addon that uses CurTime() for logic, including the engine itself. Great idea![/QUOTE]

Then make it a double, please.

[Zeh Matt]

[QUOTE=code_gs;50459380]Then make it a double, please.[/QUOTE]

Like thats easy to do, just grab the Source SDK 2013 and check every reference that uses CurTime (gpGlobals->curtime) whenever it assigns it to a float you are pretty much stuck fixing that reference.

While its possible to assign a double to a float you will still loose the precision by that, so I highly doubt this will ever happen.

[c👌de_g🎷]

[QUOTE=Zeh Matt;50459486]Like thats easy to do, just grab the Source SDK 2013 and check every reference that uses CurTime (gpGlobals->curtime) whenever it assigns it to a float you are pretty much stuck fixing that reference.

While its possible to assign a double to a float you will still loose the precision by that, so I highly doubt this will ever happen.[/QUOTE]

Won't it autocast to a float whenever it's manipulated by another float? I don't see the issue, honestly.

[NeatNit]

[img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/Global/CurTime]CurTime[/url]

[quote]This is internally defined as a float, and as such it will be affected by precision loss if your server uptime is more than 6 hours, which will cause jittery movement of players and props and inaccuracy of timers, it is highly encouraged to refresh or change the map when that happens (a server restart is not necessary).

This is [b]NOT[/b] easy as it sounds to fix in the engine, so please refrain from posting issues about this[/quote]

[>>oubliet]

[QUOTE=code_gs;50459498]Won't it autocast to a float whenever it's manipulated by another float? I don't see the issue, honestly.[/QUOTE]

It will autocast to a 32bit floating point (when something expects it, but gets a double instead) and lose the 64bit precision making it completely pointless.

[YourStalker]

[QUOTE=NeatNit;50459522][img]http://wiki.garrysmod.com/favicon.ico[/img] [url=http://wiki.garrysmod.com/page/Global/CurTime]CurTime[/url][/QUOTE]

Not easy ~= not possible

[c👌de_g🎷]

[QUOTE=>>oubliette<<;50459525]It will autocast to a 32bit floating point (when something expects it, but gets a double instead) and lose the 64bit precision making it completely pointless.[/QUOTE]

If a double-typed NetworkVar were added, then it would at the very least help with SWEPs and entities having bad prediction after about 6 hours.

[Willox]

[QUOTE=code_gs;50459732]If a double-typed NetworkVar were added, then it would at the very least help with SWEPs and entities having bad prediction after about 6 hours.[/QUOTE]

Adding new NetworkVars is probably not a good idea. Every one that exists is already overhead regardless of if it is being used or not.

[Zeh Matt]

[QUOTE=code_gs;50459732]If a double-typed NetworkVar were added, then it would at the very least help with SWEPs and entities having bad prediction after about 6 hours.[/QUOTE]

You could do that with lua alone.

[c👌de_g🎷]

[QUOTE=Zeh Matt;50460373]You could do that with lua alone.[/QUOTE]

Fair enough, but CurTime would still need to be a double.

[NeatNit]

It seems that [url=http://wiki.garrysmod.com/page/render/RenderView]RenderView[/url] doesn't use anti-aliasing by default, regardless of my settings. Is there a way to change that? I found nothing of the sort in [url=http://wiki.garrysmod.com/page/Structures/ViewData]ViewData[/url].

On the other hand, I noticed that offcenter was added! While I have no special use for it at this moment, it should actually come in very handy in certain situations. In particular, it can make rendering through Portals a lot faster, so instead of rendering the whole screen and cutting off most of it, you can just render the part that's relevant. Not that I'm making another portal gun, it's just a thought that crossed my mind. :smile:

[Willox]

[QUOTE=NeatNit;50461611]It seems that [url=http://wiki.garrysmod.com/page/render/RenderView]RenderView[/url] doesn't use anti-aliasing by default, regardless of my settings. Is there a way to change that? I found nothing of the sort in [url=http://wiki.garrysmod.com/page/Structures/ViewData]ViewData[/url].

On the other hand, I noticed that offcenter was added! While I have no special use for it at this moment, it should actually come in very handy in certain situations. In particular, it can make rendering through Portals a lot faster, so instead of rendering the whole screen and cutting off most of it, you can just render the part that's relevant. Not that I'm making another portal gun, it's just a thought that crossed my mind. :smile:[/QUOTE]

It works for me.

[NeatNit]

Right, sorry. Turns out my case has a bunch of other factors which I thought were irrelevant, evidently incorrectly. I'll post again with more concrete details and reproduction code if I can pinpoint it.

[editline]6th June 2016[/editline]

Seems to be when rendering into a non-default texture:
[lua]local tex, mat = render.GetSuperFPTex(), Material("pp/copy")

hook.Add("RenderScene", "AntiAliasingTest", function()
render.PushRenderTarget(tex)
render.RenderView()
render.PopRenderTarget()
mat:SetTexture("$basetexture", tex)
render.SetMaterial(mat)
render.DrawScreenQuad()
return true
end)[/lua]

Compare with:
[lua]hook.Add("RenderScene", "AntiAliasingTest", function()
render.RenderView()
return true
end)[/lua]

Also tried GetRenderTarget("dnsjasndka", ScrW(), ScrH(), false) instead of render.GetSuperFPTex(), no anti-aliasing.

[uRandomAlex]

[QUOTE=Robotboy655;50459192]And fuck up every single addon that uses CurTime() for logic, including the engine itself. Great idea![/QUOTE]
I don't think that server will be broken completely. We can just make that the WipeCurTime will fix most of the errors, i.e. all entities freezed for a second (so animation/walk distance/physics/etc. calculating based on CurTime will be stopped).

[Zeh Matt]

[QUOTE=uRandomAlex;50462811]I don't think that server will be broken completely. We can just make that the WipeCurTime will fix most of the errors, i.e. all entities freezed for a second (so animation/walk distance/physics/etc. calculating based on CurTime will be stopped).[/QUOTE]

You can not just assume every addon will function properly if you reset the time. Heres some example:

function ENT:Think()
	NextThink(CurTime() + 0.2)
	return true
end

Imagine you reset the time after this Think was executed, it will take exactly your last timestamp before its gonna call Think again.

I know you could probably go over all the Think timestamps and adjust them, this might work just fine on scripted entities however there are likely variables that have the timestamp set and nobody knows about them.

Theres just way too much too consider doing this.

[uRandomAlex]

[QUOTE=Zeh Matt;50462825]-snip-[/QUOTE]
"CurTimeReset" hook?

[Zeh Matt]

[QUOTE=uRandomAlex;50462831]"CurTimeReset" hook?[/QUOTE]

Like that will fix anything, ever considered you can not access all variables especially on non scripted entities?

You are probably better off restarting and before that just serialize every object and put it back once it restarted as nothing ever happened, why is that such a big deal?

[uRandomAlex]

[QUOTE=Zeh Matt;50462839]-snip-[/QUOTE]
I believe that GMOD developers can rewrite some of the non-scripted entities code (and that they have it) to reset all their timers on "CurTimeReset". I'm already using system that saves everything before map restart, but I think that WipeCurTime will be a better solution.

[SteppuFIN]

[QUOTE=uRandomAlex;50462982]I believe that GMOD developers can rewrite some of the non-scripted entities code (and that they have it) to reset all their timers on "CurTimeReset". I'm already using system that saves everything before map restart, but I think that WipeCurTime will be a better solution.[/QUOTE]

Why would you even need WipeCurTime? You could also just changelevel in that case. Wiping CurTime will just be more useless work and will probably break shitton of addons, and not all devs will know that people can WipeCurTime, which will make most of the addons break.

[Kevlon]

[QUOTE=uRandomAlex;50462982]I believe that GMOD developers can rewrite some of the non-scripted entities code (and that they have it) to reset all their timers on "CurTimeReset". I'm already using system that saves everything before map restart, but I think that WipeCurTime will be a better solution.[/QUOTE]

cTime = cTime or CurTime
newCTime = newCTime or 0
function CurTime()
     return (cTime() - newCTime)
end
function ResetCurTime()
     newCTime = cTime()
end

:v: ?

[Zeh Matt]

[QUOTE=Kevlon;50463328]

cTime = cTime or CurTime
newCTime = newCTime or 0
function CurTime()
     return (cTime() - newCTime)
end
function ResetCurTime()
     newCTime = cTime()
end

:v: ?[/QUOTE]

Stop this nonsense already, its easier to actually get the double type under the hood rather than doing weird shit around it.

[Kevlon]

[QUOTE=Zeh Matt;50463363]Stop this nonsense already, its easier to actually get the double type under the hood rather than doing weird shit around it.[/QUOTE]

[IMG]http://i.imgur.com/9nohQh4.jpg[/IMG]

[highlight](User was banned for this post ("Reaction Image" - UncleJimmema))[/highlight]

[jackool]

[QUOTE=Kevlon;50463369][IMG]http://i.imgur.com/9nohQh4.jpg[/IMG][/QUOTE]

It's good he posted that, you don't want novice developers coming in this thread getting the wrong idea on how to do something in a bad/useless way.
Overriding the Lua CurTime function and returning something else wouldn't help with the precision issue and could even break stuff, regardless of it being a joke.

[c👌de_g🎷]

[QUOTE=jackool;50464930]It's good he posted that, you don't want novice developers coming in this thread getting the wrong idea on how to do something in a bad/useless way.
Overriding the Lua CurTime function and returning something else wouldn't help with the precision issue and could even break stuff, regardless of it being a joke.[/QUOTE]

I think the few novice developers that read this that would implement his code would find out the problem for themselves soon enough.

[jackool]

[QUOTE=code_gs;50466455]I think the few novice developers that read this that would implement his code would find out the problem for themselves soon enough.[/QUOTE]

Not a bad point, still doesn't hurt to post that you shouldn't do it though.
I used to search Google filtering for Facepunch.com, and some threads didn't explain things well - the more details the better even if it's something basic.
You never know. This game is well known for copy pasta of random code ending up all over the place with small edits.

... or maybe I have something against crude paint memes and my sense of humor sucks V:v:V sorry

[Willox]

Changes to queued rendering are on the dev branch. I can't find any issues, so it'd be nice if anybody who has weird render-y stuff could test it.

To enable queued rendering:

gmod_mcore_test 1
mat_queue_mode -1
cl_threaded_bone_setup 1 // Not strictly rendering, but it works now and will help if you are viewing lots of NPCs

Queued rendering has a couple of drawbacks. If you wan't to queue millions of render calls doing something weird like calling surface.DrawRect for every pixel on the screen, it'll die.

It'd be interesting to hear of any notable changes in performance anybody encounters.

[Revenge282]

[QUOTE=Willox;50467981]Changes to queued rendering are on the dev branch. I can't find any issues, so it'd be nice if anybody who has weird render-y stuff could test it.

To enable queued rendering:

gmod_mcore_test 1
mat_queue_mode -1
cl_threaded_bone_setup 1 // Not strictly rendering, but it works now and will help if you are viewing lots of NPCs

Queued rendering has a couple of drawbacks. If you wan't to queue millions of render calls doing something weird like calling surface.DrawRect for every pixel on the screen, it'll die.

It'd be interesting to hear of any notable changes in performance anybody encounters.[/QUOTE]

Seems to be working flawlessly so far. Why do you recommend mat_queue_mode -1, rather than 2?

Tested with -1 and 2 and there were no anomalies.

[uRandomAlex]

[QUOTE=Willox;50467981]-snip-[/QUOTE]
What about r_queued_* commands? Are they removed or replaced?

[Willox]

[QUOTE=Revenge282;50468043]Seems to be working flawlessly so far. Why do you recommend mat_queue_mode -1, rather than 2?

Tested with -1 and 2 and there were no anomalies.[/QUOTE]

Both will achieve the same thing on literally any modern computer. -1 is the default so I reckon it makes more sense to use that.

[QUOTE=uRandomAlex;50468050]What about r_queued_* commands? Are they removed or replaced?[/QUOTE]

Most of them didn't do anything (or were a waste of time to fix). If the command still exists in the console's auto-complete, it does something.