Need Advices for performances + shaders

[Paingouin]

Hi,

I'm a roguelike enthusiastic working on a small ASCII game on my free time, and I need advice.

First of all, let me show you the "game":

https://imgur.com/a/HaddYPf

(The distortion effect is here just for the test...)

To achieve the 3d effect :
My game map is a 2D array of cells (position (x,y), glyph + color, "height")
Each frame :
    -I generate quads based on the 2d array (each cell is the "center" of a quad).
    -I use mvp matrices with glm to calculate the position of each vertices of each quads, on the CPU, and project them to 2D.
    -Once this is done. I put them in a vertex Array and render them with one draw().
    -For the distortion effect : I render another quad using another shader (and use the screen drawn before as a texture) and do another draw().

All you see here are 2D quads.
I only use the SFML api, I don't have the level to do OpenGL stuff at the moment...

Let me show you how it looks like without the textures :
https://imgur.com/a/wODRyf8

But there's two drawback :
-The first is permormance in debug, I can draw like 200 sprite on screen at 60fps without too much problems, but I already see that having like 800 quads seem to put a single core of my CPU at 100%. (I don't do mutli-threading at the moment , maybe I should ?)
https://imgur.com/a/pvDBpPf

(spriteFromCell is the code who generate a quad (4 points) from a cell and do the billboarding/rotation based from the camera view; And "mProjection*points" apply the projection matrice to these points )

The glm projection is quite slow without compiler optimisations and I'm afraid that will be a problem when I will have more effects in the game. I would love to do the MVP multiplication within the vertex shader, but it's not possible as I can only send 2D points with the draw() function. 
Should I use some optimisation, even in debug, to have the debug binary more smooth ?


-The second is shaders : I wanted to have shaders like some heaze heat effect applied to some glyph. But I don't know how to hide these effect if the glyph is behind another glyph, using only one draw call. (The "easiest" way I think is that I would have to stop the batch rendering technique, and render the quad one by one, that way, the heat effect can be partially "hidden" by a glyph.)

As anyone worked on this type of project, and have some tips/advice to manage these thing ?
That will be so useful ! 

Thanks for you help, anyways

[binary1248]

As for your first question:

Judging by your pictures... you could benefit from using geometry shaders to generate the vertex information within the shader based on data you pass in the position vertex attributes. That way you can also perform the matrix multiply within the shader as well which will probably lead to a huge performance improvement because that is what they are made to do.

As for your second question:

In theory you can move the decision on whether to "apply" a shader to a primitive from CPU to GPU. In effect, the same shader program is left enabled and run over all vertices, but you can program the shader to only really "do stuff" when certain conditions are met (which you can control via uniforms) and just pass through the data in all other cases.

I think you overestimate the "difficulty" of using OpenGL. Sure it might not be as close to a walk in the park as maybe learning SFML might be. But as I have always said, the hardest part about learning OpenGL is not actually getting familiarized with the API itself but learning the general 3D graphics programming concepts that it is built on. Based on what you have shown, you are already familiar with these concepts, so I don't think extending your knowledge to OpenGL will be that much work.

Look at it this way: trying to accomplish what you want your game to look like is probably doable using SFML and GLSL alone, but the effort you will have to invest will be more than just learning OpenGL and doing it with that instead. The nice thing about learning new skills is that the knowledge will keep benefiting you even after you are done with your project. The techniques/hacks you would have to come up with doing everything with SFML and GLSL will probably only be applicable to your current project and almost useless anywhere else.

[Paingouin]

Thanks,

I think this is exactly what I needed to hear.

You're right, I'll now start to do all the rendering part with OpenGL. (still using SFML for window and input management etc...).

Thanks again