New graphics API ready

[Mario]

Well, probably yes, although I'm not a fan of having to write a long chain of members and sub members (like color.data.components.r). Getters might be more interesting then, but at the same time it isn't something that requires immediate changes or attention, considering there are far more interesting things to fix/change first (like OpenGL ES).

Something different:
While working on custom sprite/animated sprite classes (to make access to frames/animations easier) I noticed, that I could save quite some code by subclassing sf::Sprite, which I know isn't intended and making some things impossible to do. So, just out of curiousity, anything speaking against making sf::Drawable::Draw() protected instead of private? In this case my plan was to let AnimatedSprite::Draw() update the frame to be shown (based on an internal state and the last frame's time) and then call sf::Sprite::Draw() to draw the sprite. Now I did it making the sprite a member instead of the base class, but I think subclassing would be the better way.

[Laurent]

What code did you save by subclassing sf::Sprite? I think that your second solution is the best; for example, what happens if someone calls SetTextureRect (which is inherited) on your AnimatedSprite in the middle of a running animation?

Anyway, Draw is defined const so it wouldn't help to make it protected.

[Mario]

Ah, you're right, it's const. That's been the actual problem, not just the private/protected. Also something more important about making sf::Sprite not subclassable should be the fact that otherwise people might tend to use it as some kind of entity class otherwise.

But yeah, I'll most likely stick to the custom solution and add a Draw() that will just forward the call after updating the current frame.

[Mikademus]

Well, probably yes, although I'm not a fan of having to write a long chain of members and sub members (like color.data.components.r). Getters might be more interesting then, but at the same time it isn't something that requires immediate changes or attention, considering there are far more interesting things to fix/change first (like OpenGL ES).

Chained member access would be a nuisance, but I don't think that was the suggestion, and not what I would suggest either.

Code: [Select]

struct Colour
{
    union
    {
        struct
        {
            unsigned char r;
            unsigned char g;
            unsigned char b;
            unsigned char a;
        };
        sf::Uint32 rgba;
    };
};


In this you access the members of Colour instance c by c.r, c.a or c.rgba directly.

[Laurent]

In this you access the members of Colour instance c by c.r, c.a or c.rgba directly.

Don't forget that if you set one and read the other, the behaviour is undefined according to the C++ standard. In practice it works as expected on most (if not all) platforms, but it can still break one day.

Moreover, I think it's dangerous to provide access to all the components in a single variable, because of endianness issues.

[Mario]

Stumbled upon something else: The mentioned lack of RenderTextures for older hardware. How about adding PBuffer/Render_Texture support as a fallback? Think these were introduced with OpenGL 2.1 or so.

Also, especially without a (useable) fallback, there should be some way to check the availability of RenderTextures. At least I haven't found any such function outside their implementation classes. Just something like Shader's IsAvailable().

[Laurent]

RenderTexture::IsAvailable() existed before, when I was using P-Buffer as a fallback to FBO. Now I use a regular context in a hidden window, so the fallback works on every platform, thus there's no need to test the availability.

There are still bugs with some drivers, but no "lack of RenderTextures for old hardware".

[Mario]

So should I see something actually rendered even without proper FBO support? Thought it's meant to be some dummy renderer.

Also just found a documentation bug for sf::Shader:

Code: [Select]

sf::RenderStates states;
 states.Shader = shader;
 window.Draw(sprite, states);

This no longer works (at least under MinGW), as sf::RenderStates want sf::Shader* instead of sf::Shader&. Instead I have to pass the address of the shader object.

[Laurent]

So should I see something actually rendered even without proper FBO support?

Yes, but like I said there are some major bugs with the current implementation.

This no longer works (at least under MinGW), as sf::RenderStates want sf::Shader* instead of sf::Shader&. Instead I have to pass the address of the shader object.

The type of the "shader" variable is not given, it could be a sf::Shader*

[Lee R]

[...]Chained member access would be a nuisance, but I don't think that was the suggestion, and not what I would suggest either.

Code: [Select]

struct Colour
{
    union
    {
        struct
        {
            unsigned char r;
            unsigned char g;
            unsigned char b;
            unsigned char a;
        };
        sf::Uint32 rgba;
    };
};


In this you access the members of Colour instance c by c.r, c.a or c.rgba directly.

Don't forget that if you set one and read the other, the behaviour is undefined according to the C++ standard. In practice it works as expected on most (if not all) platforms, but it can still break one day.[...]

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.

[minirop]

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.

[Mario]

The type of the "shader" variable is not given, it could be a sf::Shader*

I won't take that as a valid solution.

The previous code example (just some lines above), accesses members without dereferencing.

Also, this is actually something a bit weird in general. Almost all other SFML calls use references and don't expect pointers. These do so though.

[Nexus]

Also, this is actually something a bit weird in general. Almost all other SFML calls use references and don't expect pointers. These do so though.

SFML uses pointers in the API when they can be null, references otherwise.

[Mario]

Ah, right, nullable... That one special case.

But something else, any reason for sv::VectorArray being non-transformable?

[Laurent]

But something else, any reason for sv::VectorArray being non-transformable?

It's usually not the final entity, it's lower level than sprite/shape/text.