Messages

31

Graphics / Re: SFML Context Management

« on: July 03, 2014, 01:46:11 pm »

From what I've seen, 8.771.1.0 means you have a HP notebook with dual AMD/Intel graphics? That driver package is 4 years old and I'm sure Intel has fixed a ton of bugs since then. Is there no way to update the drivers? HP is known to not release driver updates for their products as soon as a couple of years after release. You could try heading to the Intel download site and installing the "appropriate" driver and hope it doesn't break your AMD graphics.

From the code that has been posted so far, this looks more and more like a driver bug. There is no systematic way to explain why renderWindow.close() prevents the crash since it is called when the RenderWindow goes out of scope at the end of main() as well. So whether renderWindow.close() is present or not, the code that is executed is almost identical and really shouldn't be able to have an effect on the crash and yet it does...

You're right- the test machine I'm using is a HP notebook with dual AMD/Intel graphics. This is the only machine I have that seems to model the problems that my users are getting though - hence updating the drivers currently isn't an option. Telling my users with laptops to update their drivers hoping that it doesn't break something on theirs, isn't really an option either..;

For me with an i5 4200u (Intel HD 4400) with the latest driver (10.18.10.3621) I have no problems with the code, also with the "GPU" Geforce gt740m I get no error.

Great to know you're here to help AlexAUT - it's good to know there are other people to help check the issue.

I've noticed that the following code works without any access violation issues - any thoughts?
'renderWindow.close();' doesn't seem to cause an issue here.
The only real thing I've changed here is in using a pointer to a texture instead.

#include <SFML\Graphics.hpp>

sf::Texture* texture;

int main()
{
        sf::RenderWindow renderWindow( sf::VideoMode( 800, 600 ), "sfml test", sf::Style::Titlebar | sf::Style::Close );

        texture = new sf::Texture();
        texture->create( 100, 100 );

        renderWindow.display();

        renderWindow.close();

        return 0;
}
 

32

Graphics / Re: SFML Context Management

« on: June 28, 2014, 11:54:03 am »

Does this code crash?

#include <SFML\Graphics.hpp>
 
int main()
{
    sf::RenderWindow renderWindow( sf::VideoMode( 800, 600 ), "sfml test", sf::Style::Titlebar | sf::Style::Close );
 
    sf::Texture texture;
    texture.create( 100, 100 );

    renderWindow.display();
 
    return 0;
}

Also, what driver version is installed on the machine? Maybe this is a known bug.

The code doesn't crash - it doesn't crash if I change 'texture.create( 100, 100 );' to a 'texture.loadFromFile()' either.

The driver version on this laptop is 8.771.1.0

This code also works:

#include <SFML\Graphics.hpp>

int main()
{
        sf::RenderWindow renderWindow( sf::VideoMode( 800, 600 ), "sfml test", sf::Style::Titlebar | sf::Style::Close );

        renderWindow.clear( sf::Color( 255, 255, 255, 255 ) );
        renderWindow.display();

        sf::Texture texture;
        texture.create( 100, 100 );

        renderWindow.clear( sf::Color( 255, 255, 255, 255 ) );
        renderWindow.display();

        //renderWindow.close();

        return 0;
}
 

It seems the moment I uncomment the 'renderWindow.close()', the code crashes again.
The same happens if I add a 'renderWindow.close()' to the last part of the code you gave.

33

Graphics / Re: SFML Context Management

« on: June 28, 2014, 05:31:47 am »

I've found something interesting.

The following code crashes: (the same ntdll.dll access violation errors)

#include <SFML\Graphics.hpp>

int main()
{
        sf::RenderWindow renderWindow( sf::VideoMode( 800, 600 ), "sfml test", sf::Style::Titlebar | sf::Style::Close );

        renderWindow.clear( sf::Color( 255, 255, 255, 255 ) );
        renderWindow.display();

        sf::Texture texture;
        texture.loadFromFile( "btn_sel.png" );

        sf::Sprite sprite;
        sprite.setTexture( texture );

        renderWindow.clear( sf::Color( 255, 255, 255, 255 ) );
        renderWindow.display();

        renderWindow.close();

        return 0;
}
 

while the following code doesn't:

#include <SFML\Graphics.hpp>

int main()
{
        sf::RenderWindow renderWindow( sf::VideoMode( 800, 600 ), "sfml test", sf::Style::Titlebar | sf::Style::Close );

        renderWindow.clear( sf::Color( 255, 255, 255, 255 ) );
        renderWindow.display();

        sf::Texture texture;
        texture.loadFromFile( "btn_sel.png" );

        sf::Sprite sprite;
        sprite.setTexture( texture );

        renderWindow.clear( sf::Color( 255, 255, 255, 255 ) );
        renderWindow.draw( sprite );
        renderWindow.display();

        renderWindow.close();

        return 0;
}
 

The only difference is one `renderWindow.draw( sprite );` call.
(the same occurs if I replace the texture.loadFromFile function with texture.create( 100, 100 ); )

