Welcome back :D

[romovs]

I really don't want to discourage you guys from analyzing client performance and suggesting changes to improve it, but I really cannot help but think that y'all are looking in the wrong places. For instance:

Yes too many unnecessary object instantinations in critical routines.

Object creation in Hotspot is generally extremely cheap. I have at times even tested and benchmarked converting some very common object creations into pooled or mutable objects instead, and it has made no difference whatever. Which is as expected, really, as Hotspot implements object allocation as little more than the increment of a register. Young-gen GCs (or GCs overall, for that matter) also represent almost no part of the total CPU time expended by the client.

Never claimed it would make *significant* difference.
It's neglectable in view of other things but there is still some slight difference at least on lower end CPUs (i was toying mainly to make it workable on a C2D laptop + crappy mobile nvidia chip... inlined here and there, turned into mutable there and here, resorted to primitive datatypes in other places - the result is slightly lower CPU utilization plus ~5FPS tops. Not really worth it imo.)


But why shadows have so an adverse effect?
It doesn't seems to be an issue of integrated GPU. I though maybe shitty Linux Intel drivers where the reason but it's the same on Windows. Other games with shadows enabled e.g. Skyrim run just fine.
Is it related to this ?:

To offer my theory on why the client performs as it does and how to improve it, I'm pretty sure it is simply because the client treats all objects (graphical, in-game objects, that is) as being completely dynamic and treating them all with equal dignity.

[whiskeypete]

http://wklej.to/xCONJ/text

Also, I feel I must ask: Do you calculate the amount of indentation for each line with an RNG?

**BURN**

[Ferinex]

For those who don't know, the BGL and its Commands are used to off-load the actual calling of OpenGL driver routines to a second thread, so it is a part of parallellization. However, when I implemented it, and was at the stage where I had the BGL but not the secondary thread to do the dispatch, I ran it all in one thread, and even then it was still faster (by about 10%) than doing the OpenGL calls directly in place instead of allocating Command instances. My hypothesis on why this is so, is that bunching the preparation code and the OpenGL calls together, each for themselves, simply improves cache locality.

Why don't you just use any of graphics engines? Graphics programming is own world where people spend years to become expirienced enough to make fast and good-looking applications. Graphics engines allows not to spend billion of years understanding underground rendering pipelines, specific for each version/vendor/os pairs.
For example, back in times of hnh 1, i've spend week or two to port client to libgdx and i got like 20 fps boost without even changing client architecture.

I know you don't like to reuse code of other programmers, but this is the point where you should decide - you will continue with doing haven for yourself (for you ego or whatever) or you will become professional and continue with doing haven for players (games are made to be played, you know).

Absolutely agree with this post--even with the choice of engine. LibGDX is a great framework. If Loftar lacks the motivation to better the client--and therefore hafen--then it is only sensible to bring on a third team member. The game is crawling along with many of the same problems it has suffered since 2010 or earlier. These problems are not difficult or unsolvable--the problem is at the minute in the head of the men behind the keyboard! No offense intended. We all need to hear it sometimes. Hafen CAN be a good and playable game. The foundation is there, but a house can't be completed without contractors. It doesn't make sense to lay tile or install insulation when you are not interested in those things and lack the necessary skills. It makes more sense to take a leadership role than to continue trying to overstretch. Hafen is turning into a ball of incomplete mechanics a-la Haven, due to continually shifting motivations and direction.

[Gordon]

If only Loftar would realise how much players he lost, because they couldn't simply run the client on decent FPS, then I'm sure he would get motivated to make a new one with less requirements. I know a few who couldn't run it on ok FPS and they quit(and they didn't even have an bad PC)

[Ferinex]

http://199.233.247.46/RedFox/Haven/Tracker.html

I believe this says everything about the way things are currently going. Something needs to change.