SFML windowing system on Android, anyone?

[Spidyy]

Hello there.

I'm doing a game for Android, and I'm using SFML architecture to implement an "Android port" of the system in C++. I did some changes as we can have only one display on a mobile device (for now), so I simplified it a bit, but I'm trying to keep the Context system as is.

But right now, I'm having difficulties properly implementing Context with EGL, even understanding how the Context, GlContext and WGlContext class operate together.

Did anyone already ported a bit of the SFML windowing module to native Android?

[eXpl0it3r]

There has been some quick (& dirty) semi-port, you can/should use the search function of this forum to find it.

[Spidyy]

Oh well, I looked the topics you were talking about, and my conclusion is, I can't adapt SFML as is for Android. The sfml contexts are made so that GL resources are not deleted while the window is closed, but on Android, it is specified that a closed or sleeping app must free the memory to avoid hindering the other running apps, meaning the display and context must be destroyed any time the activity is not visible.

Thus I'll just create my own context managing, with one main context linked to the activity, and other contexts sharing the main one to allow threaded resource loading.

Honnestly, from what I saw, it would need to make a special SFML Window module specificaly for mobile devices, not just adapt the existing one, as managing a mobile app is really different from managing a desktop program.

[eXpl0it3r]

Well SFML isn't compatible with Android, thus you can't asume that one can port everything with just some minor changes.
But your findings sound correct to me.

[timo777]

Spidyy, as far as I know the memory doesn't have to be freed if the app is not visible. On my android tablet the RAM use can grow from 1 gigabyte to nearly 2 gigabyte with opening some applications. So why should it unload all graphical stuff and not the other things? They could both be saved (temp ofcourse) to the harddrive.

[eXpl0it3r]

So why should it unload all graphical stuff and not the other things? They could both be saved (temp ofcourse) to the harddrive.

And what's the difference between 'unloading' and writing everything to the 'harddrive'?
Yep: none. Because things will have to get taken out of memory and put on the SD space and to get them back on screen they need to get loaded back into memory and thus the approach SFML goes with a global & 'shared' context doesn't work, since it assumes that the memory is never unloaded.

@Spidyy: Will you ever release the new stroke class version?

[timo777]

You could pause the hole program so it does function like it would function normally. But this would just be a cheap fix.

[eXpl0it3r]

You could pause the hole program so it does function like it would function normally. But this would just be a cheap fix.

I'm not familiar with Android development so I can't really judge it.
From the PC point of you I only know that the OpenGL states and the contexts aren't the most stable things, so I could only guess that one could loose them by pausing/writing to 'disk space' (how's that properly call on Android? SD card?)....

[Spidyy]

Well stoke, huuuh... Maybe not, I'm not working on it at all right now.

You are speaking about tablet with 1 to several gig of ram, but what about smaller smartphones with 256/512mo ram, without speaking about the video memory not that huge? We need to unload what we can on those, or else the user will not even be able to load its phone application. :p