1
Feature requests / Re: Nacl support
« on: June 01, 2016, 12:51:10 pm »
These days it would probably be more reasonable to aim for emscripten 
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
Graphics / Re: Error when loading sf::Texture in another thread
« on: February 21, 2016, 05:39:10 pm »
Thanks for the replies.
I built said feature branch and it now works perfectly. I will leave a post in the related issue. Hope it gets merged soon.
This has been known for a while: #989
Just use https://github.com/SFML/SFML/tree/feature/no_internal_context for now.
The "fix" (and improvement) was submitted quite a while ago, however it has been stuck in "testing hell" since then. The more support the pull request gets, the faster it will eventually get merged. So feel free to leave feedback in #1002 and #989.
I built said feature branch and it now works perfectly. I will leave a post in the related issue. Hope it gets merged soon.
3
Graphics / Error when loading sf::Texture in another thread
« on: February 21, 2016, 04:23:05 pm »
Heya!
I am trying to load an sf::Texture in another thread. According to my googling etc, it seems to me like this should be allowed, as seen in both of these threads: http://en.sfml-dev.org/forums/index.php?topic=10452.0 http://en.sfml-dev.org/forums/index.php?topic=10344.0
So my first question is: Is it totally legit to load an sf::Texture in another thread?
Now, after seeing that it might indeed be allowed, I thought my code was the one that was broken, but then I tried the minimal example found in one of those threads, namely this:
This however exhibits the exact same problem.
The problem I get is a segfault. When backtracing it in GDB, I see the following:
I am using self-compiled sfml 2.3 and I have tried building my application with both clang and gcc, same result.
Am I missing something obvious on what I need to do to make it possible to load sf::Textures in other threads, or is this not possible at all atm? In the other threads there was talk about a bug related to glFlush() but it seems to have been fixed years ago.
Any ideas appreciated, thanks.
I am trying to load an sf::Texture in another thread. According to my googling etc, it seems to me like this should be allowed, as seen in both of these threads: http://en.sfml-dev.org/forums/index.php?topic=10452.0 http://en.sfml-dev.org/forums/index.php?topic=10344.0
So my first question is: Is it totally legit to load an sf::Texture in another thread?
Now, after seeing that it might indeed be allowed, I thought my code was the one that was broken, but then I tried the minimal example found in one of those threads, namely this:
#include <SFML/Graphics.hpp>
struct LoadTexture
{
sf::Texture& texture ;
bool & success ;
std::string filename ;
LoadTexture(sf::Texture& t, bool& s, const std::string& fname)
: texture(t), success(s), filename(fname) {}
void operator()()
{ success = texture.loadFromFile(filename) ; }
};
int main()
{
sf::RenderWindow window(sf::VideoMode(800, 600), "sf::Thread test");
bool success = false ;
sf::Texture green ;
{
sf::Thread thread(LoadTexture(green, success, "GreenTile.png")) ;
thread.launch() ;
}
// success = green.loadFromFile("GreenTile.png") ;
if ( !success )
return 0 ;
while ( window.isOpen() )
{
sf::Event event ;
while ( window.pollEvent(event) )
{
if ( event.type == sf::Event::Closed )
window.close() ;
}
window.clear() ;
window.draw(sf::Sprite(green)) ;
window.display() ;
}
}
struct LoadTexture
{
sf::Texture& texture ;
bool & success ;
std::string filename ;
LoadTexture(sf::Texture& t, bool& s, const std::string& fname)
: texture(t), success(s), filename(fname) {}
void operator()()
{ success = texture.loadFromFile(filename) ; }
};
int main()
{
sf::RenderWindow window(sf::VideoMode(800, 600), "sf::Thread test");
bool success = false ;
sf::Texture green ;
{
sf::Thread thread(LoadTexture(green, success, "GreenTile.png")) ;
thread.launch() ;
}
// success = green.loadFromFile("GreenTile.png") ;
if ( !success )
return 0 ;
while ( window.isOpen() )
{
sf::Event event ;
while ( window.pollEvent(event) )
{
if ( event.type == sf::Event::Closed )
window.close() ;
}
window.clear() ;
window.draw(sf::Sprite(green)) ;
window.display() ;
}
}
This however exhibits the exact same problem.
The problem I get is a segfault. When backtracing it in GDB, I see the following:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffeb013700 (LWP 20915)]
0x00007ffff697e80f in _int_malloc () from /usr/lib/libc.so.6
(gdb) ba
#0 0x00007ffff697e80f in _int_malloc () from /usr/lib/libc.so.6
#1 0x00007ffff69803d4 in malloc () from /usr/lib/libc.so.6
#2 0x00007ffff724b0e8 in operator new (sz=8) at /build/gcc-multilib/src/gcc-5.3.0/libstdc++-v3/libsupc++/new_op.cc:50
#3 0x00007ffff7548ce8 in (anonymous namespace)::getInternalContext() () from /usr/local/lib/libsfml-window.so.2.3
#4 0x00007ffff7548db5 in sf::priv::GlContext::ensureContext() () from /usr/local/lib/libsfml-window.so.2.3
#5 0x00007ffff7549b03 in sf::GlResource::GlResource() () from /usr/local/lib/libsfml-window.so.2.3
#6 0x00007ffff754768e in sf::Context::Context() () from /usr/local/lib/libsfml-window.so.2.3
#7 0x00007ffff7548cf3 in (anonymous namespace)::getInternalContext() () from /usr/local/lib/libsfml-window.so.2.3
#8 0x00007ffff7548db5 in sf::priv::GlContext::ensureContext() () from /usr/local/lib/libsfml-window.so.2.3
#9 0x00007ffff7549b03 in sf::GlResource::GlResource() () from /usr/local/lib/libsfml-window.so.2.3
#10 0x00007ffff754768e in sf::Context::Context() () from /usr/local/lib/libsfml-window.so.2.3
#11 0x00007ffff7548cf3 in (anonymous namespace)::getInternalContext() () from /usr/local/lib/libsfml-window.so.2.3
#12 0x00007ffff7548db5 in sf::priv::GlContext::ensureContext() () from /usr/local/lib/libsfml-window.so.2.3
#13 0x00007ffff7549b03 in sf::GlResource::GlResource() () from /usr/local/lib/libsfml-window.so.2.3
....
This goes on for thousands of stackframes
[Switching to Thread 0x7fffeb013700 (LWP 20915)]
0x00007ffff697e80f in _int_malloc () from /usr/lib/libc.so.6
(gdb) ba
#0 0x00007ffff697e80f in _int_malloc () from /usr/lib/libc.so.6
#1 0x00007ffff69803d4 in malloc () from /usr/lib/libc.so.6
#2 0x00007ffff724b0e8 in operator new (sz=8) at /build/gcc-multilib/src/gcc-5.3.0/libstdc++-v3/libsupc++/new_op.cc:50
#3 0x00007ffff7548ce8 in (anonymous namespace)::getInternalContext() () from /usr/local/lib/libsfml-window.so.2.3
#4 0x00007ffff7548db5 in sf::priv::GlContext::ensureContext() () from /usr/local/lib/libsfml-window.so.2.3
#5 0x00007ffff7549b03 in sf::GlResource::GlResource() () from /usr/local/lib/libsfml-window.so.2.3
#6 0x00007ffff754768e in sf::Context::Context() () from /usr/local/lib/libsfml-window.so.2.3
#7 0x00007ffff7548cf3 in (anonymous namespace)::getInternalContext() () from /usr/local/lib/libsfml-window.so.2.3
#8 0x00007ffff7548db5 in sf::priv::GlContext::ensureContext() () from /usr/local/lib/libsfml-window.so.2.3
#9 0x00007ffff7549b03 in sf::GlResource::GlResource() () from /usr/local/lib/libsfml-window.so.2.3
#10 0x00007ffff754768e in sf::Context::Context() () from /usr/local/lib/libsfml-window.so.2.3
#11 0x00007ffff7548cf3 in (anonymous namespace)::getInternalContext() () from /usr/local/lib/libsfml-window.so.2.3
#12 0x00007ffff7548db5 in sf::priv::GlContext::ensureContext() () from /usr/local/lib/libsfml-window.so.2.3
#13 0x00007ffff7549b03 in sf::GlResource::GlResource() () from /usr/local/lib/libsfml-window.so.2.3
....
This goes on for thousands of stackframes
I am using self-compiled sfml 2.3 and I have tried building my application with both clang and gcc, same result.
Am I missing something obvious on what I need to do to make it possible to load sf::Textures in other threads, or is this not possible at all atm? In the other threads there was talk about a bug related to glFlush() but it seems to have been fixed years ago.
Any ideas appreciated, thanks.
4
Feature requests / Re: Conversion of all SFML classes from using private to protected
« on: December 04, 2015, 01:09:30 pm »
Making everything protected by default IMO breaks a lot of design considerations. It is nicer when classes are either designed to be inherited or designed to not be. This creates an API which is more focused and clear in its purpose. Besides, to make them properly inheritable you also need to add a virtual destructor which would AFAIK cause a vtable to be inserted in every class which could be a drawback in terms of overhead in some cases.
It is better to by default try to use the avialable components to build new ones with composition rather than inheritance. If you truly have issues using this way to build upon SFML's functionality, then maybe those classes are flawed in their design in other ways in which case it could probably be improved in better ways than making everything protected.
It is better to by default try to use the avialable components to build new ones with composition rather than inheritance. If you truly have issues using this way to build upon SFML's functionality, then maybe those classes are flawed in their design in other ways in which case it could probably be improved in better ways than making everything protected.
5
Feature requests / Re: A couple suggestions
« on: August 23, 2015, 05:56:03 pm »
Just going drop a couple of words in regards to the sf::Audio and sf::Music naming. I totally agree with GraphicsWhale and I find the names very unspecific and confusing. 'Audio' is very broad and includes music, and 'Music' is in some cases also pretty arbitrary, and for someone who hasn't done audio programming at all before, it would not at all be clear why there is such a distinction and what it is for.
Naming them AudioStream and SampledAudio or something similar would make it very clear and would encourage users to understand the basic things you need to consider when doing audio programming and that's a good thing.
Naming them AudioStream and SampledAudio or something similar would make it very clear and would encourage users to understand the basic things you need to consider when doing audio programming and that's a good thing.
6
Feature requests / Re: Can we make RenderStates and Drawable loadable resources?
« on: May 27, 2015, 10:17:56 pm »
How does being able to load collada and other such 3D vertex formats benefit the common use cases for a multimedia library?
The use case you stated was really contrived and complicated and I can't see that arise in even 1 out of 100 applications. You'll have to describe a more real-world general use case which actually sounds attractive to other people than your own very specific usage. Until you do that you'll not manage to convince anyone.
Also, saying "why not adding it?" is not a valid argument. Things are added for proper reasons, not lack of counter arguments. The burden of proof, so to say, is on you.
The use case you stated was really contrived and complicated and I can't see that arise in even 1 out of 100 applications. You'll have to describe a more real-world general use case which actually sounds attractive to other people than your own very specific usage. Until you do that you'll not manage to convince anyone.
Also, saying "why not adding it?" is not a valid argument. Things are added for proper reasons, not lack of counter arguments. The burden of proof, so to say, is on you.
7
General discussions / Re: Here is an open source dynamic Queue I wrote for anyone who is interested
« on: May 24, 2015, 05:06:54 pm »
How come you say that std::queue is not useful as a queue?
8
Feature requests / Re: sf::Image::getPixel()/setPixel() validity
« on: May 19, 2015, 12:14:49 pm »Ignoring the fact that this is off topic, I was part of the first ever project (that we could find out about), where we made the school trophy by scanning people in and (me) doing the modelling in blender. It crashed every computer we put it on, including an alienware aurora, that has an i7 and 16gb of ram. It was also taking about a minute per vertex move or quadrilateral creation.
I bet you that's due to implementation, not the language selection. If it was years ago, it is likely that blender back then was more unstable.
9
General discussions / Re: bytes vs floats for color components
« on: January 21, 2015, 02:05:50 pm »
I implemented a colour class similar to the sfml one in one of my projects and I had the same considerations. I almost decided to go with floats, but I decided against it for these reasons:
When dealing with colours in other contexts aside from rendering, they are commonly represented using bytes. I.e. colour pickers in applications, data in image files, etc. This means that when interacting with other libraries for example when loading/saving images, they are going to be in bytes. This means that your code might integrate more easily when using bytes.
For example, if the bytes are stored like so:
And an image loading function spits out a char* of bytes of RGBA data, you can simply do:
And you can access the pixels directly due to binary compatibility.
Also by using bytes, there is no ambiguity. You know that if you have 223 red, you can directly compare it with the pixel of an external function. But if you store stuff in floats, maybe it would depend on arbitrary float maths if the values are exact or not. I am not sure how valid that case is, but for me it felt like a reason.
Finally, the conversions to float isn't a bottleneck in terms of performance in the very most of all cases.
Note: I don't know how much this applies to SFML's choice of using bytes, but that's my reasoning for a similar case.
When dealing with colours in other contexts aside from rendering, they are commonly represented using bytes. I.e. colour pickers in applications, data in image files, etc. This means that when interacting with other libraries for example when loading/saving images, they are going to be in bytes. This means that your code might integrate more easily when using bytes.
For example, if the bytes are stored like so:
struct Color
{
uint8_t r, g, b, a;
}
{
uint8_t r, g, b, a;
}
And an image loading function spits out a char* of bytes of RGBA data, you can simply do:
Color* color = (Color*) theImage;
And you can access the pixels directly due to binary compatibility.
Also by using bytes, there is no ambiguity. You know that if you have 223 red, you can directly compare it with the pixel of an external function. But if you store stuff in floats, maybe it would depend on arbitrary float maths if the values are exact or not. I am not sure how valid that case is, but for me it felt like a reason.
Finally, the conversions to float isn't a bottleneck in terms of performance in the very most of all cases.
Note: I don't know how much this applies to SFML's choice of using bytes, but that's my reasoning for a similar case.
10
SFML projects / Re: Feather Kit - A C++ Game Framework
« on: October 18, 2014, 04:24:25 pm »
I myself got these errors now with an updated clang version, so I have fixed all of them and the changes are in the incoming branch. Thanks!
11
SFML projects / Re: Feather Kit - A C++ Game Framework
« on: October 09, 2014, 02:17:43 pm »
Ah, hmm, Interesting with the "not a member" error. I haven't gotten that myself and glm::u64vec2 does definitely exist. Maybe glm/gtc/type_precision.hpp needs to be included. Would you mind trying adding #include <glm/gtc/type_precision.hpp> under the glm include in that file to see if that fixes it? If it does, I'll add it.
As for the second errors, would you be able to show a diff of where you changed the { } to constructors? I'll add those as well in that case.
Thanks for the information.
As for the second errors, would you be able to show a diff of where you changed the { } to constructors? I'll add those as well in that case.
Thanks for the information.
12
SFML game jam / Re: Potential Schedule
« on: July 14, 2014, 05:09:12 am »
I think a strict schedule going over a few months like this is not a that good idea. For the same reason that I think that set dates for when the jam should be (i.e. every X months) is also a bad idea.
The reason for this is that the people who are managing and organising the jam are just doing it on their spare time, and spare time can be unpredictable. For example, the last jam was not very fun because we had 1 submission in the end, all other people had no time. Not even the arrangers had time to join or such.
That's why in my opinion it would be better to not have set schedules or dates, but instead plan/announce the jams when there is time available and enough interest by people joining them. That way we can have more qualitative jams, instead of a long succession of jams that not many people ended up having time for.
The reason for this is that the people who are managing and organising the jam are just doing it on their spare time, and spare time can be unpredictable. For example, the last jam was not very fun because we had 1 submission in the end, all other people had no time. Not even the arrangers had time to join or such.
That's why in my opinion it would be better to not have set schedules or dates, but instead plan/announce the jams when there is time available and enough interest by people joining them. That way we can have more qualitative jams, instead of a long succession of jams that not many people ended up having time for.
13
SFML projects / Re: Feather Kit - A C++ Game Framework
« on: July 01, 2014, 05:27:53 am »
Thanks for the feedback!
The source of the landscape generator will be made available. I just need to refactor it becasue it is currently very (read extremely) ugly... When I've done that, I'll definitely make the source available.
Not sure about the other one though since it is a game project I am working on, and right now I haven't decided if I want it closed source or not. But it is on my todo-list to write example programs to showcase the things shown there anyway.
I will also definitely write more tutorials! The current 4 tutorials doesn't touch most of the modules hehe. Cheers.
The source of the landscape generator will be made available. I just need to refactor it becasue it is currently very (read extremely) ugly... When I've done that, I'll definitely make the source available.
Not sure about the other one though since it is a game project I am working on, and right now I haven't decided if I want it closed source or not. But it is on my todo-list to write example programs to showcase the things shown there anyway.
I will also definitely write more tutorials! The current 4 tutorials doesn't touch most of the modules hehe. Cheers.
14
SFML projects / Re: Feather Kit - A C++ Game Framework
« on: June 30, 2014, 11:21:20 am »
Alright, I felt it was time to update this thread again in case someone is interested in knowing the progress.
Since last time, I've seen some interest in the framework and I've got some users/contributors (for example this project)which really helps the maturing of the library.
I am still trying to get the library in a good shape for the 1.0.0 release (it is now at 1.0.0rc4) and some things might change until then, but as it hits 1.0.0, there will be no API breaking changes until 2.0.0.
Some notable changes since last time:
The pathfinder is completely general and can work on any data, so even if you are not interested in using featherkit in general for your project, you can still use only the pathfinder would you need to.
Example 1:
This shows how an infinite landscape can be created using the noise tools:
Link
Controls:
- Cursor keys to steer the camera.
- Click to see what biome is at a certain point.
Example 2:
This shows among other things, text rendering, entity management and pathfinding.
Link
Controls:
- Click "begin" to get past splash screen.
- WSAD to steer the camera.
- Click/drag left mouse button to place walls.
- Click/drag right mouse button to erase walls.
- Scroll to zoom.
- Press B to place a building. The workers will find a path to the building site if it exists, and build it.
Since last time, I've seen some interest in the framework and I've got some users/contributors (for example this project)which really helps the maturing of the library.
I am still trying to get the library in a good shape for the 1.0.0 release (it is now at 1.0.0rc4) and some things might change until then, but as it hits 1.0.0, there will be no API breaking changes until 2.0.0.
Some notable changes since last time:
- Audio module relies on libvorbisfile instead of libsndfile.
- Added an A* pathfinding class.
- Added a set of noise tools (probably most interesting for generating simplex noise).
- Added word wrap functionality for the text surface.
- One can now add custom shader uniforms to any drawable for use with custom shaders.
- Include directories and library prefixes are "fea" instead of "featherkit".
- Messaging now works by sending any structs instead of tuple-based messages. Great for type safety.
- Many other smaller updates/fixes.
The pathfinder is completely general and can work on any data, so even if you are not interested in using featherkit in general for your project, you can still use only the pathfinder would you need to.
Example 1:
This shows how an infinite landscape can be created using the noise tools:
Link
Controls:
- Cursor keys to steer the camera.
- Click to see what biome is at a certain point.
Example 2:
This shows among other things, text rendering, entity management and pathfinding.
Link
Controls:
- Click "begin" to get past splash screen.
- WSAD to steer the camera.
- Click/drag left mouse button to place walls.
- Click/drag right mouse button to erase walls.
- Scroll to zoom.
- Press B to place a building. The workers will find a path to the building site if it exists, and build it.
15
SFML game jam / Competition style voting?
« on: June 13, 2014, 10:25:39 am »
Hello!
I want to raise a question that I don't think have been discussed yet. Should future game jams be voting/winner based?
What I mean by this is that all submissions are voted upon after the jam time is over. After the voting period is over, the results are shown and the one with the most votes win. Votes could be made on the basis of enjoyment when playing/theme relevance/concept or even possibly things like code neatness. This would of course be decided and made clear before the jam starts.
Personally I would like this. My arguments for this are:
All in all, I think it would be a fun idea and create a bit of "spirit"! For those of you who think that it would be too "serious" and too "competitive", keep in mind that the vote/competition part of it wouldn't necessarily have to be serious and something big. Just a fun addition. It would still mainly revolve around making games with SFML.
A possible drawback is that it creates more maintenance load on the arrangers since they have to also organise the voting and whatnot related, and at least this time around, time was of a concern for many people involved. However, I think that whoever decides to arrange the next jam, ought to make sure they have time for it, so then it could be okay.
What do others think?
I want to raise a question that I don't think have been discussed yet. Should future game jams be voting/winner based?
What I mean by this is that all submissions are voted upon after the jam time is over. After the voting period is over, the results are shown and the one with the most votes win. Votes could be made on the basis of enjoyment when playing/theme relevance/concept or even possibly things like code neatness. This would of course be decided and made clear before the jam starts.
Personally I would like this. My arguments for this are:
- It would serve as a motivator to make the games more fun/polished. This is good since the final results could become a bit more attractive both for the participant to show others, and also for the SFML community to show outsiders.
- It would turn the current post-deadline anticlimax to an event with a resolution and a conclusion. The two last jams (this one especially with so few participants
) ended very anticlimactic imo. The results are in, and some people try them out, people talk a little bit about it and then that's it. A voting evaluation would make it feel more complete. - It would create more incentive to provide builds for various platforms. This is related to the previous discussion on providing binaries. When you want to attract votes, it makes sense to make it playable for as many people as possible. The drawback with this argument though is that people who are not able to provide binaries for popular platforms might be at an unfair disadvantage. This is also irrelevant if there would be a build service provided for the jam entries.
All in all, I think it would be a fun idea and create a bit of "spirit"!
For those of you who think that it would be too "serious" and too "competitive", keep in mind that the vote/competition part of it wouldn't necessarily have to be serious and something big. Just a fun addition. It would still mainly revolve around making games with SFML.A possible drawback is that it creates more maintenance load on the arrangers since they have to also organise the voting and whatnot related, and at least this time around, time was of a concern for many people involved. However, I think that whoever decides to arrange the next jam, ought to make sure they have time for it, so then it could be okay.
What do others think?