Messages

91

Window / [Mac] sf::VideoMode::getDesktopMode() returns wrong values for retina

« on: January 13, 2015, 05:51:43 pm »

Hi.

I'm using SFML master version and have set HighResolutionCapable in my info.plist to true.
sf::VideoMode::getFullscreenModes() returns me all available modes including 2880x1800.
sf::VideoMode::getDesktopMode() however returns only 1440x900 instead of the expected 2880x1800.

Greetings

92

SFML projects / Re: Image Atlas Generator

« on: December 24, 2014, 08:17:08 am »

I'd be curious to see given on a fixed set of sprites if your algorithm is better than mine.

93

SFML projects / Re: Image Atlas Generator

« on: December 22, 2014, 10:45:44 am »

Sounds like some form of a scanline algorithm. Did you come up with it on your own or did you use some algorithm that has been proven to generate an optimal solution?

Since the problem is np-hard, I doubt it is the optimal solution
Some problem remains though. The images get saved in some wonky order, so where's the file to look up the position and size for each sprite in the final atlas? Without such a mapping, the atlas itself isn't of much help.

94

Window / Re: 32 bit to 64 bit

« on: November 24, 2014, 07:30:41 am »

That also might include external libraries like libsndfile or freetype2.

95

General discussions / Re: Android and iOS ports available for testing

« on: November 22, 2014, 08:01:47 pm »

You get a move instantly after a TouchBegan? Or you don't get a TouchBegan at all? Both sounds odd though indeed. I'd believe though that SFML isn't creating events which don't came from the OS.

96

General discussions / Re: Android and iOS ports available for testing

« on: November 22, 2014, 07:02:27 pm »

Why would you want to prevent that? TouchBegan, Moved and Ended are basic concepts for any touch sensitive API. If you want to ignore that event, you'll have to create your own logic to stop handling it in certain circumstances.

97

Window / [iOS] RenderWindow turns 90° when using style-flags in constructor

« on: November 21, 2014, 10:36:36 am »

Hi.
When using style flags in a RenderWindow-constructor, the screen turns 90° clockwise. If not specifying any flags, it looks fine.
Using iOS 8.1. In 7.x it looks different, but also wrong (with and without flags actually).

Minimal sample code:

#include <SFML/Graphics.hpp>
#include <SFML/Main.hpp>

int main(int argc, char *argv[])
{
    auto mode = sf::VideoMode::getFullscreenModes()[0];
    // the next line causes the problem if some sf::Style flags are passed as parameters (any)
    sf::RenderWindow window(mode, "SFML window", sf::Style::Titlebar );
   
    auto leftRect = sf::RectangleShape(sf::Vector2f(window.getSize().x/2, window.getSize().y));
    leftRect.setFillColor(sf::Color::Red);
    auto rightRect = sf::RectangleShape(sf::Vector2f(window.getSize().x/2, window.getSize().y));
    rightRect.setFillColor(sf::Color::Green);
    rightRect.move(window.getSize().x/2, 0);
    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed) {
                window.close();
            }
        }
        window.clear();
        window.draw(leftRect);
        window.draw(rightRect);
        window.display();
    }
   
    return 0;
}

I have attached two screenshots showing the results of passing flags and not passing flags. When not passing flags, the two rects fill the entire screen:
  The red one on the left, the green one on the right - as the code suggests.
When passing flags to the window constructor, the rects get misaligned:


I'm using latest trunk revision of SFML.

98

General discussions / Re: Android and iOS ports available for testing

« on: November 18, 2014, 10:07:38 am »

Hi there.
I'm currently trying to get a simple sample app to work in iOS Simulator. After the hell having to compile FreeType-lib and LibJPEG (I have no idea which versions have been compiled and committed to the repository, but the last trunk versions of these have various incompatible parts of source code), I have now have a running app based on the MacOS Sample Code for the main loop. However. The screen stays black. Trying to change the glClearColor does nothing, it stays black. Further the "[m_context presentRenderbuffer:GL_RENDERBUFFER_OES]" call inside the "EAglContext::display()"-method takes about one second. No vsynch, no frametime specified.
Any ideas?

Edit: I forgot to include SFML/Main.hpp. Then I had to remove the Storyboard-reference from Info.plist, but now my main() doesn't get called anymore at all.

Edit2: There had been no way to get CLang convinced to call my "main" (actually internally the "sfmlMain"). Seems to be a linker-issue. Currently I performed a hack I'd like to remove: I have my own correct "main", that one calls the MainiOS.mm-main (I renamed it), then it starts the Application-Delegate and calls back my sfmlMain. I have removed the function-definitions in SFMain.mm for that to work (even though they were weak). Like I said, I'd like to rather have my SFML not patched this way, but I didn't get it to work otherwise.

