Avances sobre el desarrollo de las nuevas versiones de Gemix

[SimulatorOne]

18 erkos, esta bien?

Tienes suerte que me cambie de sistema android por otro, ya que la oficial de sony xpiera sp, máximo la 4.3

Ahora tengo el 4.4.4 con una custom ROM de los Cyanogenmod 11.0, por el momento lo veo estable... Hasta he podido jugar al Pokemon GO, tan de moda actualmente.

Tengo pensado liberar el bootloader, para cambiar de kernel, y flashear la ultima Cyanogenmod 13, aquí es necesario liberar el móvil al 100%, así podría usar un android 6.0.1 ...

[erkosone]

Hola gente! alguna novedad con gemix para android?

[CicTec]

Hola erkos,

En estos dias he estado con algo de trabajo y no he podido dedicar mucho a Gemix, tengo pendiente reactivar otra lib externa como pedido, arreglar 2-3 bugs para sacar la nueva beta y despues podre mirar el tema de Android con la ultima SDL.

[erkosone]

Gracias por la info!

[CicTec]

De nada.

[CicTec]

Buenas,

Despues de un tiempo sin news voy a anunciar las principales novedades, en luagar de sacar un update, habra una version nueva con cosas que tenia hecho hace un tiempo:
- Se han arreglados todos los bugs reportados y varios mas.

- Ahora se soportan datos INT a 64bits con y sin signo.

- Ahora se pueden generar programas nativos a 64bits, por ende habra 2 versiones del core + modules, 1 para generar programas a 32bits nativos y otro para generar programas a 64bits nativos.

- De momento parece que hay una baja de performance en el rendering en versiones a 64bits, con lo cual los programas a 32bits siguen con rendimiento grafico mejor, todavia la ejecucion de codigo con datos INT a 64bits llega puede llegar hasta mas del double, mirare el tema del rendering despues de la salida de la beta, la actual velocidad es mas que suficiente.

- El tipo INT ahora es dependiende de la version usada, esto indica que puede ser 32 o 64bit dependiendo de la version del compilador usado, esto va a requerir algunas modificas en estructuras/ficheros guardados con datos INT a la hora de poder funcionar en sistema a 64bits correctamente, todavia habra tipo INT32 que sera fijo para ambas las architecturas.

- Habra un ligero cambio en la opcion de compilacion para el audio, el sistema no hara mas distincion entre LEGACY y MODERN, sino en el tipo de lib usada, esto permite tener un sistema generico para poder tener otras libs con motores audio diferentes en la misma carpeta sin entrar en conflicto de compilacion como pasaba con la beta actual.

Utilizare este fin de semana para testar mayormente el sistema, lunes actualizare todas las libs necesarias para volver a mirar el porting a Android.

De momento es todo.

Un Saludo.
-

[shao]

Pues por mí es estupendo que vuelvas al lío.

¿Qué pasa si no lo de Android continúa atascado?.
¿Qué harías entonces?.
Yo recomiendo lo de siempre y ya no lo volveré a decir más:
Si no puedes continuar con Android por cualquier razón y tienes que esperar, entonces yo aconsejaría ponerse con esa nueva librería de físicas, ponerse con una librería para Steam, me refiero a poder usar los logros de steam y todas las características, o con la librería de Red estilo gemix.
Y esto no lo digo por mi, yo de momento no voy a usarlas, lo digo por que creo que seria atractivo disponer de ellas para cualquier usuario que llega.

Hay algunas sugerencias que recuerdo que hice pero no creo que las hayas introducido, espero que al menos las tengas anotadas.

Sobre este parrafo:

- El tipo INT ahora es dependiende de la version usada, esto indica que puede ser 32 o 64bit dependiendo de la version del compilador usado, esto va a requerir algunas modificas en estructuras/ficheros guardados con datos INT a la hora de poder funcionar en sistema a 64bits correctamente, todavia habra tipo INT32 que sera fijo para ambas las architecturas.

No entiendo bien... si yo uso la versión 32 bits, ¿tendré que hacer esos cambios?.

[CicTec]

Pues por mí es estupendo que vuelvas al lío.

¿Qué pasa si no lo de Android continúa atascado?.
¿Qué harías entonces?.

Realmente no hay razon porque no deba funcionar, la version 7.0 me sigue corriendo en el emulador/device, se creara algun conflicto/fallo con la version SDL2 actual, tengo que actualizarla a la ultima, si sigue fallando montare un ejemplo y lo reportare para encontrar la causa y poder seguir con el porting.

Habria muchas cosas por hacer, todavia seguire intentando con el Android para conseguirlo, el porting es importante.

Yo recomiendo lo de siempre y ya no lo volveré a decir más:
Si no puedes continuar con Android por cualquier razón y tienes que esperar, entonces yo aconsejaría ponerse con esa nueva librería de físicas, ponerse con una librería para Steam, me refiero a poder usar los logros de steam y todas las características, o con la librería de Red estilo gemix.
Y esto no lo digo por mi, yo de momento no voy a usarlas, lo digo por que creo que seria atractivo disponer de ellas para cualquier usuario que llega.

