R0J0hound's Forum Posts

  • I speculate that the reason the website is so slow is because the servers are becoming sentient, and are devoting more and more possessing power toward planning world *********** I just hope the Gullen bro's have amassed enough flying monkey's to hold the servers at bay once they achieve locomotion, and unleash their retribution.

  • 1

    Create new project

    2

    Add mouse, text, and canvas objects

    3

    Give the canvas object an image and position it at 0,0

    4

    Go to the event editor and add a "every tick" condition.

    5

    Add the action: text-> set text to canvas.rgbaAt(int(mouse.x), int(mouse.y))

    6

    Run it and the text object will tell the color under the mouse on the canvas object.

    Extra tidbits:

    Int() is used since mouse.x can give values like 10.5 when window scaling is used and the value needs to be a whole number.

    .rgbaAt uses x and y values relative to the top left of the canvas object. So if you moved the canvas object from 0,0 you'd have to change the expression to:

    Canvas.rgbaAt(int(mouse.x-canvas.x), int(mouse.y-canvas.y))

    Finally notice it only gets the color from the canvas' own texture. Use the drawing actions to change this texture.

  • You can use c++ to make plugins. You can download the sdk from here:

    http://sourceforge.net/p/construct/code/HEAD/tree/

    Youll need to use visual studio since the sdk uses CString. Their was a wiki with a guide, but it seems to have disappeared. You can look at the source for other plugins as examples, also you can find a lot of info here:

    construct-engineering_f168

    You could use c++ from python but it would require a python lib that allows you to use c++, or you could compile a dll and access it from python with ctypes. You'd have to use python to interface with anything in the engine though.

    I have done some expiriments with accessing sprites from c in a dll, but its tricky and still needs python to call the dll.

  • Another idea is you can use the "wait" action with actions to change angle and turning speed in between.

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

  • I can attest to arrays making it easier. Especially if you want a way to see if the kings are in check. I also recommend using the function object too. It can help you eliminate redundant events and keep you below the 100 event limit for the free version.

    Do you think you'll support more exotic moves like "en passe" and "castling"?

  • ErekT

    You can calculate it though. The complexity depends on what shapes you use. Of course an overlap seldom occurs at one spot unless they are just touching.

    The simplest would be a circle circle collision. The collision normal would be the angle from circleA to circleB.

    Normal_AtoB = angle(circleA.x,circleA.y,circleB.x,circleB.y)

    Then the point on CircleA would be (CircleA.x+radiusA*cos(Normal_AtoB), CircleA.y+radiusA*sin(Normal_AtoB))

    And the point on circleB would be (CircleB.x+radiusB*cos(Normal_AtoB+180), CircleB.y+radiusB*sin(Normal_AtoB+180))

  • For the physics behavior you can do a custom gravity angle by applying a force at an angle to the balloon every tick. This is by far the simplest to do.

    The motion bit isn't hard you could even do it without behaviors with two variables VelocityX and velocityY and an event like:

    Every tick:
---add acceleration*dt*cos(degrees-90) to velocityX
---add acceleration*dt*sin(degrees-90) to velocityY
--- ball set position to (self.x+velocityX*dt, self.y+velocityY*dt)[/code:34atxzhw]

The collision response with wall sliding is trickier.  I'd recommend the custom movement behavior with the "push out nearest" action but I doesn't look right imo.  But pushing out the closest direction is what is required for sliding, well that and making the speed in direction of the wall zero.  For that you'd need two pieces of info: collision normal and overlap depth.  

They possibly could be found with a bunch of is overlapping at offsets to find where around the ball is free and from that get the normal, then a few more overlap checks to get the overlap depth or just to push the ball out of the solid at an angle.  With 3000 collision counts per second that would be 50 per frame at 60fps.  You possibly could get it to work with using overlap checks in events but it would be tricky.  If all your walls are only rectangles you'd only need to check 4 directions (wall.angle, wall.angle+90, wall.angle+180 and wall.angle-90).

