[Mark SiblyKeymaster]

No, the monkey x documentation is for monkey x, not monkey 2.

If you are unhappy with the monkey 2 documentation, I suggest you take a break from monkey 2 for a while and try again in a few months time or so when the documentation should be much improved.

I am in the middle of writing a 3d engine for monkey 2 and right now that takes precedence, but I’m planning on a big docs effort once that is nearer completion.

[Mark SiblyKeymaster]

Well, there you go. If you want blitzbasic 2.0, go for AGK. If you want a language with perhaps some more modern features, perhaps look into monkey2 – it’s your choice. Locking this now as it looks like its going nowhere.

[Mark SiblyKeymaster]

I have never used AGK so I have no idea what it’s really about. Is it a programming language? A C++ library?

Why not try both and use the one you like the most! Programming tools are a very subjective thing so there’s really no ‘right’ answer here.

[Mark SiblyKeymaster]

And here’s a little test app:

Monkey

#Import "<std>" Using std.. Function Main() Local data:=New AudioData[4] data[0]=New AudioData( 1,AudioFormat.Mono8,11025 ) data[1]=New AudioData( 1,AudioFormat.Stereo8,11025 ) data[2]=New AudioData( 1,AudioFormat.Mono16,11025 ) data[3]=New AudioData( 1,AudioFormat.Stereo16,11025 ) For Local i:=0 Until 4 Print "i="+i For Local f:=-1.0 To 1.0 Step .125 Print "SetSample="+f data[i].SetSample( 0,f ) Print "GetSample="+data[i].GetSample( 0 ) Next Next 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

#Import "<std>"   Using std..   Function Main() Local data:=New AudioData[4] data[0]=New AudioData( 1,AudioFormat.Mono8,11025 ) data[1]=New AudioData( 1,AudioFormat.Stereo8,11025 ) data[2]=New AudioData( 1,AudioFormat.Mono16,11025 ) data[3]=New AudioData( 1,AudioFormat.Stereo16,11025 ) For Local i:=0 Until 4 Print "i="+i For Local f:=-1.0 To 1.0 Step .125 Print "SetSample="+f data[i].SetSample( 0,f ) Print "GetSample="+data[i].GetSample( 0 ) Next Next   End

[Mark SiblyKeymaster]

Nice attempt but it’s not quite right – the Mono8 case at least is broken (haven’t looked at others) as it will convert 1.0 to 0 (should be 255). But this is a long overdue addition anyway so here’s my attempt:

Monkey

Method SetSample( index:Int,sample:Float,channel:Int=0 ) DebugAssert( index>=0 And index<_length ) Select _format Case AudioFormat.Mono8 _data[index]=Clamp( sample * 128.0 + 128.0,0.0,255.0 ) Case AudioFormat.Stereo8 _data[index*2+(channel&1)]=Clamp( sample * 128.0 + 128.0,0.0,255.0 ) Case AudioFormat.Mono16 Cast<Short Ptr>( _data )[index]=Clamp( sample * 32768.0,-32768.0,32767.0 ) Case AudioFormat.Stereo16 Cast<Short Ptr>( _data )[index*2+(channel&1)]=Clamp( sample * 32768.0,-32768.0,32767.0 ) End End #rem monkeydoc Gets a sample at a given sample index. @index must be in the range [0,Length). #end Method GetSample:Float( index:Int,channel:Int=0 ) 'Ok, note that this never returns quite +1.0 as there is one less int above 0 than below 'eg: range of signed ints is [-128,+127] ' DebugAssert( index>=0 And index<_length ) Select _format Case AudioFormat.Mono8 Return ( _data[index] - 128.0 ) / 128.0 Case AudioFormat.Stereo8 Return ( _data[index*2+(channel&1)] - 128.0 ) / 128.0 Case AudioFormat.Mono16 Return Cast<Short Ptr>( _data )[index]/32768.0 Case AudioFormat.Stereo16 Return Cast<Short Ptr>( _data )[index*2+(channel&1)]/32768.0 End Return 0 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

