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

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.


Messages - Groogy

Pages: [1] 2 3 ... 89
1
Graphics / Re: Each target with its own context
« on: January 18, 2016, 02:12:20 am »
you can't share VBO's either, which is a problem because it means in my experiment I have one VBO of the same data for each RenderTexture it is going to be rendered to.
I don't get why you think VBOs aren't shareable... Like I said, I've done it many times and it is documented all over the internet, such as here. If binding a VBO in a different context is failing for you, then I can only assume there is something wrong with your code.

From that page: Any object sharing must be made explicitly, either as the context is created or before a newly created context creates any objects.

edit: Believe the explicit sharing between contexts are done with the wglShareLists in Windows and the other OSes has their own functions for it.

And with the current implementation of SFML if I attempt rendering a VBO created in the Windows context on a RenderTexture it fails on the binding because it has not been explicitly shared. My post renderer is an example of where I encountered the problem. If I do not create a VBO for the currently active context, it simply will refuse to bind the VBO. Also notice how I have to fumble around with activate A LOT to make this work in a frankly quite simple 2D application.

(click to show/hide)

So... how are thread-local contexts supposed to support drawing to a RenderTexture in a different thread than the one it was created in? SFML in its current form already requires the user to manually deactivate the RenderTexture's context before moving it to another thread. Your implementation just prohibits moving it at all. I don't see how this is supposed to be better...

This just makes the problem I tried to fix in my PR much worse...

I sincerely suggest you think this through a bit more...

It really doesn't, I remember back in the day I helped a ton of people because of the current "hidden behind" system of contexts messed stuff up for them. My suggestion would ensure an ad-hoc context(which currently is what we have but really bad) to make sure it always works but still allow the user to himself define the context he wants to work with himself because if he is doing that he is probably going to know better than the library does what he wants to do with his context. So So with my example it would guarantee and create a more flexible interface and management of contexts.

Example of creating a render texture and rendering to it in a different thread. The main point of the change is that it will make the user aware of contexts and their relationship with threads which right now is hidden. But like you say yourself, they themselves must still be aware that they need to disable a context in old thread before they are allowed to use it in the new one.

int threadfunc()
{
  threadData->aRandomContext.setActive();
  // do graphical stuff
}

int main()
{
    // Setup application and stuff
   aRandomContext.setActive(true);
   // Do graphical setup stuff
   aRandomContext.setActive(false);
   // start thread
}
 

If the user messes up and forgets to disable the context, he would still end up in the exact same state as with how it works today. The difference here is that he is explicitly made aware of contexts relationship with the thread and if he wants to do a multi-pass post process of the scene then he can do that without constantly switching contexts as well. Or the user just don't care and rely on the underlying system like always.


edit: I am kinda detecting a snarky tone with the whole "create a context for every thread even if no rendering is done" is kinda unnecessary hyperbole. Is my proposition threatening you somehow? For one I gave a quick example to motivate the behavior I found desirable by the library and not the actual implementation of that behavior. Obviously you would lazy allocate the context and your remark can only be seen as an active attempt of degrading my argument. If it is going to be like that we might as well end the conversation. I'll implement my own branch then and keep it to myself.

2
Graphics / Re: Each target with its own context
« on: January 18, 2016, 01:11:00 am »
you can't share VBO's either, which is a problem because it means in my experiment I have one VBO of the same data for each RenderTexture it is going to be rendered to.

And yes you would need to have one context per thread but that is achievable by using a global thread-local(lol) variable than by having several contexts per thread. Everything you described is still achieved and nothing lost. You still won't be able to bind buffers(VBO, FBO, etc.) that are not associated with the current active context.

The idea of that the render texture would guarantee thread safety is not true, OpenGL does that anyway all we have to guarantee is that a context exists and the user won't notice the difference. The only "promise" that would be broken is that the interface is made simpler since the activate function becomes obsolete.


All the code to make it work is already in place in the library and just top of my head something in style with this should be simple enough and eliminate need of FBO specific contexts making the code simpler to maintain but still provide the same flexibility as before where the user can have his own contexts that are not created by render targets.
// C++11 specific example
#include <threads.h>
thread_local sf::Context globalThreadContext;

void ensureGLContext() // called by functions that need an active context
{
    sf::Context* activeContext = sf::Context::getActiveContext();
    if(activeContext == nullptr)
        globalThreadContext.setActive();  
}
 

edit: realized the active context function would have to be a thread-local one as well, which it probably is already I hope? Or else it's kinda bad since it doesn't mimic OpenGL behavior then.
edit2: Yes it is with a SFML's own thread local pointer object.


Also with this you get the added choice of the user deciding what context to use at all times. If he want he can keep one context for the entire application regardless of threads. (create everything in main thread when loading then switch context ownership to render thread, etc.) The current system kinda forces you to work around the system and is quite rigid.

3
Graphics / Each target with its own context
« on: January 18, 2016, 12:19:53 am »
Hey! Long time since I've been posting here but if I am gonna return might as well return with some nagging :D

Anyway so been playing around with SFML lately on my free time and noticed that each render target is its own OpenGL Context. I think it has always been like that but I noticed an issue with it because of it. Because of them being their own individual context it means that you can't share certain buffers between the different render targets, stuff like VBO's.

Wondering if that could be up to debate for changing in the near future? There isn't really any reason as far as I can see that the FBO's under the render texture can't rely on the Window's opengl context. If I remember correctly when render texture was first implemented this was done as a lazy way to ensure there will always be an active opengl context. Though Laurent will have to correct me on that one since that's years ago.

