Client performance rant

Forum for alternative clients, mods & discussions on the same.

Re: Client performance rant

Postby loftar » Thu Jun 08, 2017 12:00 pm

algorithm wrote:JavaScript?

Three issues with that are:
  • There are parts of the downloaded code where performance is kind of important. Perhaps not crucially important, but important enough that it would be a pity to downgrade it in performance to the extent that JavaScript or any other dynamic language would imply.
  • Incorporating a dynamic language also implies writing glue code for any interface that code written in it would need to touch.
  • libv8 is larger than the entire rest of the whole client is likely to be.

Not to mention, the question remains "why". It is not a priori obvious that any performance gains would even be realized from rewriting the client in C/C++. The main reason I've considered it is really just to transfer the client to a language that I like, unlike Java.
"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: Client performance rant

Postby algorithm » Thu Jun 08, 2017 12:51 pm

loftar wrote:
algorithm wrote:JavaScript?

Three issues with that are:
  • There are parts of the downloaded code where performance is kind of important. Perhaps not crucially important, but important enough that it would be a pity to downgrade it in performance to the extent that JavaScript or any other dynamic language would imply.
  • Incorporating a dynamic language also implies writing glue code for any interface that code written in it would need to touch.
  • libv8 is larger than the entire rest of the whole client is likely to be.

Not to mention, the question remains "why". It is not a priori obvious that any performance gains would even be realized from rewriting the client in C/C++. The main reason I've considered it is really just to transfer the client to a language that I like, unlike Java.


I mean not a NodeJS JS, but JS + WebGL to run client in browser session... And with C/C++ there is a lot of libraries/frameworks, even small, that can help you with crossplatform development.

And a little question - why do you prefer OpenGL 2.1 over 3.3? I'm not a good expert in rendering pipelines, but as i know it can help you speedup mass rendering... As i know there is a lot of draw calls for rendering scenes in current version(for each object instance, even for each piece of armor, tell me if i wrong), but mostly each game engine tries to reduce it a lot, and with OpenGL 2.1 immediate mode rendering it's almost near to impossible to achieve.
algorithm wrote:Cape awarded? ;)

jorb wrote:Oh, for sure. Delivery 2022. ;)
algorithm
 
Posts: 216
Joined: Thu Aug 13, 2015 2:17 pm

Re: Client performance rant

Postby loftar » Thu Jun 08, 2017 1:44 pm

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

Haha, I see. No thanks. :)

algorithm wrote:And a little question - why do you prefer OpenGL 2.1 over 3.3?

I don't really, but there are lots of OpenGL drivers out there that simply don't support OpenGL 3, so that's why.

algorithm wrote:I'm not a good expert in rendering pipelines, but as i know it can help you speedup mass rendering... As i know there is a lot of draw calls for rendering scenes in current version(for each object instance, even for each piece of armor, tell me if i wrong), but mostly each game engine tries to reduce it a lot, and with OpenGL 2.1 immediate mode rendering it's almost near to impossible to achieve.

That being said, though, I don't think OpenGL 3 would help with any of this. Also, the only place where immediate mode is used is in the 2D drawing of the UI. While I do plan to remove that in the rewrite, I don't think it has caused any performance issues.
"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: Client performance rant

Postby algorithm » Thu Jun 08, 2017 2:37 pm

loftar wrote:I don't really, but there are lots of OpenGL drivers out there that simply don't support OpenGL 3, so that's why.


It's 2010(7 years) for 3.3, 2009 for 3.2. Is it a problem inside community with that old hardware?(If it is - ok no more questions about).

loftar wrote:Also, the only place where immediate mode is used is in the 2D drawing of the UI.


glBegin()/glEnd() = immediate mode as far as i understand it. So there is a lot of issues with it, according to internet and as I see in code - You prefer it over glDrawArrays()...
algorithm wrote:Cape awarded? ;)

jorb wrote:Oh, for sure. Delivery 2022. ;)
algorithm
 
Posts: 216
Joined: Thu Aug 13, 2015 2:17 pm

Re: Client performance rant

Postby loftar » Thu Jun 08, 2017 2:42 pm

