The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

First first, great stuff for Android, for working out of the box.


SDL Friends Libraries could tie up better (full all in android-full-project) for better set up experience (PNG & OGG Fan .

App fails to exit after main()'s return (needs a heavier exit()). Seems Android's java SDLActivity threading issue.

SDL2_net got no Android.mk, easily doable though, 4/5 source files, no deps.


Giving Back To Open Source ++ :-)

Oh, also to get it compiled there is some external deps issue, the jni directory currenlty needs some links:
  1 $ ls -lh jni
  2 
  3 Android.mk
  4 Application.mk
  5 libmikmod-3.1.12 -> SDL2_mixer-2.0.0/external/libmikmod-3.1.12/
  6 libwebp-0.3.0 -> SDL2_image-2.0.0/external/libwebp-0.3.0/
  7 SDL2-2.0.3
  8 SDL2_image-2.0.0
  9 SDL2_mixer-2.0.0
 10 SDL2_net-2.0.0
 11 SDL2_ttf-2.0.12 
 12 smpeg2-2.0.0 -> SDL2_mixer-2.0.0/external/smpeg2-2.0.0/
 13 src


And that needs to be reflected in the SDLActivity.java:
  47     // Load the .so
  48     static {
  49         System.loadLibrary("SDL2");
  50         System.loadLibrary("SDL2_image");
  51         System.loadLibrary("mikmod");
  52         System.loadLibrary("smpeg2");
  53         System.loadLibrary("SDL2_mixer");
  54         System.loadLibrary("SDL2_ttf");
  55         System.loadLibrary("SDL2_net");
  56         System.loadLibrary("main");
  57     }
  58 

Ideally none of the external deps should be exposed so explicitily, done with freetype, libogg, etcetera, but for the run...




Here is the mentioned SDL2_net-2.0.0/Android.mk i use, I link though i still do not call anything of it:
  1 LOCAL_PATH := $(call my-dir)
  2 
  3 include $(CLEAR_VARS)
  4 
  5 LOCAL_MODULE := SDL2_net
  6 
  7 LOCAL_C_INCLUDES := $(LOCAL_PATH)
  8 
  9 LOCAL_SRC_FILES := SDLnet.c SDLnetTCP.c SDLnetUDP.c SDLnetselect.c
 10 
 11 LOCAL_SHARED_LIBRARIES := SDL2
 12 
 13 LOCAL_EXPORT_C_INCLUDES += $(LOCAL_C_INCLUDES)
 14 
 15 include $(BUILD_SHARED_LIBRARY)



That's all,



On Thu, Apr 10, 2014 at 2:59 PM, Juan Manuel Borges Caño wrote:

Add to it the SDl2_image jpeg x86 .S arm asm issue.

This one wasn't easy to find, Any way to catch physical buttons Menu and Back? and while at it say, the full Android Physical Buttons, Power, Volume Up, Down, Camera, ... The SDLK table seems very PC centric.


Anyone reading? Cause i'm assuming



On Thu, Apr 10, 2014 at 4:28 PM, Juan Manuel Borges Caño wrote:

Menu is SDL_SCANCODE_MENU and back is SDL_SCANCODE_AC_BACK. Not sure about the others.


The app failing to exit is just how Android works. The intention is that it allows the app to quickly come back up again if the user opens it again. You can use it as an opportunity to save resources so they don't have to be loaded again, or you can call exit() to force close the process and make sure it's reloaded afresh next time, but this doesn't always look as smooth.



2014-04-20 0:49 GMT+02:00 Juan Manuel Borges Caño:



--
Jorge "Vino" Rodríguez
[ Tw | Fb | G+ | Ht ]

Jorge Rodriguez, the SDL_SCANCODE_* are good news, thanks, didn't knew about that as an option for Key/Button events, works great , the lack of internet documentation on forums, posts, etc. made it hard to find as of date. Good stuff, thanks!


Design Discussion:


If i code an explicit code flow end when say the users presses Back Button, main returning EXIT_SUCCESS, behaving in another way is not the C expected behaviour, the app thread is tricky and not following the expectation on flow behaviour. Not that i find the resource cached loading bad, but i would consider to do it myself, say, with some app backgrounding call, how many apps until you get out of memory?, performance?, batteries? speed?. Say my app is gonna be heavy load, play once, 20 minutes, close it for long, cached resources is not an issue or a need, thank I can close the app with an exit().

SDL_SetLogicalSize( ..., w, h), is kind of misleading in that okay, what ever your design decision was you request aspect ratio matchs display mode or stretching, occurs, but then why take redundant w, h, just say take an scale factor, SDL_SetLogicalScale(..., s) since if i would want an stretching, i would set it with the display mode and "window" creation. Important things: misleading params, consider LogicalScale, stretching mades sense for create window.


I've read Ryan Gordon say, "Don't harcode your app to any sizes", but that hardcodes to some physical ratio a logical size. No big deal, i just set logical height and width = height * ratio, but kind of makes more sense. To admit, i think he's right and i should have gone, probably gonna rewrite, screen space on dstrects instead of image space .


Anyway, not work stoppers, Thanks!








On Sun, Apr 20, 2014 at 4:14 PM, Jorge Rodriguez wrote:

2014-04-23 13:44 GMT+02:00 Juan Manuel Borges Caño:


Once a normal exit occurs (ie, the main() function returns) the program binary sits in memory invisible to the user (not in the Android task list) until the Android OS decides it wants to reclaim the memory. Then the process is killed and all memory is then freed. This happens automatically and you don't need to do anything. It probably uses some kind of recency algorithm to decide when to kill what processes. If you want your app to remain closed for a long time then either force an exit with exit(), or make sure you free all resources before your main() exits and trust Android to kill the process when it feels best about it. On my tablet if you force an app to close with exit() the close animation doesn't play and it's not as pretty, so I did the work to make sure I freed everything.



--
Jorge "Vino" Rodríguez
[ Tw | Fb | G+ | Ht ]

Ok, so on a side, i'd like to note that for stopping music when app goes background:

There is a recent thread about it, her advice works greatly, catching SDL_APP_WILLENTERBACKGROUND to Pause and SDL_APP_WILLENTERFOREGROUND to Resume.


Continuing on the exit issue, so when i do return EXIT_SUCCESS; from my jni/main.c main() flow, if the app is demanded by the user again, the app would restart as usual, only if i don't explicitly killed the assets memory, they are still there?

To clarify:


int

main()
{

  Assets *assets;

  assets = LoadAssets();

  while(!done)

   Use(assets);

  return EXIT_SUCCESS;
}


I can't use a NULL or NOT approach, since i'd have to set the assets to NULL at start, if the app restart as usual, the assets would reset to NULL, just not freed, and reloaded again.


So what i need seems an obscure, by that i mean, not explicity, event for SDL_APP_WILLEXIT that in fact, will not exit, and then can recover with an SDL_APP_WILLRECOVER. Or if assets can be reused from main i don't see how.


At the end i'm gonna think i need/use an SDL_Foreground() equivalent.


Cares to just clarify, with such a simplistic, not detailed, generic example?




On Wed, Apr 23, 2014 at 2:43 PM, Jorge Rodriguez wrote:

OK, i'm fine with exit, by the way, i think we confuse the "suspend app" "middle" button with the "close app" "left" ("arrow") button.



On Mon, Apr 28, 2014 at 1:18 PM, Juan Manuel Borges Caño wrote:

Does sdl define some kind of macro like SDL_MOBILE or SDL_DESKTOP? So i don't need to check manually ANDROID or IOS not saying the ones i don't even know and would force reediting (of my local SDL_MOBILE ).