Client performance rant

[loftar]

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.

[algorithm]

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.

[loftar]

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

Haha, I see. No thanks. :)

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.

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.

[algorithm]

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).

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()...

[loftar]

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.

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.

[algorithm]

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.

[algorithm]

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.

[loftar]

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.

[tirioll]

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).

[loftar]

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.