Messages

286

Feature requests / Re: Image non const getPixelsPtr

« on: July 01, 2015, 10:46:01 pm »

As I understand it, he is wanting to manually decompress into the Image/Texture/etc.

Rather than decompress to a vector/array/etc, then pass the decompressed array into the Image/Texture to be copied.

287

Graphics / Re: sf::Texture::update memory leak.

« on: June 29, 2015, 08:30:08 pm »

It does, but you don't quite have control over it as much as you do with a context for a window (activating/deactivating) is my line of thought. Then again, I could be wrong as well.

288

Graphics / Re: sf::Texture::update memory leak.

« on: June 29, 2015, 08:20:02 pm »

Well, if you didn't notice, a window is not in the example, as one is not needed to demonstrate the issue. So no call to setActive.

So, I'd say no.

And as well, even if this "isn't a memory leak", this is still a problem. As I run out of memory quickly. My application stops getting calls from the SDK, as it is unable to allocate memory for the images it passes to me.

289

Graphics / sf::Texture::update memory leak.

« on: June 29, 2015, 07:55:07 pm »

Spoke with eXpl0it3r on irc a bit about this.

Anyway, so I have a multithreaded application. Seems that calling sf::Texture::update repeatedly, leaks. Tracking it revealed that it's specifically sf::priv::WglContext::createContext which leaks, and it leaks a lot, very quickly (~42 MiB in 3 sec).
sf::priv::WglContext::makeCurrent also causes a leak, but no where near as much (~72 KiB in 3 sec).

Essentially, my application has a thread controlled by an SDK I'm using, of which I have no control over. It calls a function that I write, and waits until it returns. I have this function launch a thread to do some processing on what the SDK passed to me, and detach from it, so I can let the SDK's thread continue.

I'm taking the image it gives, me converting it to an sf::Texture, and then in another thread, drawing said sf::Texture with an sf::Sprite on a sf::RenderWindow.
I have mutexes around any access to the texture.

Minimal example:

#include <SFML/Graphics.hpp>

#include <mutex>
#include <thread>

int main()
{
        using byte = unsigned char;

        sf::Texture texture;

        std::mutex textureMutex;

        std::thread([&]()
        {
                while (true)
                {
                        sf::sleep(sf::milliseconds(32));
                        std::thread([&]()
                        {
                                std::lock_guard<std::mutex> textureLock(textureMutex);

                                std::vector<byte> bytes(640 * 480 * 4);

                                if (texture.getSize() == sf::Vector2u{0, 0})
                                {
                                        texture.create(640, 480);
                                }

                                texture.update(bytes.data());
                        }).detach();
                }
        }).join();
       
        return 0;
}
 

The sf::sleep is there to simulate time waiting for the call from the SDK.
Also, without it, SFML outputs this:

Code: [Select]

An internal OpenGL call failed in TextureSaver.cpp (38) : GL_INVALID_OPERATION,
the specified operation is not allowed in the current state
An internal OpenGL call failed in Texture.cpp (390) : GL_INVALID_OPERATION, the
specified operation is not allowed in the current state
An internal OpenGL call failed in Texture.cpp (391) : GL_INVALID_OPERATION, the
specified operation is not allowed in the current state
An internal OpenGL call failed in TextureSaver.cpp (45) : GL_INVALID_OPERATION,
the specified operation is not allowed in the current state
Failed to create an OpenGL context for this window:
and an abort() gets called from crtmbox.c for every set of the above messages. Though, that seems less relevant.

Also, here is the VS *.diagsession file from running VS' Memory Analysis tool (had to put it on my Dropbox, as it's too big).

Oops, forgot versions and hardware and stuff:

OS: Windows 8.1 Enterprise
CPU: i7-4790
GPU: Intel HD Graphics 4600 (tried default driver and latest driver)
SFML: 2.3 from Github, compiled myself

Given that it's an Intel GPU, I'm assuming this is probably a driver issue... I'd try another graphics card, but I don't think we have any here at work.

