SDL port for Android SDK/NDK 1.6

Quickly share your Android Code Snippets here...

Re: SDL port for Android SDK/NDK 1.6

Postby confi » Sat Jun 02, 2012 10:32 am

Hello,

not much posts here these days, hope someone's still there :)

maybe it has already been asked but I did not find an answer with the search feature : I would like my SDL application to terminate properly using a keypress for instance. Is it possible? as for now I am forced to kill the app via the android application management menu.
confi
Junior Developer
Junior Developer
 
Posts: 15
Joined: Tue Dec 27, 2011 11:12 pm

Top

Re: SDL port for Android SDK/NDK 1.6

Postby confi » Sat Jun 02, 2012 10:39 am

ok I found my answer, simply call exit(1) :S
confi
Junior Developer
Junior Developer
 
Posts: 15
Joined: Tue Dec 27, 2011 11:12 pm

Re: SDL port for Android SDK/NDK 1.6

Postby PanaceaSupplies » Mon Jul 09, 2012 5:26 am

Hey Everyone.

So I've posted the source code of four ports of SDL games to Android - http://github.com/dennis-sheil/commandergenius/branches

Three of these are on Google Play. They were released between late May to late June of this year. Two of them each have over 1100 downloads and over 675 active installs.

I've written a blog post ( http://www.vartmp.com/blog/2012/06/20 ) on this. Some of my points here are a repeat of them. The main issues I've come across in porting these and other SDL programs again and again are:

  • The C++ code says to run in hardware mode instead of software mode when Android can not do so.
  • Looking for directories with configuration files and graphics can be another problem, you have to set it up properly.
  • Check if it is looking for defines in a config.h file. These defines will have to be set properly for Android. Also look for similar defines not in the config.h files, like a define for LOCALE or the like.
  • The SDL_SetVideoMode call might have parameters Android can not handle
  • Pelya's framework script does not compile C++ files with a suffix of cc instead of cpp.
  • Stuff from iostream like cout and cerr do not work out of the box. Neither do XM audio files

These are the main things I have to change to get SDL games working on Android.

As Pelya says "The screen is always double-buffered, and after each SDL_Flip() there is garbage in pixel buffer,
so forget about dirty rects and partial screen updates - you have to re-render whole picture each frame."

So I often replace SDL_UpdateRect in the code with SDL_Flip().

I also am explicitly listening to KeyEvent.KEYCODE_VOLUME_DOWN or KeyEvent.KEYCODE_VOLUME_UP and manually implementing adjustVolume if Pelya's files are grabbing the volume up/down button. I believe Pelya says you can turn off that redefinition of keys in the configuration file.

Pelya has an EditText box pop up when screen input is needed. I've played around with that a little - putting it in different sections of the screen, changing the color etc. We can do more with this I'm sure. Then there's the whole issue of when to and when not to pop up the on-screen keyboard.

The on-screen 1 and 2 buttons I set to unique issues in some cases. That's for a game I have not put up - Ice Breaker, which I ported.

I'd also like to bring stuff like ads like Admob more into JNI (or in Video.java or the like, turned on and off from the C++ code).

I'm very interested in getting the gettext functionality working with JNI. Unfortunately, the libc Android uses, bionic, does not include specific locale info.
PanaceaSupplies
Freshman
Freshman
 
Posts: 7
Joined: Fri Dec 02, 2011 6:17 am

Re: SDL port for Android SDK/NDK 1.6

Postby pelya » Mon Jul 09, 2012 3:10 pm

PanaceaSupplies wrote:The C++ code says to run in hardware mode instead of software mode when Android can not do so.

