I don't see anything obviously out of whack there. You probably want to use Tracer to explore exactly what is going on in GPU land.

15 hours ago, EddieK said:

I figured out that I need to use glBufferSubData() instead. Tried it, but it was even slower

You should read the Khronos wiki page on streaming buffer updates. There are a lot of nuances to this, worth playing around with a few approaches.

2 hours ago, swiftcoder said:

 

I'm using OpenGL ES 2.0 which doesn't have the glMapBufferRange or glBufferStorage so I think I can't use streaming. 

In that case you probably want to experiment with double-buffering your vertex updates.

There's not a lot of information on how to implement this in practice. Maybe you have some examples of how I could do that? 

I did try to use switch between different vertex objects every frame but that didn't work out too well. 

I've been working on optimizing my game for a straight week, and I still have gotten nowhere. It can barely render 1500 textured squares at 60FPS

On 2/22/2018 at 6:01 PM, EddieK said:

Well because I need to update the vertex positions and their colors every frame. How else am I supposed to update the vertices? Sorry, but I am a newbie when it comes to OpenGL. 

What they mean is that you can create the mesh only once, only supplying the Positions/texture coordinates. 

To update the position you can simply upload a transformation matrix and a color as uniform to your vertex shader before each draw call and use that in the shader to position / colorize the mesh.

So instead of constantly destroying / creating the buffer that hold your vertex data you would now always reuse the same and let the matrix position/rotate/scale it correctly.

Before you start optimizing something random, I'd suggest you test whether that is the actual issue.

Buffer update:

Before you focus on buffer updates, try rendering without updating the buffers (just initialize it the first frame), if you get the exact same performance, you won't benefit of updating the buffer in "better" ways.

Fillrate:

Reduce the size of the quads to 1/2 (yes, that will look wrong, but it's for testing only), if that speeds up the rendering significantly, you're fillrate limited.

Texture sampling:

Hardcode your fragment program to only output one constant color, no texture sampling.

Alphatest:

you seem to have some alphatest/color key/pixel clip/pixel kill enabled. Disable it and check the perf (eventually you render the whole scene with that enabled, which might disable significant optimizations on the GPU).

On 2/22/2018 at 4:40 PM, EddieK said:

I'm really out of ideas here, it seems like I tried everything and I still can't get past 3000 triangles without the framerate dropping below 60. I read somewhere that MALI-400 is capable of 30 million polygons per second and I am getting only around 500,000.

There are many different "MALI-400". Beside polygon count, they have other limitations, e.g. they manage to render 210MPixel/s - 2000MPixel/s, that's 3.5MPixel/frame - 33MPixel/frame. Your screenshot is 2.3MPixel, hence you can afford an overdraw of 1.5x - 14x, which is not much if you add all the UI and overlaying sprites ->If you figure out that fillrate is the issue, maybe it would be enough to render your pixel art into a way lower resolution initially and just upscale it at the end.

4 hours ago, Krypt0n said:

Before you start optimizing something random, I'd suggest you test whether that is the actual issue.

Buffer update:

Before you focus on buffer updates, try rendering without updating the buffers (just initialize it the first frame), if you get the exact same performance, you won't benefit of updating the buffer in "better" ways.

Fillrate:

Reduce the size of the quads to 1/2 (yes, that will look wrong, but it's for testing only), if that speeds up the rendering significantly, you're fillrate limited.

Texture sampling:

Hardcode your fragment program to only output one constant color, no texture sampling.

 

Alphatest:

you seem to have some alphatest/color key/pixel clip/pixel kill enabled. Disable it and check the perf (eventually you render the whole scene with that enabled, which might disable significant optimizations on the GPU).

 

There are many different "MALI-400". Beside polygon count, they have other limitations, e.g. they manage to render 210MPixel/s - 2000MPixel/s, that's 3.5MPixel/frame - 33MPixel/frame. Your screenshot is 2.3MPixel, hence you can afford an overdraw of 1.5x - 14x, which is not much if you add all the UI and overlaying sprites ->If you figure out that fillrate is the issue, maybe it would be enough to render your pixel art into a way lower resolution initially and just upscale it at the end.

Oh I didn't know about the fillrate thing. Thank you for shedding some light on it. It now seems that it's not my code's problem, it's the GPU that can't handle the amount of pixels I'm pushing per second. I did the calculations (for my older 800x480 screen phone) and it should be pushing around 1MPixels/frame max, plus adding the cost of collision detection and other logic, it seems that the framerate I'm getting is nominal.

Case closed

I didn't say that's the only possible issue ;). Rather test these 4 points I've layed out, it shouldn't take long. Finding the issue might help you to improve the situation.