Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Fizix

Pages: [1] 2
1
General discussions / Re: Android GL context loss
« on: April 15, 2015, 03:08:38 pm »
Do you have something concrete in mind, from a user perspective? Can an external library really help here?

Not really.  I went through the thor resource manager a few weeks ago and remembered it also kept track of the resources loaded.  Our own resource manager keeps track of the location where a texture was loaded from as well as the actual sf::Texture object.  So for us it is easy to just go through each one and reload them from disk in a single call.

This has some flaws, like not being able to recreate textures that were generated and stored in memory, other than of course keeping them stored in main memory.  But this isn't a requirement for our system.

2
General discussions / Re: Android GL context loss
« on: April 15, 2015, 12:16:21 pm »
Of course it is not random, hence the quotes. ;)

Keeping track of all the GL resources internally would not be a good idea.  I think it is just one of those things that users should be aware of when using textures on the Android platform and deal with it appropriately.

This would be a great opportunity for thrid party libraries, like thor, to include this in their custom resource managers perhaps.

I don't think adding a new event to handle this specific situation on this specific platform is part of the SFML way.  So using an existing event would be preferred I guess?  The focus change event seems like a good place to do it, but then we need some state to check to see if the context was recreated or not.  I think this is where the biggest questions come in as far as SFML development goes.

Can we put it in the ActivityState?

3
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.

4
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?

5
General discussions / Re: Android access to activity
« on: October 14, 2014, 12:42:30 am »
I'm aware of that, but passing the whole struct is out of question right now I guess, especially considering that's all subject to change and not exposed/public so far.

What is about to change?

There isn't much you can do with a handle to the ANativeWindow*, that SFML doesn't handle already, but for completeness, I guess returning it in sf::Window::getSystemHandle would be good.

This doesn't solve the problem of getting to the Java environment and making JNI calls though, but fitting that into the public interface is a bigger problem in itself I guess.

6
General discussions / Re: Android access to activity
« on: October 13, 2014, 01:16:39 pm »
Actually the thing we are trying to get at is the ActivityStates object, and not the activity handle or the window handle.

The ActivityStates object holds all relevant data for the currently running Android app/activity, so it work to make it the equivalent of a "process handle" on other platforms.

I guess the question is just what do you return for the other platforms, if anything at all.

7
General discussions / Re: Android access to activity
« on: October 13, 2014, 03:47:50 am »
On Android you can only have one instance of sf::Window anyway, so you can't return a handle per window even if you wanted to.

Returning the activity from sf::Window::getSystemHandle() makes sense.

8
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?

9
General discussions / Re: Android static linking
« on: July 07, 2014, 01:11:57 pm »
Just an update to what I've found so far.  I was able to link statically with SFML on Android after I followed these steps.

I changed BUILD_SHARED_LIBS in the cmake file to be false (it is currently hard coded to true)
After building, there are -s variants of the libs in the ndk directory.  e.g. sfml-system-s.a, sfml-graphics-s.a
The Android.mk file already has -d flavor of libraries, so I added a -s option with all the libraries set to link statically.
I also changed the c++_shared option to c++_static.

The activity must also be changed not to use sfml-activity as the main native library any more, but just the example library.  The sfml-main module was set up so that it also has a NativeActivity entry point, which works out well.  This is also why it should be set as LOCAL_WHOLE_STATIC_LIBRARIES, so that the entry point doesn't get stripped.

I might have left out some steps, but this is the general idea to do it.

There is one big issue with this.  The sound libraries are still dynamic, so using the audio module will crash the app, because those libraries aren't loaded by the sfml-activity any more.  Linking them statically is possible, but there is an ongoing issue about that if I remember correctly.


10
General discussions / Re: Android static linking
« on: June 06, 2014, 05:15:24 am »
Yes the entry point is stripped from the .so because it's not references, but there are ways around this.  There are compiler switches, which I don't know if it'll work on android toolchain.  The ndk sample glue code also has this problem and they use a dummy function to force the entry point to be referenced.

So it would just be a matter of finding the most elegant solution.

11
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.

12
General discussions / Re: Android and iOS ports available for testing
« on: January 27, 2014, 09:20:26 am »
I also got the EGL_BAD_ALLOC, and setting the width and height to 1 in the attribs for creating the pbuffer solved it for me and rendering continued as normal.

13
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.

14
SFML projects / Re: Chesster [SFML Puzzle Game]
« on: January 15, 2014, 10:38:42 am »
Very nice! You have my vote.

15
Window / Re: Render and event loop in different threads?
« on: January 13, 2014, 03:54:42 pm »
Don't try to poll the events on another thread.  Poll events on the main thread and once an event is available, add it to your own queue (std::queue<sf::Event>?), which gets processed in a loop on a different thread.

Synchronizing the two threads can not be avoided and you'll end up with the main thread having to wait for the event thread and vice versa, which is worse than just doing both on the main thread in the first place.

You might want to look into task based parallelism.

Pages: [1] 2
anything