Events and more events..

[PhatPeterParticipant]

How do you use Event.Eat correctly? I would like an app to ignore all events such as kbd, mouse etc.

Also is there way to idle, in earlier products I think you used something like “delay #” but I guess this is very much event based only so, is something like that still needed to truly idle and save maximum power?

Havn’t yet found an example that uses Event.eat, found Ted2Go so I guess the editor is written in Monkey2 itself? that is amazing it’s lot of code though to get to know in a weekend.. Is there an easier way to learn about “Event.Eat” and everything else that might screw up an app and disturb it?

[AdamStrangeParticipant]

erm, in simplest form. don’t use onMouseEvent and OnKeyEvent

Heres an example with no mouse and no keyboard stuff + full explanation:

Monkey

[crayon-5cb9cbf7acf67480313148 inline="true" ]'A Mojo App has a window. Mojo has all the commands and logic to deal with windows 'namespace is what we call the app. 'Other files with the same namespace will behave as if they are a single unified file Namespace myMojoApp 'import std and mojo to provide basic monkey commands and window extensions #Import "<std>" #Import "<mojo>" 'Using allows us to reference commands in std and mojo without std. or mojo. prefixes Using std.. Using mojo.. 'we now need a Main function to call. Every app needs a Main() 'Here you can see we are using an extended Window Class (MyWindow)) Function Main() New AppInstance New MyWindow App.Run() End 'Here we have the class that deals with the window, drawing, etc Class MyWindow Extends Window 'We are Using all the Default stuff in Window, but doing our own drawing, so override OnRender() Method OnRender( canvas:Canvas ) Override canvas.DrawText( "Hello World",Width/2,Height/2,.5,.5 ) 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

[crayon-5cb9cbf7acf67480313148 inline="true" ]'A Mojo App has a window. Mojo has all the commands and logic to deal with windows   'namespace is what we call the app. 'Other files with the same namespace will behave as if they are a single unified file Namespace myMojoApp   'import std and mojo to provide basic monkey commands and window extensions #Import "<std>" #Import "<mojo>"   'Using allows us to reference commands in std and mojo without std. or mojo. prefixes Using std.. Using mojo..   'we now need a Main function to call. Every app needs a Main() 'Here you can see we are using an extended Window Class (MyWindow)) Function Main() New AppInstance New MyWindow App.Run() End   'Here we have the class that deals with the window, drawing, etc Class MyWindow Extends Window   'We are Using all the Default stuff in Window, but doing our own drawing, so override OnRender() Method OnRender( canvas:Canvas ) Override canvas.DrawText( "Hello World",Width/2,Height/2,.5,.5 ) End End

[/crayon]

[PhatPeterParticipant]

Thanks, okay. I never used onMouseEvent and OnKeyEvent so that was kind of a surprise I thought that was whole idea to be able to get rid of the events and to catch them EARLY, and just throw them away.

That example never show any window at all?

[PhatPeterParticipant]

The class of windows needed an empty new() method, now I got a window !

Monkey

' A Mojo App has a window. Mojo has all the commands and logic to deal with windows ' Namespace is what we call the app. ' Other files with the same namespace will behave as if they are a single unified file Namespace myMojoApp ' import std and mojo to provide basic monkey commands and window extensions #Import "<std>" #Import "<mojo>" ' Using allows us to reference commands in std and mojo without std. or mojo. prefixes Using std.. Using mojo.. ' We now need a Main function to call. Every app needs a Main() ' Here you can see we are using an extended Window Class (MyWindow)) Function Main() New AppInstance New MyWindow App.Run() End ' Here we have the class that deals with the window, drawing, etc Class MyWindow Extends Window Method New() End ' We are Using all the Default stuff in Window, but doing our own drawing, so override OnRender() Method OnRender( canvas:Canvas ) Override canvas.DrawText( "Hello World",Width/2,Height/2,.5,.5 ) 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

