[Mark SiblyKeymaster]

Or is it to do with drawing different textures?

More than likely – changing some rendering ‘state’ (blendmode, shader, material etc – NOT color or matrix) will cause an internal ‘flush’ which will slow things down. Worse case would be something like…

Monkey

For Local i:=0 Until lots canvas.DrawImage( image1,x1(),y1() ) canvas.DrawImage( image2,x2(),y2() ) Next

1 2 3 4 5

For Local i:=0 Until lots    canvas.DrawImage( image1,x1(),y1() )    canvas.DrawImage( image2,x2(),y2() ) Next

…where image1 and image2 used entirely different textures.

This would not be able to queue ANY draw ops, ie: each: DrawImage would effectively be doing a Flush.

Sorting drawing ops ‘by texture’ (ie: ‘by image’ ) will minimize these problems. Ditto, sorting by blendmode, ie: draw all opaque objects, then all transparent objects.

Using a texture atlas will also help a great deal, as an atlas allows you to draw different images from the same texture.

Perhaps the above test could be modified to include a togglable ‘sort by texture’ mode to show the difference?

[Mark SiblyKeymaster]

Just did a few experiments, and -Os seems to be fastest and produces smallest output file sizes. I think I’ll change debug opts to this.

The main overhead once everything’s built the first 2 times is linking. Switching to MSVC can greatly reduce link times, but can be a bit fiddly to get going.

[Mark SiblyKeymaster]

This can happen in mingw when using reflection in debug mode – the compiler is generating too many symbols and is hitting some kind of built-in hard limit. I can do the same thing to ted2go by adding #import “<reflection>”.

The reflection system needs some mechanism to prevent it generating reflection info for *everything*, which is something I hope to work on soon. This should both speed up compile times for apps that use reflection and hopefully fix this problem in general.

In the meantime, you can try using MX2_CPP_OPTS_WINDOWS_DEBUG=-O2 in bin/env_windows.txt, or building in release mode. This fixes the problem for ted2go anyway.

[Mark SiblyKeymaster]

Yuck! But it works…

What’s probably needed is something like SetStyle in the Theme class, so you can programmatically set any style used by the gui internals that you don’t get to directly create, like MenuButton etc. Will look into adding this.

A theme json file is still IMO the best way to do all styling…

(hmm…does F1 no longer show docs? It shows the status bar quick-help but it used to open actual docs I think?)

[Mark SiblyKeymaster]

It looks nifty, so I’m wondering: Is that not a good cross-platfom choice?

It looks OK, though I’d prefer something that didn’t need ‘org’ and ‘app’ params, so it could be used like ‘intern::blah’ etc.

Mobile app always ‘know’ their own name, so this is only really a problem on desktop. Perhaps some global vars could be added here for desktop apps to set before they Run()? Other ideas?

[Mark SiblyKeymaster]

There is no specialized terrain class as yet (I am working on one), however there are Mesh.CreateTerrain and Model.CreatTerrain extensions for creating plain mesh based terrains. Here’s a quick, somewhat ropey demo:

Monkey

Namespace myapp #Import "<std>" #Import "<mojo>" #Import "<mojo3d>" #import "assets/terrain_256.png" #Import "util" Using std.. Using mojo.. Using mojo3d.. Class MyWindow Extends Window Field _scene:Scene Field _camera:Camera Field _light:Light Field _terrain:Model Method New( title:String="Simple mojo app",width:Int=640,height:Int=480,flags:WindowFlags=WindowFlags.Resizable ) Super.New( title,width,height,flags ) 'create scene ' _scene=Scene.GetCurrent() _scene.ClearColor=Color.Sky 'create camera ' _camera=New Camera _camera.Near=.1 _camera.Far=100 _camera.Move( 0,15,-20 ) Local fly:=New FlyBehaviour( _camera ) 'create light ' _light=New Light _light.RotateX( 60 ) 'create terrain ' 'heightmap Local terrain_hmap:=Pixmap.Load( "asset::terrain_256.png" ) 'material Local terrain_material:=New PbrMaterial( Color.Green ) 'model+mesh _terrain=Model.CreateTerrain( terrain_hmap,New Boxf( -256,0,-256,256,32,256 ),terrain_material ) _terrain.CastsShadow=False End Method OnRender( canvas:Canvas ) Override RequestRender() _scene.Update() _scene.Render( canvas,_camera ) canvas.Scale( Width/640.0,Height/480.0 ) canvas.DrawText( "Width="+Width+", Height="+Height+", FPS="+App.FPS,0,0 ) 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