4
General / Reviving rbSFML
« on: October 18, 2015, 12:52:38 pm »
Hey! Long time since I wrote here but felt it was time to return. I am currently in the process of reviving rbSFML and rewriting the binding from scratch to clear out a lot of old errors that had been made and make maintenance of the library less time-consuming so I don't have any excuse anymore to not keep it updated  ;D

The new revived version can be fetched for now at: https://github.com/Groogy/rbSFML/tree/rebirth

I have only implemented sfml-system in the new branch, the configuration files are just done as "just to work" and I have only tested this so far with Matz Ruby Implementation and on Windows. 

So far not the most interesting but I felt like I should put up a life pulse of the project that it is being reanimated from the dead. In this implementation I am also making my own binding language as I felt Rice wasn't good enough so when rbSFML is done, writing C++ additions to it to expand with your own stuff should be pretty easy.

5
General discussions / Re: SFML Game Development -- A book on SFML
« on: March 19, 2014, 12:05:04 am »
I couldn't wait to get this book and bought the kindle edition. It is ok on the kindle, but I'm going to buy the hard copy when I can because I like to make notes. This is a great book that I am enjoying reading!

Love to hear that you enjoyed it :)

6
Graphics / Re: Bullet Tracers
« on: March 09, 2014, 05:08:24 pm »
You could do streak effects, I think there was a tutorial somewhere here on the wiki, perhaps it was the old wiki. but the best I could find was from the Ruby forum where they do a flame effect

http://en.sfml-dev.org/forums/index.php?topic=3475.msg23739#msg23739

Basically what you do is that you create segments as the bullet move and these together form a line. It would be much more efficient, reliant and better looking than particles if the effect you want is something like this:


7
General discussions / Re: Simplifying SFML
« on: March 06, 2014, 10:54:46 am »
As much as I tried, but I find your code extremely hard to read. :|

Yeah I have to agree, the code was really hard to follow, not from its complexity but from the coding standard you have.

I think the problem you reached with several windows is that each window is its own context.
how do you mean though one at a time? Did you try to render to each window in its own separate thread?
Because correct me if wrong but I think that isn't supported until OpenGL 4.x and DirectX 11

Also to me it just looks like you've made a MVC-Architecture with a lot of restrictions to it. Having something like that in the base of SFML would just restrict people in how they do something. Since SFML isn't an engine I don't see a need for that.

8
General discussions / Re: SFML Game Development -- A book on SFML
« on: March 05, 2014, 04:43:43 pm »
We were trying to give a broad view of structures and patterns that you use and have a kind of exercise to use them. Like Nexus said, instead of just blindly adopting something we showed the strengths and weaknesses of everything.

You don't have to imagine a similar structure, there is no need to reinvent the wheel when it comes to stuff like this. Most often if you conform with a design pattern or similar the code will end up much better and cleaner.

I have been using SFML since I went to Highschool, so I guess that is about 6 years as well for me I think. C++ for much, much longer. Though I have to honest to say that Nexus skill in the new standards of C++11 were completely new to me and I loved that he actually pushed forward that we used that because I learned so much.

9
General / Re: Not Run!
« on: February 27, 2014, 09:55:46 am »
If you followed the tutorial for codeblocks, referring to this picture right here:



You should do essentially the same, but add glew to the list. If that still doesn't work it means codeblocks can't find GLEW on your computer, you will either need to install it with your linux package manager or add the path to it.

The tutorial in question is the Codeblocks one for Windows but it should work almost the same. http://www.sfml-dev.org/tutorials/2.1/start-cb.php

10
General / Re: rbSFML
« on: October 12, 2013, 10:16:48 pm »
The binding has a lot of shortcomings and has gone out of date. I want to work on it but have a hard time finding time for hobby projects outside my job. But I have recently moved stuff around so my weekends are free, hopefully I will pick this up again as the project is really important to me.

11
General discussions / Re: SFML Game Development -- A book on SFML
« on: July 29, 2013, 08:49:56 am »
It is awesome to see you invent new stuff with what we provide. Though wondering, is it not possible to make the scene graph into the actual quad tree? The branch nodes would simply be scene nodes. It might be a bit more work though but would be nice to not have two structures refer to the objects.

12
General discussions / Re: SFML Game Development -- A book on SFML
« on: July 28, 2013, 02:40:23 pm »
The book covers how to not just send packages but how to actually utilize it in your game as well :)

Hope you will enjoy the book!

13
General discussions / Re: SFML Game Development -- A book on SFML
« on: July 20, 2013, 01:10:51 pm »
I've done a commit now, let me know if this works. Sorry it took such time but I was on the train and didn't reach my destination until midnight.

doing an proxy function in the sub-class Aircraft is more unclean fix and is more or less forcing your class to work with the tools rather than have the tools fit the task at hand. Kind of like using a screwdriver to hammer in a nail. So instead it's swapped for a boring lambda function:

Code: [Select]
data[Pickup::HealthRefill].action = [] (Aircraft& a) { a.repair(25); };It doesn't look as good as the std::bind function and it's kind of hackish, but it is the better of the two.

Also fixed the dumb warnings for VC++11 when you have a switch-statement and cover all possible results.

14
General discussions / Re: SFML Game Development -- A book on SFML
« on: July 19, 2013, 12:01:23 pm »
They are related from what I remember.

Looking from the source in Laurents repository, something must have gone wrong because I can't find the fix in the code. When I get home I'll check where it went. In any case, fixed version will be up today.

15
General discussions / Re: SFML Game Development -- A book on SFML
« on: July 19, 2013, 10:52:53 am »
This problem is what I mentioned earlier, a bug in the new compiler from Microsoft. I did some fixes and got it to compile I'm gonna check what happened, could be that those fixes disappeared along the way somehow.

Pages: [1] 2 3 ... 89