New graphics API ready

[Laurent]

undefined symbol: _ZN2sf6ShaderC1ERKS0_

Are you sure that your executable uses the right SFML libraries?

[Richy19]

Think I have managed to get it working now

BTW do you thnk the whole intel rendertarget bug will be fixed with the release of SFML2?

[Laurent]

BTW do you thnk the whole intel rendertarget bug will be fixed with the release of SFML2?

No. This is for SFML 2.1.

[Groogy]

I'm wondering about a thing in the shader class. Why does the setter function for matrixes require a mat4 when sf::Transform is only a 3x3 matrix? You should be able to upload a 3x3 matrix to a mat3 right? Or you got a certain reason for that?

Also a sf::Transform3D will not be provided right? That would make sense to upload to a mat4 then. Though it would not make sense in the 2D api of SFML, except for maybe if someone wants to create some special effect in the shaders where he needs a 3D matrix. ( Lighting, shadows, water, motion blur, etc. etc. ) But a very special case.

Or am I missing something?

Also this one is confusing: sf::Shader::SetParameter(const std::string& name, CurrentTextureType);

It let's you set the sampler which is the current texture? The texture we are drawing to? Or? I don't get it, is it the sprites texture? And what is the second parameter supposed to be?

[Laurent]

sf::Transform will most likely be applied to vertices, which are vec4. So it's easier if it's a mat4. Even if only two components are relevant, you do all your shader calculations with 4 components.
Moreover, a sf::Transform is internally a 4x4 matrix, so it would require an extra step with copies in order to upload it as a 3x3 matrix.

Also this one is confusing: sf::Shader::SetParameter(const std::string& name, CurrentTextureType);

I thought the doc was clear enough, obviously it's not :?
It maps a sampler shader variable to the texture of the object being drawn (that's what the doc says). So if you draw a sprite, it will be the texture of the sprite. I don't know how to explain it differently, sorry.

The second parameter must be sf::Shader::CurrentTexture, nothing else (the doc says that too). It's like a tag that selects the right overload of SetParameter, the value itself doesn't mean anything (it's an empty struct). It's more elegant than writing a function with a different name just for this specific case, it keeps the syntax consistent with all other overloads.

[Groogy]

sf::Transform will most likely be applied to vertices, which are vec4. So it's easier if it's a mat4. Even if only two components are relevant, you do all your shader calculations with 4 components.
Moreover, a sf::Transform is internally a 4x4 matrix, so it would require an extra step with copies in order to upload it as a 3x3 matrix.

But the public interface don't let us use it as a 4x4 matrix right? Which is too bad, though if the variable myMatrix is protected we can inherit from sf::Transform and implement our own 3D version right? Or we can just use the GetMatrix() function for that without having to have myMatrix protected.

I thought the doc was clear enough, obviously it's not :?
It maps a sampler shader variable to the texture of the object being drawn (that's what the doc says). So if you draw a sprite, it will be the texture of the sprite. I don't know how to explain it differently, sorry.

Yeah I read it and now it seems obvious, I don't know why I saw it as obscure. Though there might be others, especially newbies.

The second parameter must be sf::Shader::CurrentTexture, nothing else (the doc says that too). It's like a tag that selects the right overload of SetParameter, the value itself doesn't mean anything (it's an empty struct). It's more elegant than writing a function with a different name just for this specific case, it keeps the syntax consistent with all other overloads.

After writing I guessed it was something like that.

[Haikarainen]

Are you going to merge the drawables branch with the regular one anytime soon?

[Laurent]

But the public interface don't let us use it as a 4x4 matrix right? Which is too bad, though if the variable myMatrix is protected we can inherit from sf::Transform and implement our own 3D version right? Or we can just use the GetMatrix() function for that without having to have myMatrix protected.

There's absolutely no point using the 3rd row/column of the 4x4 matrix, which are dedicated to the Z component. SFML only deals with 2D.
Stop requesting 3D features, you won't get anything :lol:

Are you going to merge the drawables branch with the regular one anytime soon?

As soon as it is optimized enough. I don't want the master branch to be 3 times slower than before the update.

[Groogy]

There's absolutely no point using the 3rd row/column of the 4x4 matrix, which are dedicated to the Z component. SFML only deals with 2D.
Stop requesting 3D features, you won't get anything :lol:

You misunderstood, it was just a question if it would be possible to create a 3D transform class that behaves like SFML's one through that. You know make it myself for my own stuff, so instead of providing an entire new class called Matrix44 I can just adopt sf::Transform to custom::Transform3D and it should work perfectly by itself together with the rest of SFML, right

[Laurent]

Ok I see. But I don't think that you can extend sf::Transform, you'll have to create your own class from scratch.

[Haze]

But if the line is neither vertical (A.x != B.x), nor horizontal (A.y != B.y), we must use trigonometry to compute the line length (rectangle width = distance between A and B), and then rotate the rectangle.

Yes. It's not a big deal.

So it doesn't worth creating a LineShape class?

I've also a couple of questions about the split Transformable/Drawable :

- In the previous graphics API, we were able to inherit from sf::Drawable in order to draw items relatively to the drawable position (I mean: positions of the items drawn in the overridden Render method were offset by the drawable's own position).

I cannot reproduce this behavior anymore (I've tested inheriting from Transformable - using my own Show method, and from Transformable + Drawable - using the overridden Draw method).
Is this feature still exist? If yes, how do I achieve this?

- Why don't you use a reference to pass the RenderStates object in the Drawable::Draw method?

Code: [Select]

virtual void Draw(RenderTarget& target, RenderStates states) const = 0;


Thanks

[Laurent]

I'll answer both of your questions with a simple piece of code:

Code: [Select]

virtual void Draw(RenderTarget& target, RenderStates states) const
{
    states.Transform *= GetTransform();
    target.Draw(some_child_entity, states);
}

[Haze]

Great, it works fine. Thanks Laurent.

[Laurent]

I've changed the type of Vertex::TexCoords, they are now floats. This was needed because some ATI drivers don't seem to handle integers correctly.

This fixes the stretched textures problem that some have reported after testing the new API.

[Nexus]

I've changed the type of Vertex::TexCoords, they are now floats. This was needed because some ATI drivers don't seem to handle integers correctly.

Wouldn't it be better to keep ints at the user interface and to convert them to floats internally? Floats in the API have the disadvantage that it's not immediately clear whether the coordinates are in the interval [0, size] or [0, 1] and whether it makes sense to use non-integral coordinates.