Mark Sibly

Forum Replies Created

Viewing 15 posts - 1,126 through 1,140 (of 1,431 total)
  • Author
    Posts
  • in reply to: Compilation Error #4105

    Mark Sibly
    Keymaster

    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!

    in reply to: external destructors #4104

    Mark Sibly
    Keymaster

    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.

    in reply to: Mac font Class/module #4093

    Mark Sibly
    Keymaster

    Nice!


    Mark Sibly
    Keymaster

    The 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:

    https://www.appodeal.com/sdk/documentation?utf8=%E2%9C%93&proguard=0&framework=1&platform=1&fs_spec=1&ads_type%5B%5D=1&to_generate=1

    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.

    in reply to: problem with text editing. #4077

    Mark Sibly
    Keymaster

    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…

    in reply to: problem with text editing. #4075

    Mark Sibly
    Keymaster

    You’re reading past the end of line, you need something like:

    But mx2’s not helping here – it should be generating something like ‘index out of range’ when you try to do this. Will fix ASAP.


    Mark Sibly
    Keymaster

    > 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?


    Mark Sibly
    Keymaster

    Do 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.


    Mark Sibly
    Keymaster

    iOS 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!
    in reply to: Is/will there be an Array.Resize() ? #4035

    Mark Sibly
    Keymaster

    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.

    in reply to: XML module #4034

    Mark Sibly
    Keymaster

    Hokay, try again – maybe this time!

    in reply to: you can't have a field in an extend of 'external extends void' #4033

    Mark Sibly
    Keymaster

    Having 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).

    in reply to: Mark – question about additions #4027

    Mark Sibly
    Keymaster

    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.

    in reply to: XML module #4025

    Mark Sibly
    Keymaster

    Ok, this runs for me now!

    Just committed compiler fixes+new binaries.

    in reply to: Is/will there be an Array.Resize() ? #4024

    Mark Sibly
    Keymaster

    Yes there will.

Viewing 15 posts - 1,126 through 1,140 (of 1,431 total)