search

ghaerr / microwindows

The Nano-X Window System
Other
659 stars 90 forks source link

Build nanox demo APKs #16

Closed nwrkbiz closed 5 years ago

nwrkbiz commented 5 years ago

I extended the build system now to create android apps for the demos. The asset files are packed into all apps even if they are not needed.

But i clould not execute them. The apps are crashing with following stacktrace:

02-02 15:42:45.980 16843 16843 I crash_dump32: performing dump of process 16790 (target tid = 16790)
02-02 15:42:45.981 16843 16843 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
02-02 15:42:45.981 16843 16843 F DEBUG   : Build fingerprint: 'OnePlus/OnePlus3/OnePlus3:8.0.0/OPR1.170623.032/1812060016:user/release-keys'
02-02 15:42:45.981 16843 16843 F DEBUG   : Revision: '0'
02-02 15:42:45.981 16843 16843 F DEBUG   : ABI: 'arm'
02-02 15:42:45.981 16843 16843 F DEBUG   : pid: 16790, tid: 16790, name: windows.demoarc  >>> org.microwindows.demoarc <<<
02-02 15:42:45.981 16843 16843 F DEBUG   : signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xff49ffe4
02-02 15:42:45.981 16843 16843 F DEBUG   :     r0 00000210  r1 00000024  r2 cadd2510  r3 cadda620
02-02 15:42:45.981 16843 16843 F DEBUG   :     r4 00000000  r5 cadfd1c0  r6 c88fee98  r7 ff49fff0
02-02 15:42:45.981 16843 16843 F DEBUG   :     r8 00000000  r9 00000000  sl cadd3890  fp cadfda74
02-02 15:42:45.981 16843 16843 F DEBUG   :     ip cadf8dc4  sp ff49ffe8  lr cacc67df  pc cacc4494  cpsr 800f0030
02-02 15:42:45.982 16843 16843 F DEBUG   : 
02-02 15:42:45.982 16843 16843 F DEBUG   : backtrace:
02-02 15:42:45.982 16843 16843 F DEBUG   :     #00 pc 00030494  /data/app/org.microwindows.demoarc-NC6yiYlaJ9vi8ZLLcLztFQ==/lib/arm/liballegro.so (al_set_memory_interface+11)
02-02 15:42:45.982 16843 16843 F DEBUG   :     #01 pc 000327db  /data/app/org.microwindows.demoarc-NC6yiYlaJ9vi8ZLLcLztFQ==/lib/arm/liballegro.so (_al_get_new_display_settings+50)

I currently have no time to debug into it, maybe some time next week. I already merged with the last changes and replaced an #elif with #else in srvmain.c to make it build on my machine.

I should mention the apks require a monolith build of allegro.so. I also found out that only allegro 5.1.X versions are supported. Starting with 5.2.x the headers have changed somehow.

ghaerr commented 5 years ago

Nice work Daniel, thanks!

I accepted all of it, but will be changing the default src/config back to config.macosx so you will have to copy Configs/config.android over before your builds.

Not sure why the demo app is crashing, I'll look into it. Is your FLTK/NX11 application working?

Greg

nwrkbiz commented 5 years ago

There may be a linking problem... but as I said currently I have no time to look into it.

