Messages

1

Graphics / Re: Check if a Texture has an Image loaded?

« on: June 09, 2015, 12:59:41 am »

Looking at the responses here http://stackoverflow.com/questions/7200674/is-null-defined-as-nullptr-in-c11 it seems to imply that NULL is implicitly converted to nullptr in C++11 so code such as

Code: [Select]

if (mySprite.getTexture() == nullptr) will be fine?

2

Graphics / Re: Check if a Texture has an Image loaded?

« on: June 09, 2015, 12:46:49 am »

Ha, point taken 
I was creating an object that has sprite (and texture) to render, I wanted to only load the texture on the first call to myObject.Render(...) and keep hold of it until the object was destroyed. I was trying to accomplish by checking if the texture had been loaded already but using a boolean marker now. Is this reasonable or would you say that it's a poor approach?

On a related note - the documentation says Sprite::getTexture() returns a NULL pointer if no Texture has been set - is this the C++11 nullptr or is it NULL?

3

Graphics / Check if a Texture has an Image loaded?

« on: June 09, 2015, 12:12:15 am »

Not to be confused with checking whether a call to

Code: [Select]

Texture::loadFromFile("...") was successful.
[/size]I wondered if there was a method to do something like

Code: [Select]

Texture::hasImage() that would tell me whether a Texture has an image loaded or not?

4

Graphics / Re: How to redraw sprites added to the window higher up?

« on: May 14, 2015, 07:14:46 pm »

Ok, thanks. Also, just for future reference, how do you display the code like in your post? (it's so much more readable than in mine)

5

Graphics / Re: How to redraw sprites added to the window higher up?

« on: May 14, 2015, 07:04:39 pm »

Hopefully the code below makes it clearer - in the "isOpen()" loop inside MainMenu::Run() I want to be able to keep the background sprite in the window (i.e. know it exists and redraw it).

// INSIDE MAIN
// Create background sprite
sf::Sprite background_sprite // Plus other code to set up and attach a texture and scale it correctly...

render_window.draw(background_sprite);

// Run main menu - passing the address of the render window so main menu can draw to it
MainMenu main_menu(&render_window);
main_menu.Run();


// INSIDE MAINMENU::RUN()
// Create another sprite
sf::Sprite main_menu_sprite = ......

sf::Event event;
while(m_render_window->isOpen()){
    while(m_render_window->PollEvent(event)){
        // Code to poll events (just close window currently)
    }

    m_render_window->clear();
    m_render_window->draw(sprite);
   // Somehow know about and redraw background_sprite
    m_render_window->display();
}
 

6

Graphics / How to redraw sprites added to the window higher up?

« on: May 14, 2015, 06:49:16 pm »

Inside my main function I create a RenderWindow and a Sprite which is then applied as a background image. I then pass a pointer to the window to my MainMenu class which adds a menu to the window - however, inside the draw loop in the MainMenu class it has no knowledge of the background sprite and so it cannot redraw it.

Is there a way (other than passing all the sprites I wish to be redrawn as a vector to the MainMenu class) to let the MainMenu class know that I want all sprites currently attached to the window to be redrawn?

7

General / Re: Is libglew.a still needed by libsfml-graphics.a (and libsfml-graphics-s.a)?

« on: May 12, 2015, 12:43:59 am »

Thank you 

My current "project" is just trying out bits from the tutorials. I'd glossed over the dependencies and kept coming back to the FAQ for that though... 

8

General / Is libglew.a still needed by libsfml-graphics.a (and libsfml-graphics-s.a)?

« on: May 12, 2015, 12:36:28 am »

Here http://www.sfml-dev.org/faq.php#build-link-static it says that "glew" is a required library for using "sfml-graphics" (sfml-graphics-s in my case). But linking using MinGW from command line gives error "cannot find -lglew". If I remove this link then everything is fine and my program links and runs.

Looking in the libs directory of my install for SFML shows that libglew.a is not there. It isn't the dependencies folder for MinGW on GitHub either (https://github.com/SFML/SFML/tree/master/extlibs/libs-mingw/x86). Does this mean it is not required anymore?

9

General / Re: Linking SFML statically - openal32.dll still required

« on: May 10, 2015, 04:30:34 pm »

Thank you very much for the responses 

For anyone else coming across this thread and wondering about the terms of the LGPL, this answer clears things up quite nicely http://stackoverflow.com/questions/30150217/sfml-not-linking-statically-to-openal32-links-statically-to-all-other-dependenc/30152505#30152505

10

General / Re: Linking SFML statically - openal32.dll still required

« on: May 10, 2015, 03:16:02 pm »

Just looked at it again - yes, I realise SFML_USE_STATIC_LIBS was not relevant to this at all, sorry...

Ah, reply #6 on this thread http://en.sfml-dev.org/forums/index.php?topic=262.0 led me to believe that the license for OpenAL did not have that restriction.

Is there anywhere that provides the license for OpenAL (their website http://openal.org/ has very little)? Or are you able to clarify - am I allowed to distribute the openal32.dll with my executable or does the end user have to download it themselves?

11

General / Linking SFML statically - openal32.dll still required

« on: May 10, 2015, 01:13:14 pm »

I compiled SFML using CMake for MinGW. After running "mingw32-make install" everything is built and installed with no errors. But when running the examples - pong.exe, sound.exe, sound-capture.exe and voip.exe all depend upon openal32.dll.

I specified SFML_USE_STATIC_LIBS = true when configuring CMake and all other dependencies of the example executables are only upon native windows dlls.

Can anyone explain why it has dynamically linked to openal32 (but nothing else)?

I came across this thread http://en.sfml-dev.org/forums/index.php?topic=262.0 which is discussing exactly the same problem. The last post on this thread indicates that openal32 was going to be statically linked in the future (and the thread is from 2008).