DevStream 20191026, 19:00 UTC

Announcements about major changes in Haven & Hearth.

DevStream 20191026, 19:00 UTC

Postby jorb » Thu Oct 24, 2019 6:40 pm

That time of the month, thus:

DevStream, 20191026, Saturday, 19:00 UTC. Loftar will be on, and we will dedicate the stream almost exclusively to a discussion about the fighting system, where we are, our analysis and hot takes, and where we're going. Be there to opine if you know it all.

http://twitch.tv/bruderbohne

Catch you there!

EDIT: YouTube upload
"The psychological trials of dwellers in the last times will be equal to the physical trials of the martyrs. In order to face these trials we must be living in a different world."

-- Hieromonk Seraphim Rose
User avatar
jorb
 
Posts: 18263
Joined: Fri Apr 03, 2009 7:07 am
Location: Here, there and everywhere.

Re: DevStream 20191026, 19:00 UTC

Postby nardyman8501 » Thu Oct 24, 2019 6:42 pm

Nice
Think like men of action.
Act like men of thought.
Live life with intensity
and a passion for excellence.

---Gen. James Mattis
User avatar
nardyman8501
 
Posts: 63
Joined: Thu Jul 26, 2012 10:31 pm
Location: South of Hell

Re: DevStream 20191026, 19:00 UTC

Postby jorb » Sat Oct 26, 2019 10:36 pm

Thanks a lot, guys! It was a lot of fun, and I think we decided to keep working on what we have. YouTube upload.
"The psychological trials of dwellers in the last times will be equal to the physical trials of the martyrs. In order to face these trials we must be living in a different world."

-- Hieromonk Seraphim Rose
User avatar
jorb
 
Posts: 18263
Joined: Fri Apr 03, 2009 7:07 am
Location: Here, there and everywhere.

Re: DevStream 20191026, 19:00 UTC

Postby sMartins » Mon Oct 28, 2019 9:43 pm

Impressive, I'd say Jigsaw are falling into place :)

"Cedete lo passo" tu (ENG sub)
I'd hardly call anything the Bible of our times » special thanks to MagicManICT
I only logged in to say this sentence. by neeco » 30 Oct 2018, 02:57
Default Client, Best Client!
User avatar
sMartins
 
Posts: 2851
Joined: Wed Nov 11, 2015 10:21 pm
Location: Italy

Re: DevStream 20191026, 19:00 UTC

Postby Granger » Tue Oct 29, 2019 11:09 am

Having watched the replay, some comments:

Next time you test it would be a good idea to setup one of your local systems to have relevant higher latency, in case that changes the average outcome of your sparring tests... some more time on the drawing board to come up with something that is more lag-agnostic would certainly be helpful, to not turn the stat- into a latency-check.

Regarding 'client input lag': could it be that the click-hit test is performed on the next frame instead of the one the user saw when he actually clicked onto something? Could explain why eg. herbs are difficult (to impossible) to click while moving, the bigger the window the worse (as of lower framerate from the old gfx card that struggles to cope with a screen 6 times as big as it was ment to handle, less FPS = more delta in position of the object between frames = object no longer at the click point in the next frame).

Last regarding RSI: the CPS rate I heard in the stream completely discourages me from practicing combat, no game is worth wrecking my health. Hence, please, give cowards like me a way to flee from unilateral combat (while leaving some loot behind to have the aggressors not come up empty).
⁎ Mon Mar 22, 2010 ✝ Thu Jan 23, 2020
User avatar
Granger
 
Posts: 9263
Joined: Mon Mar 22, 2010 2:00 pm

Re: DevStream 20191026, 19:00 UTC

Postby iamahh » Tue Oct 29, 2019 1:26 pm

reading about AoE netcode I remember metering was important, so maybe this is a chance to have a server-side combat replay system, maybe instanced around the combat area only
iamahh
 
Posts: 1810
Joined: Sat Dec 12, 2015 8:23 pm

Re: DevStream 20191026, 19:00 UTC

Postby loftar » Tue Oct 29, 2019 10:44 pm

Granger wrote:Regarding 'client input lag': could it be that the click-hit test is performed on the next frame instead of the one the user saw when he actually clicked onto something?

That certainly is the case, and whether it should be the case is a larger question. The reason it is so is, of course, that the click-test information is only rendered when necessary, and the alternative would be to render it every frame, regardless of whether it's useful. I have certainly considered changing to that many times, but there are good arguments both for and against.

The arguments against it is obviously first and foremost the potential hit to performance. That being said, if the click-test info is being rendered as part of the main render pass, the performance hit would be less than it currently is for those frames where it is in fact rendered, so it's a bit of an argument both for and against. More than that, however, it also requires a lot more memory, since I couldn't reuse render targets the way I currently do; and also especially if MSAA is enabled, since all render targets need to be MSAA'd together. On 1920x1080 with 4xMSAA, the framebuffer just for the click-info would be 100 MB of VRAM; I'm honestly not sure how much that matters on current iGPUs, but there is a case to be made that if you want to use MSAA, you should be prepared to have the VRAM for it.

The main argument for it is the reduction in input latency that it would entail, which would be quite nice. It would also be possible to do "mouse-over tests" the way the Legacy client can do, which would also be a nice ability to have. As regards the performance issue, it is true (as already mentioned) that a combined render-and-click pass would take less performance than separate ones, which would be nice, but there's also a case to be made that more consistent performance is actually better than strictly high performance (and using more render-time for frames with click-testing does have a tendency to make performance inconsistent around those frames).

