Black screen on Android #13
Comments
|
The Microwindows version in this repo will not work for Android. Please use the binary version in this repo: https://github.com/georgp24/microwindows-android-bin In there there is an application note how to get this to run on Android: Georg |
|
Thanks for your prompt answer, I already checked out your second repo :) I am trying to build a cross platform template for FLTK applications and made quite some progress so far (https://projects.nwrk.biz/projects/fltk-mvc-templ/wiki/). I wanted to avoid precompiled stuff for transperancy and portability. As I mentioned the app seems perfectly running (i can put debugg messages in logcat), but the display stays black. Nevertheless I will try to link your precompiled libs and report back if they worked :) |
|
Here is the reicepe I used to compile: https://projects.nwrk.biz/projects/fltk-mvc-templ/repository/revisions/dev/entry/_template/packages/nanox/Makefile |
|
When linking against prebuilt -lPX11 and allegro it works :) |
|
Daniel,
Thanks for publishing your Makefile, it’s an interesting way of specifying the changes
you require as well as automating two builds in one file!
It looks like you have a semi-recent version of Microwindows source, do you know when
you pulled it? Just so happens I have been making lots of cleanups to the source and
config files recently. The config.linux file was replaced with two versions, config.linux-X11
and config.linux-fb. I think the config.linux-X11 should work for you. I have also done
work on building using just the local X11 headers for the NX11 build for SDL (see config.sdl).
I would like to help you debug the Android version, and will create a Configs/config.allegro5
using the updated config format and settings from your config_android_arm as defaults.
From there we should be able to get you on the new source tree and then get your display
problem debugged quickly. I’ll also remove the C++ nanox demos when building for Android.
I have made a number of driver enhancements recently that will allow the screen update
to be sped up tremendously, and also have rewritten the Mw/GsSelect() function for polling
drivers like Allegro5. Once we get it painting, I can suggest some changes for you to try.
In general, the new polling driver format should look close to drivers/*sdl.c, with all screen
updates occurring only in the Preselect() entry point using a single draw function and bounding rect.:q
Why do you require the -m32 switches for the Linux build?
After I create an updated config files for you, can you try your Makefile using the latest source?
The biggest changes were removing the tons of different driver options and replacing them
with SCREEN=, MOUSE= and KEYBOARD= rather than having a large list of =Y/=N options.
I’ll ask Georg about what the differences are between his Android tree and mine, I’m not sure
if he’s running updated drivers or instead is just posting the binaries in his tree. I would like to
get the Android build automated and working in the master though.
Regards,
Greg
… On Jan 31, 2019, at 12:51 PM, Daniel G. ***@***.***> wrote:
Here is the reicepe I used to compile: https://projects.nwrk.biz/projects/fltk-mvc-templ/repository/revisions/dev/entry/_template/packages/nanox/Makefile <https://projects.nwrk.biz/projects/fltk-mvc-templ/repository/revisions/dev/entry/_template/packages/nanox/Makefile>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALbi5V8bTkpRYPbmiKQCOksI-30BOBTKks5vI0kkgaJpZM4acNZV>.
|
|
That’s great news!
We need to diff the drivers/*allegro5.c in his and my tree, and copy Georg’s to the master tree
if different. I just described some other changes in the mainline polling mechanism that were
required for the SDL2 port, and we can get the Allegro driver updated to the newer mechanism
and you should then have a version you can compile from scratch.
Georg - what are the reasons that you were saying that the current source master isn’t
compatible with getting an Android version work? Is it just the driver files, or are there
other items in the tree that are necessary?
Regards,
Greg
… On Jan 31, 2019, at 5:05 PM, Daniel G. ***@***.***> wrote:
When linking against prebuilt -lPX11 and allegro it works :)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALbi5WIZDCmPJu1zshpPfXGTx1PTEJbXks5vI4SwgaJpZM4acNZV>.
|
|
Daniel,
I just added a Configs/config.android based on your config_android_arm into the source master.
In the cleaned up tree, only the section in Arch.rules under ANDROID will need to
be modified. Can you try pulling the new tree and setting that section with your CFLAGS/LDFLAGS
and then running your Makefile? This will get us a long way forward to debugging
the screen issue, knowing now that Georg’s binary works. I will then add the CFLAGS/LDFLAGS
into Arch.rules so that we have a compiling version.
If you change your Makefile to 'cp Configs/config.linux-X11 config' that should work with the new tree also.
Regards,
Greg
… On Jan 31, 2019, at 5:05 PM, Daniel G. ***@***.***> wrote:
When linking against prebuilt -lPX11 and allegro it works :)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALbi5WIZDCmPJu1zshpPfXGTx1PTEJbXks5vI4SwgaJpZM4acNZV>.
|
Thanks for your reply! I tested your config and added my flags to Arch.rules instead of sed replacing in Makefile.rules and it compiled, but again resulting with a running app without screen output. regards, |
I already did a diff on the driver/*allegro5 files and did not find any significant changes. The only thing that changeg were some direction macros within the mou_allegro5.c file. |
|
Oh the -m32 switch is needed to compile 32 bit binaries. I do this to get binaries which can be executed on a wider range of machines :) So nothing thats really needed on a normal build. |
|
I tested your config and added my flags to Arch.rules instead of sed replacing in Makefile.rules and it compiled, but again resulting with a running app without screen output.
Can you send me your modified Arch.rules? I would like your working settings.
We are now testing both NX11/PX11 library and libnano-X.a. In order to reduce variables,
any chance you can test one of the Nano-X demos, like demo-hello? You will need to set
NANOXDEMOS=Y in your config and then possiibly edit demos/nanox/Makefile.
With everything compiling, we should be able to fix things soon. There is a small chance I
will have to modify the allegro driver but i think we’re backwards compatible but just not for speed.
Georg contributed the Android port and knows much more about this than I do, we’re waiting for
his response on why the current tree won’t support Android.
Regards,
Greg
… regards,
giri
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALbi5W4zQsC_mfeInXz0uIpT9v1zD7GNks5vI5o3gaJpZM4acNZV>.
|
I have attached my Arch.rules file, but it depends on my project structure and on debians android ndk packages. Should i test to build the examples for android? Or just if it compiles using the android toolchain when setting the right include paths. For android the programms need to be compiled to a .so and then wrapped into a small android app executing the .so using allegro. |
|
I have attached my Arch.rules file, but it depends on my project structure and on debians android ndk packages.
Thanks, I will edit this slightly and add it so that others can build by setting
ANDROID_NDK_HOME and ANDROID_PLATFORM_VER, and ALLEGRO5_INCLUDE.
I think the ALLEGRO5_INCLUDE should be set in the config file.
Should i test to build the examples for android? Or just if it compiles using the android toolchain when setting the right include paths.
I would like to see you build demo-hello at least (very basic) and then see whether it runs.
It likely won’t, but this at least eliminates libNX11 as a possible problem.
For android the programms need to be compiled to a .so and then wrapped into a small android app executing the .so using allegro.
If you show me a Makefile for doing that, I can add that to the tree also, similar to what was done
for EMSCRIPTEN, see demos/Makefile-emscripten,
Thanks!
Regards,
Greg
… —
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALbi5dPvolaD6Gpk39pUHCIQ_GJLHv11ks5vI6OngaJpZM4acNZV>.
|
I just compiled lNX11 and nano-X using georgs source tree and the resulting binaries work. (just to verify if the source matches the precompiled binaries) Ok i will try to create a demo-hello android .apk Creating android apps is usually done using gardle. Gardle completely sucks IMO, because it hides everything it does from you and is very painful to configure. So I created a makefile which executes all commands to pack a android app (see the very end of this file): https://projects.nwrk.biz/projects/fltk-mvc-templ/repository/revisions/dev/entry/_template/src/Makefile |
|
I just compiled lNX11 and nano-X using georgs source tree and the resulting binaries work. (just to verify if the source matches the precompiled binaries)
Good news. I’m looking at the android-bin source tree right now.
Try setting “-DHAVE_SELECT=0” in your CFLAGS in Arch.rules. It looks like
by default, the Android build is saying its UNIX and that may cause the wrong GsSelect()
to be used in nanox/srvmain.c, which could hang in select() and GrDelay().
Ok i will try to create a demo-hello android .apk
Creating android apps is usually done using gardle. Gardle completely sucks IMO, because it hides everything it does from you and is very painful to configure. So I created a makefile which executes all commands to pack a android app (see the very end of this file): https://projects.nwrk.biz/projects/fltk-mvc-templ/repository/revisions/dev/entry/_template/src/Makefile <https://projects.nwrk.biz/projects/fltk-mvc-templ/repository/revisions/dev/entry/_template/src/Makefile>
Ok, I’ll look at this to educate myself.
Regards,
Greg
… —
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALbi5VUBSwwykgCihs-bGXlQi-whtwJ4ks5vI6t_gaJpZM4acNZV>.
|
|
Hooooraay thanks!! -DHAVE_SELECT=0 did the trick :)))) |
|
If you want to i can try to create a little sample project to create andriod apps within your source structure. |
|
Hooooraay thanks!! -DHAVE_SELECT=0 did the trick :))))
Great!! I have added your CFLAGS/LDFLAGS into Arch.rules and will add
the -DHAVE_SELECT=0 also. I will also start doing some cleanup and getting
the allegro driver structure moved to the newer style. If there’s a speed issue
then it won’t be too much work to make things faster.
Glad we got this working quickly, and you moved to the newer source tree!
Regards,
Greg
|
|
If you want to i can try to create a little sample project to create andriod apps within your source structure.
Yes, that would be great. Then others can verify the build by running some pre-written demos.
If the link side is a bit messy, see what was done with demos/Makefile-emscripten. I took Georg’s nice
work on getting EMSCRIPTEN initially figured out and ported, and moved the build into the standard
Microwindows make system. The EMSCRIPTEN link is a bit complicated for the Microwindows
standard link system, so all the demos are now built using this single Makefile after the standard “make”.
(see src/make-emscripten and src/link-emscripten for that example).
We could do the same for Android.
Thanks!
Regards,
Greg
|
|
Bah I feel really happy right now :) The cross platform fltk MVC template project is now working on android too :D If you are curious, i just created a fresh build: The apk works fine on all my testing devices :)
I'll close this issue now. I think next week i have some spare time where I can try to create the andruid builds. I will send a pull request when finished if thats ok? Thanks again for your help, |
Hello :)
I am having troubles to get nanox + allegro running on android. Allegro and its examples work fi
ne, but when starting an nanox demo application, it seems to run but the screen keeps black.
Here is the config I used to build nano-X.a:
config_android_arm.txt
Here is a part of the android logcat:
LogCat.txt
Thanks in advanced, and thank you for this project :)
The text was updated successfully, but these errors were encountered: