SFML community forums
General => General discussions => Topic started by: Laurent 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
-
sounds great...
-
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?
-
- 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!
-
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.
-
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 :D
How about image resizing? That would be really helpful to me :p
What kind of image resizing?
-
Can't you just use a sprite with different scale?
-
Can't you just use a sprite with different scale?
Yeah I thought so too.
-
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 ;)
-
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.
-
looks good, it will take a couple of years to do all this right? ;)
-
couple of MONTHS :P
edit: :twisted: THE DEVIL POST! :twisted:
-
couple of days?
btw, look at ur post count: 666 (at the moment of this msg)
-
:twisted:
-
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.
-
looks good, it will take a couple of years to do all this right?
I hope to finish it in 2009 ;)
-
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.
-
Yes, I'm interested. Can you send me your implementation?
-
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
-
- 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.
-
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 :)
-
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.
-
- Batch system (particles, tilesets, static strings)
w00t!
w00t! :P
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 :P
-
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:
#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:
(http://img390.imageshack.us/img390/9602/appercu4gq0.th.jpg) (http://img390.imageshack.us/my.php?image=appercu4gq0.jpg)
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...
-
Sounds great! Continue your great work, Laurent!
Backward compatibility AFTER fixing inconsistencies :D
I am really glad to hear that. :)
In general, backward compatibility is frequently achieved at the expense of progress... :roll:
-
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 :D.
-
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.
-
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.
-
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....
-
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.
-
Detaching SFML from a specific graphics library is currently something that would extremely retard the on-going development. I'd rather suggest to create a separate branch and eventually delegate this to another person, so that the mainline development with SFML doesn't almost freeze.
But generally, I'm absolutely fine with OpenGL. What are the reasons for DX-lovers here? ;)
-
I'd rather suggest to create a separate branch and eventually delegate this to another person, so that the mainline development with SFML doesn't almost freeze
It will be done in a separate branch after SFML 2.0, but not by another person ;)
What are the reasons for DX-lovers here?
I'm not a Dx lover but I can answer : the only reason would be to support Dx-only platforms (XBox).
Other than that, there's really no need for DirectX in this context.
-
Some one is doing it in he french forum :P. (Near finish i think)
-
Some one is doing it in he french forum :P. (Near finish i think)
?????
-
Some one is doing it in he french forum :P. (Near finish i think)
Aren't you misunderstanding with the iPhone port ?
-
The iPhone port has been discussed on the english forum. I think he's confused about the Delphi project using a Wiimote.
-
I'd rather suggest to create a separate branch and eventually delegate this to another person, so that the mainline development with SFML doesn't almost freeze
It will be done in a separate branch after SFML 2.0, but not by another person ;)
Well, if someone just branches the mainline by himself, there's nothing you can do against it. ;) j/k
I'm not a Dx lover but I can answer : the only reason would be to support Dx-only platforms (XBox).
Other than that, there's really no need for DirectX in this context.
I think this is again minor important for a graphics library primarily designed for the PC. So it's good so see the same opinion from you. :)
Btw, are you really developing SFML completely on your own? The only hint is the SVN log, where at least two usernames appear.
-
Well, if someone just branches the mainline by himself, there's nothing you can do against it
I still have to give him write access so that he can commit his branch :P
Btw, are you really developing SFML completely on your own? The only hint is the SVN log, where at least two usernames appear.
I'm developing the Windows/Linux version of the main library, as well as the C and .Net bindings.
The rest (OSX port, Python binding, D binding) are maintained by external contributors :)
-
I still have to give him write access so that he can commit his branch :P
I doubt that. That person could easily open an own repository and even announce it here! ;)
-
The iPhone port has been discussed on the english forum. I think he's confused about the Delphi project using a Wiimote.
My bad :S.
-
Yes, I'm interested. Can you send me your implementation?
I just remembered that I'd forgotten about this... Now I just need to remember when I'm home.
-
I doubt that. That person could easily open an own repository and even announce it here!
Of course. But that would never be officially integrated to SFML.
-
Sent to your email. I also included uses of AlphaMasks/ RenderMasks for texture blending and texture shadowing.
Also, as far as changing the interface, do you know yet what changes will be necessary? If so, making as many as them as possible immediately might be better then incrementally changing the interface. I'd prefer a one-time transition than having to modify my code everytime I update. (Although I certainly understand it's not possible to anticipate every possible interface change you may need.)
-
Sent to your email. I also included uses of AlphaMasks/ RenderMasks for texture blending and texture shadowing.
Thank you very much :)
Also, as far as changing the interface, do you know yet what changes will be necessary? If so, making as many as them as possible immediately might be better then incrementally changing the interface. I'd prefer a one-time transition than having to modify my code everytime I update. (Although I certainly understand it's not possible to anticipate every possible interface change you may need.)
I'll do my best to include all the interface changes in SFML 2.0. I hope to be able to provide backward compatibility after that.
-
I'll do my best to include all the interface changes in SFML 2.0. I hope to be able to provide backward compatibility after that.
I was referring more to the SVN builds, which I understand are all WIP and such. But if you already know an interface change that will be necessary, I think it's better to go ahead and make it sooner rather than later if possible.
-
Ok I get it. I'll do my best ;)
-
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.
Is that the latest state? Because it would be great to have a GUI so that not every programmer must use CEGUI or develop his own GUI.
If the only problem is, that you couldn't do it because you haven't got the time to implement it, it could be delegated to another person...
I would offer to do this (I've already developed a small GUI-System that works), if necessary and wished...
-
But would your work fit SFML philosophy ?
-
But would your work fit SFML philosophy ?
What do you exacly mean with "SFML philosophy"? That it is small, easy, flexible, portable and object oriented?
-
But would your work fit SFML philosophy ?
What do you exacly mean with "SFML philosophy"? That it is small, easy, flexible, portable and object oriented?
Only Laurent can really answer this, but I think that's most of it.
-
Actually, I'd like to do it myself.
This is a funny and interesting thing I'd love to do, after I've worked hard on a lot of boring stuff for SFML 2.0 :)
-
Actually, I'd like to do it myself.
This is a funny and interesting thing I'd love to do, after I've worked hard on a lot of boring stuff for SFML 2.0 :)
Great...
-
But you other guys shouldn't hesitate to implement your own SFML-compatible GUI and release it. I need one for my current project and CEGUI and guichan are no real options for me (CEGUI is misconfigured and refuses to build, guichan would be possible, but needs a new driver for SFML, thus the efford you put into that could be better used for a clean SFML-based GUI), so I started one myself. It's a bit inspired by the gtkmm hierarchy. As soon as it gets usable, I'll release a version here.
-
Do you know there are about 4, 5, maybe more "small SFML gui" that are being developped by users right now (I'm doing one myself too) ?
-
No, I don't. Since I only read the English (and German) forums, I haven't seen a proper thread in the projects board recently. My French is just too bad.
The question is how flexible those "small GUIs" are. Most people program their stuff to fit (only?) into their current project. Are the mentioned GUIs flexible enough to be used more generally? Also, if you could provide some links, I'd be thankful. I wouldn't do my own GUI if I knew of another good GUI for SFML.
-
I can't tell you of any fully usable GUI for now.
I know one that uses widget hierarchy, one that does not, but none of these is finished.
I can speak a bit of mine.
It's an immediate mode GUI (widgets can't contain sub-widgets) made for a video game I'm developing with some friends of mine but I don't think it's limited to my project.
I'm focusing on three points :
- customizable : the whole GUI design (widgets' background/border color, text color, color when it's enabled/disabled, border width) can be loaded from an XML file
- extendable : you can make your own widgets really easily by subclassing my base Widget class
- easiest use : minimal functions (developer), intuitive interface behaviour (user)
It's obviously portable. For now it depends on libxml2, boost and SFML. I'll drop the libxml2 dependency as soon as I think of it.
What I've done till now : global interface event handling, global interface drawing, focus handling, base widget, text field (insertion, moving with cursor and deletion), button (using boost for target function binding) and simple box. Plus an XML file loader and a Matrix class. What I'm working on : TableView, Label, Checkbox and RadioButton.
Now.. if you wish.. I can give you the current sources. They are mostly not commented.
-
That sounds really good, but I'm not a friend of immediate GUIs. I'd like to have a similar approach like gtkmm, that means: Specify an XML file with all widget definitions, load it with one function call and connect signals/events to callbacks. This is maybe not really a "game-ish" approach, but I just like it better than immediate.
Everything else of your GUI just sounds good, it seems to be well advanced. What about showing some screenshots? I'd be interested in seeing it. Or is there a demo/video available?
-
I don't want to go on talking about this in the SFML 2.0 topic. I'll send you a private message.
-
This is a funny and interesting thing I'd love to do, after I've worked hard on a lot of boring stuff for SFML 2.0
Great!
In which version of SFML do you integrate a GUI? SFML 2.0?
-
No. Hopefully in version 5.0 or something :lol:
-
Uh... lol :mrgreen:
-
Just write your own GUI or use an existing one. Then you can meet all your desires. :)
The probability, that an SFML-integrated GUI is not exactly as you imagined, is very big anyway... ;)
-
And since Laurent works alone, a release in version 5.0 is quite a realistic forecast. ;)
Ceylo, you've got a cool GUI in progress, just go with it. :)
-
I can't wait to use sf::RenderImages ! :p
-
Idk if it has been discussed before, but maybe some sort of process control would be a good addition.
Being able to spawn new processes and such. Sure would be useful to me!
I think that it goes beyond the scope of SFML. And there are already good libraries for this stuff (boost::process).
Also, true static linking builds that require no DLLS to run
If you're talking about libsndfile and OpenAL DLLs, I can't link them statically because they are LGPL.
And maybe going forward Linux 64bit binaries?
Is it that hard to build SFML? ;)
But yeah, maybe I'll provide those 64-bit binaries in the next release.
-
Also, true static linking builds that require no DLLS to run
If you're talking about libsndfile and OpenAL DLLs, I can't link them statically because they are LGPL.
LGPL don't provide static compilation ??
-
LGPL don't provide static compilation ??
It does, but then your project has to be LGPL itself. And SFML is not.
-
Also, true static linking builds that require no DLLS to run
If you're talking about libsndfile and OpenAL DLLs, I can't link them statically because they are LGPL.
LGPL don't provide static compilation ??
If SFML was statically linked against it would effectivle become LGPL Licensed itself ;)
-
Ok, thanks for indication. :)
-
Idk if it has been discussed before, but maybe some sort of process control would be a good addition.
Being able to spawn new processes and such. Sure would be useful to me!
I think that it goes beyond the scope of SFML. And there are already good libraries for this stuff (boost::process).
boost::process seems pretty BA, but isn't it still in the sandbox?
-
About the gui discussion, it would fairly simple to port over guichan as it already has an opengl port but it will need a SFML for the event processing.
The framework for like the accelerometer and touches are somewhat done already on the iPhone code I've posted in the other thread so it shouldn't be too hard to clean it up and add it.
-
About the gui discussion, it would fairly simple to port over guichan as it already has an opengl port but it will need a SFML for the event processing.
Yeah, I have worked on it, the port also should include an ImageLoader class (for loading BMP fonts)
I will put it to the wiki in the future.
-
Ok, the tutorial is online, but only in French at the moment.
But there is a package (not stable yet) on the wiki page.
Requires SFML 1.4 and Guichan 0.8.1
-
Great !! I've recently been looking at Guichan and I was about to do the backend you've just been doing..
I'm really pleased to see it now, thank you very much !
-
I don't know if this was requested:
A transparent "preemptive" priority sound manager.
Because OpenAL can go from 16 to 62 sources (optimistically). Maybe more with some fat-ass sound cards, but those aren't probably owned by the common public.
Like for example, it could have this interface (it feels somewhat redundant, it could be worked out):
void Sound::SetPriority(float Priority);
void Sound::SetSeizable(bool Seizable);
void Sound::SetOwnsSource(bool OwnsSource);
priority[0..1]: default 0.5
seizable: default false
OwnsSource: default true
This default values yield a "classic" behaviour.
So if a sound is requested to play:
If there are free sources: Attach to a source and play it
If no sources are available: Seize the source of a less or equal priority sound that is seizable.
Sounds that own the source are not in the pool of non-playing sources until they are destroyed.
If the lib is meant to be easy, it should have this functionality. Everything is explained like Sound is to audio like a Sprite is to Graphics.
But Sound actually is owning a resource (AL's Source), Sprites don't.
For instance, every enemy object owns it's own sprite. But if they wanted to own their own Sound... it would fail miserably on some drivers.
On other drivers, it would just allow me to have ilimited sources but only play some and stop playing when it runs out of real internal sources (without priority).
Also, if the user wants to implement its own manager, or don't care... then it just have to leave this parameters as default.
EDIT: it could also take into account the distance to the listener to roughly degrade the priority by the distance (roughly=fast=sqrt table).
Thanks
-MartÃn
-
Also, true static linking builds that require no DLLS to run
If you're talking about libsndfile and OpenAL DLLs, I can't link them statically because they are LGPL.
LGPL don't provide static compilation ??
Actually, LGPL 3.0 corrected for that but I think the libraries used are under LGPL version 2.x .
-
A transparent "preemptive" priority sound manager
SFML-Audio is not an audio engine, the "word" manager is already out of its scope ;)
There are better libraries if you want a more professional and complete engine (like FmodEx).
Plus, using a software implementation of OpenAL (like OpenAL-Soft which is more or less becoming the new standard -- and is what SFML uses on Windows), you can have any number of sources. The default is 256 but you can change it to whatever you want.
-
A transparent "preemptive" priority sound manager
SFML-Audio is not an audio engine, the "word" manager is already out of its scope ;)
There are better libraries if you want a more professional and complete engine (like FmodEx).
Plus, using a software implementation of OpenAL (like OpenAL-Soft which is more or less becoming the new standard -- and is what SFML uses on Windows), you can have any number of sources. The default is 256 but you can change it to whatever you want.
FmodEx has a commercial paid licence, ranging from u$s100 to u$s6000 per product.
That's the thingy. I don't have that kind of cash, not even the hundred bucks, to invest.
OpenAL-Soft, it may accept 256 sources but sometimes sounds don't start to even play (when my game is really filled with enemies).
I notice this because the shooting sound is fired 3 times per second, and it's really noticeable when it skips one.
I should look deeper into this, maybe making specific benchmarks.
Even thou, that wont address the "sprite to graphics = sound to audio" point.
For an entity I can have as many sprites as I want (eg. cannons, ship, rockets, cockpit, etc.), but not multiple sounds.
If I have 100 entities that own 5 sf::Sounds, (charge shoot, shoot, move, collide, destroyed). It will fail.
(As a comparison, in space invaders there are 55 invaders per screen... 100 isn't really a big number)
That makes the Sound class not really useful.
Perhaps not a manager, but a simple Source pool.
That makes SFML "own and handle" OpenAL's sorces, and those could be acquired or releseased by sf::Sound depending on the sound's state: playing or paused/stopped, respectively.
It's not trivial to implement if you want Sounds to be able to play more that once at the same time.
Regards
-MartÃn
-
Even thou, that wont address the "sprite to graphics = sound to audio" point.
For an entity I can have as many sprites as I want (eg. cannons, ship, rockets, cockpit, etc.), but not multiple sounds.
If I have 100 entities that own 5 sf::Sounds, (charge shoot, shoot, move, collide, destroyed). It will fail.
Why? Just increase the maximum number of sources in OpenAL-Soft and it will work.
Moreover, having 5 sound sources per enemy and 100 of them doesn't seem to be a good design.
That makes the Sound class not really useful.
... for you. I don't think many users will need 500 sound sources ;)
Implementing a pool/manager/whetever so that it is completely invisible for the end user can be a complex task, I have many other complex tasks to complete (mainly on the graphics side) before thinking about this kind of stuff.
-
Moreover, having 5 sound sources per enemy and 100 of them doesn't seem to be a good design.
... for you. I don't think many users will need 500 sound sources ;)
I don't want 500 sources, just 500 sound flyweights.
Not that I'll be playing them simultaneously, as I'm not drawing 100 sprites simultaneously neither.
But I need to keep the entities' states (i.e.: health/position/angle...) so the logic solution is have them owning a "sound source pointer" (Sound), not a source (which is a resource), such as sprites have a "texture pointer", they don't own their textures (resource).
What would you recommend to have instead of a bunch of sf::Sound per entity?
I understand you have more important stuff to do. I don't want you working for me :lol: . I just think it would be an upgrade to the library.
I'm making a source pool out of need, compatible with SFML (an alternative "ManagedSound" which is mostly a copy of sf::Sound), so if you want I can contribute with that. Of course it would need rework, but as a starting point it would be useful and less of a burden.
-
Been using SFML last couple weeks and I must say I do like it very much. The only thing i might suggest that wasn't in your list is to make all the file loading functions accept std::wstring for the filename in addition to std::string that they use currently.
-
It is actually in the list ;)
The "DataStream framework" will address this issue, by enabling any custom type of source stream for loading resources.
-
ot, my mistake.
-
window::rotate
-
window::rotate
:?:
-
window::rotate
:?:
sorry, i meant to say view::rotate :)
-
Yep, it will probably be added to SFML 2.0 (I just have to make sure it doesn't break anything).
-
What about an easy interface to create multiple viewports?
-
What about an easy interface to create multiple viewports?
What functionality would you need which isn't provided by sf::View?
-
What about an easy interface to create multiple viewports?
What functionality would you need which isn't provided by sf::View?
multiple cameras looking at different places in the world at the same time visible on the screen (think of the commandos games)
-
multiple cameras looking at different places in the world at the same time visible on the screen (think of the commandos games)
I think render to texture would be able to handle that (a texture for each view-port).. that is if I understood correctly.
-
I think render to texture would be able to handle that (a texture for each view-port).. that is if I understood correctly.
Correct.
However there may be a simpler/more efficient way of doing it, using OpenGL viewports.
I'll add a new task in the tracker for SFML 2.0 :)
-
This is not really in the scope of SFML.
-
i haven't tried it yet, but does sfml or windows in general support playing with 2 gamepads of the same type at the same type?
for example: can i plug in 2 playstation 3 controllers and get different input from each controller?
edit: does sfml support gamepads in general?
-
Windows can. And I think SFML can also ( JoyButtonPressed, JoyButtonReleased, JoyMoved ) . But maybe I'm wrong and two different physical button are linked to the same event. I mean one on each gamepad.
-
SFML supports up to two joysticks at the same time.
-
Long time ago, a software renderer as a fallback was talked about, any plans for this in the future still?
This would make my day. Some systems just don't agree with OpenGL.
-
It's still planned, but with a very low priority. I'll probably think about it again after SFML 2.0 is stable enough.
-
I don't know if this has been asked, but a String that renders to a texture on SetText, instead of having a character set.
This is EXTREMELY necessary for multilingual writing or languajes with a really big charset (like Mandarin).
If I would like chatting on a game to be completily internationalized (any language character displayed) I can't use the current String implementation.
It's very limited.
Word wrap/clipping rect would also be really good (for simple GUI rendering).
Also I recommend again an option to disable font antialiasing (In FreeType), for pixel-based games. It would be like what "SetSmooth" is to Image, but with the need of re-rendering the charset.
Regards
-MartÃn
-
Just a little remark cause I just found that:
The whole SFML2.0 graphics namespace seems to be fully compatible to SFML1.5 except that Sprite.Center is missing. I know SFML2.0 isn't released yet, so I bet it would have been implemented until then, but hust wanted to mention it anyways, so it wont be forgotten.
-
I don't realise the need about render to texture for strings, but I totally agree with an option to disable text antialiasing. Word wrap/clipping would also be fine but looks more important to me.
-
I don't know if this has been asked, but a String that renders to a texture on SetText, instead of having a character set.
And then what? Reload the font file entirely / render glyphs to bitmap / copy pixels to the texture every time SetText is called? :shock:
But I agree, I'll try to remove the charset limitation in SFML 2.0 and make something more dynamic.
Word wrap/clipping rect would also be really good (for simple GUI rendering).
It's in the roadmap ("clipping masks" or something).
Also I recommend again an option to disable font antialiasing (In FreeType), for pixel-based games. It would be like what "SetSmooth" is to Image, but with the need of re-rendering the charset.
I think that pixel-based games will use pixellated fonts. They render very well in SFML.
-
The whole SFML2.0 graphics namespace seems to be fully compatible to SFML1.5 except that Sprite.Center is missing
It's now called Origin ;)
-
I don't realise the need about render to texture for strings, but I totally agree with an option to disable text antialiasing. Word wrap/clipping would also be fine but looks more important to me.
The current implementation precaches a limited charset (Latin-1 I think), and optionally you can set your own.
What this does is render all the character glyphs to a texture and afterwards, when rendering, each sf::String character is a quad (opengl jargon) mapped to a portion of that texture.
If I wanted to enable the writing of several languages glyphs (like mandarin chinese, greek, cyrillic, ...):
1. It will use a lot of space saving pre-rendered glyphs
2. They probably wouldn't fit in a hardware supported texture size.
I don't know if this has been asked, but a String that renders to a texture on SetText, instead of having a character set.
And then what? Reload the font file entirely / render glyphs to bitmap / copy pixels to the texture every time SetText is called? :shock:
But I agree, I'll try to remove the charset limitation in SFML 2.0 and make something more dynamic.
The font kept on memory (inside a sf::Font).
Approach 1:
Render to bitmap using FreeType and recreate a texture each time the text changes.
Approach 2:
Clipping would be mandatory to prepare a texture of good proportions.
Render glyphs to bitmap.
Load the pixels with glTexSubImage2D on the texture you already have (as it's faster than glTexImage2D).
This could implement clipping/word-wrapping or even right-to-left rendering (if needed) directly from FreeType.
Previous to rendering, the new string and a cached one should be tested for equality to avoid a costly operation.
Of course this is intended not as a replacement for sf::String, but for a totally different functionality.
This wouldn't be intended for dynamic text but for static not-changing-much text.
For example, in an in-game chat you could have a queue with a number of sf::NoCharsetString that have messages from other players, keeping them across each frame, and drawing them (without rendering the font)/freeing after use. The position could be changed without problems.
Also, when using for example 2500 character, you would reduce the triangle use (rendering) from 5000 to 2 (with the texture memory cost)
So, with the speed fact properly documented, it would be a nice adition to the SFML arsenal.
On a sidenote: this could enable all sprite utilities on it, like flipping.
Word wrap/clipping rect would also be really good (for simple GUI rendering).
It's in the roadmap ("clipping masks" or something).
Yes, but I believe it should be together with word wrapping, clipping mostly in a vertical direction, and "newlining" wrapping per words or, if they're too long, per character.
This isn't internationalization friendly (as there are a LOT of rules for word wrapping on other languages) but for half the world that uses a latin alphabet it would be sufficient.
Also I recommend again an option to disable font antialiasing (In FreeType), for pixel-based games. It would be like what "SetSmooth" is to Image, but with the need of re-rendering the charset.
I think that pixel-based games will use pixellated fonts. They render very well in SFML.
Even when using a pixelated font (Like ProFont (http://www.tobias-jung.de/seekingprofont/)) FreeType antialiases the borders.
I've already posted a topic on this.
If you don't want FreeType to do this, when rendering to an image you should pass that you want "monochrome" rendering.
Regards
-MartÃn
-
Even when using a pixelated font (Like ProFont) FreeType antialiases the borders
I tried, and pixel-based fonts render perfectly, there's no visible antialiased edge. Which is normal because a pixellated font will only have hard edges, no antialiasing is needed.
-
That's not the issue.
Perhaps I can't use a font because if it's licence and can't ship the game with the game for that reason, or I want some other font in game that doesn't have a pixel version.
If I want to use a Liberation font in point size #4 (which is rather pixelated), it would be nice to be able to disable antialiasing. It's just adding another optional parameter in font load :roll: :D
Then (without smoothing) I could scale the sf::String to draw a bigger and more readable text.
-
If I want to use a Liberation font in point size #4 (which is rather pixelated), it would be nice to be able to disable antialiasing. It's just adding another optional parameter in font load
Then (without smoothing) I could scale the sf::String to draw a bigger and more readable text.
This would look ugly ;)
-
is it intentional that a sprite moves its position when you change its center?
-
Yes, because the position (which doesn't change) is now the position of the new center :D
-
applying textures to shapes would be awesome.
-
For doing what? Do you have a useful example?
-
Textured polygons would be useful, like in Soldat. Also SDL_gfx provides textured polygons, so perhaps it is something SFML should provide as well?
-
Textured polygons would be useful, like in Soldat
What is Soldat?
Also SDL_gfx provides textured polygons, so perhaps it is something SFML should provide as well?
SFML doesn't aim at being a clone of SDL & co ;)
-
Soldat is a free 2D shooter game online. The maps are done with textured polygons.
Its a good idea if you want to use polygon collisions.
-
Very good game btw:
www.soldat.pl to download it.
-
For doing what? Do you have a useful example?
example: i want to do a 2d sidescroller that isn't based on tiles, because tiles limit your accuracy of movement (cause tiles are quad blocks). you can't really do realistic slopes, you always have to simulate them. stuff like loopings that aren't hardcoded like the ones you see in the sonic games would also be very hard to do. having actual slopes (meaning lines that are somehow rotated) makes calculations a lot easier.
now let's say you have a rock that has 7 corners. at the moment in sfml you can't really do stuff like that, cause you'd have to write an extremely slow and complex algorithm that creates sprites for you which replace a natural texture. you'd have to draw a lot of sprites to fill in the little gaps that come because sprites are quads, or alternatively you'd have to draw a seperate texture resembling a 7-corner-rock and manually attack it to your ingame rock.
all of that stuff is really complicated. it would be easier to just have the possibilty to take a texture and "lay it upon" a certain shape.
-
Ok, I understand. I'll think about it.
-
SFML doesn't aim at being a clone of SDL & co ;)
Of course not, it aims to exceed them in all aspects :wink:
-
now let's say you have a rock that has 7 corners. at the moment in sfml you can't really do stuff like that
Couldn't you use OpenGL to draw a 7 sided polygon for you?
Something like:
// Structure for coordinates
struct Coordinates
{
float x,y;
};
// Declare rock vertices and texture coordinates
struct Coordinates RockVert[7]={ {0,10}, {10,5}, ... };
struct Coordinates RockTex[7]={ {0,0}, {1,0.5}, ... };
// Load sf::Image
...
// Bind the image and set it to repeat, not mandatory
Image.Bind();
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
// Inside main loop
{
...
// Draw polygon
Image.Bind();
glBegin(GL_POLYGON);
for (int i=0; i<7; i++)
{
glTexCoord2f(RockTex[i].x, RockTex[i].y);
glVertex2f(RockVert[i].x, RockVert[i].y);
}
glEnd();
...
}
If you want to set that texture repeating, it width and height has to be power of two (hardware requirement).
For example, texture size 128x128 or 32x64 will work with that repeat command.
-
yes of course i could do that and indeed i do that manually at the moment, but that's not really the point of asking for the feature.
i would not ask a manufacturer to build me a car because i don't know how to do it. i could build me a car, but it's complicated and time consuming. also building my own car without standardized equipment will make it hard for me to customize it later :) okay enough of the analogy here. you get what i mean.
-
looks good, it will take a couple of years to do all this right?
I hope to finish it in 2009 ;)
How's it going? Any idea about when it will be released?
I plan to remake much of the code of a project that is using SFML 1.5 (structure issues). I should start somewhere on the beginning of 2010 and I wish I can use the final release of SFML 2.
If release isn't planned for soon, I might give the SVN version a try (but final is final, and I also like to avoid eventual compilation problems with the SVN)
Anyway, you're doing an awesome work!
Oh, and merry Christmas to everyone :wink:
-
How's it going? Any idea about when it will be released?
It's not close enough to the final release for me to give an estimation. But I'll try to focus on the changes that break the public API, and keep the additions for future minor 2.x releases.
and I also like to avoid eventual compilation problems with the SVN
I never commit something that doesn't compile. If it happens, simply report it here and I fix it as soon as I can (it's often a matter of minutes).
-
This is a little offtopic, but have you ever considered moving development to a distributed version control system like Git or Mercurial? Maybe you could get more contributions from others if your project were hosted in something like Google Code, Bitbucket or Github (all 3 allow easy forking)?
-
I agree with this. Distributed systems like Git / Mercurial make branching and developing your own contribution really easy.
However I don't really want people to start creating branches, developing their own stuff (sometimes huge contributions), and submit it to me. SFML is not a community project, I like controlling and implementing stuff myself, and I like the current system where people write their requests or submit their patches here :)
-
Not to mention that I hated using Git in my last project...
-
Any porting notes for 2.x?
What displays in 1.6 does not display in 2.x (blank window), the only change of code I've done is replace View::SetRect() calls with View::SetViewport() calls since SetRect() is gone.
-
Any porting notes for 2.x?
Not yet, but of course there will be one for the first public release.
What displays in 1.6 does not display in 2.x (blank window), the only change of code I've done is replace View::SetRect() calls with View::SetViewport() calls since SetRect() is gone.
SetRect has been replaced with Reset. SetViewport sets the viewport, which is a completely different thing.
By the way, the API documentation of this class is up-to-date, you can look at it in the View.hpp header.
-
SetRect has been replaced with Reset. SetViewport sets the viewport, which is a completely different thing.
Thanks, that (semi) fixed it. What's the point of RenderTarget keeping a reference to the view when you need to call SetView() every time you Reset() it? (otherwise the changes have no effect for me)
Also, is the OpenGL state for the matrices pushed and popped for every single object that is drawn? I rendered some 2D objects in the same coordinate system as everything else via raw OpenGL - however, now that does not work, the OpenGL-drawn objects are always drawn with an identity matrix. What exactly changed here and why?
-
What's the point of RenderTarget keeping a reference to the view when you need to call SetView() every time you Reset() it? (otherwise the changes have no effect for me)
It doesn't keep a reference to the view anymore, it was changed recently to store the view by value so that you have to call SetView everytime the view changes.
Also, is the OpenGL state for the matrices pushed and popped for every single object that is drawn? I rendered some 2D objects in the same coordinate system as everything else via raw OpenGL - however, now that does not work, the OpenGL-drawn objects are always drawn with an identity matrix. What exactly changed here and why?
Your OpenGL objects are drawn with the matrix that you setup, SFML doesn't alter the OpenGL states.
Note that SFML 2 doesn't actually draw when you call Draw, it stores everything in a render queue and renders everything when you call Display. So if you want to draw something on top of SFML objects, you have to force rendering with Flush.
-
What's the point of RenderTarget keeping a reference to the view when you need to call SetView() every time you Reset() it? (otherwise the changes have no effect for me)
It doesn't keep a reference to the view anymore, it was changed recently to store the view by value so that you have to call SetView everytime the view changes.
////////////////////////////////////////////////////////////
/// Change the current active view
////////////////////////////////////////////////////////////
void RenderTarget::SetView(const View& view)
{
// Save it
myCurrentView = view;
// Send the view's viewport and projection matrix to the render queue
myRenderQueue.SetViewport(GetViewport(view));
myRenderQueue.SetProjection(view.GetMatrix());
}
This is from branches/sfml2, HEAD revision. Edit: Wait, myView is not a reference?
Your OpenGL objects are drawn with the matrix that you setup, SFML doesn't alter the OpenGL states.
Could I get a little breakdown of what exactly SFML does during the rendering process? Not too specific but I want to see how it handles all the transformations and renders from a higher level.
Note that SFML 2 doesn't actually draw when you call Draw, it stores everything in a render queue and renders everything when you call Display. So if you want to draw something on top of SFML objects, you have to force rendering with Flush.
This is why I want the higher level breakdown I mentioned, because from what I can see, the queue essentially filled and cleared every frame? That has no advantage over immediate mode, in fact, it should be slower.
-
This is from branches/sfml2, HEAD revision. Edit: Wait, myView is not a reference?
It wouldn't work if it was a reference. References can only be initialized at declaration, so this would still be a copy anyway. To keep a reference instead of copying the view, the myCurrentView member would have to be a pointer (that was the case before).
Could I get a little breakdown of what exactly SFML does during the rendering process? Not too specific but I want to see how it handles all the transformations and renders from a higher level.
Why? The purpose is that you don't have to care about what SFML does internally, it never impacts what you do with OpenGL outside. I could tell you about the internal details, but there's no point for you to know that, it should even change in the next days.
This is why I want the higher level breakdown I mentioned, because from what I can see, the queue essentially filled and cleared every frame? That has no advantage over immediate mode, in fact, it should be slower.
It allows batching, which is much faster. It also reduces the number of states changes from N (number of drawables) to 1 per frame.
-
It wouldn't work if it was a reference. References can only be initialized at declaration, so this would still be a copy anyway. To keep a reference instead of copying the view, the myCurrentView member would have to be a pointer (that was the case before).
Oh yeah I'm just being stupid. Comment is a bit misleading.
Why? The purpose is that you don't have to care about what SFML does internally, it never impacts what you do with OpenGL outside. I could tell you about the internal details, but there's no point for you to know that, it should even change in the next days.
Because I want to render with OpenGL under SFML's view transformation. For example, now there is no way for me to draw 1-pixel-wide lines, for, say, a grid. Now I have to manually push SFML's view transformation back onto the OpenGL state.
It allows batching, which is much faster.
I don't see any batching, every drawable seems to make a new batch every frame. Besides, you can't just batch any N drawables together because they might be overlapping, in which case you will get inconsistent behavior (one might show on top of the other even though you want to draw it first).
It would be much more efficient for every drawable to create its own VBO at time of creation or modification, and keep that VBO until it dies. If the user wants to batch things together, he can use a BatchDrawable which takes the VBOs of N Drawables and puts them all into a single VBO which then moves as a whole.
This is how high-performance 3D engines do it, and it is no different in 2D.
It also reduces the number of states changes from N (number of drawables) to 1 per frame.
I don't understand how reducing the amount of state changes has anything at all to do with the queue. You can have a list of random objects and still have a single state change, regardless of a queue.
-
Because I want to render with OpenGL under SFML's view transformation. For example, now there is no way for me to draw 1-pixel-wide lines, for, say, a grid. Now I have to manually push SFML's view transformation back onto the OpenGL state.
This is intended, SFML doesn't expose its internal states to the outside. Like I already said, you'll have to setup your own OpenGL view to match SFML's one. Any other solution would be a hack, and my break any time after an internal modification.
I don't see any batching, every drawable seems to make a new batch every frame
Look further, into the sf::RenderQueue class.
Besides, you can't just batch any N drawables together because they might be overlapping, in which case you will get inconsistent behavior (one might show on top of the other even though you want to draw it first).
The current implementation takes this issue in account properly. The order of drawing is not modified.
It would be much more efficient for every drawable to create its own VBO at time of creation or modification, and keep that VBO until it dies. If the user wants to batch things together, he can use a BatchDrawable which takes the VBOs of N Drawables and puts them all into a single VBO which then moves as a whole.
I can't assign a single VBO to every drawable. This would be inefficient, and make drawables not sa lightweight as they are currently.
But don't worry, the current code works well and I'm currently making it even better.
I don't understand how reducing the amount of state changes has anything at all to do with the queue. You can have a list of random objects and still have a single state change, regardless of a queue.
Maintaining states through the lifetime of an entire frame (with possibly external OpenGL calls between) requires more work than when everything is done in a single function.
-
This is intended, SFML doesn't expose its internal states to the outside. Like I already said, you'll have to setup your own OpenGL view to match SFML's one. Any other solution would be a hack, and my break any time after an internal modification.
Why not add View::applyProjectionGL() or something like that?
The current implementation takes this issue in account properly. The order of drawing is not modified.
How? Consider 2 objects that qualify for a single batch (same shader/texture/etc.) If they are overlapping, their triangles will be part of a single draw call - thus, regardless of the Draw() order, the actual order in which they will appear over each other would be up to the GPU. There is no clever trick or anything in the code (such as using the ZBuffer), so how is it handled?
I can't assign a single VBO to every drawable. This would be inefficient,
What are you talking about, that's how high performance 3D renderers work. Batching is left up to the user via a BatchDrawable or something that will combine VBOs of other Drawables. See above as to why auto-batching everything won't work.
and make drawables not sa lightweight as they are currently.
... They already hold their all vertices, what "lightweight" are we talking about?
Have you actually profiled it against what I'm suggesting? Or really against anything else? I'm willing to bet that the old immediate mode code is faster than the current code for a lot of scenes. Right now you're filling one giant VBO (more if objects vary in texture/shader/etc.) every frame.
-
Why not add View::applyProjectionGL() or something like that?
Because I don't want to add such things into SFML ;)
How? Consider 2 objects that qualify for a single batch (same shader/texture/etc.) If they are overlapping, their triangles will be part of a single draw call - thus, regardless of the Draw() order, the actual order in which they will appear over each other would be up to the GPU. There is no clever trick or anything in the code (such as using the ZBuffer), so how is it handled?
It is handled so that the current batch is stopped whenever a state changes. Even if the same states are set again later, the corresponding geometry will not belong to the same batch. This way, the drawing order still has the priority.
What are you talking about, that's how high performance 3D renderers work. Batching is left up to the user via a BatchDrawable or something that will combine VBOs of other Drawables. See above as to why auto-batching everything won't work.
High-performances 3D renderers work with models, not with 2D quads. It's very different, and it can't be handled the same way. Optimizing a generic, low-level 2D API is not straight-forward.
... They already hold their all vertices, what "lightweight" are we talking about?
No they don't.
Have you actually profiled it against what I'm suggesting? Or really against anything else?
Of course I did.
Right now you're filling one giant VBO (more if objects vary in texture/shader/etc.) every frame.
What's wrong with that?
Now I'll stop discussing, I don't like the way you answer to me. You're talking as if you wrote SFML but you obviously know nothing about it. You talk about critical internal details, but first have a look at the source code and come back when you know that the batching system works well with the drawing order, and that sprites don't "already hold their all vertices". Thank you.
-
It is handled so that the current batch is stopped whenever a state changes. Even if the same states are set again later, the corresponding geometry will not belong to the same batch. This way, the drawing order still has the priority.
Right, I noticed. However, consider two objects qualify for the same batch, as so:
// Check if the current batch differs from the new render states
if (!myCurrentBatch || !myCurrentBatch->Matches(myCurrentTexture, myCurrentShader, myCurrentBlendMode, myCurrentViewport))
Same shader, same texture, same blend mode, same viewport. Then what?
What are you talking about, that's how high performance 3D renderers work. Batching is left up to the user via a BatchDrawable or something that will combine VBOs of other Drawables. See above as to why auto-batching everything won't work.
High-performances 3D renderers work with models, not with 2D quads. It's very different, and it can't be handled the same way. Optimizing a generic, low-level 2D API is not straight-forward.
No they don't.
???
////////////////////////////////////////////////////////////
// Member data
////////////////////////////////////////////////////////////
std::vector<Point> myPoints; ///< Points composing the shape
Of course I did.
Right now you're filling one giant VBO (more if objects vary in texture/shader/etc.) every frame.
What's wrong with that?
I believe that filling up a giant VBO with all the objects every frame is not efficient. I'd love to see your profiling results that say otherwise.
-
Same shader, same texture, same blend mode, same viewport. Then what?
Then they will belong to the same batch.
???
////////////////////////////////////////////////////////////
// Member data
////////////////////////////////////////////////////////////
std::vector<Point> myPoints; ///< Points composing the shape
This is sf::Shape. Shapes are custom geometrical shapes, there's no higher-level way of storing their geometry. sf::Sprite and sf::Text however don't store their geometry, it is deduced from their parameters when they are rendered, which makes them lightweight.
I believe that filling up a giant VBO with all the objects every frame is not efficient.
Well, it's obviously a lot more efficient than immediate mode rendering. I didn't say that it was the best technique ever, it's just the best that I found that matches all the requirements of low-level 2D rendering.
I'd love to see your profiling results that say otherwise.
I didn't write a profiling log, sorry. But in worst case (every drawable uses a completely different set of states, thus no batching happens) it performed the same as the old implementation based on immediate mode, and in the best case (like a tilemap, a particle system, a GUI, etc. ie. many sprites using all the same states) I got an average speed increase of 5x.
You shouldn't bother with this discussion, automatic batching will probably be removed soon, I'm currently working on it.
-
Same shader, same texture, same blend mode, same viewport. Then what?
Then they will belong to the same batch.
(http://img192.imageshack.us/img192/2782/overlappingissue.png)
rt.Draw(blue);
rt.Draw(red);
How is the draw order guaranteed if both end up in the same batch, if the batch is rendered as a whole?
I believe that filling up a giant VBO with all the objects every frame is not efficient.
Well, it's obviously a lot more efficient than immediate mode rendering.
Actually it's not that obvious at all. Thus why I asked for profiling results. I'll look into it myself.
You shouldn't bother with this discussion, automatic batching will probably be removed soon, I'm currently working on it.
And replaced with what?
I think I might have a go implementing my own ideas and benching that when I find the time.
-
How is the draw order guaranteed if both end up in the same batch, if the batch is rendered as a whole?
OpenGL renders triangles in the same order as they are in the buffer. I couldn't find a spec that clearly says that, but I can't find a reason why the vertices would be rearranged by the driver.
Actually it's not that obvious at all. Thus why I asked for profiling results. I'll look into it myself.
It's obvious when you compare the number of driver calls required for both techniques. And driver calls are exactly what needs to be optimized in SFML.
And replaced with what?
With whatever I'll find that is good enough ;)
I'm still experimenting.
I think I might have a go implementing my own ideas and benching that when I find the time.
That's an excellent idea. This is the most important area in sfml-graphics, and I still haven't found the perfect solution so far, so your help is appreciated.
Please keep in mind that I want both performances and easiness (I mean in the public part of the API), so if you come up with an optimized solution that requires tons of extra calls on user side it will be as bad as a clean solution with poor performances.
-
For SFML 2, I would suggest to deactivate the smooth filter for sf::Image by default.
A lot of beginners (me inclusive, when I started) are confused about why a drawn sprite looks different than in the source file. Related problem threads seem to come up again and again (some examples: 1 (http://www.sfml-dev.org/forum/viewtopic.php?t=2239) 2 (http://www.sfml-dev.org/forum/viewtopic.php?t=1294) 3 (http://www.sfml-dev.org/forum/viewtopic.php?t=1716)). In my opinion, it would be more intuitive to render an image 1:1 by default, and let the smooth filter be an additional feature which can be activated when required.
How do you see this?
-
The rendering is now 1:1 in SFML 2 even with the smooth filter activated, as long as your coordinates match the window pixels.
Do you think it's enough to keep smooth images by default? :P
-
The rendering is now 1:1 in SFML 2 even with the smooth filter activated, as long as your coordinates match the window pixels.
Hm, what exactly has changed here since SFML 1? I'm not very well versed in SFML 2 smooth filters. ;)
And do you mean that if the sprite's coordinates are not integers, the sprite will be blurred? If so, how to avoid that? Rounding manually?
-
Hm, what exactly has changed here since SFML 1? I'm not very well versed in SFML 2 smooth filters
A lot of things. The internal rendering process is completely different, I've removed some tricks and added some others to get to this result ;)
And do you mean that if the sprite's coordinates are not integers, the sprite will be blurred?
Kind of. Pixels that don't exactly map to one pixel will not be rendered perfectly.
If so, how to avoid that? Rounding manually?
Yes. This may look very annoying, but I can't help much. In a previous version I was applying an automatic rounding, but some users found that this was preventing smooth transitions when a sprite was translated/rotated/scaled slowly. So basically we need these blurred pixels to make dynamic things smooth.
-
A lot of things. The internal rendering process is completely different, I've removed some tricks and added some others to get to this result ;)
Okay. Maybe you remember the artifacts bug. Since it is fixed, SFML seems to render quite nicely. But I haven't experimented too much... Probably I should do it, especially with newer revisions.
So, with a simple code like that, one could expect a 1:1 rendering?
sf::Image image;
image.LoadFromFile(...);
sf::Sprite sprite(image, sf::Vector2f(20, 30));
Yes. This may look very annoying, but I can't help much. In a previous version I was applying an automatic rounding, but some users found that this was preventing smooth transitions when a sprite was translated/rotated/scaled slowly. So basically we need these blurred pixels to make dynamic things smooth.
Just a spontaneous idea: Would another switch to either round automatically or manually bloat the interface?
-
Okay. Maybe you remember the artifacts bug. Since it is fixed, SFML seems to render quite nicely. But I haven't experimented too much... Probably I should do it, especially with newer revisions.
I tried to gather all the codes related to rendering artifacts which were posted to this forum, and they all succeeded with the current implementation.
But don't hesitate to experiment, I'm sure that you can find something. It's like this problem has no solution anyway ;)
So, with a simple code like that, one could expect a 1:1 rendering?
Yes.
-
I suggest adding some method to the Renderer to support vertex arrays too. That should further reduce driver calls.
The Renderer will soon become "fat". But you can't really have both speed and simplicity at the same time.
-
I suggest adding some method to the Renderer to support vertex arrays too. That should further reduce driver calls.
It doesn't help at all to render single quads.
It's a little too easy to say "use VA/VBO, it's faster", you have to look at the whole rendering process ;)
-
Hello. Today, on 12 April 2010, the Visual Studio 2010 has been released. Are there any plans to support it in SFML?
-
Absolutely.
-
I'm sorry if this is kind of off-topic, but since it didn't seem appropriate to start a thread just to ask a single question: I'm currently planning to code a little 2d engine and I'm planning to use SFML. Since it's going to take some time to get it ready: should I stick with the 1.x branch and somewhere in the future port the thing to 2.x or should I use 2.x directly?
I don't mind some breakage from time to time, but I don't want to spend most of my time fixing the thing instead of implementing my project :P
-
I'm sorry if this is kind of off-topic, but since it didn't seem appropriate to start a thread just to ask a single question: I'm currently planning to code a little 2d engine and I'm planning to use SFML. Since it's going to take some time to get it ready: should I stick with the 1.x branch and somewhere in the future port the thing to 2.x or should I use 2.x directly?
I don't mind some breakage from time to time, but I don't want to spend most of my time fixing the thing instead of implementing my project :P
I just use SFML2.0, and I recommend you to do the same. API is not changing on every commit, so I don't have to change nothing more than a few lines per 3 months or so. Also you can stick with an especific revision for a while!
-
Thanks panithadrum, that's all I needed to know :)
-
I agree with this. Distributed systems like Git / Mercurial make branching and developing your own contribution really easy.
However I don't really want people to start creating branches, developing their own stuff (sometimes huge contributions), and submit it to me. SFML is not a community project, I like controlling and implementing stuff myself, and I like the current system where people write their requests or submit their patches here :)
I'm quite late, but I'd answer that you're absolutely not forced to do more community management with git/hg than you do with svn, neither do you lose control on what happens (Torvalds himself likes to control everything).
Distributed vcs brings version control to contributors without having them hit the official repo. Imo it's a good thing − look at what happens on the python binding, bastien couldn't hit the svn repo, so he went for mercurial… all in all, version control is needed and contributors contribute.
Regarding huge contribs, just do as you would do with any other vcs stuff : refuse patches that are too big or not debated enough, write a HACKERS file to explain how you want contributions to happen, do the merging stuff yourself and control everything if you want to. A lot of developpers have the same feelings as you about their project, distributed vcs just works fine.
Not to mention that I hated using Git in my last project...
You should give it another try, it's not that terrible and it's really worth it.
-
Torvalds himself likes to control everything
I like how you address him like if he's a deity...
Anyway. I liked Git/GitHub but it's not something I would recommend for this project. SourceForge is much more suited for this kind. And as Laurent says he likes to stay in control. If someone came and made a complete new branch out of the Ruby bindings I would probably be a bit pissed. If someone wants to contribute or even so do a huge change on my project, it would be nice if they asked first. Also if they go so far to actually wanting to merge their branch with the original then I would say absolutely no. I would have no idea of what they've done to the project. They might have gone against some of my personal rules when it comes to programming and etc. etc. The issues are endless when it comes to programmers interacting :D
Using TortoiseSVN makes everything easy and suits my needs. Well at least on Windows. So I work with the Ruby bindings on a Virtual Machine Ubuntu installation but commit trough Windows XD
-
Torvalds himself likes to control everything
I like how you address him like if he's a deity...
Haha, he might not be a deity, but as far as I know of him, he's known to be 3 things :
- the creator and maintainer of linux, and the only person who can commit to the official linux repo
- the creator of git
- a lucky bastard
He has (and keeps) control on just everything goes in one of the biggest software project ever. And he created and uses git for it. Dare to come and say that git is not suited because you want to keep control on your project. :P
If someone came and made a complete new branch out of the Ruby bindings I would probably be a bit pissed. If someone wants to contribute or even so do a huge change on my project, it would be nice if they asked first..
svn does not prevent forks, neither wild huge contributions. svn does not force developers to get in touch with maintainers before doing what they want.
There's no more control with a centralized vcs than with a distributed one.
The only thing svn prevents is contributors to have their work be version controlled, they have to get commit access to the official repo or set-up their own vcs. The former is less control because you have to trust someone enough to give him commit access, both are tedious.
Also if they go so far to actually wanting to merge their branch with the original then I would say absolutely no. I would have no idea of what they've done to the project. They might have gone against some of my personal rules when it comes to programming and etc. etc. The issues are endless when it comes to programmers interacting :D.
I'd say no too, and it's arguably a good answer to that kind of contribution. But there's nothing here that advantages svn over git or hg. That's necessary and inevitable community management, traditionnaly done through some file aimed at developers which gives them enough keys to avoid making a faux-pas.
Using TortoiseSVN makes everything easy and suits my needs. Well at least on Windows. So I work with the Ruby bindings on a Virtual Machine Ubuntu installation but commit trough Windows XD
I understand that and I don't want to force anyone, but there was some prejudices on distributed vcs that couldn't stay uncorrected. ;)
-
And as Laurent says he likes to stay in control.
First, there's a huge difference in the terms of having "control". With SVN, that means to have an authz and passwd file and restrict write and read access to certain persons. Like Kaoron said, this can be a huge security hole (a guy's box gets hacked, sniffed, he gets angry, whatever). With Git you're building a so called "network of trust". Say you're the maintainer of initial creator of a project, and there're 2-3 guys that you know for years who also contribute to your project. You check their changes and if they fit, you throw them into your repository. Those 2-3 guys may also have 2-3 guys they trust, and so goes the hierarchy.
You see, with Git, you are much more in control than with Subversion.
If someone came and made a complete new branch out of the Ruby bindings I would probably be a bit pissed.
Then I'd recommend to stop programming for Open Source software. If you can't tolerate people "stealing" (some people think it's like that, where it isn't in reality) your written down code, then you shouldn't contribute to SFML in any way, because SFML itself is clearly released under a license that's *very* open, and also the maintainer (Laurent) seems to be completely open-minded to any things you're willing to do with SFML (he can't even stop you because of the license ;)) -- at least that's my impression that I respect very much.
- the creator and maintainer of linux, and the only person who can commit to the official linux repo
That's only partly true. Linus invented Linux, but he only maintains his own copy of Linux. The most people around the world clone his repository, because they like what he does, how he maintains his repository and stuff. But as soon as people think he's an idiot, they will stop pulling from his repository and just move over to another that looks better in their eyes. This is true Open Source in my opinion and Git brings this philosophy to the version control systems.
Using TortoiseSVN makes everything easy and suits my needs. Well at least on Windows. So I work with the Ruby bindings on a Virtual Machine Ubuntu installation but commit trough Windows XD
Okay, I highly doubt you're really talking about SCM systems here, are you? It doesn't care what client you use, the design matters. If it's TortoiseSVN, TortoiseGit, svn CLI, git CLI, gitg, gitk, svnweb, gitweb, ... who really cares? ;) Your sentence "[...]but commit through Windows" brought me to that conclusion.
Personally, I became a big fan of Git (or DSCM in general) and nowadays I think SVN is a bunch of crap. ;) It's so much easier, faster and reliable and I bet you won't regret using it. However in the end I don't care much, because git-svn does its job very well. The only drawback is sending in patches easily with Git, but since Laurent rarely accepts those, I'm fine with it. ;)
-
Well I'm so-so to Open Source. Thinks it's a good idea but got it's faults. But it's perfectly suited for something to work on your hobby.
And why I am contributing to the project is because I got tired of waiting for a Ruby binding to get done so I decided to make it myself.
And you missed my point, I don't mind if anyone "steal" from me, as long as they ask first. I will absolutely say yes but it's a courtesy that I... desire? Nah that's the wrong word. But I think you understand my point.
That's why in my original rbSFML post I first ask if it's okay that I pick it up instead. Though I think the original maintainer left the forum ages ago so I've sent an email too.
And I've used GitHub, doesn't have any bad experiences. Just that at my University they use SVN to work in the group projects so you get used to that. So naturally I've started to prefer that over Git. But before I went here I preferred Git over SVN. So it's just a matter of what you are used too. Just like how I "preferred" SDL over SFML before :oops: (Which was mostly because of the Rubygame bindings)
Anyway I think we are getting off-topic.
-
Thinks it's a good idea but got it's faults. But it's perfectly suited for something to work on your hobby.
What kind of faults? It's not only perfectly suited for hobby programmers, but also for the industry. There's enough software out there that prove that.
And you missed my point, I don't mind if anyone "steal" from me, as long as they ask first. I will absolutely say yes but it's a courtesy that I... desire? Nah that's the wrong word. But I think you understand my point.
I got the point, even in your previous posting. However I still think it's the wrong principle. When you release code under any Open Source-compatible license or whatever, then there's no need for anyone to "ask" for permission, even of kindness. If you want that, choose a proper license.
That's why in my original rbSFML post I first ask if it's okay that I pick it up instead. Though I think the original maintainer left the forum ages ago so I've sent an email too.
I think that's a point that I agree with. If there's code maintained by someone and you want to extend it, the best option is to contact that person. Not to ask if it's okay to modify or extend, but if it's possible to coordinate work. It'd be useless if two people worked on the same code. ;)
So naturally I've started to prefer that over Git. But before I went here I preferred Git over SVN.
Are you serious? ;) I've never heard of one person that liked Subversion more than Git when moving from Git to SVN. Of course it's a matter of taste (in some points...), I'm just wondering.
Anyway I think we are getting off-topic.
I guess that's okay, since the thread is not very active anymore. If it's a problem, Laurent may move our discussion, please. :)
-
Thinks it's a good idea but got it's faults. But it's perfectly suited for something to work on your hobby.
What kind of faults? It's not only perfectly suited for hobby programmers, but also for the industry. There's enough software out there that prove that
Suited for the industry... Not to a 100%... Got real world examples.
Legal issues are a pain. Massive Entertainment got sued for using a Open-Source implementation of Python. Most companies lawyers start to cold-sweat if you mention Open-Source. Several game studios has been and will be screwed by the Open Source resulting in fee's much more expensive than just buying something properly licensed.
Also several Open Source projects are not stable enough for the industry or even the public. OOo is a classical example. Something else would be Open-Source IDE. Most things you find out there does not cut it for at least the Game Development Industry. Also the support for it is not as good as something you pay for.
Open-Source projects are mostly maintained by hobbyists, nonprofessionals, and people who have studied the field but never actually practiced it. *aerhm* my previous teacher *aerhm*. I'm no exception to this rule. I like Open Source, I support the concept. But as the community is now, it can't compete with the non-open-source world.
To quote Niklas Hansson (former Lead Developer at Massive Entertainment): Open Source has it's rare diamonds, but most of it is garbage.
*EDIT*
Will have to note that with "Open-Source" I am of course implying on the community for the most. That's what actually makes up the cons and pros with open source software.
-
What are you talking about? I use almost exclusively open source software and most of it is veeery good and I'm very happy with it.
Have you used an IDE like Code::Blocks or kdevelop? In my opinion, Code::Blocks is just as good as Visual Studio (with the added benefit that it runs on Linux, Mac, whatever), and kdevelop is massively better (although harder to use, once you get used to it, it's waay better).
I do give that closed-source software is generally easier to use for the average user though, but to say "has its rare diamonds, but most of it is garbage" is a very misleading (if probably true) statement. Because there are sooooo many open source projects, and maybe 10% of them aren't garbage, which means there are many, many good open source projects. Sure, they aren't always so easy to find.
Oh, and I agree that open office sucks :) Fortunately I don't use office software, only LaTeX, and kile is very good too.
-
In my opinion, Code::Blocks is just as good as Visual Studio
Apparently you haven't worked that much with Visual Studio. There's nothing on the market that beats it's debugger interface. I would say that anything working with GCC is more appealing, but I have to give it to Microsoft, they really succeeded there. Just like they did with their Office package. If I could, I would fuse Visual Studio with GCC :D
Because there are sooooo many open source projects, and maybe 10% of them aren't garbage, which means there are many, many good open source projects. Sure, they aren't always so easy to find.
He did mean what you consider the "good" ones.
And the perspective is from Game studios, not myself or how it really is. More like a basic simplification about open source in game studios eyes.
And even if this thread isn't used for anything else. This isn't the place to talk about it. Let's not continue being off-topic. SFML2 begins here again plz.
-
- Generalization of data access for loading resources (from files, from memory, ...) with a DataStream framework
Excellent. This is something I miss from SDL.
It may be wise to include FIFOs and sockets as well, if they weren't already planned. Maybe over the HTTP and FTP protocols as well.
- Rewrite of OpenGL contexts handling to make it more elegant, more robust and easier to use
While you're at it, it would be advisable to expose all GL functions through GL contexts rather than direct GL calls. Sounds weird, but it will allow for supporting non-GL backends (perhaps software rendering, DirectX, GDI, XRender, etc) in the future.
- Unlink sf::Input from sf::Window, make it use direct OS calls rather than relying on windows events
Would be useful for some applications, but not terribly many.
-
I would assume the reliance on OpenGL is too strong in some places to be able to use a different backend transparently while retaining all the available features. Shaders are a good example.
Not to say that it wouldn't be nice to have, but hard to see it being worth the effort to allow for a variety of backends when they don't play so nicely with one another.
-
While you're at it, it would be advisable to expose all GL functions through GL contexts rather than direct GL calls. Sounds weird, but it will allow for supporting non-GL backends (perhaps software rendering, DirectX, GDI, XRender, etc) in the future.
I don't care about other back-ends, OpenGL is widely implemented and every new hardware supports an OpenGL variant by default. And SFML is an OpenGL library by definition, its interface is made to mix nicely with native OpenGL calls.
Would be useful for some applications, but not terribly many.
This is not a feature, it's more a bug fix ;)
The current system is not reliable, for example it can't keep track of what's happening when the window looses the focus.
-
I think specializing in OpenGL is the right thing to do. Look at Id Tech 5 and the planned Id Tech 6 game engines are all based on OpenGL and are freaking amazing!
Trying to support some other back end would just consume unnecessary time and effort. Though the idea that we have a OpenGL object oriented interface would be really really nice. Though I would understand if it would be too much to implement.
-
Though the idea that we have a OpenGL object oriented interface would be really really nice. Though I would understand if it would be too much to implement.
Honestly, if I was starting SFML now I would do that. Too bad I didn't have this idea before.
By the way, Qt have this kind of object-oriented OpenGL layer now.
-
Honestly, if I was starting SFML now I would do that. Too bad I didn't have this idea before.
Well it would be pretty cool. If I had more time after school I would love the idea of helping out with creating a public class separated from the internal GLContext class (encapsulating it or something and providing an interface and then providing functions for the OpenGL calls). Though I must say I don't got enough knowledge/experience on OpenGL to create something like that or the time to learn it currently, Damn school forcing me trough DirectX since that's what the industry demands -.-'
-
I don't care about other back-ends, OpenGL is widely implemented and every new hardware supports an OpenGL variant by default. And SFML is an OpenGL library by definition, its interface is made to mix nicely with native OpenGL calls.
As a side note, crappy drivers make 2D programs terribly slow, on GNU/Linux at least.
My laptop has Intel's driver, but it can just display like 100 sprites at 60 FPS. The LinCity game runs fine with the SDL backend, but the OpenGL one is terrible. Generally speaking, I can't imagine that games like Wesnoth would run fine on it if they used OpenGL since I already have trouble displaying 200 sprites with SFML.
My desktop computer has the same problem, but it uses a WIP open source driver, so it's somewhat normal.
So I'm all for OpenGL, but it's sad to see SDL has much better performance on the computers I use. :(
-
Using software rendering with SDL or which backend?
Honestly, if I was starting SFML now I would do that. Too bad I didn't have this idea before.
Why aren't you implementing it then? SFML 2 could be something with a good new direction. If it's the bunch of work you're afraid of, maybe try to open your mind for some guys that can help you out. Setup a detailed roadmap and let the magic happen. It would definitely better to realize the stuff you'd love to instead of skipping it because of time reasons or whatever.
sf::Input and sf::Window stuff
Great. The best thing is that sf::Input doesn't require an sf::Window reference anymore, which reduces complexity. Cool. :)
-
Why aren't you implementing it then? SFML 2 could be something with a good new direction. If it's the bunch of work you're afraid of, maybe try to open your mind for some guys that can help you out. Setup a detailed roadmap and let the magic happen. It would definitely better to realize the stuff you'd love to instead of skipping it because of time reasons or whatever.
Maybe I'll do that for SFML 3. Or as an add-on module for SFML 2.
Great. The best thing is that sf::Input doesn't require an sf::Window reference anymore, which reduces complexity. Cool.
1. It's not done nor even decided in details
2. I don't know if it's a good solution, for example when you hit a key you want the focus window to receive it, not the others
-
Is SFML 2 suitable for SFML beginners? I heard that it is already complete and free of bugs (why isn't it released then?). Thanks! :)
-
It may be free of bugs, but it's far away from being feature-complete. And SFML2 will be similar easy to use like the 1.x versions, I guess.
-
it's far away from being feature-complete
Don't scare people :lol:
It's almost complete, in fact. A lot of things that I planned for SFML 2.0 can be added to SFML 2.x later, they won't break the existing API of SFML 2.
-
Let's hope so, by goodness! ;)
-
Laurent, would it be possible to add a method to sf::RenderWindow that returns a RenderImage (or just Image) containing everything that's "drawn on the window" right now?
Would make setting the texture inside a shader to the current screen's contents very very easy and much more comfortable.
-
Why not simply draw everything into a render image (and if needed draw the image to the window) ?
-
Laurent, would it be possible to add a method to sf::RenderWindow that returns a RenderImage (or just Image) containing everything that's "drawn on the window" right now?
There is no need to do that, as sf::Image::CopyScreen() (http://www.sfml-dev.org/documentation/2.0/classsf_1_1Image.htm#35d840e67a4303e92e1449c94833faf6) already provides that feature.
Sometimes, it's worth to take a look at the documentation. ;)
-
Though the idea that we have a OpenGL object oriented interface would be really really nice. Though I would understand if it would be too much to implement.
Honestly, if I was starting SFML now I would do that. Too bad I didn't have this idea before.
As long as it's optional to use it.
Having to refactor rather large existing codebases to work with "OO"-wrappers like Tao/OpenTK to get them to work under C# was a major pain in the baguette. I would rather not have to do again in order to get them to work with future versions of SFML. (which btw is looking very neat) :)
-
Hi there,
i just stumbled over sfml by accident and was intrigued by it's well thought out design and ease of use. I'm usually a Java guy (ya, start running and screaming :)) but i like getting back to C++ every now and then. SFML is a more than welcome alternative to the mess that is SDL. Great job so far.
I'm actually maintaining a very similar library for Java and was wondering how you pulled of sprite/glyph rendering in SFML. I first had a look at Drawable, Sprite and Renderer and was surprised to find that you actually use immediate mode rendering and only remember the last bound texture to reduce binds.
Now, i figured you have a reason for this and searched the forums. I found this thread (http://www.sfml-dev.org/forum/viewtopic.php?t=1682&postdays=0&postorder=asc&highlight=batching&start=30), you seem to have tried batching already but reverted to immediate mode rendering. Shortly afterwards i found this thread (http://www.sfml-dev.org/forum/viewtopic.php?t=2063&highlight=batching) which gives a little bit more details on why you ditched batching all together.
With our Java based project we have created something very similar to SFML (Win/Lin/Mac/Android). Our Sprite classes look nearly identical from an API point of view, the internals are of course a little different. The interesting part is this: we use batching heavily as it is mandatory on mobile devices like Android. And what's good for a mobile GPU is good for a desktop GPU as well. We support OpenGL ES 1.x as well as 2.0, which is more or less the same as desktop GL minus display lists and immediate mode. So we are forced to go the batching route.
I wanted to compare the performance of both SFML and our lib and create a little microbenchmark. Here's the SFML version:
#include <SFML/Audio.hpp>
#include <SFML/Graphics.hpp>
#define SPRITES 50000
#define randf() ((float)rand() / RAND_MAX)
int main()
{
// Create the main window
sf::RenderWindow window(sf::VideoMode(800, 600), "bench");
// Load a sprite to display
sf::Image image;
if (!image.LoadFromFile("badlogicsmall.jpg"))
return EXIT_FAILURE;
sf::Image image2;
if (!image2.LoadFromFile("bob.png"))
return EXIT_FAILURE;
sf::Sprite* sprites[SPRITES];
for(int i = 0; i < SPRITES; i++) {
sf::Sprite* sprite;
if(i < SPRITES / 2) {
sprite = new sf::Sprite(image);
sprite->SetBlendMode(sf::Blend::None);
sprite->SetPosition(randf() * 800, randf() * 600);
sprite->SetOrigin(16, 16);
} else {
sprite = new sf::Sprite(image2);
sprite->SetBlendMode(sf::Blend::Alpha);
sprite->SetPosition(randf() * 800, randf() * 600);
sprite->SetOrigin(16, 16);
}
sprites[i] = sprite;
}
sf::Clock clock;
float timePassed = 0;
unsigned frames = 0;
while (window.IsOpened())
{
sf::Event event;
while (window.GetEvent(event)) {
if (event.Type == sf::Event::Closed)
window.Close();
}
float elapsed = clock.GetElapsedTime();
float scale = timePassed>0.5?1-timePassed / 2:0.5f + timePassed / 2;
clock.Reset();
window.Clear();
for(int i = 0; i < SPRITES; i++) {
sprites[i]->SetRotation(sprites[i]->GetRotation() + elapsed * 45);
sprites[i]->SetScale(scale, scale);
window.Draw(*sprites[i]);
}
window.Display();
timePassed += elapsed;
frames++;
if(timePassed > 1.0f) {
printf("fps: %d\n", frames);
timePassed = 0;
frames = 0;
}
}
return EXIT_SUCCESS;
}
Please forgive my poor C++, it's been years since i actively worked (http://www.apiservers.com/yagl/) with it.
Our APIs are so similar that the Java version based on our lib looks pretty much the same (we don't have a classic main loop due to Android being a little bitch).
package com.badlogic.gdx.tests;
import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.graphics.GL10;
import com.badlogic.gdx.graphics.Texture;
import com.badlogic.gdx.graphics.Texture.TextureFilter;
import com.badlogic.gdx.graphics.Texture.TextureWrap;
import com.badlogic.gdx.graphics.g2d.Sprite;
import com.badlogic.gdx.graphics.g2d.SpriteBatch;
import com.badlogic.gdx.tests.utils.GdxTest;
public class SpritePerformanteTest2 extends GdxTest {
static final int SPRITES = 50000;
Texture image;
Texture image2;
Sprite[] sprites;
SpriteBatch batch;
float timePassed = 0;
int frames = 0;
@Override public void create() {
image = Gdx.graphics.newTexture(Gdx.files.internal("data/badlogicsmall.jpg"),
TextureFilter.Linear, TextureFilter.Linear,
TextureWrap.ClampToEdge, TextureWrap.ClampToEdge);
image2 = Gdx.graphics.newTexture(Gdx.files.internal("data/bobargb8888-32x32.png"),
TextureFilter.Linear, TextureFilter.Linear,
TextureWrap.ClampToEdge, TextureWrap.ClampToEdge);
sprites = new Sprite[SPRITES];
for(int i = 0; i < SPRITES; i++) {
Sprite sprite = new Sprite(i < SPRITES / 2?image:image2);
sprite.setPosition((float)Math.random() * 800, (float)Math.random() * 600);
sprites[i] = sprite;
}
batch = new SpriteBatch();
}
@Override public void render() {
Gdx.gl.glClear(GL10.GL_COLOR_BUFFER_BIT);
float elapsed = Gdx.graphics.getDeltaTime();
float scale = timePassed>0.5?1-timePassed / 2:0.5f + timePassed / 2;
batch.begin();
batch.disableBlending();
for(int i = 0; i < SPRITES / 2; i++) {
sprites[i].setRotation(sprites[i].getRotation() + elapsed * 45);
sprites[i].setScale(scale, scale);
sprites[i].draw(batch);
}
batch.end();
batch.begin();
batch.enableBlending();
for(int i = SPRITES / 2; i < SPRITES; i++) {
sprites[i].setRotation(sprites[i].getRotation() + elapsed * 45);
sprites[i].setScale(scale, scale);
sprites[i].draw(batch);
}
batch.end();
timePassed += elapsed;
frames++;
if(timePassed > 1.0f) {
Gdx.app.log("SpritePerformanceTest2", "fps: " + frames);
timePassed = 0;
frames = 0;
}
}
@Override public boolean needsGL20 () {
return false;
}
}
As you can see both tests load two imgages (32x32 RGB and RGBA images to be exact), create 25k sprites using the first image, 25k sprites using the second image and draw them brute force. To spice things up a little i also scale and rotate each sprite in each iteration. Half of the sprites are blended, the other half isn't.
Now, as i understand the latest SFML 2 code which i used for this your stuff is all shader based. Ours can work with shaders as well, and also interoperate with normal GL operations much like SFML. For the test above i used the GLES 1.x path, meaning no shaders are involved but only fixed function stuff. Both tests output the number of frames per second, each second.
Here are the results on an Asus EEE 1215n, with an Nvidia ION2 card, the latest drivers and vsynch forced off. SFML was compiled in release mode, as was the test project itself of course, with /O2 in Visual Studio 2008 Express. On the Java side i use the latest client JVM from Oracle.
SFML:
fps: 7
fps: 6
fps: 6
fps: 6
fps: 6
fps: 6
Libgdx:
SpritePerformanceTest2: fps: 24
SpritePerformanceTest2: fps: 24
SpritePerformanceTest2: fps: 24
SpritePerformanceTest2: fps: 24
SpritePerformanceTest2: fps: 24
SpritePerformanceTest2: fps: 24
SpritePerformanceTest2: fps: 24
SpritePerformanceTest2: fps: 24
I think this illustrates the case for batching. If you look at the java code you'll see that the difference is the SpriteBatch.begin() and SpriteBatch.end() calls. With the current SFML API there's no need for such explicit batching. However, we decided against the SFML model for two reasons: you are likely to not mix 2D and 3D rendering like draw sprite, draw 3D model, draw sprite and so on. It's also a lot better in terms of state handling since you are forced to cleanly separate your 2D and 3D rendering. I can see though that the SFML model has its merits, especially for newcomers as it eases the code a little bit.
I zipped up the Visual Studio 2008 project which is self contained. You can download it from here (http://www.file-pasta.com/s/1125/bench.zip). The source code for the Java test can be found at http://code.google.com/p/libgdx/. A runnable cross-platform jar (Windows/Linux/Mac, 32 and 64-bit) can be downloaded from here (http://www.file-pasta.com/s/1126/bench.jar). To see the fps output you have to start the jar from the command line like this
java -jar bench.jar
You can also double click the jar, at least on windows and the thing will start automatically. Without a console though, but you should see the visual difference in performance.
In any case, i think batching should be reconsidered for SFML 2. Laurent, you could check out our SpriteBatch (http://code.google.com/p/libgdx/source/browse/trunk/gdx/src/com/badlogic/gdx/graphics/g2d/SpriteBatch.java), Sprite (http://code.google.com/p/libgdx/source/browse/trunk/gdx/src/com/badlogic/gdx/graphics/g2d/Sprite.java) and SpriteCache (http://code.google.com/p/libgdx/source/browse/trunk/gdx/src/com/badlogic/gdx/graphics/g2d/SpriteCache.java) classes if you are interested in our approach. Given that our crap is Java based it should actually perform even better in C++. Because we all know C++ is 10 times faster than Java, right? :)
Goody, sorry for the wall of text. Keep up your extremely good work. I'm looking forward to the full 2.0 release. As it stands it's already mighty awesome, i'll give it a try in one of my next projects maybe. I really want to get back to C++ again a little, i only write some stuff for our lib in C++ for Android cause their VM sucks.
-
Hey, thank you very much :)
In fact I'm currently (trying to) rewriting the entire drawable API in SFML, and then I'll rework on performances optimizations and batching.
Anyway, I'll check your code and see if I can get some interesting ideas from it.
-
Cool. Don't get bitten by the dirty Java :)
-
I think implicit batching (i.e. having a renderer which sorts the renderables before rendering) would be a better choice for sfml.