Gemix Studio

Hola abro este hilo para no ensuciar el de Amaka y DivGO que era donde estaba hablando sobre esto

- CicTec me comentabas que java no es un lenguaje optimo para esto, bueno.. ya lo se XD.. lo que pasa es que java es muy bueno para otras muchas cosas y cuando hacen falta pocos procesos puedes hacer una barbaridad de cosas interesantes en ambitos industriales, la cosa es que la folosofia Div es una pasada, pero muy pesada y compleja de optimizar.

No existe nada parecido simplemente por que Div usa un tipo de serialización de datos muy intenso y como bien dices hay que programarlo a muy bajo nivel para que rinda decentemente.
La verdad es que el trabajo metido en el gestor de Gemix es muy bueno eso hay que reconocerlo, y como lenguaje para juegos tiene mucho potencial. pero en cuanto te sales un poco de los juegos ya se queda corto.

Claro, Gemix está pensado para juegos, esto no es una limitación por que es para lo que es, pero yo intento hacer algo similar para entornos diferentes a los juegos. y la verdad es que siempre saco un "GUAU!!" la gente cuando ve una aplicación de escritorio para trabajar con toques reconocibles de los videojuegos se queda agradablemente sorprendida XD..

Te enciendo cuando dices que es una perdida de tiempo, pero ten en cuenta que aunque Java no me permite abusar demasiado "permitia.." de los procesos, me da otras muchas cosas.
Y digo permitia por que acabo de descubrir que existen librerías para la serialización de datos a bajo nivel para java que rinden X10 del core de java oficial.. estoy muy sorprendido pero es cierto, estoy probando varias y funcionan muy por encima de la parte de 'Collections' oficial del lenguaje.

Parece tontería pero así haciendo pruebas estoy moviendo 80 procesos a 60FPS.. y realmente tampoco me hace falta mucho mas.
Claro que esto me obliga a hacer algunas cosas de forma diferente a como las haría descuidadamente en Gemix por que rinde mas XD.. pero ahun así no es una perdida total de tiempo, está resultando una experiencia muy gratificante

Ahora te entiendo mejor cuando tardas en sacar depende que cosas jeje.. esto no es tan facil como parece jajajajaja.
Un saludo maestro CicTec.

mira así haciendo pruebas..
50 fps mas o menos con 1200 procesos sin hacer operaciones, no es demasiado.. pero algo es algo jeje...

Hola erkos,

Pues que decirte, claramente no era para bajarte de animo, pero mas 15 años de experiencia en programacion con lenguajes de medio/bajo nivel hacen, y mas de 10 años programando DIV-Like.

erkosone wrote:Ahora te entiendo mejor cuando tardas en sacar depende que cosas jeje.. esto no es tan facil como parece jajajajaja.

Jejeje, ya ves, parece tonteria, pero pensar en una implementacion optimal y implementarla requiere muchisimo tiempo.

erkosone wrote:mira así haciendo pruebas..
50 fps mas o menos con 1200 procesos sin hacer operaciones, no es demasiado.. pero algo es algo jeje...

Si, es algo, pero realmente muy bajo, tienes en cuenta que el actual gestor de Gemix, que no es aun rapido cuanto deberia (tengo pensado tecnologias de implementaciones para mejorarlo), saca 10.000 procesos haciendo operaciones a mas de 300 fps, la diferencia ya es muchisima, eso para evidenciar, como el lenguaje da utilizar, segun lo que se debe implementar es fundamental.

Un Saludo.

Alguien de aquí tiene experiencia con la librería de física Box2D?

Estoy implementando el sistema de colisiones al micro engine para juegos en java que estoy haciendo y me surge una duda..
- La Box2D detecta colisiones por eventos de manera que cuando dos cuerpos colisionan se crear un objeto del tipo 'contact' con diversa información sobre la colisión..

Mi idea es basicamente crear una lista dinámica de vectores donde almacenar los pares de ID de cada colisión lanzada por el evento contactStarted(FContact contact), osea mas o menos así:

Al crear un sprite en mi engine se le da un ID que es un numero del tipo INT, sabiendo esto:

1 - Al iniciar un nuevo frame: eliminar la lista de vectores que contienen los ID.
2 - Al detectar una nueva colisión añadir un nuevo vector con los ID de cada body involucrados en la colisión.
3 - Si llamo a la función collision( sprite id1, sprite id2 ).. simplemente recorro la lista dinamica de vectores en busca de una coincidencia entre los ID de los sprite que he pasado como parametros.

Alguien puede asesorarme sobre esta técnica? es la mas correcta? hay alguna otra forma mas eficiente de hacer esto?

Bueno, pues ando estos dias entretenido a tope con un proyecto en java, estoy creando mi propio motor 2D para hacer juegos rapidamente en este lenguaje, no busco nada mas que aprender a crear un pequeño motor para juegos, realmente no voy a invertir demasiado tiempo en el como para que sea algo profesional XD..

La verdad es que ya me he encontrado con varios temas bastante interesantes y que me han hecho romperme la cabeza en busca de la solución, el ultimo ha sido el crear un sistema que simule lo que hace gemix con su VirtualResolution.

En un principio crear algo así parece facil XD.. pero cuando tienes que modificar los eventos nativos del mouse para que traslade de coordenadas reales a virtuales la cosa se pone interesante jajajaja...
Joer que pasada, al final he terminado por crear mi propio mouse y sus eventos.. que odisea..

Esto me está abriendo los ojos y me está haciendo ver realmente el trabajo que hay detrás de algo como Gemix con todo lo que hay detrás que no se ve pero que hay que hacerlo funcionar bien

Esto de virtual resolution es relativamente sencillo, haz un compilador + interprete de DIV-Like y un motor 2D desde 0 via software y por aceleracion hardware (OpenGL, Direct3D, etc...) y ya me contaras....

El concepto de region de Div.. no termino de entenderlo bien, osea, se para que sirve claro, pero no termino de ver como está implementado, supongo que se puede hacer de varias maneras diferentes pero..

Para los que teneis experiencia en esto..

Es buena idea hacerlo así?
- crear un buffer de vídeo del tamaño de la region.
- pintar en el.
- y finalmente volcar este buffer al buffer principal de vídeo.

O hay alguna otra manera mas sencilla y eficiente de hacerlo?

Es que al pensar en lo de pintar en regiones de pantalla no se si será mejor usar alguna otra técnica o esta que comento, que opináis?

erkosone wrote:El concepto de region de Div.. no termino de entenderlo bien, osea, se para que sirve claro, pero no termino de ver como está implementado, supongo que se puede hacer de varias maneras diferentes pero..

Para los que teneis experiencia en esto..

Es buena idea hacerlo así?
- crear un buffer de vídeo del tamaño de la region.
- pintar en el.
- y finalmente volcar este buffer al buffer principal de vídeo.

O hay alguna otra manera mas sencilla y eficiente de hacerlo?

Es que al pensar en lo de pintar en regiones de pantalla no se si será mejor usar alguna otra técnica o esta que comento, que opináis?

La forma que dices es la que uso yo en Div GO, es lo que me daba mejores resultados. Por cada región un buffer del tamaño que se declara con define_region() y después lo vuelco en el buffer final. Para el reescalado (resolución virtual) de pantalla yo lo aplico al dibujar solo en el buffer final, es más óptimo que aplicarlo de forma independiente a cada región.

Un saludo.

Gracias por la info Amaka, voy a mirar de implementar las regiones al motorcillo que estoy haciendo jeje..

Eso de volcar en un buffer y luego en el final es muy ineficiente, razonadlo mas porque la solucion es mas sencilla de eso.