R0J0hound's Forum Posts

  • Use three instance variables:

    z =100 for the z position

    vz=-10 for the z speed

    g=10 for the gravity

    Then with events:

    Every tick:

    — sprite: add self.g*dt to vz

    — sprite: add self.vz*dt to z

    — sprite: set scale to 100/max(100,self.z)

    It’s still parabolic but simpler than using the parabolic equation because you’d have to do more on top of it.

    Anyways you’ll have to adjust the variables to get the effect you want.

    If the object gets too big, make vz smaller.

    If it happens too fast or slow, then adjust g. Keep in mind you’ll need to adjust vz after that too.

    The use of max() in the set scale action limits the scale to never be lower than 100.

  • You could turn webgl off in the project properties.

    With it off the text objects are drawn directly to the game.

    With it on the text is drawn to a hidden canvas and that is then copied to a webgl texture, which can then be drawn on screen. Of course the copying is only done when the text changes.

  • But why are you creating roads every tick?

    The straight parts of the road can be done with single stretched rectangle sprites, and the rounded turns can be done by putting a circle sprite at the turns. It ends up looking the same as in the video of your game anyway, plus only uses maybe 20 or so sprites at any given time.

    You shouldn't be generating road by time intervals anyway. Just add more as the end of the road gets too close to the top of the screen.

    Destroying the road should be as simple as just checking when the y is below the bottom of the screen and it's off screen.

    uc88e55a465077cdbd7d87ed981e.dl.dropboxusercontent.com/cd/0/get/CiAZ5BKUhq96l38_4k1e-3TSUQ_3QnVOIA_2DlCaj5L5V3N6pV0iBsmAFO8xAsEWlvdqcVxqXxKfsAueEY80xnsiNSFlFqsm-6VOdbLJ3_NWMR2MvZtAO42aRjhPjDj_5h8/file

    At any rate this is how any similar games you've seen would do it.

    In the example the view is fixed and all the sprites are moved down. You can do the opposite, leave everything fixed and just scroll down. The only real change other than not moving the road would be to to reference the top and bottom in the view instead of using fixed y positions.

    So instead of y>-100 use y>viewtop-100

    and instead of y>480+100 use y>viewbottom+100

    I apologize if that's not the names of those expressions, but the actual one's should be similar.

  • An array is just data, if it’s really big don’t loop over the whole thing at once and it won’t cause an apparent hang.

    You can look at the browser console for more details about what the “network error” may be.

    You could also look into compressing the data before sending it. Also if it’s tilemap data why not put it in a tilemap first before getting the json. It will be smaller that the json from the array object.

    Instead of using a separate program to generate the json that runs in the background, I’d reccomend doing it in JavaScript instead so you don’t have to deal with network file transfers.

    You could do the generating in events too. The key here is to do stuff over many frames instead of all at once to avoid long slowdowns that would seem like a crash to the browser.

  • One idea would be to loop over the tokens and rebuild the comma separated list.

    Var a=“1,2,3,4,5”

    Var b=“”

    Repeat tokencount(a,”,”) times

    — loopindex=2

    ——add 44&”,” to b

    — else

    ——add tokenat(a,loopindex,”,”)&”,” to b

  • Wouldn’t it be better to create a new replacement plugin than to port it?

    They aren’t that high quality. But I guess if you just want it to work the same by all means.

  • Some plugins will never be ported. Either the dev isn’t around anymore, they don’t use c3 for some reason, or they just don’t have any interest.

    Porting to the new runtime adds more obstacles to port from the above mentioned reasons. One being the plugin may have relied on some internals of constructs runtime that changed.

    The only situation where you could say a plugin dev was unwise to port a plugin was maybe if they were selling it. Still, that’s up to them.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • So it doesn’t seem to be caused by the loops you added to your events. Maybe it’s an infinite loop inside a plugin?

    Rather than shooting in the dark, maybe try to utilize the browsers debugger. I’m really rusty with it but it should be able to show you where it’s looping infinitely.

  • G is the gravity amount

    Vx is the horizontal velocity

    Vy is the vertical velocity.

    For low speeds I wouldn’t worry about more precise bounces. It will look very precise.

    For a fixed timestep you’d do just that use 1/60 instead of dt in the equations. If the frame rate varies a lot that could be an issue. Sometimes a solution for that is to keep track if the next position and the current one and interpolate between them depending on the time. It’s simpler to just use dt though since that’s how constructs game loop works. It’s easier to make it look better anyways.

    There’s a property to draw sprites at integer positions. Just use that to avoid subpixel positions. You don’t want to round the position directly unless you keep the unrounded values in some variables. The motion would be messed up otherwise.

    Anyways just making events like the code above should be fine. If you want integer poisons use the position rounding property in the editor. (I forget what it’s called exactly)

  • You can do it without behaviors. Just give the object an x and y velocity and do the bouncing by checking if walls are going to be hit horizontally or vertically. If they are, then reverse the velocity. 

    Globals:
