Topics

31

General discussions / IRC chat (70+ users)

« on: August 12, 2010, 01:01:20 pm »

WARNING: SFML nowadays is mainly using Discord. We have connected the IRC channel to the "General" Discord channel, however you'll be missing on a lot of chats on other Discord channels. Therefore I highly recommend to use the Discord server.

---

Greetings!

For friendly help and talks about SFML (and also offtopic chats), connect your fancy IRC client to the server below.

Host: irc.sfml-dev.org
Port (plain): 6667
Port (SSL): 6697
Channel: #sfml

32

Python / A little more abstraction

« on: July 09, 2010, 08:56:09 am »

Hi guys,

as I'm currently synchronizing PySFML to trunk (SFML2), I've realized that it'd be maybe a good point of time to bring in some more abstraction to PySFML.

As some of you maybe know, PySFML is directly created by using the Python C API. The advantage is no garbage and full control over the sourcecode.

However, maintaining such a library (which is getting bigger and bigger) just with the Python C API is a hard and sometimes annoying task, not speaking of the attention you have to pay, because many things can go wrong without even being recognized.

So my proposal is to bring in a higher level of abstraction for creating the binding. Personally, I've had made very good experiences with Boost.Python. Binding classes (or other types) to Python works with ease and is not as much error-prone as the direct approach (Boost.Python takes care of most of the internal stuff).

The drawback is that this throws in a dependency (Boost.Python) that's needed to build the binding library (it's *not* needed for using it). But I think it's worth it -- especially regarding to the time that can be saved by synchronizing PySFML to trunk.

So I really would love to hear your opinions about this -- won't make this step without acquiring vogue.

33

Graphics / Copying of sf::Fonts fails

« on: February 19, 2010, 03:22:30 pm »

Hey,

when copying fonts, the destination object is somehow invalid. I guess something doesn't get copied properly.

Minimal example:

#include <SFML/Graphics.hpp>

int main() {
        sf::RenderWindow  window( sf::VideoMode( 800, 600, 32 ), "Muh" );

        sf::Font  afont;

        {
                sf::Font  tmpfont;
                tmpfont.LoadFromFile( "whatever.ttf" );
                afont = tmpfont;
        }

        sf::Text  text( L"Foo", afont, 50 );

        window.Clear();
        window.Draw( text );
        window.Display();

        sf::Sleep( .5f );
}
 

Backtrace:

Code: [Select]

#0  0x00007ffff5cfd1d5 in FT_Request_Size () from /usr/lib/libfreetype.so.6
#1  0x00007ffff5cfd295 in FT_Set_Pixel_Sizes () from /usr/lib/libfreetype.so.6
#2  0x00007ffff76dfce4 in sf::Font::SetCurrentSize(unsigned int) const () from /usr/local/lib/libsfml-graphics.so.2.0
#3  0x00007ffff76e0d0f in sf::Font::LoadGlyph(unsigned int, unsigned int, bool) const () from /usr/local/lib/libsfml-graphics.so.2.0
#4  0x00007ffff76e109c in sf::Font::GetGlyph(unsigned int, unsigned int, bool) const () from /usr/local/lib/libsfml-graphics.so.2.0
#5  0x00007ffff76ec835 in sf::Text::Render(sf::RenderTarget&, sf::Renderer&) const () from /usr/local/lib/libsfml-graphics.so.2.0
#6  0x00007ffff76e785a in sf::RenderTarget::Draw(sf::Drawable const&) () from /usr/local/lib/libsfml-graphics.so.2.0
#7  0x0000000000402bd1 in main () at s.cpp:19

This happens in the line with "window.Draw()", but everything else that accesses the font's properties leads to this error, too.

SFML is version 2, revision 1412 on Debian GNU/Linux.

34

Window / Undefined ref to sf::Window::OnEvent()

« on: February 19, 2010, 01:46:20 pm »

Heya,

in the latest SFML2 revision (r1412) there's an undefined reference to sf::Window::OnEvent() when linking SFML.

r1400 works fine.


Greetings.

Oops, this was supposed to be written into the Window board.

35

Python / Tuple -> sf::Vector

« on: February 11, 2010, 03:07:58 pm »

Hey,

currently PySFML uses tuples for representing sf::Vector* objects. I discussed that with someone (pekuja) some weeks before (sorry for that, got less time ) and we came up with the idea to implement sf::Vector* classes in PySFML, too. There're mainly two reasons:

• Tuples are immutable, meaning you just can't change its elements. This is unfavorable because you often want to change only the x or y component of a vector without creating new tuples.
• Naming conventions would be better. Instead of pos[0] and pos[1] you'd have pos.x and pos.y

Open for comments.

36

Graphics / Messed up font texture (SFML2)

