hey, i downloaded vcmi for android from google play and tried to play heroes 3 but the game crush after i asve or load and even in the middle of the game.
i saw that the update was year ago and i wanted to know if there gonna be any new pdate release soon or if there a way i can fix that problem.
my device is: samsung galaxy s wifi 5.0 or in his other name samsung galaxy player 5.0 if it helps the model name is YP-G70(its a mini tablet)
thanks ahead!
i just wanna say that you are doing amazing job! heroes 3 was my favorit game when i was a kid so when i saw that i can play it on my sgp i got so excited!

Hi,

I'm using pelya framework to port SDL 1.2 apps and emulators to my android 4.0 JXD portable consoles.
I've ported my Pandora CPC version of Caprice32, and i'm facing several issues with the SDL Sound/Audio.
The Sound is really laggy, i've added many buffers to compensate the latency/lag and the sound is now playing well but with 1/4 sec delay. After i instrument the code, i've notived that threads scheduling is really chaotic and the audio thread may sleep for a while as if the priorty was not high enough.

I'm sure many others have encountered this issue, i've read somewhere that we may better use jni / AudioTrack but i can't find any example that could be used in my context (C and C++ SDL based apps), in order to replace SDL Audio Init / callback stuff. Any advice would be appreciated

If you want to use AudioTrack from your C code directly - here's an example, it's from OpenAL library.

Audio on Android is a source of many woes indeed, because you cannot access audio drivers in kernel - you have to route audio through Java. SDL uses AudioTrack to output sound, like pretty much every other Android application. There is OpenSLES library on Android starting from 2.3, which is supposed to give less lag, however I never used it, also it's designed pretty much like OpenGL - you upload your sound samples to the engine, and trigger their playback in the 3D environment, so if you want to generate an audio stream yourself, you're stuck with AudioTrack.
SDL sets the audio thread priority to maximum in Java - see here. You may also try to lower your main video thread priority here

@pelya: thanks for those advices. i will give them a try.

This evening i succeed to get a nearly working audio SDL stuff (without laggs) by modifying SDL_androidaudio.c and add a SDL_Delay in WaitAudio callback (the delay is something like this SDL_Delay((audio->spec.samples*800)/audio->spec.freq), so 80% of the delay required between two fill buffer calls).

It's a quick and durty hack, but it works for my emu ports.

EDIT: i did a better hack that delay the thread of the required amount of time based on sample rate and SDL_Ticks. It gives me good results on several emulators (msx, coleco, caprice32 and Hu-Go). I can send you the diff if you want. Btw i've found a bug in TTF Solid render fonction with sdl-1.2 (i can also send you the fix).

I use your SDL 1.2 port and it is really GREAT ! Thank you !

However I have a problem.
When I send the application to the background and onResume it I see the black screen on only.

the LogCat output sais:
E/SurfaceTexture(1912): [SurfaceView] dequeueBuffer: SurfaceTexture has been abandoned!
E/MaliEGL(28513): void __egl_platform_dequeue_buffer(egl_surface*):1094 [EGL-ERROR] failed to dequeue buffer from native window (0x209f118); err = -19, buf = 0x0

I'm investigating this issue for couple of days and I found that:
- the touch events are passed correctly
- we can take the colors from the screen and obtain correct values (not zeros)
- it is enough to change the CompatibilityHacks to YES but then the screen blinks

It seems like my application:
does not call SDL_Flip() or SDL_UpdateRects() appropriately
according to the ./ChangeAppSettings.sh script.



Can you give me any suggestions please ?
My best regards.

Do you have SwVideoMode=y in your AndroidAppSettings.cfg? It usually solves all such problems.
CompatibilityHacks is a last resort for broken apps, it forces screen to update 10 times per second, disregarding what application thinks about that, so it will flicker.
Could you please compile and run Ballfield, or any other test application from the repository, and check if it has similar problems?

I have SwVideoMode set to yes and use the SWSURFACE.
I have compiled the ballfield and the reminescence applications. Both work correctly after onResume.

In my application I compared the SDL_GetVideoSurface() return result.
The result is constant and does not change after the onResume. So it seems like the pointer to the SDL_surface is constant. Moreover the fields inside the SDL_surface returned by SDL_GetVideoSurface() remains the same.

My application uses the 1024x768 graphical files and scales it keeping the 4:3ratio. It also uses the SDL_SetVideoMode( 0, 0, 16, SDL_SWSURFACE | SDL_FULLSCREEN );


