CHIPMUNK en bennu

[Prg]

otra cosa, el prototipo de las funciones hook no puede ser cualquiera, esto no va:

static int updatePhisc(INSTANCE * my, int * params)

debe ir esto

static int updatePhisc()


cuidado cuando modificas las coordenadas del proceso, porque deberias tener en cuenta las modificaciones que el usuario haga, por ejemplo, mover un personaje, aunque este este afectado a un efecto fisico, tu efecto fisico deberia interactuar con esto.

quizas en estos casos deberias poner unas locales que indican como el objeto se mueve en ese frame, algun INCR_X, INCR_Y o DELTA_MOTION_X, DELTA_MOTION_Y, o incluso alguna que indique la fuerza que ejerce en ese movimiento (si corresponde), y esas variables seran responsabilidad del usuario/programador setear, asi a vos te es mas facil actualizar las coordenadas.

sí tomo en cuenta las modificaciones del usuario. lo que hago es revisar el valor de la x con la x del frame anterior, si son distintas actualizar las posición del curpo físico y luego actualizar las coordenadas del proceso con lo que la física me indica. eso sí, Debo pulir un poco esto para que el modificar las coordenadas del cuerpo no se brinque la física.

Supongo que ahora será con listas ligadas o con un arreglo dinámico (antes eran prosesos loa que se encargaban).

ya tengo gran parte funcionando con ids, además ya se inicializa la librería automáticamente y se libera, sólo me faltaría implementar las LLS o el arreglo dinámico para la actualización cada frame de los procesos. para saber si un proceso existe, uso el código de la función exists, o será mejor revisar cada proceso en cada frame para saber si está en el motor y entonces actualizar las coordenadas? (si la respuesta es revisar cada frame, cómo se revisan todos los procesos?)

ah si, el update ya funciona, gracias

[SplinterGU]

fantastico...

si, imagine que ibas a usar ese metodo de calcular segun el valor anterior... pero... (malditos peros...) el problema esta en que no siempre los cambios de coordenadas corresponden a un movimiento, podria darse el caso que se trate de un reposicionamiento o reubicacion, con lo cual seria el movimiento cero de ese objeto y no deberia aplicar la fisica, por lo menos, no en ese frame.

por eso, yo sugeri un delta... asi si ese delta es 0, sabemos que el objeto no se movio.

[Prg]

ya veo.  :)

No estoy muy seguro si hay problemas con reubicaciones (por la forma en que la física trabaja). Si encuentro algún problema o alguien lo encuentra le ponemos los deltas, también existe la opción de reposicionar mediante una función cuando se requiera un cambio extremo.

aunque ahorita que lo pienso los deltas podrían solucionar algunos problemas menores que tengo ahorita... y se podrían aplicar impulsos para resolverlos...

tengo que revisar muy seriamente esta opción. gracias por la idea amigo.

Iré haciendo la lista ligada para la actualización de los procesos y luego vemos este tema... saludos

por el momento te dejo tranquilo, tengo todo el material que necesito para continuar programando mucho rato. gracias

[Prg]

creo que hablpe muy pronto con lo de ya no preguntar...
cómo le hago para acceder a las locales que otros módulos definen como x, y, angle e id?

con un ejemplo es suficiente

[SplinterGU]

agregando una entrada al fixup...

la idea del fixup es, quiero acceder a la variable XXX, pero no tengo la direccion... querido motor, me das la direccion? entonces el motor recorre tu estructura fixup con todos los nombres de las variables que vos queres acceder y rellena en el campo que incialamente esta en NULL, la direccion, los otros 2 valores que estan a -1 son size y cantidad de elementos, que los llena el motor cuando carga la dll, solo se necesita que el usuario ponga el nombre.

por eso, si queres acceder a X, Y o angle o id, pones 4 entradas con el nombre de cada una de estas variables... luego agregas un define que te sirva para identificar mas facilmente cual de los indices de ese array accedes con GLO o LOC.

recordar que hay 2 fixups, 1 para globales y otro para locales.

y si vas a usar variables de otro modulo, o usas la funcion para detectar si la variable existe, que basicamente es ver que el valor del address no sea NULL en el caso de las globales y el size en las locales (pero ya hay un define para eso)... o incluir el modulo (o lib) en las dependencias (modules_dependency).

----

con respecto a la reubicacion, la cosa es que deberia ser transparente al usuario... y no tener que llamar a ninguna funcion desde el lenguaje... salvo funciones como ser (tiro cosas sin saber el api), por ejemplo, "crear_viento(direccion, fuerza)", hablo por hablar... no tengo idea del api... pero espero se entienda la idea.

[SplinterGU]

