I'm back!

[sikgamer]

Some things just never get old. It's quite satisfying to take down a bear, even if it's the thousandth bear you've killed in a month.

[Blaze]

Month?

My record is 67 bears in one 4 hour period.

[sikgamer]

How do you find them all so fast D:
Also I see you changed your avatar.

[swebonny]

boost bear spawn by e^(i*pi) percent!

[loftar]

I'm no OpenGL expert, but I'm sure it has to do with the amount of data sent back and forth. The whole landscape is being constantly streamed on a connection that can't be any faster than your standard cable connection (unless jorb has a T1 and I'm just full of myself).

That theory couldn't be correct for a lot of reasons, but still, that only happens when anything actually changes, so it doesn't account for the client being slow even when everything is static.

Also: You are sending graphical assets in real time, yes? If that is a right assumption, I think a downloaded client (as opposed to one that streams) with all assets in place would be more efficient then one that loads on the fly. Just have them load from the harddrive when needed.

By default, everything is fetched from the JAR file; HTTP fetching is only used when something is missing (usually because we've added some single thing and I haven't made a new JAR file for it, since that would just be an unnecessarily large download for a change of a few kilobytes at most), and even then, once it has been downloaded it is cached locally, so normally things are only downloaded once.

Also the fact you're using java doesn't help. It's stupid hard to optimize to any computer, especially the hardware your common userbase probably has.

Now, I do dislike Java with a passion, but that's for entirely different reasons. I think people tend to underestimate the performance of Java. The Hotspot VM is actually quite swell when it comes to optimization; in particular since it does some really cool optimizations that non-JIT compilers couldn't do even if they wanted (one of my favorites is the heavy inlining of functions where even just a currently monadic type can be detected, along with dynamic deoptimization of the same code in case that type invariant breaks due to classloading -- even if the code is currently running!). Likewise, thanks to garbage collection, the memory allocator is stupendously fast (under a GCing memory system, heap allocation is as simple as stack allocation; it's just a matter of incrementing a pointer).

In fact, I've been doing some quite heavy profiling on the drawing code, and I was able to optimize it a lot in the beginning (yes, it was even slower to begin with, believe it or not), but right now it seems almost all time is spent in the actual drawing primitives. Of course, modern graphics hardware simple cannot be that slow, so I cannot really interpret it other than me abusing OpenGL somehow.

Game over, thanks for playing! Please do try again, I'd really love to get useful comments on it.

[theTrav]

Fraid I'm probably going to be fairly useless as well as I've never really looked at GL OR your rendering code super closely, but here's a few tips:


1 - GL tends to do better when it's rendering one or two large tiles rather than lots and lots of little ones.
Are you rendering the landscape onto a single large surface once and then just blitting that surface at different offsets a lot of times?

2 - Are you loading all your sprites into video memory as opposed to system ram? From memory there's a way to specify which is which and if you don't you get a lot of swapping between your ram and your video memory, which slows things down a lot.

3 - have you considered making your plants less random? Make 3/4 layout variations, load them all in as 3d objects or whatever and then just pick which one you're rendering rather than doing the layout calculations each render loop.

[loftar]

1 - GL tends to do better when it's rendering one or two large tiles rather than lots and lots of little ones.
Are you rendering the landscape onto a single large surface once and then just blitting that surface at different offsets a lot of times?

I used to do that back when I used Java2D, but I thought that one of the advantages of using OpenGL might be to not exclude from the start the possibility of animated tiles, so, no, I've actually tried to keep myself from doing that.

2 - Are you loading all your sprites into video memory as opposed to system ram? From memory there's a way to specify which is which and if you don't you get a lot of swapping between your ram and your video memory, which slows things down a lot.

Do I have a choice? When I create a texture and fill it with glTexImage2D, it is transferred to video memory, right?

3 - have you considered making your plants less random? Make 3/4 layout variations, load them all in as 3d objects or whatever and then just pick which one you're rendering rather than doing the layout calculations each render loop.

Each plant actually only has 3, 4 or so actual sprite variations that it consists of, though. Depending on the plant, those variations are drawn in various numbers. If I recall correctly, a Hemp plant draws two "strands", a hops plant four and a wheat plant twenty. I don't recall all the exact numbers, but it's somewhere around those. The sorting has to be done per loop anyway, or they would order incorrectly with other sprites passing through them. I'm currently experimenting with an algorithm that packs the various sprite variations into the same texture (as is being done with tiles), so that OpenGL should have to swap less between different textures (and probably save a bit video memory). Let's see if it makes a difference.

EDIT: Brodgar's public fields are very practical for testing, btw. Thanks for growing them. :)

[loftar]

I'm currently experimenting with an algorithm that packs the various sprite variations into the same texture (as is being done with tiles), so that OpenGL should have to swap less between different textures (and probably save a bit video memory). Let's see if it makes a difference.

Well, that completed with mixed results. On the one hand, it drastically decreased the texture swapping rate when viewing crops, but on the other hand it actually required more texture memory. I haven't yet proven mathematically if the latter is a problem with my naive packing algorithm or if it's an inherent problem becuase of the power-of-two texture sizes. Either way, the texture swapping rate seems to have no performance hit at all on my nVidia cards, but I've gotten the impression that ATi cards (and maybe others as well) may care a lot more about it. If anyone wishes to try and tell me if it makes a difference, please check out and compile the "texpack" branch in the client repository, and see if it makes rendering faster.

[Pacho]

After merging this code I found that I can't farm at all. =|