forked from enlightenment/efl
parent
ff3e3c3b39
commit
f5a849a691
|
@ -171,7 +171,7 @@
|
|||
* sphere EPhysics_Body previously created.
|
||||
*
|
||||
* We mainly use the ephysics_body_central_impulse_apply() function. This
|
||||
* function applies an inpulse on the center of a body.
|
||||
* function applies an impulse on the center of a body.
|
||||
*
|
||||
* Once pressed \<Up> key it applies a central impulse of 0 kilos on X axis,
|
||||
* 10 kilos on Y and 0 kilos on Z - so the ball is forced up.
|
||||
|
@ -907,7 +907,7 @@
|
|||
* last parameters are responsible to set a relative position to apply the
|
||||
* force.In other words, the force applied with an offset will make the body
|
||||
* rotates. Otherwise (0, 0, 0) the force would be applied on the center of the
|
||||
* body, in this case its recomended use the
|
||||
* body, in this case its recommended use the
|
||||
* ephysics_body_central_force_apply();
|
||||
*
|
||||
* @skipline ephysics_body_force_apply(box_body1
|
||||
|
@ -980,7 +980,7 @@
|
|||
*
|
||||
* In this callback, we'll pass through a list with 3 balls and apply the
|
||||
* growth and the shrink between the limit we'll set. Note that the variable
|
||||
* i recieves different values on each iteration (-1, 0, 1). For the first
|
||||
* i receives different values on each iteration (-1, 0, 1). For the first
|
||||
* iteration it will decrease the size variable, the second will keep the
|
||||
* same value, and the last one will increase the size variable.
|
||||
*
|
||||
|
@ -1465,7 +1465,7 @@
|
|||
*
|
||||
* We need to handle the velocity using delta time to have the acceleration
|
||||
* on every tick. Check if its the first time to return before shows
|
||||
* informations about the velocity because we dont have the old aceletations
|
||||
* informations about the velocity because we don't have the old aceletations
|
||||
* and then the calculation of this informations will be wrong.
|
||||
*
|
||||
* Here we calculate the aceletarions using this formula:
|
||||
|
|
|
@ -392,7 +392,7 @@
|
|||
* canvas and a red border around the container object of interest,
|
||||
* the box, to mark its boundaries. Resizing of the canvas will keep
|
||||
* the box's proportion with regard to the whole canvas', so that you
|
||||
* can experiment with different sizes of the box to accomodate its
|
||||
* can experiment with different sizes of the box to accommodate its
|
||||
* children:
|
||||
* @dontinclude evas-box.c
|
||||
* @skip adjust canvas' contents on resizes
|
||||
|
@ -937,10 +937,10 @@
|
|||
* an interfaces demonstration.
|
||||
*
|
||||
* A smart interface is just a functions interface a given smart
|
||||
* objcet is declaring to support and or use. In Evas, interfaces are
|
||||
* object is declaring to support and or use. In Evas, interfaces are
|
||||
* very simple: no interface inheritance, no interface
|
||||
* overriding. Their purpose is to extend an object's capabilities and
|
||||
* behaviour beyound the sub-classing schema.
|
||||
* behavior beyond the sub-classing schema.
|
||||
*
|
||||
* Here, together with a custom smart object, we create and declare
|
||||
* the object as using an Evas interface. It'll have a custom
|
||||
|
@ -956,7 +956,7 @@
|
|||
* Note that there's error checking for interfaces creation, by means of
|
||||
* the @c add() method's return value (@c _iface1_add(), here).
|
||||
*
|
||||
* Now note that here we are filling in the interface's fields dinamically.
|
||||
* Now note that here we are filling in the interface's fields dynamically.
|
||||
* Let's move on to that code region:
|
||||
*
|
||||
* @dontinclude evas-smart-interface.c
|
||||
|
|
Loading…
Reference in New Issue