I don't know if this helps track down something.

34

Graphics / Re: SFML Context Management

« on: June 28, 2014, 04:56:53 am »

So does the following code also (immediately) crash?

#include <SFML\Graphics.hpp>

int main()
{
        sf::RenderWindow renderWindow( sf::VideoMode( 800, 600 ), "sfml test", sf::Style::Titlebar | sf::Style::Close );

        renderWindow.clear( sf::Color( 255, 255, 255, 255 ) );
        renderWindow.display();

        sf::Texture imageVec[3];

        for ( int i = 0; i < 3; ++i )
        {
                imageVec[i].create( 100, 100 );
        }

        renderWindow.clear( sf::Color( 255, 255, 255, 255 ) );
        renderWindow.display();

        renderWindow.close();
}

I've just checked the code - it crashes right away.

35

Graphics / Re: SFML Context Management

« on: June 28, 2014, 03:44:28 am »

Thanks for the feedback 

#include <SFML\Graphics.hpp>
#include <array>

using ImageVec2 = std::array<sf::Texture, 3>;

int main()
{
        using namespace std;
        sf::RenderWindow renderWindow( sf::VideoMode( 800, 600 ), "sfml test", sf::Style::Titlebar | sf::Style::Close );

        ImageVec2 imageVec;

        while ( renderWindow.isOpen() )
        {
                // check all the window's events that were triggered since the last iteration of the loop
                sf::Event event;
                while ( renderWindow.pollEvent( event ) )
                {
                        switch ( event.type )
                        {
                        case sf::Event::Closed:
                                imageVec.empty();
                                renderWindow.close();
                                return 0;

                        case sf::Event::KeyPressed:
                                switch ( event.key.code )
                                {
                                case sf::Keyboard::Num4:
                                {
                                        for ( auto& pBtnImage : imageVec )
                                        {
                                                pBtnImage.create( 100, 100 );
                                        }
                                }
                                }

                        }
                       
                        renderWindow.clear( sf::Color( 255, 255, 255, 255 ) );
                        renderWindow.display();
                }
        }

        return 0;
}
 

The same memory address errors occur after pressing on the 4 key a few times and closing the window.

The crash is something I noticed while trying to reproduce the original issue.
The code that loads the textures in the original issue and the above code are closely related in my engine code - fixing this might fix the texture corruption issue that users have reported to me about.

I notice visual studio breaking me at times on
`pBtnImage.create( 100, 100 );` in the original engine code (the same ntdll.dll issue), this might be the source of trouble in the minimized code here as well.

36

Graphics / Re: SFML Context Management

« on: June 28, 2014, 02:24:10 am »

Thanks for the reply,
I managed to get a hold of a laptop pc with an intel hd graphics 4000 graphic card.

#include <SFML\Graphics.hpp>
#include <memory>
#include <array>

std::unique_ptr<sf::RenderWindow> pRenderWindow;

using ImageVec = std::array<std::shared_ptr<sf::Texture>, 3>;

int main()
{
   using namespace std;
   pRenderWindow.reset( new sf::RenderWindow( sf::VideoMode( 800, 600 ), "sfml test", sf::Style::Titlebar | sf::Style::Close ) );

   ImageVec imageVec;

   while ( pRenderWindow->isOpen() )
   {
      // check all the window's events that were triggered since the last iteration of the loop
      sf::Event event;
      while ( pRenderWindow->pollEvent( event ) )
      {
         switch ( event.type )
         {
         case sf::Event::Closed:
            imageVec.empty();
            pRenderWindow->close();
            pRenderWindow.reset();
            return 0;

         case sf::Event::KeyPressed:
            switch ( event.key.code )
            {
            case sf::Keyboard::Num4:
            {
               ImageVec imageVec_ = { make_shared<sf::Texture>(), make_shared<sf::Texture>(), make_shared<sf::Texture>() };
               imageVec = imageVec_;

               for ( auto& pBtnImage : imageVec )
               {
                  pBtnImage = make_shared<sf::Texture>();
                  pBtnImage->create( 100, 100 );
               }
            }
            }

         }
         
         pRenderWindow->clear( sf::Color( 255, 255, 255, 255 ) );
         pRenderWindow->display();
      }
   }

   return 0;
}

Running the code and hitting on the keyboard 4 key a couple of times and then closing the window will produce the following error: (with just different memory addresses)

First-chance exception at 0x7797E3BE (ntdll.dll) in sfml_test.exe: 0xC0000005: Access violation reading location 0x95159966.
First-chance exception at 0x7797E3BE (ntdll.dll) in sfml_test.exe: 0xC0000005: Access violation reading location 0x95159966.
First-chance exception at 0x7797E3BE (ntdll.dll) in sfml_test.exe: 0xC0000005: Access violation reading location 0x95159966.

Tell me if there is anything wrong with the code itself - it works completely fine on my pc with the ATI graphics card; the problem only occurs on the one with the Intel card.

37

Graphics / Re: SFML Context Management

