This topic contains 8 replies, has 3 voices, and was last updated by 
Mark Sibly
2 years, 7 months ago.
-
Posts
-
I get a “gcMark” error…
May be it’s by design with the difference of gc management. I have to use a pointer to the object.
Files are attachedI’ll fix the compiler error, but the main problem here is you shouldn’t really store GCable objects (like MiniFoo) in non-GCable objects (like Foo or any subclass) as Foo’s fields will not be garbage collected (since Foo isn’t) and MiniFoo will eventually be GCd unless you have somehow made sure it’s kept alive elsewhere. I think this should be prohibited altogether.
Using a Ptr – or even a Ptr to a struct that contains a MiniFoo – wont help because MiniFoo still wont be found by the GC.
If you really need to do this, the safest way is probably via an int handle, and an IntMap<MiniFoo> somewhere that assocates handles with objects.
My aim is to pass the canvas passed to OnRender to my box2D debugdraw.
Is there any chance the gc could reallocate the canvas while OnRender is processing?
If not the pointer to canvas should be way more convenient than a handle. My tests worked fine. I pass the varptr canvas to my debugdraw object just before I ask for a draw. Never had any memory violation or visual incoherence.
Actually I don’t see how to create handles. Would I need to call gcnew myself on the cpp side and understand how gc works?
My aim is to pass the canvas passed to OnRender to my box2D debugdraw.
The safest way would be to pass it as a parameter if possible.
Failing that, a canvas ptr will work as long as you stick the canvas somewhere the gc can see it, eg: in a monkey2 global. Then, c++ code can safely use the pointer as long as you don’t modify the global, as the gc will be keeping the global alive. If that’s what you’re doing, it’s not a bad solution.
The OnRender canvas will indeed probably ‘survive’ at least one pass through OnRender without you having to do anything tricky (right now it’ll probably survive for as long as the window) but I can’t guarantee that’ll be true forever.
1> The safest way would be to pass it as a parameter if possible.So just to be sure, is this safe?:
12345Method OnRender( canvas:Canvas ) OverrideApp.RequestRender()canvas.Clear( Color.Black )polys.Draw(canvas) 'set color and DrawPrimitives in the methodEndusing a pointer to the global/Field sticked to canvas
[/crayon]123[crayon-5cba16a3c057a879288047 inline="true" ]b2canvas=canvasDDrawer.CycleInit(Varptr b2canvas,40,viewpoint)world.DrawDebugData()gives the folowing error:
-for Field:
no known conversion for argument 1 from ‘bbGCVar<t_mojo_graphics_Canvas>*’ to ‘t_mojo_graphics_Canvas**’
-for global:
no known conversion for argument 1 from ‘bbGCRootVar<t_mojo_graphics_Canvas>*’ to ‘t_mojo_graphics_Canvas**’but maybe doing the following would “save” the canvas too?
[/crayon]123[crayon-5cba16a3c057f252828430 inline="true" ]b2canvas=canvasDDrawer.CycleInit(Varptr canvas,40,viewpoint)world.DrawDebugData()Just passing canvas as a plain parameter would be the safest/cleanest if this is possible.
It’s kind of hard to suggest the best approach without knowing more about your code – if you’ve got something that works probably best to just stick with it for now until you have more to show/share.
I decided to use the good old global sharing, not elegant but should do the job. And I had better perfs compared to “canvas ptr”…
If you are interested into having a sight on the approach, you can see full code on github: https://github.com/abakobo/Box2D_for_monkey2
thx for the suggestions
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).
You must be logged in to reply to this topic.