whether C++11 should be non-optional,then what advantages could there be in designing the library around the latest C++ standard?
Firstly, how exactly does optional C++11 work? You could insert new features that define code better or swap-out with older style code, like override, or nullptr etc.?Not sure, moste likely with a lot of ugly #ifdef, I just add the non-optional thing to make it clear and since currently there's optional C++11 support (https://github.com/SFML/SFML/issues/129) targeted for 2.x - which ofc could change.
Also, C++14 is due soon enough, and VS, GCC and clang will also support it soon enough (if Herb Sutter's projections for VS weren't too optimistic). Would it be worth using C++14 in place of C++11?It's really to early to tell for sure, C++14 is still just a draft and how fast compiler vendors will implement the proposal is also an open question.
You can take a look at the Kinetic framework (http://kineticjs.com) which is written in JavaScript.It would be nice, if you could elaborate on things a bit more, especially given that JavaScript and C++ aren't easily comparable in certain regions. It would be especially interesting to hear your thoughts on the event things that you mentioned.
It has really nice features like transitions, tweening, group/layer -rendering and neat on-events like onClick, onHover and so on... This clearly fits within the multimedia limit.
If possible, render and audio context management. In other words, separate the contexts out from the Window and wherever it is stored for the audio into sf::RenderContext and sf::AudioContext and provide an API for using custom contexts. This would make it way easier to integrate SFML in certain situations and would mean better ownership-based design with less magic stuff going on. That magic stuff is sure arguably easier and more simple but I find that in the long run, it is a drawback.I totally agree with that.
Would be neat to have web-compile capabilities for SFML as well!This is less likely to happen. But if someone provides an implementation, why not.
Awesome! :DQuoteContext stuff.I totally agree with that.
Ah, any particular reason why it is not likely to happen? Running things in the browser is all the rage these days.QuoteWould be neat to have web-compile capabilities for SFML as well!This is less likely to happen. But if someone provides an implementation, why not.
Ah, any particular reason why it is not likely to happen? Running things in the browser is all the rage these days.I think because nobody on the team has a single clue of how that's going to work. Perhaps we can elaborate what changes are exactly needed to make this happen. With help from someone who has a good knowledge of emscripten we can probably work something out.
Perhaps we can elaborate what changes are exactly needed to make this happen.
Perhaps we can elaborate what changes are exactly needed to make this happen.Of the top of my head:
The Windowing API would need to use GLEW to create the window and handle events without any OS specific code (or at least the OS specific stuff is #ifdef'd away).
The Graphics API needs to support the WebGL subset of OpenGL (which is basically OpenGL ES 2).
Audio API.
Networking would need porting to WebSockets/WebRTC. Probably easier to drop support of it for Emscripten.
GLEW or any manual extension loading is not required for emscripten. All supported GL calls work out of the box. The graphics API needs to be ported to work with OpenGL ES 2.
GLEW or any manual extension loading is not required for emscripten. All supported GL calls work out of the box. The graphics API needs to be ported to work with OpenGL ES 2.
Damnit Brain-fart, GLFW. not GLEW xD argh, those aren't confusing similar names at all
As I understood it you have to use EGL (https://github.com/kripken/emscripten/wiki/EGL-Support-in-Emscripten) (+X11), GLFW, or SDL to create a window for OpenGL. I edited to list them, but doesn't SFML already use GLFW in parts?
Also the Android port I'm guessing uses EGL, so there's already that code available.
I'm a bit confused. What role is SDL playing in this all? Because I don't think it's really an option to have SDL or GLFW as dependency of SFML... ;D
* a technique to insert an event (example: my_triple_mouse_click) to the event loopWhy would you need that? You can easily have a custom event queue on top of SFML's...
* timer eventsCan you elaborate?
I'm a bit confused. What role is SDL playing in this all? Because I don't think it's really an option to have SDL or GLFW as dependency of SFML... ;D
* removing sf::clock and sf::thread and friends in favour of the C++-versions of it.sf::thread, maybe.
* a technique to insert an event (example: my_triple_mouse_click) to the event loopThese could all be done by implementing your own event system on top of SFML's event facilities, which would be more flexible and far superior for your game logic needs. I think sf::Event should be kept to what it is now, for window and input related events.
* timer events
* a technique to insert an event (example: my_triple_mouse_click) to the event loopWhy would you need that? You can easily have a custom event queue on top of SFML's...
* timer eventsCan you elaborate?
There is a little overhead in adding an own event queue. Just call window.pushEvent(myEvent) would be nice.
Lets say, you would like to close a window after some seconds, check for network after some time, save a game state on disk every hour and so on.
Doesn't even the SFML tutorial say that you should use C++ 11 threads where possible? If SFML 3.0 makes C++11 fully required, then I could see why it's being removed-* removing sf::clock and sf::thread and friends in favour of the C++-versions of it.sf::thread, maybe.
Removing sf::clock is definitely a no no for me. It's a useful utility class and provide higher precision than VC12's std::chrono::high_resolution_clock due to the library not using native high precision API.
Lets say, you would like to close a window after some seconds, check for network after some time, save a game state on disk every hour and so on.
There are other C++ libraries that provide this functionality, and implementing it yourself is not difficult but details are quite dependent on your own current system. Whilst the OS does provide some timer behaviour SFML could hook this into, it seems like a 'Game Framework' feature, not an SFML feature, to me.
Doesn't even the SFML tutorial say that you should use C++ 11 threads where possible? If SFML 3.0 makes C++11 fully required, then I could see why it's being removed-You are right. Personally I use std::thread and have never used sf::Thread.
Things I really want:
- Enhanced math library (more vector/matrix stuff, up to 4D, and including things like quaternions)
That's why you should add simple demos and free stuff for first-time-use. Some free music, textures etc. Also default font would be nice improvement. I never understood why original author didn't include it.There are many code examples to show the various parts, so what do you mean? SFML provided a default font in earlier versions, but it was removed (if you're interested in the reasons, search the forum, there was a discussion about it).
Worst you can do is to expect people to install hundreds of additional libraries to make their games and apps work, just because "they can do it". We are not talking about SFML 2.x, but SFML 3 and it's long-time project, so there is no reason to reject any idea just because it's "time wasting" and "it is already done in XYZ library".
IMO there are absolutely no reasons to add advanced maths stuff since there are other libraries doing that and being focussed on it. GLM for example is headers only and has heaps of functionality related to 3D graphics maths. Adding a maths module to SFML would only mean more maintenance and reinventing the wheel.I'm not asking for the whole kitchen sink (I said "enhanced," not "advanced"). The thing is SFML already provides vectors and matrices. And these aren't things that can be stripped out of SFML, as coordinates and transforms need to be specified for SFML to do its work. But these things SFML provides have no support for basic linear operations (dot/cross products, projections, etc.). It would be nice if common operations and data types (i.e. quaternions, particularly if 3D support is added) were supported.
I'm not asking for the whole kitchen sink (I said "enhanced," not "advanced"). The thing is SFML already provides vectors and matrices. And these aren't things that can be stripped out of SFML, as coordinates and transforms need to be specified for SFML to do its work. But these things SFML provides have no support for basic linear operations (dot/cross products, projections, etc.). It would be nice if common operations and data types (i.e. quaternions, particularly if 3D support is added) were supported.
You are talking different backends, this isn't as simple as you think and would require a complete redesign of SFML internally.
multimedia library with DirectXIn fact I don't see the point of using DirectX (especially with an obsolete version like directX9, I'm not very familiar with directX, but this version is almost 6 year old, no ?), and in my mind OpenGL is faster and cross platform (perhaps I'm wrong..).
You are talking different backends, this isn't as simple as you think and would require a complete redesign of SFML internally.
Support texture packer.
It's nice seeing all this feedback, rest assure we'll be discussing most of the points and some have already been kind of agreed on before this thread started. ;)You can sort them, pass same values easily to large group of sprites (for example, when user do not want to use views becouse it is corrupting drawing of his GUI - yep that is my case - you can do it like XNA, and so passing camera with transformation matrix to sprite batch), pass blending to large group of sprites easily and so. Imo, sprite batch is better for bigger projects, and for small ones, it is better to use normal rendering (becouse it is pointless to create new spritebatch f.e. for 2 sprites). Look for example at my implementation of SpriteBatch to my engine. It is working exactly like drawing sprites to RenderWindow, you can pass there IDrawable (for example Sprite) and spritebatch will enqueue it. It is highly modified version of krzat´s spritebatch https://bitbucket.org/krzat/sfml.utils/src/ce2ec1656e13424141b23583b495197b60bd2fcf/SpriteBatch.cs?at=master
As for sprite batching, you suggest it as addition to the normal sprite rendering, but is there any advantage not to batch all sprites or what's the difference between batching and non-batching?
(for example, when user do not want to use views becouse it is corrupting drawing of his GUI - yep that is my case - you can do it like XNA, and so passing camera with transformation matrix to sprite batch)Sounds like you didn't understand how to use views properly. You can use multiple views to render things independently without "corrupting drawing", unless you meant something else.
Isn't that mixing two different concepts? What has been discussed here before was sprite batching as in making something like a vertex array more automated/accessible. While what you describe sounds more like a node system. Is that the same?(for example, when user do not want to use views becouse it is corrupting drawing of his GUI - yep that is my case - you can do it like XNA, and so passing camera with transformation matrix to sprite batch)Sounds like you didn't understand how to use views properly. You can use multiple views to render things independently without "corrupting drawing", unless you meant something else.
RenderWindow.Draw(Sprite);
For multiple sprites:SpriteBatch.Begin();
SpriteBatch.Draw(Sprite1);
SpriteBatch.Draw(Sprite2);
SpriteBatch.Draw(Sprite3);
SpriteBatch.Draw(Sprite4);
SpriteBatch.Draw(Sprite5);
SpriteBatch.End();
RenderWindow.Draw(SpriteBatch);
SpriteBatch.Begin(Sort.Inverse, TransformMatrix, Blending.Add)
RenderWindow.SetView()
For scaling, zooming, moving entire screen. And I do not want to create new render textures just for using 2 different views. Correct me if I do not got views functionality correctly.
As for sprite batching, you suggest it as addition to the normal sprite rendering, but is there any advantage not to batch all sprites or dwhat's the difference between batching and non-batching?
Code: [Select]SpriteBatch.Begin();
SpriteBatch.Draw(Sprite1);
SpriteBatch.Draw(Sprite2);
SpriteBatch.Draw(Sprite3);
SpriteBatch.Draw(Sprite4);
SpriteBatch.Draw(Sprite5);
SpriteBatch.End();
RenderWindow.Draw(SpriteBatch);
A sprite batch is just a way to reduce the number of draw call for things that use the same texture.
This code for example:Code: [Select]SpriteBatch.Begin();
SpriteBatch.Draw(Sprite1);
SpriteBatch.Draw(Sprite2);
SpriteBatch.Draw(Sprite3);
SpriteBatch.Draw(Sprite4);
SpriteBatch.Draw(Sprite5);
SpriteBatch.End();
RenderWindow.Draw(SpriteBatch);
If all of those sprites used the same texture, it would essentially create a vertex array and then draw everything with one draw call internally.
////////////////////////////////////////////////////////////
/// <summary>
/// Draws all queued sprites for this vertex batch. Call
/// this only after calling End().
/// </summary>
////////////////////////////////////////////////////////////
public void Draw(SFML.Graphics.RenderTarget target, SFML.Graphics.RenderStates states)
{
uint index = 0;
foreach (var item in _textures)
{
states.Texture = item.Texture;
target.Draw(_vertices, index, item.Count, SFML.Graphics.PrimitiveType.Quads, states);
index += item.Count;
}
}
A sprite batch is just a way to reduce the number of draw call for things that use the same texture.
This code for example:Code: [Select]SpriteBatch.Begin();
SpriteBatch.Draw(Sprite1);
SpriteBatch.Draw(Sprite2);
SpriteBatch.Draw(Sprite3);
SpriteBatch.Draw(Sprite4);
SpriteBatch.Draw(Sprite5);
SpriteBatch.End();
RenderWindow.Draw(SpriteBatch);
If all of those sprites used the same texture, it would essentially create a vertex array and then draw everything with one draw call internally.
For such thing, you can simply create vertex array. If I would wanna use spritebatches only for drawing sprites with same texture, I wouldn´t use them. Yes, spritebatch should reduce draw calls, but imo efficient spritebatch reduces it to number of different textures what are added to it.
- Scripted quest system
- Scripted quest system
I think this is way too specific for a library. I can think of many games (let alone applications) that would never, ever need this. A lot of game engines (which SFML is not) don't even go to these sorts of lengths.
- Change the developement direction to a game programming framework not being only a media layer.
- Integrate thor library
- Create an entity system
- Create a TiledMap class
- Messaging systems
- Lua scripting class that exposes entities, camera and the map
- Scripted quest system
One way to do it it's create another layer.
Yep, you oversimplified it :DA sprite batch is just a way to reduce the number of draw call for things that use the same texture.
This code for example:Code: [Select]SpriteBatch.Begin();
SpriteBatch.Draw(Sprite1);
SpriteBatch.Draw(Sprite2);
SpriteBatch.Draw(Sprite3);
SpriteBatch.Draw(Sprite4);
SpriteBatch.Draw(Sprite5);
SpriteBatch.End();
RenderWindow.Draw(SpriteBatch);
If all of those sprites used the same texture, it would essentially create a vertex array and then draw everything with one draw call internally.
For such thing, you can simply create vertex array. If I would wanna use spritebatches only for drawing sprites with same texture, I wouldn´t use them. Yes, spritebatch should reduce draw calls, but imo efficient spritebatch reduces it to number of different textures what are added to it.
Perhaps I oversimplified it by mentioning only one texture, but yeah, sprite batches should work regardless of the thing being drawn has the same texture as anything else in the batch. That was just supposed to be a basic example to explain the underlying concept to eXpl0it3r. ;)
There's no need to quote 3 other quotes...What is really bothering me? Different rectangle and vector types, that is really annoying...
Anyways, my question was more going into the direction of: Is there any disadvantage in not having sprite batching for all sprites?
Also yes SFML will not turn into a game engine, but we still like to hear what people want, but again as I said in the beginning, we'd like to hear less about specific features and more about what changes SFML should get to make it a better library. What is currently bothering you most with SFML and would like to see changed?
Different rectangle and vector types, that is really annoying...Would you mind explaining what you mean?
It is uncomfortable for me (and I think I am not alone) to have 3 different vector types (Vector2u, Vector2f, Vector2i) and 2 different rectangle types (FloatRect, IntRect). Imo, Vector2f and IntRect are enought, before I started working on my framework, I was using only that 2 and used casts to convert from rest of rectangle and vector types.QuoteDifferent rectangle and vector types, that is really annoying...Would you mind explaining what you mean?
Sorry giving this idea again, but, I really would like SFML Team to implement DirectX as beckend.You write your own lib using DirectX, don't publish the code, come up with a very synthetic benchmark and claim that DirectX is 10x faster than OpenGL?
I did some testing with my lib(Simple Tool For Games[STFG] - its not published yet...) and SFML.
DirectX is 10x times faster.
I tested this with drawing some number of rectangles.
I don't see why not implementing DirectX as other beckend.Sonkun is already working on an experimental DirectX implementation. Whether this is necessary is still up for discussion. The one advantage I can think of is enabling future support for platforms that are prevented from providing OpenGL support (http://en.wikipedia.org/wiki/Xbox). Other than that, I don't see any real advantage DirectX would provide when OpenGL can be used as well.
Btw, it would be nice to have sf::Array in SFML System ModuleHave you heard of the standard template library? In particular the containers library (http://en.cppreference.com/w/cpp/container). Doing a bit of research before suggesting something that is already a language library feature helps sometimes...
It is uncomfortable for me (and I think I am not alone) to have 3 different vector types (Vector2u, Vector2f, Vector2i) and 2 different rectangle types (FloatRect, IntRect).You're pretty much alone in that regard, I'd say. On the one hand there's just one template version of Vector2 and the ones you listed are just typedefs, on the other hand unsigned integers, floats and integers are not the same types and can't be treated as such, if you care about the precision and most of the people do care about that. So again the integer vector is used for when there are only integers values, float vectors are used for when something can have a decimal part (e.g. a position) and unsigned integer vectors are used when a value can't get negative and is an integer (e.g. window size). The same goes for rectangles.
It is uncomfortable for me (and I think I am not alone) to have 3 different vector types (Vector2u, Vector2f, Vector2i) and 2 different rectangle types (FloatRect, IntRect).There are several types of vectors and rectangles for the same reason that there are several types for numbers. Because each type is suitable in a given situation.
Sorry giving this idea again, but, I really would like SFML Team to implement DirectX as beckend.You write your own lib using DirectX, don't publish the code, come up with a very synthetic benchmark and claim that DirectX is 10x faster than OpenGL?
I did some testing with my lib(Simple Tool For Games[STFG] - its not published yet...) and SFML.
DirectX is 10x times faster.
I tested this with drawing some number of rectangles.
First of all... unless you implemented your drawing exactly as SFML did, it already isn't a fair comparison, because SFML might be able to do things that your lib doesn't and you wrote the test so it would run using both libraries.
What people seem to forget when comparing DirectX and OpenGL is that in the former case, you choose which API to use before writing even your first line of code. What happens if your library uses DirectX 11 and you have 10 year old hardware? Yeah... it doesn't work anymore. SFML will work on hardware that runs OpenGL 1.5 which dates all the way back to the last millenium. To make your comparison a bit more fair, you would have to make it use DirectX 7.It's really easy to check if DirectX 9 or 10 or 11 or whatever is supported. :)
You must be joking!!! (sarcastic, of course I know that...)I don't see why not implementing DirectX as other beckend.Sonkun is already working on an experimental DirectX implementation. Whether this is necessary is still up for discussion. The one advantage I can think of is enabling future support for platforms that are prevented from providing OpenGL support (http://en.wikipedia.org/wiki/Xbox). Other than that, I don't see any real advantage DirectX would provide when OpenGL can be used as well.Btw, it would be nice to have sf::Array in SFML System ModuleHave you heard of the standard template library? In particular the containers library (http://en.cppreference.com/w/cpp/container). Doing a bit of research before suggesting something that is already a language library feature helps sometimes...
But this really is cool:This does not look cool. Well, for me. =)
This method is used only to draw a quad, with no textures, no support for binding shaders. If SFML wanted to write separate draw() methods for each and every possible scenario there would be more of them than all the other methods in RenderTarget put together. SFML is designed to be generic. Like I already predicted before, your code is optimized with certain use cases in mind and your benchmark is thus very very synthetic. I highly doubt you will get such a big performance difference in a real world scenario, let alone allow real world usage without having to duplicate code a lot more than is actually required if you tried to stay generic.void Window::draw(st::g2d::RectangleShape& recta)
{
...
}
It's really easy to check if DirectX 9 or 10 or 11 or whatever is supported. :)It is less easy to restrain yourself to an ancient API version just to stay compatible with older hardware. The code you posted probably wouldn't work if you went ahead and made it compatible with DirectX 7 hardware like I suggested.
But this really is cool:std::vector is way cooler.
#ifndef STFG_ARRAY_H
#define STFG_ARRAY_H
#include <assert.h>
namespace st
{
template <typename TYPE>
class Array
{
...
};
}
#endif //STFG_ARRAY_H
anyway, let's get back to the topic, shall we? ;)Agreed.
This method is used only to draw a quad, with no textures, no support for binding shaders. If SFML wanted to write separate draw() methods for each and every possible scenario there would be more of them than all the other methods in RenderTarget put together. SFML is designed to be generic. Like I already predicted before, your code is optimized with certain use cases in mind and your benchmark is thus very very synthetic. I highly doubt you will get such a big performance difference in a real world scenario, let alone allow real world usage without having to duplicate code a lot more than is actually required if you tried to stay generic.There is already st::Drawable class. ;)
The first step of course, would be to make it public... but when that will happen, I don't know.It will happen soon, currently I'm making 3D Shapes(already added cuboid, cylinder...)
There was a problem with sf::sleep. Some programs like Chrome modify the FPS.This is already fixed.
I would love to see thing like support for non-western texts/fonts??
different styles??
QuoteIt is uncomfortable for me (and I think I am not alone) to have 3 different vector types (Vector2u, Vector2f, Vector2i) and 2 different rectangle types (FloatRect, IntRect).There are several types of vectors and rectangles for the same reason that there are several types for numbers. Because each type is suitable in a given situation.
Don't try to teach me the good coding behavior, I know them, this is my work to know that.Too bad it's not your job to follow them, unfortunately. :D Just kidding.
For me is about prototyping and fast development and trashing. ..... Maybe I should not use SFML for that purpose and using something like unity or gamemaker. But I like C++ and SFML ;D
There's been a few times for myself that having the sf::Text hold a reference to a string rather than a value would've been nice. I'd be a fan of the change if it was done.How good it will be in multithreaded app?
Was there a design decision as to why it holds a value? I mean, most of the API holds references rather than values.
There's been a few times for myself that having the sf::Text hold a reference to a string rather than a value would've been nice.
Until you realize that there would be not any clean solution for the text object to know if the reference it points at has changed its string and internal states need to be updated.That is what I thought, more or less. Until very recently I had a utility struct acting as a wrapper on top of sf::Text, which also held a container of sf::String*. The idea was to give the needed strings to the Text instance once, and then forget about them. But even this way, whenever the language changed, I had to do myOwnText::update(), with no argument, so as to apply sf::Text::setString() internally.
That is what I thought, more or less. Until very recently I had a utility struct acting as a wrapper on top of sf::Text, which also held a container of sf::String*. The idea was to give the needed strings to the Text instance once, and then forget about them. But even this way, whenever the language changed, I had to do myOwnText::update(), with no argument, so as to apply sf::Text::setString() internally.
Was there a design decision as to why it holds a value? I mean, most of the API holds references rather than values.In general, value semantics are more transparent, less surprising and easier to use than reference semantics. For example, sf::RenderWindow::setView() was changed to store a copy because of that.
- C++11: std::to_string ...So, why can't you just use std::to_string then?
- Network: nat hole punching, define packets ttl, timestampNAT hole punching isn't something you can just "enable" between 2 parties, it always consists of at least one party that doesn't require hole punching e.g. an internet server and the parties that do. So in case the 2 parties who are both trying to communicate behind each other are behind NAT gateways, you will need a publicly accessible server somewhere in the internet. This is really not a feature any more, but rather a concrete use case.
- Graphics: motion blur shader, shake screenThese are post-processing effects which are already possible with sf::Shader.
- Global: "inline" for short functions [like getPosition(), getRotation() ...etc]If you enable optimizations, you will find that more often than not, the compiler is smart enough to inline calls where they make sense. The opposite is also true, they don't inline where it doesn't make sense, even if the function is marked inline by the programmer. In the end it is only a hint, and a good optimizer shouldn't need that many hints to produce a program that runs fast, even without explicit inlines.
- System: add precise clock: std::chronoSo, do you want SFML to replicate std::chrono? Is there a reason you would rather use SFML's sf::Clock rather than std::chrono? Currently, SFML's clock might even have a higher resolution than std::chrono's high_resolution_clock, so I don't understand what exactly you are requesting.
i dont want to replace it with chrono just add something like sf::PreciseClockBut sf::Clock already has maximum precision. ???
I wish there would be a class called Camera. That could be very handy... Panning, Viewing, Zooming, etc. Although I know you can do it on sf::View, but I think its a cool idea to add Camera.So you want to add a second class that does the same as sf::View but with another name? ???
So you want to add a second class that does the same as sf::View but with another name? ???
I am not sure if this should be added in 3 or 2.2, but in SFML.NET there is no way to check if creating RenderTexture was succesfull or not.This is just a small issue that needs to be addressed quickly. Here we'd rather like to hear about your vision of what SFML 3 should be ;)
I already stated that I would like to see SpriteBatch in SFML 3, and it is not very small issue, becouse for example I am using rendertexture for my lighting system, and when it fails to create it, no lights are displaying :DQuoteI am not sure if this should be added in 3 or 2.2, but in SFML.NET there is no way to check if creating RenderTexture was succesfull or not.This is just a small issue that needs to be addressed quickly. Here we'd rather like to hear about your vision of what SFML 3 should be ;)
Thor integrationWhat features do you have in mind? And don't say "everything", I'd really like to know which parts of Thor you (and others) use most.
it is not very small issue, becouse for example I am using rendertexture for my lighting system, and when it fails to create it, no lights are displayingYes of course it is an important bug... but it's probably fixed in 5 minutes. You understand that it is not this kind of feedback we're expecting in this thread, do you? :P
Thor integrationWhat features do you have in mind? And don't say "everything", I'd really like to know which parts of Thor you (and others) use most.
maybe integrating the functionality projects of SFML into just one thing.
sf::Result<sf::Texture> texture = sf::Texture::loadFromFile("file.png");
if (!texture)
std::cerr << texture.err() << std::endl;
sf::Texture actualTexture = *texture;
I'm just getting started with SFML but I'll put in my 2 cents so far.
C++11 required
OpenGL 3.2+ Core Profile (for desktop OGL).
Both of those offer performance improvements right off the bat. Mesa already has OGL 3.3 support so I think it's getting to that time when we drop legacy OGL and compatibility profiles.
I disagree - there are still a huge number of PCs out there with "legacy" OGL. Implement the new features of 3.3+ by all means, and allow people to use them, but don't break it for people who don't have modern systems.
If you watch Valve during the Steam Dev Days their hardware survey shows very little legacy hardware out there. Unless you are dealing with Intel cards that are pre 2012 then you'll have core profile support.
Why wouldn't it work to just use SFML < 3.0 for legacy stuff?
It's also been stated that SFML 3.0 is a ways out. Are you saying that by the time 3.0 comes out you are still going to be dealing with a "huge" number of people who can only run OGL 2.1?
I realize right now there is probably a lot of people with pre 2012 Intel GPUs, but we are talking the future. It would be naive to think people won't ever upgrade their hardware, let alone people who play games.
slotdev, those applications sound really interesting. Do you see other SFML modifications that could affect the mentioned systems, such as moving from C++98 to C++11?
Maybe in general, are there many people bound to compilers that don't even support basic C++11 (i.e. VS <2010, g++ <4.6)?
There are for sure, in more industrial/commercial environments, a lot of people still use VS2008. Personally, I still use VS2005 for "systems" development and VS2010 for actual application (game..) development. So, enforcing C++11 could be a problem.The "S" in SFML stands for "Simple" and the "Simple" stands for simplicity in usage. It's not meant as "simply backwards compatible with 10+ years old hardware".
I worry we will lose the "S" in SFML.
Talking about industrial applications; you have to remember that replacing many thousands of PCs is very expensive - not only in the cost of the hardware, but the time and people required to do it. That is why it takes many years to update. Our oldest system we have to support is an Intel Celeron II based PC with 32mb VRAM. This is a nightmare, but we must do it.To be honest, it's not SFML's concern at all, how a company spends their money and whether it's too expensive to upgrade or not. SFML is free and open source, it's nice that it gets used in various commercial products, but it's not something that needs to constrain the software itself. The "problem" here is not that SFML is moving forward, but the problem is that a company is trying to save money (nothing against you or company of course! :) ).
Tank - the problem is more of a support one. If there is a major bug discovered, who is going to fix it?At one point we as an SFML Team will move on, as it has happened with SFML 1.6. When this happens there won't be anyone that fixes issues of old versions for free, especially not if it's for a company.
There is no incentive for people to work on 2.1 or whatever when 3.0 is the focus.The focus is still on SFML 2.x, this thread is merely here to gather what people envision SFML 3 to be, so we can create some sort of roadmap for SFML 2.x as well as SFML 3.x. As such it's kind of pointless discussing that new versions of SFML wouldn't work for you. First we need to figure out what the new version of SFML will be. :)
Tank - the problem is more of a support one. If there is a major bug discovered, who is going to fix it? There is no incentive for people to work on 2.1 or whatever when 3.0 is the focus.I can perfectly understand that, however it's important to also understand that SFML does not offer any guaranteed support. You will have to choose between options eXpl0it3r mentioned.
As such a move to C++11 will enforce the "S" even more.
To be honest, it's not SFML's concern at all, how a company spends their money and whether it's too expensive to upgrade or not.
Overall, you should not forget that everything we do here, is done for free.
I know, but also remember that there are companies and individuals who donate hundreds, if not thousands of Euros every year to allow the purchase of hardware, etc, which also allows the project to continue... ;)
Supporting C++11 will allow nice additions, but it won't replace many things. After this change, I think you'll still be able to write a program that uses mostly C++98, if you want to.If it can be done easily/nicely then sure. So yeah we'll have to discuss this in detail.
Regarding backward compatibility and maintenance of older versions, it's true that we'll move forward and focus on improving the latest versions, but I think it would be wise to spend some time back-porting bug fixes to the latest revision of the previous major version (i.e. 2.x after 3.0 is out). If we want SFML to be used in the real world, and not only for short-term small projects, we have to care a minimum about backward compatibility, and not abandon users who would not stick to the latest version. So where should the limit be? I don't know, but this should definitely be discussed.
..and people who don't use C++11 will have to go and learn a whole new set of skills. A good thing, but you're only going to get questions from people who don't know it inside out. Allow it, but don't enforce it.The discussion around C++11 is only whether the compiler has to support it or not. As for using SFML's public API you most likely won't have to know C++11, but if you do, you might be able to write more performant and nicer code.
Indeed. But there are real people who want to make games or whatever using SFML, who maybe don't have much money, and so buying new hardware also isn't an option.Yes, unfortunately we can't limit innovation to support someone's old hardware. I mean we're working for free and try to listen as much to the community as possible, so if there's anything specific that wouldn't work for someone, we'll try to find a satisfying solution for both sides.
I know, but also remember that there are companies and individuals who donate hundreds, if not thousands of Euros every year to allow the purchase of hardware, etc, which also allows the project to continue... ;)Again, not really a concern regarding SFML's development. If we would calculate all the time Laurent and all other developers of SFML spent on developing and supporting this project and multiply it with a "normal" senior developer salary, the cost on hardware would rather quickly shrink in comparison.
Just out of curiosity, if you're allowed/willing to tell us. Which company do you work for? In what kind of kiosks does SFML get used?
I mean in the end, one could always discuss/think about something like a partnership - libraries that are backed by companies often gain in popularity and over all code quality. Not that this is in any way my decision to make, just thought I throw it out there. :D
I don't know how popular https://www.bountysource.com/ is but it could benefit SFML if people are willing to put bounties on bugs and features. Might get us to version 3.0 a little sooner :DAs seen here (http://en.sfml-dev.org/forums/index.php?topic=15168.0) we don't have the money to do that. ;)
As seen here (http://en.sfml-dev.org/forums/index.php?topic=15168.0) we don't have the money to do that. ;)
However a mixture might be interesting, i.e. feature requests are made, everybody discusses them, based on arguments it's accepted or declined, and if it's accepted, people might vote for influencing priority/severity (is that what you meant, binary1248?).This is what I understood when I saw the UE4 roadmap. They took requests into consideration and only put up the ones they thought made sense. Then they let the community decide which ones were most important to them (i.e. should be done first) by enabling voting. Voting only influences the priority already confirmed features get, not what new features are going to be implemented.
Perhaps SFML 3 can feature genuinely modern C++...
I would implore to all and sundry that we don't end up with anything resembling Boost and its template hell in any wayDo you really think I would allow such things, after 7 years of efforts to keep SFML clean? ;)
Do you really think I would allow such things, after 7 years of efforts to keep SFML clean? ;)
For a functionality-focused library like SFML (rather than one that provides features for the language itself), these concepts complicate everything. Concepts require code to be written as templates, i.e. forcing definitions in headers, delaying/hiding compile errors, exposing internals and making compile times explode. Concepts make interfaces implicit; one must read the documentation in order to know an API can be used. They abstract from the obvious parts and make APIs less simple to use.
Concepts are not currently a feature of the language, hence the obscure errors and lack of helpful intellisense.You're right that these specific issues are mitigated when concepts are integrated as a language feature, but many of the problems I stated will remain as a result of the template-based implementation.
they are the cutting edge, whereas oop and RAII are as old as C++ itself.Being new doesn't imply meaningful applicability to all code. For example, a lot of C++11 features are only interesting for designers of generic, language-focused libraries. C++ has always been a language with a wide range of paradigms, and most applications make only use of a specific subset.
sf::Vector is a template but this genericity is mostly wasted as sf::Vector2f is the bread-and-butter point throughout the library. While the case could be made that OpenGL handles floats anyway, a whole host of other classes could fulfill the float-coordinate Point concept.
Adapting SFML's classes to Boost.Geometry's concepts makes evident that sf::Shape, sf::Sprite and sf::VertexArray are effectively ranges of points - additionally associated with colors and/or a texture. Conceivably, a std::vector<std::complex<float>> could serve just as well.
sf::Shape::getPoint, sf::VertexArray::operator[] and sf::Image::getPixel are essentially methods of iteration, yet require additional work to apply generic algorithms on them.
I can definitely see an argument for making sf::VertexArray behave more like an STL container with proper iterators (especially since it calls itself an array)This would be a total waste. sf::VertexArray is nothing else than a std::vector<sf::VertexArray>, adding more std::vector "features" would only lead to useless code duplication. If you want iterators etc. just role your own vector of vertices. ;)
This would be a total waste. sf::VertexArray is nothing else than a std::vector<sf::VertexArray>
It'd be nice if there was a way to make it so window.draw() could take a std::vector of sf::Vertex?
Maybe it's time to introduce the SFML Video module? I'm not even sure it would be that much work if based on ffmpeg :P
Shouldn't video playback be a basic component of a Simple and Fast Multimedia Library ?
myl
There really should be a way of managing the requests better. Personally I have the problem that I quickly lose overview in a forum, because current stuff gets mixed with old stuff. And once you have read the threads marked with "New posts!", it's difficult to remember what's still important and what not.
Just like with this thread: One has to go through *all* posts for collecting all the ideas etc. GitHub's issue tracker would work, however then ideas would be mixed with actual issues, which is not an option as well.
I agree to Nexus that a 100% free-form voting would end up in SFML becoming a 2D game engine with a world editor, tons of effects and a class "sf::GameGenerator" -- probably not what this library is intended for. ;) However a mixture might be interesting, i.e. feature requests are made, everybody discusses them, based on arguments it's accepted or declined, and if it's accepted, people might vote for influencing priority/severity (is that what you meant, binary1248?).
Tello might be something worth looking into. Here's the feature tour and an example:
https://trello.com/tour
https://trello.com/b/nC8QJJoZ/trello-development
As promised we as the new team, would like to be more open towards the community especially regarding the current development. We're currently discussing on how to approach things after SFML 2.2 and as such, we need to figure out what SFML 3.0 should actually be about.
Keep in mind this shouldn't really be about simple feature requests, for that we have dedicated forum, this should be more about what SFML 3 should offer besides a few new feature. For example: How the graphics API should be changed/opened/advanced, or whether C++11 should be non-optional, or should we change the way window states are handled, or etc...
We won't make any decisions here, we simply want to hear the ideas from all community members.
What is your vision of SFML 3?
- Support for multiple monitors.I'm curious, what do you mean by multiple monitor support? :-)
I'm curious, what do you mean by multiple monitor support? :-)Currently it's not possible to specify on which monitor a window should be created. Actually SFML doesn't even "know" that there are multiple monitors, it always just assume the primary monitor is the only monitor in existence.
All I want is a Line class >.<
Yup, the line is a rectangle shape with height = 1, but everytime I need to draw line, I have to calculate length and angle =)
(It was too hard to draw lightnings with rectangles ;D)
Very small feature:
Just as a sf::Transformable has a setPosition(float x, float y) as well as a setPosition(const sf::Vector2f& position),
it'd be nice if the setSize(const sf::Vector2f& position) function could also be setSize(float x, float y).
Why not have give the option to write it either way?Having only a vector overload encourages people to use vectors instead of separate components, which is generally a good thing. Also, it is more consistent with the rest of the API... unless you want every function to take separate components, but then also colors and rects.
@Kojay
Wait, I still don't get why doing that overload is a bad thing. Why not have give the option to write it either way?
4) Support for custom loop points for the audio module, or a way to achieve it without having to hack SFML's sourcesThis will at least soon be possible without hacking into SFML sources, with the coming modifications to the audio module.
Are you going to make SoundFile public?Exactly.
Adding Thor ParticleSystem & AnimationSFML is a multimedia library, not a game library ;)
adding more sound formats, specially midi, might be pluginable for other stuff like gstreamer, pulseaudio or JACKThis is something that we'll consider with the new sound file system.
if thinking about Video, a render video to RenderTarget would be funThe main blocking point about video is the huge list of dependencies needed, their license and their build system (yes, I have ffmpeg and all its codecs in mind).
Ogre CompositorChain with that you can have multiple gpu programs/shader for rendering one viewportThis is a bit too high-level.
sf::Shader add way to get the type of a parameter from the program if possibleI don't think if OpenGL gives this option, and I have no idea why one would have to do that. You're supposed to know what types you've declared in your shader...
does SDL2 have something we might need?SDL 2 is always an interesting source of inspiration, but we'd like to avoid "please implement X because SDL has it" ;)
Have Styleable Text where TextSections can be styled differentlyThis is also a bit high-level in my opinion. You can easily make your own with what SFML provides.
add more samples, specially from the new features, but i would also like to see the SoundListener features in actionFeel free to provide a more detailed list of what you'd like to see :)
This is also the reason why interface blocks were introduced in GL 3.1. The idea is that you declare a shader with a specific interface in mind, which you of course have to reflect in your code. Multiple shaders (even shader stages) can implement the same interface block if they are to be accessed in the same way from the user code. You are the one who writes the interface, for both sides. So anybody writing a custom shader that should work with your code will have to abide by it.Quotesf::Shader add way to get the type of a parameter from the program if possibleI don't think if OpenGL gives this option, and I have no idea why one would have to do that. You're supposed to know what types you've declared in your shader...
oh ok i didn't consider it "game libary" only stuff, i thought that would be basic enough for multimedia libQuoteAdding Thor ParticleSystem & AnimationSFML is a multimedia library, not a game library ;)
So let's keep these more advanced concepts in add-on libraries like Thor.
Dammit ok it might be but as far i dont know if it can be emulated with addons for sfml, like binary said:QuoteOgre CompositorChain with that you can have multiple gpu programs/shader for rendering one viewportThis is a bit too high-level.
The main idea is to add features to SFML that extension libraries wouldn't be able to implement because of a limitation within SFML itself.currently i dont know if it can be done with extension libraries
i looked myself what we could need ... SDL2 has gamecontroller support (we only have joystick, that might be a bit different), otherwise i didnt find anything what we might need.Quotedoes SDL2 have something we might need?SDL 2 is always an interesting source of inspiration, but we'd like to avoid "please implement X because SDL has it" ;)
hm okay if its simple to make it might be able to add to thor or similar,QuoteHave Styleable Text where TextSections can be styled differentlyThis is also a bit high-level in my opinion. You can easily make your own with what SFML provides.
i might look what i can do ... mostly currently i am thinking how to combine sf::Sprite with sf::SoundSourceQuoteadd more samples, specially from the new features, but i would also like to see the SoundListener features in actionFeel free to provide a more detailed list of what you'd like to see :)
Dammit ok it might be but as far i dont know if it can be emulated with addons for sfmlI don't know what it is in detail, but if it is a chain of full-screen effects then this can easily be achieved with two sf::RenderTexture.
As the graphics API supports shaders, it would be nice to be able to (at least) apply audio filters to create reverberations, echos, convolutions, 3D effects etc. :DThis isn't as easy as it seems ;). sf::Shader is built on top of OpenGL shaders. They make use of an own language: GLSL. OpenAL isn't really comparable to OpenGL in that it isn't hardware accelerated and as such doesn't have an equivalent for filters to entail something like an ALFL :P. And if there isn't any free and compatible (license-wise) library to perform filtering, I don't think it will make it into SFML any time soon.
sf::SoundStream is a base class that doesn't care about the stream source, which is left to the derived class. SFML provides a built-in specialization for big files (see sf::Music). No network stream source is provided, but you can write your own by combining this class with the network module.As far as I can tell, everything you described can be achieved with the current API...
It is even explained that you would want to derive from it to implement your own class that streams data from whatever source you want, including a filter you wroteI know, but a filter wouldn't be a source here, just some code between the raw samples and the filtered samples. The real source would be a file, and since the SoundFile wrapper is not exposed, it's difficult to stream them simply. I could use sf::SoundBuffers as in the tutorials, but it's not file streaming.
i was thinking a bit about Spites and SoundSource and SoundListener ...No no no... Sounds have 3D positions, sprites have 2D positions. Sounds have no direction. And most important: there's no dependency between the audio and graphics modules, and there will never be. It's up to you to synchronize audio and graphics, this is a high level task.
hm first, make a BaseInterface moveable, its for controling the Position and Direction of Sprite/(BigSprite)/SoundSource ..
Integrating some of Tor features directly in SFML functions if there's high-level or "misc." functions, providing them as well in a dedicated module
Just a note for al future posters: The main idea is to add features to SFML that extension libraries (like Thor, sfeMovie, SFGUI) wouldn't be able to implement because of a limitation within SFML itself. They are built on top of SFML and provide higher-level functionality as Laurent already said. Suggestions here should be targeted towards lower level things that have to be in core SFML to be made accessible to said higher-level libraries or your own code.
Quotei was thinking a bit about Spites and SoundSource and SoundListener ...No no no... Sounds have 3D positions, sprites have 2D positions. Sounds have no direction. And most important: there's no dependency between the audio and graphics modules, and there will never be. It's up to you to synchronize audio and graphics, this is a high level task.
hm first, make a BaseInterface moveable, its for controling the Position and Direction of Sprite/(BigSprite)/SoundSource ..
??? now i am ashamed ... Listener did had direction, not SoundSource ...It still has, but that doesn't change the fact that it doesn't make sense to store sprites and sounds or sound listeners together. What you actually want is an abstraction layer in between, most likely a scene graph. This is definitely not SFML's task.
but i did also think about that it might be complications with other stuff like Thor Animation and Particle System i did use so when they should animate the object, the Sound might not follow the SpriteThat sounds very confused. Animations, particles and sounds are widely independent components, how you combine them depends entirely on your game's code design. Again not something SFML should care about.
hmmm now i am thinking if SoundSource should have a direction too, so like you can only hear it if the speaker is showing into your direction ...Are you actually requiring those features or are those just spontaneous ideas? I ask because we have enough ideas on what would be possible, but we prefer implementing the useful ones first ;)
hmmm2: i also did think there might be some value for the current acceleration of the SoundSourceObject so it might the detect if its moving to you or away from you, (for the Doppler Effect) or is that already managed by AL?
hmmm now i am thinking if SoundSource should have a direction too, so like you can only hear it if the speaker is showing into your direction ...This doesn't make sense (even in real life), sounds propagate in all directions.
i also did thought about some kind of SceneGraph ... currently i dont know if i can get it working right impl drawable into that SceneGraph might not be a problem, but Transformable for sample is, because its functions are not virtual for overloading ... :/??? now i am ashamed ... Listener did had direction, not SoundSource ...It still has, but that doesn't change the fact that it doesn't make sense to store sprites and sounds or sound listeners together. What you actually want is an abstraction layer in between, most likely a scene graph. This is definitely not SFML's task.
i was thinking in form of PC speakers ... like for them you cant hear them (right) when you are on the wrong end ...Quotehmmm now i am thinking if SoundSource should have a direction too, so like you can only hear it if the speaker is showing into your direction ...This doesn't make sense (even in real life), sounds propagate in all directions.
Doppler effect is supported by OpenAL but it is not exposed by SFML.
Blender Support.Thank you for this amazing contribution.
I'm thinking about something like allegro5/Blender.QuoteBlender Support.Thank you for this amazing contribution.
This "idea" seems to be completely off-topic, but you can explain it with more details if you want...
As I see it, SFML is a little too low-level to cater to that.Ik that, but is it possible to create object import it to the blender and render and show part of that image with pos of camera and rotation. Slow sampling could be solved by showing preview of the object that could be shown, something like preview in the blender and that developers could use something like window.preview(blenderObjChar); and when they are happy you could use .draw() and it could sample it.
What you want can be done by higher level libraries that use SFML underneath.
SFML is a multimedia library, that means; get pixels on the screen, get samples onto sound cards, read events from the OS. Higher level stuff like, process this 3D model or handle this collision detection or similar is not SFML's job.
Just how I see it.
I've only said that it should be easier to create one.
You might want to try this (https://github.com/SFML/SFML/tree/feature/gl_dev). It's been around for a while. Just hasn't been promoted that much ::).
- Option to create a core context, maybe only for sf::Window due to the legacy code in sfml-graphics.
- Drop glew and use glLoadGen (less dependency when linking statically, less typing 8) )
- Expose the OpenGL ID from textures
- C++11 no-obligatory (to allow older platform)
- Filesystem
- GUI (like SFGUI)
- Easier ressources managements with containers (like Thor)
I'm pretty sure using C++11/14 only restricts the compilers you can use, not the platforms the final executable will run on. It's not like OpenGL versions.Latest visuals had minor issues with deployment onto XP but there is update for that. I know, 'XP is dead' but many people still wanna support it and who knows how long compilers will support building for XP, especially Microsoft's.
For SFGUI/Thor/etc, putting them directly into SFML is probably a bad idea (they're really a layer on top of SFML, not additional modules for it), but it would be very nice to see those extensions officially distributed alongside SFML so their build processes could be streamlined and they'd get more exposure/usage.Honestly, every SFML module except system is extension or 'layer on top of' to system (and graphic is also extension to window). There is nothing preventing you from discarding one module and pretending it doesn't exist, they are not internally tied to each other and there is no reason new ones like GUI, Thor, Whatever should be. It was just issue of 'out of our scope of SFML' and API stability so far for not including more stuff.
The proposals in this thread should focus on functionality that cannot easily be implemented on top of SFML, because of a limitation within SFML itself. That is, not features that can as well be part of external libraries.
WHAT I MEAN IS : Let the next SFML Version play video natively :)
cLion support :DSupport an IDE? SFML works with CLion as I've already shown you here (http://en.sfml-dev.org/forums/index.php?topic=16307.msg116790#msg116790)
Laurent, is it possible (and are you planning) to remove all of the dynamic dependencies of SFML?Not really. The main problem is, that there's nothing compareable out there to OpenAL. Some similar libraries are even less permissive and others don't support iOS and Android..
Another question: Would it be possible to separate all of the platform specific code from the SFML logic code on different files? Like, the OpenGL code separated from the Drawable/Window/Whatever code, in a way that the platform specific code could be easily ported without messing with SFML's logic?I'm not sure what you're asking. All platform specific code is usually in separated class (see all the XYZImpl.hpp/cpp files).
I see... There was talk some time ago about asking for permition to static link OpenAL from the developers, or something like that. Did it go through?Laurent, is it possible (and are you planning) to remove all of the dynamic dependencies of SFML?Not really. The main problem is, that there's nothing compareable out there to OpenAL. Some similar libraries are even less permissive and others don't support iOS and Android..
Another question: Would it be possible to separate all of the platform specific code from the SFML logic code on different files? Like, the OpenGL code separated from the Drawable/Window/Whatever code, in a way that the platform specific code could be easily ported without messing with SFML's logic?I'm not sure what you're asking. All platform specific code is usually in separated class (see all the XYZImpl.hpp/cpp files).
As for the rendering/OpenGL code, we might investigate a more detached approach.
I see... There was talk some time ago about asking for permition to static link OpenAL from the developers, or something like that. Did it go through?
Lets say I want to port my SFML game to Xbox360, for example.
QuoteI see... There was talk some time ago about asking for permition to static link OpenAL from the developers, or something like that. Did it go through?
It was permission to statically link libsndfile, however we did not get permission to do so. AFAIK dropping libsndfile as a dependency is what we are going to do about that.
QuoteLets say I want to port my SFML game to Xbox360, for example.
Porting SFML's rendering to DirectX is not really porting to another platform, its just changing the backend. So if you want XBox support you need platform specific code for the XBox and you need to change the rendering backend. That said, allowing multiple backends is unlikely to happen anytime soon. If you want to mess around with porting SFML's rendering to DirectX have fun. It won't be as easy as you make it out to be ;)
I see... There was talk some time ago about asking for permition to static link OpenAL from the developers, or something like that. Did it go through?You probably confuse this with libsndfile. I asked again and there wasn't any progress after 8+ month - still hasn't. As such the decision was made to drop libsndfile.
Lets say I want to port my SFML game to Xbox360, for example. As far as I know, Xbox360 has no OpenGL support, only DirectX. With the platform code (in this case, OpenGL) in its separated classes, all I would need to do would be to reimplement the platform classes using DirectX (I would imagine classes like Texture, Polygon, Display, or something like this, very low level), while maintaining the same interfaces, recompile SFML with those new implementations, then SFML would work with DirectX instead of OpenGL. The same if I would want to port my game to a platform that doesn't support OpenAL, for example.You're misusing the word "platform"; OpenGL isn't "platform code". SFML could currently potentially be ported to any platform supporting OpenGL 2.x-ish or with the upcoming Android port also OpenGL ES 1.something. The fact that Xbox360 doesn't support OpenGL, doesn't make the OpenGL code "platform code", but Xbox360 simply doesn't provide the nessecary dependency.
I see... There was talk some time ago about asking for permition to static link OpenAL from the developers, or something like that. Did it go through?You probably confuse this with libsndfile. I asked again and there wasn't any progress after 8+ month - still hasn't. As such the decision was made to drop libsndfile.
OpenAL itself is well supported on all platforms, so there's currently no issue (iOS comes with its own version).
Lets say I want to port my SFML game to Xbox360, for example. As far as I know, Xbox360 has no OpenGL support, only DirectX. With the platform code (in this case, OpenGL) in its separated classes, all I would need to do would be to reimplement the platform classes using DirectX (I would imagine classes like Texture, Polygon, Display, or something like this, very low level), while maintaining the same interfaces, recompile SFML with those new implementations, then SFML would work with DirectX instead of OpenGL. The same if I would want to port my game to a platform that doesn't support OpenAL, for example.You're misusing the word "platform"; OpenGL isn't "platform code". SFML could currently potentially be ported to any platform supporting OpenGL 2.x-ish or with the upcoming Android port also OpenGL ES 1.something. The fact that Xbox360 doesn't support OpenGL, doesn't make the OpenGL code "platform code", but Xbox360 simply doesn't provide the nessecary dependency.
However there are discussions going on, on how to refactor the graphics code to make it possible, to implement different rendering back-ends, such as DirectX. How and if this will be done, is still in discussion.
Edit: Hrmpf zsbzsb :P
However there are discussions going on, on how to refactor the graphics code to make it possible, to implement different rendering back-ends, such as DirectX. How and if this will be done, is still in discussion.
I don't know, it seems to me that any code that isn't ANSI C/C++ is to be considered a platform specific code, even if it has ports on multiple platforms. But if you preffer, you could interpret my posts as referring to backends then.Not really. If you use library X one OS K, the library API doesn't become "platform code", the API itself has nothing to do with OS K, it's just an API on it's own. The issue that library X isn't supported on OS J still doesn't make the library API platform specific/platform code.
It is a make or break feature for any user or game studio evaluating SFML for use in a console game, or even a PC game with a potential console port down the road. This is a large user base to turn away from SFML due to lack of necessary cross-platform support.We're aware of that. However one should also not forget that developing for consoles usually comes with a licensing price to begin with, thus officially porting SFML to such "pay-first-develop-later" platforms probably won't happen, unless there are generous sponsors or something. ;)
It may be worth looking at Ogre3D's (http://www.ogre3d.org/download/source) decoupling of RenderSystems (DirectX, GL, GLES) when considering a similar architecture for SFML.I don't think, it's worth looking at that too much, then again I don't know it in detail. ;)
\However one should also not forget that developing for consoles usually comes with a licensing price to begin with, thus officially porting SFML to such "pay-first-develop-later" platforms probably won't happen, unless there are generous sponsors or something. ;)
I don't know, it seems to me that any code that isn't ANSI C/C++ is to be considered a platform specific code, even if it has ports on multiple platforms. But if you preffer, you could interpret my posts as referring to backends then.Not really. If you use library X one OS K, the library API doesn't become "platform code", the API itself has nothing to do with OS K, it's just an API on it's own. The issue that library X isn't supported on OS J still doesn't make the library API platform specific/platform code.
I can write a library just using standard C++ (it's probably better to use ISO than ANSI, even if ISO stuff is automatically ANSI), like my library has a public function test() which prints out "Hello World". By your definition my standard C++ library would now turn into platform code, since my function test() isn't part of the standard C++. However since my code is written in standard C++, it will work on any platform, thus my API (the test() function) isn't platform code.
OpenGL is also "just" an API (okay it's a bit more tricky than that), it's not platform code, but the API isn't available on all platforms. ;)
What would you do with a window with no GL context?use another context :P
GL core spec should be used by default. Yes I can recompile SFML, but defaults mattersfml-graphics is still written to use legacy OpenGL, so as long as you use it, you will have to use a compatibility profile context. Work is already under way in the gl_dev branch (https://github.com/SFML/SFML/tree/feature/gl_dev) to add support for selecting between compatibility and core profiles. If you don't need to use sfml-graphics and only use sfml-window, you will be able to create a core (and debug) context.
- http://www.sfml-dev.org/tutorials/2.0/window-window.php says it uses sf:sleep for managing framerate limit, and that sf:sleep's "resolution depends on the underlying OS, and can be as high as 10 or 15 milliseconds". I find it very important to use the best (most accurate) solution on every OS. i.e. Windows has Multimedia Timers (http://msdn.microsoft.com/en-us/library/windows/desktop/dd743609%28v=vs.85%29.aspx). Using an inaccurate thread-sleep in non-v-synced mode kind of defeats the purpose of a non-v-synced mode (reduced input lag).The discussion about this, has been moved to this thread (http://en.sfml-dev.org/forums/index.php?topic=16424.0).
However one thing I wouldn't really want to see is Strata 0. Sure we won't be able to prevent it, but for the most time it's really just a lot of wasted effort when people try to use SFML without being able to program the most basic things. We've developed and maintain a library and aren't here to hold introduction to C++ or programming talks. There are dedicated communities which do this kind of thing to some form and they are usually way better equipped with information and teaching material.This. SFML is written in C++. C++ is not Java/C#/Rust/Scala/Racket/Haskell/Python/JavaScript/etc. It doesn't hold your hand. It gives you a loaded gun, and lets you do whatever you want with it, especially shoot yourself. It's important to keep the target audience in mind: C++ developers. These developers might have a wide range of skill and experience levels, but if they're using SFML and C++, then 1) they aren't (or shouldn't be) total novices to programming, 2) they're in it for the pain, and 3) they're prepared to deal with the fact that they might (and eventually will) blow their leg off. While I think SFML should be as simple and user friendly as possible, it shouldn't coddle users who are woefully unprepared for the tools they're using.
The point is to make MASTERING sfml easier by reducing the skill curve. You reduce the amount of options and you also reduce the complexity. Then people can master a subset of the functionality of SFML proper, and when they are content with that and really are being held back by the lack of options they can move up one stratification level and learn more things and do more things. That increases the rate at which newbie users develop into expert users.Isn't that what makes games great? Being easy to learn and hard to master? Given that SFML doesn't aim to keep people "playing the development game" longer than they want to, I don't think it is necessary to give people a "virtual milestone" where they can claim that they have mastered some aspect of SFML. Who knows... maybe they might think that they have mastered something, when in fact they are far from it. As such any such "virtual milestone" doesn't make much sense to me, and gives people more of a reason to falsely assume that they have completed something that has no clear completion conditions.
More general purpose functionality, such as a fully fleshed vector class.
For SFML 3.0 i hope you'll still maintain the C# binding :p
It would be nice to have extended features for Vectors, like Lerp/Distance, and an official tweaning api would be great addition i think
Console support would be cool too :p
- Some of the compatibility we do see in SDL, SFML does work against all pc platforms but I would love to use some of these tools when making android games as SFML has some of the best sprite handling in my opinionSFML already works on Android and iOS.
- This is just a small gripe of mine but if you could getting rid of having to use the different configs with .lib / .a files when there are 2 sets of libraries that are generated. Sadly in that sense that is a win for SDLI'm not sure I understand what you mean here.
- Some bug fixes with using SFML Textures in OpenGL, this might just be me but when I use sf::Texture::bind() on some objects in opengl there will be an error message in the console that says there was an openglI don't think bug fixes belong to the "vision for SFML 3" thread ;)
What about getting rid of overriding huge amount of methods like that:Yes, we already mentioned this point.
sf::Transformable::move(float x, float y)
sf::Transformable::move(sf::Vector2f vec)
?
sf::FileInputStream => std::ifstream (literally the same)
sf::InputStream => std::istream (literally the same)
Also when will the SFML 3 project/branch be started?Same question for me. I would really like to participe in SFML 3 development. ;)
I don't know if we can use the i(f)streams with Android and iOS, that's probably why they were created.
sf::ThreadLocal => no need if sf::Threads become a std::thread ? (not sure what it does)Not std::thread, but the thread_local keyword
sf::InputStream => std::istream (literally the same)If it were literally the same, SFML had used std::istream in the first place, as it's no C++11 feature. Read the documentation to see what it does.
Not sure to understand...are you talking about http://en.cppreference.com/w/cpp/language/storage_duration (http://en.cppreference.com/w/cpp/language/storage_duration)sf::ThreadLocal => no need if sf::Threads become a std::thread ? (not sure what it does)Not std::thread, but the thread_local keyword
I should not have said (literally the same) on this one, but the fact is that you are using it as the base class for all your input with a focus on file inputsf::InputStream => std::istream (literally the same)If it were literally the same, SFML had used std::istream in the first place, as it's no C++11 feature. Read the documentation to see what it does.
Abstract class for custom file input streams.By replacing this with std::istream we would have access to all of the standard library type that inherit from std::istream and the future type coming (C++17, C++20,...) like in C++20 there's the standard networking library that should be ready and if it magicaly have a std::isocketstream we could have without change support for loading assets from a network... (this is a crude and simple exemple, but serve it purpose).
This class allows users to define their own file input sources from which SFML can load resources.
Also, some implementations, while they exist in the standard library, are rather low-level and not always well-supported by all compilers (e.g. it took quite long until high_resolution_clock was adopted by MSVC). This is also a point to consider when changing the implementation.I'm not following you on this one.... there was multiple intervention on this forum thread about SFML 3 using C++11, and all my implementation replacement use at most C++11 and on top of that all major compiler vendor (GCC, Clang, MSVC) now have stable support up to C++14 language features http://en.cppreference.com/w/cpp/compiler_support (http://en.cppreference.com/w/cpp/compiler_support) we're nearly in 2017.... C++17 is nearly here... C++11 use should not even be in debat right now
like in C++20 there's the standard networking library that should be ready and if it magicaly have a std::isocketstream we could have without change support for loading assets from a network... (this is a crude and simple exemple, but serve it purpose).Keep in mind that most SFML resources need a seekable stream, that network streams will most likely not be. Things won't be as magical as it seems.
Yeah... but it was just a simple exemple to illustrate an advantage (and i didn't knew of another feature coming in the futur that might use an std::istreamQuotelike in C++20 there's the standard networking library that should be ready and if it magicaly have a std::isocketstream we could have without change support for loading assets from a network... (this is a crude and simple exemple, but serve it purpose).Keep in mind that most SFML resources need a seekable stream, that network streams will most likely not be. Things won't be as magical as it seems.
Also about "let's use standard stuff instead": I fully agree, but you also have to admit that some standard library stuff feels horribly overcomplicated compared to what SFML provides or provided in regards to simplicity, especially for beginners. I think the former sf::Randomizer (http://www.sfml-dev.org/documentation/1.6/classsf_1_1Randomizer.php) would be a typical example for me compared to what C++11 provides (http://en.cppreference.com/w/cpp/numeric/random).
Yes, these classes are public now. We even have support for loop points pending (I don't know if it has been merged into master yet).
It leaves me with the impression -- rightly or wrongly -- that the powers-that-be are less interested in hearing the community's vision for SFML 3 than maintaining the status quo.That's a fair critic and we should definitely improve on that. For the record though, this impression is incorrect: we really value community feedback -- granted that only extremely convincing and well developed arguments will convince us that a new feature indeed fits SFML scope.
We have some sort of roadmap here: https://en.sfml-dev.org/forums/index.php?topic=21542.msg153137#msg153137 I think you'll find many of the wishes made in this thread on the roadmap.Thank you for the link! This is exactly what I was hoping to see, mainly because it contrasts with what this thread exhibits. I'm still feasting on much of the contents under discussion, and expect to be for some time. Brain food, as it were. ;D
. . . 3) more community PR.I agree. Do you have anything specific in mind? How can I help?
I think this last point would really help make SFML better with faster progress. It's obvious that the core team has many things to do and many other activities besides SFML, so if we could delegate more to the community that'd be awesome.
set line height, letter spacingAll done (will be released in 2.5). This kind of non-breaking changes don't need to wait for SFML 3, and we can discuss them at any time in the "feature request" sub-forum.
Clipboard support
Will there be a C and .NET port of SFML 3?If someone writes them, yes.
SDL2 is low-level, it feels right to hide it away. SFML is higher-level by it's very natureI'm curious to know what makes SFML higher-level. It is designed to provide the exact same set of features than SDL and other similar frameworks. Maybe SFML just looks higher-level, because it is designed nicely with an object-oriented approach? ;)
On a less dramatic note, I'd love if Image/Audio loading returned an std::future or had a "loadFromFileAsync" variant that returned an std::future :)I think it's wrong to ask an asynchronous version of XYZ feature when you can simply do
Maybe SFML just looks higher-level, because it is designed nicely with an object-oriented approach? ;)
I think it's wrong to ask an asynchronous version of XYZ feature when you can simply doauto result = std::async([](std::string filename){sf::Image image; image.loadFromFile(filename); return image;}, "blop.png");