Here is a capx of that idea:
[url=https://dl.dropboxusercontent.com/u/5426011/examples24/balloonPush.capx]https://dl.dropboxusercontent.com/u/542 ... nPush.capx[/url]
Notice it's a bit jittery so it may need some more finesse. Maybe a sub event of 10 to backup into the wall by smaller steps than a pixel.  As it stands I get about 10 collision checks per tick.  Also pushing out at the corners of walls will be jumpy.

A superior method is in slide3.capx in this post:
[url=https://www.scirra.com/forum/viewtopic.php?f=147&t=103339&p=775018&hilit=wall+sliding#p775018]viewtopic.php?f=147&t=103339&p=775018&hilit=wall+sliding#p775018[/url]
It does one overlap check per wall and then calculates the closest direction and how far exactly to push out.  The con is its much more complicated to make.  Also a bench would have to be done to see if it is actually fast or if the extra calculations counteract. 

But again the physics behavior is the easiest to work with.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • No, even internally c2 only checks if there is an overlap not where they collide.

  • The difference is the for loop will do everything in one frame and the tickcount or adding variable way will take 30 frames. If the for loop takes too long the browser may complain, thinking it may be an infinite loop but it may not be.

    The "for" loop will run 30 times every time it's encountered in the events. That means that everything stops until it finishes. If the events it does is very time consuming then the web browser will show a popup guessing it's an infinite loop, but it's not always, it's just taking too long. Usually for something like level loading you only want to do it once instead of every tick so you'd use "start of layout" or something.

    Start of layout

    For "t" 1 to 30 do ----- "level loading events"

    The tickcount way just runs once per frame for 30 frames (ticks) instead of 30 times in one frame. Doing it that way has the advantage of distributing the time to do something over multiple frames. Specifically this will run once per frame for the first 30 frames.

    If tickcount < 30 do ----- "level loading events"

    You could also use "is in between values" to run at any frame range. For instance to start at tick 30:

    global number Start_Tick = 30

    If tickcount is between values Start_Tick to Start_Tick+30-1 do ----- "level loading events"

  • In my experience "Bounce Off Solids" works well only when bouncing off of stationary objects.

    For example this uses "Bounce Off Solids" for everything.

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

    Notice unsightly teleportation when objects get in close quarters.

    So one Idea that eliminates the teleporting is to have the enemies not have the solid behavior and resolve their collisions as they move with events. Basically it involves checking the distances of every enemy with all the others. If the enemies are too close we can calculate exactly how much they are overlapping and then can move one enemy half the overlap one way and the other enemy half the distance the other way.

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

    One thing that is not addressed is changing the enemy's speed. They will appear to stop until the path is free and they will jet back at their original speed.

    In this final example I addressed the lack of bouncing. To do it I needed to get and set velocity x and y so I opted to remove the bullet behavior and do the movement with events.

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

    It works well, but there is no collision response with the walls.

    You could make example 2 work with the bouncing in example 3 by converting the bullet behavior's speed and angleOfMotion to vx and vy with:

    vx=speed*cos(angleOfMotion)

    vy=speed*sin(angleOfMotion)

    doing the calculations and then converting back with:

    speed=distance(0,0,vx,vy)

    angleOfMotion=angle(0,0,vx,vy)

    Another idea would be just to use the physics behavior for the whole bit.

  • Opps... I see I had the subtraction reversed. :p Glad you got it working.

    cheers

  • You'll have to use this plugin to get the date:

    http://c2rexplugins.weebly.com/rex_date.html

    on the start date save the UnixTimestamp (seconds since Jan 1, 1970) to webstorage for later, we'll call this start_time.

    Then any following times you want to see how many days have passed you retrieve the saved time from webstorage and subtract the current UnixTimestamp. That will give you the number of seconds from one date to another. Divide by 60 to get minutes, 60 again to get hours, and finally also by 24 to get days.

    days = (start_time - UnixTimestamp)/60/60/24

  • The closest thing to that would be to use the third party Canvas plugin. It has a rgbaAt expression but it only works to get the color on the canvas object's texture. It also has actions to draw other objects onto this texture which is useful.

    The overall method would be to draw everything on screen to a screen sized canvas object, and after that get the color with rgbaAt.

  • Short version:

    1.The 2500 is from the conversion factor (50) from box2d units to pixels.

    2. Your equation to calculate won't work for all shapes. Instead of just mass you need to calculate the Moment of Inertia for that particular object. After that the only magic number is 0.02 or (1/50) which is the conversion factor from pixels to box2d units.

    3. [quote:2iwgq6s7]AngularVelocity = Velocity / Diameter (pi)

    should be:

    AngularVelocity = Velocity * 180 / (radius * pi)

    Long Version:

    Box2d internally uses it's own distance unit (m) which is 0.02 pixels.

    The conversion is:

    1 [pixel] = 0.02 [m]

    or

    50 [pixel] = 1 [m]

    The set Velocity action and getVelocity expression already do the conversion without help, but the conversion isn't considered with Force or Impulse.

    Before I go any further I'd like to suggest that the mass expression is returning a bad value. The formula for mass with units is:

    Mass [d * m^2] = density [d] * area [m^2][/code:2iwgq6s7]
Where [d*m^2] is the same as [kg]

So for a 32x32 pixel square with density 1 the mass should be:
[code:2iwgq6s7]area [m^2]= (height [pixel] * 0.02 [m/pixel]) * (width [pixel] * 0.02 [m /pixel]) = (32 * 0.02) * (32 * 0.02) [m^2] = 0.4096 [m^2]
mass [d * m^2] = density [d] * area [m^2] = 0.4096 [d * m^2][/code:2iwgq6s7]
But the mass expression returns 20.48 or 50 times 0.4096 which is incorrect since that makes the units [d*pixel*m].

This is only important because if it were correct you'd only have to multipy by 50 instead of 50*50 or 2500 with the Force and Impulse equations.

Torque is a bit trickier.  The equation for Torque is:
[code:2iwgq6s7]Torque [kg*m^2*deg/s^2] = inertia [kg*m^2] * ang_accel [deg/s^2][/code:2iwgq6s7]

[url=http://en.wikipedia.org/wiki/List_of_moments_of_inertia]Inertia is calculated differently for different shapes[/url].  For a square the equation is:
[code:2iwgq6s7]Inertia = mass * (width^2 + height^2)/12[/code:2iwgq6s7]
For mass we'll use 0.4096 and we'll need to covert height and width from [pixel] to [m] and we get:
Inertia = 0.4096 * ((32*0.02)^2 + (32*0.02)^2)/12 =~ 0.02796...

I then ran a test to apply a torque of 1 for 60 ticks. At the end the angular velocity was approximately 35.76. From that the acceleration could be calculated with acceleration=(final_speed-initial_speed)/time which ended up being 35.76.

The numbers agreed with the equation when it was plugged in:
torque = inertia * ang_accel
1 ?= 0.02796 * 35.76 
1 ~= 0.9998

This link may also be useful as it predicts motion using equations much like yours.

-cheers

  • For #1 are triggering a floodfill when just hitting a ceiling. It doesn't look like it is.

    For #2 I've noticed the snapping doesn't seem right at times. The equations I used do what they were designed to do: find which square on a staggered grid to snap to.

    I did a test to evaluate the equation.

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

    The formula is about the same as in the bubble shooter capx I've made before. I also compared it to just picking the nearest grid sprite which would be perfect minus the need all the sprites. Anyway there are subtle differences in the gaps. My conclusion is a new formula needs to be found so that snapping isn't done to the nearest square but the nearest hexagon, which would mirror using picking nearest.

    A internet search for "snap to hex grid" would probably be the next step.

    After that the issue of snapping into walls or other jewels may still be there and require another solution.