Closed nwrkbiz closed 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
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) 😊
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?
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?
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.
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.
I still cannot built with Allegro v5.2.4 I created an issue with the error that occurs for me.
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.
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.
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.
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 ^^
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.
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/
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.
I have forgotten to upload the screenshot in my last post, sorry :o
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.
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.
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
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.
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
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.
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.
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:
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.