Do you mean setting SDL_HWSURFACE inside SDL_SetVideoMode(), then not using HW surfaces properly? I've hit that problem way too often myself, and I'll probably just force SDL to use SW surfaces, based on the SwVideoMode=y setting inside AndroidAppSettings.cfg, and ignore whatever flags application requests.
Currently there are just two SDL applications that properly use HW surfaces - Alien Blaster and Pachi (and I've modified both heavily).
With SDL 1.3 things are much easier, because HW-accelerated surfaces are renamed to SDL_Texture, and there are many examples in the documentation how to use them.
Also, almost any Android device sold today will render SW surfaces fast enough, so there's no need to sacrifice the familiar way of how things are working for the sake of a little rendering speed gain.

PanaceaSupplies wrote:Looking for directories with configuration files and graphics can be another problem, you have to set it up properly.

Most games expect their current directory to contain data files, I did not have many issues with that. On the other hand, if you're using "configure" script - it will be a pain regardless of how many hacks and workarounds you'll implement. You might try to set "--datadir=.", however your best chances are to modify source files.

PanaceaSupplies wrote:Check if it is looking for defines in a config.h file. These defines will have to be set properly for Android. Also look for similar defines not in the config.h files, like a define for LOCALE or the like.

Well, SDL repo has the script setEnvironment.sh which should take care of the most things that unholy configure script wants to be defined, check for example the scripts AndroidBuild.sh inside project/jni/application/milkytracker (the good example) or project/jni/application/openttd (the bad bad ugly hacky example).
AndroidBuild.sh is called when you have CustomBuildScript=y inside AndroidAppSettings.cfg.
Anyway, there will always be applications where my wrapper script will fail, and you'll have to compile the sources directly, and just guess the correct CFLAGS.

PanaceaSupplies wrote:The SDL_SetVideoMode call might have parameters Android can not handle

Yeah, I'll fix that, see my earlier reply (I suppose you're talking about SDL_HWSURFACE).

PanaceaSupplies wrote:Pelya's framework script does not compile C++ files with a suffix of cc instead of cpp.

Good point, I've fixed that.

PanaceaSupplies wrote:Stuff from iostream like cout and cerr do not work out of the box. Neither do XM audio files

C++ thingies should just work if you have a recent SDL sources and a recent NDK (r7 or r8).
SDL_mixer has support for .XM files for quite some time already, you may also directly use mikmod library. I've just written a simple test for it, and it works on my side.

PanaceaSupplies wrote:As Pelya says "The screen is always double-buffered, and after each SDL_Flip() there is garbage in pixel buffer,
so forget about dirty rects and partial screen updates - you have to re-render whole picture each frame."

So I often replace SDL_UpdateRect in the code with SDL_Flip().

SDL_UpdateRect() simply calls SDL_Flip() internally, I've made it that way long ago, because most apps just misuse SDL_UpdateRect(), and actually expect whole screen to be updated, and SDL for Windows/desktop Linux/MacOsX works exactly that way.

The worst application in that regard is MilkyTracker - with the special flag CompatibilityHacks=y inside AndroidAppSettings.cfg I'm forcing SDL to actually ignore SDL_Flip() or SDL_UpdateRect() calls from MilkyTracker, and update the screen 100 ms afterwards, that solves the ugly screen flickering.

PanaceaSupplies wrote:I also am explicitly listening to KeyEvent.KEYCODE_VOLUME_DOWN or KeyEvent.KEYCODE_VOLUME_UP and manually implementing adjustVolume if Pelya's files are grabbing the volume up/down button. I believe Pelya says you can turn off that redefinition of keys in the configuration file.

Yeah, you can force those keys to change volume by setting RedefinedKeys="XXX YYY NO_REMAP NO_REMAP ZZZ", that is, set third and fourth keycode to NO_REMAP. I've updated readme file, please tell me if that's clear enough.

PanaceaSupplies wrote:Pelya has an EditText box pop up when screen input is needed. I've played around with that a little - putting it in different sections of the screen, changing the color etc. We can do more with this I'm sure. Then there's the whole issue of when to and when not to pop up the on-screen keyboard.

I've tried another approach in MilkyTracker built for tablets, when it invokes keyboard without EditText, right over application window, it works on Galaxy Note but does not work on HTC Evo, so there's probably something wrong with my code. You can enable that mode by setting CompatibilityHacksTextInputEmulatesHwKeyboard=y inside AndroidAppSettings.cfg.
Also I'm always accepting your patches :D

PanaceaSupplies wrote:I'd also like to bring stuff like ads like Admob more into JNI (or in Video.java or the like, turned on and off from the C++ code).

I'm planning to publish an ad-supported game myself, and I'm planning to add support for AdMob into SDL, along with methods to control it from C code. I think I'll do that during August.

PanaceaSupplies wrote:I'm very interested in getting the gettext functionality working with JNI. Unfortunately, the libc Android uses, bionic, does not include specific locale info.

