1
Graphics / Strange behaviour if RenderWindow is initialized last
« on: February 18, 2012, 03:39:23 pm »
Yes, 3.2.6 Kernel, 64bit, Intel GM965 gfx chip
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.
Pages: [1]
2
Graphics / Strange behaviour if RenderWindow is initialized last
« on: February 18, 2012, 03:27:32 pm »
There are two demonstration programs:
1) Working
2) Not working
...and screenshots showing the result of their execution:
1)
2)
The only difference between these two programs is that in the second Texture and Sprite objects are created and initialized BEFORE RenderWindow.
I expected that there would be no difference when initializing RenderWindow after the creation of resources, since they do not look interconnected until the drawing, but after asking on #sfml IRC channel I've been told that it's a matter of context, which is created when a window is initialized. So, in doubt if this is a bug or not, I'm posting my "discover" here.
What you think about this?
(Running under Arch Linux with 3.2.6 kernel, 64bit with Intel GM965 graphics chip)
1) Working
2) Not working
...and screenshots showing the result of their execution:
1)
2)
The only difference between these two programs is that in the second Texture and Sprite objects are created and initialized BEFORE RenderWindow.
I expected that there would be no difference when initializing RenderWindow after the creation of resources, since they do not look interconnected until the drawing, but after asking on #sfml IRC channel I've been told that it's a matter of context, which is created when a window is initialized. So, in doubt if this is a bug or not, I'm posting my "discover" here.
What you think about this?(Running under Arch Linux with 3.2.6 kernel, 64bit with Intel GM965 graphics chip)
3
General discussions / A new logo for SFML
« on: January 11, 2012, 11:45:56 am »
Like the gears, but don't like device icons at all.
Haikarainen version is beautiful, but does not resemble the concept of SIMPLE and FAST. And at first look, the impression is that we're talking about a complete engine, not a SIMPLE (!) library.
Another minus is that device icons aren't original. It's a drawback, as for me, and the first time I went on SFML website, I instantly noticed that icons are "stolen", even if they are in public domain. This kind of "theft" is ok when someone is customizing his desktop with a icon theme, but it's not acceptable for a logo, in my opinion, which has to resemble the project it represents.
Look at Qt toolkit. It is by far more complex and provides a huge functionality, think how many icons could they put in their logo... But they've chosen a simple green icon, and it is clear as the library itself. And if miniaturized, it still looks nice.
Like a lot Cuban-Pete, Brendon, jmglez and Cpl.Bator styles, as for me, they have to work a little more on their ideas...
Haikarainen version is beautiful, but does not resemble the concept of SIMPLE and FAST. And at first look, the impression is that we're talking about a complete engine, not a SIMPLE (!) library.
Another minus is that device icons aren't original. It's a drawback, as for me, and the first time I went on SFML website, I instantly noticed that icons are "stolen", even if they are in public domain. This kind of "theft" is ok when someone is customizing his desktop with a icon theme, but it's not acceptable for a logo, in my opinion, which has to resemble the project it represents.
Look at Qt toolkit. It is by far more complex and provides a huge functionality, think how many icons could they put in their logo... But they've chosen a simple green icon, and it is clear as the library itself. And if miniaturized, it still looks nice.
Like a lot Cuban-Pete, Brendon, jmglez and Cpl.Bator styles, as for me, they have to work a little more on their ideas...
4
General discussions / New naming convention
« on: January 11, 2012, 11:23:13 am »
I'm also a Qt user, and love its naming convention and consistency. As a new SFML user I found a little strange the FuncIsCapital() convention, and now absolutely love the change.
As of my experience, the main advantages of this naming convention are:
As of my experience, the main advantages of this naming convention are:
- There's a clear difference between member functions (methods), functions in general and classes, enums.
- funcName() is shorter than func_name()
- funcName() is readable as func_name() but not so horrible
5
Graphics / Pre-rendered images vs OpenGL transformations
« on: January 06, 2012, 01:34:03 am »
I have a nooby question. Say, I want to create and animate an UFO sprite (a circular object with some details on it). And I want to let it rotate around its center. Coming from SDL experience, I simply pre-rendered in Blender the rotation animation into several images (48 pieces), and displayed a different one on each frame. But we're hardware-accelerated here, so I simply loaded the first frame, set up the origin on center and called Sprite::Rotate() on each update. It looked a bit ugly, so I turned on smoothing on Texture object, and it looks almost perfect. The question is, which of two methods is faster? I'll have a lot of UFOs, asteroids, debris and stuff like that, ignore the memory consumption of the first method, is OpenGL-variant good enough to handle a lot of this kind of stuff without a heavy performance impact? I know it depends on machine, and I'd like to be able to run my game on integrated GPUs and stuff like that... Thx in advice 
Pages: [1]