Ashley's Forum Posts

  • No, reflecting isn't supported yet. Also, if you use a blank texture in the Light object, the shadows still draw - and you can use a cone-shaped Sprite for a cone shaped light.

  • Use tiled backgrounds with a power-of-two square texture wherever possible, which sounds like it'll work well, since you're using 64x64 tiles (which is a power-of-two). Graphics cards can draw tiled power-of-two images in one go, which is really fast, whereas if the texture is not power-of-two, the tiled background draws it the same way it would a series of sprites lined up.

    Avoid large canvases. As Deadeye said, they will always create a texture the size of the object, which uses a lot of VRAM. As a rule of thumb, don't create a canvas bigger than the application window.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I thought you might be able to do this by adding something like, car.x > layout width, then set car.x to 0

    You should use unbounded scrolling, but you should still have some kind of wrapping system like this: the further you get away from the 0,0 origin, the less accurate the floating point values that hold the coordinates become. Still, you can be fairly generous and have say 10-50k pixels before you wrap. You'll need it to be a multiple of the width of any tiled background images you use for it to be seamless.

    Setting the X to 0 is going to stutter, because it makes no provision for how much further beyond the layout width you've gone (it still goes to X=0 even if you've gone 1 or 100 pixels over the edge). To fix this, subtract the layout width from the X co-ordinate instead, eg. Car.X > LayoutWidth, set Car X to .X - LayoutWidth.

  • I thought I fixed this. Can you upload a .cap demonstrating the problem?

  • As mentioned in the other thread, there's no good efficient way that I know of for drawing bezier curves with high performance in DirectX. The current best way to deal with different collision masks is to use separate invisible sprites for the colliding.

  • They're conditions in the System object.

  • You might be able to find newer drivers here:

    http://downloadcenter.intel.com/Product ... 2&lang=eng

    That's for the chipset you're using, but the last update was in 2006. Still, that's better than five years old.

  • Hmm, it sounds like you're running out of VRAM, but 64mb graphics memory should be fine to run Construct. Can you not find any newer drivers? Intel generally do really crap drivers for their graphics controllers, and updating them can often fix problems. If your drivers are really five years old, that's not going to end well in DirectX 9 apps.

  • It is perfectly possible to do what you want to do - your .cap just has a rounding error. The 'start loop' action takes an integer for the number of times to run the loop, and your loop advances the box 1 pixel every loop.

    If the purple box is moving 1.4 pixels a tick, your loop will round that down to running only once (you can't have 0.4 of a loop!). So one box is moving at 1.4 pixels/sec, and the other at 1 pixel/sec. Obviously these speeds are different.

    You can do per-pixel collision tests with loops and timedelta'd movements, you just need to be careful not to cause rounding errors. The simplest way would be to calculate the final position - as a float, using .X + speed * timedelta - loop every pixel one at a time towards that position - and when the loop is done, set the position to the final, floating point saved coordinate.

  • TotalObjects? Use it in a Compare Values condition to test what the number is.

  • Seems to work OK here for me... I can double click the event sheets in the project bar and view them just fine.

  • How do you mean? Isn't that what conditions do anyway? In what situation would it be useful?

  • ActiveX doesn't work on Firefox, Opera or Chrome. IE only.

  • I don't think its anything unusual. It's just that the floor acceleration is much lower than the deceleration.

    When you let go of all the controls, you decelerate to a stop (at the floor deceleration rate).

    When you press the opposite direction, you accelerate in the opposite direction (at the floor acceleration rate).

    So yes, if you set the acceleration much lower than the deceleration, you'll get this slightly weird behavior. It doesn't seem to be a problem with the whole movement - just this specific combination of settings. Perhaps it would be more realistic, if you are changing direction, to add the deceleration and acceleration rates together. Then when you start accelerating in the direction of the arrow key you are pressing, it carries on at just the acceleration rate.

  • Ah, you need to make the layout at least as big as the window. Make the layout 640x480 and it works fine. When you make the layout smaller than the window the runtime tries to do "put a border around the layout because it's smaller" but this doesn't factor in zooming... hmmm... basically, it's broken if the layout is smaller than the window. :-\</p>