« on: June 27, 2014, 04:37:24 pm »

Hi, I've asked for some additional info from my users previously reporting bugs. It seems they're using:

Intel HD Graphics 4400
Intel HD Graphics 4000

They've replied back to me saying that they'd all updated to the latest drivers they could get.

I can understand wanting to reduce the number of workarounds to serve the minority with issues, but is there no underlying method to address or improve them all?

I've had roughly 20 people during the last month email me with the problem (back before the fix)
- while they may be a minority in terms of a larger group, I definitely don't feel that they should be considered lightly;
especially if something as simple as adding a 'pRenderWindow->setActive(true)' before all texture/view/window manipulation functions cleaned out most issues.

I'm not sure how effective this would be, but would it be possible to add something along the lines of a 'normal' mode and 'safe' mode trigger for context management? 'normal' mode would run without the workarounds pertaining to minority drivers, while 'safe' mode would be as cautious as possible to suit as many drivers as possible.

38

Graphics / SFML Context Management

« on: June 26, 2014, 02:00:23 pm »

Hi, I'm currently working on a small game engine using sfml.

I've recently had users with intel graphics cards building reporting that they were getting corrupt images when loading image files. Sadly, I couldn't reproduce the problems with my graphics card.

In the end, I had to place a

pRenderWindow->setActive( true );

before each and every texture and view manipulation function
and a glFlush() right afterwards.

Users have been telling me since that they aren't getting the problems,
but I feel like this is a terrible ad-hoc hack just waiting to hit me in the face again any time.

Are there any plans to improve context management in sfml,
or is this the only way to prevent these weird bugs?

The attached image is a screenshot sent to me by one of my users -
there's this weird mixing of textures going on despite having loaded single image files.

I am not running the executable in a multithreaded fashion and all images loaded are done through
the normal .loadFromFile() function.

39

Graphics / Re: Simple method to rotate sprite about it's centre point

« on: June 22, 2014, 04:03:22 am »

I just think this is an extremely convenient function to have and adding it into SFML as a default function would definitely make this more accessible.

No, if something like setSize(...) was removed in favor of directly using setScale(...) then this function does not belong at all.

Could you elaborate? I don't quite understand what you mean.

40

Graphics / Re: Simple method to rotate sprite about it's centre point

« on: June 21, 2014, 03:33:45 am »

I can't help thinking "what's wrong with changing the origin to what makes sense for a given transformation, do the transformation, draw the result, then change the origin back"?
No need to make a simple thing complicated; just change, transform, draw, change back 

Definitely, and a function along the lines of setOriginAndReadjust that maintains the visual appearance of the entity on screen despite the origin change would simply do just that without the manual readjustment fuss.

41

Graphics / Re: Simple method to rotate sprite about it's centre point

« on: June 20, 2014, 11:59:19 am »

AlexAUT

I really do feel though that this should be a default function in SFML 

I don't think so, because basically when you create the sprite/rect/circle/whatever with the origin already centered you won't have this "problem" with the offset.

Right, but I think in cases when you do change the origin after creation (for certain visual effects, etc.), you many a time probably don't want the visual appearance of what's already on screen to change.

The intention is more along the lines of 'change the origin to this, and have future .setPosition(), .setScale()' applied based on this', than 'change the origin to this, and have everything I've done up until now changed'.

I just think this is an extremely convenient function to have and adding it into SFML as a default function would definitely make this more accessible.

42

Graphics / Re: Simple method to rotate sprite about it's centre point

« on: June 20, 2014, 08:34:25 am »

Thanks for all the help AlexAUT!

I really do feel though that this should be a default function in SFML 

43

Graphics / Re: Simple method to rotate sprite about it's centre point

« on: June 20, 2014, 08:04:39 am »

Thanks AlexAUT!

Is there a reason for the offset.x * 2.f though? It seems to put my sprite slightly right than before.

object.move( { offset.x, offset.y } )

in comparison seems to work fine visually - although I'm not sure if this is technically correct.

44

Graphics / Simple method to rotate sprite about it's centre point

« on: June 20, 2014, 06:43:10 am »

Hi, I was wondering if there was a simple way to rotate a sprite around it's centre point.

The rotate() function rotates about the sprite's top left corner,
which means I need to change the origin to the sprite's centre point.
However changing the origin then requires readjusting the position, and the scale.

Is there a simple way of going about this, or is this the only way?

I personally feel that rotation about the centre point is more instinctive and widely used than rotation about the top left corner (same with scaling). It would be great to have a function that easily gets this done if currently not implemented.

--update--

On second thought, perhaps a function on the lines of .setOriginAndReadjust() might be nice; where it not only changes the origin but also readjusts internal position, etc. to maintain the same visual appearance.

45

General discussions / Re: Unofficial Nightly Builds

« on: May 20, 2014, 05:53:59 am »

Thanks for all the work, the builds are absolutely great.

Any possible nightly builds for sfeMovie? (especially the sfeMovie2 branch)