Link to .capx file (required!):

dl.dropboxusercontent.com/u/2425456/Games/Mousewheel_zoom_and_scroll.capx

Steps to reproduce:

1. Hover mouse over List box and scroll with mouse wheel.

Observed result:

Items in list box do not scroll.

Expected result:

Items in list box should scroll.

The conflict is caused by the Mouse plugin running preventDefault() (line 174 in runtime.js), even though its event is aborted by the negative hover condition.

Browsers affected:

Chrome: yes

Firefox: yes

Internet Explorer: yes

Operating system & service pack:

Windows 8 Pro 64-bit

Construct 2 version:

r139 (64-bit)

Paradox

No, unfortunately not, it still seems to run preventDefault, even if I condition it on mouse not hovering the list object. That would be another way to solve it I guess, to only make it preventDefault when the event is actually run.

In my game, I let the user zoom in and out on the map by using the mousewheel, which is pretty standard nowadays. I also have some HTML-based list boxes on my HUD using the List object. Normally, the user can scroll in these list boxes using the mousewheel when mouse hovers over it, which is a great usability feature. However, when I enable mousewheel zooming on the map, the scrolling in the list box no longer works.

The problem is that the official Mouse plugin on line 174 runs preventDefault() when it captures a mousewheel event, which overrides any default events, such as scrolling of list boxes.

If I manually edit the plugin and remove this line, it works just as expected, so my feature request is that you either disable preventDefault(), or better yet make it into a setting in the Mouse object. Although I'm not entirely sure of when it could be useful (IE compatibility?), making it into an option would reduce the risk of compatibility issues, if you leave it enabled by default.

Thanks for listening!

ghost

Oh, wow, I didn't know that. Thanks for the info. Not sure if this is good or bad news for Node-Webkit.

R0J0hound

Ah, good point, that would explain a great deal. A bit surprised that Chrome doesn't use WebGL in this particular case, as it seems to use it in other situations, but there might be more to it than I understand.

Thanks a lot for the update!

Thanks for still updating this.

I just noticed another thing relating WebGL performance in Windows.

In native Chrome the performance for me is great, with 250 fps with vsync disabled and 60 fps when enabled. Almost no performance hit when drawing to canvas every tick. In both Node-Webkit and Firefox, however, the frame rate drops to around 30 fps.

I wouldn't be surprised if Firefox did something different, but I wonder why the performance is so much worse in Node-Webkit compared to Chrome, as it supposedly uses the same render engine.

After the latest update, this only happens when clearing/updating the canvas (which I unfortunately do every tick). The performance is better with WebGL off, so it seems related to WebGL.

Any ideas what's causing this? Could it be related to the original WebGL issue?

clrammer

My canvas is 1920x1080. I've only tested on desktop though, and so far I'm only using it to draw basic shapes like lines and circles that I redraw every tick. I'm just using a single canvas object.

Before the update I had 30 fps, but now I'm back at 250, which is the same as without the canvas.

I'm not getting your ReferenceError, although it looks like it might be a bug in instanceProto.onDestroy() as I don't see how glw could be defined. Not sure if this is related to your performance though.

You mean your fps is the same as before the update, with WebGL enabled? And you're sure the fps drop is caused by the canvas? Maybe you could try on desktop to figure out if it's on iOS only?

R0J0hound

Wow, amazing, you did it! Now it runs perfect for me with WebGL enabled. Thanks a lot!!!

I find this plugin really interesting for drawing dynamic paths. However, like others have mentioned, the fps hit is terrible when using WebGL and a large canvas object.

Does anyone know what's causing this?

The plugin code is quite clean and small, but my knowledge of WebGL is too limited to understand what could be causing this slowdown in the drawGL() function.

You might want to check out Rex Hash plugin:

scirra.com/forum/plugin-hash-table_topic47637.html

It allows you to create hierarchical ("multidimensional") dictionaries. This way, you could get a better structure of your stored data, creating objects like this:

world1.title = "Cool World"

world1.enemies.0.name = "Evil bunny"

world1.enemies.0.health = 100

world1.enemies.1.name = "Nasty kitten"

world1.enemies.1.health = 150

world2.title = "Warm World"

...and so on.

All with just one object.

Maybe not the best example, but I think you get the point.

I really hope they include it as an official plugin someday, as arrays and single-leveled dictionaries are way too limited for complex data management, and Javascript already includes more powerful alternatives.

Although Rex plugin is great, it lacks some features like sorting on keys or values, so you might need to complement it with normal arrays. My own plan is to modify the plugin, or create my own, to support sorting once I get there, as I feel that arrays are too limited for most of my needs.

Unless you're updating huge amounts of data at the same time, performance shouldn't be an issue.

Holy crap! Construct 2's plugin system is amazing!

I just spent 10 minutes fiddling with the default particles plugin, added 6 lines of sweet js code, and suddenly the particles follow their emitter.

It should be easy to add it as an option to the GUI so that it can be set for each emitter.

I'm also thinking of adding an event action to manually move all particles on screen, which would likely be a breeze as well.

Ashley, would you consider adding this functionality to the official plugin if I make these modifications? I guess I'll start by making a custom copy of the particles plugin for my project, but then I would have to manually merge it with the official plugin when it gets updated.

You have to set "Force own texture" to "Yes" in the layer containing the special blend mode. I don't know why, but that's what they did in the examples.

Good idea! It worked almost perfect just placing all objects in a family and looping them each tick. Next to no performance loss. Thanks a lot for your help.

System Every tick
    Local number PlayerX = 0
    Local number PlayerY = 0
    Set PlayerX to Player.X
    Set PlayerY to Player.Y
    Player: Set position to (0,0)
    Scroll to Player
    For each Objects
        Objects Set position to (Self.X-PlayerX, Self.Y-PlayerY)