I've ported several games which use gettext (it's called intl or libintl in the sources) - OpenTTD, UfoAI and Free Heroes 2, however all of them have a language option inside settings (or inside .cfg file in the case of Free Heroes 2), also all these apps add a custom search path to libintl, so that it will use current application directory instead of usual location like /usr/share - see bindtextdomain or an example here. SDL sets environment variables LANG and LANGUAGE to the current device language setting, so gettext should know what language to use (in theory, I never checked whether this actually work).

Also, few things from your blog:

PanaceaSupplies wrote:Sergii "Pelya" Pylypkeno

Please don't call me that - my name is Sergii Pylypenko, "pelya" is not capitalized, and please don't squish my nick inbetween my name and surname, I'm not a boxer.

PanaceaSupplies wrote:He published then unpublished Jooleem. I thought it was pretty cool and e-mailed him saying I wanted to release it, but was there some unknown reason he unpublished it to Google Play. He said there wasn't, so I did some work on it, then published it.

The only reason is that I was pissed because users gave poor ratings to Jooleem. Now I don't care about ratings that much. I'll probably update TeeWorlds and publish it back, when I'll have some free time during August.
pelya
Master Developer
Master Developer
 
Posts: 323
Joined: Mon Nov 23, 2009 11:31 am

Re: SDL port for Android SDK/NDK 1.6

Postby PanaceaSupplies » Wed Jul 11, 2012 9:42 am

pelya wrote:
PanaceaSupplies wrote:The C++ code says to run in hardware mode instead of software mode when Android can not do so.

Do you mean setting SDL_HWSURFACE inside SDL_SetVideoMode(), then not using HW surfaces properly? I've hit that problem way too often myself, and I'll probably just force SDL to use SW surfaces, based on the SwVideoMode=y setting inside AndroidAppSettings.cfg, and ignore whatever flags application requests.
Currently there are just two SDL applications that properly use HW surfaces - Alien Blaster and Pachi (and I've modified both heavily).
With SDL 1.3 things are much easier, because HW-accelerated surfaces are renamed to SDL_Texture, and there are many examples in the documentation how to use them.
Also, almost any Android device sold today will render SW surfaces fast enough, so there's no need to sacrifice the familiar way of how things are working for the sake of a little rendering speed gain.

Yes. An example of this is in the Tuxmath port mathgame, I turn off HW-acceleration because it can not handle it as is

http://github.com/dennis-sheil/commande ... c795110d02

pelya wrote:
PanaceaSupplies wrote:Looking for directories with configuration files and graphics can be another problem, you have to set it up properly.

Most games expect their current directory to contain data files, I did not have many issues with that. On the other hand, if you're using "configure" script - it will be a pain regardless of how many hacks and workarounds you'll implement. You might try to set "--datadir=.", however your best chances are to modify source files.

I've had issues, but usually small issues. If you're lucky, the data will be in a sub-directory, but that is not always the case. For instance, in ri-li, the sounds are in the Sounds subdirectory, I moved the Sounds directory to be a data sub-directory - http://github.com/dennis-sheil/commande ... a4d5c95c65 . In the hex-a-hop port lilyhop, we need to define the DATADIR macro as "." http://github.com/dennis-sheil/commande ... c986fd06cf

Like you said, your best chance is in modifying (or moving) the source files. You just have to go through the code to find which directories, files, macros etc. are needed. Or debug it later if there is a problem.

pelya wrote:
PanaceaSupplies wrote:Check if it is looking for defines in a config.h file. These defines will have to be set properly for Android. Also look for similar defines not in the config.h files, like a define for LOCALE or the like.

Well, SDL repo has the script setEnvironment.sh which should take care of the most things that unholy configure script wants to be defined, check for example the scripts AndroidBuild.sh inside project/jni/application/milkytracker (the good example) or project/jni/application/openttd (the bad bad ugly hacky example).
AndroidBuild.sh is called when you have CustomBuildScript=y inside AndroidAppSettings.cfg.
Anyway, there will always be applications where my wrapper script will fail, and you'll have to compile the sources directly, and just guess the correct CFLAGS.


An example is lilyhop where files like i18n.h and system-relative.c have "#ifdef HAVE_CONFIG_H" calls and other references to macros in config.h.

http://github.com/dennis-sheil/commande ... d10e2676fe

The setEnvironment script does not always handle everything that the code asks for. As you said, you can do a custom script like milytracker does. I just created a config.h file and manually filled in a few blanks, hopefully correctly.

pelya wrote:
PanaceaSupplies wrote:The SDL_SetVideoMode call might have parameters Android can not handle

Yeah, I'll fix that, see my earlier reply (I suppose you're talking about SDL_HWSURFACE).


