[DruggedBunnyParticipant]

Following on from the above, I’ve posted the final piece of the puzzle. (For now!)

Monkeying Around with mojo3d: Behaviours for simple entity management

This covers the creation of the little white ground markers, showing how Behaviours can be used to manage lots of objects, including those without any physics components, without the need to manually manage lists of entities. You simply place the Behaviour-ised entity in the scene and leave it to update itself.

(Scene.Update, in the main OnRender loop, will call Behaviour.OnUpdate for all entities with behaviours attached.)

Note that there are no manual references kept to the markers whatsoever — markers are created by BulletBehaviour upon impact with the ground, then… that’s it!

In this case, the marker behaviour records the time it’s created, and on each call to Scene.Update, checks if it’s existed for longer than a second. If it has, it deletes itself from the scene.

I’ll try get around to doing some basic mojo3d intro posts in the near-ish future…

Try the demo in the post above if you haven’t already!

[DruggedBunnyParticipant]

Hi all,

I’ve finally published my latest article!

Monkeying Around with mojo3d: more Behaviours… with bullets!

This one simply adds bullets and ground markers, along with a bunch of tweaks to improve the plane’s control, and you can try it in-browser here:

Island WebGL Demo

It’s quite in-depth, so I think you would definitely need to be reading along with the source code in order to make sense of it!

The last post in the series will be to address how the markers work, as these are interesting simply for how they allow management of non-physics entities in the scene.

After that, I’ll probably go back to basics and do a simple intro to mojo3d, as there has been a fair bit of interest lately. (Relatively speaking!)

[DruggedBunnyParticipant]

That’s basically right, though simple assignments can be done if you can define them on the same line, eg. Global a:=1.

You can of course assign them in Main, which, if you think about it, is really what defining variables ‘outside of functions’ was in Blitz & co. Monkey/Monkey2 just adopted the more formal approach of having an explicit Main…

Monkey

#Import "<std>" Using std.. Global a:= 1 Global test:= New Map<String,String> Function Main() test["test"]="Hello" test["temp"]="Bye" Print test["test"] Print test["temp"] End

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

#Import "<std>"   Using std..   Global a:= 1 Global test:= New Map<String,String>       Function Main() test["test"]="Hello" test["temp"]="Bye" Print test["test"] Print test["temp"] End

I tried a few variations but I don’t think there’s a way to initiate the string data on the global line in this case. (Could be wrong… )

[DruggedBunnyParticipant]

Nice!

[DruggedBunnyParticipant]

Nice to see more people dabbling with mojo3d!

[DruggedBunnyParticipant]

Just added a new post:

Monkeying Around with mojo3d: wrapping physics behaviours

This one’s a little technical, and possibly not a lot of fun, relating more to improving the layout of the code.

The next one should be more enjoyable… hopefully later in the week!

[DruggedBunnyParticipant]

I’d suggest opening an ‘issue’ on Github with the solution — it would help others and save you having to manually change it each time if accepted.

[DruggedBunnyParticipant]

Nice to hear! I’ll try do a few more over the next few days/week anyway…

Thanks for the comments!

[DruggedBunnyParticipant]

Just done a follow-up to try and explain how mojo3d Behaviours work, as well as how to apply forces/torques and impulses:

Monkeying Around with mojo3d: physics behaviours

[DruggedBunnyParticipant]

Oh, god no! Desktop web apps are universally AWFUL! And they have to ship with a hundred MB of web browser each time — slow, buggy, terrible “custom” interfaces in every case. No no no!

More seriously, I think the core native stuff maybe isn’t that much for Mark to maintain, at least relative to the std/mojo modules, and they’re all in .mx2 code, so perhaps the C/C++ support isn’t really the larger part of the work. Certainly most of the stuff I’ve reported and had fixed was in the .mx2 realm.

This is the only way I can imagine Mark can commit to supporting the non-wasm platforms, as otherwise nothing’s changed in terms of workload!

(He said, cluelessly.)

[DruggedBunnyParticipant]

I would note this line, too:

I do plan to continue supporting monkey2 on other targets, and will continue to do so for as long as people keep posting issues at github

So get yourself a Github account if you don’t already have one! Mark’s done plenty of fixes for me and it’s easy to report them via:

https://github.com/blitz-research/monkey2/issues

(Main page -> Issues -> New Issue.)

[DruggedBunnyParticipant]

I only really use the mojo3d stuff, but really enjoy it, though it’s been a learning curve in many ways. I also use only the ‘develop’ branch, but find it really stable, regardless.

I think it’s all pretty future-proof, being based on third-party compilers and modern GL. Even if Mark were to stop working on it completely — which sounds unlikely given Mark’s recent update/plans on the News page — it should just keep working…

http://monkeycoder.co.nz/2018/11/11/back-to-the-future/

I’m not so interested in web development, but it should certainly still be interesting, and provide a focus that should also benefit the core monkey2 modules, thereby improving things for those of us who want to keep using it for desktop/other platforms.

He has been quiet the last few weeks… I’m guessing knee-deep in wasm internals!

[DruggedBunnyParticipant]

More work on this!

Source code at:

https://github.com/DruggedBunny/Super-Thrusting-Game

Win32 64-bit build at:

https://github.com/DruggedBunny/Super-Thrusting-Game/releases

Current gameplay is:

Collect all Space Gems to spawn the Atomic Orb, which appears at your start point.

Drop the orb in the Portal Lock (glass sphere) and head for the Space Portal (which will be near straight-up on first level, needs adjusting) — fly through to proceed to next level. (N to skip levels.)

Refuel by landing on pads.

Still lots of problems (frame timing on non-60 fps systems in particular), VR broken, all still very WIP!

Use an Xbox pad if at all possible! Game will use the first one it finds attached.

[DruggedBunnyParticipant]

Cool, I’ll hopefully get to try tonight or tomorrow.

[DruggedBunnyParticipant]

Native HTTPS would be really nice — could probably just borrow from brucey’s libcurl/libcurlssl modules.

Really surprised assimp/mojo3d-loaders don’t do .b3d!

Blitz3D interpreter: surely the stuff of unhinged crack-pipe dreams?

 

For me:

Mojo3d flat-shading mode!

Easier shader stuff, eg. access to depth buffer (not managed to figure this out, though it seems to be in there), and rendering PostEffect shaders at arbitrary resolutions (eg. to a Spectrum 256 x 192 texture, rendered via quad to native 1080p/4K or whatever).

I’ve come to love mojo3d, especially its Behavior-based physics integration!

[Author]

Posts