290

General / Re: Licensing help (in general)?

« on: June 28, 2015, 02:19:19 am »

I've found Github's choosealicense.com and this flowchart useful in the past.

291

General / Re: Slow performance with A*

« on: June 25, 2015, 11:58:18 pm »

Also, since no one has mentioned it: make sure you're trying Release mode as well, and not just Debug. A good optimizer will fix some of the issues that were already mentioned.

292

Audio / Re: AL_INVALID_OPERATION from SFML 2.3 Audio

« on: June 25, 2015, 10:11:17 pm »

Windows 8.1 64-bit
VS 2013
SFML 32-bit.

Did you try it in debug mode?

Sorry, should've clarified, I tried both Debug and Release.
Only dynamic though, not static. (it was 2 AM. )

Though, it looks like VS doesn't define DEBUG automatically in Debug builds (grumble grumble), it defines _DEBUG (note the underscore). So that'd be why I could not reproduce. I can try again after work, thought it looks like that may be redundant.

@Nexus:
Yeah, when googling and looking at the Github I thought that macro was pretty... interesting. The two statement macro + if-statement without braces didn't click for me though.
Heh, that may be why my workplace's coding standards require braced if-statements...

But yeah, you're right. Who knows what else could be caused by similar errors? I'm interested in the effects on client code. I'll try that branch out on some of my existing code and see if anything breaks.

293

Audio / Re: AL_INVALID_OPERATION from SFML 2.3 Audio

« on: June 25, 2015, 09:15:20 am »

I could not reproduce.

Windows 8.1 64-bit
VS 2013
SFML 32-bit.

I can try Linux tomorrow.

294

General / Re: Error when trying to use SFGUI with Visual Studio 2013

« on: June 25, 2015, 07:44:03 am »

Have you ran it step-by-step? So you can at least narrow it down to exactly which function call is causing the access violation.

Bonus points for getting debug libs of sfgui and tracing it down to where it happens in sfgui.

295

SFML projects / Re: Thor 2.0

« on: June 14, 2015, 09:49:36 pm »

My guess would be that you are referring to STL(not the library)

You would be correct! Haha.

If that indeed does reproduce, SpeCter or I could message him then I guess. He may be able to fast-forward a fix, that's why I mentioned him as a possibility. Haha.

296

SFML projects / Re: Thor 2.0

« on: June 14, 2015, 08:55:35 pm »

I know of a user on Reddit who works on the VS compiler/standard library (may just be the standard library, can't remember exactly). I could try messaging him to ask about it, if you like.

He'll prolly want a sscce.

297

SFML projects / Re: Thor 2.0

« on: June 14, 2015, 08:03:30 pm »

I've seen bits and pieces of the changelog for 2015. They've done a fair amount of changes with templates and such... Could be a bug. It is just a release candidate after all.

298

General / Re: Can't set my project up

« on: June 07, 2015, 07:12:20 pm »

Error1 error LNK1104: cannot open file '(­ditionalDependencies).obj'

Take another look at the file name in the error message. Looks like a copy and paste error to me.

(click to show/hide)

should be "additionalDependencies.obj", not "ditionalDependencies.obj".

299

General / Re: Unable to load image SFML 2.3

« on: June 03, 2015, 10:38:45 pm »

Are you running the program from inside VS or outside of VS?

I can't remember the running directory that VS uses, but that'd be it...
(this might help...)

Besides that though, I just use a function to get the location of my running program, and then make the path to resource files from there.
Like this for windows, and like this for linux.

300

Graphics / Re: Highlighting a sprite when mouse left clicks it

« on: June 03, 2015, 02:47:35 am »

by default a Sprite's color is solid black (0, 0, 0, 255), right?

No. The default colour for a sprite is solid white as a sprite's colour effectively filters the colours in the sprite's texture. White allows all of the texture through as is, and black changes all of the colours in the texture to black.

Riiight... My bad.

Only difference really is that your texture will end up a bit darker than when you made it then.