The fltk/nanox stuff works flawlessly for me, successfully ported my fist app to android (https://projects.nwrk.biz/projects/dart_counter) 😊

ghaerr commented 5 years ago

I've finally got Allegro5 up and working on my OSX system, so I can now test the Allegro/Android driver. I'm working on converting it to the new, fast update driver format. I noticed in one of your Makefiles that you are using the zoomfactor and doubling it. Is there a reason you need that? Doesn't that cause the application to show only a portion of the screen contents?

nwrkbiz commented 5 years ago

Jeah, i do this because otherwise the windows are very tiny and not very convenient to handle 😅 But yes this cuts a part from the screen ^^

Is there maybe a way to maximize the windows?

ghaerr commented 5 years ago

You could try maximizing the window by replacing ALLEGRO_WINDOWED with ALLEGRO_FULLSCREEN_WINDOW in src_allegro5.c. But I think we’d have to increase SCREEN_HEIGHT and SCREEN_WIDTH as well.

The window contents would still appear small though. This is also happening on OSX, and the screen size is quite a bit smaller than the same size specified with the SDL driver. Strange.

Regards,

Greg

On Feb 3, 2019, at 4:21 PM, Daniel G. notifications@github.com wrote:

Jeah, i do this because otherwise the windows are to tiny and not very convenient to handle 😅 But yes this cuts a part from the screen ^^

Is there maybe a way to maximize the windows?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/ghaerr/microwindows/pull/16#issuecomment-460098740, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5V6XiPL7rbELjXH_VAPsNaf09kFXks5vJ28IgaJpZM4afoXD.

ghaerr commented 5 years ago

I've rewritten the ALLEGRO v5 screen driver to support a 2x zoom factor that improves readability greatly without clipping, and also aggregates screen updates into a single blit for speed. I've only tested it on OSX but it should run on Android, can you test it? I updated your config.android to use SCREEN=ALLEGRO (not ALLEGRO5), everything else is the same. The Allegro v4.x driver was deprecated, I tested this on Allegro v5.2.4.

nwrkbiz commented 5 years ago

I still cannot built with Allegro v5.2.4 I created an issue with the error that occurs for me.

nwrkbiz commented 5 years ago

Hmm, if i get it right, setting ALLEGRO_FULLSCREEN_WINDOW this will create a fullscreen allegro context where nanox is drawing into? Is this true?

Is there a way to make the nanox windows fullscreen (like clicking on the maximize button of an application on linux/windows). I usually try to design my FLTK apps to scale when maximized, this would make them look like a native android app :)

You could try maximizing the window by replacing ALLEGRO_WINDOWED with ALLEGRO_FULLSCREEN_WINDOW in src_allegro5.c. But I think we’d have to increase SCREEN_HEIGHT and SCREEN_WIDTH as well. The window contents would still appear small though. This is also happening on OSX, and the screen size is quite a bit smaller than the same size specified with the SDL driver. Strange. Regards, Greg … On Feb 3, 2019, at 4:21 PM, Daniel G. @.***> wrote: Jeah, i do this because otherwise the windows are to tiny and not very convenient to handle sweat_smile But yes this cuts a part from the screen ^^ Is there maybe a way to maximize the windows? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#16 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5V6XiPL7rbELjXH_VAPsNaf09kFXks5vJ28IgaJpZM4afoXD.

ghaerr commented 5 years ago

Yes, it is my belief that using the fullscreen setting above will create a fullscreen allegro drawing context that should make the nano-X windows fullscreen. However, the nano-X application's idea of the screen size will not change, so their behavior won't be any different. Allegro will just scale the drawn window larger.

I did rethink the zoom factor idea with the driver rewrite however and the nano-X applications should appear larger in either the windowed or fullscreen case, with no clipping. If you set the fullscreen setting and it works, we can possibly tweak the zoom or screen width/height settings in order to get the most visually appealing display. I would like to see a screenshot, as I don't have the Android toolchain setup over here.

ghaerr commented 5 years ago

I forgot to mention that I left in a commented-out fullscreen setting in drivers/scr_allegro5,c, just add that and comment out that windowed setting above it to try this out.

nwrkbiz commented 5 years ago

I forgot to mention that I left in a commented-out fullscreen setting in drivers/scr_allegro5,c, just add that and comment out that windowed setting above it to try this out.

Haha damn, i did not see a difference, because i did set height and width to my phones screen resolution :'D let me retry ^^

ghaerr commented 5 years ago

I think you should be setting the width and height to the phone screen resolution.

I’m not sure whether the fullscreen setting does anything different or not, but the screen width/height should remain the same in the config settings.

Allegro is always scaling our application framebuffer output regardless. I solved the appearance issue by telling Allegro that the display is twice the width/height specified in the config, and then it scales the actual framebuffer contents when “flipping” the display each cycle. The applications still think they’re running in the width/height specified in the config.

Does the display look any different with the new driver, or about the same, since you were running with a zoom of 2.0 previously? It shouldn’t clip now however.

Regards,

Greg

On Feb 4, 2019, at 9:54 AM, Daniel G. notifications@github.com wrote:

I forgot to mention that I left in a commented-out fullscreen setting in drivers/scr_allegro5,c, just add that and comment out that windowed setting above it to try this out.