SDL_HWSURFACE was a big one. I had some trouble with SDL_DOUBLEBUF sometimes

http://github.com/dennis-sheil/commande ... cfede21c0c

Looking through the code and making sure sane SDL_SetVideoMode calls are being made is always a good idea. Because anything can be happening.

elya wrote:
PanaceaSupplies wrote:Pelya's framework script does not compile C++ files with a suffix of cc instead of cpp.

Good point, I've fixed that.

Cool!

pelya wrote:
PanaceaSupplies wrote:Stuff from iostream like cout and cerr do not work out of the box. Neither do XM audio files

C++ thingies should just work if you have a recent SDL sources and a recent NDK (r7 or r8).
SDL_mixer has support for .XM files for quite some time already, you may also directly use mikmod library. I've just written a simple test for it, and it works on my side.

OK, I will double check that.

pelya wrote:
PanaceaSupplies wrote:As Pelya says "The screen is always double-buffered, and after each SDL_Flip() there is garbage in pixel buffer,
so forget about dirty rects and partial screen updates - you have to re-render whole picture each frame."

So I often replace SDL_UpdateRect in the code with SDL_Flip().

SDL_UpdateRect() simply calls SDL_Flip() internally, I've made it that way long ago, because most apps just misuse SDL_UpdateRect(), and actually expect whole screen to be updated, and SDL for Windows/desktop Linux/MacOsX works exactly that way.

The worst application in that regard is MilkyTracker - with the special flag CompatibilityHacks=y inside AndroidAppSettings.cfg I'm forcing SDL to actually ignore SDL_Flip() or SDL_UpdateRect() calls from MilkyTracker, and update the screen 100 ms afterwards, that solves the ugly screen flickering.

I have a few code tree branches, some are up-to-date, some have not been updates since April/May. Anything I'm hitting a problem with I'll merge your newer changes in and try again.

pelya wrote:
PanaceaSupplies wrote:I also am explicitly listening to KeyEvent.KEYCODE_VOLUME_DOWN or KeyEvent.KEYCODE_VOLUME_UP and manually implementing adjustVolume if Pelya's files are grabbing the volume up/down button. I believe Pelya says you can turn off that redefinition of keys in the configuration file.

Yeah, you can force those keys to change volume by setting RedefinedKeys="XXX YYY NO_REMAP NO_REMAP ZZZ", that is, set third and fourth keycode to NO_REMAP. I've updated readme file, please tell me if that's clear enough.

I will take another look at it. It's working for me either way, but your way would be a little easier, and more Android-proper.

pelya wrote:
PanaceaSupplies wrote:Pelya has an EditText box pop up when screen input is needed. I've played around with that a little - putting it in different sections of the screen, changing the color etc. We can do more with this I'm sure. Then there's the whole issue of when to and when not to pop up the on-screen keyboard.

I've tried another approach in MilkyTracker built for tablets, when it invokes keyboard without EditText, right over application window, it works on Galaxy Note but does not work on HTC Evo, so there's probably something wrong with my code. You can enable that mode by setting CompatibilityHacksTextInputEmulatesHwKeyboard=y inside AndroidAppSettings.cfg.
Also I'm always accepting your patches :D

Mostly what I've been working with is games which are almost exclusively mouse-only, but then for high scores or something have extensive keyboard use. What I have been doing is a lot of manual tweaking, very kludgey. For example, figuring out generic width and height multiples and then multiplying DisplayMetrics.widthPixels and heightPixels by them. Then perhaps doing a different parameter to _screenKeyboard.setTextSize depending on DisplayMetrics.heightPixels. For a one-time thing, it has worked for me but is kludgey. Better would be to look at where SDL is putting the text and putting it there.

Jooleem actually had a blinking cursor - which I disabled (CURSOR_BLINK to 0, m_blinking = false, commented out some code for good measure).

As I said, what I have done has been unique kludges, but if I write some code where I pull the cursor screen location from SDL and set it on EditText that way, and it works, I'll send you a patch.