obviamente, estas cosas estaria bueno ponerlas si es posible, si no lo es, pues nada... se queda con funciones...

[Prg]

actualmente con códigos como este

[code language="bennu"]//PRG, ejemplo para el motor de física

import "mod_key";
import "mod_text";
import "mod_proc";
import "mod_grproc";
import "mod_video";
import "mod_wm";
import "mod_map";
import "mod_say";
import "mod_math";
import "mod_screen";
include "libChipmunk.h"

global
   pelota;
   cpVect verts[]=
   -25,-25,
   -25,25,
   25,25,
   25,-25;
   cuadro;
   bola;
   bomba;

Begin
   set_mode(800,600,32);
   cuadro=load_png("cuadro.png");
   bola=load_png("bola40.png");
   bomba=load_png("bomba.png");
   damping=1;
   for (z=0;z<15;z++)
      cuadro(z*50+50,50);
   end
   for (z=0;z<15;z++)
      cuadro(z*50+50,550);
   end
   for (y=0;y<4;y++)
      for (z=0;z<6;z++)
         cuadro(z*100+150,y*100+150);
      end
   end

   for (z=0;z<9;z++)
      cuadro(50,z*50+100);
   end

   for (z=0;z<9;z++)
      cuadro(750,z*50+100);
   end
   bomberman(150,150);
   bias_coef=1;
   write(0,400,10,4,"Presiona v para dejar una bomba que se empuja");
   write(0,400,20,4,"Presiona space para dejar una bomba que NO se empuja");
   while (!key(_esc))
      frame;

   end
   let_me_alone();
end

process cuadro(x,y)
begin
   static=true;
   mass=infinity;
   inertia=infinity;
   elasticity=1;
   friction=1;
   group=1;
   addPolyShape(0,0,4,&verts);
   graph=cuadro;
   z=-15;
   loop
      frame;
   end
end

process bomberman(x,y)
private
   cpVect pos;
   press,press1;
   id2;
begin
   x=400;
   y=100;
   mass=10;
   inertia=10;
   priority=father.priority-2;
   elasticity=0;
   friction=0;                 //para que no gire al friccionar con otros objetos
   group=2;
   addCircleShape(0,0,20);
   graph=bola;
   while (!key(_esc))
      if (key(_right))
         incr_x=5;
                       angle=0;
      end

      if (key(_left))
         incr_x=-5;
         angle=180000;
      end

      if (key(_up))
         incr_y=-5;
         angle=90000;
      end

      if (key(_down))
         incr_y=5;
         angle=270000;
      end

      if (key(_space))
         if (press)
            bomba(x,y,20000.0);
            press=false;
         end
      else
         press=true;
      end

      if (key(_v))
         if (press1)
            bomba(x,y,1.0);
            press1=false;
         end
      else
         press1=true;
      end

      frame;

   end
end

process bomba(x,y,mass)
private
   cpVect pos;
   pego=true;

begin

   priority=father.priority-2;
   group=2;
   elasticity=0.3;
   friction=0;
       addCircleShape(0,0,20);
   graph=bomba;
   while (!key(_esc))
      if (pego and not collision(father))
         group=CP_NO_GROUP;
         pego=false;
      end
      frame;

   end
end
[/code]

ya tenemos física.

ahora sólo falta revisar que todo esté bien, agregar un callback para saber cuándo se puede brincar (espero saber cómo hacerlo) y uno para saber dónde colisionan los objetos (he visto esto en los ejemplos, pero ambas cosas no se cómo se hacen).


también quiero ver por qué el raycol detecta algunos círculos y otros no, quizá sea por el tamaño del radio...

dejo la carpeta con los ejemplos en la funcionando con las locales en la parte de la descarga de abajo. Se eliminó el link de descarga y se deja la última versión al principio del tema

[SplinterGU]

deberiamos evitar estas funciones:

addPolyShape(0,0,4,&verts);
addCircleShape(0,0,20);

quizas agregar variables locales del estilo:

ShapeType

y en base a ShapeType tomar en base al grafico (la circleshape) el radio y en usando una variable shapeVerts los vertices, no se si esta variable son de cantidad fija de elementos, si es asi, entonces no hay drama, si es cantidad variable, entonces deberia ser un array de ints, con el primer elemento indicando la cantidad de vertices, asi como hace la xgraph.

[Prg]

podría hacerse, pero se elimina la posibilidad de agregar varios shapes a un sólo proceso (actualmente se deja que la masa, inercia, elasticidad y fricción se definan aparte en los shapes extras. Aún no pruebo que funcione el sistema con varios shapes), y haciéndolo como comentas se elimina la posibilidad por completo.

