[Mark SiblyKeymaster]

I couldn’t figure out how to make it night-time…

With black ambient light and no lights in the scene, all you’ll be able to see is specular reflections. By default, mojo3d uses a built in environment map for this, so this is what you’ll be seeing.

The fix here is to use a suitable night-time environment map, but there’s also a Scene.EnvColor hacked in for pretty much this purpose – set this to black to ‘turn off’ specular reflections, ie:

scene.AmbientLight=Color.Black
scene.EnvColor=Color.Black

It would be cooler to find a nice ‘starry’ skybox/envmap though, or to perhaps even generate one randomly.

[Mark SiblyKeymaster]

I managed to get the fetch API going and am in the process of doing an HttpRequest for all targets…

[Mark SiblyKeymaster]

For desktop I would recommend using wget or curl right now as they deal with all the proxy/https etc BS that a raw socket implementation can’t (and I wont be attempting to build libcurl (again) any time soon).

See src/ted2go/product/ModuleManager.monkey2 for an example, esp. DownloadModules() function.

There is no ETA for an emsctipten WGET yet, although there is a ‘fetch’ API that could theoretically do the trick if anyone’s interested in mx2-ifying it.

[Mark SiblyKeymaster]

Nice, rocket model and explosions look cool!

I suspect for max speed for the explosion fragments, you’re probably best manually updating a single model’s vertexbuffer instead of using a Model instance for each triangle, but that’d be a major PITA…

The fragment ‘clouds’ look a bit ‘boxey’ though, I suspect you’re generating velocities via something like Rnd(-1,1) for x,y,z?

You might want to consider normalizing here, eg:


Function FragVel:Vec3f( minSpeed:Float,maxSpeed:Float ) ‘untested!
Return New Vec3f( Rnd(-1,1),Rnd(-1,1),Rnd(-1,1) ).Normalize() * Rnd( minSpeed,maxSpeed )
End


The normalize steps makes the length of the random vector ‘1’, effectively giving you random points on a sphere.

Also, the fragments are doing something weird when they hit the ground, kind of ‘sticking’ or something, perhaps play around with friction or restitution here?

[Mark SiblyKeymaster]

The default timeout is apparently 60 seconds for ios and ‘infinite’ for android. I’ll add the ability to be able to set timeout soon.

What would be a good common default?

[Mark SiblyKeymaster]

Shadow weirdness should be fixed now – well kludged around anyway.

It actually relates to this problem, which appears to be a bug in angle and/or the d3d compiler:

https://bugs.chromium.org/p/angleproject/issues/detail?id=2571#c5

I found ‘shaderfrog’ in the process which is kind of fun and should help to narrow down such bugs in future:

https://shaderfrog.com/app/view/2329

Would love to do something like this for monkey2 too!

[Mark SiblyKeymaster]

Nice find on the collision detection stuff, I was doing it wrong. Things were actually colliding with terrain even if just bounding boxes intersected, should be fixed now.

Note that CollisionMask and CollisionGroup are bitmasks, each collision type should get 1 bit eg: 1,2,4,8,16 etc. then you ‘or’ together all the types you want to collide with. You may already realize this of course – your demo only uses type 1 and 2 so it’s hard to tell, but I’ll look into making this stuff more intuitive ASAP.

I can probably wangle something with alpha objects casting shadows but there might be some limitations, eg: self shadowing may or may not be a problem. Will look into this too.

[Mark SiblyKeymaster]

Nice catch Arpie, and glad to hear it runs on a  GalaxyS8 now!

[Mark SiblyKeymaster]

You can ignore deprecated warnings, I’ll fix these soon.

I don’t have a Galaxy S8 so that’s a little more serious. All 3D is working fine here in emulators and on my nvidia shield so I’m kind of stuck there. Can you see/post logcat output?

[Mark SiblyKeymaster]

The general idea is for mojox to do all the layout stuff for you, so you don’t have to worry about positions/sizes etc so much. This allows guis to work on a wide range of resolutions and devices and to respond very dynamically when windows are resized etc.

You generally create a hierarchy of views using DockingViews, ToolBars, ListViews, TreeViews, GridViews etc and mojox does the positioning and sizing for you when it needs to update the GUI layout.

[Mark SiblyKeymaster]

The main idea is to write a ‘GameView’ style class that implements your game rendering, and then to add that to your app’s view hierarchy, eg:

Monkey

#Import "<std>" #Import "<mojo>" #Import "<mojox>" Using std.. Using mojo.. using mojox.. Class GameView Extends View Method OnRender( canvas:Canvas ) Override canvas.DrawText( "Game Rendering goes here!",Width/2,Height/2,.5,.5 ) End End Class GameWindow Extends Window Field _gameView:GameView Field _textView:TextView Field _dockingView:DockingView Method New() _gameView=New GameView _textView=New TextView _dockingView=New DockingView _dockingView.ContentView=_gameView _dockingView.AddView( _textView,"right",320,True ) ContentView=_dockingView End End Function Main() New AppInstance New GameWindow App.Run() End

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49

#Import "<std>" #Import "<mojo>" #Import "<mojox>"   Using std.. Using mojo.. using mojox..   Class GameView Extends View Method OnRender( canvas:Canvas ) Override canvas.DrawText( "Game Rendering goes here!",Width/2,Height/2,.5,.5 ) End End   Class GameWindow Extends Window Field _gameView:GameView Field _textView:TextView Field _dockingView:DockingView Method New() _gameView=New GameView   _textView=New TextView   _dockingView=New DockingView _dockingView.ContentView=_gameView _dockingView.AddView( _textView,"right",320,True ) ContentView=_dockingView End   End   Function Main() New AppInstance New GameWindow App.Run() End

This sets up a docking view that contains your game view as its ‘main’ view and adds a resizable TextView on the right.

Have a look in modules/mojox/tests for some mojox examples.

[Mark SiblyKeymaster]

Very cool! Landing on its own is quite fun, how about…

• A landing zone target(s).
• Ability to crash the landing if you’re going too fast or land too far from target.
• A velocity readout/indicator, perhaps turns red if you’re going too fast?

[Mark SiblyKeymaster]

Thanks eyeryone!

[Mark SiblyKeymaster]

I actually want to move the ball-pivot to the bottom of the rocket here, rather than the centre of the body.

Assuming the orb starts out in the right position relative to the rocket, the orb relative pivot (ie: ConnectedPivot) can be automatically calculated from the rocket relative pivot.

For example, if the joint is attached to the rocket (not the orb) and the orb is positioned 10 units below the rocket and you’ve set the joint pivot to 0,-10,0, then the orb relative pivot must be 0,0,0. Ditto if you set the joint pivot to 0,-5,0 then the orb pivot must be 0,+5,0.

The only time this wont work is if you start the orb out in the ‘wrong’ place, ie: at a position where the 2 pivots are not touching in world space.

I mention this because I’ve had a quick look at other joint types and there’s a lot of redundancy where you have to specify the connected pivot/axis/matrix, but these can potentially be calculated from the joint pivot/axis/matrix.

Worse case is the FixedConstraint where you need to specify a LocalMatrix for both bodies. However, if we assume everything starts in the right position, this can be made totally automatic. It turns out fixed constraints are springy too which is kind of cool.

[Mark SiblyKeymaster]

Also, should I remove ConnectedPivot? I can actually calculate this by moving the local pivot into the connected body’s space.

This does assume that you’ve initialized the bodies so they are in the correct relative position though.

[Author]

Posts