Messages

1

Graphics / Clear() doesnt clear Depth Buffer

« on: February 09, 2010, 04:04:09 pm »

Hi,
I was just about to do some SFML/pure OpenGL mixing. Found out that RenderWindow->Clear() does not clear the depth buffer. Not surprising, because a depth buffer is not in use
However, if I create my RenderWindow using the ContextSettings, and I set DepthBits to some reasonable value, I would expect Clear() to clear it, too.
No big deal, though.
boogi

2

Graphics / text.getrect() behaviour

« on: February 05, 2010, 10:52:31 am »

i may be wrong but i think that 1.5 didnt care about literals that exceeded the bottom line, it always returned the top-to-bottom-line-difference (which was to small for strings containing such literals).

I don't remember changing that, but maybe I did it a long time ago.

ok i looked it up and it seems that i was wrong, 1.5 and 2.0 have same behaviour on that one.

Anyway, this stuff will soon change in SFML 2, so don't worry and just wait and see

i actually fixed my problem, sf::text.getcharactersize() is a value that doesnt change on different literals and can be used for scaling the text. so i stopped worrying and started waiting and seeing

3

Graphics / text.getrect() behaviour

« on: February 05, 2010, 09:54:50 am »

any way to handle this? i am actually interested in the "bounding rect" that pretends to always have a preceding "j" in it the text.

But your text doesn't have this "j"
I can't make the bounding rectangle bigger just in case you type a "j" later.

But I don't understand why your edit box depends on the size of its contents? Isn't it supposed to have a fixed size?

it has fixed size. the sf::text is scaled so that it nicely fits into it.
i am not sure whether you noticed the inconsistency. sf::text.getrect() gives same height for "nnn" and "NNN" and ".....". but it gives bigger height for "nng". i may be wrong but i think that 1.5 didnt care about literals that exceeded the bottom line, it always returned the top-to-bottom-line-difference (which was to small for strings containing such literals).

4

Graphics / text.getrect() behaviour

« on: February 05, 2010, 08:44:23 am »

i checked out sfml2 and was wondering what happened to the sf::String class. took a while til i realized that its now split up into string and text. i think i like it that way, not sure yet
however, in my small imgui code that i wrote a while back i replaced all sf::string by sf::text and it pretty much works like it did, with a single exception: sf::text.getrect() takes into account if theres a literal that "goes through" the bottom line, like "y" or "g". so my nice little edit box that i am so proud of starts popping up if i hit such a literal, eg the box shows "nnn" and i add a "j". however, getrect() does not do the same on the upper half of the glyph, texts like "nnn" and "NNN" give same y-coordinates.
any way to handle this? i am actually interested in the "bounding rect" that pretends to always have a preceding "j" in it the text.

5

General discussions / Re: Strange math needed

« on: February 05, 2010, 02:25:55 am »

I found that I needed to divide the size of the sprites height by two for it to calculate correctly and to prevent the paddle from moving off the screen at all otherwise, perfectly half of the paddle would move off of the screen. I couldn't figure out why so anyone have ideas?

i think its just where the origin of your sprite is. obviously its in the centre of the sprite. so if you have 640x480 resolution, your paddle ist 100 pixel in height, and it moved down to y = 430: how much space is left on the bottom to move your paddle further down?

6

General discussions / Re: [Seeking] Easy 3d-model loading library

« on: January 30, 2010, 04:41:42 am »

Does anyone of you know a simple library to load 3d-objects ( 3ds, asc...)
and display them via OpenGL.

