Messages

1

Window / ContextWGL crash after updating from 1.5 to 2.0 beta

« on: August 11, 2010, 09:58:33 am »

Ouch.
I'd be happy to help test this if you devise a fix for this issue. I also have an ATI Radeon card on my other computer, although I would have to check that it crashes first on that card.

2

Window / Oddity with Event.Key.Code(s) ?

« on: August 11, 2010, 09:45:33 am »

Oops! Yep. Works fine. Looks like it's in the documentation also (Which I should probably take a quick look at first when something goes wonky).  

Thanks.

3

Window / Oddity with Event.Key.Code(s) ?

« on: August 11, 2010, 06:21:35 am »

This one is very straightforward. Using this code:

Code: [Select]


        while (window.GetEvent(Event))
        {
  if( Event.Key.Code == sf::Key::Down )
{  
             // setting a breakpoint here triggers when the mouse gets moved most the time.


Moving the mouse around will trigger Key::Dir events and possibly (untested) others. Very strange.

Windows XP. VC++ 09. SFML2.0


[edit] - I investigated this further and found this to be re-produceable when moving the the mouse coordinates outside of the top-left corner of the window and back.

In other words: Just shake the mouse real fast next to the window icon.

4

Window / ContextWGL crash after updating from 1.5 to 2.0 beta

« on: August 11, 2010, 06:09:49 am »

Hi. Was a solution to this problem ever found? I'm using SFML 2.0 and experience this same crash with static linking on an Intel card. Is there a fix for this?

Thanks.

[EDIT] I missed reading the second page. So a fix might be in GLContext.cpp? I'll have a look even though I don't quite understand what needs to be changed.

5

Graphics / ~Image() crash -sfml2.0

« on: August 05, 2010, 11:49:35 am »

No, sorry I wasn't clear about that. What I mean is this is not a bug in SFML but with my Intel drivers. It shouldn't cause a crash there AFAIK, even though it sometimes does. This is properly fixed in this case (for me that is) by making myTexture public. This makes me wonder just how card manufacturers decide to implement these functions... And just how often, and on what cards, will calling glDeleteTextures actually do anything on exit? ..Ideally it would delete the textures I suppose.


@GetTexture. Sure, but it would take one line of code and let users do this:
glBindTexture( GL_TEXTURE_2D, sf::Image::GetTexture() );
// draw a gluQuadric or something

6

Graphics / ~Image() crash -sfml2.0

« on: August 05, 2010, 12:51:51 am »

It's the only way to allow RAII. In this respect, I consider the destructor the best place.

No, I'm afraid you are wrong in this case: http://www.opengl.org/wiki/Common_Mistakes

At best; trying to clean up resources when there is no OpenGL context does nothing anyway.

Where would you put the deallocation of the texture? Would you force the user to call an explicit function before every sf::Image is destroyed?

I just stuck it right before the window.Close(); function. Works fine for me.


Also there should be an GLuint sf::Image::GetTexture() function, but there doesn't seem to be.

7

Graphics / ~Image() crash -sfml2.0

« on: August 04, 2010, 01:23:14 pm »

Nah, don't need to go through all that. Here's yer problem:

Code: [Select]


void Image::DestroyTexture()
{
    // Destroy the internal texture
    if (myTexture)
    {
        GLuint Texture = static_cast<GLuint>(myTexture);
        GLCheck(glDeleteTextures(1, &Texture));
        myTexture        = 0;
        myTextureUpdated = true;
        myArrayUpdated   = true;
    }
}

Surely a dtor is about the worst possible place to put that.

(True, this probably would simply be undefined on my NVidia card, but still...)

8

Graphics / ~Image() crash -sfml2.0

« on: August 04, 2010, 12:00:31 pm »

HEAP[Tests.exe]: Invalid Address specified to RtlFreeHeap( 00150000, 08C64750 )

    Tests.exe!sf::Image::DestroyTexture()  + 0x66 bytes   
    Tests.exe!sf::Image::~Image()  + 0x51 bytes   
>   Tests.exe!main()  Line 349 + 0x19 bytes   C++
    Tests.exe!_WinMain@16()  + 0x19 bytes   C++
    Tests.exe!__tmainCRTStartup()  Line 574 + 0x35 bytes   C
    Tests.exe!WinMainCRTStartup()  Line 399   C

This is the best I can do as I have no program database files for SFML. (didn't think I would need them you know)

I'm using the 2.0 snapshot from about 3-4 weeks ago. Also I've since removed all other SFML rendering code, including .Draw(text) calls, though I don't know why that would matter any.

Are you calling glDeleteTextures() there?

9

Graphics / ~Image() crash -sfml2.0

« on: August 04, 2010, 09:52:42 am »

Yes.
- sfml-main-d.lib sfml-system-s-d.lib sfml-window-s-d.lib sfml-graphics-s-d.lib opengl32.lib glu32.lib
- Minimal rebuild.

I take it this may not be a common issue then? I'll see about getting a stack trace next time it happens.

10

Graphics / ~Image() crash -sfml2.0

« on: August 04, 2010, 05:29:23 am »

I will sometimes get a crash from the Image destructor on program exit. "Sometimes" as in not very often, but occasionally.  -MSVC 2008 _DEBUG setting.

Here is the main function with non-SFML code removed:

Code: [Select]


int main()
{
sf::RenderWindow window(sf::VideoMode(640, 480), "SFML OpenGL" );

sf::Image tilesheet;
if (!tilesheet.LoadFromFile("image.png"))
          return -123;

  // create OpenGL texture with tilesheet.GetPixelsPtr()
 
  // -main loop
  {
  // OpenGL code here
window.SaveGLStates();
{
window.Draw(text);
}
window.RestoreGLStates();

window.Display();
  }
  return 0;
}