Forum Replies Created
…and no doubt it’ll all change one day not too far off anyway…
Hezkore promised to do me an autodetect for this!
sh: em++: command not found
Looks like you need to install emscripten:
There’s also an experimental ‘devtools’ style download for 64 bit windows on the downloads page here. Just extract it to your monkey2 devtools dir and you should be good to go. On windows/linux you’ll need to use the above version.
You’ll also need the emscripten ‘mserver’ moini-server from the downloads page to be able to run emscripten apps.
Cool, is it using the github REST api?
OK, things may be a bit rocky on the develop branch until thread support is integrated, although there is still no reason for the EACCES error AFAICT so please update your NDK and see if that helps.
I have successfully updated android components here to Android Studio 3.1.3 ; Android SDK 27 (Oreo 8.1) ; NDK 17.1.4828580 ; Android SDK Tools 26.1.1 and all appears to be OK. I can run the mojo3d template app on an API 27 emulator anyway, yay!
Android building fine here on windows 10.
That’s quite old, I am using 17.0.something plus there are updates – installing now.
edit: if i build then any example it fails with ***** Fatal mx2cc error *****
Have you rebuilt everything? There have been mx2cc changes recently which means mx2cc will need to be rebuild too.
Yes, admod support is for ios/android only.
OK, I’ve just added Time.FromFileTime:Time( fileTime:long ) which can simply be passed a GetFileTime() time, eg:
Local time:=Time.FromFileTime( GetFileTime( filePath ) )
Now up in develop branch.
Woohoo nice, first ‘published’ monkey2 app?
Meh, I don’t trust any of ’em any more!
But I can’t see anything really changing at least in the near future and have no plans to change. Perhaps a few more ads on github, MS are big on that sort of thing going by xbox.
Gitlab is apparently a good alternative although they use cloud space provided by – wait for it – MS! But still, if you make the leap I’d be interested to hear how it works out.
Ok, lights in spacegem seems to be the main cause of slowdown here, if I disable these I can run at 90fps. Will investigate (eventually).
Have you checked it isn’t just good old fashioned slow down? Don’t forget, you need to draw about twice as much in 2/3 the time…
I would suggest turning everything off except the spaceship and see if it’s still slow. If not, keep adding stuff back in etc, comparing framerates as you go so you can see what takes how long etc…
Please report any disfunctional bananas at the github issues page.
Someone got the necessarty apt-gets down to this – I’ll update the SDK docs:
sudo apt-get install g++-multilib libopenal-dev libpulse-dev libsdl2-dev
This is the only reference I can find relating to force/impulse:
The way I read it, ApplyForce does not need to take any sort of duration into account but ApplyImpulse does, ie: impulse=force*time.
So you’ll need to compensate for frame rate here. Easiest was is probably to scale your impulse ‘force’ by (App.FPS/1000.0) which hopefully means apply X force force for 1 frame. I think I’m sort of starting to get it…
Another thing to try would be using ApplyForce instead of ApplyImpulse as this may do the time scaling stuff for you. You may have to use ClearForces() if thrust is NOT being held.
Just checked out the bananas, all working fine although ‘stress-test’ lives up to it’s name, even in release mode FPS drops below 60 sometimes…