someone said in another thread that the horde3d enginge (http://www.horde3d.org/home.html) is easy to use with sfml.
another way would be to use AssImp (http://assimp.sourceforge.net/main_features.html)
i havent used any of them, but they should be able to do the job

7

General discussions / Re: SFML 1.6 released soon

« on: January 27, 2010, 01:31:53 am »

Is there anything that you would like to be improved/fixed in this release? Did I miss something?

Is refreshing while window resizing fixed yet?

8

General discussions / New strategy for the internal rendering code in SFML 2

« on: January 25, 2010, 02:54:53 pm »

So you would like me to revert to batching? What are your reasons? The new implementation is faster, simpler and removes a lot of bugs.

the reason is that i like your style. the library is really easy to use and this is what oop is all about - hiding away all the dirty stuff. and it would just feel right to have at least vertex arrays behind the scenes, because its an optimization that was introduced ages ago (wasnt it opengl 1.1?)
however, i fully agree with you that if it would make the use of the library more complicated, its not worth implementing it.
i cant tell yet what my solution would be for sfml, but as i can remember from former projects that vertex arrays boosted the frame rates quite a bit, even if i filled up the array buffers every frame. writing this, i feel like i should do some sfml opimization research...

9

General discussions / New strategy for the internal rendering code in SFML 2

« on: January 25, 2010, 01:19:19 pm »

So please before debating again and again, write some code and prove me that you have something better.

Can you give some specs about a benchmark that would convince you? I think drawing a background of 32x32 pixel tiles on a 1920x1080 resolution wouldn't convince you despite of outperforming the IM, because its not the "usual case". So what should a Move-Laurent-Back-To-Batching-Benchmark look like?

10

General discussions / New strategy for the internal rendering code in SFML 2

« on: January 23, 2010, 06:42:40 pm »

and 1.6 will be a bug fix release, right? a couple of weeks ago i read some thread where you wrote about text rendering in sfml2 and someone agreed that it has improved quite a bit. i actually dont wanna miss that out

11

General discussions / New strategy for the internal rendering code in SFML 2

« on: January 23, 2010, 06:23:16 pm »

i checked out the sfml2 from svn and i am wondering whether to use it for a new project or to stick to 1.5? when will there be some "feature freeze" or so that locks the api to what it is now?

12

General discussions / Re: New strategy for the internal rendering code in SFML 2

« on: January 21, 2010, 05:41:43 pm »

I've totally rewritten this part, and there's no batching and delayed rendering anymore. There's now just a render states cache, which gives even better performances than before.

wow, i didnt't expect this to hear for today. so this is the end of the batch rendering show? will there ever be any kind of va/dl/vbo support on sfml drawing functions?
boogi

13

Feature requests / string class enhancements

« on: March 25, 2009, 02:55:32 am »

hi!
i have seen in the roadmap that you plan to rewrite parts of the unicode and string classes for e.g. outlined text. if you do so anyway, you may consider some more changes - this is not a real feature request, just something to think about.

first of all, if you have unicode support all over the place, it may be useful to have the possibility to display strings in other directions than from left to right. that can help on i18n or making a label for vertical sliders/progress bars.

secondly, i have seen in a couple of games (namely quake3, warcraft3, trackmania nations) that they support colored names. color information are kept within the text by leading control symbols. besides colored names, it can also help making a single letter of a button highlighted (e.g. for the shortcut key that has same function as clicking on the button). its pretty hard to do that manually, the button text hast to be splitted up and drawn in parts one after another (or did i miss something out?).

however, as said above, smfl can very well do without those two changes - they are hardly worth mentioning (especially because both are kinda gui-related).

boogie :shock:

14

Graphics / sfml and irrlicht

« on: March 21, 2009, 07:51:26 pm »

hi laurent,
i would want to use the sfml library anyway (for sound, network, i/o), and want to use the irrlicht engine only for 3d drawing because of the scenegraph. so rather irrlicht is the optional library, not sfml.
irrlicht has its own gui, and as it looks like, its not the worst.
but i want to make some small immediate mode gui, and i like the sf::String class very much. its pretty much perfectly suitable, along with the sprite support that would skinning make easy.
maybe i should just try it out. is there a way to get the window handle out of sfml?
i think different opengl states may not be a problem, because the rendering can be done successively. first the 3d scene, then the gui. however, i have not much experience in opengl, so your opinion is definetly worth more...

boogie :shock:

15

Graphics / sfml and irrlicht

« on: March 21, 2009, 05:33:30 pm »

hi!
i want to use sfml and irrlicht, sfml for some gui elements, and irrlicht for displaying a mesh. i didnt try out to code it yet, so its pretty much a question in advance...
how do i proceed the best way?
shall i set up the window using sfml, and create an irrlicht context based on the window handle (how do i get it from sfml?) - or the other way around: irrlicht for window creation, passing window handle to sfml... (i've seen something like that on the wxwidgets tut or so)

boogie :shock:

ps: i think theres a french thread about that topic, i cant speak french tho