[arpieParticipant]

So it looks like I didn’t fully understand SwapInterval after all.  Thank you, Mark for linking to the relevant docs.

And thank you to all of you for taking the time to look at this.

I am still convinced something odd is going on.  Back at 60fps with SwapInterval = 1, I still get less visible lag if I call Timer(60, RequestRender) instead of calling RequestRender() from OnRender()… but I’ve looked through the mojo source and afaict there is absolutely no reason why it would make any difference!

I think for now I am just going to hide the pointer and move on to coding something more interesting.  How exactly do I go about hiding the pointer I wonder…?

[arpieParticipant]

@peterigz I think I have already understood what SwapInterval means.  In my above post (#5882), I set SwapInterval = 30 and I get 1 OnRender call every 30 vsyncs.  Here, that runs at 2 frames per second (according to the App.FPS variable).  When I move my mouse over the window, there is a 2 second delay before the crosshair moves.  That is 4 times slower than it should be.  Isn’t it?

I think this is a Monkey2/Mojo bug but would like somebody else to confirm they are seeing the same results and that I am not doing something silly.  Please try running the code I posted above and tell me if you see the same as I do.

At full speed (60fps), using a Timer() function to call RequestRender actually gives acceptable results here.  There is an expected slight lag but it is not too bad.  Calling RequestRender() in OnRender() is much slower.

[arpieParticipant]

I’m on Arch Linux running Gnome3.  That does look like a similar issue… did you find a fix?

[arpieParticipant]

Deleted.  Mark’s answer was much better

[arpieParticipant]

There is definitely something funny going on here.  If I turn the framerate down to 2fps, the problem is obvious.

Reducing the framerate by setting SwapInterval = 30 and calling RequestRender() in OnRender(), the lag is massive.  Whenever I move the mouse, there is a delay of about 2 seconds before the crosshair moves.  Surely this is a bug?

If I use a Timer() to call RequestRender, at a rate of 2 per second, the delay before the crosshair moves is about half a second (as I would expect, given the framerate).

Can anybody confirm they are getting the same results?  It may be an issue with just my OS, I guess.  I’m running Gnome Desktop on Linux.  I don’t have a Windows machine I can test this on, so relying on you guys!

This first code uses SwapInterval = 30 and has a 2 second lag when I move the mouse :

Monkey

#Import "<std>" #Import "<mojo>" Using std.. Using mojo.. Function Main() New AppInstance New MyWindow App.Run() End Class MyWindow Extends Window Public Method New() ClearColor = Color.Black SwapInterval = 30 'Local timer := New Timer( 2, RequestRender ) End Method OnRender( canvas:Canvas ) Override canvas.Color = Color.White canvas.DrawLine(Mouse.X - 5, Mouse.Y - 5, Mouse.X + 5, Mouse.Y + 5) canvas.DrawLine(Mouse.X - 5, Mouse.Y + 5, Mouse.X + 5, Mouse.Y - 5) canvas.DrawText("FPS:" + App.FPS, 100, 100) RequestRender() End Method End Class

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

#Import "<std>" #Import "<mojo>"   Using std.. Using mojo.. Function Main() New AppInstance New MyWindow App.Run() End Class MyWindow Extends Window   Public Method New() ClearColor = Color.Black SwapInterval = 30 'Local timer := New Timer( 2, RequestRender ) End Method OnRender( canvas:Canvas ) Override canvas.Color = Color.White canvas.DrawLine(Mouse.X - 5, Mouse.Y - 5, Mouse.X + 5, Mouse.Y + 5) canvas.DrawLine(Mouse.X - 5, Mouse.Y + 5, Mouse.X + 5, Mouse.Y - 5) canvas.DrawText("FPS:" + App.FPS, 100, 100) RequestRender() End Method End Class

This next code uses a Timer() function and shows no unexpected lag :

Monkey

#Import "<std>" #Import "<mojo>" Using std.. Using mojo.. Function Main() New AppInstance New MyWindow App.Run() End Class MyWindow Extends Window Public Method New() ClearColor = Color.Black 'SwapInterval = 30 Local timer := New Timer( 2, RequestRender ) End Method OnRender( canvas:Canvas ) Override canvas.Color = Color.White canvas.DrawLine(Mouse.X - 5, Mouse.Y - 5, Mouse.X + 5, Mouse.Y + 5) canvas.DrawLine(Mouse.X - 5, Mouse.Y + 5, Mouse.X + 5, Mouse.Y - 5) canvas.DrawText("FPS:" + App.FPS, 100, 100) 'RequestRender() End Method End Class

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

#Import "<std>" #Import "<mojo>"   Using std.. Using mojo.. Function Main() New AppInstance New MyWindow App.Run() End Class MyWindow Extends Window   Public Method New() ClearColor = Color.Black 'SwapInterval = 30 Local timer := New Timer( 2, RequestRender ) End Method OnRender( canvas:Canvas ) Override canvas.Color = Color.White canvas.DrawLine(Mouse.X - 5, Mouse.Y - 5, Mouse.X + 5, Mouse.Y + 5) canvas.DrawLine(Mouse.X - 5, Mouse.Y + 5, Mouse.X + 5, Mouse.Y - 5) canvas.DrawText("FPS:" + App.FPS, 100, 100) 'RequestRender() End Method End Class

[arpieParticipant]

Thank you all for the explanations.  SwapInterval=0 does remove the lag completely… and reports a framerate of 2400 FPS here.  I had no idea that was even possible!

However, I played with @peterigz suggestion of ‘using some kind of timing code’ and found a curious thing.  The following code still has a slight lag but it is much less noticeable and runs much more smoothly.  Can anybody else confirm the same result?  Can anybody explain why?  The only difference is that RequestRender() is being called from a Timer(), rather than in OnRender().  As far as I understand, that means it is still waiting for a vsync.

Monkey

#Import "<std>" #Import "<mojo>" Using std.. Using mojo.. Function Main() New AppInstance New MyWindow App.Run() End Class MyWindow Extends Window Public Method New() ClearColor = Color.Black Local timer := New Timer( 60, RequestRender ) End Method OnRender( canvas:Canvas ) Override canvas.Color = Color.White canvas.DrawLine(Mouse.X - 5, Mouse.Y - 5, Mouse.X + 5, Mouse.Y + 5) canvas.DrawLine(Mouse.X - 5, Mouse.Y + 5, Mouse.X + 5, Mouse.Y - 5) canvas.DrawText("FPS:" + App.FPS, 100, 100) End Method End Class

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

#Import "<std>" #Import "<mojo>"   Using std.. Using mojo.. Function Main() New AppInstance New MyWindow App.Run() End Class MyWindow Extends Window   Public Method New() ClearColor = Color.Black Local timer := New Timer( 60, RequestRender ) End Method OnRender( canvas:Canvas ) Override canvas.Color = Color.White canvas.DrawLine(Mouse.X - 5, Mouse.Y - 5, Mouse.X + 5, Mouse.Y + 5) canvas.DrawLine(Mouse.X - 5, Mouse.Y + 5, Mouse.X + 5, Mouse.Y - 5) canvas.DrawText("FPS:" + App.FPS, 100, 100) End Method End Class

[arpieParticipant]

Woohoo!  Low level is good…  it means more flexibility.  Working perfectly here on Linux.

[arpieParticipant]

@adamstrange : Mark may have been a little harsh but I think he was also realistic. If @mikehart isn’t happy using mx2 then there is no point anybody getting stressed about it.  Taking a break until mx2 is more mature seems to me like a sensible move.  It would be useful to know why he was having so much trouble, though.

@Mark Sibly : Code may not fall perfectly formed from your fingertips but from what I’ve seen it’s not far off!  Don’t be so harsh on yourself!

[arpieParticipant]

@mikehart, yes, you sounded frustrated! There is not much worse than useless error messages for getting programmers riled. Like I said above, if any improvements could be made to the error report or the parser, please do make suggestions.

If the parser reports a missing End, there probably is an End missing somewhere… but not where it thinks it is. Usually much higher up in the code. This is the reason I always use End Class or End Method etc.

Did you figure out the performance issues with Ted? I built mine in exactly the same way as you. All runs smoothly here.

[arpieParticipant]

Okay, I just noticed that Mark himself often calls it mx2 in his blog.  He seems to use mx2 and monkey2 interchangeably.  So I guess that means we can do the same.  I’m going to crawl back under my rock and keep quiet now.

[arpieParticipant]

You are, presumeably aware that Monkey 2 is a language undergoing heavy, fast development?

If you want stable, try MonkeyX.

To quote the Readme file that you downloaded from git :

W A R N I N G ! The master branch is super-volatile, and the develop branch is event worse! Grabbing the most recently tagged version is recommended if you just want to give monkey2 a try.

If you get an error message that makes no sense, try reporting it in detail on the forums… so that the error reporting can perhaps be improved.
I’m using v 1.1.02 here with no performance problems at all.  Are you sure you built it correctly?  How did you build Monkey 2?  How did you build Ted2Go?  Did you use the scripts provided in the scripts folder?  Can you give any more details if you are indeed asking for help?

[arpieParticipant]

I presume you have all seen this thread : http://monkey2.monkey-x.com/forums/topic/its-called-monkey-2/

While I agree with a lot of the sentiment surrounding the name Monkey, we also need to bear in mind that one of the most important things about branding is consistency.  Mark has stated in the past (as far as I remember, sorry, can’t provide a link) that the name is sticking as it is.  Why don’t we respect that decision and offer him our unanimous support, instead of repeatedly trying to persuade him to change it?

Then again, if we are looking for alternatives, I’d vote for ‘Prime 8’ (pun intended).

[arpieParticipant]

Come on guys, @mikehart made a very valid point and you seem to have missed it.  Look at the top of the screen, next to the logo.  It doesn’t say ‘Monkey X2’ or ‘MX2’ or any other mixture of whatever name you think it ought to be.

It says ‘Monkey 2’.  In the online documentation it says ‘Monkey 2’.  In the URL it is ‘monkey2’.  The author of the software has called it Monkey 2.  That is its name.  Like it or not, that is what you should call it.  Branding is important, and consistency is important to strenghten a brand.  If you want to see your favourite languate succeed long term, give it some respect.

Python is a ssssilly name.  Lisp always makes me chuckle.  ‘D’ got a lot of slack for being ungooglable but it is still a fantastic language.  If I created a language, I wouldn’t choose to give it a pink logo and name it after an animal.  But that doesn’t mean I should poke fun at anybody else that does.  I love coding in Monkey and will do anything I can to support Mark in pushing Monkey 2 (and 3 and 4) to its limits and beyond.

[arpieParticipant]

This is because TwoPi is a Double.

On line 71, if rot < 0, rot is set to TwoPi (implicit cast from Double to Float) but on line 72 you then compare a Float with a Double.  It looks like they are being implicitly cast to Doubles before being compared and so rot is rounded to be slightly larger than TwoPi… and gets set back to zero.

Try changing line 72 to :

If i.rot > Cast<Float>(TwoPi) Then i.rot=0

Or define your own variable TwoPiF (or whatever) as a Float if you don’t like using an explicit cast.

[arpieParticipant]

After some googling, I would suggest that the only format worth supporting is VP8 (or VP9?), aka WebM.  It is effectively a successor to Theora and is pretty-much guaranteed patent free.  Its only drawback seems to be slower encoding speed than Theora – for games, I don’t see this being a big deal?  VP8 and VP9 both appear to be supported by the same library in ffmpeg (libvpx).  I’ll stop making suggestions now, in case anybody else has any thoughts on this that may contradict mine

http://en.swpat.org/wiki/VP8_and_WebM

http://www.webmproject.org/about/

http://git.videolan.org/?p=ffmpeg.git&a=search&h=HEAD&st=commit&s=libvpx

[Author]

Posts