SFML 2.0

[Laurent]

looks good, it will take a couple of years to do all this right?

I hope to finish it in 2009

[quasius]

I've already added stuff for render masks, if your interested.  I implemented them using the TextureCombiners extension.  (Should be supported pretty much everywhere and avoids issues with requiring main-memory images data, excessive computation, etc.)

Edit:  It would be possible to add a rollback if TextureCombiners is not supported, but I imagine the set of machines that don't support TextureCombiners, but would have enough CPU to calculate this stuff the hard way each frame would be very small.

Edit Edit:  Unless you just want to do everything at load time, but that would make the interface awkward and limit run-time features.

[Laurent]

Yes, I'm interested. Can you send me your implementation?

[quasius]

Yes, I'm interested. Can you send me your implementation?

Yeah, as soon as they let me out of my engineer's <strike>cell</strike> cube and I get home.  :p

[T.T.H.]

- Batch system (particles, tilesets, static strings)

w00t!

- Font outlines

w00t!


Another suggestion: GUI, because nearly everybody needs it and not everybody is willing to include a monster of code like CEGUI. I would suggest to either implement a GUI module directly to SFML or at least make another tutorial about how to integrate another existing GUI besides CEGUI into SFML. In 2008 at the Ogre3D forum there had been plenty of talk about GUIs and several new GUI projects came into existence because many people felt uncomfortable with CEGUI (too big, too slow, too unmaintained). Maybe you can find some inspiration there.

[dabo]

Another suggestion: GUI, because nearly everybody needs it and not everybody is willing to include a monster of code like CEGUI. I would suggest to either implement a GUI module directly to SFML or at least make another tutorial about how to integrate another existing GUI besides CEGUI into SFML. In 2008 at the Ogre3D forum there had been plenty of talk about GUIs and several new GUI projects came into existence because many people felt uncomfortable with CEGUI (too big, too slow, too unmaintained). Maybe you can find some inspiration there.

I would like this, I don't want to use CEGUI, it's just too much. I have done my own implementation of some basic GUI but it is far from optimal

[Laurent]

Another suggestion: GUI

I'd love to do it, really. But it's too much of work and not necessary at all for the other SFML modules, so I just can't do it now.

[irri]

- Batch system (particles, tilesets, static strings)

w00t!

w00t!
I'm looking fordward to the batch system really much!
Cause' I'm making a RPG game with tilegrid-based maps, and particle effects for spells

[Daazku]

I developed a little GUI myself. It work pretty well the only problem is that i didn't finished to create elements... I have only a "box" and a "button" for the moment (Plus an input but i need to rewrite it to work with my new template loader)

It work like this:

Code: [Select]

#include "boost/bind.hpp"
#include "../Gui/GuiHeaders.hpp"

struct WindowRef
{
    sg::RenderWindow &renderWindow;

    WindowRef(sg::RenderWindow &theWindow) :
    renderWindow(theWindow)
    {

    }

    void close()
    {
        renderWindow.Close();
    }
};

