SirSpunky's Forum Posts

  • I prefer the Default theme's lighter colors over the more grey-blue Windows 7 look. The Default theme to me has a better contrast balance overall, making it easier to distinguish action lists from each other. However, it would be nice to have some other colors on variables/includes as MadFactory said.

    Although I like the green variable definitions, my least favorite part of the Windows 7 theme is the dark grey include boxes. If you change this theme to the default, please consider making them lighter.

    The other two themes have more severe contrast issues and just feel too grey.

    The Default theme with lightly colored variables/includes, and a more light-bluish tint rather than purple would be awesome.

  • You can use the layer's name instead of the number, for exemple : "Game Layer"

    Oh my god. How could I miss that?! Thanks a lot, that makes it so much easier. Then I don't really mind anymore. That was my biggest worry of the two.

    Thanks Ashley and Nathan, I know about those, but I still think making individual instances selectable and removing the filter from the z-order list would make it slightly more intuitive and useful. But definitly not top priority, especially if they're tricky to fix.

    I was more worried about the layer ID:s, but that kind of solved itself :)

  • Layers are a really cool and powerful feature of Construct 2. There are just two small things I miss that would make them even easier to use:

    1) Unique layer IDs

    Currently, layer IDs are more like a sort order, as they're based on the layer order. This makes it tricky to use them to identify layers (for example, when creating new objects through events) because as soon as you add a new layer, the layer IDs change. What I miss is either a constant numeric layer ID that doesn't change based on ordering, or the possibility to add your own custom identifier to a layer. You can use variables to store your layer IDs, but you still have to update them manually everytime you add/delete/reorder layers which is quite cumbersome.

    The easiest solution might be to implement some kind of "lock layer ID" checkbox on layers, so that IDs stop changing based on sort order and instead just auto-increment. Or an editable textbox called "Identifyer" underneath the layer name in the layer settings, that can then be used instead of layer ID in events to identify layers. This should be both back- and forward compatible.

    2) The ability to select objects from the Z order list

    We already have the "Z order" window, which is awesome. However, currently you can only "Flash this instance" and not really select objects using this window. If you could select them just by clicking on them in the list, that would be very useful when you have many small objects on a layer that are hard to find and click on using the normal view.

    I also think the current filter in the Z order window is a bit too smart for me, as it hides objects that are not overlapping an object when it's selected. Although it's an impressive feature, it would be great if you could disable this feature, to always show all objects on the active layer, even if an object is selected. Maybe this could be changed at the same place you choose "Show active layer only" (which I prefer to leave on).

    Sorry if these ideas have been mentioned before, or you already have them in your todo. Love the new beta versions, and your focus on tilemap and multiplayer support. Keep up the great work!

  • Just for your info, the latest Chrome version seems to misalign circles created by "Draw circle". However, it works fine if I export to Node-Webkit, so I believe this is a problem with Chrome and not your plugin. The strange gradient effect I had before is gone though.

    EDIT: The misalign is quite small, but can be seen when drawing very large circles and placing objects along the circle borders.

  • The latest Chrome version broke something for me with "draw circle". Drawing large circles of certain sizes at certain positions makes a strange gradient effect appear next to the circle borders. I'm pretty sure this is a bug in Chrome's canvas drawing and not in your plugin though.

  • Ashley

    Ah, of course. I sometimes forget that Construct 2 is also used to make embedded web games, as I'm working on a full stand-alone game.

    Here's a bug report with a .capx:

    scirra.com/forum/topic76648_post458873.html

  • 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!

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • 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.