[Mark SiblyKeymaster]

Ok, v1.1.10 is actually faster here for updating modules:

v1.1.09 – update modules, clean existing data checked (ie: rebuild all): 15m 4s

followed immediately by…

v1.1.09 – update modules, clean existing data not checked: 0m 21s

…and…

v1.1.10 – update modules, clean existing data checked (ie: rebuild all): 13m 15s

followed immediately by…

v1.1.10 – update modules, clean existing data not checked: 0m 14s

Both of these used mx2cc built with msvc x64. To do this, you need to change to appropriate scripts dir and updatemx2cc with bin/env_windows.txt set correctly.

I am not exactly sure why it’s faster though. Although I’m constantly making tweaks to mx2cc, c++ compiles still take up most of the time when updating modules. There’s a chance that some change I made could be producing code that is more c++ friendly – wanna see if I can do more of it!

Do you perhaps have space in your project path? There was in fact a bug in mx2cc that I found shortly before the v1.1.10 release that caused mx2cc unnecessarily rebuild output c files that had a space in their path. I thought I had fixed this but maybe not?

[Mark SiblyKeymaster]

What are you building?

I haven’t noticed any obvious slowdowns with v1.1.10 myself, and I rebuild mx2cc/modules a lot!

[Mark SiblyKeymaster]

Yes, x<=>y produces…

an int value=0 if x=y,

an int value<0 if x<y or

an int value>0 if x>y.

[Mark SiblyKeymaster]

You’re meant to combine flags with the | ‘or’ operator, eg: WindowFlags.Resizable|WindowFlags.Maximized.

The fact you can go WindowFlags.Resize.Maximized is a little bugette that I think has already been reported and has just been bumped for fixing priority!

[Mark SiblyKeymaster]

You can already open some 3d file types in ted2go, eg: double click on one of the 3d files in mojo3d/tests/assets.

So you can already use mojo3d in a mojox view. Using a mojox view in mojo3d (eg: have a view mapped onto a 3d box face or something) is technically doable but it would be much harder. I would love to do this for the VR stuff, but unfortunately, I don’t really have the time right now.

[Mark SiblyKeymaster]

Oops, yeah, there’s a bunch of debugging crap in my last commit – sorry, will clean up ASAP!

[Mark SiblyKeymaster]

I would argue that we would need a feature that’s more like Threads in the near future

I agree with this, I think proper threading is the real fix for this instead of hacking in a bunch of async load functions.

Aw, I didn’t see the post with the code and ended up making the asset loading screen in my own caveman style.

Actually, after sleeping on it for a bit I think caveman style is probably the right approach for now!

[Mark SiblyKeymaster]

May I beg the question on what the idiomatic way is for handling memory in Monkey2?

Well, the general idea in monkey2 is to use classes/objects for dynamically created, reference style types, and structs for value style types. This is very similar to Java/C#/D etc. For examples of this ‘idiom’, check out the mojo, mojo3d, mojox modules. This way, you get the full benefit of GC and not worry about memory management or pointer lifetimes etc.

You are free to use ‘pointers to structs’ if you want, but then you’ll miss out on GC and have to deal with manual memory management issues – just like a c/c++ coder, whee! But this is effectively programming AGAINST the monkey2 idiom. The goal is for coders to  never have to use Ptr unless you are heaving to deal with native code, as use of Ptr leads to all sorts of delightful c/c++ problems. Of course, if you’re the one dealing with native code, you’re kind of stuck, but if you’re writing a c++ lib wrapper module, it would be *nice* if it could be wrapped in such a way that users of the module never have to deal with Ptrs. Alas, realistically this isn’t always possible, but it’s also true many monkey2 moduls/libs (eg: assimp, bullet) could be much more elegantly wrapped.

Relevant to this case, I might want to create a pointer and point to a struct. Wouldn’t that be okay?

Of course, but again it’s up to you to manage the lifetime of the pointer/struct. If you don’t want to have to do this, use an object/class instead. If you don’t want to do this either, perhaps monkey2 isn’t for you?

Not trying to piss you off here, but I do get the impression that you are really trying to use monkey2 as kind of a ‘simple c/c++’ and I think in this respect you’ll always be disappointed. C++ is a huge, complex language, whereas monkey2 is (supposed to be) a small, simple language. There is plenty of c/c++ code out there that is NOT trivial to ‘wrap’ for use with monkey2, and that to wrap ‘properly’  would really require some fairly serious native wrapper code (same goes for many languages that need to wrap c++). It probably doesn’t really help that I added some ways to ‘half ass’ the wrapping process – things like Extends Void etc – but what’s done is done.

[Mark SiblyKeymaster]

