New graphics API ready

[Laurent]

Could you please post a complete and minimal example that reproduce the problem, for both issues?

[Mario]

Okay, I'm able to reproduce it.

Code: [Select]

#include <SFML/Graphics.hpp>
#include <SFML/Audio.hpp>

int main(void)
{
sf::Texture tex1, tex2;
sf::RenderWindow window;

sf::Sound test1[16]; // this will cause the "tons of threads" (Windows 7 x64 with MinGW32) running a X-Fi Xtreme Music

tex1.LoadFromFile("test1.bmp"); // this texture won't show up on Ubuntu 11.10 (x64 in VirtualBox) - it will show up as test2.bmp

window.Create(sf::VideoMode(320, 240), "");

sf::Sound test2[16]; // this is fine

tex2.LoadFromFile("test2.bmp"); // this is fine too

sf::Sprite spr1(tex1);
sf::Sprite spr2(tex2);
spr2.SetPosition(32,0);

while(window.IsOpened())
{
sf::Event event;
while (window.PollEvent(event))
{
if (event.Type == sf::Event::Closed)
window.Close();
}
window.Clear();
window.Draw(spr1);
window.Draw(spr2);
window.Display();
sf::Sleep(0);
}
}

Output on Windows 7 (x64):


Output on Ubuntu 11.10 (x64; VirtualBox):