además es esta función la que crea el nodo de actualización del motor internamente.

[josebita]

Prg, cuando tengas esto medio rulando definitivamente, mándame un PM (ando con exámenes y no puedo estar muy atento a todo lo que me gustaría, así que igual no me entero) y lo meto en mi PPA, que me interesa mucho.

[Prg]

Prg, cuando tengas esto medio rulando definitivamente, mándame un PM (ando con exámenes y no puedo estar muy atento a todo lo que me gustaría, así que igual no me entero) y lo meto en mi PPA, que me interesa mucho.

ok, yo te aviso. :)

deberiamos evitar estas funciones:

addPolyShape(0,0,4,&verts);
addCircleShape(0,0,20);

quizas agregar variables locales del estilo:

ShapeType

y en base a ShapeType tomar en base al grafico (la circleshape) el radio y en usando una variable shapeVerts los vertices, no se si esta variable son de cantidad fija de elementos, si es asi, entonces no hay drama, si es cantidad variable, entonces deberia ser un array de ints, con el primer elemento indicando la cantidad de vertices, asi como hace la xgraph.

bueno, ya lo he pensado bien, veré qué hago..

una pregunta, se pueden invocar funciones de bennu desde la librería?
recuerdo haber escuchado que con una cadena con el nombre se podian llamar, sería para dejar dos callbacks al alcance del usuario bennu, unos callbacks con muchos beneficios: saber cuando dos objetos collisionan y saber cuándo se pueden borrar objetos manualmente..

[SplinterGU]

podría hacerse, pero se elimina la posibilidad de agregar varios shapes a un sólo proceso (actualmente se deja que la masa, inercia, elasticidad y fricción se definan aparte en los shapes extras. Aún no pruebo que funcione el sistema con varios shapes), y haciéndolo como comentas se elimina la posibilidad por completo.

además es esta función la que crea el nodo de actualización del motor internamente.

la idea es que el nodo se actualice internamente usando esta funcion, pero no se que onda si son varios shapes, lo mio fue una idea, pero puedes usar una variable para cada tipo de necesidad (masa, inercia, friccion, elasticidad, etc)

Prg, cuando tengas esto medio rulando definitivamente, mándame un PM (ando con exámenes y no puedo estar muy atento a todo lo que me gustaría, así que igual no me entero) y lo meto en mi PPA, que me interesa mucho.

ok, yo te aviso. :)

deberiamos evitar estas funciones:

addPolyShape(0,0,4,&verts);
addCircleShape(0,0,20);

quizas agregar variables locales del estilo:

ShapeType

y en base a ShapeType tomar en base al grafico (la circleshape) el radio y en usando una variable shapeVerts los vertices, no se si esta variable son de cantidad fija de elementos, si es asi, entonces no hay drama, si es cantidad variable, entonces deberia ser un array de ints, con el primer elemento indicando la cantidad de vertices, asi como hace la xgraph.

bueno, ya lo he pensado bien, veré qué hago..

una pregunta, se pueden invocar funciones de bennu desde la librería?
recuerdo haber escuchado que con una cadena con el nombre se podian llamar, sería para dejar dos callbacks al alcance del usuario bennu, unos callbacks con muchos beneficios: saber cuando dos objetos collisionan y saber cuándo se pueden borrar objetos manualmente..

los callbacks no es algo fiable, por lo menos no mientras se ejecuta el ciclo, quizas puedes capturar los eventos para el proximo frame o procesarlos en los hooks, no se, seria cuestion de probar.

[Prg]

Ya terminé...

sólo quedó un detallito:

cuando seteo las variables, no puedo crear su cuerpo sino hasta después del primer frame, por lo que antes de usar funciones del motor hay que hacer un frame la primera vez. esto se ve en los ejemplos.

Agregué un ejemplo de plataformas con scroll.

ahora hay que ver si todo está bien. eso lo veré con sus quejas.

mmm, información no hay. los ejemplos es toda la información. Después agregaré ayuda.

dejo la versión actual aquí y en el primer mensaje.

[josebita]

Veo que trae código C. ¿La puedo considerar final?
Otra cosa, para subir la librería al PPA necesito darle una licencia, ¿la librería es GPLv2, como bennu?.

Gracias :)

PD: Necesito saber también el número de versión de la librería (para facilitar el tema de las actualizaciones).

[SplinterGU]

hay que resolver el tema del frame...

por eso decia yo de que el cuerpo no lo crees en el proceso, sino por variables... tambien podes crearlo ni bien sale el proceso (frame) y no esperar el frame real, esto es por si otros procesos interactuan con este proceso... esto se hace con un callback, algo de post_process o algo asi.