algorithm wrote:It's 2010(7 years) for 3.3, 2009 for 3.2. Is it a problem inside community with that old hardware?(If it is - ok no more questions about).

I don't actually have any precise statistics, but I continually see OpenGL 2 implementations among the client error reports I get, so I'd say it seems common enough.

algorithm wrote:glBegin()/glEnd() = immediate mode as far as i understand it. So there is a lot of issues with it, according to internet and as I see in code - You prefer it over glDrawArrays()...

As I said, the 3D rendering code doesn't actually use it, only the 2D code, and the 2D drawing doesn't actually take any significant part of the frame time, so it wouldn't seem to be a problem. That being said, as I also said, I do plan to remove it in the rewrite. It's mostly a remnant of an earlier era.
"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: Client performance rant

Postby algorithm » Thu Jun 08, 2017 2:47 pm

loftar wrote:As I said, the 3D rendering code doesn't actually use it, only the 2D code, and the 2D drawing doesn't actually take any significant part of the frame time, so it wouldn't seem to be a problem. That being said, as I also said, I do plan to remove it in the rewrite. It's mostly a remnant of an earlier era.


I need to read code more carefully next time - with little bit more time spent, i've found it. :cry:
algorithm wrote:Cape awarded? ;)

jorb wrote:Oh, for sure. Delivery 2022. ;)
algorithm
 
Posts: 216
Joined: Thu Aug 13, 2015 2:17 pm

Re: Client performance rant

Postby algorithm » Thu Jun 08, 2017 3:27 pm

loftar wrote:I don't actually have any precise statistics, but I continually see OpenGL 2 implementations among the client error reports I get, so I'd say it seems common enough.


According to this You wont move to Vulkan anyway.
algorithm wrote:Cape awarded? ;)

jorb wrote:Oh, for sure. Delivery 2022. ;)
algorithm
 
Posts: 216
Joined: Thu Aug 13, 2015 2:17 pm

Re: Client performance rant

Postby loftar » Thu Jun 08, 2017 3:57 pm

algorithm wrote:According to this You wont move to Vulkan anyway.

When I do implement Vulkan, I would offer it in addition to OpenGL 2, not instead of.
"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: Client performance rant

Postby tirioll » Thu Jun 08, 2017 4:39 pm

loftar wrote:
Lizard_Paszczyk wrote:C++ is much faster...

That is debatable. It has been like 20 years since Java was slow.

But yes, I have considered it from time to time. Besides the prospect of rewriting everything, though, what I'm relying on the most right now in Java is the ability to load and run downloaded code in a platform-independent way, which I don't really have any alternative for in C/C++ that I have found to my liking.

Runescape has gone a long way and has a big team working on it. They were in Java for ages. Then rewrote everything in JS/HTML5, there was even live beta, but performance was not good. And now they are rewrote the client in C++ and gradually phasing out Java. On my mediocre laptop, the C++ client runs faster than the Java one (still have to use both on minimal settings...)

I don't know, maybe if they rewrote Java from scratch, it could become faster too. But I am sure they must have considered all options, and chose to stick with C++ (even though "play in your browser on any computer" was always Runescape's hallmark).
User avatar
tirioll
 
Posts: 144
Joined: Thu Nov 21, 2013 4:05 pm

Re: Client performance rant

Postby loftar » Thu Jun 08, 2017 5:12 pm

tirioll wrote:I don't know, maybe if they rewrote Java from scratch, it could become faster too. But I am sure they must have considered all options, and chose to stick with C++ (even though "play in your browser on any computer" was always Runescape's hallmark).

Well, don't get me wrong; rewriting the client in C/C++ (more likely the former) is not something that I've completely ruled out. Nevertheless, given the size of the project and the unclear gains from it, I'm certainly not about to set out on it right now. Even if it's true that significant gains could be had from it, I might as well do this rewrite in Java anyway, solve the childhood problems of the new rendering system and evaluate its performance before that.
"Object-oriented design is the roman numerals of computing." -- Rob Pike
User avatar
loftar
 
Posts: 8926
Joined: Fri Apr 03, 2009 7:05 am

PreviousNext

Return to The Wizards' Tower

Who is online

Users browsing this forum: No registered users and 7 guests

cron