Messages

1

Audio / Re: When I disable and re enable audio output device there is no audio output.

« on: October 11, 2017, 02:23:30 am »

This was changed quite a while ago. "Restarting" OpenAL is possible.... Simply put, "restarting" SFML audio is already possible now.
[/quote]

How?

In our situation if a user Hot-Tabs away from the application AND it is using HDMI audio out, we get the error AL lib: (EE) MMDevApiProc: Failed to get padding: 0x88890004, and the audio stops working. The "solution" is to restart the app. However, adding logic to simply restart OpenAL under certain circumstances would be preferable.

Edit: After looking more at the source, it seems that if stop caching SoundBuffer instances in a global object (main screen) and instead cache them as memory objects only, instantiating them as SoundBuffer instances only when required, OpenAL will effectively reset every time we return to the main screen. Is this correct?

2

Graphics / Re: Occasional failures of wglCreateContextAttribsARB() inside WglContext::createCon

« on: August 18, 2017, 11:37:12 pm »

1) getErrorString has flaws:

- The length passed for FormatMessage is incorrect if TCHAR is longer than a byte
- System Messages returned in FormatMessage may have format markers; since you don't what they are beforehand, the FORMAT_MESSAGE_IGNORE_INSERTS should always be used.
- If a message cannot be found, the return buffer is not set to an empty string, so the return value of FormatMessage should be checked. If zero, the first character of the buffer should be set to zero.

2) Debug

I was not talking about mixing debug and release builds, but doing a release build WITH debug information on. Yes, many things get optimized away, but you can usually set breakpoints and get stack traces.

3) I've run into the same problem on both 2.3.2 and 2.4.2. In testing the error happened in 2.4.2 much more frequently with the actual release (versus the modified stress test code), hence the requirement given to me that 2.3.2 was to be used.

4) All calls to SFML occur on a single thread.

5) I've created stand alone tests, but so far all pass.

6) The 2.3.2 Release with Debug Info build I did this morning resulted in a failure extremely slightly different than with 2.4.2 in that when I allowed the program to switch to different playback "modules", they hadn't yet failed. Close examination of the failing "module" shows that it uses RenderTexture far more than any other module. I believe this can be refactored to reuse far fewer RenderTextures.

7) More research on my part found that Intel's OpenGL support has been less than optimal in the past, if not downright broken.

3

Graphics / Re: Occasional failures of wglCreateContextAttribsARB() inside WglContext::createCon

« on: August 18, 2017, 05:19:23 pm »

With 2.3.2 (which we've been using because it's more stable) and 2.4.2 we tend to get:

Failed to create an OpenGL context for this window:  (Followed by gibberish since getErrorString has a bad implementation)

With just 2.4.2, we received the additional following error:

An internal OpenGL call failed in RenderTextureImplFBO.cpp(92).
Expression:
   GLEXT_glGenFramebuffers(1, &frameBuffer)
Error description:
   GL_INVALID_OPERATION
   The specified operation is not allowed in the current state.

Impossible to create render texture (failed to create the frame buffer object)

* * *

What I then did was build the app with the debug version of 2.4.2 (since I was unable to build 2.3.2 without jumping through hoops) and put breakpoints in the methods producing the above. When they broke, I then backtracked and stepped through WglContext::createContext several times.

As a side note, I was running a very long test with 2.3.2 on my dev machine. I'd modified the code to run only the constructors of a select set of playback modes in a very methodical way. After running for almost 48 hours, I had six "Failed to create an OpenGL context for this window: NULNULÞ errors. The next iteration the program exited with no other warning.

UPDATE: I built a 2.3.2 release with debug version in VS 2015 by eliminating the FLAC and OGG support and rebuilding Freetype and libjpeg.

4

Graphics / Re: Occasional failures of wglCreateContextAttribsARB() inside WglContext::createCon

« on: August 17, 2017, 11:05:39 pm »

The app is a promotional product which runs on both a tablet and wall display. The display shows what's happening on the tablet if the tablet is being used, or what happened on the tablet otherwise. The non-promo load on the display system is rather small. (I did run one test on my dev machine where I blasted the GPU with textures from a second program and the promo program didn't "blink.")

I'm highly suspicious of the Intel driver, but don't want to fall into the trap of just blaming it.

5

Graphics / Occasional failures of wglCreateContextAttribsARB() inside WglContext::createCon

« on: August 17, 2017, 10:21:16 pm »

I'm getting occasional failures of wglCreateContextAttribsARB() inside WglContext::createContext which is, in turn, being called by sf:RenderTexture::create. When this happens, the fallback call to wglCreateContext also fails. Once this happens, the failures continue.

The program will successfully run for hours or even days before the error happens. and, though it may not be relevant, all Sprites/Textures not created using RenderTexture continue to work.

This is with Visual Studio 2015 64-bit, SFML 2.4.2 (and 2.3.2). The system which breaks the most often (relatively speaking) is Windows 7 64 with Intel HD 2500 graphics. I've had it fail once on my dev system; Windows 10 64 with Intel HD Graphics 530.

I'm writing small programs in an attempt to have the failure happen more predictably, but in the meantime, does anyone have any ideas?