Forum Replies Created
-
Posts
-
Ok, just tested mojo3d/tests/ducks on my aging ipad2 and it’s working fine (after the env file tweak) if a little slow…
I am running macos 10.12.6 (16G1036) and xcode 9.1 (9B55).
Yay, this seems to do the trick – will add it to mx2cc_macos so this is automated in future.
xcrun --sdk iphoneos --show-sdk-path
You need to modify the bin/env_macos.txt. Change the line that begins ‘MX2_SDKROOT=…’ to this:
1MX2_SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.1.sdkThis needs to be updated each time a new version of ios is released (apparently about once a week!). I haven’t found a way to ‘automate’ locating this dir yet so for now it must be updated manually.
You may also need to rebuild ios modules depending on what apple has messed with.
Sort of a bug, it’s actually recursing to death as To:Derived is calling Cast<Derived> which is calling To:Derived etc etc.
Not sure of allowing operator To to downcast is such a great idea, could live without it myself but will think about it.
(VarPtr slf)[0])
Please don’t use this anymore, it’ll probably be going soon, along with any sort of ‘Object Ptr’ types.
If you really, really need the adress of an object, you can now use Cast<Void Ptr>( obj ) but of course be careful as the returned pointer will become invalid if the object is GCed, ie: it’s up to you to keep the object alive while you are using the pointer.
Yeah, nah, no way I’m going there…!
There is currently no way to do this.
‘Star Rogue’?
When trying to us some Key.Raw mask within OnEvent I get no result..
Key.Raw mask is only intended for use with keyboard.KeyDown, not events. KeyDown/KeyUp events are always virtual keys.
Use KeyChar events for ‘typed’ characters which are unicode and take into account local shift key layout etc.
In general use KeyDown for ‘control’ keys like arrows, ‘home’, ‘end’ etc. and KeyChar for ‘typed’ keys that have text/unicode representation.
I’m not sure of the legality of redistributing MSVC/Windows kits etc. Can someone reassure me on this point?
As the bunny on drugs mentioned, many of the utility methods such as Move, Rotate are implemented via extensions, which means they’re rather inconveniently located in a separate section of the docs:
file:///D:/dev/monkey2/docs/modules/mojo3d/module/mojo3d-EntityEXT.html
Ideally, I want docs to either link to (at least) extensions in the same module from the class docs page, or perhaps even show extensions in the class itself, but that’ll happen ‘later’. For now, I’m concentrating on the coding part, and being able to implemement this util stuff in a separate ‘extensions’ file is very nice.
I’m not sure why autocomplete isn’t finding them – in fact, it doesn’t seem to be able to find any entity members…will look into it.
#Import <"mojo3d-loaders">
This should be all you need to do to add assimp support to a mojo3d project so you can load b3d, 3ds, x etc.
The ‘turtles’ test in mojo-loaders/tests/ uses b3d I think.
I’m currently working on animation stuff so animated entities are properly copied (doesn’t currently work) and some form of ExtractAnimSeq is implemented, possibly via an Animation.Slice(…) method. Should have some b3d animation demos converted soon.
To hopefully clarify a bit:
It’s sort of the same as if you add something to a global stack. It can never be reclaimed/finalized because the stack itself is keeping the object alive. So this code wouldn’t work:
123456789101112Global stack:=New Stack<C>Class CMethod New()stack.Add( Self )End'Hypothetical finalizer can't work - stack is keeping self alive so this will never be called!Method Finalize()stack.Remove( self )EndEndthe lapsed listener problem.
Yes, this is very much the issue – anything that is listening to an event wont/can’t be reclaimed by GC. And sometimes that’s a good thing, as the event may in fact be the *only* thing keeping an object alive.
When I call Discard I suppose the object will be destroyed and so everything ‘connected/chained’ to it (like the pointer’s function). Or not?
Well, there is no Discard. But sort of – when an object becomes ‘unreachable’ (ie: no vars can see it) all of it’s fields – including all ‘listeners’ of any function pointers – become potentially unreachable. Another way to think about it is, when an object becomes unreachable, all its fields are ‘nulled’ out, meaning other object may become unreachable etc. This is often enough to mean you don’t have to worry about any of this in the first place – when the object that is emitting events itself becomes unreachable, none of this is an issue. It’s when you have a ‘persistant’ object that you want to add/remove listeners to you have to be a bit careful to actually call -= when necessary, or the event can ‘artificially’ keep objects alive for longer than they should be. No magic finalizers can help here, we need magic weak references…
If I’m using sequencer.BeatEmitted=NULL I should ‘clear’ any ‘connections’? Right?
Setting a function pointer to null effectively ‘removes’ all listeners.
Really, some features of the Monkey2/advanced OOP are … obscure to me
But having to deal with adding/removing listeners is a pretty classic programming problem that doesn’t really have much to do with OO.
We’re really getting into the guts of things here too – I’m going into a lot of detail which I hope isn’t putting anyone off, but in practice, none of this is really very complex.
Yes, channel.Stop() is the way you’re supposed to stop music and your code should work fine.
Can you confirm both pieces of music work OK if they are played first? Ditto do both glitch if played second? How about if you play the same piece of music the first and second time?
Can you send me the music files? My email address is blitzmunter at gmail dot com.
and that seems to work, but what if Discard is not called?
If Discard is not called, IGotABeat will never be ‘removed’!
>[EDIT]: Does Mx2 have Destructors?
No.
[EDIT] To clarify a bit: I don’t think they’d be much use in this case – and I assume you mean finalizers, ie: a method called when an object becomes unreachable?
Assigning (or adding) a method to a function pointer has the effect of keeping the method’s ‘instance’ alive for at least as long as the function pointer remains alive, so while an object is pointed to by a reachable function pointer, it will itself be reachable and therefore it’s finalizer will never be called!
Unless of course the function pointer itself becomes unreachable, but at that point there’s no point in the object -= itself anyway.
There is an ‘unsafe’ finalizer in the std.resource.Resource class, but this is only intended for discarding OS resources like files, textures etc. Code in resource finalizers must be careful not to touch member objects, arrays or function pointers as there is no logical ‘order’ in which resource finalizers are called so there is no way of knowing which members may have themselves already been finalized, or even freed, when a finalizer runs.
It might be possible to fix this and add ‘real’ finalizers to the monkey2 language, but I am currently unaware of a way to do it without seriously forking up the incremental GC system and I’m not prepared to do that at this point. If there was a huge demand for it I might be keener (maybe) but I would much rather explore alternate ways to solve problems like this – we have a whole language to play with after all.
But as mentioned above, even with real finalizers we still have a problem in this cae, and the solution probably involves ‘weak references’ of some sort, ie: if you want an object to be able to -= itself from a function pointer when it becomes unreachable, then you’re implying that being assigned to the function pointer doesn’t ‘count’ as being reachable in the first place! And it may be possible to build something like this into the language – I haven’t thought a whole lot about it, but some kind of mechanism that combined finalizers with weak references might be an interesting idea as they kind of imply each other (in the above case anyway).
Not exactly useful info here as I’m running windows 7 and it worked just fine,
Very useful as I now know joysticks work on window 7! Also, 80% success rate…
Sdl2+Mojo works out of the box,
…except for joysticks I assume? ie: joysticks are still crashing on windows 10? Or have you only tried on Macos? I’m actually more interested in Windows in this case for once!
Working fine here on ‘7 with X360 wired controller and XB1 wireless controller
83%!
As for GameController, it’s actually a sort of ‘virtual’ joystick that maps a joystick’s physical axes/buttons to a fixed set of predefined ‘gamecontroller’ axes/buttons, so you can always use the same ‘button names’ no matter what device is attached. It’s something I’ve tried to do in the past in hacky ways but have never really achieved. It’s really nothing monkey2 couldn’t do on it’s own without any help from SDL though. The button/axis mappings are defined in a ‘config’ file so you can add you own mappings. There’s a public database of mappings here:
https://github.com/gabomdq/SDL_GameControllerDB/blob/master/gamecontrollerdb.txt
If your gamecontroller isn’t in the database you’re kind of stuck, you ‘ll need to edit the database file. There’s a pretty cool tool to help with this though:
http://www.generalarcade.com/gamepadtool/
I used this to configure my unrecognized saitek controller and it worked fine. I guess the idea is to do a pull request to the public DB now…might just try creating an issue first, always balls up pull requests! I’d recommend all monkey2 users do this too if they have to add a controller, as it benefits everyone.
The gamecontroller and joystick classes could actually be pretty easily merged, ie: I could theoretically use the gamecontroller database to auto-remap joystick axes/buttons and just ditch ‘game controllers’ altogether (now that I get how it works), although I’m OK with things the way they are right now. Thoughts?
