Ashley's Forum Posts

  • Yeah, fair enough. True blurs can be done faster by downsampling, blurring the smaller image, then linear filtering the small image up to the original size again, but the rendering engine in the runtime can't support this right now - it'll be included in 2.0 though.

  • Wow, that's beautiful... loving the trees and parallax

  • These are a good idea - but your algorithm is wrong, it's not a true blur. What it's really doing (and it's obvious from the shader code that it does this) is additively blending a set of offset images. This looks like a blur for low radius values, but doesn't work for high blur values. If the sampling points are more than one pixel apart, then a kind of stepped shadow becomes visible.

    <img src="http://www.scirra.com/images/blurs.png">

    This is why I haven't added variable blur radius to the existing blur horizontal and blur vertical: if the blur value goes too high, you get shadowing, and if it goes too low, you're sampling the same pixel more than once, which is inefficient. A true blur has to take in to account every single pixel over a range.

    They're still useful though, and something like Motion Blur would be cool to adapt in a way like Blur Horizontal works

  • You do not have permission to view this post

  • The Tools subdirectory of the install path. (edit: ninja'd)

  • Sounds like a bug, submit a tracker item for it.

  • Huh... weird, that was definitely added to the code, but it didn't seem to get included in the 0.99 release for some reason. Should be in the next build.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It's just a handy helper function to do the math Mipey posted for you, so in the case of moving 50 pixels right or moving 50 pixels at angle 0, they're identical.

  • Persist files don't just save the state of the UI, they save which layouts/event sheets you had open when you last used the .cap. If you turn them off, .caps will only ever load the layout editor for the first layout, which can be annoying.

  • Can we animate mesh object points?

    Yes but only by always setting the mesh points manually by events.

    How do collisions work with Z-ordering? Do they only collide if on the same Z, or do they always collide while on the same layer?

    They collide as if they were at Z=0. There is no 3D collision.

  • It doesn't take long to add an include to the event sheets you need it for, plus you don't need to have the added complications of those events running on unintentional layouts (you don't need your main game code running on the menu!).

  • Then why don't make a function on sprite meshes that "rasterize" the mesh and transform it directly in a sprite? That would be easy and simple.

    There are technical reasons why this is a bad idea, essentially that's a massive hack. It would consume additional VRAM, and involve slow transmissions from GPU to CPU over an already bottlenecked bridge. People would complain that it's slow, and there are further technical issues relating to bounding box complications making it not a simple implementation even for that hack.

  • You can kick and scream all you like, but it's probably not going to happen: firstly, sprites and mesh distortion are made of textured polygons, therefore there is already a way to display textured polygons as you wish. Further, the collisions algorithm would be, as I said, a tricky and time-consuming thing to program. Of course it's possible, but the collisions engine is a highly optimized and low-level MMX based bitmask generator and tester, and would be difficult to adapt. In the same time it would take to do that, we could've done several things useful to 10x as many users. Therefore, it just doesn't make sense to implement it right now.

  • How do you mean?

  • gammabeam: those are both known bugs, the former is fixed in the next build.

    konjak: try it. It should do that