G=100

Instance variables:
Vx=0
Vy=0

Every tick
— sprite: add g*dt to vy

Sprite: overlaps wall at offset (self.vx*dt, 0)
— sprite: set vx to -self.vx

Sprite: overlaps wall at offset (0, self.vy*dt)
— sprite: set vy to -self.vy

Every tick
— sprite: set x to self.x+self.vx*dt
— sprite: set y to self.y+self.vy*dt

    Just set vx and vy when the player throws it. You can adjust g to taste.

    Should be pretty close. At the very least you’ll get the perfect bounces. There are improvements that could be had. Here are a few of them that may be of interest:

    Possible improvements:

    The sprite needs to be outside of walls when it starts and throughout the motion. If it’s in a tight area, or it’s started inside a wall, then you need to move it out of the wall first.

    Usually not an issue if created inside the players collision area, and it’s given enough room to move around.

    There can be energy loss with vertical bouncing at times. The sprite will bounce lower after a few bounces.

    One reason for this is variable dt. You can help correct this by replacing self.vy*dt in all expressions with self.vy*dt+0.5*g*dt*dt.

    Bouncing is done by checking where the ball will be a frame later. You can get more precise bounces by calculating when the wall is hit exactly before bouncing then moving again with the remaining time. Not really necessary but has advantages for very fast sprites.

    A final idea is to only use integers for position and speed, and always use a fixed dt. This complicates it a bit but it removes energy loss from rounding caused by floating point numbers.

  • There isn’t any debugging feature for that, at least not in construct. The browser’s debugger can let you look at the JavaScript where it’s looping, but that is very abstracted away from events so it probably isn’t very useful. I mean if we wanted to deal with JavaScript and debugging it we’d be using something other than construct.

    Anyways,

    You don’t have to check every loop you have though.

    If you use “while”, then I’d pay attention to that. It’s the only way to create an infinite loop other than with function recursion.

    Just make sure it can exit the loop. If not then as a band aid you could replace the while with a repeat. That way it will just stop instead of looping indefinitely.

    The second thing to look out for isn’t an Infinite loop, but a loop that takes long enough that the browser asks to stop it. It happens with infinite loops too, but I digress.

    Are you looping over big arrays that are increasing in size?

    Do you have a loop that changes the number if iterations based on an expression that sometimes gives a very big number?

    Anyways that’s where I’d look.

    Ideas to mitigate that is to not loop over an entire giant array in one tick but do it in smaller chunks. Like half one frame and the other half the next. Big is the key word here.

  • There’s a system condition that checks if a xy position is overlapping a object. That should do it.

  • Just temporarily change them. So change them to allow the boost, then after a little time change it back.

  • The speed is limited by the max speed and the deceleration brings it to a halt fairly quick.

  • Wikipedia is your friend for the various methods and how they are done.

    Apart from utilizing JavaScript you can do something by looping over the characters and changing them to something else.

    The simplist would be something like replace

    0 with v

    1 with 7

    2 with ;

    ...

    And so on.

    Decoding would be the reverse.

    It’s as tedius as it sounds. Athough there are shortcuts.

    Anyways I’m going to have to defer to someone else to finish answering this one.