R0J0hound's Recent Forum Activity

  • Since it's an analog control there is no on released. One way around this would be to use a global variable for each control with the values of 0 for up and 1 for down. Every tick set all controls to up or 0 then check the keyboard, gamepad or any other control scheme you use and set the relevant control to 1 or down. Be sure this is at the top of the event sheet. Then you can reference the variables elsewhere in your events to see the control state. This will make your events more readable and it will make it trivial to add more control types.

    global number control_left = 0

    global number control_right = 0

    ...

    Every tick:

    --- set control_left to 0

    --- set control_right to 0

    --- ...

    key left pressed

    or

    gamepad compare x<-90

    --- set control_left to 1

    ...

  • I've never experienced such a thing. The event sheet is always run every frame.

    I suppose we could muse about possible situations, but it would help if you could give an exact situation.

    For me I have found events to be very solid and I've been able to do most anything I want to with as good of reliability as I'm able to design into it.

    As a final note, I've been using c2 since it first came out and if it had any on again off again issues with its core event system I'm sure I would have run into them and I would have most certainly reported them.

  • Yes, it's very consistent. Post examples of what code is on again off again and I'll try to give an explanation.

    Games are usually very dynamic so exact conditions are not often repeated.

    Here's a quick example of some events that may cause an issue given certain conditions.

    Bullet collides with enemy

    --- subtract 1 from enemy health

    --- destroy bullet

    Enemy health<=0

    --- destroy enemy

    --- add 1 to score

    With this one point is added per enemy hit. But depending on how many bullets are flying around you can have more than one enemy that has health less than or equal to zero. In those cases the enemies will be destroyed but you'll only get 1 point per group of dead enemies. This is not what we want instead we want a point per enemy.

    The fix is easy, just add a for each enemy to the second event.

    Enemy health<=0

    For each enemy

    --- destroy enemy

    --- add 1 to score

    Both ways are behaving exactly as written but the second one does what we want.

  • A solution is do a flood fill from the top row of bubbles. Mark the the top bubbles and then mark all the connected bubbles. After that any unmarked bubbles are not connected.

    Here is an example of the concept with squares:

    https://dl.dropboxusercontent.com/u/5426011/examples19/floodfillconnected.capx

    Click to add/remove squares. They will be destroyed if not connected to the center square. This can be adapted any way you like. Just change the function that marks the connected objects.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • It should. All the plugin does is utilize c2's renderer to draw to a texture so it should be as fast as that.

  • Ashley

    Ok, cool, that's good to know. I was unaware of the spec.

  • Everything seems to be working in my tests.

    Can you post or pm me a capx of the issues?

  • They are just triggers for when buttons for specific devices are pressed, and as it says they aren't implemented in cocoonjs. They can be safely ignored and will not affect performance at all.

  • ghost Ashley

    My error was a bit different. It was caused by trying to render to the current texture used for drawing. It may have been a false positive as everything worked fine apart from the assert. I corrected it by using glw.setTexture(null); before setting the render target.

    Oh, and in the case of my plugin the situation was easy to recreate. If the plugin was the last object to be drawn then any actions that draw to a texture would cause the assert.

    For what I can tell "texture 1" is a bit different but I think it may be a false positive as well since the texture will be changed to something different anyway and won't be used for drawing.

  • If you name your layouts like this:

    level 1

    level 2

    level 3

    ...

    You could use the action "Goto layout (by name)" with these two expressions to go next/previous:

    for Next Layout:

    "level "& int(mid(LayoutName, 6, 3))+1

    for Previous Layout:

    "level "& int(mid(LayoutName, 6, 3))-1
  • To add to the report:

    The glitch only occurs if it's resized.

    Steps to reproduce:

    1. In the image editor resize the color picker. At this point it all looks fine with the controls positioned correctly.

    2. Close the color dialog and then re-open it. Stuff is now positioned wrong.

    zendorf

    For now you can use "preferences"->"reset dialogs" put the dialog back to it's original size.

  • Re-download the plugin, I made a fix for r147.

    I did like the color blending in the canvas version, but I used a slightly different approach in the paster version so backgrounds wouldn't be as washed out. It could use improvement though.

R0J0hound's avatar

R0J0hound

Member since 15 Jun, 2009

Twitter
R0J0hound has 157 followers

Connect with R0J0hound