' A Mojo App has a window. Mojo has all the commands and logic to deal with windows ' Namespace is what we call the app. ' Other files with the same namespace will behave as if they are a single unified file   Namespace myMojoApp ' import std and mojo to provide basic monkey commands and window extensions   #Import "<std>" #Import "<mojo>" ' Using allows us to reference commands in std and mojo without std. or mojo. prefixes   Using std.. Using mojo.. ' We now need a Main function to call. Every app needs a Main() ' Here you can see we are using an extended Window Class (MyWindow))   Function Main() New AppInstance New MyWindow App.Run() End ' Here we have the class that deals with the window, drawing, etc   Class MyWindow Extends Window   Method New() End   ' We are Using all the Default stuff in Window, but doing our own drawing, so override OnRender()   Method OnRender( canvas:Canvas ) Override canvas.DrawText( "Hello World",Width/2,Height/2,.5,.5 ) End End

[PhatPeterParticipant]

No it didn’t work, using the template for some code they all still jitter when you move the mouse over the app or hit the kbd.

I’m confused about how to ignore UI events?

[PhatPeterParticipant]

I can relate this problem as a really REALLY REALLY bad IRQ handler. The IRQ’s actually being OS events in this case and not actual hardware interrupts.

I don’t see any documentation about where this polling of events takes place I think actually it’s polling that’s going on a thread or something similar on because interrupts are not supposed to eat power, of course.

So something similar to threads are actually affecting each other, one of the affected ones are handling the screen buffer.

[AdamStrangeParticipant]

Do you have an example with reproducible affects on macOS. I can try and debug here.
Also what system are you running it on (cpu specs, machine etc)

[PhatPeterParticipant]

Sure. Let’s see I can use the same simple example as I’ve used the last few months as it’s a good one.

I Include it.

I’m mainly trying to use Apple products, currently I’m using:

– A couple of iMac’s 3.06Ghz / 4GB DDR3, and one with 8Gb, both running High Sierra (10.13.2). These are Up-to-date in everything macOS, Xcode, drivers etc. Running Monkey2 non-dev version 1.1.08 on these two.
On this one Monkey1 version of this code is performing no better than Monkey2. Both are equal.

