Forum Replies Created
-
Posts
-
Should be working now.
OK. Why would you want to use Extension instead of Extends?
The main advantage of extensions is that they can be used with objects that you *didn’t* create. With inheritance, you need to be in control of the ‘new’ that creates the object.
So the above ‘Grow’ extension can be used with any Rect, not just ‘MyRects’ or some other class that Extends Rect. (also, you can’t currently extend structs anyway but that’s not really the point here!).
You can do all sorts of cool things with extensions, like add a DrawMysprite() method to canvas, To:String() or To:JsonValue() to *anything* etc.
There can also be multiple extensions of the same class, as opposed to single inheritance where you can create a new CoolRect1 or a CoolRect2 – but not both.
It’s important to note that extension methods are really just global functions (which is why I was a bit wary of adding them in the first place). But in mx2, some functionality can only be achieved via methods, eg: operators, To:String() etc, so they provide quite a nice way of dealing with that.
Here you go..
1234567891011121314151617181920#Import "<std>"Using std..Struct Rect<T> ExtensionMethod Grow:Rect<T>( size:T )Return New Rect<T>( min.x-size,min.y-size,max.x+size,max.y+size )EndEndFunction Main()Local r:=New Recti( 0,0,10,10 )r=r.Grow( 5 )Print rEndActually took me a few attempts to get right – you should be able to use plain ‘Rect’ inside the extension instead of ‘Rect<T>’ (the way you can inside normal class decls) but that’s not working. Will look into it eventually, but Rect<T> will always work.
New build of openal.so is up now.
ShadowCaster is currently just a simple container for vertices, it doesn’t really ‘manage’ them.
So you can add vertices by doing something like:
123456789Local verts:=new Stack<float>verts.Push(...)verts.Push(...)verts.Push(...)verts.Push(...)Local shadowCaster:=New ShadowCaster( verts.ToArray() )...if we need to change them later...shadowCaster.Vertices=verts.ToArray()I guess it could include a stack, but this would just be ‘deadweight’ once the app was running, unless apps have a need to add vertices in realtime?
Here, Cmd-Q quits ted2 but not mojo apps.
This is because I’m ‘faking’ Cmd-Q in Ted2. On windows, Alt-F4 is automatically converted to a ‘close window’ message by the OS, but macos doesn’t do the same with Cmd-Q.
It’s easy enough to fake it for macos mojo apps too the way I do with Ted2 though, and I think it’s a good idea – you can always intercept the window close event to prevent it. Any objections?
Can you post an issue for this?
> Same size, but wrong location!
Ha, yes! Will fix.
I presume GitHub’s the correct place to post bugs, then?
Yes, I’ve grown to like it a lot compared to my old ‘bug reports’ forum approach.
I didn’t know if this was intended behavior or not.
When in doubt, post, I can always just chuck it later.
Woah, somone’s actually *using* the android target?!?
Double woah, lightsparks works really nicely on my Shield! And, once I remembered to build modules, it’s a pretty smooth build/run process.
As for the strof issue, according to both the thread you linked to above and this thread here:
http://stackoverflow.com/questions/14571399/android-ndk-cant-find-atof-function
…it should be enough to set APP_PLATFORM in Application.mk for the openal.so project to an api version <=19.
The project that builds openal.so isn’t actually included in the mx2 repos (it’s here: https://github.com/apportable/openal-soft.git) but looking at it now, APP_PLATFORM isn’t set to *anything* in Application.mk. And I’m getting a warning when building about api 24 being greater than minsdk version, so it’s probably using api 24.
I’ll rebuild openal.so using api 10 (which is the what the mx2 product minsdk is) and upload soon.
mx2cc has actually had a ‘-semant’ option for a few versions now, in fact it now has -parse, -semant, -translate, -build and -run. Specifying any of these automatically include the previous ones, eg: -semant means -parse, -semant, while -run includes all of ’em.
Probably easier easiest if I add this myself as it’s in the middle of the/my buildactions file.
Can you post this to github issues, so it doesn’t get ‘lost’?
Use a libc.char_t for the param type, eg: SomeFunc( chr:libc.char_t ).
did you try using a c++ nullptr instead of the bb_array_null
No, but I doubt it would work as it’s still just a const 0.
The problem was my nasty habit of using -> with null ptrs. This officially became ‘undefined behaviour’ a few years back, so compilers are now starting to optimize out stuff like ‘this==0’, ‘!this’, ‘this==nullptr’ etc, because ‘this’ can/will never be null in a ‘well formed’ program.
So the ‘length()’ method, which used to be ‘return this ? this->length : 0’ was being optimized down to plain old ‘return this->length’.
The bb_array_null global fools/forces the compiler into always doing the ‘this’ comparison, since the compiler can’t know that nothing else changes bb_array_null (even though nothing does). But of course this involves an extra pointless read of the global.
I could make Length a static/extension method, but the real fix IMO is to turn arrays into ‘handles’ that contain the pointer to the array (which they have been on and off during mx2 dev) and I’m in the process of doing that now. It will break any native code that use bbArray (easily fixed though) but it needs to be done so the sooner the better.
Besides, it’ll make arrays much nicer to use with native code, eg: instead of “bbArray<bbInt> *p=bbArray<bbInt>::create( 100 )” it’ll just be “bbArray<bbInt> p( 100 )”. Also, you’ll be able to index via plain operator[] in native code instead of current ugly (*p)[] or p->at().
I managed to reproduce this by installing/building with gcc-6.
There’s a quick ‘n’ dirty fix up now at github, let me know if it works!
Actually, I think I may have a clue what’s going on here – thanks for exe it should prove helpful.
