1
Feature requests / Re: Stereoscopic Rendering
« on: January 10, 2015, 06:21:35 pm »
Any update on this?
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
General discussions / Re: SFML 3 - What is your vision?
« on: April 30, 2014, 10:15:04 pm »
Haven't logged in in a long time, but this is important to me since I love SFML as a library, but meta-topics keep me and my team from using it at work.
What's an absolute must is cross platform support that also covers mobile platforms, namely android, ios, and windows phone. Would be helpful if you went a way similar to Cocos2D, which now includes a cross-platform project management and build tool, but I guess that's never been the focus of SFML so I don't suspect you will look into it.
What's an absolute must is cross platform support that also covers mobile platforms, namely android, ios, and windows phone. Would be helpful if you went a way similar to Cocos2D, which now includes a cross-platform project management and build tool, but I guess that's never been the focus of SFML so I don't suspect you will look into it.
3
Window / Re: OpenGL context resource sharing
« on: September 03, 2013, 09:04:44 pm »Which version of SFML are you using? Can you show a complete and minimal code that reproduces the problem? Have you tried a glFlush() at the end of the loading thread?
2.1
glFlush won't solve the issue. The resources are loaded and available (checked with gDebugger) when the main thread wants to access them.
Minimal code that reproduces the problem... ughh. I have to write boilerplate opengl again
. Not today, I'm in super lazy mode since Rome 2 was released. But I'll post something tomorrow.You know, I just rembered that I don't set the same pixel format with sf::ContextSettings when I create sf::Context instance. This is required in windows, I think (unless sf::Context takes care of using the settings of the main context somehow), otherwise it won't recognize the context's as shared. I'll try it out tomorrow, now I need to conquer Carthage.
4
Window / Re: OpenGL context resource sharing
« on: September 02, 2013, 08:06:37 pm »
Have you tested this on both windows and linux?
It doesn't seem to work for me. When I create the resource in question in a secondary thread, the main thread doesn't render it (I've gone through the code a dozen times now, the rendering logic is correct, just nothing shows up on screen). When I "pre-load" the resource in the main thread, it renders as expected. The main thread just starts a window at the start of the application, and the secondary thread just puts a sf::Context context; in a place where it stays until the thread is shut down (which doesn't happen until the end of the application).
The secondary thread still creates the resources correctly (I've checked with gDebugger), but for some reason when the main thread renders using those resources nothing shows up.
It doesn't seem to work for me. When I create the resource in question in a secondary thread, the main thread doesn't render it (I've gone through the code a dozen times now, the rendering logic is correct, just nothing shows up on screen). When I "pre-load" the resource in the main thread, it renders as expected. The main thread just starts a window at the start of the application, and the secondary thread just puts a sf::Context context; in a place where it stays until the thread is shut down (which doesn't happen until the end of the application).
The secondary thread still creates the resources correctly (I've checked with gDebugger), but for some reason when the main thread renders using those resources nothing shows up.
5
Window / OpenGL context resource sharing
« on: September 02, 2013, 06:07:19 pm »
Assuming I have some secondary threads and one main thread that runs the window.
Is it enough to just create the window in the main thread, and instantiate sf::Context once per secondary thread in the respective thread? Will the active context of the main thread have access to OpenGL resources created by secondary threads (i.e. if I create a texture in thread 2 and receive the name "42" for it from OpenGL, will the other threads be able to access it via glBindTexture(..., 42)?).
Is it enough to just create the window in the main thread, and instantiate sf::Context once per secondary thread in the respective thread? Will the active context of the main thread have access to OpenGL resources created by secondary threads (i.e. if I create a texture in thread 2 and receive the name "42" for it from OpenGL, will the other threads be able to access it via glBindTexture(..., 42)?).
6
Window / Re: Xbox 360 Controller button/stick mapping
« on: September 02, 2013, 06:05:00 pm »
Yeah, but it has received a lower priority now. Was megalazy and just implemented keyboard + mouse control. Will come back too it soon(ish).
7
Window / Re: Xbox 360 Controller button/stick mapping
« on: August 31, 2013, 12:19:48 pm »
well, for testing I have to write and app and press buttons, but since I'm the first I'll do it later and post the results here 
8
Window / Re: Xbox 360 Controller button/stick mapping
« on: August 30, 2013, 08:53:09 pm »Why don't you just test it?
I don't want to reinvent the wheel.
9
Window / Xbox 360 Controller button/stick mapping
« on: August 30, 2013, 08:42:01 pm »
Does anyone happen to have a list of which buttons and sticks on the 360 controller correspond to which buttons/axes in SFML?
10
General / Stack corruption bug with sf::Shape
« on: November 18, 2012, 10:30:45 pm »
I posted this in General since it might be a VS2012 bug.
Basically, in any function that looks like this:
The code will crash upon exiting the func() function, because foo creates a stack corruption. This is with Visual Studio 2012, standard compiler, SFML2 RC (downloaded like a week ago).
It should be noted that the same happens when I used a dynamically allocated shape that I delete at the end of the function. But instead of a stack corruption, it will be a heap corruption, of course.
Any idea what could be the cause of this?
When debugging, it seems like the shape isn't initialized correctly. The vectors inside the attributes of sf::Shape have weird sizes (e.g. 6 and 12) and the values of their elements seem like "undefined behavior' kind of values.
Basically, in any function that looks like this:
void func()
{
sf::RectangleShape foo; //can be any kind of shape
}
{
sf::RectangleShape foo; //can be any kind of shape
}
The code will crash upon exiting the func() function, because foo creates a stack corruption. This is with Visual Studio 2012, standard compiler, SFML2 RC (downloaded like a week ago).
It should be noted that the same happens when I used a dynamically allocated shape that I delete at the end of the function. But instead of a stack corruption, it will be a heap corruption, of course.
Any idea what could be the cause of this?
When debugging, it seems like the shape isn't initialized correctly. The vectors inside the attributes of sf::Shape have weird sizes (e.g. 6 and 12) and the values of their elements seem like "undefined behavior' kind of values.
11
Graphics / Re: How does SFML 2.0 rendering works aka is it worth to change my code
« on: June 10, 2012, 10:50:54 am »
@Laurent
So there is some automated batching when drawing sprites directly?
Good, I thought you had to take care of the batching manually.
So there is some automated batching when drawing sprites directly?
Good, I thought you had to take care of the batching manually.
12
General discussions / Re: SFML on Mobile
« on: June 08, 2012, 09:56:25 pm »
Laurent, have you ever considered pulling outsiders into the project? It seems like your free-time is really limited, and SFML already is the best C++ 2D basics library for Windows/Linux/Mac, but it could be so much more. I think you could still do whatever you want to do with the library, you would just have additional help actually coding the features.
13
Graphics / Re: Changing the BlendEquation
« on: April 12, 2012, 12:25:18 pm »
I need them for a step in a 2D shadow generation algorithm (which is on the CPU). I can do that step without min blending, but that step is currently by far the largest bottleneck in the algorithm, and with min blending the algorithm I'm using will handle hundreds of lights at high framerates, because it's largely independent of light numbers, where the algorithm used in "let there be light" depends on the number of lights on the screen. Also, it's on the GPU and practically doesn't use up anything on the CPU at all, which is good since most 2D games are very simple graphically and the performance bottlenecks are usually in CPU algorithms.
I will probably also need it for blending together signed distance fields sometime in the future. A signed distance field is just an image where every pixel of the image contains the distance to the closest obstacle. These are very expensive to create, but you can pre-calculate the large ones for static objects in your world and then only compute small ones for your dynamic objects and blend them together using min blending, too.
I will probably also need it for blending together signed distance fields sometime in the future. A signed distance field is just an image where every pixel of the image contains the distance to the closest obstacle. These are very expensive to create, but you can pre-calculate the large ones for static objects in your world and then only compute small ones for your dynamic objects and blend them together using min blending, too.
14
Graphics / Re: Changing the BlendEquation
« on: April 12, 2012, 11:48:12 am »
GL_MIN.
edit: if this is not possible at all, I wouldn't mind making some custom changes to SFML. do you know which parts I'd need to change (optimally to encompass all drawables, not just specific ones like sprite or shapes)?
edit: if this is not possible at all, I wouldn't mind making some custom changes to SFML. do you know which parts I'd need to change (optimally to encompass all drawables, not just specific ones like sprite or shapes)?
15
Graphics / Changing the BlendEquation
« on: April 12, 2012, 11:10:20 am »
If I want to draw something drawable onto the screen/a RenderTexture and want to temporarily set the blending equation of OpenGL to something different, how would I go about doing it in SFML2?