Client 100% CPU / sleeping

[Oddity]

It would be nice if the client didn't consume 100% CPU all the time. It really isn't necessary for game like this. I'm sure my computer can draw the game's screen like 300 times per second but that is overkill. You could limit it to even 60 fps and that would reduce CPU usage enormously.

All the client needs to do is calculate the time in between each frame, and each frame check whether a desired amount of time has passed (about 0.1667 secs for 60 fps) since the last frame, and if not then sleep the rest of the time away. This would greatly reduce CPU time and I'm sure people using less powerful computers would appreciate it.

I don't know whether Pacho's client does this because it won't work for me ("Unable to launch the application."). If I knew Java I would even download the source for Pacho's (after getting the client to run somehow) and do this myself -- assuming Pacho's doesn't do it already.

[Oddity]

I guess I am the only person who cares about this.

I got Pacho's working, and I had a look at the source-code for it but I couldn't figure out where the "main game loop" is. I'm also not very familiar with Java but I think I could fix it if I knew what part of the code to look at. Somebody help me find the main loop!

Any word from the devs on whether they care to fix this problem (or even understand what I'm talking about) would be appreciated.

[mvgulik]

Just dropping in something that seems somewhat related to this topic.

A additional behavior of the default H&H client, other than its seemingly constant high cpu use. Is the fact that if the client is suffering a temporary hick-up. This hick-up is transfered to other currently running applications. (assuming some lack of some cpu sharing code in the parts thats waiting for something. seems server communication related.)

Example: I general run WinAmp for background music. And when the H&H client is temporary stalled. WinAmp start to repeat the music part (~1sec long). (playing local music file.)
While playing music this behavior is of course directly noticeable. But other applications suffer the same fate. (Browser(Chrome) for example.)

PS: I'm running H&H in LOW-priority, in case it matters. (Xp32ProSp3)

[loftar]

It would be nice if the client didn't consume 100% CPU all the time. It really isn't necessary for game like this. I'm sure my computer can draw the game's screen like 300 times per second but that is overkill. You could limit it to even 60 fps and that would reduce CPU usage enormously.

Actually the FPS is limited to 50. I wish it could draw the game's screen 300 times per second. I think the main fault lies with my inexperience with OpenGL (since most of the CPU time is actually spent inside the OpenGL functions themselves) -- if there is anyone who has any idea how to optimize it, I very much encourage you to give it a try.

Just dropping in something that seems somewhat related to this topic.
[...]
Example: I general run WinAmp for background music. And when the H&H client is temporary stalled. WinAmp start to repeat the music part (~1sec long). (playing local music file.)
While playing music this behavior is of course directly noticeable. But other applications suffer the same fate. (Browser(Chrome) for example.)

I've never seen that behavior on any computer I've run the client on, so I'd wager that's something else on your system.

[mvgulik]

Example: I general run WinAmp for background music. And when the H&H client is temporary stalled. WinAmp start to repeat the music part (~1sec long). (playing local music file.)
While playing music this behavior is of course directly noticeable. But other applications suffer the same fate. (Browser(Chrome) for example.)

I've never seen that behavior on any computer I've run the client on, so I'd wager that's something else on your system.

Well its a combination of multiple things of course.
This hick-up seems related to high server load. So its not a constant problem.
On the local part. I have no clue as were to look yet, other than probably some internal network related thing. But it at least sound like it could be fixed at my end.
Thanks.

[Granger]

I think the main fault lies with my inexperience with OpenGL (since most of the CPU time is actually spent inside the OpenGL functions themselves) -- if there is anyone who has any idea how to optimize it, I very much encourage you to give it a try.

Without a clue how the client is structured (i'm not in the mood to reverse engineer sparse commented java at the moment) it is hard to say.
Do you have any kind of documentation about what you do where inside the client (some form of design document)?

I took a quick look at the code and because of low comment/code ratio the only thing looking fishy i was able to spot was the multithreading.
Looks to me (ok, i'm no java guy) that the netcode is able to stall other threads through locking data structures when data arrives.
This could well lead to the profiler registering time spend in OpenGL since the renderloop it's busy-waiting for semaphores to free.

Just dropping in something that seems somewhat related to this topic.
[...]
Example: I general run WinAmp for background music. And when the H&H client is temporary stalled. WinAmp start to repeat the music part (~1sec long). (playing local music file.)
While playing music this behavior is of course directly noticeable. But other applications suffer the same fate. (Browser(Chrome) for example.)

I see heavy disk I/O (virtual memory trashing) cause by the client on low memory machines, leading to stall of realtime processes.

[loftar]

Do you have any kind of documentation about what you do where inside the client (some form of design document)?

Lol :)

I may have plenty of free time, but not so much to be writing and updating documentation that almost noone will ever read. :)

I'd be willing to answer questions, of course. And yes, I know that the client code isn't all too pretty -- since I rather intensely dislike both Java and writing UI code, I tend to want to avoid writing on the client, and try to get it over with as soon as possible. (Not to mention how it's pretty much impossible to write Java code that could be called "good". The language itself isn't really conducive to that.)

I took a quick look at the code and because of low comment/code ratio the only thing looking fishy i was able to spot was the multithreading.
Looks to me (ok, i'm no java guy) that the netcode is able to stall other threads through locking data structures when data arrives.
This could well lead to the profiler registering time spend in OpenGL since the renderloop it's busy-waiting for semaphores to free.

Thanks, but I really don't think that's the case, for a couple of reasons:

• The code handling network messages is really simple, so any single message shouldn't take more than a few microseconds to handle.
• The only network code doing any coarse locking is that handling widget messages sent to the client (the code handling objdata and mapdata does much finer locking which should have extremely minor impact). Widget messages generally only arrive at a rate of at most a few per second; and often far less than that.
• Even assuming that weren't the case, I've been profiling the OpenGL code by disabling only the innermost calls to the actual OpenGL functions, inside all locks, and comparing the profile from that to that when the OpenGL functions are enabled, and that's where almost all (at least more than 50%) the CPU time lies. I don't see how such a profiling would be susceptible to locking issues (since the locks are still taken).

Just dropping in something that seems somewhat related to this topic.
[...]
Example: I general run WinAmp for background music. And when the H&H client is temporary stalled. WinAmp start to repeat the music part (~1sec long). (playing local music file.)
While playing music this behavior is of course directly noticeable. But other applications suffer the same fate. (Browser(Chrome) for example.)

I see heavy disk I/O (virtual memory trashing) cause by the client on low memory machines, leading to stall of realtime processes.

While that could be true, the machine would have to be very low on memory indeed if such code as an MP3 player were to be swapped out. I don't know how much resident memory WinAmp requires these days, it is true, but I've never ever had an MP3 player unable to play because of swapping [and I've managed to get my systems swapping pretty badly, mind you ;)]. Not to be overly skeptical, but it isn't the first explanation I'd seek. If anything, I would put my guess at a badly designed driver or other kernel code taking out some really coarse (system-wide) lock or disabling interrupts in some code that the client triggers.

[Oddity]

It would be nice if the client didn't consume 100% CPU all the time. It really isn't necessary for game like this. I'm sure my computer can draw the game's screen like 300 times per second but that is overkill. You could limit it to even 60 fps and that would reduce CPU usage enormously.

Actually the FPS is limited to 50. I wish it could draw the game's screen 300 times per second. I think the main fault lies with my inexperience with OpenGL (since most of the CPU time is actually spent inside the OpenGL functions themselves) -- if there is anyone who has any idea how to optimize it, I very much encourage you to give it a try.

I didn't even realize that the client was open-source when I started this thread (I wasn't sure about how Pacho's looked/felt exactly the same as the normal client, hah). Now I really wish I was experienced enough with OpenGL solve this or at least contribute to figuring this out. Unfortunately my knowledge of OpenGL is very limited, and I don't know Java yet either