map_get_pixel, alternativas.

[shao]

Hola, mas que nada por curiosidad, hay alternativas a map_get_pixel?, los juegos que se mueven por mapas irregulares de otros motores tambien usan este metodo?.
Se lleva usando desde div2, no hay nada nuevo?.

[kozka]

hombre por decir cosas asi lo que se me ocurre vamos XD:

1.puedes usar collision o overloap . --pero es muy lento

2.puedes usar un mapa de tiles,o variables a las que preguntar si ahi ahi un solido. --tiene poca resolucion a no ser que lo compliques.

3.el metodo que intenta terminar erkosone mirando si lineas ,circulos colisionan , --necesitas hacer polilineas y hacer mapas muy irregulares es costosom, y hacer este sistema es complejo.

4.existe otro metodo al 3 rodeando a un graph con multiples vertices que son los que usas(nose muy bien como va este metodo pero he leido algo por ahi.

no se me ocurren mas nose.

[shao]

Si pero me refiero a nuevas funciones, no que tengas que construirlas tu como el metodo de erkosone.

[erkosone]

no hay que construir nada, por poner un ejemplo con la librería libGDX tienes una clase sprite, le dices que compruebe colisión con todo lo demás como si fuera un polígono y fuera.. lo hace todo solo, simplemente compruebas si hay colisión como en gemix y listo.

Lo de map_get_pixel está antiguado desde hace ya años jeje.

[shao]

Y por que no se añade un nuevo metodo como ese que dices para modernizar un poco esto del map_get_pixel?.

[kozka]

afer el mat get pixel es una funcion, esa funcion ayuda a hacer un sistema de fisicas con el terreno basante resulton y con mucha performance
lo que a dicho erkosone es un sistema de fisicas integrada en el lenguaje que no existe, no es solo una funcion son tropecientas mil.
lo que si que puedes hacer es usar map get pixel mejor .y crearte una funcion que haga todos los procesos de fisicas ahi , asi solo tienes que llamarla en el proceso que quieras usarlam vamos es como lo hara
la mayoria pero por comentarte.

[GINO]

Desde mio punto de vista, todo lo que sea trabajar con píxeles a nivel de colisiones (collision y durezas vía map_get_pixel) es un error. Es fácil de usar, pero yo creo que el mejor de los sistemas es usar formas geométricas tanto para colisiones como para durezas (que al final vendría a ser lo mismo). Directamente no se puede usar nada de eso porque no está implementado de serie, habría que hacer un set de funciones que lo implementen.
La cosa sería tener un gráfico al que le puedes asociar un set de formas geométricas. Los píxeles, osea la imagen en si, solo sería una skin. Para colisiones se usaría la geometría e incluso se podría usar la misma para usar con box2D u otro sistema.

[CicTec]

Desde mio punto de vista, todo lo que sea trabajar con píxeles a nivel de colisiones (collision y durezas vía map_get_pixel) es un error. Es fácil de usar, pero yo creo que el mejor de los sistemas es usar formas geométricas tanto para colisiones como para durezas (que al final vendría a ser lo mismo). Directamente no se puede usar nada de eso porque no está implementado de serie, habría que hacer un set de funciones que lo implementen.
La cosa sería tener un gráfico al que le puedes asociar un set de formas geométricas. Los píxeles, osea la imagen en si, solo sería una skin. Para colisiones se usaría la geometría e incluso se podría usar la misma para usar con box2D u otro sistema.

Yo lo veo logico y bien, propongo a que prepares (cuanto tienes tiempo) un documiento sobre este posible sistema y asi lo vamos a discutir y implementar para el nuevo motor 2D (y en la medida de lo posible en el viejo soft si compensa).

[GINO]

Esto no tiene nada que ver con un motor 2D. Simplemente tenemos grupos de formas geométricas, que pueden estar asociadas a un gráfico, para lo cual es mejor hacer un formato nuevo de gráfico, más que nada para que se puedan organizar mejor las partes o "secciones" dentro del mismo.
Luego se hace una rutina de colisión entre 2 grupos de formas que lo que hace es mirar si interseccionan las formas.
El problema con gemix es que tal y como está si añades algo y más tarde se te ocurre añadir algo relacionado vas a tener que reescribir todo seguramente, es demasiado laborioso. Hay demasiadas cosas que están fuertemente atadas unas a otras sin sentido (regiones y puntos de control por ejemplo) lo cual impide hacer cosas realmente versátiles. Digo lo de los puntos porque realmente es lo mismo que esto de la geometría.

• Lo ideal es tener un formato de archivo altamente versátil al que se le puedan añadir cosas, todas las que quieras sin tener que andar cambiando la especificación a cada paso (formato basado en chuncks o mismamente un zip en el que cada chunck sería un "archivo"). Para esto lo ideal es tener un formato de recursos propio o basado en zip (recomiendo el último, permite compresión y encriptado a nivel de entrada de serie aparte). Un sistema en gemix que permita abrir un archivo de esos y tratar cada entrada como un archivo normal (por ejemplo: cargar un fpg del archivo zip con un load_fpg). Esto de por si ya proporciona una base bastante buena y versátil para organizar contenidos.
• Con esto podemos especificar el nuevo formato map por ejemplo como un zip en el que hay un archivo en el directorio raíz que se llame "format" y que dentro tiene unos bytes que representan el formato de recurso y la versión, y que se usa para saber qué contiene el archivo zip o si gemix puede interpretarlo como uno de sus recursos (imagen, fpg, etc.). Siguiendo con el formato imagen, directamente se podría meter en el zip un archivo de imagen con el nombre "image" y que realmente fuese uno de los formatos de gemix (.map, .bmp, .png, etc.). Esto permite directamente que el usuario pueda crear el archivo de imagen gemix sin tener que andar con conversiones absurdas (directamente lo arrastra en el programa archivador).
  Al margen de eso el usuario puede incluso meter en el archivo zip cualquier otro archivo que le de la gana (un txt con información por ejemplo). Asimismo el formato podrá ser expandido con nuevas "secciones" en el futuro, según necesidades.
• Por otro lado, crear un sistema de geometría con las funciones más típicas (intersecciones, etc.). El sistema puede cargar archivos que especifiquen tal geometría. Dicho archivo podría ser una serie de datos binarios o lo que es mejor, en formato texto. Siendo texto es fácilmente modificable.
• Ese archivo de geometría puede ser abierto por un usuario desde gemix o desde fuera.
• Gemix proporcionaría un sistema para manipular geometría, por ejemplo ver si hay colisiones, etc. Todo el tema de los puntos de control entraría aquí realmente. La geometría solo sería cargada a petición del usuario, ya que si no la usa no tiene sentido que ocupe memoria. La geometría podría cargarse desde cualquier sitio. Por ejemplo, load_geometry("c:/xxx.geo"). Eso quiere decir que el sistema de geometría es totalmente aparte del sistema de pintado.
• Al tratarse de un "archivo" es fácilmente añadido dentro del zip que tiene la imagen, eliminado, modificado o incluso copiado a otro archivo de imagen.
  El mismo sistema se puede usar para los puntos de control, aunque realmente los puntos de control son una chapuza de DIV hay que decirlo. Lo ideal es que estuviesen contenidos en el archivo de geometría.
• Para cargar el archivo de geometría asociado a la imagen, tan solo hay que cargarlo del archivo zip en vez de directamente de disco.
• Con esto tenemos dos sistemas que sirven para dos cosas diferentes bien separados. Incluso se podría cargar la geometría y asociarla a la box2D u otro sistema. Por poder incluso puede el usuario tener dos archivos de geometría o más diferentes en el zip y que usará en consecuencia según las necesidades.
• Otra aplicación de esto sería un nuevo formato fpg en el que se guardan los gráficos como "archivos" dentro del zip. Asimismo el usuario puede incluir archivos que contengan seguencias de gráficos para especificar animaciones en el propio archivo de fpg.
• Las ventajas son infinitas.

El problema mayor con todas estas cosas que se se pueden ocurrir no es que se ocurran o no o sean más difíciles o fáciles de por si. el problema es que requiere una reescritura de gran parte de gemix mismo. Directamente todo lo que tiene que ver con div internamente. Por ejemplo el sistema de puntos, el sistema de regiones, el sistema de transformaciones geométricas, una infinidad de cosas que funcionan bien si se mantienen simples como en div pero que no hacen más que dar dolores de cabeza si se quieren actualizar a algo mejor o más completo, porque directamente habría que o bien desecharlas y reimplementarlo o hacer una chapuza de parches sobre lo que está, lo cual además de chapucero lleva más tiempo de hacer y es más difícil de mantener.
Por ideas no es, el problema es implementarlo en gemix.

[kozka]

si algo asi estaria bien.

- lo de usar zip para tener los recursos comprimidos y con contraseña bien, quizas poniendo al principio del programa la "llave" open_recursos_key("1234")
y cada vez entres automaticamente meta la contraseña o algo asi.

- respecto al total de archivos propios de gemix yo pienso que harian falta : por dar ideas de lo que podria ser el sistema global.
-Fpg (archivo que sirve para clasificar los graph por grupos)

- Ani (archivo que usa los archivos del fpg relacionado, para describir animaciones secuenciales con esos graficos, dentro estaran varios archicos de animaciones que se pueden cargar desde un process , y seria posible grabar todos los comportamientos tanto de alpha fx etc etc.. ,mas que nada por si se hace
un programa para la edicion de anis.

- Vec se trataria de una forma geometrica que vas adaptando a las diferentes secuencias de ANI, permitiendo si quieres perfilar mas o menos . si es solo un grafico de un ani pues haces un cuadrado o lo que sea y listo.

- Mar_gravada(tipo marioneta). se usan los vec necesarios, para realizar una animacion que se guarda y se puede reproducir exactamente igual.

- Mar_in vivo(tipo marioneta). se usan los vec , como los usa erkosone y en muchos juegos aparece por ejemplo cuando te matan que el cadaber se golpea con todo y tiene un mobimiento por fisicas aceptable y mas cosas.