SFML community forums
General => General discussions => Topic started by: Laurent on March 01, 2011, 09:02:22 pm
-
Hi
The fix is finally implemented, it's a shame it took me so long because the code is really really straight-forward. Well, it involves a major design modification that I don't really like, that's why it was not implemented before. So it's not a magic fix, it's a new design that allows SFML to get rid of this bug.
But anyway. This API change adds a new class, which is in fact nothing more than sf::Context. But now it is required in the main thread as well (unless you create a render target first). And I need you to... find a name for it :D
I don't like sf::Context because it's not meaningful at all. It refers to an implementation detail that most users (especially beginners) won't understand. This class must be used to enable graphics calls in a thread -- so I guess its name should refer to the Initializer/Thread/Graphics words. I really have no idea, so please help me ;)
Here is an example:
void func()
{
sf::???? ???;
sf::Image image;
image.LoadFromFile("...");
...
}
int main()
{
sf::??? ???;
sf::Thread t(&func);
t.Launch();
sf::RenderWindow window;
...
return 0;
}
After we all agree on a perfect name, I'll commit the fix, let you test, and try to boost my motivation to release SFML 2 soon. Even if it means dropping the changes I wanted to make on the drawable system.
I'll clean the task tracker as well, and *really* start to use it: I'll put there all the remaining tasks for SFML 2 (the real ones), all bugs, suggestions, etc. that were collected in my private text-file-todo-list.
-
What about http://www.sfml-dev.org/forum/viewtopic.php?p=27685#27685 ? It comes to my mind we could also use some macro and keep everything like it is now. (Maybe I'm missing something, I hope not!)
// in SFML/Window.hpp
#define main _sfmain
// in some Main.cpp (on the SFML side)
int _sfmain(int, char**);
int main(int argc, char** argv) {
// some stuff
int returnCode = _sfmain(argc, argv);
// some stuff
return returnCode;
}
// in the user's project
#include <SFML/Window.hpp>
int main(int, char**) { /* classic stuff */ return 0; }
The only downside I see with this is that the main (in the SFML-user project) must be of the form int main(int, char**). But maybe this could be managed with some kind of trick ?
EDIT : ok, I see another side effect : how will this work with Qt ?
-
Yeah, using a custom main is not an option. There are too many situations where you can't "control" it (plug-in, integration to an existing GUI, conflict with libraries that use the same technique, ...). And it only solves the problem for the main thread.
-
That what I was missing. :lol:
(I've no good idea for the name)
-
Will it be used for anything (as in called by the code)? Or is it just a static object that needs per-thread existence?
-
It is just a static object that needs per-thread existence. It will have a constructor, a destructor, and that's it.
-
so I guess its name should refer to the Initializer/Thread/Graphics words. I really have no idea, so please help me
sf::GraphicsInitializerThread.
=p
More seriously : sf::GraphicsExtend, in the way you extend the graphic functionnalities to more threads.
-
Hi! (sorry for my English ^^)
sf::GraphicsRoot : because without it the rest can't stand up :p
sf::GraphicsInit : because we have to create it first.
sf::GraphicsContext : because without context we don't see anything :p
Or just ArtworkThreadInitialiser :D
*run far far away...*
With only the main thread we need this one? or it's just with more than one thread?
-
Just out of curiosity Laurent, what were the custom Drawable changes? I, for one, can wait until these changes are complete! :)
Do we need to cheer you on? :lol:
-
With only the main thread we need this one? or it's just with more than one thread?
You need it in any thread where you don't have an active render target, whether it is the main thread or a secondary one.
Just out of curiosity Laurent, what were the custom Drawable changes? I, for one, can wait until these changes are complete!
Would be too long to explain, and I don't want to pollute this topic. But you can probably find a discussion about it on this forum (I don't remember where it is, maybe it's on the french side).
The problem is that this thing is totally blocking me, so if I wait and wait and wait... SFML 2.0 will never be released.
-
If you want the name to be newbie-friendly, I would suggest you leave thread out of the name. Chances are, most will just use a single thread in their programs and be done with it. A blurb in the documentation about threading usage should be sufficient for the non-newbies. (or you could provide a typedef that gives a TLS-name for those wanting to be specific that it's for multi-threading use, since you require one per thread).
I understand why it's difficult to name it - since it's just an object that needs to exist - but not actually used for anything else.
I would probably call it something with Rendering, rather than Graphics. Or add Enabler at the end.
sf::Renderer;
sf::GraphicsEnabler;
sf::RenderingContext; (or sf::GraphicsContext works well too)
Or if you really want Thread in there:
sf::RenderingThread rt;
sf::GraphicsThread gt;
Avoid Initializer - it's darn hard to spell right.
Or if you want to appeal to newbies:
sf::GraphicsSingleton s; // and a sf::GraphicsThreadSingleton typedef. ;)
;)
-
What about a simple "sf::Init"? Or "sf::Start"? It's more like a function name than an object name, but I think it's the easiest to understand in a first tutorial :o
-
Yes, I agree with Mjonir, Sf::(Draw?)Init is the easiest to understand solution.
-
I'd like to keep full words, this is one of my coding rules. So we'd be back to sf::Initialize(r).
-
What about a global function like sf::Init() ?
-
It can't be a function, it needs to be a RAII class so that the automatic destruction performs the internal cleanup.
-
I'd like to keep full words, this is one of my coding rules. So we'd be back to sf::Initialize(r).
I have the same rule :D
I think just "Initialize", "start" or "Render" won't be good for newbie, because they need to know what they init with it.
It's an action and we need to know on what this action ,... "act" and here we just create something so a verb (alone) is not a good idea I think.
Maybe somthing like "sf::InitializeRender" will be better than just "sf::Initialise"
Or much like say Devlin
sf::GraphicsEnabler;
or sf::Draw(ing)Enabler;
After all It's an objet that let us "Draw" something without an active render target.
And sorry for my english :s
-
After all It's an objet that let us "Draw" something without an active render target.
Nop. If you draw then you have a render target, so you don't need this class. This is more for loading images etc. before creating your render target.
-
sf::InitialContext;
sf::BackgroundContext;
Could be suitable in that case.
-
Perhaps sf::ThreadLocalContext? Even though "context" may be not clear for beginners, it's probably the most general and exact notion...
-
Perhaps sf::ThreadLocalContext? Even though "context" may be not clear for beginners, it's probably the most general and exact notion...
I agree that this name is a perfect match according to what the class does. However I'm not convinced, it looks too complicated/technical to me. But I guess there's no perfect name for it, I'll have to find a compromise.
-
Oups yes i'm not actualy in graphic and made a mistake in my mind :oops:
Perhaps sf::ThreadLocalContext? Even though "context" may be not clear for beginners, it's probably the most general and exact notion...
I agree.(and will probably name my variable with "context")
Newbie will realy use sfml and graphics without any RenderTarget?
A window, It's the first thing that many tutorial I have seen, show to start.
A good doc with an simple explanation to beginner is more helpfull that just a name that can say something else in an other lib. (personnaly a use more technical/generic name for class name and use a variable name that show what i do with it in actual context)
something like this in doc :
// Create the main window
// If you want to work on graphics without having any RenderTarget(like RenderWindow, RenderImage,...) you have to create an instance of sf::???????.
// ex: sf::ThreadLocalContext BackGroundGraphic.
sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window");
Will more help me that just the name of this object and i have both technicaly name and meagningfull explanation of it.
If I begin, I just need this and if I want to know more I can see the doc for more detailled explanation.
Or search on web these term : thread, Context.(and if i'm not english BackGround :D)
-
Will that also fix the thread related problems, like loading renderImage in different thread? :p
-
Will that also fix the thread related problems, like loading renderImage in different thread? :p
It's not supposed to solve anything else than the ATI crash. It's the same as before, except that there won't be a global context in the main thread anymore.
But let's focus on the name, I'll open a new topic for tests/comments/questions ;)
-
Well... we're dealing with a graphic context (meaning an environment where everything is ready to do graphics, not especially the "OpenGL meaning") and threads...
Thus.. I'd use something like GraphicContext and nothing more. I wouldn't add any information about the thread because I suppose that someone dealing with graphics and threading would probably know a little bit about threading and would understand that a graphic context is local to a thread. Anyway, that would be explained too.
-
sf::GraphicContext sounds good.
By the way, GraphicContext or GraphicsContext?
-
Uh.. I dunno :lol: . I suppose it could be both, I'll let you choose :P .
-
Sometimes the simple terms are the best :)
I suggest GraphicsContext, since 1. the SFML module is called Graphics and 2. it's also "graphics card", "graphics processing unit", "graphics software" etc. (And of course 3. it's easier to pronounce :D)
-
I'll go with sf::GraphicsContext for now, and... I can still change it later if someone has a better idea ;)
But at least I can go on now.
-
sf::GraphicsContext or sf::RenderingContext would work. Though you could replace Context with Environment instead if you want it a bit more nooby friendly.
What you also could do is typedef if you want to have a newbie friendly name and a more accurate name as of what it does.
Though the thing is, can't you put in more functionality into it somehow? Maybe like extract what graphics card is being used or something like that. Just having an object exist feels inappropriate. If some functionality like that is put into it then Environment would be a perfect fit also give it a more logical existence.
int main()
{
sf::RenderingEnvironment re;
std::string someManufacturer = re.GetGraphicsCardManufacturer();
std::string someModel = re.GetGraphicsCardModel();
return 0;
}
Just an idea and is actually a useless functionality but would give the context/environment object some more use than just sitting there looking pretty.
Just came up with a use of this, if you can get a hold of the drivers version number, you can do a check-up and look if the drivers are old and warn the end user to upgrade his drivers. League of Legends does that when you enter a new game.
-
But at least I can go on now.
And everyone stood up and /cheered you on! :)
-
Though the thing is, can't you put in more functionality into it somehow? Maybe like extract what graphics card is being used or something like that. Just having an object exist feels inappropriate. If some functionality like that is put into it then Environment would be a perfect fit also give it a more logical existence.
Could be confusing, people would focus on these members (because they are the only ones) and forget that the main purpose of the class is to create a valid graphics context.
Moreover, they wouldn't get these features with "regular", contexts created through sf::Window.
Just came up with a use of this, if you can get a hold of the drivers version number, you can do a check-up and look if the drivers are old and warn the end user to upgrade his drivers. League of Legends does that when you enter a new game.
Hum... Assuming that I leave the definition of "tool old" to the end user, and simply provide the version number, it's already quite difficult.
Maybe I can get something interesting with glGetString, but then it would probably require parsing the result according to the graphics card vendor.
-
Hum... Assuming that I leave the definition of "tool old" to the end user, and simply provide the version number, it's already quite difficult.
Maybe I can get something interesting with glGetString, but then it would probably require parsing the result according to the graphics card vendor.
I didn't expect more than that. I didn't expect you to parse it or decide what version number is old. That would be up to the end-user. Because let's say we have an application that is tested and works with version xx.yy.zz of the ATI drivers. Then we would say that anything lower than that is an "old" driver even though that version that we have as reference point is not the newest.
-
@Groogy: Sounds more like an extension rather than core functionality - to be honest.
-
Might be so, I was just trying to come up with something that would fit.