New graphics API ready

[Lee R]

If we're being pedantic, it's worth mentioning that ISO C++ doesn't define anonymous structs, thus the above construct relies on a compiler specific language extension.

C++11 does.

Oh that's nice. FDIS reference?

[Haikarainen]

What have you changed with sf::Text except GetRect -> Get*Bounds ?

I'm having troubles debugging my REALLY messy menu-system, wich draws lots of texts. No texts are drawn unless I tamper with them after I create them (like selecting another menu item).

I'm creating texts like this;

Code: [Select]

sf::Text meh;
Meh.SetFont(*FontPointer);
Meh.SetCharacterSize(8);
Meh.SetColor(sf::Color(255,255,255));
Meh.SetPosition(sf::Vector2f(x,y));
Meh.SetString("bleh");

Is there a post with full changes ?

[Laurent]

It should work, sf::Text hasn't changed at all (except the GetBounds thing).

Can you reproduce the problem with a complete and minimal example?

[novemberdobby]

I'm trying to convert my project to the new system, but I've come across a problem. There no longer seems to be a way to set individual point colours in ConvexShapes. I was previously using them to do this:



I could take the polygons that I draw (see below) and set a different fill colour for each one, but that won't interpolate between vertices and looks like coloured squares instead of a nice gradient.



Is this going to be a feature later on?

[Laurent]

There won't be a replacement in the Shape API, you must use vertices (sf::Vertex) directly if you want more control.

[model76]

There won't be a replacement in the Shape API, you must use vertices (sf::Vertex) directly if you want more control.

So there is a good way. I was really worried about this.

Could you give a short example of how to do, say, a quad with different colored corners in SFML2?

[novemberdobby]

I can, since it works now:

Code: [Select]


sf::VertexArray va(sf::Quads, 4);
va.Append(sf::Vertex(sf::Vector2f(0, 0), sf::Color::Red));
va.Append(sf::Vertex(sf::Vector2f(100, 0), sf::Color::White));
va.Append(sf::Vertex(sf::Vector2f(100, 100), sf::Color::Black));
va.Append(sf::Vertex(sf::Vector2f(0, 100), sf::Color::Yellow));
rTarget->Draw(va); //any render target


after my fixes:



Thanks!

[model76]

Very nice! So exited about SFML2 now. Thank you.

[Mario]

Possible bug in shader handling (actually just some aggressive programming).

I forgot to check for shader availability on a Intel 45GMA (Eee PC), which essentially lead to a call to "RenderTarget::ApplyShader(0)".

This - for that PC - causes a segmentation fault (instruction pointer being set to 0) outside SFML's scope due to "glUseProgramObjectARB" pointing nowhere (which is called in RenderTarget.cpp at line 377).

Not sure if there should be a bit more defensive programming being used here.

[Laurent]

How did you manage to reach this call with a null argument?

[GloryFish]

I have a game project that I was building with a version of SFML 2 from September. Last night I pulled the latest version of SFML and worked on updating my code to work with the new API.

Without looking at any resource other than the 2.0 documentation I was able to convert my project to the new API in about 2 hours. It was a breeze. I really like how things are structured now.

Just wanted to say thanks to you and all the contributors for the great work.

[Mario]

How did you manage to reach this call with a null argument?

Haven't had time to track it down yet, but it seems like that's happening due to RenderTarget::Draw() trying to unbind the shader used just before updating the vertex cache:

       // Draw the primitives
        GLCheck(glDrawArrays(mode, 0, vertexCount));

        // Unbind the shader, if any
        if (states.Shader)
            ApplyShader(NULL);

        // Update the cache
        myCache.UseVertexCache = useVertexCache;

The issue here might be the integrated Intel graphics card supporting a lower shader version (I think OpenGL 1.4 is the last version being feature complete with the driver supporting some 2.0 features).

states.Shader is set to point to the shader object. Previous state's shader (don't remember name right now) is set to 0.

[Laurent]

So you load and use a shader, whereas Shader::IsAvailable() returns false? Right?

[Groogy]

It must be. Giving the program id 0 will set back OpenGL to use the fixed pipeline. I.E it's defined behaviour and should not act like that if shaders are supported. Could also be a delayed bug. It happens a lot earlier but doesn't crash until later. Experienced that a lot with intel.

[Mario]

So you load and use a shader, whereas Shader::IsAvailable() returns false? Right?

I completely forgot about the check, so essentially, yes.

It must be. Giving the program id 0 will set back OpenGL to use the fixed pipeline. I.E it's defined behaviour and should not act like that if shaders are supported. Could also be a delayed bug. It happens a lot earlier but doesn't crash until later. Experienced that a lot with intel.

As mentioned above, it's not due to the passed NULL. It's due to the function pointing nowhere (as it couldn't be loaded by GLEW).