Haha damn, i did not see a difference, because i did set height and width to my phones screen resolution :'D let me retry ^^

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/ghaerr/microwindows/pull/16#issuecomment-460324243, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5QagAFkCPZBcOKGnya79FcFunTdqks5vKGXagaJpZM4afoXD.

nwrkbiz commented 5 years ago

Ok i can verify that ALLEGRO_FULLSCREEN_WINDOW does not make any difference. The display now looks like when setting the zoom factor to x2 with the old driver, so pretty nice imo :)

You can test it yourself with my last build here: https://buildbot.nwrk.biz/share/fltk_mvc_template/origin/master/27/install_package/

ghaerr commented 5 years ago

Daniel,

Thanks for the verification that the new driver works and that there is no difference with the fullscreen setting. I should be mostly done with ALLEGRO and Android modifications at this point. I did notice that your master Makefile is now outdated with regards to the sed modifications.

I am still having troubles getting the nano-X demo applications running with Allegro on OS X, but the win32 demo apps are running. I’ll debug that soon, not sure whether that is an issue with the Android APK builds you setup or not. Allegro has a very strange issue with OS X where they internally setup a separate thread for calling OS X APIs and they’ve kludged it to require a separate main() entry point to make this work. None of the nano-X demo apps use threads however.

On Feb 4, 2019, at 10:15 AM, Daniel G. notifications@github.com wrote:

Ok i can verify that ALLEGRO_FULLSCREEN_WINDOW does not make any difference. The display now looks like when setting the zoom factor to x2 with the old driver, so pretty nice imo :)

You can test it yourself with my last build here: https://buildbot.nwrk.biz/share/fltk_mvc_template/origin/master/27/install_package/ https://buildbot.nwrk.biz/share/fltk_mvc_template/origin/master/27/install_package/ — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/ghaerr/microwindows/pull/16#issuecomment-460332146, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5RpmVPcBDVZmjKce157SmaW2gq9wks5vKGrIgaJpZM4afoXD.

nwrkbiz commented 5 years ago

screenshot_2019-02-05_165340

I have forgotten to upload the screenshot in my last post, sorry :o

ghaerr commented 5 years ago

Daniel,

Very nice! The new 2x zoom really helps!

It’s really wild to see FLTK X11 apps running on Android :)

Is this the full screen or just the application portion? Does the system still show the time and a window name above this? I was wondering about whether a window title should be added, for instance.

On Feb 5, 2019, at 9:00 AM, Daniel G. notifications@github.com wrote:

https://user-images.githubusercontent.com/6352567/52285891-79012800-2967-11e9-99af-ce445e5474c1.jpg I have forgotten to upload the screenshot in my last post, sorry :o

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/ghaerr/microwindows/pull/16#issuecomment-460693552, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5Z2rPIKIv5XyNTAPrURSCFuWWkAIks5vKaqkgaJpZM4afoXD.

nwrkbiz commented 5 years ago

Daniel, Very nice! The new 2x zoom really helps! It’s really wild to see FLTK X11 apps running on Android :) Is this the full screen or just the application portion? Does the system still show the time and a window name above this? I was wondering about whether a window title should be added, for instance. … On Feb 5, 2019, at 9:00 AM, Daniel G. @.***> wrote: https://user-images.githubusercontent.com/6352567/52285891-79012800-2967-11e9-99af-ce445e5474c1.jpg I have forgotten to upload the screenshot in my last post, sorry :o — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#16 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5Z2rPIKIv5XyNTAPrURSCFuWWkAIks5vKaqkgaJpZM4afoXD.

This is a screenshot of the full andriod screen, so everything you see on my display when starting the app :) No there is no "app window" and the system statusbar is also hidden "behind" the app.

nwrkbiz commented 5 years ago

Haha, a silly idea just came up to my mind maybe you can answer me the question.

Lets pretend I use a fltk gl window to draw some png pictures. Would it be posible to use NX11 and nanox in combination with glshim/gl4es (to translate opengl calls for to opengles on android devices)? Or do you think the X11 emulation would be too slow?

Thanks in advance, giri

ghaerr commented 5 years ago

Sounds like possibly a lot of work just to look at a png! LOL