« on: February 11, 2010, 03:01:27 pm »

Hi guys,

I've recently discovered that the font texture gets somehow messed up. Look at this screenshot:



The lines are created after each other. When I don't add the last two lines (abcdef...), only the "v" in "Server disconnected" is missing.

5th line is lower-case, 6th line is upper-case. This happened to me at first with the default font, so I switched it -- just to say that it's not font-related.

37

Window / No rendering with joystick attached on Linux

« on: December 12, 2009, 01:17:37 pm »

Hey,

I've got a problem with SFML when I've attached my Saitek X52 Pro controller. When launching programs, nothings gets rendered -- or sometimes just the first frame.

When I disconnect the joystick, everything's just fine.

There're no error messages or crashes. The applications just doesn't respond anymore.

38

General discussions / SWIG

« on: November 23, 2009, 01:50:07 pm »

Hey,

as I'm currently working with SWIG, have you (Laurent) ever thought of using it with SFML?

39

Python / PySFML2

« on: November 23, 2009, 01:35:13 pm »

Hey,

is it possible for the maintainer to close up to SFML2? I did the most stuff myself, but got stuck with sf::SoundStream::OnSeek(), which is pure virtual.

40

Graphics / Blending of drawables with alpha on RenderImage (SFML2)

« on: October 28, 2009, 03:32:29 pm »

Hey,

I've just discovered a problem I can't solve. I'm drawing some sf::Strings onto an sf::RenderImage that got initialized with black full transparent pixels.

Now pixels of the strings having an alpha values are -- because it's alpha blending -- blended with the RGBA = 0, 0, 0, 0 pixels of the sf::RenderImage, resulting in not displaying those pixels at all.

Is there any solution available? I want the sf::RenderImage to be transparent except stuff that I draw on it.

41

Graphics / Maybe a problem with Rect intersections

« on: October 16, 2009, 12:44:21 am »

Heya,

as I'm currently in war with sf::Rect, here's another thing that came up into my mind when using Rect intersections:

Code: [Select]


sf::Rect  a( 0, 0, 1, 1 );
sf::Rect  b( 1, 1, 2, 2 );
std::cout << a.Intersects( b ) << std::endl;


Matter of price: What do you expect gets printed? Two possibilities here:

1. Rects do NOT intersect because b is next to a.
2. Rects DO intersect because b shares the upper left point with the lower right point of a.

If a and b of the example above intersected by definition, it'd mean that there's an intersection rect = (1, 1, 1, 1). If NOT, then I think it should be impossible to have rects with a size of 1 either in width or height -- which would be bad in my opinion.

The current implementation of Intersects() uses method 1, which can lead to serious problem. Imagine this case:

Code: [Select]


sf::Rect  a( 1, 1, 1, 1 );
sf::Rect  b( 1, 1, 1, 1 );
std::cout << a.Intersects( b ) << std::endl;


a and b are still valid rects (with width and height of 1; at least that should be the case. SFML currently calculates wrong sizes, but a bugfix is already in the pipeline as stated by Laurent in another thread) and should therefore (or better: must!) intersect because they're at the exact same position.

So my proposal is to use method 2 for intersection checks.

Edit: Regarding to a fix: I think replacing

Code: [Select]


    return (overlapping.Left < overlapping.Right) && (overlapping.Top < overlapping.Bottom);


in sf::Rect<T>::Intersects() by

Code: [Select]


    return (overlapping.Left <= overlapping.Right) && (overlapping.Top <= overlapping.Bottom);


would fix it.

Thus a new problem appears in the Intersects() method accepting an additional parameter for actually getting the intersection rect:

Code: [Select]


        intersection = Rect<T>(0, 0, 0, 0);
        return false;


Intersects() returns false indicating that no intersection happened. But (0, 0, 0, 0) is wrong in this case, as it would define an intersection rect at (0, 0) with a width and height of 1.

42

Graphics / Logical error with sf::Rect<T>?

« on: October 13, 2009, 01:29:56 pm »

Hey,

I'm just wondering about a behaviour inside the sf::Rect<T> class:

The method Contains() checks if a point is inside the rectangle, boundaries inclusive. But GetSize() returns a size without the right and bottom boundary.

So when I've got a rectangle from (0, 0) to (2, 2), then the points (x, y) are within that rect when x = [0, 2] and y = [0, 2]. Therefore I'm able to check for 3(!) points on each axis which means that the rectangle's width and/or height must be 3.

But since you return Right - Left (Bottom - Top) in GetSize(), I get a 2 here which leads to serious errors in my quadtree implementation.

43

Feature requests / Mouse position in MouseWheelMoved event

« on: September 22, 2009, 01:49:51 am »

Hey,