Namespace myapp   #Import "<std>" #Import "<mojo>" #Import "<mojo3d>"   #import "assets/terrain_256.png"   #Import "util"   Using std.. Using mojo.. Using mojo3d..   Class MyWindow Extends Window Field _scene:Scene Field _camera:Camera Field _light:Light Field _terrain:Model Method New( title:String="Simple mojo app",width:Int=640,height:Int=480,flags:WindowFlags=WindowFlags.Resizable )   Super.New( title,width,height,flags ) 'create scene ' _scene=Scene.GetCurrent() _scene.ClearColor=Color.Sky 'create camera ' _camera=New Camera _camera.Near=.1 _camera.Far=100 _camera.Move( 0,15,-20 ) Local fly:=New FlyBehaviour( _camera ) 'create light ' _light=New Light _light.RotateX( 60 )   'create terrain ' 'heightmap Local terrain_hmap:=Pixmap.Load( "asset::terrain_256.png" )   'material Local terrain_material:=New PbrMaterial( Color.Green ) 'model+mesh _terrain=Model.CreateTerrain( terrain_hmap,New Boxf( -256,0,-256,256,32,256 ),terrain_material ) _terrain.CastsShadow=False End Method OnRender( canvas:Canvas ) Override   RequestRender() _scene.Update() _scene.Render( canvas,_camera )   canvas.Scale( Width/640.0,Height/480.0 ) canvas.DrawText( "Width="+Width+", Height="+Height+", FPS="+App.FPS,0,0 ) End End   Function Main() New AppInstance New MyWindow App.Run() End

Stick this in mojo3d tests/ dir. It would of course look a lot better with textures and there’s no easy way to do collisions yet (possible-ish though, see mojo3d-physics tests).

[Mark SiblyKeymaster]

Have a look at this thread for a similar discussion re: mojox and how layout works in general (near the end).

MojoX GUI questions

Use window method UpdateWindow( False ) in window ctor to force a full window layout which will update all view sizes. Views aren’t normally resized until just before rendering during a layout phase – more info here:

http://monkeycoder.co.nz/forums/reply/10228/

In general, mojox is designed to automate layout as much as possible, making it highly reactive. However, people who are used to maxgui etc and having to do layout ‘by hand’ might find it a bit confusing.

How do I change the font of the menus?

There may actually be no programmatic way to do that right now, I will have a closer look at some point. You should be able to do this by setting the MenuButton{} style in a theme file though. I would actually recommend using a theme file anyway, but it really should be possible to set menu button font programmatically too.

[Mark SiblyKeymaster]

Pretty sure I know what’s going on here.

Skin extends Resource which extends BBResource which…is a native class, and native classes cannot be reflected (yet?).

There is a simple fix for this though that has unfortunately failed to make the v1.1.08 release of about half an hour ago! Oh well, next time…

[Mark SiblyKeymaster]

Woah, had forgotten completely about that – please ignore it, I’ll probably remove it for the 1.1.08 release.

An SDL style GameController would be nice though IMO, and I think this is what I started out with but ended up getting a bit carried away.

[Mark SiblyKeymaster]

Hi Danilo, glad to see you back.

Monkey2 v1.1.08 should be released very soon, this week sometime I hope. It’s pretty much the same as the current develop branch which should be easy to build if yer curious.

[Mark SiblyKeymaster]

I’m waiting for such filter!:)

Soon – hopefully by v1.1.09!

[Mark SiblyKeymaster]

Change this…

MainView.AddView(WorldDoc, "top")

…to this…

MainView.ContentView=WorldDoc

The problem here is that ‘border’ views added to a DockingView (ie: views added via AddView, not the ContentView) should implement the OnMeasure method, as this is how the docking view knows how high (for top/bottom views) or wide (for left/right views) the border views should be for layout.

The ContentView of a DockingView does not actually need to implement OnMeasure as it gets all the remaining space once the border top/bottom/left/right views are added. The size of the ContentView as returned by OnMeasure is effectively ignored.

I think OnMeasure might return 0,0 by default. It’d probaby be better if it returned 16,16 or something else non-null so in cases like this at least something gets rendered.

[Mark SiblyKeymaster]

Nice bug, will fix it!

For DrawPolys, it’s close to what I need, but all of the private AddVertex methods transform the vertices by the matrix, I think I’m right in saying.

The idea is it would still transform positions, colors etc if it had to (ie: if matrix was non-null and/or color was non-white). This is pretty much the same as the existing DrawPolys methods, only with more convenient Vertex2f style parameters.

I’m stubbornly using my own matrix tree and display transformation code

No problem, glad you find the rest of it useful, go nuts!

[Mark SiblyKeymaster]

Have you looked at DrawPolys? I have also been considering adding a version that takes Vertex2fs for max flexibility+speed. Plus, the API would be much cleaner!

You are free to mess with whaever you want to of course, but just be aware that AddDrawOp (or indeed anything private) could be changed or even removed in future from the BRL version of Canvas.

[Mark SiblyKeymaster]

Have you tried the latest develop branch (mx2cc is v1.1.08 now)?

Have you deleted .build and .products dirs (.products dir needs to be deleted if I modify the android studio project template too much – templates are in /products dir)?

I was tooling around with android yesterday and it was working fine, athough I was only building the musictest banana.

[Author]

Posts