SFML community forums
Help => Window => Topic started by: nomonkeybusiness on February 24, 2009, 01:32:45 pm
-
Hi all! I'm new to the forum, and new to SFML.
I am studying at Gotland University, where I study to become a game programmer. I have previously used SDL to build games, and I think I have a decent knowledge of C++.
Anyhow. I am just getting started with SFML, and I'm wondering wether there is a function similar to SDL's "SDL_GetError()" wich returns a const char*, containing a description of the last error that occured. So..is there?
Thanks
/Christoffer
-
Nope
-
Errors are written on the standard error output (std::cerr).
-
Yes, i just noticed, thank you ;)
-
While we're on the subject of comparing SDL and SFML.
I'm building a basic framework, and I'm having a "drawImage()" in my cRenderTools class.
Is there any way of obtaining the renderwindow to draw on, from an outside class without having to send it there via function arguments?
Like sdl's SDL_GetVideoSurface() ?
-
Is there any way of obtaining the renderwindow to draw on
And which one is it? In SFML you can have multiple render windows at the same time.
-
Oh. Didn't know that. Well, it seems kind of...not good to initialize a new renderwindow for the purpose of drawing stuff on, so a would like to obtain the main renderwindow, the one that I initialize in my cApp-class.
-
...not good to initialize a new renderwindow for the purpose of drawing stuff on, so a would like to obtain the main renderwindow, the one that I initialize in my cApp-class.
1. Make your own renderwindow derived singleton class for main render target and use something like this: MainRenderWnd::getInstance().whatever()
2. Use global variable if you are stuck at C style.
-
1. Make your own renderwindow derived singleton class for main render target and use something like this: MainRenderWnd::getInstance().whatever()
2. Use global variable if you are stuck at C style.
Uhm.. In my opinion both suggestions aren't really good. Singletons should be used *extreme* rarely. It's better to give references to a RenderTarget instead making everything dependent on that one singleton.
And second, do never ever use global variables. I'd be fine if C++ didn't allow them. ;)
-
And second, do never ever use global variables. I'd be fine if C++ didn't allow them. ;)
And global accessor?
-
Global accessors are global variables wrapped into an accessor function. :) Why don't just encapsulate stuff into something where it belongs to? Nothing needs to be "just there".
-
And how will you desing a game with Graphics. Audio, Network, Game engine without global accessor? All objects need to use these module and the simplest (and fastest) way to do that is via global accessor.
"Global" -> "Static" don't exist for nothing.
-
And how will you desing a game with Graphics. Audio, Network, Game engine without global accessor? All objects need to use these module and the simplest (and fastest) way to do that is via global accessor.
The fastest, no. The simplest, yes. But only in the short term. The dependencies you create can become your doom. For example graphics: You don't need them everywhere. Not at all. You can let a single or a few classes handle graphics and call their methods with logic parameters. Creating a sf::Sprite and instantly drawing it everywhere something needs to be drawn might be the wrong way...
"Global" -> "Static" don't exist for nothing.
Not for nothing. But backward compatibility is one of the reasons.
-
I would instead keep global variables in a namespace, you know like for things that don't need to be objects.
Like an ImageManager, though it needs two dynamic arrays to keep track of image and the name of image. Those I would keep global but only the functions within the namespace would be allowed to use them.
Like I have a "private" function in the namespace called "AllocData" that is not declared in the header file and it allocates the arrays. And thne the only function used outside is "sf::Image * GetImage(const char * name)". If your not going to use global here, would you instead place them in the GetImage function as a static variable?
I would say global variables is just a taboo by teachers and books. It's still Not everything needs to be objects, it only makes the application slower, so if it can be designed as not an object would be faster and better.
-
"Global" -> "Static" don't exist for nothing.
Statics don't imply being global, at least not being in any global namespace.
IMHO Nexus is absolutely right. You create a lot of dependencies, thus writing code that is far away from being modular. This is something that's often done wrong with games, in my opinion. Why should classes like "Weapon" or "Player" draw themselves? You should rather write classes that *use* those, e.g. for displaying or sending stuff over the network.
I would instead keep global variables in a namespace, you know like for things that don't need to be objects.
Nothing "needs" to be an object, but it's just more logical, especially in terms of object oriented programming. Why doesn't your ImageManager belong to something more specific? Like a Game class or Gamestate class or whatever? I can't understand why resource managers are just "there" and don't belong to anything. That's a reason why I dislike singletons, and your design is a kind of singleton.
I would say global variables is just a taboo by teachers and books. It's still Not everything needs to be objects, it only makes the application slower, so if it can be designed as not an object would be faster and better.
There's a reason why teachers and books (also good books, for example by Bjarne Stroustrup) teach you that you shouldn't use such designs. There's also a reason why you shouldn't use "goto". Mostly people just don't know the reason and think it's only a "programmer taboo", but it isn't.
Not everything should belong to an object, that's true, but only for modularity reasons. For example, you should not write overloading functions for operator<< using ofstreams as a member. And please show up where your method is somewhat faster than *elegant* C++ code. The difference is neglectable. And if you've got a reason to produce more dirty code, you can still do that when performance penalties occure, but not by pre-optimization.
-
Most programmers want things virtual in C++, kinda like aiming against what Objective-C or Ruby or any dynamic language provides. The whole function lookup process makes it slower. While when you stay with the original C version, it just binds the function to the symbol compiled in the executable.
And sure I agree Globals are bad, but they are very usable, and if used you should only have it as some internal things for a set of functions.
I think we've strayed off-topic.
-
Most programmers want things virtual in C++
Hopefully only when needed. Virtual functions are only needed for polymorphism. But yeah, most C++ programmers declare function virtual by default, which is a big no-no.
II think we've strayed off-topic.
True, but since the original question has been answered, I guess nobody cares. ;)