Welcome, Guest. Please login or register. Did you miss your activation email?

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.

Topics - kullerhamPster

Pages: [1]
Graphics / How to use sf::Image:LoadFromMemory?
« on: February 05, 2017, 07:05:39 pm »
From what I have read in the documentation and some posts I found here in the forum, this function does not expect just an array of RGBA values, but an entire image (file) in memory, and therefore 'data' has to point to the first byte of the file in memory.
But if this is true, I don't know why the second parameter 'size' is needed and how it is interpreted.

If the function expects an entire file, it could determine the size of the image via the file's header, just as loadFromFile probably does (which doesn't expect a size). So I guess I understand something wrong here and hope that someone can explain why this parameter is needed.

SFML website / Binaries for VC++ 2015
« on: September 06, 2015, 02:16:20 pm »
Hi there. Are there plans to include binaries for VC++ 2015 in the downloads for Windows? As the final version of VS2015 is released and available for download, I think these would be nice to have :)

System / [SFML 2.0 RC] - Threads
« on: June 03, 2012, 06:38:45 pm »
I just wanted to get an old (and never finished) project to work with SFML 2.0. I found out that there were lots of changes to the sf::Thread class, and I'm a bit confused why the 'old' way of creating threads (by inherting from sf:Thread and overriding 'Run()') was removed - I found this approach simple and elegant.
What's the reason for this change? Are there plans to reimplement the 'old' approach as an alternative?

General / Performance within VirtualBox
« on: December 08, 2009, 10:33:36 pm »
I tried to run a simple SFML-app I've written inside a Linux virtual machine, hosted by VirtualBox on a Win 7 x64 host.

VirtualBox supports OpenGL for guest operating systems since quite a while now, and the performance is surprisingly good when using some Compiz desktop effects inside the VM (like wobbly windows or transparency). My SFML-app however (which does not much more than drawing a few sprites) runs really, really slow and stuttering, and I'm not quite sure whether this is a problem of VirtualBox, my app, or SFML.

Has anyone else here ever tried to use SFML inside a virual machine?

EDIT: Just found out that the problem seems to be created by drawing a pseudo-3D-starfield in the background which consisted of 500 stars. Perhaps there's something wrong with the way I update the position of these stars. I'll see if I can figure it out.

EDIT2: Ok, it seems to be related to some graphic/OpenGL-stuff. If I calculate the position for each star but don't draw it (by commenting out the call to the draw-method of the render-window), it runs at quite normal speed.

System / Drawing from within a thread
« on: January 01, 2009, 07:41:15 pm »
As explained in my other posting here, I have written a small class that inherits from the thread class.
The purpose of this thread is to draw some moving stars (up to now, these are only small, white rectangles). This starfield class has a member variable that points to the appropriate RenderWindow.

The class's Run() method calls another method that iterates over all the stars, creates a Rectangle for each, and draws this Rectangle to the RenderWindow that is specified by the appropriate pointer.

The Display()-method of the RenderWindow is called outside this thread, in the program's main loop.

Now, for some reason, whatever I try to draw within this separate thread doesn't get displayed on the window, whereas stuff I draw in the main loop is correctly displayed.

In contrast, when I call the Draw-method of my Starfiled class from within the main loop, everything is displayed correctly.

Is this some sort of race condition, as it might happen that the thread tries to draw some stuff on the RenderWindow, while the main loop calls Display()?
If so, I guess I'd have to use some mutex for synchronization, but in that case, there wouldn't be any benefit from using a separate thread for drawing those stars (my original intention was to keep movement of the player's sprite more responsive, by not having to wait until all stars are drawn before input is processed).

System / Correct method for thread termination?
« on: January 01, 2009, 03:22:03 pm »
Hi all, and happy new year :)

I have a small question regarding threads: I have written a class that inherits from the thread class, let's call it "Mythread". The according thread does nothing but to draw some pixels on the screen all the time (which currently doesn't work, but that's another problem ;) ).

When my main application is about to terminate, this thread should of course also end. My current implementation of this looks (roughly) as follows:
Code: [Select]

void Mythread::Run()
    while ( this->running )
        // call method to draw something

void Mythread::~Mythread()
    this->running = false;

    // call delete for other Mythread-intenal stuff

So my main application does nothing but to call the destructor of the Mythread class when it's about to exit.

I have included some debugging output in the functions shown above, and from what I can see there, this solution seems to work correclty. Anyway, I thought to better ask here if it really is correct or if something is wrong with it.

By the way: While testing this stuff, I made my Linux crash twice. Probably, my mistake was to call Mainwindow.Close() before exiting the thread. So it could have happended that the thread tried to draw to a non-existing window. This, of course, shouldn't lead to a system crash, but there seems to be some bug within the ATI video driver.
The syslog says:
BUG: unable to handle kernel paging request at 0000100000002068
IP: [<ffffffffa022b8d5>] firegl_unlock+0xb5/0x1b0 [fglrx]

I don't know if this could be worked around within the SFML, but as I find this bug rather interesting, I thought I'd post it here ;)

Pages: [1]