I have been working on a game for a while using glut for basic window creation. I was rendering to an offscreen buffer so that I could implement various effects like screen bulging, motion blur, refraction, etc. I also used the screen texture with antialiasing (fxaa).

Now I have changed from glut to sfml. I switched on the in-built antialiasing and it looked much better than my version, but now I don't have the screen in a texture so I can't use the screen effects.

So my question is, how to people normally deal with this issue? Can I take advantage of sfml's antialiasing functionality and retain my effects? I thought about using glReadPixels, but that seems way too slow. Does sfml do offscreen rendering behind the scenes and can I access that texture?

This is not specific to sfml. How do AAA games do it? Do they always implement their own antialiasing techniques?


As far as I know, SFML doesn't provide own anti aliasing. Well, when you create a new window, there is an optional parameter for the anti-aliasing level. But this super-sample anti-aliasing is a default handeled by the graphics driver instead of SFML. You can easily get that with GLUT, too.

Internally, SFML doesn't use render to texture, I think. But there is a class to do so on you own. It's named sf::RenderTarget. You can render to all classes derived from that, including sf::RenderTexture, which might be exactly what you are looking for.

You could either do rendering yourself using raw OpenGL and handle all shaders, render targets and framebuffers yourself. Or you could make use of another SFML class provided for this case. If I remember correctly, it was called sf::PostFX and was renamed to sf::Shader now. Though I haven't used those classes, it seems rather easy to use them and apply effects. You read the documentation, it is a very good one which many described use cases. But since SFML has only 2D capabilities, I am not sure whether you can use that for a 3D game or not.

Nearly all recent AAA titles make use of deferred rendering, which means to render multiple attributes like depth, view space normals and texture color, to texture. Shading can be applied by reading from those textures, so that the geometry hasn't to be drawn multiple times. This is a step further than what you want to do. Deferred rendering is especially useful for computing a lot of lights.

At least for deferred rendering, anti-aliasing is still a big issue. There are various approaches with their trade-offs. But super sampling is to slow in most cases since you have to super sample all the textures rendered to, which amplified rapidly. What some games do is to detect hard edges using depth and normal information and apply a blur to those pixels. Easier implementations do only read the color texture, for example FXAA. Those are what you want to implement. That is kind of faked anti-aliasing but it has an acceptable low performance trade off.

But before you start altering you whole game think carefully if it makes sense to use those post process anti-aliasing algorithms. If you don't use deferred rendering, it is very likely that you are fine with the default super sampling. It can be used by passing sf::ContextSettings to your sf::Window instance.


Anti-aliasing is little more than rendering at a higher resolution and scaling it down before putting it on the screen.

Have you considered rendering to a larger off-screen texture?

  • \$\begingroup\$ Eh sorta kinda. There is a whole lot more to it though and simply down scaling is a not really an acceptable solution. \$\endgroup\$ – ClassicThunder May 2 '13 at 6:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.