Here’s one possible approach – build it in the simplelight banana dir or use your own image.

Note that it only syncs with OnRender every .1 seconds (shouold probably be slower?) – if you sync *every* load you substantially slow down loading time of course as waiting for OnRender can take up to 16ms.

Writing truly async loaders should be substantially simpler now as most of the async framework stuff is already in there. The only tricky bits will be the loaders written in pure monkey2 as they will need to be rewritten in c++ to be threadable. The only one I can think of here is the WAV loader.

Monkey

Namespace myapp #Import "<std>" #Import "<mojo>" Using std.. Using mojo.. #Import "Slate Tiles II_D.png" Class MyWindow Extends Window Field image:Image Field progress:Float Field future:Future<Bool> Field time:Double Method New( title:String="Simple mojo app",width:Int=640,height:Int=480,flags:WindowFlags=Null ) Super.New( title,width,height,flags ) New Fiber( LoadStuff ) time=Now() End Method WaitRender() Local elapsed:=Now()-time If elapsed<.1 Return time+=elapsed future=New Future<Bool> future.Get() future=Null End Method SignalRender() If future future.Set( True ) End Method LoadStuff() For Local i:=0 Until 256 progress=i/256.0 image=Image.Load( "asset::Slate Tiles II_D.png" ) WaitRender() Next Print "Finished!" End Method OnRender( canvas:Canvas ) Override App.RequestRender() If image canvas.DrawImage( image,0,0 ) canvas.DrawText( "Progress="+int(progress*100)+"%",Width/2,Height/2,.5,.5 ) SignalRender() End End Function Main() New AppInstance New MyWindow 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 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85

Namespace myapp   #Import "<std>" #Import "<mojo>"   Using std.. Using mojo..   #Import "Slate Tiles II_D.png"   Class MyWindow Extends Window Field image:Image Field progress:Float Field future:Future<Bool> Field time:Double   Method New( title:String="Simple mojo app",width:Int=640,height:Int=480,flags:WindowFlags=Null )   Super.New( title,width,height,flags ) New Fiber( LoadStuff ) time=Now() End Method WaitRender() Local elapsed:=Now()-time If elapsed<.1 Return time+=elapsed future=New Future<Bool> future.Get() future=Null End Method SignalRender() If future future.Set( True ) End Method LoadStuff() For Local i:=0 Until 256 progress=i/256.0   image=Image.Load( "asset::Slate Tiles II_D.png" ) WaitRender() Next Print "Finished!" End   Method OnRender( canvas:Canvas ) Override App.RequestRender() If image canvas.DrawImage( image,0,0 ) canvas.DrawText( "Progress="+int(progress*100)+"%",Width/2,Height/2,.5,.5 ) SignalRender() End End   Function Main()   New AppInstance New MyWindow App.Run() End

[Mark SiblyKeymaster]

That’s probably the way to go for now.

It should be possible to at least RequestRender/Yield between loads, I’ll have a look into that.

[Mark SiblyKeymaster]

Async image/sound loading is not currently supported, and fibers wont really help here as they are cooperative.

[Mark SiblyKeymaster]

Try setting env var __GL_SYNC_TO_VBLANK=1?

http://us.download.nvidia.com/XFree86/Linux-x86/367.57/README/openglenvvariables.html

[Mark SiblyKeymaster]

As far as I can work out, the problem is that vsync support is purely down to the graphics driver, and not all drivers support it. On my cheap and cheerful linux+ATI setup, SwapInterval=1 works fine – which I find mildly surprising because I’m sure I didn’t used to work…

I think this may be because I was running the prorietary ATI ‘fglrx’ (?) driver in the past, but have recently switched to the official ‘open source’ one, which seems to work really well these days. You might want to try this if possible, but if SwapInterval=1 doesn’t work all you can really do is use a timer instead – see spacechimps for a timer demo.

Can anyone shed any more light on this? SwapInterval=1 ultimately results in a single call to glxSwapIntervalEXT, so I’m not sure what else I can do to make it work.

[Mark SiblyKeymaster]

It does indeed sound like there’s something weird going on with your opengl drivers. Your HW looks fine – have you updated your graphics drivers lately?

Deferred renderers are generally faster if you have scenes with lots of lights, with fewer lights they can in fact be a bit slower. On my nvidia 970 they’re about the same with just a single light. On hardware with crappy video memory bandwidth (eg: mobile) deferred is considerably slower – also, many mobile devices don’t even support the necessary opengl extensions needed for deferred renderering.

[Mark SiblyKeymaster]

You don’t need to manage ‘new Structs’ as they are always created on the stack and ‘copied’ into whatever var etc you assign them to.

This goes for both pure monkey2 structs and extern structs.

[Author]

Posts