is it possible to add mouse positions to the MouseWheelEvent structure? This is currently only possible through sf::Input(). Unfortunately I don't have access to sf::Window::GetInput() where I need the positions.

44

Feature requests / Good old sf::View methods

« on: August 02, 2009, 07:31:59 pm »

Hey.

Before SFML2, sf::View got some methods like GetRect() and SetFromRect(). SetFromRect() is still available through the new Reset(), but GetRect() isn't. That's probably because of the underlying data storage, since you're saving the view's center and not the rectangle anymore.

Is it possible to have a GetRect() again or at least a GetPosition() and SetPosition()? For me, it would be easier for some map movements. I'm currently doing the calculations by myself (get the center and subtract half of the view's size), but would rather see it in SFML itself.

Greetings

45

Graphics / OpenGL bug? Nvidia driver bug? SFML bug? My fault?

« on: July 17, 2009, 12:56:12 pm »

Hi guys,

I've recently discovered a very disturbing "bug" -- if it's any. I'll try to describe the problem:

I'm using two threads in my application: the first polls SFML events, handles them and calls then another class (called "State") to render the scene. The second thread is inside that State class. It's launched when the State is created, waits a second and just creates an sf::Image and loads an image.

While the image gets loaded, it's possible that the first thread is just rendering the scene/clearing the window/displaying the contents.

So, my first question is: Is SFML threadsafe enough so that I don't have to manage that myself?

What happens is: when you start the program often enough (depends on luck, I guess...), it freezes. Backtrace:

Code: [Select]

#0  0x00007f8d9c74e1f4 in __lll_lock_wait () from /lib/libpthread.so.0
#1  0x00007f8d9c749acb in _L_lock_312 () from /lib/libpthread.so.0
#2  0x00007f8d9c7494d1 in pthread_mutex_lock () from /lib/libpthread.so.0
#3  0x00007f8d9dbff3c9 in ?? () from /usr/lib/libGL.so.1
#4  0x00007f8d9ac71d98 in ?? () from /usr/lib/libGLcore.so.1
#5  0x00007f8d9ac2caaa in ?? () from /usr/lib/libGLcore.so.1
#6  0x00007f8d9a8f133b in ?? () from /usr/lib/libGLcore.so.1
#7  0x00007f8d9d4a215e in sf::RenderTarget::Clear () from /usr/lib/libsfml-graphics.so.1.6
#8  0x000000000040354f in Tilechat::Run ()
#9  0x0000000000402f3b in main ()
So the last call before going to system libraries is sf::RenderTarget::Clear(). Then it's diving into OpenGL, where an infinite lock happens. This *normally* tells us it's a bug in OpenGL. But since I haven't learned the SFML source code good enough, that'd be also a possibility.

In the worst case, that "bug" even kills my X-Server! The log tells me this:

Code: [Select]

Backtrace:
560 0: /usr/bin/X(xf86SigHandler+0x6a) [0x47898a]
561 1: /lib/libc.so.6 [0x7f4c034470f0]
562 2: /usr/lib/xorg/modules/drivers//nvidia_drv.so(_nv001853X+0x6) [0x7f4bffbdf756]
563 3: /usr/lib/xorg/modules/drivers//nvidia_drv.so [0x7f4bffd5561c]
564 4: /usr/lib/xorg/modules/drivers//nvidia_drv.so [0x7f4bffd6c499]
565 5: /usr/bin/X(Dispatch+0x342) [0x44f7e2]
566 6: /usr/bin/X(main+0x4a5) [0x436bd5]
567 7: /lib/libc.so.6(__libc_start_main+0xe6) [0x7f4c034335a6]
568 8: /usr/bin/X [0x435e99]
nvidia_drv.so, that really sounds bad. But again, I don't know in which context and whatever. It's of course possible the bug starts very sooner and just kicks in at driver level.

So far, so good. Here's a ZIP containing source code for a minimal reproduction setup: *click* . Please keep in mind that the sources come from a rather full-blown game. I've stripped them down as much as possible to isolate the bug.


Okay, then something else, which maybe has something todo with the described bug above:
In my full game, I've also got one critical bug: *Sometimes* (not always!) the program crashes with an GLXBadContext error code. That ALWAYS happens when 1. using sf::Image::LoadFromFile() OR 2. doing something with the loaded image after that.

If that helps, I can post more source code, but since it's a big project, it would take some more time to understand it. So I thought I'd just point you in the right direction at first to see if you know anything that can help.

My system setup is:
Debian GNU/Linux on a 64 Bit AMD CPU
SFML version: SVN r1177 (latest)
Graphics driver: nvidia, 185.18.14 (latest)
Kernel: 2.6.26

If you need any information, please let me know. It's important for me to get that thing fixed, since it stops my programming entirely.