R0J0hound's Forum Posts

  • So I did, I guess I'm not paying attention. :)

    I'll have to look again. It actually varies, here are the stats:

    webglstats.com

  • The resolution is the size of the texture the plugin uses and by default it uses the initial size of the instances. So ya, it VRAM usage is the same as an equivalently sized image. The only limit other than memory is the max texture size which on my PC is 4096x4096.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • sqiddster

    The issue should be fixed now, re-download from first post.

    —

    It's pasting fine here. Tested with r148 and Firefox 24.0. I also tested with chrome but not the latest.

  • Ah, I hadn't looked into the case where the resolution is larger than the size. I'll be looking into it.

  • sqiddster

    This is by design, the set resolution action deletes it's current texture and creates another of the new size, so anything that's drawn to the object is lost. Resolution is basically the internal texture size of the object, and it defaults to the initial size of the object. It is completely independent of the object's size and any drawing done to it is mapped accordingly with no extra events to position it right.

    In the case of your example just set the resolution once. If you set it to 1024x1024 it will look crisp if the window size is anything from 512x512 to 1024x1024. On a side note the largest supported texture size for webgl is 2048x2048.

  • Modulo with integers will always be exact. Hence 4160%64 = 0. Modulo with decimals will be as accurate as the computer can represent it. (tivia: 6.4 cannot be exactly represented with floating point numbers)

    416/6.4 is not acctually 6.4 it's 5.399999999999977, but Construct does some rounding so numbers look prettier. For example if you set some text to 416/6.4 you'll get 6.4 and if you set the text to str(416/6.4) you'll get 5.399999999999977.

    Back to the issue, it's bad practice to check to see if a floating point value is equal to an exact value.

    So instead of this:

    number=value

    The usual method is to do something like this:

    abs(number-value)<epsilon

    Where epsilon is a small number such as 0.00000001. The idea is you don't check if it's exact but rather it's close enough.

    When using modulo for example a%b the result will be in the range of 0 to b so to check if the result is close enough to 0 or b you can do an expression like:

    abs(a%b - b/2)>b/2-epsilon

    Of course I don't think such a formula is needed, but I'm too lazy at the moment to watch the tutorial video to see exactly what they do.

    You could re-write your formula for time. I assume speed is in pixels/tick and you're events are something like this:

    <img src="https://dl.dropboxusercontent.com/u/5426011/examples19/a.gif" border="0" />

    You could rewrite it to be time based so it would run the same speed no mater how many ticks per count, and you'd avoid the cpu math precision issue.

    <img src="https://dl.dropboxusercontent.com/u/5426011/examples19/b.gif" border="0" />

    The issue now is the platforms aren't always butted up against each other, sometimes there's a gap. So instead you could check the last platform's distance from the edge of the screen to see when to create another platform.

    <img src="https://dl.dropboxusercontent.com/u/5426011/examples19/c.gif" border="0" />

    No gaps, but with constant 60fps you may run into the need to create more than one platform if the speed exceeds 32*60 or 1920pixels/second. Not sure if the player will die long before that speed. If the issue comes up you could just duplicate the last event for a quick fix.

  • For the undamped version add an action to the top of event 4 to set step to mouse.x/vx/11.

    Or in general:

    (targetx-startx)/vx/loop_length

    For the damped version it is more complicated. The basic objective is taking the equations for x and y positions and solving for the time when x and y are at the mouse.

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

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