Sobre lo de cambiar el tema de los estupendos map_get_pixel y tal.. haber.. esto es algo que seguramente tiene una solución mas simple de lo que parece, según comenta gino la idea es modificar practicamente todo el core para adaptarlo a este nuevo sistema, pero.. este sistema en si es bastante valioso y muy practico para seguir haciendo cosas concretas y que en un momento dado no se hasta que punto podríamos echarlo en falta..
Yo propongo otro punto de vista:
- Los archivos .map y .fpg que sigan siendo identicos a como lo son ahora, osea, mapas con algo de info extra "los .map" y librerías de este tipo de gráficos "los .fpg", y el plato gordo del nuevo sistema yo me lo imagíno de esta manera:
El motor box2D es bueno, es actualizado y mantenido así que lo veo una buena opción para considerarlo como un posible candidato ya en firme.
El tema es el siguiente:
Si se parte de la base en que se va a usar esta librería "que de una forma bastante sencilla lo hace todo sola con muy pocas lineas de configuración" yo veo el problema como algo bastante simple.. solo hay que incluir en el propio core de gemix un desvío a una subrutina que se encarge de modificar las variables X Y ANGLE de los procesos, nada mas.
Osea.. si estoy en lo cierto el core de gemix mira por prioridad a los procesos y los ejecuta en serie uno detrás de otro hasta el ultimo, vale.. pues simplemente hay que añadir a cada proceso unas pocas variables locales que definan el tipo de colisión que se desea, la masa de ese proceso, y poco mas.. por que box2d creo que ya tiene algún sistema para converitr a polígono una imágen, y en el fondo de todo este asunto, un proceso no deja de ser mas que una imagen o Sprite el cual manipulamos con unas pocas variables locales..
Osea resumiendo, si tengo un proceso que se llama "pepe" y escribo esto en su código:
process pepe();
begin
physics.status = true;
physics.collisionType = type_circle;
ya no necesito nada mas.. en realidad con esto basta para que la bos2d haga todo, simplemente hay que desde el core mirar si el proceso que toca ejecutar en ese momento tiene su "physics.status" en true, si es así se le dice a la librería que haga lo que tiene que hacer.. que es manejar al objeto.. como lo hace? simple, si he creado 100 process y los 100 tienen su STATUS en true.. pues pasan a ser objetos controlados por a box2D, si no pues la box2D los ignora y punto.
El único punto fuerte de todo esto es solo uno, el sistema que se va a usar para convertir una imagen en algo que la box2D entienda como un polígono o circulo, todo lo demás está tirado en serio, no es nada complicado pues la lib lo hace todo sola..
También hay otro punto fuerte que hay que mirar de solucionarlo de la mejor forma posible y que sea fácil, es el tema de "la escena" o el escenario.. hay una forma muy sencilla que es la que yo uso en el mini motor que hice, y es simplemente que GINO que se lo curra un montón con los programas para Escritorio jeje... pues que GINO se proponga modificar el map editor, si, ese programa que casi no se usa, pues para esto va a venir que te cagas.. por que se le añade un menú mas para tirar lineas por el map y guardar esta info en los propios CPOINT del map y ya tienes un escenario vectorizado, esto hay que hacerlo a mano siempre en cualquier lenguaje.. así que no hay llantos que valgan.. esto es así, yo creo que si os ponéis a montar una modificación del map editor para poder trazar lineas y vectorizar lo que serán las nuevas "durezas" ya está todo listo para dar el primer paso.
Que os parece esta idea?
En realidad todo debería reducirse a integrar unas pocas variables mas a modo LOCAL en los process, y simplemente delegar todo el enjambre de matemáticas a la box2D que para eso está.
Que el termino FPS es un poco contrario al tema que hablamos.. pues si, y que? si en realidad es tan sencillo como tener esto como un IMPERATIVO antes de hacer nada:
La box2D ha de correr en un thread a parte, nunca debe pretender sincronizarse con los procesos y el framerate.. esto es un completo error muy grave, la cosa no funciona así.
La librería de física debe correr en un thread independiente para poder desarrollar su delta_time correctamente, que supone esto para el core de gemix? simple..
Yo creo que una buena secuencia a seguir sería esta:
1º El core se encarga de hacer todo EXACTAMENTE IGUAL QUE COMO LO HACE AHORA.
2º La box2D corre de forma independiente al core, la única forma de que desde un process el programador pueda manipular los datos de un process con este nuevo sistema es mediante un set de funciones SETTERS como estas:
// para mover a los process:
phisics_add_vx( float velocity );
physics_add_vy( float velocity );
physics_add_velocity( float velocity, float angle );
Y poco mas...
Entonces que pasa.. que el programador solo podrá "FPS" veces por segundo manipular los datos internos de la box2D sobre ese objeto, vale.. y que? esto es como lo hacemos ahora.. Gemix no tiene ni Div tenía TimeSteep.. esto es cosa de la lib de física que tiene que correr a su rollo de forma independiente.
Vamos.. yo creo que esto sería empezar con buen pié sin desmontar nada de lo que hay ahora mismo