The code above also causes the bug with tons of threads created over and over again (X-Fi Xtreme Music; not sure if that's important).

Regarding the two texture files, both are 128x128 pixels, test1.bmp is blue, test2.bmp is red.

[Klaim]

The old one-liners like rt.Draw(sf::Shape::Rectangle(...)) are no longer available. I thought they're rather handy for quick debug drawings. sf::RectangleShape isn't a real perfect replacement due to lacking constructor parameter (you should still be able to set position, colors and thickness through the constructor).

The list of arguments would be really huge, and not as clear as calling individual setters.
Is it really important to be able to fully construct and configure a shape with one line of code?

Wouldn't returning *this from setters allow setting any structure in "one-liners", like in Ogre::Procedural?

Example :

http://codepad.org/OQewh4E1

Code: [Select]

#include <iostream>


class Test
{
public:

    Test( int k ) : m_k(k){}

    int k() const { return m_k; }

    Test& incrementK() { m_k++; return *this; } // note that it's not const

private:

   int m_k;

};



int main()
{
    std::cout << "Test value : " << Test(0)
                                          .incrementK()
                                          .incrementK()
                                          .incrementK()
                                          .k()
                                 << '\n';  // prints "Test value : 3"
    return 0;
}

It's a very powerful idiom for types like Shape and it's child classes (and others I guess) because it allows the developer to provide simple constructor but still allow "in place construction" (where its not a big performance problem to setup the object outside the constructor -- meaning not in Verctor classes for example).

It would allow to write this :

Code: [Select]

rt.Draw(sf::RectangleShape( {0,0} ).SetSize( 100, 100 ) );

Or something similar.
It seems like a minor modification with a great (potential) impact for the user.

[Mario]

That would actually be a neat idea that won't break any existing code.

Well, it's not just about everything being on one line, but right now you have to use a variable with multiple calls, which can be rather annoying if you're trying to draw lots of small stuff you don't want to cache/store over several frames.

[Nexus]

It seems like a minor modification with a great (potential) impact for the user.

No. It is a problem since some functions are defined in base classes, so no type information about the derived class can be kept in the return type.

I like the decision that the constructor only takes the most important arguments, even if this means to split code into multiple lines. It is much clearer than the old

Code: [Select]

sf::Shape::Rectangle(20, 30, 100, 120, sf::Color(200, 30, 150), 3, sf::Color(100, 150, 100, 100));
If you want one-liners, you can still build free functions. For example, I implemented thor::Shapes::Line() to create lines.

[Laurent]

Okay, I'm able to reproduce it

I can't, with the same platforms as you. Make sure that your audio/graphics drivers are up-to-date.

[Klaim]

It seems like a minor modification with a great (potential) impact for the user.

No. It is a problem since some functions are defined in base classes, so no type information about the derived class can be kept in the return type.

True, this way of expressing it works only if real-type-specific functions are called first, then general types.

It would have worked better if CRTP was used I guess.

[c0ffee]

minor inconvenience sf::Text default Color is Black, while documentation says it's White.

[Laurent]

minor inconvenience sf::Text default Color is Black, while documentation says it's White.

It's fixed, thanks.

[c0ffee]

minor inconvenience sf::Text default Color is Black, while documentation says it's White.

It's fixed, thanks.

Wow, fast!
Additionally I get error on exit in Windows7 when using default font for sf::Text
Have legacy ati card.

[Mario]

Okay, I'm able to reproduce it

I can't, with the same platforms as you. Make sure that your audio/graphics drivers are up-to-date.

They are, plus for the audio issue, I've been able to reproduce it with an alternative sound card set as default device, too. Will try a bit more tomorrow.

[Contadotempo]

Hi, since I've been using the new API I can't execute SFML applications on my laptop. It's an Intel integrated 945 graphics chip. Drivers are up to date.

The executable crashes right after (or while) creating an sf::RenderWindow.

I get the error: Unhandled exception at 0x00000000 in Intel Graphics.exe: 0xC0000005: Access violation.
The program '[3796] Intel Graphics.exe: Native' has exited with code -1073741819 (0xc0000005).

This is the call stack for the application:


The source is here: http://www.sfml-dev.org/documentation/2.0/
Except I exchanged sf::Window with sf::Renderwindow

What can I do? Did I do something wrong?
Thanks in advance.

[model76]

Also, maybe I missed it, but it's (for now?) no longer possible to create a sf::Shape with different colors at different points? Tempted to reimplement that, cause I thought it's been rather handy for gradients and such.

You're right, this feature was removed. I admit that I was not happy to drop it, but with the new API I can no longer have both a global color and a color for each point, so i had to choose.

That seems like a huge loss to me!  
Are you sure that is the right choice? Or is there another way to easily create gradient effects in SFML now?

[asdfghjkSHfkgAD,kgaSkd]

The old one-liners like rt.Draw(sf::Shape::Rectangle(...)) are no longer available. I thought they're rather handy for quick debug drawings. sf::RectangleShape isn't a real perfect replacement due to lacking constructor parameter (you should still be able to set position, colors and thickness through the constructor).

The list of arguments would be really huge, and not as clear as calling individual setters.
Is it really important to be able to fully construct and configure a shape with one line of code?

I signed up for an account specifically to ask if the old one-liners could be put back into the API. I use them all over the place to add things like borders or bezels around pictures or text. I understand that I can still do this with the RectangleShape class, but if I have to draw 30 rectangles I would much rather write

Code: [Select]

Window.Draw( Shape::Rectangle( ... ) );

rather than

Code: [Select]


RectangleShape rect;
rect.SetPosition( ... );
rect.SetSize( ... );
rect.SetFillColor( ... );
rect.SetOutlineColor( ... );
rect.SetOutlineThickness( ... );
Window.Draw( rect );


I understand that the one-liner isn't as clear as calling the individual setters but that doesn't mean that it should be taken out. For example, if I just want to quickly draw a rectangle around a sprite during a debugging session to confirm that the bounding box is what I expect it to be, I don't need the clarity that using the setters would give, I just want to quickly write the single line of code and move on.

As Nexus said, we could write our own function or macro to get back the one-line functionality, but considering that the functions were already in SFML and are now being removed it seems like a straight downgrade with no upside.

[Laurent]

Additionally I get error on exit in Windows7 when using default font for sf::Text

It's a known bug.

Hi, since I've been using the new API I can't execute SFML applications on my laptop.

Make sure that you made a complete recompile.

Are you sure that is the right choice? Or is there another way to easily create gradient effects in SFML now?

You can now use vertex arrays to do whatever you want.
And if I change the implementation to be GL 2.0 (shaders only) soon, I'll probably be able to put the global color back.

I understand that the one-liner isn't as clear as calling the individual setters but that doesn't mean that it should be taken out.

Shapes have more properties now (texture, texture rect) it's no longer possible to have them all in the constructor. The best solution now is really to create your own functions for building shapes, so that you can choose only the properties that you're interested in.