Forum Replies Created
-
AuthorPosts
-
The Stargate source is old and hasn’t been upgraded to the latest mx2 yet – I have a version here that’s ‘almost’ done but I never quite get around to finishing it!
Try this:
Method Destroy() Extension=”delete”
This will convert blah.Destroy() to delete( blah ) in native code – a bit sneaky but it appears to work.
Nice!
September 23, 2016 at 10:40 pm in reply to: Your help in my decision please. Mx2 ready to start mobile project? #4079The basic plan is move all the ugly/target specific stuff out of modules and into the target project.
There will still need to be modules to ‘talk’ to the target project of course, but I’m not going down the road of supporting manifest file tweaks, or importing bizarro ‘subproject’ libraries (now deprecated of course) like I tried to do with mx1. It never really worked, and it definitely never ended!
This time around, the approach will consist mainly of leaving it up to users to come up with their own ‘target project templates’ for various SDKs that they will hopefully share around. Such a template would consist of, for example, a ‘raw’ android project with the following changes:
Done!
Well, not quite, we still need an mx2 module to ‘talk’ to the crapware code, and in the case of android I plan to do a simple c++->java translator, with JNI on the c++/mx2/module side and a simple relection based java interpreter on the java/target project side. For ios, things are even easier here as it’s all c++.
This approach is more monolithic than what I tried to do with mx1, but IMO that mostly failed as admob (esp. the latest ‘upgrade or else’ version) ended up mostly ‘baked in’ to the android project anyway and, more importantly IMO, anyone who wanted to use something else was in for a world of hurt because they *couldn’t* just follow the instructions ala appodeal setup above, they had to deal with a rats nest of code in several different places and a bunch of nasty hooks that may or may not do what they need.
Note that there will always be some simple SDKs where it will be possible to just #import and that’s it – stuff that only needs to import a lib or something. But for SDKs that require 5 pages of ‘do this to your project, do that to your manifest, add this to your gradle build file…’ etc etc, nah, not going there again.
I think this approach will work well for 99% of users:
** Much easier to create a new project.
** Everything is ‘target project IDE’ friendly, so mucyh easier to tweak *anything*.
** Don’t happen to worry about tweaks in the native IDE getting overwritten.
** Much easier to implement a new SDK.
** SDK code gets direct access to Activity class, app delegate (eventually – app delegate is currently in SDL2 but I think it should be moved to a target project source file).
Where it gets a bit dicey of course is if you want a ‘googleplay+appodeal’ project, in which case you will need to roll your own if there isn’t one already. But the mx2 modules wont need to be rewritten and it will only involve starting with a googleplay project and following the SDK setup instructions for appodeal on top. It’s just something I can live with for the vast amount of simplification it provides.
Your first while loops compares char at j with 32, without first checking that j<line.Length. With char index checking on, it indeed fails here on the first line of the text file.
Your second while loop is better, but it checks j<line.length *after* reading char at j so the check is too late.
it works fine.
This is because Mid() uses Slice, which does a range check so it’ll be returning an empty string once you go past end of line. Here, it works for a bit longer with this change but I eventually get a ‘memory access error’.
String char index checking would have made this 100 times easier to find (can’t believe it wasn’t there – sure it used to be), so it’s my fault really…
You’re reading past the end of line, you need something like:
Monkey123456789While j < lines[i].Length And lines[i][j]<>32s += String.FromChar(lines[i][j])j+=1WendWhile j < lines[i].Length And lines[i][j] = 32j+=1WendBut mx2’s not helping here – it should be generating something like ‘index out of range’ when you try to do this. Will fix ASAP.
September 23, 2016 at 7:04 pm in reply to: Your help in my decision please. Mx2 ready to start mobile project? #4073> Do you plan for mx2 to automate the nightmare hell of various modules requiring specific changes to the project files?
Not sure what you mean here, which project files?
September 21, 2016 at 10:12 pm in reply to: Your help in my decision please. Mx2 ready to start mobile project? #4054Do you plan to support armv7s, arm64, simulator builds in the near or distant future?
arm64=near future, simulator=later…
What is the state of 3rd party native module support for these platforms?
Non existant.
It’s early days for mobile and it sounds to me like your after something more complete. My primary goal is to get games running well on mobile and work with the community to get the crapware/monetization side of things going and that could be a while off yet.
September 21, 2016 at 7:07 pm in reply to: Your help in my decision please. Mx2 ready to start mobile project? #4052iOS support is already up and running!
It’s still very immature (as is android) but you can generate xcode projects that run.
There are some limits:
- armv6 only – no arm64 support yet.
- It can only generate code for real devices, not the simulator.
- No touch support yet beyond mouse emulation (ditto android).
- Likely to be many bugs!
Just added a ‘1D’ resize and committed it.
It works the same as mx1, ie: you can’t resize an array ‘in place’ – it always returns a new array.
N-D versions of slice, resize etc will happen when I work out how to do them! In the meantime, you can use array methods on N-D arrays if you want, although they’ll always treat the N-D array as 1D, and return a 1D array.
Hokay, try again – maybe this time!
September 19, 2016 at 9:29 pm in reply to: you can't have a field in an extend of 'external extends void' #4033Having seen the code, I agree this is probably the easiest/safest way to do what you need in this situation.
For some reason, I was thinking that you were wanting to access mx2 objects from c++ (in which case directly accessing the ‘name mangled’ global would work just the same).
By color extensions, do you mean the extra color consts? If so, this will probably happen eventually (although I’m not too keen on adding too many) but it’s low priority right now.
I recommend posting issues at github if you want features added – just mentioning/requesting stuff in the forums wont generally work as it just scrolls off into oblivion after a while, or I might not even see it in the first place.
Ok, this runs for me now!
Just committed compiler fixes+new binaries.
Yes there will.
-
AuthorPosts