Forum Replies Created
-
Posts
-
I think there may be something a bit weird going on with Rnd, will take a look today.
What are you trying to achieve though? There may be an easier way to do it without reflection, or it could be done on the monkey2 side etc…
What the hell are you trying to do?!?
Welcome to mx2!
Were you having some problems with hello-world?
This is just an (incomplete) attempt to make thick lines look a bit nicer. Ultimately, I’d like to store line params in texcoords and let the shader do this but we;re not there yet, ditto with points, ie: it’s WIP.
Max glLineWidth differs on different graphics cards, so can’t be used reliably so mojo draws an ‘oriented’ rect if width>1. I could add an ‘AnitaliasedLiesEnabled’ property, but I’d rather wait until shaders can deal with this.
There is no FSAA yet but it will happen.
Nice bug! Potential fix pushed to develop branch.
if I try to extend MXRectangle (in MX2 code) (so I can add extra code to some of the methods) its asking for the default constructor of MXRectangle ?
This is just normal OO behaviour. You can either added a default ctor to MXRectangle, or use Super.New(…) in dervided class ctors.
Very nice, however one important issue that I should have picked up on earlier…
MXRectangle should be declared as a class not a struct, eg:
123456789101112ExternClass MXRectangle 'Note: No 'Extends Void' - this is a REAL mx2 object!Method New( w:Int,h:Int )EndPublicFunction Main()Local r:=New MXRectangle( 10,20 ) 'easy!EndThe problem with using a Struct Ptr is that GC does not track pointers – only class references (which, yes, are really pointers in C++, but you know what I mean…) – so assigning a ptr to a variable will NOT keep an object alive.
This in fact makes things easier though, as there is no need to use a factory method or bbGCNew() on the C++ side (you still can but you need to be a bit careful – more on this later) and there’s no need to have ‘Ptr’ everywhere in the mx2 code since it’s a real mx2 object.
Sorry about not making that clear earlier, I wasn’t look at all the code!
In this case, there is no need for a dtor as it’s a NOP and bbObject already declares a virtual dtor.
But you can add dtor code if you want. There is no need/way to call super.dtor as c++ already does this for you automatically after your dtor executes.
Coming soon!
Yep, Modifier.Menu is Modifier.Control on all targets except for Mac where it’s Modifier.Gui.
but you could always call the factory place the pointer in a field of a GC’d class that you *then* return from the wrapper… :-/ !
Yes, and this is what I thought you were thinking of in the first place re: bullet. But I like this abuse of multiple inheritance much more (in fact, the litehtml modules uses this approach) – separate wrapper objects get messy as you need to foward ALL methods and allowing users to override virtual methods is tricky.
Try this to create the rectangle:
12RectangleMX* r = bbGCNew<RectangleMX>( w,h );This is mx2’s special ‘new’ to create GC aware objects – it must be used with classes that extend bbObject.
This makes this approach unsuitable for libraries that use ‘factory’ methods to produce objects, but it should work for bullet?
Can you email me the module?
Close!
The problem is with the ‘disambiguation’ bit in RectangleMX’s ctor – your code actually creates a temporary Rectangle on the stack that is immediately destroy when RectangleMX’s ctor exits.
To call a super class ctor from a ctor you need to use this special syntax:
123RectangleMX::RectangleMX(float w, float h):Rectangle( w,h ) {}
