That's great! Many sites I never heard of and have quite some visits.
Thank you.

I was told by someone here that if you make the game logic update seperate from the rendering, then the hicups won't be as bad because you will always have the most up to date state even if your renderer is stalled. I didn't try this myself though...

I am on the same boat with you with those spikes, I get them both on PC and Android. Ok, my Android game is already quite heavy and I don't expect it to be more than 30 FPS, but on the PC it's very light on rendering and I still get stutters.

I am not entirely sure, but maybe it's worth trying out other games and see if they got hicups as well.
Also, try to use DDMS, it should show you those hiccups and it has a very nice graph showing your performance.
This gave me the idea to try and use DDMS on other games(not mine) and see if they got those hiccups as well. Maybe we are very sensitive to our own games' stutters but don't notice when it happens to others.

Hmm, 10 ms is not slow. You still get 60 FPS with 10 ms, and from what I have seen on my device it would wait the rest of the frame if it fits into 16.67 ms.
The same with 30 FPS, it would try to fit into 33ms batchs if you are slightly less than that.
This is from what I saw and understood seeing DDMS, although DDMS can only profile the VM as far as I know, so it won't get into your JNI functions.
If your whole program is C++ then... sucks to be you...

Anyway, I suggest first trying to "gather more infromation" and try to figure out something. The way you describe it doesn't really give us enough information to tell what exactly is the issue.

I think slow downs and frame skips might be normal for Android. However a difference between 5 ms and 40 ms is suspicious. If you said 20 ms to 60 ms it would make more sense.

You might also have bursts. Don't think the throughput is balanced and evend out for the frame duration automagically. If you do intense calculations in a short time it is going to stall you even if you have enough "space" throuput wise.

Ok, that's more clear.

I tried to watch the video but it's awfully long and I didn't quite find the point of what you are trying to tell us. I guess it's this Objecty thing but I don't know what exactly that it does without watching the whole video.

I am trying to read assets in another thread in JNI.
I have a java function that reads an assets and returns byte[]. I can call this java function from JNI.
The issue is that now I want to read assets in JNI in a different thread than my main thread, which means I need to read assets in more than one thread.

The question, should I even bother?
I can read the assets on the main thread when requested and just parse it on the ResourcePump.

What do you think I should do?

(I guess I will try first the reading on main thread and pumping later, then I will be wiser).

That's another issue, from what he wrote I understood he WANTS people to build their own client.

As long as your server is not open source, it's just like any other online game. (As was mentioned earlier).
Also, why would people build their own client? Unless you are super popular like mount and blade... and even then it's easier to just mod your client.
I hope you don't rely on your users to build the client for you because you can't be arsed to build a proper client, because it is not likely to happen.

Err, they do?
They just don't package the updates D3DX stuff.

Yea, as I already mentioned, you can code with DX11 API for "DX10 features" or even "DX9 features" GPU.

Well I don't think I am CPU bound since this is an RPG game and very little processing.
But if draw calls only cause CPU performance issues, that's a different story...

Well what I understood from you is that you think I have one draw call per INSTANCE of character, while I have one draw call per character which might have mutliple instances.
For instance "book" has will be drawn with 3 draw calls.

I was told to tell you to use this:

http://en.wikipedia.org/wiki/Caesar_cipher

You could sign it so the end user won't be able to read it, but the issue is that you WANT the end user to read it. Or at least your application.
Whatever you provide the application which the user install to read it, the hacker can use to read it as well.
You can't hold the rope on both ends.

Edit: You could make it harder for the hacker to reverse engineer it, but the question is why would you want to? This is an extremly waste of effort on protecting something that is not clear anyone will bother to hack or even want to play\use. To be honest.

It's like putting a nickle inside a safe, being a bit harsh. XD

Thanks Tommo.

Christian, but that is not what I am doing.
I am simply batching all the identical characters. For instance 'e' would likely appear more than once on a big text.

Well I guess I got my answers now.

So you want to tell me that binding 1 2048x2048 texture is just the same as binding a 32x32 texture?
Also, why do you always assume that the bigger texture will always have less draw calls.
With quads it might be easier, but with instancing objects and meshs there might be a lot more geometry than you can do in one batch and you might get better performance batching the same object many times, rather than everything.
Let's say you have a plane, a tank, a jeep and a solider.
You have 3 planes, 10 tanks, 20 jeeps, and 50 soliders. Maybe having a 3, 10, 20, 50 batchs is better than just one 83 batch?

I am not ignoring.
I am just not sure that atlases are always the best solution.
Perhaps binding one 512x512 texture is just the same or even worse than binding four 256x256 textures? Assuming 1 draw call vs 4 draw calls.
Maybe you can even get less draw calls with split textures than with atlas overall.
I ask you to provide data since I am not sure it's such an obvious one parameter optimization. There might be several factors that need to be optimized in parallel rather than one.

Edit: Not to mention that with the atlas you will be probably sending more geometry in the VBO. With quads that might not be a big deal, but if you instance objects instead of just quads it might be an issue.

The best would be to code for DX11. DX9 is ancient, DX8 is like... belong to another time in history.

(Yes you can code with DX11 on a DX10 GPU)

Is there some analysis or article mentioning that anything more than 1 draw call reduce performance or is a bottle neck, like you claim?

The benefit is that you use a smaller texture per draw call.
I am sure there is a cost for using a bigger texture per draw call. If there wasn't a cost, you could basically draw all your scene in 1 or 2 draw calls.