pelya wrote:
PanaceaSupplies wrote:I'd also like to bring stuff like ads like Admob more into JNI (or in Video.java or the like, turned on and off from the C++ code).

I'm planning to publish an ad-supported game myself, and I'm planning to add support for AdMob into SDL, along with methods to control it from C code. I think I'll do that during August.

Very cool. What I've been doing is putting an initial screen Activity to the app with an ad, and then I'll launch the app. But my click-through-rate is very low. If I can place it in a good place in the app it might be good.

I have never used TapJoy, but I hear they are a good ad service to use with games. I have several applications on the market, my SDL apps are the first games I've done, and the popular ones are geared toward children, so maybe Admob does not do currently do as well for children's games as it does for utilities that older people use.

pelya wrote:
PanaceaSupplies wrote:I'm very interested in getting the gettext functionality working with JNI. Unfortunately, the libc Android uses, bionic, does not include specific locale info.

I've ported several games which use gettext (it's called intl or libintl in the sources) - OpenTTD, UfoAI and Free Heroes 2, however all of them have a language option inside settings (or inside .cfg file in the case of Free Heroes 2), also all these apps add a custom search path to libintl, so that it will use current application directory instead of usual location like /usr/share - see bindtextdomain or an example here. SDL sets environment variables LANG and LANGUAGE to the current device language setting, so gettext should know what language to use (in theory, I never checked whether this actually work).

I will definitely look into this. It would be REALLY cool if I could have gettext working without a whole rigmarole. I've had some success with my apps, but if they could use their gettext translations, the audience would be much wider and they would be a lot more successful.

pelya wrote:Also, few things from your blog:

PanaceaSupplies wrote:Sergii "Pelya" Pylypkeno

Please don't call me that - my name is Sergii Pylypenko, "pelya" is not capitalized, and please don't squish my nick inbetween my name and surname, I'm not a boxer.

Haha. I changed it to Sergii Pylypenko (pelya). I changed pelya to lowercase, unless it starts a sentence or something.

pelya wrote:
PanaceaSupplies wrote:He published then unpublished Jooleem. I thought it was pretty cool and e-mailed him saying I wanted to release it, but was there some unknown reason he unpublished it to Google Play. He said there wasn't, so I did some work on it, then published it.

The only reason is that I was pissed because users gave poor ratings to Jooleem. Now I don't care about ratings that much. I'll probably update TeeWorlds and publish it back, when I'll have some free time during August.


Actually, I think you were right to begin with, I just unpublished Jooleem recently. I guess people just don't get the game for some reason. I like it, they don't. I also unpublished Ice Blocker. Circus Linux I uploaded to Google Play but never published, I had second thoughts because I didn't like how on-screen control worked. The three games I have up there now are the ones which I like and which are somewhat popular (Lily Hop is the newest and not popular yet but I hope it becomes so).

I've gone through a lot of games and these three are the first round I'll put in. I may fix them up more so they work with Android, such as increase the keypad on mathgame, or fix some crashes on toytrain.

I figured these would be good Android games. My second tier games were Abe's Amazing Adventure, Tuxpuck, Epiphany, Powermanga, Ceferino, and Adonthell. They all seemed OK, but I thought the three I put on Google Play would translate to Android better. I might reconsider and do one (or more) of the second tier.

There's a few SDL apps I've thought of bringing over, apps popular already elsewhere. The apps were generally large and complex though. So I've passed on them for now. I might come back to them though.

As I said before, if gettext works without a lot of hassle, that's exciting, as the apps can have a wider audience. I'll definitely be looking into that.
PanaceaSupplies
Freshman
Freshman
 
Posts: 7
Joined: Fri Dec 02, 2011 6:17 am

Re: SDL port for Android SDK/NDK 1.6

Postby MemoryController » Sun Jul 29, 2012 4:50 pm

In my app doing
sdl_videoFlags |= SDL_SWSURFACE;
surface = SDL_SetVideoMode(480, 800, 16, sdl_videoFlags);
crashes the app. An ideas why?
MemoryController
Once Poster
Once Poster
 
Posts: 1
Joined: Sun Jul 29, 2012 4:47 pm

Top

Re: SDL port for Android SDK/NDK 1.6

Postby pelya » Sun Jul 29, 2012 7:08 pm

I guess you'll need "800, 480" instead of "480, 800". SDL default screen orientation is landscape, if you need portrait - set ScreenOrientation=v in AndroidAppSettings.cfg
pelya
Master Developer
Master Developer
 