99

Window / iOS Settings Version Number

« on: November 18, 2014, 09:32:23 am »

Hi.

I'm currently trying to get SFML to display anything at all on iOS simulator and I noticed that GlContext initializes the settings with version-numbers like that:

Code: [Select]

const GLubyte* version = glGetString(GL_VERSION);
if (version)
{
// The beginning of the returned string is "major.minor" (this is standard)
m_settings.majorVersion = version[0] - '0';
m_settings.minorVersion = version[2] - '0';
}
Now I get the following string returned: "OpenGL ES-CM 1.1 Apple-10.1.5"
The resulting major and minor version numbers are 31 and 53, because it tries to use "O" and "e". Is that a problem or can that be ignored?
(The OpenGL ES specification also verifies this string: https://www.khronos.org/opengles/sdk/1.1/docs/man/glGetString.xml - so the "standard" differs )

100

Window / Re: Weird Window-Sizes on MacOS

« on: November 12, 2014, 11:19:58 am »

Which commits are relevant for such changes? I can't find anything related in the log.

Edit:
Found it. Must be rev265c411c39f498f95a03517818167b47b754c440.

101

Window / [solved] Weird Window-Sizes on MacOS

« on: November 12, 2014, 11:01:50 am »

Hi.

I'm using MacOS 10.9 and SFML 2.1 on a MacBook Pro (NVIDIA GeForce GT 750M) with retina display (2560x1600). SFML only lists me video-modes up to 1680x1050 and it looks like the window gets scaled up about twice in size. Even the system-specific window-buttons to close or minimize the app only show in half resolution compared to all other apps.
I don't have such issues with other games. For example Diablo 3 always has the correct size and even allows retina resolution.

Any ideas what's going on? The SFML-sample-applications or Xcode-Templates behave the same by the way.

102

Graphics / Re: Requesting a Stencil Buffer on sf::RenderTexture?

« on: April 24, 2014, 10:51:28 am »

I just wanted to say thanks for helping me where to add the proper stencil support for RenderTextures. I guess I would have missed the FBO-version.
Some more stuff is required to work properly though. The "clear" method needs to also check for enable stencil buffering to set the right flag (GL_STENCIL_BUFFER_BIT) and to set the correct StencilMask before clearing (typically 0xFF).
Great post nonetheless!

103

System / Re: [2.0] Using a thread to load game resources

« on: May 11, 2013, 12:12:59 pm »

glFlush() solves the issue indeed. My bad, thanks a lot! 

The texture actually doesn't show in the sample above. In my real code it does.

104

System / Re: [2.0] Using a thread to load game resources

« on: May 11, 2013, 11:00:03 am »

Here you go.
Access violation in ~RenderWindow -> ~Window ->... ~WglContext -> wglDeleteContext()
I assume the destruction of the texture causes the problem, because it is deleted in another thread than in which it had been created in. But I have no such issues in my own engine and I have also no idea how to bypass this in SFML.

#include <SFML/Window/Event.hpp>
#include <SFML/System/Thread.hpp>
#include <SFML/Graphics/RenderWindow.hpp>
#include <SFML/Graphics/Texture.hpp>

int main(int argc, char* argv[])
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "access violation in destructor");

    bool loaded = false;

    sf::Texture* tex;
    sf::Thread thread([&](){tex = new sf::Texture(); loaded = tex->loadFromFile("res/img/gui/Window.png");});
// same in this version:
//    sf::Texture* tex = new sf::Texture();
//    sf::Thread thread([&](){loaded = tex->loadFromFile("res/img/gui/Window.png");});

    thread.launch() ;

    while ( window.isOpen() )
    {
        sf::Event event ;
        while ( window.pollEvent(event) )
        {
            if ( event.type == sf::Event::Closed )
                window.close() ;
        }
        if(loaded)
            window.setTitle("Thread done, close now");
    }
    delete tex;

    return 0; // Access violation here - in ~RenderWindow -> ~Window ->... ~WglContext -> wglDeleteContext()
}

105

System / Re: [2.0] Using a thread to load game resources

« on: May 10, 2013, 08:54:47 pm »

Is there any news on that? I have a similar issue on 2 of 3 PCs with that. Loading all works fine, but when closing the Window and internally wglDeleteContext gets called, an access violation is thrown. When loading stuff without using a thread, everything is fine. Loading from within an sf::Thread causes trouble.
(ATI card)
I created other games with GL before and also loaded my stuff in separate threads and never had that issue there.