sqiddster's Forum Posts

  • Firstly, what would one recommend as the best window size for a project, if I want it to be able to be used by many, embedded on websites, and be a relatively large size.

    Secondly, I read the blog post on the audio formats. Does this mean that, for the foreseeable future, I have no options for audio that is supported by all browser types? If that is the bleak case, what format would I be best off choosing?

  • It seems the .capx still uses a collision box?

    EDIT: I removed all the code that checks for collision. It runs perfectly and at 59fps when there are many squares to check. So it seems OK.

    Next step. What happens when I have multiple instances of the object which checks as well?

  • I have tried both programs and may I just say that Construct 2 is better than game maker in almost every aspect of game design.

    (I won't qualify for a testimonial because I am not willing to release my name and location at this point).

  • A .capx would be nice... they are always very informative!

  • I think the best way (since so many people would need this) would be for the function to be built into the program and able to be optionally used.

  • No, the range is relatively small.

    However, this UID and looping is part of what is confusing to me about construct. SO what am I to do? A large invisible circle around the object? I am still a bit confused.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Yes, there must be simpler way to pick the closest instance! I caertainly need this and there is quite a lot of instances, too. hmm...

  • When I mention an object in another object's field (e.g. move towards object), if there are multiple instances of the second object, it does not pick the nearest instance but a seemingly random one.

    Why does this happen? Could a feature be implemented to make the nearest instance be chosen (since I am sure that 99% of the time people would want this).

    If this is unavoidable, what can I do to make the object choose the nearest instance?

    thanks, sqiddster

  • There is a setting for parralax on every layer. There is also a behaviour called scroll to. This is probably all you need.

  • I know you guys are very busy implementing the community's most wanted features (and doing a great job!) but what do you think of a feature to modify certain aspects of a sprite including contrast, brightness, and color manipulation without importing more images.

    I'm not sure how hard that would be to implement, but I think it would be an important feature to have eventually.

  • Gee, my last post seems rather critical. Just to be clear, Rojo's method was the main base for my small improvement and I could never have done it without his excellent example. Thanks man!

  • I also saw no performance drop but in a big game every bit counts, especially if you want pixel-perfect accuracy (as in reaches all the way to the wall but does not go in it). In Rojo's example if you want pixel-perfect accuracy you are performing a collision check for every pixel of the distance until the laser reaches a target.

    Well the two different object types were for my own purposes, if this was in Rojo's example it would also consume more events.

    I understand what you are saying and I do not want to turn this into a contest, but by my maths if the object is more than 220 pixels away the first example is performing as many calculations as mine but still displaying a 20 pixel inaccuracy...

    The first method is certainly simpler and good if you do not need accuracy however I believe (I may be wrong) that a couple more events is less consuming than hundreds of collision checks per tick for greater accuracy.

  • R0J0hound... That is a great solution! after seeing your solution, however, I think I have found a better way to do it that involves less performance drop and more accuracy (it does not at all stick into the walls.) I think all this is is a minor improvement on your way of solving it.

    OK, so we have an instance variable for the laser called increment. It starts at 1000 or any value that you want to be the max range.

    We start our loop.

    If the laser does not collide with any walls, set the width to width + increment.

    If the laser does collide with a wall, set the width to width -     increment.

    divide increment by 2.

    Loop breaks when increment is less than or equal to one.

    That is only 11 calculations per step (or 12 if you want a longer range of, say, 2000).

    I think this may actually be the best solution to the problem. I hope this helps people with their laser issues!

    Here is the improved example: dl.dropbox.com/u/41931267/Improved%20example.capx

  • I, too, vote for collision polygons. I think this is by far the most important feature to be added.

  • I think the problem lies in the logic. The laser chooses its length by stretching, however it do not think it is possible to find this X and Y value of the collision.

    You say you need 'the X and Y values of the object you are crossing' however if this object is stretched out significantly and the laser want to hit the edge, you will have a problem.