Los mire hace tiempo y estaba empezando a hacer algo, pero luego lo deje para hacer otros temas.

Hay algunas sugerencias que recuerdo que hice pero no creo que las hayas introducido, espero que al menos las tengas anotadas.

Tengo anotado mucho, y ahora mismo no recuerdo cual son las ultimas sugerencias que hiciste, indicame el thread, quizas la implemente.

Sobre este parrafo:

- El tipo INT ahora es dependiende de la version usada, esto indica que puede ser 32 o 64bit dependiendo de la version del compilador usado, esto va a requerir algunas modificas en estructuras/ficheros guardados con datos INT a la hora de poder funcionar en sistema a 64bits correctamente, todavia habra tipo INT32 que sera fijo para ambas las architecturas.

No entiendo bien... si yo uso la versión 32 bits, ¿tendré que hacer esos cambios?.

Imagina de tener en tu codigo algo asi:

Source Code (Gemix) [ Download ] [ Hide ]

Source Code (Gemix) [ Download ] [ Show ]

• struct game_info
•   lives;
•   enemies;
•   level;
• end
•  

Esta estructura tiene miembros INT, en la version DIV y actual de Gemix estos datos tienen tamaño 32bits, en la version del compilador a 64bits, tienen tamaño de 64bits.
Si la estructura es utilizada para ser guardada con FOPEN o SAVE no puede ser recuperada en ambas versiones a 32 y 64bits, si la guardas con tu programa compilado a 32bits y pruebas a cargarla con el mismo programa a 64bits, faltan bytes, viceversa habra bytes sobrantes y la carga dara error o procurara datos anomalos.
Para que el programa guarde en forma cross-platform entre las architecturas el tamaño debe ser fijo, en este caso como se utilizan datos INT a 32bits, habra que modificar el codigo asi:

Source Code (Gemix) [ Download ] [ Hide ]

Source Code (Gemix) [ Download ] [ Show ]

• struct game_info
•   int32 lives;
•   int32 enemies;
•   int32 level;
• end
•  

De esta forma, el fichero sera guardado/recuperado correctamente da los programas 32 y 64bits

[shao]

Entonces en la nueva beta tendría que especificar el tipo de dato en todas mis declaraciones.

¿Has añadido alguna opción para el compilador que indique el tipo de dato por defecto?.
Así no habría que hacer esta modificación al código y se podría seguir declarando un dato usando solamente su nombre sin especificar si es 32 o 64 ya que el compilador lo hará automáticamente con esta opción.

Si no la has añadido, ¿qué te parece añadirla?.
¿O estamos hablando de que ahora existirán dos compiladores para descargar?, 1 a 32 y otro a 64.
En ese caso yo usaría el de 32, así no tendría que modificar nada.
Pero creo que no estamos hablando de eso, creo que solo habrá un compilador y habrá que especificar si el dato declarado es a 32 o 64.

[CicTec]

Entonces en la nueva beta tendría que especificar el tipo de dato en todas mis declaraciones.

No, solo en las declaraciones de datos que necesitan ser guardados/recuperados con FOPEN, LOAD/SAVE y que tienen datos INT deben ser modificadas, si tus datos no van a ser guardados no hay que tocar nada.

¿Has añadido alguna opción para el compilador que indique el tipo de dato por defecto?.
Así no habría que hacer esta modificación al código y se podría seguir declarando un dato usando solamente su nombre sin especificar si es 32 o 64 ya que el compilador lo hará automáticamente con esta opción.

Si no la has añadido, ¿qué te parece añadirla?.

No he añadido niguna opcion y no se puede, INT es usado en retrocompatibilidad DIV para guardar ID de procesos, en Gemix un ID de una instancia es un indiricio de memoria de la maquina, en maquinas 32bits es 32bits y en maquinas 64bits es 64bits, por eso cambia el tamaño de INT y se requiere nuevo tipo de dato fijo para INT 32bits.

¿O estamos hablando de que ahora existirán dos compiladores para descargar?, 1 a 32 y otro a 64.
En ese caso yo usaría el de 32, así no tendría que modificar nada.

Como explique en el primer mensaje habra 2 compiladores, y el pack sera unico incluyendo los 2.

Pero creo que no estamos hablando de eso, creo que solo habrá un compilador y habrá que especificar si el dato declarado es a 32 o 64.

Como ya dicho, son 2 compiladores en un solo pack, si vas a usar siempre y solo el compilador 32bits no tendras que preocuparte de modificar niguna declaracion, viceversa si decides de compilar tus programas para 64bits nativos tendras que hacer las modificaciones oportunas para los datos que necesitan ser guardados/recuperados.