Topics

1

General discussions / Android GL context loss

« on: April 15, 2015, 11:19:09 am »

It is well known that Android will "randomly" decide to kill the GL context of apps that is switched to the background or if your device goes to sleep, etc.  If that happens all your textures are lost when the context is lost.

Its hard to find a device to reproduce this problem consistently, so debugging/fixing is not easy.  We only hear about it from people using the app.

Does SFML recreate the GL context when it is lost?  The way to do it, according to Google, is when you try to do a eglSwapBuffers, and get an error, the error returned will be that one of the 3 parts of the context is lost.  Surface/Display/<Something else>.  So doing a proper shut down of everything and recreating when that happens seems like a simple thing to do.

The harder part is to reload all the textures that is lost, but this is not SFML's responsibility. There should however be some way to tell if the context was recreated or not at runtime so that the app can respond appropriately.

Some input would be appreciated.

2

General discussions / Close Android Activity

« on: December 02, 2014, 02:26:57 am »

What is the best practice to close an android activity?

In the example it checks for Event::Closed, which is when Android requests that the activity closes, but how do I request that the activity close?  Do I just call window.close() on some event?

3

General discussions / Android access to activity

« on: July 07, 2014, 01:28:40 pm »

The Android port handles the NativeActivity interface internally and wraps everything up nicely so that you can only have a main() in your code.

All the NativeActivity stuff is stored internally, but in some cases users might want access to those to make JNI calls.  Maybe to use Google Play or Google Play Games services.  Or even just some custom libraries that exist on the Java side of things.

You can get access to all those things through one simple interface, but there are a few problems with that.

The biggest problem is that it is not part of the "public" API of SFML.  Does SFML expose platform specific calls at all?

Second issue is that generally when those pointers are accessed, they main NativeActivity thread should be locked.  So you can't just expose the pointers, because they are "owned" by the NativeActivity thread.

A general guide is to have a locking interface like this:

  sf::ActivityStates* states = NativeActivityAttachToThread();  // Locks the mutex.
  // ...make your JNI calls...
  NativeActivityDetachFromThread();

Would there be an nice enough way to add this to SFML?

4

General discussions / Android static linking

« on: June 05, 2014, 03:26:07 am »

I'm currently looking into building the android flavor of SFML as a static library and linking against them.  SFML has hard coded the fact that libraries are dynamic in the "glue" code, but i can't really find a place where this design choice and motivation is discussed, etc.

I've already started to poke at the code and came up with a few ideas, but if someone else also thought about this I would love to hear your comments.  Maybe we can come up with a more concrete plan to move forward with if possible.

5

Window / Vertical Sync clarification

« on: January 23, 2014, 12:17:45 pm »

Testing the following code:

#include <iostream>
#include <vector>

#include <SFML/Graphics.hpp>

int main(int argc, char* argv[]) {
  sf::RenderWindow window(sf::VideoMode(800, 600, 32), "Render window");
  window.setVerticalSyncEnabled(true);

  sf::RectangleShape rr(sf::Vector2f(20.f, 20.f));

  while (window.isOpen()) {
    sf::Event evt;
    while (window.pollEvent(evt)) {
      if (evt.type == sf::Event::Closed)
        window.close();
    }

    window.clear(sf::Color::Blue);

    sf::Clock clock;

    rr.setPosition(0, 0);
    window.draw(rr);

    sf::Int64 time1 = clock.restart().asMicroseconds();
    std::cout << "1: " << static_cast<double>(time1) / 1000.0 << std::endl;

    rr.setPosition(20, 20);

    window.draw(rr);

    sf::Int64 time2 = clock.restart().asMicroseconds();
    std::cout << "2: " << static_cast<double>(time2) / 1000.0 << std::endl;

    window.display();

    sf::Int64 time3 = clock.restart().asMicroseconds();
    std::cout << "3: " << static_cast<double>(time3) / 1000.0 << std::endl;

  }

  return 0;
}
 

Timing all the intervals between draws it seems that vertical sync is enforced before the first draw call is made in stead of when calling display(), which seemed more sensible in my opinion, because drawing to a back buffer doesn't nescessarily mean your going to swap it.

This can be tested by moving the .clear call to after creating the clock, then the first time is about the time of a  single vsync'd frame.

I understand that on windows at least the wglSwapIntervalEXT call sets the number of frames that is allowed to be swapped per screen refresh cycle.  Is this the way it's supposed to be enforced?  Is this the same for all other platforms?

I'm using NVIDIA drivers.