Ashley's Forum Posts

  • Yeah, I guess "stable" is a bit of a misnomer, it really means "not as unstable".

  • It's alright, I don't mind answering questions!

  • What's your video hardware? Is your graphics card very old?

  • If I remember correctly, you need to set info.collMode to COLLISIONMODE_FINE to enable per pixel collisions, then info.imgHandle will be used as the collision mask. Don't forget the bounding box has to be correct for that.

  • You do realise that all textures have a collision mask already created by Construct automatically? You only need that function when you're creating a render target and rendering custom shapes on to that, in which case the collision mask will have changed. But I would strongly advise against using render targets to render something as simple as a button.

  • I think that function was custom coded for the Canvas object. What are you trying to do with it? Can you paste some code snippets too?

  • Moved to help & tech support.

  • It's hard to say unless you find something you can turn on/off which affects it. It could be a single action in your events which takes half a second to complete, and therefore briefly halves the framerate because of the way it averages out the framerate over one second. Or, it could be something Windows does in the background and briefly prioritises another process. The best thing to do is either re-make it from scratch - or delete things back to an empty .cap - and watch when the problem changes.

  • Strictly speaking you need to purchase the Prof-UIS interface library to compile the IDE. However, if it's the runtime crashing, you don't need Prof-UIS (nor ProfUIS284ym.lib) to compile the runtime, but you will need the DirectX 9 SDK. Debugging the IDE won't actually help if the runtime is crashing.

    Which module is the crash in? If it's a .csx that should tell you which plugin the crash is caused by. You could also try running the .cap via 'Debug application' in Construct, and see if it can tell you any more about the crash.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Could you post this to the bug tracker? Crashes mean bugs.

  • Wow, unexpected surge of opinion! The thing is, it's not quite so simple as you might think, especially when it comes to circles.

    - you can update the shape in real time, while a static texture remains the same.

    Isn't this what mesh distortion does?

    [quote:3fa4nrb2]- collision checking is easy between geometric primitives, because you can simply solve rather than check for each pixel

    Actually, the opposite is true. Most of Construct's collision engine uses per-pixel collisions, and that makes detecting collisions between geometric primitives and per-pixel sprites extremely difficult. I don't really want to add new features unless they integrate with all other features, especially something as intuitive as collision checking (where if any combination simply didn't work the forums would be full of people asking "why doesn't my 'on collision' event work here?")

    [quote:3fa4nrb2]- I mentioned transparent pixels... well, static textures, when zoomed in, have these all over the place. There would be no such "dirt" with polygons.

    I don't see the point here. I think it is quite simple to ensure you have a clean polygon sprite on a texture.

    [quote:3fa4nrb2]- low memory footprint. A huge circle (to preserve crispiness) can easily take a good chunk off memory, while a primitive circle would take substantially less (if we draw directly to the visible screen, skipping offscreen). Static texture still retains the same space, even if it is not drawn offscreen.

    You might save one texture, yes. But the rendering of a circle is much slower. The way it'd have to be done in Construct is basically create a circle out of straight lines, which means hundreds of vertices arranged in a ring. (As I said before, DirectX can't natively draw circles, only triangles) And four vertices is equivalent to pushing a sprite to the graphics card, so you could end up with a single circle using the rendering power of a hundred sprites.

    You could use a shader, but why require special pixel shader hardware for something as simple as a geometric primitive?

    Given all this, I'm afraid I don't see much case for a series of geometric primitive plugins. A third-party dev could try making some, but it would still suffer the same pitfalls - probably no collisions with ordinary sprites and slow rendering of circles. Really - is there something that bad about using sprites with textures?

  • Can you post the .cap to the bug tracker? Thanks.

  • Is the sprite original size and not rotated? Rotation and scaling on small sprites with point sampling could garble the pixels a bit.

  • This could be added, but I don't see much advantage over using sprites with geometric textures. You still get pixel-perfect collisions, you can pre-render antialiasing on the texture rather than relying on expensive multisampling for improving quality, and for some shapes like circles, textures are actually the only way to do it. Genuinely the best way to render a circle in DirectX is to draw a texture with a circle on it. The other option (a ring of vertices) would be slower, and worse quality (aliased)!

  • What's it supposed to look like?