– A stock 8Gb Macbook Air, with 8GB with Sierra (10.12) Here I use Monkey 1.1.07, also non-dev.
On this one Monkey1 code works perfectly. (I don’t include the Monkey1 source here (it’s in another thread If someone really wants to see the difference).

Mouse events especially disturbs everything on both Monkeys and it’s VERY visible.
Even just leaving the screen by itself in Monkey2 creates visible disturbances, but moving the mouse adds a lot more.

* Note : before running the code make sure that you change the resolution to your native one.
I didn’t make it automatic but it really needs to be native and non-stretched to make it into a fair test.

Attachments:

1. Simple-test.zip

[abakoboParticipant]

You code is stressing the computer due to lots of canvas work. Where is the limit? Is any app having jitters? Do you have jitters with this code for example?(I don’t):

Monkey

Namespace myapp #Import "<std>" #Import "<mojo>" Using std.. Using mojo.. Class MyWindow Extends Window Field i:=0 Method New( title:String="Simple mojo app",width:Int=640,height:Int=480,flags:WindowFlags=Null ) Super.New( title,width,height,flags ) Fullscreen=True End Method OnRender( canvas:Canvas ) Override App.RequestRender() For Local k:=0 To 110 For Local j:=0 To 170 canvas.DrawRect(-k*40-90+i+80*j,5+k*40,40,40) Next Next i+=1 If i=80 Then i=0 canvas.Color=Color.Black canvas.DrawText( "Hello World! FPS:"+App.FPS,50+Width/2,50+Height/2,.5,.5 ) 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

Namespace myapp   #Import "<std>" #Import "<mojo>"   Using std.. Using mojo..   Class MyWindow Extends Window Field i:=0   Method New( title:String="Simple mojo app",width:Int=640,height:Int=480,flags:WindowFlags=Null ) Super.New( title,width,height,flags ) Fullscreen=True End   Method OnRender( canvas:Canvas ) Override App.RequestRender() For Local k:=0 To 110 For Local j:=0 To 170 canvas.DrawRect(-k*40-90+i+80*j,5+k*40,40,40) Next Next i+=1 If i=80 Then i=0 canvas.Color=Color.Black canvas.DrawText( "Hello World! FPS:"+App.FPS,50+Width/2,50+Height/2,.5,.5 ) End End   Function Main()   New AppInstance New MyWindow App.Run() End

[PhatPeterParticipant]

Yes I’m partly stressing the computer, you can see that on my comment on that you should stress it reasonable to see this particularly good. But you DON’T STRESS it more you always leave at least ONE full framebuffer of computing power, so without any mouse movement. It won’t be any stutter, this is important . It’s not stutter DUE to enormous stress but to bad code underneath, i’m trying to find out what.

Also important is that not all events seem alike for example the mousewheel and the buttons does not affect anything but moving the actual mouse (and to some extent pressing any keys on the keyboard) does heavily affect performance.

I’ve been struggling for some time now without getting any support on
how to get a simple, smooth and reliabley working base code.

I actually get stutter on your code when I move the mouse on that simple example aswell.
Because of how all this works underneath it might even have micro stuttering when not moving it, but it’s hardly visible at all except that you get the feeling that it’s not perfectly solid all the time even if it’s smooth.

Maybe I havn’t explained myself well enough or you didn’t get the idea of what I want. Maybe you’re just looking for something completely different than me. The idea is this; I want truly smooth graphics instead of the smooth:ish graphics that you seem to settle for. To you it might seem like a stupid idea but believe me; it’s not.

[PhatPeterParticipant]

You need to overdo it to make it visible, and remember it’s not stressing the computer. This happens well before truly stressing it.

[PhatPeterParticipant]

Let me explain like this.
Suppose one can have 20 fullscreen layers of tiles/sprites moving smoothly. It’s a lot of things going on but it’ll work, but never ever touch that mouse or touchscreen.

Now say that want to have enough “power” to be able to move the mouse.

This means you can’t have 20 layers anymore. How many CAN you have? How much do you need to sacrifice?

Can you have 19 layers? No, you need to cut it down to more like 1-5 layers just to be certain (and probably still some twitches will find their way through but it’ll be okay:ish let’s say we settle for that). Most users won’t notice or at least they won’t have the strength to complain.

But it shows how much you need to sacrifice in power, just to have the headroom to “hide” any slowdowns that the mouse and kbd may induce. This is a really good example in that it’s not about stressing the true computer power to its limits. It’s stressed bc of something else.

There’s a lot of power sucking going on here. We needed to down from 20 possible layer (actually maybe we could use 32 layers but that IS stressing the computer so we’re taking it easy with 16-20 layers, and that’s plenty). But we needed to decrease that into 2-5 layers to afford e.g. mouse movement.

So It takes more power to accept events e.g. a simple movement of the mouse, than it takes to draw say 20 fullscreens of tiles/ sprites. It’s not reasonable.

I’ve seen this happen with some Windows systems but with Apple they seem to happen all the time.
The only time you don’t see it is when you have x1000 power than you actually need. I always develop on at least ONE slow machine just because of this fact. It’s good to see what really happens.

[AdamStrangeParticipant]

@phatpeter Your code didn’t run, compiled, bu when run didn’t do anything, no window, etc.
Quick look into the code and there was window code commented out, etc.

nevermind…

[EthernautParticipant]

I get some occasional stutter when using Intel HD graphics card, and super smooth 60fps when using AMD Radeon card. Both on MacOS, 3 year old laptop. (I use this utility to manually switch cards:https://gfx.io).

I get the point of doing a “stress test”, but I think any kind of 2D game can be designed to work really well in Monkey2 in modern hardware. Either way, I don’t think there’s much garbage collection going on in your test, if any. I wonder if something like SDL is doing anything under the hood that could cause the occasional stutter.

[PhatPeterParticipant]

@adamstrange MY code that i included runs without a single problem.

[Author]

Posts