Ashley's Forum Posts

  • In Application Properties, you can change the default controls.

  • I guess that you accidentally put the tiled background on a layer above the layer the bullets were created on. This would mean the tiled background is covering up the bullets!

    Remember when you insert an object, it is inserted to the currently selected layer on the layer bar. You can accidentally put things on the wrong layer if you're not aware of that.

  • Maybe you could upload the .cap file somewhere so we can take a look? If the objects really are being created and the Z order is the problem, you could try creating the bullets on a layer on top. Use the Layer Bar to add a new layer, and you can spawn the bullets on this layer. If they still don't show up when the layer is on top, it must be something else (they're not created, they're positioned wrong, they're set to invisible, the opacity is 0, etc). However, the tutorial should set everything up correctly for you

  • Hmm, maybe you shouldn't use the timeline object for this. How about 'Every X milliseconds' in the system object? Or, 'Compare time' in the system object if you want to trigger an action at a certain time. Alternatively, the Function Object has an action - 'Call function after delay' - which allows you to, for example, re-enable firing after a few seconds.

  • Another thing that would ROCK which I know has been mentioned is toggling a physics object's collisions, being able to turn them on and off and choosing which objects could collide with which at runtime would pretty much complete the physics object for me

    This is also added now: you can use a 'Disable collisions' action with Physics in the next build, eg. Disable collisions with 'Debris' sprite and it wont collide with it.

  • Well, it's an efficiency thing. When a layer has no effects or anything, it just draws directly to the screen, because it's just another bunch of objects. 'Force own texture' makes it draw to a separate, offscreen surface, and once the layer is drawn there, the whole surface is pasted on top of the screen. This is slightly slower since it has to copy the surface to the screen, but most video cards can do this sort of thing a few thousand times a second without breaking in to a sweat.

    When the layer is drawing directly to the screen, erase doesn't work because you can't cut a hole in the screen - there's nothing underneath. When the layer is drawing to its own surface, it's cutting out an area of transparency in the surface, so when it's pasted to the screen, there's a hole in the layer and whatever was beneath shows through.

    If you change the layer opacity, filter, or add layer effects, it has to draw the layer to its own surface to process the effects anyway. So you only need 'Force own texture' if you want to process an erase or mask effect, and the layer has no effects.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Edit: Oh, I noticed just that when layer is rotated, even MouseX("layer") doesn't show the real cordinates. I guess than it's not yet implemented?

    It should work. What's wrong with it?

  • I gather from this thread some video cards are fibbing about whether or not they support motion blur. It might be it really doesn't, but the marketing team got there first.

  • [quote:2pi7jdls]Perhaps a parameter like mouseX(layernumber)

    That's already implemented! You can also use MouseX("Layer name")...

  • This is fixed in the next build - it works the same both ways now! (It stays on top of the red object)

  • I have actually investigated this - created objects don't become fully "real" until the next event tick - with the exceptions of loops like Repeat, which make sure created objects are up-to-date. It's a bit of a weird way to handle things, so I'll try making it more sensible for the next build.

  • I've added collision detection for the next build - physics collisions also trigger 'On collision'. I'll see about the other features.

  • Debugger's fixed for the next build ... that was one of those weird heisenbugs, where judging from the sourcecode it should never have worked in the first place... no idea why it blows up now...

  • The depth should be 1 for Z for a 2D array - 0 elements would mean the array has 0 elements in total (x size * y size * z size = 0 if any dimension is 0).

  • As it stands, the array is 0-based, so a 10x10 array would have elements 0-9. I think this should be changed to be 1-based. Do you agree?