R0J0hound's Forum Posts

  • I can't open your capx because I don't have all those plugins installed, but try to use 320 and 240 instead of WindowWidth and WindowHeight.

  • I'd like to make a correction, it's not a bug at all. Instead of using the WindowWidth and WindowHeight expressions when in Fullscreen(scaled) mode, use the Edit time window size.

  • Eureka,

    I realized it was a different issue. In your capx use the edittime windowwidth and windowheight values for positioning.

    For ex. it would be

    Sprite set x: scrollX - 640/2

    Sprite set y: scrollY - 480/2

    So you would do the math as if the window were not scaled at all.

    Edit:

    Actually it looks like no issue at all. I thought it was because with unbounded scrolling off scrollx and scrolly were returning 479.25 and 240, but it seems to be correct.

  • Danijerry

    Re-download the canvas plugin, that memory leak should now be fixed.

    I also second Ashley's suggestion to leave WebGL off when using the canvas plugin. The webgl portion of it needs to be rewritten so it is more efficient. As it is now it's sort of a hack that uses a 2d canvas as a backend.

  • Animmaniac's solution should have worked. It appears to be a bug that it doesn't work with "fullscreen on(scaled)" as it works with "fullscreen off" and "fullscreen on (crop mode)". To be exact the scrollx and scrolly expressions are returning a position that's in the center of the screen but doesn't seem to have a correlation to the screen size.

    Now for a workaround select "fullscreen on (crop mode)" and set the scale manually. Then use these actions:

    Set layout scale to: min(WindowWidth/640,windowheight/480)

    Sprite set x: scrollX - WindowWidth/(LayoutScale*2)

    Sprite set y: scrollY - WindowHeight/(LayoutScale*2)

  • You can simulate Bounded scrolling with unbounded with this:

    Scroll to X: Clamp(Sprite.X, WindowWidth/2, LayoutWidth-WindowWidth/2)

    Scroll to Y: Clamp(Sprite.Y, WindowHeight/2, LayoutHeight-WindowHeight/2)

  • Just add the ships angle into the equation.

    The usual setup is to have "right" as an angle of 0.

    So the turret angle range would be:

    Ship.Angle+45 to Ship.Angle+135

    Then to reset the angle of the turret like your image set the turret's angle to Ship.Angle+90.

  • Nope, using Delta-Time makes it frame rate independent.

  • ranma

    In your first capx if you hide the locked sprite at the same time as destroying it you won't see it flash. When destroying a sprite it is not destroyed till the beginning of the next frame, so that is probably why you see it flash.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Here are two other ways.

    1. Destroying the EditBox or Button will restore the keyboard focus.

    2. If you want to use python:

    import ctypes
hwnd=ctypes.windll.user32.GetActiveWindow()
ctypes.windll.user32.SetFocus(hwnd)

  • Instead of "every 1 seconds" use a instance variable for a cooldown time between shots.

    Here is an example of multiple turrets and multiple targets:

    http://dl.dropbox.com/u/5426011/examples%209/turret.capx

    In the example the turrets target the closest player within range. I didn't work it out but it could be modified so that only the first object in range will be targeted until it is out of range.

  • The only tricky issue you may be the visual sorting of your objects if you have more than two overlapping.

  • To fix the collisions Add the "solid" behavior to "collisionhouse" and remove event 3.

  • It is crashing because you are using the OR condition, it's buggy. It often causes crashes when used with layout changes. I removed the OR conditions from your cap and it did not crash any more.

    Edit:

    I've looked at the source for the OR condition before and wasn't able to fully understand how it works. Which was mainly because it is spread though out the core event engine code.