BlitzMax goes mobile
Community Forums/Showcase/BlitzMax goes mobile
| ||
 (screenshot by Android Monitor, from a Nexus 7 running 4.4.2) All I can say is, this is pretty much the coolest thing I've seen so far from BlitzMax :-) Thanks to everyone for doing their various things, especially the OpenGL experts and the generous donators. As you can see, the SDL version of OpenGLES Max2D appears to be working well so far. Obviously lots still to do, but not bad for a couple of hours faffing. |
| ||
| Seems I uselessly spent some time with libGDX to bring a little mole-game to android. Happy "adb push"... You know that I am watching the github repos closely ... you really should commit it before christmas (hey...there is still time for a html5-over-gwt or html5-over-emscripten target :p). bye Ron |
| ||
| cant wait |
| ||
| This is awesome! Have BRL approached you about any of this just yet? |
| ||
| Now this is getting interesting. :) |
| ||
Something a bit more interesting : The starfield looks nice, even if it is only in the corner of the screen. No sound as yet - haven't tried building any of the audio modules. May require a new module to drive that part of it. Have BRL approached you about any of this just yet? I know that BRL are not against the project, but otherwise it's a completely unofficial thing. Current state (technical stuff) bmk is able to compile all the native stuff into a shared object. Currently I am cross-compiling on OS X with the NDK and SDK command-line tools. Making the apk is somewhat up in the air at the moment. In my testing, I have a basic android project, into which I copy the shared object. Then I run "ant debug" on it, and then I install the apk on the device. Of course, the individual settings for the apk need to be "easily" modifiable. There are some xml files and a .java that need some things changed on a per-project basis. This could probably be automated from a project file as part of the build. (in a similar way to how Monkey does it) Input. As noted in a thread elsewhere in the forums, we'll need to implement the touch interface - SDL supports this, and we just need to plug it into BlitzMax. Of course, you may need to change your apps to work better in a touchy-feely world. Audio. No idea what's required yet. One little step at a time ;-) Otherwise, it all just seems to work. If I knew how to auto-magically scale the display to fit the screen (you can't seem to change resolution, but maybe there's an OpenGL way to scale the view), then the screenshots would look better. Fun fun :o) |
| ||
| but maybe there's an OpenGL way to scale the view Can't you just change the Graphics command parameters?If not, the only way I can think of is to render to a separate frame buffer and then render a scaled quad to the main buffer. However it would be a device-specific solution without some extra commands. |
| ||
| Maybe changing the viewport size to the device resolution? |
| ||
| Very, VERY nice! |
| ||
| For Android devices you will have to introduce virtualviewports. There is no way around - there are plenty of devices and resolutions and the engine cannot care for it on their own. Ok it can - in the case of a "stretching viewport" (just make it "fullscreen" without taking care of the rest) ... but then it also have to take care of coordinates (projecting touch coordinates to "resolution"-coordinates). So the best bet is to NOT scale at all - but provide the screen resolution. It is then upon the user to use a framework/helper which provides a virtual canvas to draw things on. While "TouchX()" returns the real screen coordinate (using the devices native resolution) the framework then handles the "virtual" TouchX() - which returns the position using the touchpoint "rebased" to the used resolution (unscaled) of the app. Why should such a framework get used instead of just "scaling and adding black borders to keep aspect ratio" (which is the thing which could be done by the "brl.mod/..."-portions) ... because there might be people which do not want to have these black borders - but draw custom borders- or they want to have one screen which fits for all "common" aspect ratios (4:3 - 16:10). The last one is usually done with a screen with the width of the "16:10" resolution and the height of the "4:3" resolution. Everything inbetween both resolutions is then scaled on one axis to fit as much as possible eg. on height. The other axis is then smaller or equal to the other limit. So you end up displaying only portions of your screen. All interactable elements should then be in the portion of the screen visible on all resolutions (there is a "minimum area" visible in all supported aspect ratios). If one does this "framework" for all others (in an extendible way) there is no reason NOT to include it in the "NG"-package so people just could get on using BlitzMaxNG and it "works". There are some "virtual viewports / virtual graphics" projects floating around - maybe including them in the "brl-packages" might be a good idea (maybe using "brl-ng.mod" as basement for compatibility issues). Of course they might need some enhancement. Hoever you decide on this: as mobile devices tend to not have the "windowed" option, you as app developer have to take care how your game is displayed in fullscreen. Instead of everyone needing to invent the wheel again it would be a good idea to have a basic "camera/viewport/whatever" solution included in the "package" already - maybe do it like with the graphics engines - provide a "driver" doing nothing but pure stretching - and make it extendable using more advanced "cameras/viewports". bye Ron |
| ||
| OH! Nice! My compliments sir! |
| ||
| If you decide to go with the scaling/black borders thing, this might help -- not sure if it can be applied at max2d level here, though? The algorithms might be of use anyway... VirtualGfx I do think it should be optional, though, as Derron suggests. Remember there's also VirtualMouseX/Y and co (might be in that code already)... |
| ||
| As I described the "extend"viewport thing: I created an overview of some sample resolutions ... As you might see: 1024x768, 800x600, 640x480 share the same aspect ratio - so when designing for 800x600 the 1024x768-setup just has to scale the graphics up and 640x480 down. For the other aspect ratios the system must provide multiple options: - designed for 800x600 -> stretch in all areas just to fit without paying attention to aspect ratio - designed for 800x600 and you want to run it on 840x480 -> scale everything up to fit "width": you end up using 840x600, you loose top/bottom areas -> do not scale and get letter boxes 0-20 and 820-840 while still loosing data on top/bottom (but less this time) - designed for 840x600 (maxWidth concerning aspectratio, maxHeight concerning aspectratio) and run on 800x480 -> instead of fiddling with aspect ratio we just fit the "least cutting" dimension and clip the rest: so we scale down to 800x572 - and cut 46 pixels on top and bottom  The Camera/Viewport should be able to return some kind of "safe Area" concerning the allowed/supported aspect ratios, think of it as with the "safe areas" when designing DVD-menus/printable areas and so on. So the developer knows that this portion of the screen is never Cut/stretched out of the visible screen. Hope I did not add to much confusion now. bye Ron |
| ||
| Thanks. You probably want to post that in the other thread though, this being the "showcase" area and all. :-) |
| ||
| Heh, I'd never heard of SetVirtualResolution... |
| ||
| @Input Turns out that SDL is mapping (first) touch to mouse, so MouseX and friends are already working :-) |
| ||
| Very very interesting project Brucey - keep up the smashing work :-) |
| ||
| OMG, this is Xmas before time :)) !!!!! |
| ||
| Sound is now working :-) Thanks to Skid's most excellent and bodacious FreeAudio engine! In theory, you can now set the audio driver to "FreeAudio SDL" on any platform and the sound will *just work*. (in as much as it would for any SDL-based application on that particular platform). The only issue I've observed so far on Android is that the mixed buffer is not cleared when the app wakes up again, so for a while you get twice as much audio mixed together, until the buffer clears. (I imagine there will be an event to be trapped to know when to clear the mix buffer or some such thing) Thanks Skid! :o) |
| ||
| This looks really awesome, great looking work. |
| ||
| Great work! |
| ||
| Ohhh, well done Brucey!! |
| ||
| Hey Brucey - can you upload the APK somewhere so we can test? |
| ||
| Not much to test at the moment... it just shows the main screen, in the corner of the display. Input needs to be modified for a touch interface, as well as screen re/sizing. |
| ||
| All game engines emphasis about the need to optimize the draw calls, is there is something similar with "Blitzdroid" ? |
| ||
| I was just thinking if we had the APK we could test it on a wide range of devices for you. |
| ||
| Awesome Stuff! :D |
| ||
| @I agree with Therevills... it would be interesting to test with my smartphone,china-tablet and minix x8 |
| ||
| The android port relies on: - a c compiler targeting android - the sdl libraries So if things do not work it wont work on up to all devices. Brucey "constructs" the APK himself, so there might be issues in it (meta-data etc.) but this should stop working at all - or in no way. Things he could have "misconfigured" are "min-api-level" and "targeted-api-level". If things "crash" or just "do not work" it will most likely be an issue with the libraries. But like said: once it works on device X it will most propably work on device Y too. Things which need more consideration are "differences to desktop applications". For android this are the "intents" (I would more likely call them "eventlisteners"). So for android apps it is more likely to get "suspend/resumed/...". Also they need specific "rights" granted to be able to do specific things they could do without hassle on windows/linux/mac-desktops. So maybe we should introduce a generic "SystemEventListener"-class which creates some "stubs" for desktops and reacts to system thingies on other platforms. For us "game devs" this is most likely one of the "onChangeScreenOrientation" things - or "onResize" (if it ever happens to get added to "non-maxgui-apps" in BlitzMax). Each listener you want to register owns information about "needed access-rights". To make them "readable" by the compiler-bmk-chain, the listeners should be "readable" using special notations. This might dilute the existing bmx-language - in the same way the current bmk-extensions extend the language. So eg. to register for specific "rights", bmk-ng should scan for '@bmk bla this "bla" could be commands to announce interest for "intent.xy" on android (or even a more generic command, so it could be translated platform-dependend). Using the above method, modules/code could define on their own what they need - or if things could stay disabled (eg. accelerometer or other battery draining sensors). I mean: instead of saying "no" to a right, they must explicitely say "yes" - the sum defines what rights are needed for the app to work flawlessly on the target platform. bye Ron |
| ||
| Okay, here's a link to the digesteroids test apk : http://brucey.net/programming/blitz/bmx_ng/demos/android_test_01-debug.apk.zip (5.3 meg) Not very useful in this state, other than to see if it runs on your device or not. Interesting things to note : * the code is essentially unchanged. Much like with our banana-eating cousin, it's simply been a case of compiling it for a different target. * uses SDL to drive all the backend stuff - graphics context, audio driver, input (not that you'll notice much input interaction in this example) * uses a new community-developed Max2D which is OpenGLES 2.0 friendly. It was built for API 19, to run on a Nexus 7 running 4.4.x. So, YMMV ;-) |
| ||
| Looking good on my Pantech Flex running 4.2.1 |
| ||
| I assume the min api of "10" (2.3.7) should be possible. @AndroidManifest.xml Why is this "mangled" (some odd char encoding used?) With "UTF-16" I was able to at least read some words. With UTF-32 it did not load at all, UTF-16LE and BE did not help either. same happens for res/layout/main.xml - so I assume your editor used some "uncommon" encoding. But the most important thing: it started up (took some 2-3 seconds on my dualcore 1.2GHz Huawei Phone running on 4.). Sound played as well (like I said before: if it works for "one" it will most likely work for all). Display was unscaled - so I saw only a portion of the game (840x480 here). What did not work: "app suspend/exit" using "back"-button on the phone. So I do not know if it really "exits" when pressing the home button - or if it stays in memory. Edit: but like said, this is not that important as this thread is to show of "that it is running on android now", not about a 100% perfect working target with adjusted samples. Edit2: as people tend to like pictures I made one to show that it is no "emulator screenshot":  bye Ron |
| ||
| How does keyboard emulation work on the Android? Can you force it to show and just use it the same way we use our desktop keyboards? |
| ||
| Oh! Just tested on my smartphone (nobrand, A4.2, quad core) Some seconds of waiting, the the music works, the starfield/splashscreen doesn't fill the screen (about 20% of the right side is 'black') - more or less like in the image posted at the top of this thread) No iteraction(= touch screen does nothing) great job! now testing on minix... Edit Tested on minix... It works without problems a expected, the device supports hd screen so I cansee just a picture in picture of the game. As on the smartphone there is a wait of about 3-4 seconds... So it is not hardware related I suppose. |
| ||
| While Blitzmax internally handles "Keyevents" - and presents it to you via "KeyHit/KeyDown" this does not work for Android anymore. For Android "NG" should introduce a new command: "WaitForTextInput(boolean)". This then triggers: SDL_StartTextInput / SDL_StopTextInput on the supported platforms. In the case of android this will show the OSD-keyboard then. On other platforms it should do nothing. Next to these commands there are some others replacing "old scancode"-based functions. Instead of asking for scancodes you now just get the text the user entered. For the old "KeyHit(Key_left)" functionality you will have to supply your own "virtual keyboard" (I posted a "virtual input"/dpad-solution in the other thread in the programming section). bye Ron |
| ||
| There's no way to just make the keyboard show all the time? |
| ||
| Bloody amazing stuff :) |
| ||
| Works perfectly on my Tegra note 7. As regards to keyboard input has anyone tried using a OTG cable and a usb keyboard? |
| ||
| Cheers Brucey. On my Moto G, it took a few seconds to display anything but it looks good:  |
| ||
| ..very nice..it seems ill be back to BMax again.. :) |
| ||
| Wow. Even I myself might go back to developing in Blitzmax at this rate. :) Great work! Stunning! |
| ||
| If everything was simple then I would definitely use BlitzMax having the 64bit sorted would also be a massive plus :) |
| ||
On my HTC One V, the Screen is not scaled only the 800x480 native display will displayed, the Intro runs ok one this 1GHz Singlecore device. Sound runs Okay, but no Exit from the Intro. |
| ||
| Nice first post :p. @scaling It is not included in the apk @"back" same thing. @Brucey Sorry... did not want to start a "blitzmax on real devices"-picture-thread (but seems we attracted new voices for the things going on). bye Ron |
| ||
| @exit/back Been looking into this a bit. I've had to implement BlitzMax's disabled "KEY_BROWSER_X" keycode mappings, as SDL is using some of those for the "back"/"home" buttons. Having done that, pressing Back now generates a key event, which you can (for example) KeyHit() for. Having applied that to the demo (in all the places KEY_ESCAPE was checked for) it now attempts to close the app when pressing Back from the main menu. However, there appears to be a (well documented via various forum posts on the internet) problem in that SDL is not shutting down properly on "main" returning at the end of program. Exit() (End in BlitzMax terms) however does work. So I'm considering adding a forced Exit to the end of the program in order for the app to shut itself down correctly. When it is closing fully, attempting to run the app again results in a full-startup (as you would expect). @delay may be down to it having to extract everything from RAM and load stuff? (everything there is incbin'd at the moment until I can see that it going to load assets from the correct places). It may also be related to the fact that Digesteroids, having been designed for desktop, is not expected to take long to start up - whereas one might otherwise have a loading screen to fill the time where other stuff is happening... @pictures Nice to see it running on such a variety of devices. Does hold out some hope that once all the niggles are squashed, BlitzMax may well have a good life ahead of it on (at least) Android :o) |
| ||
| A little Benchmark where nice, to see the Speed of Blitzmax on Android at so old devices as my HTC One V Single Core ^^. |
| ||
| Unfortunatly it does not run on my Asus 7" (ASUS ME175CG-1B038A ) :/ |
| ||
| Unfortunatly it does not run on my Asus 7" (ASUS ME175CG-1B038A ) Indeed, it was built for ARM, not Atom/x86. One would need a new build targeting a different toolchain. This is down to the fact that we are building everything in native C/C++, rather than Monkey's route where it generates Java. In theory, native code should execute faster than the equivalent Java app. |
| ||
| Aahh, ok, good to know. That Android world is nightmare to me. |
| ||
| Just tried it on my aging LG Optimus One P500, with Android 2.3.3 installed and it fails to run (it installed fine). |
| ||
| I just tried on a Huawei U8600 running CM7 (2.3.7). This is also a gingerbread based ROM. "Forcefully closing" here too. 2.3.3 and 2.3.7 mean "API Level 10". When playing with the "encoding" of the androidManifest.xml-file in the APK I saw two numbers "8" - but these numbers stood some lines after the line containing the min/target definition. @Brucey What was the "minimum requirement" you defined? Logcat: EDIT: While I thought this has to do with "minsdk" I think I now know what is the reason: the smartphone is running on "armv5" - and you compiled for "armv7". EDIT2: According to http://stackoverflow.com/questions/5089783/producing-optimised-ndk-code-for-multiple-architectures You could call the compiler in a way so it adds both libraries: "APP_ABI := armeabi armeabi-v7a". If the system uses "v7" it will have an increased performance, but the compilation tries to stay "compatible" with older devices. Maybe "v7 only" should be an extra compilation flag (same for "v5 only") - just in the case of one trying to provide multiple variants of the app (to keep filesize down). bye Ron |
| ||
| @ arm5 / arm7 That's going to complicate things somewhat. Will need to introduce different arm architectures that you would choose for your build. (eg. instead of arm, you would need to get more specific). Not impossible, of course, just a schlepp. And *then* you'd need the build (bmk) to handle merging two/multiple sets of binaries into a single apk. Again not impossible, but... I suppose we can put it on the list of "nice to haves" for later ;-) At the moment I'm trying to get bmk to do a "single-click" build for Android. (i.e. compile/make apk/execute on device) |
| ||
| It doesn't work on the Samsung Galaxy S4 - a black screen for a split second, then exits. |
| ||
| Could you connect your S4 via USB + enable Developer options? Then from a console run "adb logcat" to see what happens when starting the sample on your phone. You will get something similar to what I posted above. Maybe it shows "what is crashing" there.. @Brucey and armeabi Couldnt you "just" add both "armeabi" and "armeabi-v7a" to the compiler flags - in the case one wants both supported? @one click This wont work that nice - because you then need to have a "device selector" (maxide will have to know about existent emulators/adb-connected-devices). So it might be easier to have it build an "apk" and then run something hmm "3rd party" (like the thing I suggested: lua scripts for individual targts). That way bmk finishes its work - and then routes the output data (filename, commands, options ...) to a potential script (or let it fetch the commands/options/filename upon startup). This script then takes - or not takes - care of existing devices, presenting selection dialogues, remembering previously selected things etc. To have all of this in "maxide" makes it more of a beast than needed ... But hey...just do as you want (I know...satisfying results are the best :p). bye Ron |
| ||
| I have no f*****g idea how you did this, it's really an extreme achievement. |
| ||
| I have no f*****g idea how you did this, it's really an extreme achievement. I'm suspecting voodoo myself. |
| ||
| the big bunch of work was to create the "bmx->c" translator. At the end you have something like a "c-project" of your blitzmax files. As long as the generated C-code + potential libraries does what they are told to do --- it should work on other platforms too. The long story would surely include the hassles of tightly connected dependencies (X11, OpenGL, ...) which eg. were solved by Brucey via splitting things apart or replacing basic "engines" with other ones (EGL, SDL2 - for graphics context, audio, input ...) especially on targets like raspberry/android. bye Ron |
| ||
| the big bunch of work was to create the "bmx->c" translator. Yeah, I can see how that would be. I can also see how it would be a titanic amount of effort. The long story would surely include the hassles of tightly connected dependencies (X11, OpenGL, ...) which eg. were solved by Brucey via splitting things apart or replacing basic "engines" with other ones (EGL, SDL2 - for graphics context, audio, input ...) especially on targets like raspberry/android. ^ This part is where the splitting wedge hits my cranium. Do you happen to know what Brucey's CS background is? I do understand how wrappers and stuff work but I'd be more likely to try to write a |
| ||
| the big bunch of work was to create the "bmx->c" translator. Yeah, I can see how that would be. I can also see how it would be a titanic amount of effort. The long story would surely include the hassles of tightly connected dependencies (X11, OpenGL, ...) which eg. were solved by Brucey via splitting things apart or replacing basic "engines" with other ones (EGL, SDL2 - for graphics context, audio, input ...) especially on targets like raspberry/android. ^ This part is where the splitting wedge hits my cranium. Do you happen to know what Brucey's CS background is? I understand wrappers and how engines like Blitzmax are ported, but as I said this seems like just a titanic amount of effort for someone to go to. Does Brucey write actual games or other apps that would make this financially worthwhile? |
| ||
| BlitzMax is modular enough that it didn't take too much effort to create a new SDL-based backend. Do you happen to know what Brucey's CS background is? The word "dogsbody" comes to mind. This week I've been doing Informix 4GL :-( |
| ||
| Brucey Ive been flicking through here and Im new to the ideas above, but please make a new mobile target for Max :) I really think Max is one of the best computer tools in the world, and to have a new target would be just the perfect hello world |
| ||
| Does Brucey write actual games or other apps that would make this financially worthwhile? I have a job which pays the bills, and I'm not so good the entrepreneur. I leave it up to others to make their fortunes with all this stuff. However, I'm very grateful to all the support via donations which has helped to fund various tools that help with the work. |
| ||
| Some enjoy watching movies, some like doing sports ... and some like tinkering around wrapping code from X for Y. I really would enjoy coding something together with Brucey (even if I only am used to do some sprites/graphics :p), but I assume his interests are a bit different than ours - and so also goals in a project will differ more widely than its good (grade of perfection concerning "polishing" graphics etc.). bye Ron |
| ||
| The word "dogsbody" comes to mind. That's a shame. Would be interesting to see what you could do working full time on this stuff. |
| ||
| Hi, The images of Digesteroids on mobile are just blowing my mind. Blown. Drooling at the thought of Phoenix USC on mobile. :D |
| ||
| Would it be possible to decompile the exe files after its been compiled by BlitzMax and then get a C source file, and then load into monkey? In just thinking out load because I seen this on the net. I found this http://www.backerstreet.com/decompiler/decompilers.htm |
| ||
| Brucy i worship you |
| ||
| @brucey: is it still correct that you took parts of the Monkey toolchain to create this new BMX? |
| ||
| I have a job which pays the bills, and I'm not so good the entrepreneur. I leave it up to others to make their fortunes with all this stuff. However, I'm very grateful to all the support via donations which has helped to fund various tools that help with the work. ..you have my respect for this words..ill be more than happy to support you with project such as this one..im not sure is there any 'donate button' or something, but for sure, you got me.. |
| ||
| im not sure is there any 'donate button' or something, but for sure, you got me.. http://brucey.net/programming/blitz/ |
| ||
| This week I've been doing Informix 4GL :-( Well.. consider this: I'm using a DMS for work surely based on Informix (somewhere I saw an icon/splashscreen about Informix engine or sort of). If you think programming in Informix is bad (I have no idea there is a language... I just think it was a DBSQL engine...), you can think I'm using an application written in this language... and everyday I think who wrote this application, didn't use it in real work! :D In any case I think that it's time to have a 'serious' home for BMX-NG... not just some post/thread around here (@BRL if someone is listening... more chances to receive an answer from Alpha Centaury I believe!) |
| ||
| In any case I think that it's time to have a 'serious' home for BMX-NG Surely it already has a home: bruceys github page? |
| ||
| Will it be able to run modules as well like the infamous xors? or blitzmax commands only? |
| ||
| @PhotonTom: I mean something more specific, like a proper webpage/site (or at least a thread on this forum) At the moment it seems (because it is...) very 'for expert only', where you need to download/find everything you *should* need and try to run it. Personally this seems the BRL approach I would love not to repeat :) |
| ||
| Does this scale to different resolutions? After all if this has the power of Blitzmax with the portability of monkey its a win win in my book, the 32bit issue was a long term problem in my book as some of my projects are slow burn and by the time of release I would have had to rewrite for 64bit. |
| ||
| @degac Maybe it would be a good idea to update the Blitzmax wikibook with a Blitzmax-NG page and get a corresponding forum section. |
| ||
| @scaling The "opengl/gles"-screen is just a canvas ranging from 0,0-1,1 so it is up to you to scale it properly (virtual resolution, viewport ...). We already posted some code taking care of this (VirtualGraphics/SurfaceCamera/...). Mobiles or other "fixed fullscreen resolution"-devices need some special handling the classic "desktop apps" do not require - except notebooks or other widescreen-monitors and your old 4:3 or 5:4-resolutions (800x600, 1280x1024...). bye Ron |
| ||
| Nice :) |
| ||
| Well done! BtW: Is the 64bit conversion of BMX still in development? |
| ||
| I think there are still modules not working on "win 64-compilation" (didn't Brucey mention DirectX and DirectSound or so?). bye Ron |
| ||
| Yeah cant wait to see how it all works :) |
| ||
| Ok I use Blitz a lot, but Im only just looking at mods and stuff, so excuse my daft questions, but I havnt seen a 64bit compilation mod, where do I get it and what do I need to compile? and my god this expands blitzmax into a real monster. the iOS and android mod too this is an xmass to remember thanks Brucey who ever you are, I bet its a big team with a front guy :) |
| ||
| i bet its a one man show |
| ||
| It's the army of Bruce. :) |
| ||
| I would like this as a mod but I do believe its a conversion of bmk or bcc |
| ||
| How would you do this "by mod" ? The result has to be an "APK" ... an apk is a package containing java + x. X in this case is some compiled code based on C. The problematic part is to "compile for other platforms/architectures". The "fasm" currently does not handle what "gcc" can handle regarding these things. The "SDL-on-android"-approach is to provide a thin layer using java. This java code then relies on the compiled (in our case using the NDK), I assume other sources would be possible, as it just utilizes it similar to a "dll". As a mod "fasm" would be in need to be able to compile for ARM. Also there would be the need of some additions to package the whole thing into an APK etc. . Currently this needs a modification of "bmk". I think the "translation" from BMX to C allows for many things. Also do not forget, that this includes changes to "brl.mod/pub.mod" to make it compatible for 64bit compilations. bye Ron |
| ||
| As a mod "fasm" would be in need to be able to compile for ARM ... cough. (Not that I'm saying it would be a good idea!) |
| ||
| again I ask.. would this mod of making an apk from blitz max will also compile stuff that are using addons like minib3d? |
| ||
| Only if minib3d is compatible with GLES 2. |
| ||
| Tnx LT SO the current project of bruceys will be able to compile just Blitzmax native commands? |
| ||
| It will compile BlitzMax and whichever modules have been updated. MiniB3D, last I checked, used older OpenGL commands that are not compatible with mobile devices. My information may be out of date, though. |
| ||
| I recently added touch events as first-class values to NG's brl.event. Of course, basic BlitzMax doesn't generate touch events, but frameworks such as SDL can, so you can now code your event Hook function to pick up events such as EVENT_TOUCHDOWN and EVENT_TOUCHMOVE. Touch events are rather useful on mobile devices ;-) Here's a small Android demo. It's a tweaked version of simonh's Fireworks sample. http://brucey.net/programming/blitz/bmx_ng/demos/TouchTest-debug.apk.zip (780kb) Source : |
| ||
| runs fine and fast , but has a red background color on my note2. digesteroid has the red issue on 50% of running. great brucey |
| ||
| Runs great on my Device with 2 Fingers :) |
| ||
| Just comparing the fireworks original and your new one mobile one Brucey, a few questions: * Is the framework always needed for the mobile version? * Why the imports, is it to reduce the "exe" size? * Why the incbin? * Can you remove the "AddHook" later? * How would you go with different events per "screen"? * Why do you load the image and only use plot? * I guess SetImageFont doesn't work yet? :) |
| ||
| Works perfectly on my china-phone Android 4.2! Full screen! |
| ||
| * Is the framework always needed for the mobile version? * Why the imports, is it to reduce the "exe" size? You answered it on your own: framework gets rid of the "include all mods" approach. Of course you then have to import what you need (else you run into trouble). @addhook It is needed - but surely could get hidden in a module (import it, and it adds the hook automagically). For now it surely just shows how to attach a listener to something which emits the newly introduced touch events. @setimagefont as it works in digesteroids, I assume it should work here too. bye Ron |
| ||
| Hallo :-) Is the framework always needed for the mobile version? No. How you build your app is entirely up to you. I happen to always use Framework. Each to their own, of course :-) Why the imports, is it to reduce the "exe" size? The Framework build was 780KB (this includes a compiled-in SDL) The non-framework build is 1.6 meg. Again, if you want to include stuff your app isn't actually using, that's entirely up to you :-) Why the incbin? That would be laziness on my part, having tweaked the code to use plot instead of drawing images. Can you remove the "AddHook" later? I'd considered adding something akin to MouseX and friends, but I'm sure that's not difficult for anyone to implement how they see fit. PolledInput uses a Hook function to populate the Key and Mouse arrays that provides values for MouseX etc. How would you go with different events per "screen"? I've no idea about the concept of different screens on a mobile device (in this example). SDL provides coordinates based on a 0..1 range over an entire "touch device". How that translates to multiple "screens" I can't say. Why do you load the image and only use plot? See previous laziness comment. I was messing around to see if plot was much faster than image. It is a bit, on my device. I guess SetImageFont doesn't work yet? It might. But I didn't want to dig out an Arial.ttf file to incbin in the app :-p |
| ||
| Therevills: How would you go with different events per "screen"? Brucey: I've no idea about the concept of different screens on a mobile device (in this example). SDL provides coordinates based on a 0..1 range over an entire "touch device". How that translates to multiple "screens" I can't say. I think he did not talk about multiple screens, but multiple events. So something in the likes of "multi touch" (2+ fingers touching simultaneously). @Arial I would suggest to use a "latin chars only" variant to keep filesize down :p bye Ron |
| ||
| Thanks Ron and Brucey :) With my screen question, when I code and develop games I have different "screens", for example: * Title Screen * Option Screen * Game Screen * Level Complete Screen * Game Over Screen All these "screens" will need to do something different when touching the screen and I was just wondering how that could be done using the TouchHook function. |
| ||
| As I know "Diddy" (I used some approaches of it for my blitzmax framework/code-collection) I know what you mean with "Screens". I just assumed that the following would be a "no-brainer" for you. Ok, Bruceys "hook"-democode shows some kind of "direct handling" (touch = action). But he also answered your question already: therevills: Can you remove the "AddHook" later? Brucey: I'd considered adding something akin to MouseX and friends, but I'm sure that's not difficult for anyone to implement how they see fit. PolledInput uses a Hook function to populate the Key and Mouse arrays that provides values for MouseX etc. What he means: have some globals (TouchX[finger], TouchY[finger], TouchDown[finger], TouchHit[finger], ...). Within your hook handling you then set these globals accordingly. Your screens then just have to read the globals to get the information. If you now provide helpers like "TouchDown(finger:int)" which returns the corresponding array entry PLUS reset that entry (so the next request will return false - until hook handling sets it to true again) you will have the same behaviour than with the Mouse input handling in BlitzMax. Something about "finger": each simultaneous touch could get counted - you just start with "finger 0" and reset the finger count each "tick". Normally you cannot say which touch event is what "finger index" - so things might get switched - finger 0 gets finger 1 next time (during a "touchDown" moment). You might bring in some "intelligence" remembering the last position and then checking for the "nearest" one. But I assume there are some libraries out there handling "swiping" etc. . Recoding them will be an effortless time-consumption. In short (single touch solution): - Open up mod/brl.mod/polledinput.mod/polledinput.bmx - Check lines 22-79, should be self explanatory bye Ron |
| ||
| Getting better and better. Too bad I hate mobile development, otherwise I might use this! |
| ||
| Talking of Wiebo, when are you planning on adding joystick support to game2d? I was even considering implementing it myself... :-p The reason being that, having factorized the joystick stuff for BlitzMax, I can now implement a multi-touch driven virtual joystick, which would be useful for playing your games on a device that has no keyboard :-) |
| ||
| I just happened to have some time to poke in and see what was on the development scene with BlitzMax and this is quite the surprise Brucey! Good job getting Android added to the mix of Max coding :) I'm looking forward to seeing what this can do with the OUYA!! I have a couple of issues with Max running on Yosemite (sadly) that keep me from doing much of anything with it right now. Joystick support is basically gone right now (but it worked on Mavericks). Almost all of my tried and true code that worked pre-Yosemite are failing with Joystick input. I'm gonna have to dig into that and see what I can do about re-birthing Max on my Mac! I haven't done much with Max or Monkey lately... *sigh* new job takes precidence over all else these days! |
| ||
| any news ? |
| ||
| Blitzmax on mi phone, i must be dreaming. Go Brucey! |
| ||
| Any further news on this awesome enhancement? |
| ||
| The number you have dialed is not assigned |
   |