int main() {

    sg::RenderWindow window(sf::VideoMode(500, 350, 32), "Daazku", sf::Style::Close, sf::WindowSettings(24,8,4));
    window.LoadTemplate("Gui/template.xml");
    window.SetFramerateLimit(60);

    WindowRef winRef(window);  

    sg::GuiBox* box_Login_Infos = new sg::GuiBox("box_Login_Infos", sf::Vector2f(250,120));
    box_Login_Infos->setMiddleColor(sf::Color(0x1D, 0x36, 0x3A, 150));
    box_Login_Infos->setBorderColor(sf::Color(0xEA, 0xCF, 0xB3));

    sg::GuiInput* input_Login_Name = new sg::GuiInput("input_Login_Name", sf::Vector2f(150,18));
    input_Login_Name->SetPosition(sf::Vector2f(80, 15));
    input_Login_Name->setMiddleColor(sf::Color(0x0F, 0x1D, 0x1D, 130));
    input_Login_Name->setBorderColor(sf::Color(0xEA, 0xCF, 0xB3));
    input_Login_Name->setDefaultText("Login :D");

    sg::GuiInput* input_Login_Password = new sg::GuiInput("input_Login_Password", sf::Vector2f(150,18));
    input_Login_Password->SetPosition(sf::Vector2f(80, 40));
    input_Login_Password->setMiddleColor(sf::Color(0x0F, 0x1D, 0x1D, 130));
    input_Login_Password->setBorderColor(sf::Color(0xEA, 0xCF, 0xB3));
    input_Login_Password->setDefaultText("*******");

    sg::GuiButton* button_Login_Login = new sg::GuiButton("button_Login_Login", sf::Vector2f(80,25));
    button_Login_Login->SetPosition(sf::Vector2f(30, 80));
    button_Login_Login->setMiddleColor(sf::Color::Red);
    button_Login_Login->setBorderColor(sf::Color(0xEA, 0xCF, 0xB3));
    button_Login_Login->setText("Login");

    sg::GuiButton* button_Login_Exit = new sg::GuiButton("button_Login_Exit", sf::Vector2f(80,25));
    button_Login_Exit->setMovable(false);
    button_Login_Exit->SetPosition(sf::Vector2f(140, 80));
    button_Login_Exit->setMiddleColor(sf::Color(0x33, 0x47, 0x64));
    button_Login_Exit->setBorderColor(sf::Color(0xEA, 0xCF, 0xB3));
    button_Login_Exit->setText("Exit");
    button_Login_Exit->setOnMouseButtonClicked(
        boost::bind(&WindowRef::close, &winRef)
    );

    box_Login_Infos->addGuiElement(input_Login_Name);
    box_Login_Infos->addGuiElement(input_Login_Password);
    box_Login_Infos->addGuiElement(button_Login_Login);
    box_Login_Infos->addGuiElement(button_Login_Exit);

    window.addGuiElement(box_Login_Infos);

    while (window.IsOpened())
    {
        window.Clear(sf::Color::Black);

        sf::Event event;
        while(window.getWindowEvent(event)) //<-- This function is the new one to use with the GUI
        {
            if (event.Type == sf::Event::Closed)
            {
                window.Close();
            }
            else if (event.Type == sf::Event::KeyPressed)
            {
                if (event.Key.Code == sf::Key::Escape)
                {
                    window.Close();
                }
            }
        }
        window.Display();
    }

    return EXIT_SUCCESS;
}

Visually:



With my new template loader you can create your own design.

I will try to finish the input element, clean the code and post the source!

For the moment i have another problem with sf::string but that not that bad...

[Nexus]

Sounds great! Continue your great work, Laurent!

Backward compatibility AFTER fixing inconsistencies

I am really glad to hear that.

In general, backward compatibility is frequently achieved at the expense of progress... :roll:

[Daazku]

Source:

http://www.offsetzero.com/download/SFML-GUI.7z

Input element cant compile for the moment.
I need to do alot of work before I can release it but the framework is ok. I only need to add element and do all my TODO XD

I'm having problem to compile me gui in lib.. It work but when i close the project i got a segfault! GDB can't help.. need to talk with Laurent .

[Laurent]

One more thing regarding SFML 2.0: I encourage SVN users to switch to the sfml2 branch, as it will contain all the important new features, and allow me to get feedback for them. The trunk will now just be updated with minor bug fixes for SFML 1.5.

[eleinvisible]

I like to see this project continue forward. All the proposed features (if implemented) would be great. The graphics (batch, shader, render-to-image, and vectors), audio (consistent architecture) and system (DataStream) are changes I see as important. I think that you may be too ambitious; especially to be done within the year!

However, I must suggest that further down the road to allow the render system to be detached from OpenGL all together. This would allow Windows users to swap for a DirectX render. SFML shouldn't depend entirely on OpenGL's future support.

[Daazku]

I like to see this project continue forward. All the proposed features (if implemented) would be great. The graphics (batch, shader, render-to-image, and vectors), audio (consistent architecture) and system (DataStream) are changes I see as important. I think that you may be too ambitious; especially to be done within the year!

However, I must suggest that further down the road to allow the render system to be detached from OpenGL all together. This would allow Windows users to swap for a DirectX render. SFML shouldn't depend entirely on OpenGL's future support.

That a nonsense...

OpenGL is portable and that why sfml use it. If laurent start to code the "window" part in directx and the "linux" part in opengl and the WEG%$Q part in F#!G#G it will be, firstly, time consumming and secondly, near useless because they do the same thing....

[Laurent]

That makes sense, but not for implementing a DirectX backend. It will be necessary for platforms using OpenGL ES, or slightly modified versions of OpenGL.

It's a pretty huge task, but as it will be the base for other ports (iPhone, NDS, OpenPandora, ...) I'll think about it soon. But probably not yet for SFML 2.0.