Messages

1

General discussions / Isometric map in SFML

« on: June 24, 2011, 04:12:27 am »

If anybody is interested, I wrote a blog post about building an isometric map system using SFML.

http://www.gamedev.net/blog/33/entry-2250273-isometric-map-in-sfml/

The system is fairly basic, the lighting very retro, but it uses basically straight SFML, no diving into OpenGL or anything. It's an update of code from an ancient, long-dead project of mine that hasn't really been thoroughly tested, but it was actually quite easy to bring it over to SFML. The blog post includes a link to the source of the demo, including bindings to Lua and a binary build of the demo, if anyone cares to take a look. It is built against a very recent (as of a couple days ago) snapshot of SFML 2.0.

Again, bear in mind that it isn't really code that I use in production, so I'm almost certain it has bugs. Any bugs, though, are most likely my fault and not the fault of SFML which I have found to be a quite excellent little library. Kudos to the developer.

2

General discussions / Shader::SetCurrentTexture member shadowing?

« on: June 20, 2011, 10:46:33 pm »

Well, maybe not huge, so much as potentially annoying to find down the road. If I had $1 for every time I've done that...

3

General discussions / Shader::SetCurrentTexture member shadowing?

« on: June 20, 2011, 10:30:56 pm »

Been doing a little source diving of the latest snapshot, preparatory to tackling a new project using shaders, and in Graphics/Shader.cpp I found the function SetCurrentTexture:

Code: [Select]


void Shader::SetCurrentTexture(const std::string& name)
{
    if (myShaderProgram)
    {
        EnsureGlContext();

        // Find the location of the variable in the shader
        int myCurrentTexture = glGetUniformLocationARB(myShaderProgram, name.c_str());
        if (myCurrentTexture == -1)
            Err() << "Texture \"" << name << "\" not found in shader" << std::endl;
    }
}


This seems a little weird to me, since the declaration int myCurrentTexture appears to shadow the member myCurrentTexture declared as part of Shader class. Thus, the result of the glGetUniformLocationARB call is discarded at the end of the scope, rather than being assigned to the member. Is this intentional? If so, it still seems weird, since no other method in the Shader class assigns to Shader::myCurrentTexture except the constructor, which inits it to -1. Yet the Shader::Bind method checks the value of Shader::myCurrentTexture before calling glUniform1iARB.

4

Feature requests / Pre-multiplied alpha

« on: June 09, 2011, 09:47:27 pm »

http://home.comcast.net/~tom_forsyth/blog.wiki.html#%5B%5BPremultiplied%20alpha%5D%5D

http://keithp.com/~keithp/porterduff/p253-porter.pdf

http://blogs.msdn.com/b/shawnhar/archive/2009/11/06/premultiplied-alpha.aspx

Premultiplying alpha can help reduce or even eliminate "haloing" around alpha-blended sprites if the sprites are filtered. It can contribute to better DXT compression. But the main reason I use it is to be able to have particles and sprites that include both alpha-blended and additive areas in the same operation.

In a standard alpha blend using (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA) the equation of course is (src.rgb * src.a) + (dest.rgb * (1-src.a)). With premultiplied alpha, you are just doing the (src.rgb * src.a) step separately, when the texture bitmap is created. For additive blending, we don't bother multiplying the src.rgb by src.a during texture creation. This way, if a src pixel has color but 0 alpha, the color is added on top of the destination pixel rather than blended with it.

In other words, for something like a particle flame, you can have both flame and smoke particles drawn from the same texture, without switching texture state between passes. I use it pretty extensively for various magical spell effects in my current game project.

5

Feature requests / Pre-multiplied alpha

« on: June 09, 2011, 05:44:22 pm »

I use pre-multiplied alpha almost exclusively, since it is useful for being able to perform alpha blending and additive blending in a single operation. In pre-multiplied alpha, instead of doing a (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA) blend operation you do (GL_ONE, GL_ONE_MINUS_SRC_ALPHA) and assume that the source color has already been multiplied by its alpha value.

This way, if you want to do regular alpha blending, you supply a texture in which the color values are scaled by the alpha value. If you want to do additive blending, you supply a texture in which the color is not scaled, and the alpha is 0. You can thus combine the two types of blending in a single operation, in a single texture.

The fix I applied is simple, consisting of another enum field added to sf::Blend::Mode, and the line case Blend::PreMultiply: GLCheck(glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA)); break added to Renderer::SetBlendMode.

Perhaps you guys could consider making it official?