&Roids (take 2)

BlitzMax Forums/BlitzMax NG/&Roids (take 2)

dw817(Posted May) [#1]
I'm understanding that BMX-NG can create executables that will run on cell-phones and Androids.

However, in attempting to run this code which creates a frameless window leaving the icons at the bottom for Windows, it does not work here, but does work in standard BlitzMAX.

Any solution so it will run in BMX-NG ?

col(Posted May) [#2]
There are only a few things that you need to look out for to get old code to run on NG. Most notably are the datatypes that should be used. In the legacy BlitzMax it would use Int where it *should* really have been using Byte Ptr, but it would get away with it because an Int is also the same binary size as a 32bit Byte Ptr.
In NG these in-corrections are... corrected.

For eg where you have
Local handle:Int
	handle = FindWindowA( "BBDX9Device Window Class", AppTitle)

In the Windows OS ( the API uses the C language so we have to work as if using C datatypes ) a window handle is really a pointer and not an Int. When compiling for 32 and 64 bit targets the pointer size changes accordingly whereas an Int is 32bit in both. For NG to work correctly these underlying datatypes have to be correctly defined, therefore NG expects a pointer, ie a Byte Ptr, where in the C language it would expect a pointer too. Admittedly a HANDLE in the windows API doesn't look like a pointer but if trace through the windows SDK to find the C datatype of a HANDLE you will find that it is indeed a pointer.

So for NG use
Local handle:Byte Ptr
	handle = FindWindowA( "BBDX9Device Window Class", AppTitle)

That's pretty much the major change in getting any original BlitzMax code to run with NG. You may find smaller minor changes required too but they would be very simple.

As for Android work, I've no idea.

Have fun :)

Derron(Posted May) [#3]
For android the most complex part to get working is "assets".

It will work non-problematic if you know the assets to load and just have 10 images you "loadimage()" or so. But as soon as you have dynamic asset loading (in my game I have this to be "moddable") things will become harder to solve.

Once that is done you will of course have no real trouble running your app on android. Brucey has run some of my DIG-samples on android/ios (as I did too).
Just have to finish the "asset part" to make a real test (my somewhat "bigger" game).


col(Posted May) [#4]
Hi Derron

What is it that makes things difficult on Android? Are paths different on different devices? No easy API define or function for getting at an asset folder? or something else?

Derron(Posted May) [#5]
I cannot name it as I did not dig deep enough in the android swamp ;-)

Basically things change when building for android.

Currently I have directories/files like

To have NG bundle everything it should be stored in specific folders.

So all your loaderstuff should be written to allow easy redirection of URIs.

Dunno what happens if you reach 100+ mb of assets (think there was a limit requiring additional "package downloads").

My dig-framework (github.com/gwron/dig.git) already has some GUI-samples utilizing xml-configured assets) so you might use that to check out what needs to be adjusted. The code itself should work on Android (run it some months ago).


Brucey(Posted May) [#6]
As far as I remember, everything should be in the "assets" folder (and subdirs thereof). The SDL path APIs should handle retrieving things from there.

GW(Posted May) [#7]
I created a basic game with NG for android. You can look at the sourcecode and see if that helps