Ashley's Forum Posts

  • Trakan - please don't submit full games in bug reports - see the bug report guidelines. This report is already closed so best start a new thread.

  • Thanks, fixed for next build.

  • Great, good to see Construct 2 being used for education! Was there any feedback about Construct 2? I'd be curious to hear about it if any.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Oops, well spotted. Fixed the display text for the next beta.

  • ErekT - your code modifications make no sense, referring to property names that don't exist. It looks like it will have identical effect to set 'Sampling' to 'Point' in project properties, which sets linearSampling to false and turns it off, as opposed to accessing the non-existent pointSampling property which returns undefined which is probably also interpreted as false.

    I still have no idea what people are talking about when they say things are jittery, and still nobody has provided a .capx to demonstrate. Everything has always worked perfectly from C2's side as far as I've ever seen. My best theory is that everything is working correctly and the perceived "jitter' is simply the difference between point and linear sampling. Linear sampling can look very smooth and elegant, especially when scrolling slowly, because it can render smoothly along sub-pixel positions. When you switch to point sampling, what you are telling Construct 2 to do is to turn off that lovely smooth linear sampling and revert to a nearest-neighbour filter. This can sometimes look comparitively "jumpy", since it will not render any sub-pixel positions - it will pick a side, and go with that. So scrolling slowly goes from a lovely smooth sub-pixel transition to occasional pixel-size jumps. I would agree this does not look so good, but by choosing point sampling you are literally asking for that to happen.

    So in other words this is the normal, expected result in computer graphics. It's more to do with how digital rendering works than Construct 2 itself. That would also explain why Amanita has observed it in other tools.

  • Compiling events to PHP is not going to happen! Insanely complicated and kind of a weird idea.

  • IE11's initial release had buggy support for pixel formats so we turned it off, making it unaffected by this

    I guess most games either have content in the initial image or load images where you can't see the quality difference. It depends on the first image in the sprite.

  • Aphrodite - oh, thanks for the tip. But the .capx hasn't got any events using shift (or any keys other than arrow keys) nor does pressing shift in-game do anything. Maybe the wrong .capx got uploaded.

  • I don't know what you mean by "Use MAJ to run". I can't see any events that might relate to that step. I also can't see anything shaking. It changes quickly if you tap the movement keys quickly, but that appears to be the correct playback of animations as you have it set up.

    I'm not sure precisely when you mean by "shaking a bit at the start". At the start of what? Please remember to be exact and thorough in your bug report descriptions.

  • Thanks, should be fixed in the next build.

    Workaround: just put a bit of color in the initial image of the object you load the image in to. The problem is the exporter works out that since it's just a transparent empty image it can export it in RGB5_A1 format (5 bit colors and 1 bit alpha) to save memory. However when you load an image in it keeps that format, degrading the loaded image to 5-bit color and 1-bit alpha. By adding in some initial color it will export as RGBA8 and keep full precision. Or just wait for the next build which correctly applies RGBA8 when loading a new image.

  • Closing, this is not a bug, it's just IE does not support invoking downloads. For the feature to work the browser needs to support the anchor 'download' attribute. Check browser support here. We have a fallback that tries to open a data URL in a new window in order to achieve the same effect, but IE doesn't support that either.

    BTW please always follow the bug report guidelines; you have 97 events, the vast majority of which are unrelated to the actual problem. If the issue wasn't obvious like it was here, I'd have simply closed it without investigation and asked for a minimal example as per the guidelines in order to prove it's not caused by your own events.

  • Can't reproduce, works fine here. If this really was a C2 bug I'm sure we'd be inundated with reports since it involves such a common feature, but this is the only report we have so far. Graphics drivers are such a disaster (see our blog archives) that it would not surprise me at all if both systems you tried had buggy drivers. Given that I assume it's working correctly for the vast majority of our users, I would say our code is correct. Not sure what we can do about this, we could work for days and not find a workaround.

  • Looks like a bug in IE's shader compiler. Found a workaround, should be fixed for the next build.

  • Closing as not a bug. Of course it changes, Layout 2 only has one layer, so the object must be placed on that layer. If you had two layers, it would place it on the layer with the same index.

  • Check your graphics drivers are up to date. Node-webkit disables the GPU blacklist on Windows. You can see what Chrome's blacklist status is by visiting chrome://gpu in your browser.