Best way to get BlitzMax games on Switch and Mobile?

Started by GreyAlien, January 11, 2018, 19:04:58

Previous topic - Next topic

GreyAlien

NG doesn't have Switch support as far as I know right? But what about mobile?

Or is the best thing to port BlitzMax to Monkey (or Monkey2?) and go from there? I know Monkey supports mobile as I used it for an iOS/Android port, but what about Switch and other consoles?

Derron

For now there is no "switch support" - and I think it might need a bit more than a gifted Switch for Brucey. Dunno if the libs work there or not.

@ Mobile
There should be Android / RasPi support. iOS might be there too.

But I can say that Brucey is kind of buried under work load now, so I assume bigger things just happen if he needs them at work "somehow" (module stuff bugs which need to get ironed out). Everything else is done in his spare-rare sparetime.

Regardless of this: NG compiles to "C", so at the end everything is possible - with knowledge on what the platform needs and how it needs its "food".

bye
Ron

GreyAlien

Ah OK thanks for the info. So yeah Switch = no go.

For me to do a mobile port, I'd definitely need iOS, but ofc it's totally understandable that Brucey is busy and that may not be 100% ready (or if it's close, it's bound to need tweaks once tested on the actual platform for a commercial game).

Regarding compiling to C, does it output some readable C++ code before that gets turned into the final exe? I seem to recall that being a phase. So in theory I could give someone that output (and the BlitzMax code with comments for reference) and say "use this to make a port" right?

Or if I found the right person, they could modify the BlitzMaxNG mods to fix any mobile side issues if Brucey was too busy.

Derron

Last option is what would generate a benefit for all users :)


Assume SDL - which is used on certain platforms - is available for "platform X" too, then it might be easier to get things running. Similar to Monkey the crucial things are "system" (file handling, input, events) and multimedia (graphics, sounds). Generic things like maps, lists ... are (I assume you know that) working regardless of the OS.


@ readable C
Just give it a try - the more complex it gets, the more complex the files become.
I would say one could _read_ the code but I would not suggest to use it as a base for a port. It allows to understand the "logic" behind but it is not that pretty to watch at (at least for me, as a not-experienced-in-C programmer).

BTW it generates (for now) C and not C++. Brucey played with the idea of switching to C++ (as it allows to more directly convert from bmx to C++ without the need of "helping structures" as some things are not 1:1 available in C while they are in C++).


@ iOS
Do not have iOS devices, so I never tried that. Only tried Windows, Mac, Linux and Android with NG.


bye
Ron

GW

I once wrote a android game in in bmaxNG for android (it uses the Max2s_sdl mod), It worked. I have no idea about ios, but in the past brucey has shown screenshots of some the bmax demos running on ios.
The c code put out by NG is almost readable, but I wouldn't want to edit it. better off tweaking the mods to add the functionality you want. 


EDIT: Here is link  http://mojolabs.nz/posts.php?topic=106403

GreyAlien

OK thanks for the info. I didn't realise it outputted C, not C++. Yeah OK so it doesn make more sense to modify the mods instead and maybe for me give BlitzMaxNG to a porting company to handle the mod alterations.

Pingus

Hey GreyAlien,

Beeing on the same casual market, I have the same issues ;).

I envisaged few options to make a IOS port from blitzmax :

- BlitzmaxNG - unreliable at the moment imo. If Brucey can free some time later, that would be the easiest/fastest way.
- Monkey/Cerberus  - seems quite complicated and tedious
- from scratch (hiring people) - uh, probably no way to get a positive ROI
- Monkey2 - maybe... but it still lacks working examples (for IOS and Android) and tutorials and doc. To not speak about the curious business approach of Mark.
- use another game tool, must be close to blitzmax, easy to use, reliable, fast, have a big community. AGK could fit some of these features, but to me, it is probably not fast enough. The tests I did showed serious weakness when it comes to handle a lot of loops.

However, for a Solitaire game, it could worths a try because there is no need to check interactions between lot of objects. AGK is really easy to use and there are already several published game on IOS and Android, which proves it is doable (whatever the games quality). Of course it requires to rewrite everything but the code is not that different from bmax (compare to many other engines).


Derron

I tried not to derail but: if you have too many loops you should consider tuning the algorithm. Means reduce "complexity" or in other words: do not check "all" versus "all" but put them into quadrants or multiple lists or ... and only check what is needed. If necessary, have one organizational list (containing each object) and some lists in addition which are used as helpers ("objectsNearPlayer"). For bigger lists I have some additional lists which are filled/corrected if an entry gets changed, added, removed ("cache becomes invalid"). This reduces many iterations/loops.

I am pretty sure you would find similar things in your code. Why am I assuming this? Nobody (excuse me if you do) of us is doing "AAA"-stuff with AGK/BlitzMax/Monkey for now. And these "AAA" games do way more things than we do - and they still run on our computers (ok, not on mine, but mine is from 2011 :-)).


@ BlitzMax NG
If you have certain issues with NG on iOS, android, ... then open up an issue on the NG github website. Without knowing about issues, Brucey (or maybe others) cannot help.

bye
Ron

Pingus

@Derron,

