[Abe _King_Participant]

Thanks for the help, Mark! Hmm. . . Maybe I’m overthinking this then. Although it would be nice to emulate how ListView works, by being able to listen to clicks from the container rather than each element, it may just be best to ignore this functionality.

This was just considered bad practice in JS when adding a listener for each element rather than use one that kind of figures out which one it’s working with. I’ll probably end up scrapping that idea then and just go with a more natural flow for mojox. Still getting used to it though. . .

[Abe _King_Participant]

(Tl;DR at bottom )
@admin It’s mostly about control over the flow of the application. I didn’t really expect a label to be blocking mouse inputs from me and was thinking, wouldn’t it be better to let that be an optional feature instead of ingrained?

The real world use I’d say would be flexibility. I have a lot more control over my own application if I can decide what elements I add into a container are blocking or not . . .

My particular use-case was trying to imitate a bit of the API from ListView my own way. I wanted it to be able to use any element that extends a view and then, instead of having to specifically know if the (or which) element being added can have a click being listened to, be able to register clicks based on cells rather than what specific element is added in.

I feel like this would reduce the amount of extra code and structuring.

IE:

Monkey

Function Example1() Local tileGrid:=New TGrid tileGrid.onClick( Lambda( cell:Int, view:View ) Print "position: " + cell End ) For Local i:=0 Until 100 tileGrid.add( New Label ) Next End ' The children here are taking over the event! Function Example2() Local tileGrid:=New TGrid ' add elements here For Local i:=0 Until 100 Local label:=New Label Label.clicked=Lambda() Print "position: " + i End tileGrid.add( label ) Next End

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Function Example1() Local tileGrid:=New TGrid tileGrid.onClick( Lambda( cell:Int, view:View ) Print "position: " + cell End ) For Local i:=0 Until 100 tileGrid.add( New Label ) Next End   ' The children here are taking over the event! Function Example2() Local tileGrid:=New TGrid ' add elements here For Local i:=0 Until 100 Local label:=New Label Label.clicked=Lambda() Print "position: " + i End tileGrid.add( label ) Next End

Now for a small detail, you can tell there are already some minor issues in comparison . . . The second example adds a lot of extra memory overhead with all of those closures. The second version also means that if I start doing some re-ordering of my tileGrid the index saved inside of my closure is useless. I can work around that to an extent by making a helper function get the index from the mouse position on a click but it’s an extra cognitive overhead. There is also, of course, the problem that I may want to use the entire view as a whole but having certain items in the view that, undesirably, consume an event will force me to split up an action into two different listeners because the lower level listener stops the primary one . . .

I like to think of GUI composed as a group of pieces which work together instead of having precedence over each other. The problem for me might not be that we need more control over the bubbling, but that we need more composable elements which combine together more seamlessly. For example; A button would be a view which can be clicked and handle some events, you’d give it text and an icon by adding those components as children and further simply listen to that button.

– Sorry now, think I’m just rambling at this point!

TL;DR: We’ll have more control over the flow of the GUI and therefore be able to bend MojoX at a higher level to do more for us without actually creating specific iterations of each component.

TL;DR 2: Instead, maybe create more composable elements that allow us to generate a structure of layouts and ways to handle interactions with the declarative parts separated from the imperative parts.

Edit: And of course, don’t let me forget, thanks for the reply!!

[Abe _King_Participant]

@richard-betson There’s a good chance it could definitely be something with my particular computer, I am not too certain of what it could possibly be though. And of course! I forgot to mention that I was using chrome, but I’ll post a more detailed review of my experiences per browser below real quick. . . I’ll also ask a friend who has the same specs as me if they have any similar problems.

Chrome  64.0.3282.119: I just updated this right now! It seems to be much less stuttery and far smoother. The problem still seems to be a noticeable latency in the jump of the virtual mouse. It also seems to be resources hungry.

Firefox 58: I also just updated this right now. It seems to be about on par with Chrome, I originally tested this first and was taken back at how much smoother it was than my original experience with chrome. Though, it also suffered some high latency, and also had hiccups with some inputs.

Microsoft Edge(old friend): I was surprised at what happened here. It first loaded, and it appeared to have the highest frame right out of the box compared to the other two, but only for about a second, until some weird errors started to occur which I think are due to some unforeseen WebASM errors.

Notes: There does seem to be an excessive toll on the system overall because when this game is running in the browser the actual entire PC starts to lag. Also, even though the frames seem to be smooth, they are lower than ideal. There are no numbers, but I can tell that when I shrink the Phoenix windows that the framerate goes up to almost 60 because the lighting demo becomes almost completely responsible.

Friends experience: Seems to match up with mine.

– Moved the discussion here to not take over the other thread. If you want to take this to the Monkey2 Discord server I’m there very frequently!

[Abe _King_Participant]

@richard-betson Nice demo! I don’t necessarily have a slow computer, a lot of things work rather smoothly on it actually. I have unfortunate news though, on my computer the demo stutters heavily and the frames have more than a second of latency when watching the virtual mouse follow my own.

