Client performance rant

[Granger]

I mean not a NodeJS JS, but JS + WebGL to run client in browser session...

Haha, I see. No thanks.

asm.js in the browser could do the trick nicely - write in C (which you should like) then compile and run in the broweser:
https://kripken.github.io/mloc_emscript ... pcon.html/
http://www.davevoyles.com/2015/07/07/as ... al-engine/
http://beta.unity3d.com/jonas/WebGLBenchmark/

?

[algorithm]

asm.js in the browser could do the trick nicely - write in C (which you should like) then compile and run in the broweser:
https://kripken.github.io/mloc_emscript ... pcon.html/
http://www.davevoyles.com/2015/07/07/as ... al-engine/
http://beta.unity3d.com/jonas/WebGLBenchmark/
?

I can help Loftar here. Everything except rendering itself(GPU side, becouse of WebGL, and this is debatable too, becouse it uses simplified stack of GLES no GL) will be slower. Main goal here not to use C or something like that(as i know if you have llvm front for that language - you can compile it in every llvm back, and JS one of them, with some restrictions of course), but estimate complexity of CPU side logic - if it can fit JS(which is about 2 times slower and uses about 2 times more RAM, in average, and without normal native thread support and etc, etc) - than you can do it. Loftar thinks it's not. I can't debate here, becouse I didn't know how client is built at all.

[loftar]

asm.js in the browser could do the trick nicely - write in C (which you should like) then compile and run in the broweser:

Well, the main question is perhaps "why". Sure, if I had a stand-alone client written in C, there'd probably be no hurt in trying to compile it for asm.js as well, if only to benchmark it thusly. :)

I don't really see any significant benefit to making it a primary target, though, and all the uncertainties in how it would perform and behave in different browsers and everything doesn't seem like something I'd want to "support". Indeed that Unity link wouldn't even run on my browser, and yet I imagine this to be something relatively important for the Unity folks.

[razfen]

Heyy! Loftar, have you given a thought of tossing jogl into the trash bin?

I just found this: https://www.lwjgl.org/ it might be worth your time to check it out. Best of luck though!

[shubla]

Heyy! Loftar, have you given a thought of tossing jogl into the trash bin?

I just found this: https://www.lwjgl.org/ it might be worth your time to check it out. Best of luck though!

Jogl has bindings for the latest opengl version 4.5 so I dont see what would be the advantage on switching off from it other than some more work.

[romovs]

Btw loftar since you're already tinkering with rendering, have you considered switching from AWT to NEWT?
It solves that annoying issue with hardware cursors under X11 and also has proper support for full-screen mode and resolution changing (both on Linux and Windows. Presumably it works on OS X as well).
I tried to do that last year and overall it was a relatively smooth transition (even considering there was a need to make an adapter between AWT and NEWT keyboard/mouse events because of remotely loaded classes). Although I ended up scrapping it because someone complained about performance issues on ATI cards. Maybe that was just due to JOGL version update or me messing up something, didn't bother to investigate.

[APXEOLOG]

Jogl has bindings for the latest opengl version 4.5 so I dont see what would be the advantage on switching off from it other than some more work.

Btw loftar since you're already tinkering with rendering, have you considered switching from AWT to NEWT?
It solves that annoying issue with hardware cursors under X11 and also has proper support for full-screen mode and resolution changing (both on Linux and Windows. Presumably it works on OS X as well)

That's an example of why one would like to use LWJGL (it's based on http://www.glfw.org/)

[Malkiah]

- Really small percentage of vertices out of total drawn with large percentage of batches.

What does this mean?

Sorry I should have explained better.

By batch they refer to vertex drawing functions.
Statistics on the screenshot are per application run. Logged in and stood in a middle of the village for a minute or so.

A more detailed view of the aggregation from the first screenshot.


So essentially, there is large amount of batches (69% out of the total) that draw relatively small amount of vertices each (between 6 to 1728).
Unfortunately it doesn't show the statistics at a frame level nor actual function calls, so hard to make out the specifics from this.

This reinforces the same data I found and complained about years back about far too many draw calls, and high batch counts. I believe I suggested at the time Loftar look into using an texture atlas for any of the game objects that share the same material but differ in texture. But looking back he never responded back in that thread.

3000-4000+ draw calls is terrifying, a GPU can only squeeze so much into the window of 16ms.

[Gensokyo]

I fear the game is even worse on CPU usage, especially for animations.

[shubla]

I fear the game is even worse on CPU usage, especially for animations.

I don't know that much about the subject but lots of CPU resources are used when the client has to pass all these draw calls to into the GPU each frame.