In the ChangeAppSetting.sh you write
"does not call SDL_Flip() or SDL_UpdateRects() appropriately"
What is the apropriate SDL_Flip, SDL_UpdateRects calling ?
It may be possible I do something your port does not expect

Okay, the only thing that lets your application know it was in background are two SDL events, SDL_ACTIVEEVENT and SDL_VIDEORESIZE. Maybe your app does something when it receives those events? Could you please try to comment out that part of code?

pelya wrote:

shishanjiu wrote:Do we need SDL_Flip(SDL_GetVideoSurface()) in a while (1) loop like ballfield.cpp?

slvn also said to call SDL_Flip in 1Hz.

Doies this is actully need to solve the pause/resume issue after press home button? I feel it so wild.

Yes, SDL destroys and re-creates video surfaces inside SDL_Flip() call, so you need to call it from time to time (once per 5 seconds at least).
It also sends SDL_ACTIVEEVENT and SDL_VIDEORESIZE events from inside SDL_Flip(), however I did a quick fix, now it will send a SDL_ACTIVEEVENT asynchronously, when the app is put to background.
Please update your SDL repo, and replace all long wait functions in your app with SDL_WaitEvent() (or SDL_PollEvent() with a short sleep in a loop). I think you already did that, because your app should wait for user input.
Whenever you receive a SDL_ACTIVEEVENT - you should call one extra SDL_Flip(), that should fix the bug. SDL_Flip() will block, and will return only when user brings app to foreground.

Sorry, I'm not very clear. You have done quick fix for this issue? After your fix, do I still need SDL_Flip() call from time to time? Or What I just need is calling one SDL_Flip() in SDL_ACTIVEEVENT event?

When you receive SDL_ACTIVEEVENT you have to call SDL_Flip() one time - it will sleep until user brings app to foreground. The destroying/creating of OpenGL context is done inside that SDL_Flip(), you don't need to do any other modifications to your code. Please reply if it works for you as I've described.

pelya wrote:Okay, the only thing that lets your application know it was in background are two SDL events, SDL_ACTIVEEVENT and SDL_VIDEORESIZE. Maybe your app does something when it receives those events? Could you please try to comment out that part of code?

I have found the root cause:
The application did nothing until the user touched the screen.
There were no screen refresh and until touch.

I have also found the workaround:
I refresh the screen even the screen content does not change.

It takes some CPU unfortunately.
I tried to refresh the once just in the ACTIVEEVENT event but it does not solve the issue.

I'm still trying to find a good solution not consuming the CPU.
Maybe some refreshes after the ACTIVEENT (not in).

pelya wrote:When you receive SDL_ACTIVEEVENT you have to call SDL_Flip() one time - it will sleep until user brings app to foreground. The destroying/creating of OpenGL context is done inside that SDL_Flip(), you don't need to do any other modifications to your code. Please reply if it works for you as I've described.

Yes! It works for me! Thanks a lot.

Furthermore, When upgrade program, Android will only upgrade program itself, but preserve program's data. When upgrade a program with its new version, Android will popup a dialog which says "You are replace some program. And all previous user data will be preserved" So after upgrading, program is new, but its data is old. And this often makes mistakes when running program. Though your codes in DataDownloader.java compare crc of exist file with new file and try to upate file, this doesn't happen at all. When upgrading, no data unzipping and updating happen, only program is upgraded.

I pack all resources and data which needed by my program in a zip as assets. But when upgrading, these cannot be update. How can I solve this problem? And my program's users are used to upgrading program with new version directly. Unistalling old version and restalling new version are troublesome for most of them.

Change data download URL inside AndroidAppSettings.cfg (and rename files in assets, if you bundle them inside .apk file), then it will be re-downloaded on upgrade.

I pack all resources and data which needed by my program with a zip and put it in assets. And this is theAppDataDownloadUrl in my AndroidAppSettings.cfg:

AppDataDownloadUrl="Book data is 30 Mb|misc.zip"

Do I need to rename each file in assets? In assets, there're logo.png and misc.zip which is 30Mb and is splitted from misc.zip00 to misc.zip29. All these file are needed to be renamed including logo.png?

Yes, rename it to misc2.zip, in both assets and cfg file. The build script will split big files automatically, I've added that functionality last month.