Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: SFML 2.0  (Read 102864 times)

0 Members and 1 Guest are viewing this topic.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
SFML 2.0
« on: January 29, 2009, 06:56:12 pm »
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
Laurent Gomila - SFML developer

Mr. X

  • Jr. Member
  • **
  • Posts: 80
    • View Profile
SFML 2.0
« Reply #1 on: January 29, 2009, 07:26:52 pm »
sounds great...

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
SFML 2.0
« Reply #2 on: January 29, 2009, 07:36:30 pm »
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?
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
Re: SFML 2.0
« Reply #3 on: January 29, 2009, 08:26:01 pm »
Quote from: "Laurent"
- 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.
   
Quote
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".

Quote
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.

Quote
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.

Quote
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?

Quote
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

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
SFML 2.0
« Reply #4 on: January 29, 2009, 08:37:21 pm »
Quote from: "Wavesonics"
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.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
SFML 2.0
« Reply #5 on: January 29, 2009, 08:39:55 pm »
Quote
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 ;)

Quote
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.

Quote
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).

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

Backward compatibility AFTER fixing inconsistencies :D

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

What kind of image resizing?
Laurent Gomila - SFML developer

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
SFML 2.0
« Reply #6 on: January 29, 2009, 08:45:13 pm »
Can't you just use a sprite with different scale?
Laurent Gomila - SFML developer

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
SFML 2.0
« Reply #7 on: January 29, 2009, 08:46:13 pm »
Quote from: "Laurent"
Can't you just use a sprite with different scale?


Yeah I thought so too.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

christoph

  • Full Member
  • ***
  • Posts: 102
    • View Profile
    • http://www.christoph-egger.org
Re: SFML 2.0
« Reply #8 on: January 29, 2009, 09:15:55 pm »
Quote from: "Laurent"

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!
Quote

General
- Fix inconsistencies in public API
- Backward compatibility

:)

Thanks ;)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
SFML 2.0
« Reply #9 on: January 29, 2009, 10:33:24 pm »
Quote
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.
Laurent Gomila - SFML developer

dabo

  • Sr. Member
  • ****
  • Posts: 260
    • View Profile
    • http://www.dabostudios.net
SFML 2.0
« Reply #10 on: January 29, 2009, 11:27:04 pm »
looks good, it will take a couple of years to do all this right? ;)

Daazku

  • Hero Member
  • *****
  • Posts: 896
    • View Profile
SFML 2.0
« Reply #11 on: January 29, 2009, 11:46:41 pm »
couple of MONTHS  :P

edit:  :twisted: THE DEVIL POST! :twisted:
Pensez à mettre le tag [Résolu] une fois la réponse à votre question trouvée.
Remember to add the tag [Solved] when you got an answer to your question.

Astrof

  • Full Member
  • ***
  • Posts: 135
    • View Profile
SFML 2.0
« Reply #12 on: January 30, 2009, 12:46:04 am »
couple of days?
btw, look at ur post count: 666 (at the moment of this msg)

Daazku

  • Hero Member
  • *****
  • Posts: 896
    • View Profile
SFML 2.0
« Reply #13 on: January 30, 2009, 04:00:09 am »
:twisted:
Pensez à mettre le tag [Résolu] une fois la réponse à votre question trouvée.
Remember to add the tag [Solved] when you got an answer to your question.

SamuraiCrow

  • Newbie
  • *
  • Posts: 40
    • Yahoo Instant Messenger - samuraileumas
    • View Profile
SFML 2.0
« Reply #14 on: January 30, 2009, 05:54:28 am »
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.

 

anything