Method SetSample( index:Int,sample:Float,channel:Int=0 ) DebugAssert( index>=0 And index<_length ) Select _format Case AudioFormat.Mono8 _data[index]=Clamp( sample * 128.0 + 128.0,0.0,255.0 ) Case AudioFormat.Stereo8 _data[index*2+(channel&1)]=Clamp( sample * 128.0 + 128.0,0.0,255.0 ) Case AudioFormat.Mono16 Cast<Short Ptr>( _data )[index]=Clamp( sample * 32768.0,-32768.0,32767.0 ) Case AudioFormat.Stereo16 Cast<Short Ptr>( _data )[index*2+(channel&1)]=Clamp( sample * 32768.0,-32768.0,32767.0 ) End End #rem monkeydoc Gets a sample at a given sample index. @index must be in the range [0,Length). #end Method GetSample:Float( index:Int,channel:Int=0 ) 'Ok, note that this never returns quite +1.0 as there is one less int above 0 than below 'eg: range of signed ints is [-128,+127] ' DebugAssert( index>=0 And index<_length ) Select _format Case AudioFormat.Mono8 Return ( _data[index] - 128.0 ) / 128.0 Case AudioFormat.Stereo8 Return ( _data[index*2+(channel&1)] - 128.0 ) / 128.0 Case AudioFormat.Mono16 Return Cast<Short Ptr>( _data )[index]/32768.0 Case AudioFormat.Stereo16 Return Cast<Short Ptr>( _data )[index*2+(channel&1)]/32768.0 End Return 0 End

Note that GetSample will never actually quite return +1.0 (it will return .999 etc for max sample value). This reflects the fact that there are actually fewer sample values>0 than there are <0. Googling around suggests this is the best way to handle that. You can still SetSample 1.0 for max value no problems, it just wont read back as exactly that.

[Mark SiblyKeymaster]

Also, forgot about UpdateWindow(). Add this to the end of TestGui ctor:

Monkey

UpdateWindow( False ) rgtDock.Scroll=(rgtDock.ContentView.MeasuredSize-rgtDock.VisibleRect.Size)/2

1 2 3

UpdateWindow( False ) rgtDock.Scroll=(rgtDock.ContentView.MeasuredSize-rgtDock.VisibleRect.Size)/2

UpdateWindow causes a full window layout update so should be used sparingly, but I think its the right solution in this case.

[Mark SiblyKeymaster]

Actually, ‘field’ inside of method would be cool!

[Mark SiblyKeymaster]

Hi,

Here’s my little hack for initial auto-centering. Just replace RightDock.OnRender wth this:

Monkey

Method OnRender( canvas:Canvas ) Override Super.OnRender( canvas ) canvas.Color = Color.Aluminum canvas.DrawText( "size:" + Frame + " ,scroll:" + Scroll , 5, 5 ) Global _centered:Bool If _centered Return Scroll=(ContentView.MeasuredSize-VisibleRect.Size)/2 _centered=True End

1 2 3 4 5 6 7 8 9 10 11

Method OnRender( canvas:Canvas ) Override Super.OnRender( canvas ) canvas.Color = Color.Aluminum canvas.DrawText( "size:" + Frame + " ,scroll:" + Scroll , 5, 5 )   Global _centered:Bool If _centered Return Scroll=(ContentView.MeasuredSize-VisibleRect.Size)/2 _centered=True End

OK, it’s still not all that pretty, and also relies on a ‘done’ style flag. This is alas not easy/possible to do in the ctor because the gui has not been laid out yet – layout is done just before render so while ctor is executing, nothing has been measured/positioned yet.

I chose this design to minimize layout overhead and to simplify things. Another approach is to, as nerobot says, make views update layout in response to resize events, but in my experience this can lead to considerable layout overhead, and even layout ‘lockups’,  esp. in the case of complex hierarchies as one resize can trigger lots of layout code. I’m not adverse to adding a SizeChanged event, but I am against the idea of it being used to trigger layout.

Mojox uses a pretty simple layout system (largely pinched form Android). Layout is a 2 pass process and is always performed just before rendering (could be optimized/improved here). In the first pass, views are measured ‘bottom up’ using OnMeasure. This initializes their MeasuredSize property. Since measuring is bottom up, parent views can therefore depend on children having already been measured when measuring themselves. In the second pass, views are positioned/laid out ‘top down’. This way, everything is measured *exactly* once, and positioned *exactly* once. Also, properties like ‘Rect’ and ‘Frame’ etc are updated once and always in sync with each other and their true ‘render position’.

There are of course some limitations and issues with the mojox approach. Layout of things like wordwrapped text or html views is tricky, because view height is dependant on view width, and there are some hacks in there for dealing with that . And having layout occur ‘at some point in the future’ can sometimes be inconvenient, but in my experience the benefits are worth it. YMMV.

[Mark SiblyKeymaster]

Have a look at vsynth in bananas. It’s written by skidracer who knows more about SDL mixer than I do.

[Mark SiblyKeymaster]