The X11/NX11 will ultimately package up the bits and send them to Microwindows, where a fast blit will be used, provided that the data is in one of the fast blit formats (32 bit ARGB, ABGR would be best). With LINK_APP_INTO_SERVER=Y, transferring the bits will be relativiely fast between X11 and MW.

I’m not familiar with the glshim and gl4es libs but if these do the translation work without much or any handling, it could be worth a try!

On Feb 5, 2019, at 2:32 PM, Daniel G. notifications@github.com wrote:

Haha, a silly idea just came up to my mind maybe you can answer me the question.

Lets pretend I use a fltk gl window to draw some png pictures. Would it be posible to use NX11 and nxlib in combination with glshim/gl4es (to translate opengl calls for to opengles on android devices)? Or do you think the X11 emulation would be too slow?

Thanks in advance, giri

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/ghaerr/microwindows/pull/16#issuecomment-460811986, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5axdwvSI1pHNhjpkbAfGBq-cA19gks5vKfhogaJpZM4afoXD.

nwrkbiz commented 5 years ago

Sounds like possibly a lot of work just to look at a png! LOL The X11/NX11 will ultimately package up the bits and send them to Microwindows, where a fast blit will be used, provided that the data is in one of the fast blit formats (32 bit ARGB, ABGR would be best). With LINK_APP_INTO_SERVER=Y, transferring the bits will be relativiely fast between X11 and MW. I’m not familiar with the glshim and gl4es libs but if these do the translation work without much or any handling, it could be worth a try! … On Feb 5, 2019, at 2:32 PM, Daniel G. @.***> wrote: Haha, a silly idea just came up to my mind maybe you can answer me the question. Lets pretend I use a fltk gl window to draw some png pictures. Would it be posible to use NX11 and nxlib in combination with glshim/gl4es (to translate opengl calls for to opengles on android devices)? Or do you think the X11 emulation would be too slow? Thanks in advance, giri — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#16 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5axdwvSI1pHNhjpkbAfGBq-cA19gks5vKfhogaJpZM4afoXD.

Haha jeah, I came up with the idea, because this would allow to port the fltk client of this game to android: https://projects.nwrk.biz/projects/clanbomber

ghaerr commented 5 years ago

How about this game? Got it ported to Nano-X on 64 bit OSX, almost runs…

On Feb 5, 2019, at 3:18 PM, Daniel G. notifications@github.com wrote:

Sounds like possibly a lot of work just to look at a png! LOL The X11/NX11 will ultimately package up the bits and send them to Microwindows, where a fast blit will be used, provided that the data is in one of the fast blit formats (32 bit ARGB, ABGR would be best). With LINK_APP_INTO_SERVER=Y, transferring the bits will be relativiely fast between X11 and MW. I’m not familiar with the glshim and gl4es libs but if these do the translation work without much or any handling, it could be worth a try! … <x-msg://161/#> On Feb 5, 2019, at 2:32 PM, Daniel G. @.***> wrote: Haha, a silly idea just came up to my mind maybe you can answer me the question. Lets pretend I use a fltk gl window to draw some png pictures. Would it be posible to use NX11 and nxlib in combination with glshim/gl4es (to translate opengl calls for to opengles on android devices)? Or do you think the X11 emulation would be too slow? Thanks in advance, giri — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#16 (comment) https://github.com/ghaerr/microwindows/pull/16#issuecomment-460811986>, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5axdwvSI1pHNhjpkbAfGBq-cA19gks5vKfhogaJpZM4afoXD https://github.com/notifications/unsubscribe-auth/ALbi5axdwvSI1pHNhjpkbAfGBq-cA19gks5vKfhogaJpZM4afoXD.

Haha jeah, I came up with the idea, because this would allow to port the fltk client of this game to android: https://projects.nwrk.biz/projects/clanbomber https://projects.nwrk.biz/projects/clanbomber — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/ghaerr/microwindows/pull/16#issuecomment-460826430, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5QONSi8NukOajGkmW9dkMFdOVRioks5vKgNRgaJpZM4afoXD.

nwrkbiz commented 4 years ago

It works until the OpenGL screen, because SDL2 and glshim (OpenGL -> OpenGLES wrapper) are fighting for the OpenGLES context.

Easiest fix would be a rewrite of the GameWindow to use FLTK native commands.