R0J0hound's Forum Posts

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 1 Dec, 2015
  • Quote

  All the instances of a sprite share the same animation images. The current frame of an instance just references which image of that sprite object is used. So when you load a image from a url it replaces the shared image.

  In other words say your sprite is named "sprite" and it has three animation frames.

  Sprite object:

  frame 1

  frame 2

  frame 3

  Next you have four instances, all which use frame 1.

  sprite instance 1 -> frame 1

  sprite instance 2 -> frame 1

  sprite instance 3 -> frame 1

  sprite instance 4 -> frame 1

  So now if you use the "load image from url" action the instance's image isn't replaced (instances only reference images), instead the "sprite" type's image is replaced.

  You can't add a frame on the fly with the sprite object. You could just set each instance to use a different frame, but yeah you do need to add them at edittime.

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 30 Nov, 2015
  • Quote

  The problem is getting a good function name from all the actions and conditions, since they are mostly just sentences and there isn't any real consistency. I guess the function names from the runtime could be used, but I imagine some plugins could have some names completely different from the action/condition. Construct Classic allowed python scripting which allowed you to do this to an extent, but you couldn't do the same thing as with events.

  Beyond that point the idea of a typed scripting version of events was proposed before and one argument against it was needing to deal with the syntax and typos of such a language, which is a task in and of itself. Kind of a different beast to what C2 does already.

  You could unofficially do this already though, by generating event xml files. But it is a lot of work as I see it.

  It has the same issue as trying to convert a capx file to say c++ source code: It's simple on a very small scale, but to support everything, fix bugs and support changes as C2 updates it becomes a ridiculous task.

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 30 Nov, 2015
  • Quote

  The slight lag you see when a sprite is positioned to the mouse is a pretty common thing encountered in games in general.

  What happens is the sprite is positioned and the next vsync update the sprite is drawn. In that time the mouse could continue moving. In practice this delay is typically about a frame, but it can be longer if double or triple buffering is used as I recall which basically render frames ahead of time to help with performance.

  One solution in C2 to have an image match the mouses position exactly is to use the "set cursor from sprite" action of the mouse object. Other software can do something similar.

  Stuff like a windows app often use a different rendering pattern that allow things to be synced with the mouse exactly. Namely things are only redrawn when an event happens like a mouse move/click etc instead of at a regular rate of 60fps. Even then it's only part of the screen that gets redrawn, instead of everything.

  Edit:

  Going back to C2 the reason objects lag behind other objects they're pinned to is the the order the the pin behavior is run.

  Say you have three objects A, B and C.

  A is pinned to B and B is pinned to C.

  Ok next you move C.

  That frame first A's pin behavior runs first, but since B hasn't moved A isn't moved.

  Next B's pin behavior is run and it's position is updated from C.

  The result is A will lag behind a frame before getting in the correct location.

  This is the problem with behaviors sometimes, and why events are better imo, because you can control when things are done exactly.

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 28 Nov, 2015
  • Quote

  kingpirux

  What newt said. I was using the uids at runtime, where they never change. Setting up the hierarchy from the editor is a different issue, but still can be done with an instance variable to give each instance a unique value. Just be careful not to give two instances the same value.

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 28 Nov, 2015
  • Quote

  —

  Chipmunk2d doesn't really have kinematic bodies like box2d.

  Wouldn't setting the collision to none, giving the object a high mass, and canceling the gravity like below work?

  sprite: chipmunk: on pre step

  sprite: chipmunk: apply force rect(0,-self.chipmunk.gravity*self.chipmunk.mass)

  I realize it doesn't match box2d's defination exactly...

  [quote:23aut8md]A kinematic body moves under simulation according to its velocity. Kinematic bodies do not respond to forces. They can be moved manually by the user, but normally a kinematic body is moved by setting its velocity. A kinematic body behaves as if it has infinite mass, however, Box2D stores zero for the mass and the inverse mass. Kinematic bodies do not collide with other static or kinematic bodies.

  Namely, not responding to forces. You can set the mass to be infinite with events but there is a NaN issue with the library when doing that so a very high mass is better.

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 28 Nov, 2015
  • Quote

  Here's an experiment with some ideas.

  https://dl.dropboxusercontent.com/u/542 ... grass.capx

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 2

  • 28 Nov, 2015
  • Quote

  —

  I don't have a multi-touch device but you could try this. Put it before the event that positions the handles. The only conflict you may run into is dragging a handle while doing this.

  global number touchWidth_new=0
  global number touchWidth_old=0
  global number touchHeight_new=0
  global number touchHeight_old=0
  
  touch: on touch 1 start
  

  set touchwidth_old to (touch.xat(1)-touch.xat(0))*cos(sprite.angle) + (touch.yat(1)-touch.yat(0))*sin(sprite.angle)

  set touchheight_old to (touch.xat(1)-touch.xat(0))*cos(sprite.angle+90) + (touch.yat(1)-touch.yat(0))*sin(sprite.angle+90)

  touch: has touch 1

  sprite: pick instance with uid picked

  set touchwidth_new to (touch.xat(1)-touch.xat(0))*cos(sprite.angle) + (touch.yat(1)-touch.yat(0))*sin(sprite.angle)

  set touchheight_new to (touch.xat(1)-touch.xat(0))*cos(sprite.angle+90) + (touch.yat(1)-touch.yat(0))*sin(sprite.angle+90)

  sprite: set width to self.width+touchwidth_new-touchwidth_old

  sprite: set height to self.height+touchheight_new-touchheight_old

  set touchwidth_old to touchwidth_new

  set touchheight_old to touchheight_new[/code:fjvyjdm3]

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 28 Nov, 2015
  • Quote

  The collision point thing is mainly a recommendation, and mainly relates to C2's collision detection system. The physics behaviors use their own collision detection system if that's of any concern. Overall I'd just test it and see if it works fast enough for your liking. If not simplify your collision polygons.

  The other aspect you're testing with big backgrounds and one instance per Sprite will just use more video memory. You can leave it as is and if it works, great, but the memory requirements for your game will be higher which limits what systems can run it.

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 28 Nov, 2015
  • Quote

  You mean my example causes that error? Or in your capx?

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 28 Nov, 2015
  • Quote

  Ah ok that makes sense.

  Basically you want to put objects around the edge of the object and want the objects to be angled in the direction of the edge.

  There isn't a way to access the collision polygon. A way to approximate it could be to create a ring of objects around the ground then move them toward the ground's center until they collide with the ground. At that point the object's will be shrink wrapped around the ground. You could then find the angle of the edge by using the angle expression between two adjacent points.

  There are probably other ways to detect the edge. One could be to position invisible rotated rectangles around the shape in the editor to define the edge. You could also use the paster object to draw a Sprite in a warped way around the shape.

  Unless you're drawing the ground at runtime it's probably better to position the objects in the editor. I believe Sqiddster did that in Airscape.

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 28 Nov, 2015
  • Quote

  I don't understand the question. Can you make a diagram?

  Best I can tell you want to put tiles on top of an irregular shape? What would that look like?

  Also what do you mean by an object ends? Do you mean it gets destroyed?

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 28 Nov, 2015
  • Quote

  You'll have to export such a project to see how big it is. The images and sounds of your game will take up most of the space. Layouts and instances of objects take up a lot less space.

  The number of layouts doesn't affect performance.

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 28 Nov, 2015
  • Quote

  There is a system action to set the layout size, but it's probably easier to just set the layout to unbounded and not worry about the layout's size.

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 28 Nov, 2015
  • Quote

  If you design the starting plain in the editor then it's just a matter of creating other terrain where the plain ends.

  Let's consider creating the terrain to the right. You'll need two global variables for the X and y of the end of the terrain. You can set these values manually. Next you'll need a global variable to keep track of a random number. Your events could then look like this if each terrain piece was an object. Note the "---" means the event is a sub event.

  Global number X=400

  Global number y=409

  Global number terrain=0

  Start of layout

  Repeat 10 times

  set terrain to int(random(3))

  --- terrain = 0

  --- > create forest at (X,y)

  --- > add 200 to X

  --- terrain = 1

  --- > create hills at (X,y)

  --- > add 300 to X

  --- terrain = 2

  --- > create grass at (X,y)

  --- > add 400 to X

  Start of layout

  create right_cliff at (X,y)

  This is also assuming the values added to X are the width of the objects and the hotspot of the objects are positioned to the left.

  Anything more deluxe can be done in a similar fashion. For instance the terrain could consist of multiple created objects or you could even set tiles on a tilemap is you so desire, just be sure the tilemap is wide enough.