All that being said and considered, I am actually leaning towards changing it.
"Object-oriented design is the roman numerals of computing." -- Rob Pike
User avatar
loftar
 
Posts: 8926
Joined: Fri Apr 03, 2009 7:05 am

Re: DevStream 20191026, 19:00 UTC

Postby Granger » Wed Oct 30, 2019 1:40 am

IIRC: the client main-loop basically is: there is a data structure (that is provided by the server) that is used in conjunction with asset data to render the image (which is double- (or triple) -buffered to avoid flickering), after rendering a frame is completed it's queued to be displayed on next VSYNC and rendering pauses so the netcode can update the data structure with updates from the server - rinse&repeat.

Somewhere in there the user generates inputs (key press/release, mouse movement/clicks), which get processed at some point - currenty (in case I understood you correctly) at a point in time where the data structure might have already been updated to reflect the next frame, leading to any tests being done on the new state but with coordinates the user selected according to the prior state, leading to misclicks.

Thought experiment:

How about triple-/quad-buffering the data structure instead?

one muteable future data structure that can freely be updated by the net-code,
one frozen next frame the renderer is currently working on,
one frozen current frame that is (or will at VSYNC) on-screen, UI events are queued here for the click-test code to operate on
additional past frames in case the click-test code lags

Organized as a simple double-linked list where each node has one lock.

Each time the netcode receives data from the server it tries to take the lock on the head of the list (the future), applies to that structure, releases the lock, repeats - in case it fails to take the lock it'll create a copy of the head node that, from that point on is immutable per definition) into a new node, takes its lock, puts the node at the front of the list and continues with whatever it tried to do on the now next frame data, but on the new future it just created.

The renderer holds the lock of the next frame while doing what it does on that (per definition) static data structure (no further locking in the actual render path), when done heads out to wait on the lock of the node one up the list (the future) and as soon as that's taken releases the one it held before.

The UI holds the current frame, queuing any user interaction events to it, while waiting for VSYNC. When that happens it tries to aquire the lock one up the chain (next frame, in case it can take it it'll flip framebuffers (displaying the new image, turning the next into the [/i]current[/i] frame) and release the lock on the node it held before (turning it into a past frame) to continue what it did (just with the now current frame).

The hit-test is waiting on the current frame lock, as soon as it took it that frame will be in the past and any user events queued can be processed, if needed by rendering click-test information in parallel to the main renderer (without getting in the way, preferably also with a reduced set of data as it could cull, like based on hitboxes, what can't be in the way) and when done destroys the node it just completed to waits on the lock one up the chain.


Wouldn't that give somewhat deterministic (but small) 'input lag', while making sure that any hit tests are performed on the image the user actually clicked on - without blocking the actual renderer?
⁎ Mon Mar 22, 2010 ✝ Thu Jan 23, 2020
User avatar
Granger
 
Posts: 9263
Joined: Mon Mar 22, 2010 2:00 pm

Re: DevStream 20191026, 19:00 UTC

Postby loftar » Fri Nov 08, 2019 5:41 pm

Granger wrote:Wouldn't that give somewhat deterministic (but small) 'input lag', while making sure that any hit tests are performed on the image the user actually clicked on - without blocking the actual renderer?

Not totally satisfactorily. The input latency would still include the time needed to render the click-data (also including any latency to complete current rendering operations), which would make it about equal to the current implementation in terms of input latency. The advantage of always rendering the click-data would be that the data is already available immediately when the click event is received from the windowing system, which I think it is fair to say would constitute the minimum possible amount of input latency. The only problem it would solve would be that of matching the click testing against the currently visible data, which would also be solved by the always-click-test strategy. It would also not solve the problem that rendering click-data in addition to normal rendering is more expensive than rendering both at once.

It's also completely at odds with the current client architecture, which modifies the relevant data structures in-place.
"Object-oriented design is the roman numerals of computing." -- Rob Pike
User avatar
loftar
 
Posts: 8926
Joined: Fri Apr 03, 2009 7:05 am

Re: DevStream 20191026, 19:00 UTC

Postby shubla » Thu Nov 14, 2019 11:09 pm

loftar wrote: On 1920x1080 with 4xMSAA, the framebuffer just for the click-info would be 100 MB of VRAM; I'm honestly not sure how much that matters on current iGPUs, but there is a case to be made that if you want to use MSAA, you should be prepared to have the VRAM for it.

Partial reason why we have so shitty client is that you assume that everyone uses 20 year old computers to play this game forcing you to use like opengl 2.1. Making majority of the playerbase to suffer because you want to support hardware of the three russians that play this game with toasters is just dumb. I think that it is safe to assume that people have at least the technology that 10 years ago or so released hardware supports.

https://store.steampowered.com/hwsurvey
Valve periodically collects some data about hardware of their users.
Image
For example, this is table of VRAM.

One perhaps interesting statistic is DX10/11/12, we can see that more than 90% of users have DX12, which was released in 2015, so they most likely have at least opengl 4.5 or something like that.

This small ḿinority of people with old PCs, you should just ignore them. If they cannot afford to buy a new computer in 10 years they probably cannot afford to play your game either.
Image
I'm not sure that I have a strong argument against sketch colors - Jorb, November 2019
http://i.imgur.com/CRrirds.png?1
Join the moderated unofficial discord for the game! https://discord.gg/2TAbGj2
Purus Pasta, The Best Client
User avatar
shubla
 
Posts: 13043
Joined: Sun Nov 03, 2013 11:26 am
Location: Finland

Next

Return to Announcements

Who is online

Users browsing this forum: Naylok, Python-Requests [Bot] and 16 guests