Posts: 323
Joined: Mon Nov 23, 2009 11:31 am

Re: SDL port for Android SDK/NDK 1.6

Postby slvn » Tue Aug 14, 2012 9:15 pm

Hey All,

One month ago, I find this issue :

Using the port with SDL-1.2 and the flags : SDL_HWSURFACE | SDL_DOUBLEBUF, it appears to be crashing immediately in the SDL_SetVideoMode function.

it crashes especially with Samsung Galaxy S2 ... I think in the lib : /system/lib/egl/libGLESv1_CM_mali.so (can't remember if that was important). I think it may crash with other Samsung too.

It can be solved by modifying the file :
.../jni/sdl-1.2/src/video/android/SDL_androidvideo-1.2.c
by removing the static function : SDL_ClearSurface()
(and the only 1 call to this function)


It was not crashing with other devices ... And starting in SW_SURFACE mode would have also solved the issue.

I have no such device and had to remotely debug this problem, so it would be nice if someone could look closer to it. Or have a look at the function. Maybe it's worth a commit ..

Thanks,
slvn
Developer
Developer
 
Posts: 33
Joined: Thu Jul 28, 2011 7:45 am

Re: SDL port for Android SDK/NDK 1.6

Postby pelya » Wed Aug 15, 2012 10:01 am

This function does not do anything useful, so I've #ifdef-ed it away.
pelya
Master Developer
Master Developer
 
Posts: 323
Joined: Mon Nov 23, 2009 11:31 am

Re: SDL port for Android SDK/NDK 1.6

Postby PanaceaSupplies » Sat Aug 25, 2012 5:16 am

I ported an SDL library using game, Ri-li (now called Toy Train), to Android a few months ago. I used your code that was on Github in April 2012.

I just decided to update the game using your latest code. So I pulled down your latest code (August 15, 2012 commit 4a5d0d8880c60dbe864f25a05fd0c232574aef48). I noticed when I ran Toy Train with the newest code that everything in the various screens was flickering - very visibiy. I tried it again with your April code, and it worked fine with the April code.

I did a git bisect, and all of the code was good up until the June 12th, 2012 commit - http://github.com/pelya/commandergenius/commit/690a8c70f9f871d00b3e77032a73ed7d55f6ade4. The commit comment says "Added MOAR DIRTY HACKZ to the SDL compatibility mode, MilkyTracker now does not have any drawing glitches." Actually, this code really breaks the functionality of the program.

By the time of the latest commit on August 15th, the program is functional again, but is blinking all over the place. So somewhere between June 12th and August 15th, some of the problems put in on June 12th were fixed. But not all of them, as there is now excessive blinking.

What I'm going to do is update my code to the code right before the June 12th commit. You can see my code here -
http://github.com/dennis-sheil/commandergenius/commits/toytrain. Just the project/jni/application/toytrain directory (and src pointer to it) should be enough to look at it. You can pull just that directory alone into your tree to see what I am saying.

As I said, I'm going to do is update my code to the code right before the June 12th commit. If I have time, I'll look at the June 12th commit and see what about it exactly messed my program up.
PanaceaSupplies
Freshman
Freshman
 
Posts: 7
Joined: Fri Dec 02, 2011 6:17 am

Re: SDL port for Android SDK/NDK 1.6

Postby pelya » Sat Aug 25, 2012 10:11 am

Do you need to use the compatibility mode at all? Could you try to set CompatibilityHacks=n inside AndroidAppSettings.cfg?
The compatibility mode makes SDL update the screen asynchronously, 10 times per second, ignoring whether the application calls SDL_Flip() or not. And that commit that breaks your game goes further - when application calls SDL_Flip(), the SDL postpones next screen update for 50 ms. It was made for MilkyTracker, which calls SDL_Flip() with a garbage in video buffer, then updates video buffer shortly after this call. The worst thing is that this works okay on the desktop PC, both Windows and Linux, because they update the SDL window with a constant rate.
I'll probably split that setting into two, so you can get the old behavior from SDL.
pelya
Master Developer
Master Developer
 
Posts: 323
Joined: Mon Nov 23, 2009 11:31 am

Re: SDL port for Android SDK/NDK 1.6

Postby PanaceaSupplies » Sat Aug 25, 2012 8:44 pm

pelya wrote:Do you need to use the compatibility mode at all? Could you try to set CompatibilityHacks=n inside AndroidAppSettings.cfg?
The compatibility mode makes SDL update the screen asynchronously, 10 times per second, ignoring whether the application calls SDL_Flip() or not. And that commit that breaks your game goes further - when application calls SDL_Flip(), the SDL postpones next screen update for 50 ms. It was made for MilkyTracker, which calls SDL_Flip() with a garbage in video buffer, then updates video buffer shortly after this call. The worst thing is that this works okay on the desktop PC, both Windows and Linux, because they update the SDL window with a constant rate.
I'll probably split that setting into two, so you can get the old behavior from SDL.


I don't need to use compatibility mode as far as I know.

I set the CompatibilityHacks flag to no with your latest code, and it works beautifully, the blinking problem went away totally.

Also, there must have been an improvement between June and now, because high score entry with the keyboard is much more naturalistic now.

Very good. Thanks!
PanaceaSupplies
Freshman
Freshman
 
Posts: 7
Joined: Fri Dec 02, 2011 6:17 am

Re: SDL port for Android SDK/NDK 1.6

Postby Richard Throne » Mon Aug 27, 2012 1:31 pm

(I'd also like to bring stuff like ads like Admob more into JNI (or in Video.java or the like, turned on and off from the C++ code)..


For monetization of your app you can go with http://www.startapp.com as its a good monetization platform for us. I have also tried it and they are paying good as compare to the ad networks. :)
Richard Throne
Freshman
Freshman
 
Posts: 4
Joined: Sat Aug 18, 2012 9:24 am
Location: UK

Re: SDL port for Android SDK/NDK 1.6

Postby jenergy » Wed Sep 05, 2012 7:14 pm

Hi all, I created jzintv4droid, the android port of intellivision emulator jzintv created by Joe Zbiciak.
I used libsdl port, and audiotrack java class for audio management. All works well, except for the fact that audio does not work on tablets, instead of phone where it works. This has been reported to me by several users that tested application on tablets, but I have no tablets to test, I asked them to install alogcat and to share me logcat, but they didn't (still?) answered me. I searched for a solution here in this thread, but without success. Maybe someone of you noticed (and fixed..) this issue?
I think that the problem is related to another one I had, which forced me (sigh) to use 22050khz for output instead of 44100 Khz, the only message was "W/AudioTrack(11194): obtainBuffer() track 0xxxxxx disabled, restarting " and I solved by using less Khz..can someone help me?

Thank you
jenergy
Freshman
Freshman
 
Posts: 3
Joined: Wed Sep 05, 2012 6:54 pm

Re: SDL port for Android SDK/NDK 1.6

Postby pelya » Wed Sep 05, 2012 7:46 pm

News here! I've added AdMob support to SDL - you just need to set your publisher ID inside AndroidAppSettings.cfg, see admob-test app for an example code.
There are two C calls defined in a new header file SDL_android.h:
int SDL_ANDROID_GetAdvertisementParams(int * visible, SDL_Rect * position);
int SDL_ANDROID_SetAdvertisementParams(int visible, int left, int top);
which toggle advertismenet visibility and position.
Those two calls are not implemented yet :) I tihnk I'll implement them by the end of the week.

Please tell me if you'd prefer to use AdWhirl instead of AdMob, although AdMob can also mediate different ad networks now.

All works well, except for the fact that audio does not work on tablets

What version of SDL are you using? A month or two ago I've updated SDL to compile against Android 4.0 SDK, and there was an error inside AudioTrack caused by change in JNI (all JNI references are not automatically global now), so I've fixed that. If you've taken old AudioTrack code and compiled it for Andorid 4.0 you may get bugs on a tablet (almost all of them run Android 4.0 now).
I never encountered any problem with playing 44100 KHz audio, even on the archaic HTC G1 with Andorid 1.6.
Are my other apps work okay on your device (OpenTTD for example)?

Edit: I've finished my AdMob integration, check out file SDL_android.h and project test-advertisement for details.
pelya
Master Developer
Master Developer
 
Posts: 323
Joined: Mon Nov 23, 2009 11:31 am

Top
PreviousNext

Return to Code Snippets for Android

Who is online

Users browsing this forum: Google Feedfetcher and 5 guests