Two questions:
I am running now on a real Nexus7 rather than an emulator, and I am now seeing two issues I had not yet seen.
1) How do you work with the softkeys? Can I treat them as keys being pressed, with an event que? I ask because pressing back can lock up the device for a moment, after which I am asked if the program should be shutdown for not responding or not - and if no is pressed, the demo becomes a background behind all the icons.
2) What ever orientation the device starts in is fine, but after rotating the device the aspect becomes very warped. Rotating the device into the orientation it was when the program started makes everything right again.
What code or condition checks am I missing? I am running the allegro example. Any ideas?
All keys should come through as keyboard events. Some work should probably be done to make sure the keyboard event handling doesn't lock up the java thread.
That backgrounding issue has been brought up before. Not sure what is causing that, other than the device supporting multiple GL contexts, and the user thread continuing to run in the background drawing under the main ui.. At least thats my guess.
I'll have to do some testing on my Nexus 7.
I just updated from 4.0 4.1 to 4.1.1
The background bug persists, and can now be repeated via:
click back a bunch real fast. select wait. click home.
The rotation bug seems fixed.
Let me know if you can replicate either - if so I will add it to the bug tracker.
Ah, you were using 4.0? That isn't even possible. There was no Android port in 4.0 afaik.
But please try the latest 4.1 release, and Git if possible. Git especially, that's probably the most important.
Isn't he talking about Android? Android 4.1, Jelly Bean?
I meant android 4.1 to 4.1.1
OH. Heh. My bad. What version of Allegro are you trying?
Allegro 5.1.3
Would it be possible to try the version from the git repo? That may have some fixes for what you're seeing. (I can't remember for sure)
You MUST handle ALLEGRO_EVENT_DISPLAY_HALT/RESUME_DRAWING and should handle ALLEGRO_EVENT_DISPLAY_SWITCH_OUT/IN also. Take a look at the Allegro demo for Android to see what you need to do: http://www.nooskewl.com/content/open-source/.
EDIT:
I'll try to break it down as best I can remember (in the way I prefer to do it).
1) When you get a HALT_DRAWING, you should set up a condition variable and start a thread with al_run_detached_thread. The code in this thread is pretty simple:
I'm wondering why that is required. Can't the main thread just not run things when it knows it can't draw?
Yes, but then you mess up your main loop. Like I said, way I prefer to do it.
EDIT:
And it's impossible to wait on a condition in the main thread, because you have to wait on events, so you'll be spinning cycles needlessly.
Ah. I personally wouldn't find it would mess up the main loop. I'd probably just stop my timer and call it a day. That way no updates at all should happen till the resume drawing event, where you'd start the timer back up.
You can't. Read my edit. Well you can but it's better my way.
I wouldn't wait on a condition. Just wait for the resume event to come back, and set things back up. Basically with the timer[s] stopped, no more events should be able to come back, other than the resume drawing event. so you wait on that, rather than a condition.
Whatever. Won't argue with you. You're "The Android Guy" after all. .
Whatever. Won't argue with you. You're "The Android Guy" after all. .
I have to say you've done at least as much work, so you're like a partner in crime.
I could be missing something. Some quirk of android or allegro's interaction with it that needs something that fancy.
I am a little confused how you would add that code into this. I tried, but now I can't get graphics and it doesn't open immediately like it used to - which I believe is possibly caused by my new and not quite clear understanding of ALLEGRO_EVENTS. Here is the example main.c from the allegro5 git.