• Try Construct 3

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

  Try Now Construct 3 users don't see these ads
• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 27 Nov, 2015
  • Quote

  The customMovement behavior doesn't really add much to be helpful for that. maybe the "stepping mode" where you can check for collisions in the in between positions with the "on step" trigger.

  Pushing out once colliding isn't the best here. It would be better check if the way is clear before moving.

  And actually I would go for doing the whole thing with events.

  I'd put everything I wanted to collide with in a family and call that solid then the simplest example would be this:

  [negated] sprite: overlaps solid at offset (1,0)

  sprite: set x to self.x+1

  You could then extend it with a speed instance variable to make the acceleration and finer motion:

  [negated] sprite: overlaps solid at offset (self.speed*dt,0)

  sprite: set x to self.x+self.speed*dt

  sprite: add 1500*dt to speed

  else

  sprite: set speed to 0

  When hitting a solid it will look to stop short sometimes and close the gap. This can be improved by using a loop to check each step in between. for that add another instance variable called "delta". Another benefit is this keeps the objects on pixel coordinates while staying framerate independent. This adds consistency to the collisions so they always stop the same distance away.

  every tick

  sprite: add 1500*dt to speed

  sprite: add self.speed*dt to delta

  repeat sprite.delta times

  ---[negated] sprite: overlaps solid at offset (1,0)

  --- > sprite: set x to self.x+1

  --- > sprite: subtract 1 from delta

  ---else

  --- > stop loop

  --- > sprite: set delta to 0

  --- > sprite: set speed to 0

  Now you could instead use the custom movement behavior instead by setting the stepping mode property and using the on step trigger. The only issue is "on step" is triggered after the object moves so you'll have to back it up or push out. That can go wrong if it pushes out into another object, which can easily happen with objects with floating point coordinates while being close to each other.

  EDIT:

  Here's an example:

  https://dl.dropboxusercontent.com/u/542 ... _move.capx

  The events are generic for any angle and I shrank the collision polygon a bit.

  One more thing that could be done with this is simultaneous movement of the blocks. Right now their motion is handled on by one, but you also could let each move a pixel, then repeat for all of their deltas are below 1.

  https://dl.dropboxusercontent.com/u/542 ... neous.capx

  Further tweaks would probably be some rounding in some spots to keep things with integer values, but I'm not sure if it's needed.

  EDIT2:

  had a typo in limiting the speed. used max when it should have been min.