The only way to do this all on the GPU would be to use the OpenGL renderer and do the post-processing in a shader.
There's no way to get at the pixels of the current frame outside of a shader. All the details of what a frame looks like are hidden behind the abstract SDL_Renderer. It could be a pixel buffer for software rendering, or a set of VBOs, etc., which would mean there is no pixel representation of the final image until it's actually flushed to the GPU.
You could keep a copy of the texture in an SDL_Surface, modify the surface as you used to, then SDL_UpdateTexture to get the pixels into the final texture. You should create the texture with SDL_TEXTUREACCESS_STREAMING to tell SDL that you plan on updating the texture frequently.
Posted by Dave Hunt
on 03 December 2013 - 02:56 PM
Your l_spriteWVP matrix is wrong. The multiplication order should be scale * rotation * translation, not the other way around.
Also, I'm a bit confused by your matrix names and usages. You are including sprite position (translation) in your l_spriteWVP matrix, then multiplying that by another matrix (worldMatrix (which is really view * projection)) and setting that result on your shader as the world matrix. Then in your shader, you are multiplying the sprite position by the world matrix again. I'm pretty sure that's going to give strange results.
I would strongly recommend using the DirectX Tool Kit for sprite drawing. It's an official MS tool kit and takes care of all this for you. If you want to learn how to do it yourself, all the source code for the tool kit is available for your perusal.
Posted by Dave Hunt
on 09 November 2013 - 09:49 PM
Based on that little bit of code, I'd recommend this article.
In the future, when asking questions it's best to post what you've tried rather than everything but the part you're having a problem with. Asking for help with input and then posting code that has no attempt at input in it isn't the best approach.