Thanks for the hints. I envisaged of course to rewrite the whole core... but well, the idea of a port is to save some time, not spending time again on new algorythms unless it is really necessary :)
My blitzmax code itself takes very few time in the whole loop, compare to the displaying tasks, so I never had the need to optimize that. Even in 2005, when we started to make match3, the code loop was not an issue.
But AGK is interpreted and many loops indeed hurts.
AAA games often rely a LOT on the GPU, anyway, I doubt that AAA games would use a interpreter to parse arrays of datas.

About NG, I have no emergency, it will change when MacOS will not allow anymore 32 bits softwares... I guess there will be a intermediate time because people do not update their OS all at the same time. Porting to IOS seems however a whole mystery.

Derron

Simulation of the world is often done in CPU. And - excuse if I am wrong (I am neither owning AGK nor did I use it) - but wasn't there a "Tier 1" and "Tier 2" thingy, so it is no longer "interpreted"?


Cannot imagine that the interpreted thing is so dead slow. Maybe cut it down to a simple sample. Create a new thread - and let's have the community try out to do the "same thing" in a better "AGK Tier 1"-performing way.


bye
Ron

Pingus

Tier2, for what I understood, is like developing in C++ using AGK as a framework. Why not, but the point of using a 'game engine' is to develop faster and more easily than by coding in C++.

Tier1 (interpreted) is not "dead slow". It is perfectly valid for handling hundred of animated objects that could have simple code attached to it, like an action game or a platform game. But for my match3, I parse arrays that are sometimes like 30x20 or more. Each tile beeing tested with neighbours and with other kind of objects that behave differently.

See here by ex :

https://youtu.be/FTldYoYodjA?t=62


With a  decent PC processor, AGK can probably handle it, but once interpreted on a smartphone... ?
The last thing a develloper would want is to spend some time on a PC version then realize that whatever he does, it will never work on the aimed smartphone.

Derron

The first idea to optimize is:

A B C D E
F G H I J
K L M N O
P Q R S T
U V W X Y


You say you check each neighbor. So If you check "G", you check: ABC, FH and KLM right?
If you always check from top left to bottom right then you know what was processed already.

If you do it "row by row" (from 0 to x-length for each row):
When now processing "H" you know it can skip checks to B,C,D and G. They already checked "G-H"

If you do it "col by col" (from 0 to y-length for each col):
When now processing "H" you know it can skips checks to B,G,L and C. They already checked "G-H"


For "match 3" you mostly check for new "matches" of 3 or more. Of course you only do this when needed: so as long as things did not settle down.
If a tile changes, it marks the whole board "dirty". A tile changes once its effects stopped (blasters exploding other stones, ..., exploding stones animation stopped, ...).

If the board is dirty, your loop is run until nothing is starting a "collapse" now. Then you normally handle your tile updates (blasters, bombs, die animations). After they got updated ("one logic loop") and (at least) one of these marked the board as "dirty", you run your "matched 3 or more"-loop check.

The idea behind is to save performance hitting functions from running everytime.

The next optimization step would be, if you knew all effect ranges (blaster range) in advance, you could mark some kind of "rectangle". This rectangle contains the minimum X, minimum Y, maximum X and maximum Y in which things happened "this logic loop" (aka what got destroyed by the blaster). Then you only "check match3 connections" for the affected tiles (connected ones outside that rect will get found by the ones inside the rect, so no problem there).
This is a similar approach to the "dirty rects" method some of us used during the times 90s or earlier (you only render what has changed)


@ Moderator(s)
Please create a new thread out of the last posts.


bye
Ron

Brucey

Hallo,

@iOS
The last time I tried it, it was able to build all the required bits for running on my iPad.
That was a while ago, and not with the most recent XCode.
Half the problem with iOS development is it's not free, and I didn't renew my Apple wotsit, on account of my recent move. Whether you can still build stuff (but not put it on the store) without having a current sub, I can't remember.
If there's interest, I can look into it.

@switch
Just for fun, I've signed up to the developer program. But as yet I don't have access to the Switch section.
I googled about, and it seems someone has ported SDL2 to it - this raises the possibility that it might in fact be possible to support it.
However, the devkit is (at least) $450, so if I can get to the point of being able to cross-compile stuff, I won't be able to test it on anything.

never say never though :-)



GreyAlien

Hi Brucey! Thanks for the replies. OK well that's pretty positive about iOS. I seem to recall you can compile stuff but you just need the certificates to put it online. Maybe worth a try sometime just to confirm?

Also positive news about SDL2 for Switch though the devkit cost is a bummer.  It sounds like getting BlitzMax working with that would be more sensible than someone doing a "rewrite from scratch" port at least.

Anyway, those things are good to know should I enter into conversations with publishers/porters soon, or be in a position to do them myself.




GreyAlien

@Pingus Ah I just noticed your post, yeah I agree those are the routes. I'm most worried about people porting from scratch because Shadowhand is big and complex and it would no doubt introduce errors and lots of testing etc. (and take too long + cost too much) Therefore I'd much rather get it *mostly* working myself via NG and then passing it over to a porting company to handle all the other crap like different screen sizes/resolutions and new interface changes and then doing all the final tests and uploading to the store etc. That stuff is no fun at all :-)

My only other worry is that I use some kinda crazy 200Hz core game loop and that would be too fast for mobile so that would need changing but then I'd also have to adjust loads of animation timings etc based on that 200Hz. Again, something I'd rather do and test myself before handing to porters/publisher.

Regarding loops in solitaire, you'd be surprised at how many I need ... :-)