I don’t think the problem is your framework, I actually have seen this particular slow-down in my own monkey2 rendering tests. The frame-rate for any particular monkey2 project I’ve used exponentially drops with increasing canvas sizes. . . And I think since you have multiple virtual windows being rendered it might be hitting your demo hard on my computer.

I did notice that once I shrunk your windows all the way down, as to my hypothesis, the frame rate went to 56+.

My computer has
gpu: GTX960m,
mem: 8GB RAM,
cpu: i7-6700HQ 2.60HZ

[Abe _King_Participant]

Could you perhaps include a link to the project for us as well? I’m interested to see if I can help!

Possibly upload the code to gist.github.com…

[Abe _King_Participant]

Unfortunately, this is something missing from the Pyro2 Bananas that is pretty helpful in a lot of cases. All you gotta do is create a sorter class and then set a layer’s Sorter to it!

For Example, the class and the layer setting

Monkey

' This is your sorter, a class which has ' an update method that takes a stack of LayerObjects ' ISorter is a pyro-scenegraph Interface. Class DepthSort Implements ISorter Method Update( objects:Stack<LayerObject> ) ' sort this stack of layerobjects objects.Sort( Lambda(a:LayerObject,b:LayerObject) Return a.Z - b.Z End ) End End ' ...whatever/wherever the layer is layer.Sorter = New DepthSort()

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

' This is your sorter, a class which has ' an update method that takes a stack of LayerObjects ' ISorter is a pyro-scenegraph Interface. Class DepthSort Implements ISorter   Method Update( objects:Stack<LayerObject> ) ' sort this stack of layerobjects objects.Sort( Lambda(a:LayerObject,b:LayerObject) Return a.Z - b.Z End ) End End   ' ...whatever/wherever the layer is layer.Sorter = New DepthSort()

A while back I wondered the same thing and looked to see if there was a way to Sort elements in a Pyro layer – I found a slightly indirect answer finding out that something like this existed in the first Pyro engine and checked and saw that Pyro 2 layers also had sorting functionality!

Disclaimer: I never tested this code lol

[Abe _King_Participant]

Thank you! I would have never figured this out haha. This has helped me a lot to learn more about mojox, so that’s great news. Very much appreciated

[Abe _King_Participant]

I’m a bit late, but Happy New Year! Hope this year is going to be a great one

[Abe _King_Participant]

@xaron As far as I’m aware, that should be completely possible. I’ve actually done it in a different language if you’d like to see! Though, the WebSocket transformations were apart of a standard library in the language. But if you would like to learn more about making a WebSocket server that is the base idea. You can find out more here https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers

I will probably be making a WebSocket transformation API sometime in the future, but it’s not a priority of mine at the time being. I can try taking a look at it sooner than later if you’d like! It wouldn’t be a part of this API though

[Abe _King_Participant]

Update for everyone whos been wanting to try it out! I’m not sure how long it will be until my module is excepted but here is the repository! Feel free to dig/play around! The banana should include everything you need to start out with. Feel free to ask questions here or on the issues of the repo.

Github: https://github.com/forgotten-king/Monkey2-HTML-WebSocket/tree/Dev

[Abe _King_Participant]

Hey, everyone! Hope all is well. I’ve just pushed some much-needed updates to the GitHub repository and are ready to be tested with!

Updates include:

• implemented a single textured mode ( changes all bunnies to use 1 texture )
• now loads images under one atlas image using a generic XML atlas file
• include an atlas project file for the program “texture packer”
• minor code improvements + suggestions (thanks Ethernaut for forked repo)

Improvements have not changed the original structure for the original repository, just cleaned up some code and changed anything that was not benefiting the original test.

Also if you’re interested in creating an Atlas reader from generic XML files, this one was generated by texture packer, this has been added in. It’s relatively straightforward.

Link: https://github.com/forgotten-king/Monkey2-BunnyMark

[Abe _King_Participant]

Merry Christmas to you too, The Revills! And all my Monkey2 programmer friends!

[Abe _King_Participant]

That’s a very useful approach, I like that a lot!! Thanks, Mark!

— edit:
I can’t believe how much of a mess up I’ve been on this post haha. Apparently Map’s don’t have a limitation with being able to reset change values at all. Just another glitch I found in my own program. Well, at least now I know maps are completely fine!

[Abe _King_Participant]

Hey Adam and Abakobo, thanks for the updates. Still very helpful of both of you! Would be nice if we could have a few mains in our own project to practice a few of our own abstractions. And huh, that’s quite unfortunate about the limitation of the map. Those were my intentions to begin with! I would have never assumed that you couldn’t “reassign” using the index operator of the map. That wouldn’t be the case in other languages I believe…

[Abe _King_Participant]

Wow! I’m not sure how I missed your post, must have been writing mine while you did yours. Thanks Abakobo, that helps a ton. I would have never thought that would be possible . . . It would be a nice abstraction in my program to make use of that to hide away some of the setup stuff happening in the background. That covers just about everything then

Much thanks, everyone

[Author]

Posts