Ruskul's Forum Posts

  • rexrainbow - Thanks for your help!

    I can't seem to be able to get a plugin call to work, though: It always returns NaN...

    //Runtime

    Acts.prototype.SetX = function (tilemap, zX)

    {

    cr.plugins_.Tilemap.prototype.Exps.PositionToTileX.call(tilemap , fake_ret , zX);

    this.testing = fake_ret.value;

    };

    //edittime

    AddObjectParam("TileMap", "Set the tilemap");

    AddNumberParam("X", "X");

    AddAction(6, af_none, "Get tilemap x ", "", "gets test x", "No Description", "SetX");

  • Ashley - Layer offsets, Any chance of this happening?

  • Another solution to this problem can be to only add velocity to position whole integers. For example:

    vector2 velocity;

    vector2 preIntegrated;

    vector2 position;

    every tick

    --- preIntegrated+=velocity

    ---

    --- If ( abs( velocity.x ) > abs( velocity.y ) ) {

    --- --- if ( preIntegrated.x >= 1 ) {

    --- --- --- position.x += floor( preIntegrated.x );

    --- --- --- preIntegrated.x -= floor( preIntegrated.x );

    --- --- --- // Integrate Y

    etc

    There are some bugs here but the idea is simple (negative compared to positive would have to be handled)

  • When pixel rounding is on, the objects are drawn at the nearest pixel positions. ie -> 0.4 is drawn at 0 and 0.5 is drawn at 1.

    Consider the following : Y = -0.5x

    An object slowly moving to the right will also move upwards at half the rate it is moving to the right. However, because of the pixel rounding, the object appears to...

    move right,

    wait,

    move right,

    move up,

    move right,

    wait

    move right,

    move up,

    etc...

    This cause a noticeable hitching, as the object does not move up at the same time as right.

    If, rather than rounding the objects position, floor can be used to eradicate this hitch. The movement appears as follows

    Move right,

    wait,

    move right and up in the same tick

    wait,

    This is much more visually appealing, and is preferable to the visual syncopation resulting from rounding positions.

    You can can get around this by subtracting 0.5 from the positions of all drawn objects at the end of all events and then adding it back to them at the beginning. However, of course this doesn't work with other behaviors that move objects.

    The solution is to be able to specify whether you want an object rounded to the nearest pixel, or to be rounded down when using pixel rounding. This should not be hard to add.

    There is also a historical precedence for this option, studying mario 3 and super mario world shows that an object never moves along one axis independent of the other unless that axis is is being changed at a greater rate than the other. If velocity x = 10 and velocity y = 5, visually y will never move without also moving x.

    This effect is even more pronounced when a camera is also involved moving at dynamic rates set via x=target.x * 0.5 etc. Equations such as these result in visual transitions that create an jittering effect despite the fact that the game is running smoothly.

    Anyway, any one up for discussing this? I think it is a needed feature.

  • Tokinsom - I must be missing something, how do you copy the tile then? I didn't see a relevant portion in the manual, but then I only glanced quickly at it. I wish just a little more work would go into the tilemap. In all honesty, I know how hard it can be as a single developer, but I feel designing levels in construct 2 should be as smooth and seamless as possible. Saying that construct 2 tilemap is to tiled as the construct 2 image editor is to photshop is a bad comparison. It's easy to switch between photoshop and construct. It's not so easy to always be switching from tiled to construct.

    BTW, I have had some relative success editing other vanilla plugins to make them more robust (physics for one thing). Many changes can be simple to implement and won't break existing projects. Usually, I end up reading through them so I can argue with Ashley in a more informed manner about what needs to be done (I'm sure that's not annoying in the least). But anyway, if it becomes a productivity issue (as I think the no copy blocks or move existing tiles around will be) I may see If I can add the feature myself.

  • Tokinsom -

    "4) Will we be able to "copy" tiles that have already been placed (like right-clicking a tile in Tiled)? This is very useful for laying down certain patterns to place elsewhere, and keeps you from having to go all the way to the tileset to pick a tile."

    "5) Will there be hotkeys for the tools? (At the very least right-click to erase tiles?) "

    Ashley - "4-5) The current tilemap editor is very much a first iteration. We'll be improving it over time."

    I think that this is still a good question? Has there been any updates on this front? I was messing around with the tilemap plugin and it seems like 4 still haven't been addressed. #4 isn't just a handy feature- I would call it necessary. Making maps in tiled kills workflow when a game "needs" levels that work with game mechanics. ...and lets face it... a copy tool within the plugin should be easy to make....

    In the end, it's little features like this that make all the difference.

  • QuaziGNRLnose

    That's good to know, It's crazy how smart compilers are at this point. My problem is, is that I am never sure if I am slowing things down or doing good. I have been setting a system that sorts the objects and tries to ensure I can compute sin(a) and then use it on all objects with the same angle calculation. after those are taken care of I then calculate the rest. I try to save as much cpu time as possible due to a heavy physics system.

  • Hey,

    Does anyone know if sin and cos have look up tables in c2 to speed it up or is it calculated every time it is called?

    Thanks

  • R0J0hound ... I imagined you would be first to answer. The first one works so long as you use degrees and not radians. The whole data oriented approach sounds good though. I will build some testers for this and find out. I had always heard sqrt() was slow but I figured it might be faster than multiple calls to sin or cos.

    sqiddster - I never cared much until I wanted to create a small library and wanted to make sure I do things the most efficient way. If I can... Just so it doesn't bite me somewhere down the road.

  • Okay,

    These are my givens:

    v = (x,y)

    v2 = ?

    a = The angle between v and v2

    I want to solve for the projection (P) of v onto v2.

    I have two ways I can do this (that I know of).

    a.)

    P.X = (v.X * cos(a)) + (v.Y * sin (a))

    P.Y = (v.X * cos(a+pi/2)) + (v.Y * sin(a+pi/2))

    b.)

    v2.magnitude = sqrt ( v2.X^2 + v2.Y ^2 )

    v2.unitVector = v2 / v2.magnitude

    DotProduct = v.X * v2.X + v.Y * v2.Y

    P = DotProduct * v2.unitVector

    Which is better? More efficient, etc...

  • Colludium - did you get it working?

  • Colludium - Here is the code that can be inserted into the vanilla behaviors. If you don't understand anything let me know.

    To start with, locate the behavior file "Physics". You should make a copy of this folder someplace safe so if you mess anything up you can restore it without reinstalling construct.

    You can use this code to modify either ams.js physics or box2dweb physics. Either way, you need to open up both the edittime.js file and the runtime file (or both runtime files if you want the changes available in both physics engines).

    You need to add this line of code to the actions are in the edit time file. This creates an action that can be used in the construct 2 editor:

    AddAction(28, af_none, "Set body to Kinematic", "Object Settings", "Set {my} Kinematic", "Set this object to be a Kinematic body.", "SetKinematic");

    This goes in at around line 195. Do you see the first parameter in the AddAction call. Currently it is set to 28. This number has to be unique. If Ashley updates physics and you have this attached to the vanilla behavior and have to re add it, you may have to change that number (you can tell by looking at the last AddAction call and see what number it is using. In my case, this number was 27.

    After that, add the following to the runtime:

    Acts.prototype.SetKinematic = function (k)

    {

    if (!this.enabled)

    return;

    this.body.SetType(1);

    this.body.SetAwake(true);

    };

    I added to where all the other Actions are (denoted by "Acts.prototype...."). You can find it easier by typing "cntr + f" to find it. The physics behavior is 13,000 lines of code, so reading through it to find where to put it can take a while. (it is at the very bottom though, right above exps.prototype.... for the expressions.

    and that's it!

    If you want to create your own behavior instead of modifying the existing one, you should copy the whole physics folder, rename the folder what you want the new behavior to be called and then change the top lines in the edittime file to reflect the new name. Replace the name with your new name (as you want it to appear in construct) and then replace the ID. I know it says never change it, but as you are making a new behavior, you need to change it to be something unique, else construct will think the vanilla physics and this new one are the same thing and then you will have problems

    Let me know if it all works out!

    stupid simple... Its like 5 lines of code. I never understood why this wasn't included in the behavior >.>

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • troublesum - I new it was bad for those reasons, but making an ai in a behavior that uses physics sort of needs that dependency.

  • Aphrodite - To all points, I agree fully. Especially the first. ..."write behaviors in events, or more logically to add event sheets to objects themselves" Both are desperately needed. This is one of the reasons I find unity so much more useful when making larger games. In unity, you add a script (ie behavior) directly to an object. Everything you want that object to do is contained in the script(s) you put on it. ..

    but implementing this might be quite hard. I haven't really thought about how inter object references and dependencies would work. In Unity, you have to have a pointer to another object or script to be able to access it, which doesn't seem easy or uncomplicated for most people not having coded.

    As for behaviors... I really don't use any of the canned behaviors straight out of the box. First of all, it's hard to have that unique all your own feel when using another persons implementation. To get the most out of any behavior, you have to understand the behavior in and out. at that point, you don't really need the behavior and can write your own (depending on the time). I much prefer to role my own platformer code every time I make a new platformer prototype... But I am also a perfectionist and knowing specifically what is happening in a behavior is important to me... And ya, that 8 direction code is no good when interacting with solids.

  • troublesum - though, honestly, as construct doesn't have a large team building the software... I think the likelihood of this happening is already quite low. I did look at how the events run though in the runtime, and its interesting. It simply loops through a list of events making the aces calls. I figured scripting that loop explicitly shouldn't be too big of a deal.