SFML 2.0

[Laurent]

Hi

This topic is an open discussion about SFML 2.0. You're all encouraged to give your opinion

I made the choice to start working on it because the list of important features is growing more and more. And I won't be able to implement them properly without doing majors breaks in the current API.

So, here is my wish list for SFML 2.0. Some items are new, some others were already in the todo-list. Note that this list is an open draft, not a fixed roadmap. I'll probably update it after I've thought in detail about every item.

System
- Add functions to sf::Vector2 and sf::Vector3
- Generalization of data access for loading resources (from files, from memory, ...) with a DataStream framework
   
Window
- Rewrite of OpenGL contexts handling to make it more elegant, more robust and easier to use
- Unlink sf::Input from sf::Window, make it use direct OS calls rather than relying on windows events
- More robust and flexible keyboard mapping system
- Add events / functions for touchpad-like devices
- Improve the event system to add blocking retrieval
   
Network
- Rewrite of sockets API to make it more than just a wrapper around BSD sockets
- Rewrite of selector API to adapt it to the new sockets
- Add connected mode for UDP sockets
- Improve http / Ftp (more control for long operations)
   
Audio
- Use a context system (similar to Graphics), remove the current system (AudioResource)
- Plugin system for custom audio file formats
- Experiment audio effects ?
   
Graphics
- Batch system (particles, tilesets, static strings)
- Render-to-image
- Rendering masks
- Cleaner and safer OpenGL context use (according to the changes in Window module)
- Geometry for Drawables (GetRect, ...)
- Rewrite of sf::PostFx to make them more powerful (--> sf::Shader)
- Font outlines
- Plugin system for custom image file formats
- Vectorial rendering
   
General
- Fix inconsistencies in public API
- Backward compatibility

[Mr. X]

sounds great...

[Groogy]

Sounds promising
Even though I'm new to SFML

Though I'm wondering what the change will be to PostFX? Will sf::Shader be easier or what?

[Tank]

- More robust and flexible keyboard mapping system

Yes, please. I'm currently writing a generic console for my upcoming game, and it's really a pain to map the keycodes to their corresponding characters. I think I'll write some utility function to convert it. Depending on how you're planning to implement this, I can provide you the sources when ready.
   

Network
- Rewrite of sockets API to make it more than just a wrapper around BSD sockets

How does that look in detail? I'm absolutely fine with "just being a wrapper".

Improve http / Ftp (more control for long operations)

Do you think a media library needs such enhanced support for the FTP and HTTP protocols? This point should be very low in priority.

Graphics
- Batch system (particles, tilesets, static strings)

Uhhh yeah, I'm really looking forward seeing batching in action. It's something that I really miss in SFML.

Vectorial rendering

This is also absolutely great. Do you mean something like SVG and similiar? I guess it could be implemented through another Drawable class, right?

General
- Fix inconsistencies in public API
- Backward compatibility

Backward compatibility AND fixing inconsistencies? That sounds not being possible.

Generally it's cool that SFML still gets developed like hell. This is going to be a library of first-choice, no matter what!

[Groogy]

How about image resizing? That would be really helpful to me :p

Err, might be that I'm new, but isn't that already possible by using the scale functions?

**EDIT**
Aah sorry, that's just sprites. Though you can probably still do it very low-level like yourself with the Image ptr.

[Laurent]

How does that look in detail? I'm absolutely fine with "just being a wrapper".

Doing a wrapper was fine, until I realized my code was just a C++ translation of the BSD sockets but with less features.
I think I can do much better while keeping all the original features

Do you think a media library needs such enhanced support for the FTP and HTTP protocols? This point should be very low in priority.

Absolutely. But having progress notification / pause / resume stuff is a minimum for operations such as upload and download.

This is also absolutely great. Do you mean something like SVG and similiar? I guess it could be implemented through another Drawable class, right?

Yep, something like SVG. I still don't know if it's going to be a new module, a new Drawable or an option to replace the "bitmap" rendering of existing drawables (especially shapes and strings).

Backward compatibility AND fixing inconsistencies? That sounds not being possible.

Backward compatibility AFTER fixing inconsistencies

How about image resizing? That would be really helpful to me :p

What kind of image resizing?

[Laurent]

Can't you just use a sprite with different scale?

[Groogy]

Can't you just use a sprite with different scale?

Yeah I thought so too.

[christoph]

Window
- Unlink sf::Input from sf::Window, make it use direct OS calls rather than relying on windows events

Sounds exactly like the thing I need for my other (not yet public) project!

General
- Fix inconsistencies in public API
- Backward compatibility

Thanks

[Laurent]

Well I'm loading in a whole bunch of 1024x768 images, and displaying thumbnails of them

Ok, I thought you were displaying both the thumbnail and the original image.

You can easily write your own scale function, or use some existing code.

[dabo]

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

[Daazku]

couple of MONTHS  

edit:  :twisted: THE DEVIL POST! :twisted:

[Astrof]

couple of days?
btw, look at ur post count: 666 (at the moment of this msg)

[Daazku]

:twisted:

[SamuraiCrow]

The batch system would certainly be useful considering that there wouldn't be a way to do mesh rendering techniques otherwise.  That would even still be useful in 2 dimensional graphics.