R0J0hound's Recent Forum Activity

  • 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.

  • 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.

  • Ok, fixed the issue that came up with r147. Re-download from first post.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I haven't updated to r147 yet, so I rolled back the version in your capx and it's working fine here. What was the error message?