The use of percentages in docking view means the pane is always that percentage of docking view size, so absolute size will only change if docking view size changes. So a pane that is 25% is always 25%. If you change sizes to pixel size (eg: “60”) it works the way you want, although DockingView is really designed to have a ContentView so may have a ‘hole’ in the middle. I agree percentage sizes should probably have a resize knob too if ‘resizable=true’ and the percentage should mean ‘initial’ size. Will have a look at fixing this.

Another thing you can do is to just keep adding stuff to the “left” of a DockingView so it’s ‘stacks up’ left to right. Then, if you make the last view the ‘ContentView’ you can completely fill up the DockingView as the content view fills up the space left over after all ‘docks’ are added. Just noticed nerobot suggested something similar with VerticalLayout…

Your scrollview isn’t scrolling at least because it doesn’t have any content –  you need to set the ContentView property. The content view of  a scroll view should also have an OnMeasure method as  ScrollView uses content view’s MeasuredSize to determine how large scrollable content is, how large to make scroll bars etc.

Here’s a little scroll view demo showing the basics. Note this doesn’t extend ScrollView as there’s little point here, although if you want to customize scroll wheel handling etc you can do so. Scroll wheel handling in ScrollView uses font height for scrolling I think.

Monkey

#Import "<mojo>" #Import "<mojox>" Using std.. Using mojo.. Using mojox.. Function Main() New AppInstance New TestGui App.Run() End Class TestGui Extends Window Field gameView:GameView Field scrollView:ScrollView Method New() Super.New( "Test", 1024, 640, WindowFlags.Resizable ) gameView=New GameView scrollView=New ScrollView scrollView.ContentView=gameView ContentView=scrollView End End Class GameView Extends View Field text:String Method New() End Method OnMeasure:Vec2i() Override Return New Vec2i( 1920,1080 ) End Method OnRender( canvas:Canvas ) Override RequestRender() canvas.DrawText( "gameview:" + App.FPS + " fps, Width="+Width+", Height="+Height, 5, 5 ) canvas.DrawCircle( 200, 200, 50 ) End 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

#Import "<mojo>" #Import "<mojox>" Using std.. Using mojo.. Using mojox.. Function Main() New AppInstance New TestGui App.Run() End Class TestGui Extends Window   Field gameView:GameView Field scrollView:ScrollView Method New() Super.New( "Test", 1024, 640, WindowFlags.Resizable )   gameView=New GameView   scrollView=New ScrollView scrollView.ContentView=gameView   ContentView=scrollView End End   Class GameView Extends View Field text:String Method New() End Method OnMeasure:Vec2i() Override Return New Vec2i( 1920,1080 ) End Method OnRender( canvas:Canvas ) Override RequestRender() canvas.DrawText( "gameview:" + App.FPS + " fps, Width="+Width+", Height="+Height, 5, 5 ) canvas.DrawCircle( 200, 200, 50 ) End End

[Mark SiblyKeymaster]

I did briefly hack LoadBump so it didn’t need an actual normal map to load – instead it used a default  0,0,1 normal map. This alone allowed you to run stuff like simplelight and lightsparks without having to use bump/specular maps. I reverted this though as I wanted to spend more time on it.

The only bit ‘wrong’ about this is the light intensity was still being multiplied by the ‘N dot L’ term of the lighting equation, which will give different intensities depending on relative positions of pixels/light, which is probably not want you want. I’m guessing you’re after a more full on 2d effect that ignores light direction etc, and this should be doable by tweaking the existing lighting shader a bit.

I now tend to think that just keeping everything 2d and hacking around with blending and offscreen rendering is probably the better solution anyway as even with a hacked lighting shader, you’re still gonna have to do some kludgy rendering to achieve the groovy ‘light cone’ effect. On the other hand, the light shader approach will actually integrate with shadows should  you want to use them.

Anyway, either approach will take a bit of time to experiment with, but like I say it could probably be done right now without having to get down with shaders by using a combo of fancy blending modes and offscreen rendering.

[Mark SiblyKeymaster]

Sorry, but I’m a bit busy with other stuff and wont be able to look into this for a while yet.

You are of course welcome to try yourself! It should be fairly easy with a combination of multiply/additive blending and offscreen rendering. You are likely to have to tweaks things a bit anyway if you want to get *exactly* the same result as above which highly stylized.

[Mark SiblyKeymaster]

I wont be able to do this right away, I have some other stuff to finished up first.

[Mark SiblyKeymaster]

I am expecting the site to be hit with a ton of South Korean casino spam any day now!

[Mark SiblyKeymaster]

Ok, spoke a bit quickly there, neither my ios or android devices support AR. Bummer.

[Author]

Posts