Diario de desarrollo

[josebita]

Bueno, algunas cosas que he ido haciendo últimamente:

• mod_theora vuelve a sonar, pero esta vez mediante OpenAL. Cuando el sonido estaba basado en SDL_mixer, se podía reproducir el audio de un vídeo o todo lo demás, pero no ambas cosas a la vez.
  La limitación de sólo poder reproducir un vídeo sigue ahí, pero debería ser sencilla de eliminar ahora.
• He actualizado el proyecto para iOS, de forma que ahora mismo hay una versión -al menos mínimamente- funcional de PixTudio para iOS. No la he probado en profundidad y la limitación de no poder subir juegos a la App Store sigue ahí, pero algo es algo.
• He trabajado en separar el interfaz de depurado (la mod_debug) del renderizado. La idea es que la consola de debug funcione en un IDE, en lugar de en la propia consola del juego. Creo que será muy útil para depurar código que esté corriendo en dispositivos móviles y me ahorro tener que arreglar el código de dibujado a pantalla, que funciona a una densidad de píxeles que no funciona.
• Algunas cosas más que no me acuerdo.

[JaViS]

Bueno, algunas cosas que he ido haciendo últimamente:

• mod_theora vuelve a sonar, pero esta vez mediante OpenAL. Cuando el sonido estaba basado en SDL_mixer, se podía reproducir el audio de un vídeo o todo lo demás, pero no ambas cosas a la vez.
  La limitación de sólo poder reproducir un vídeo sigue ahí, pero debería ser sencilla de eliminar ahora.
• He actualizado el proyecto para iOS, de forma que ahora mismo hay una versión -al menos mínimamente- funcional de PixTudio para iOS. No la he probado en profundidad y la limitación de no poder subir juegos a la App Store sigue ahí, pero algo es algo.
• He trabajado en separar el interfaz de depurado (la mod_debug) del renderizado. La idea es que la consola de debug funcione en un IDE, en lugar de en la propia consola del juego. Creo que será muy útil para depurar código que esté corriendo en dispositivos móviles y me ahorro tener que arreglar el código de dibujado a pantalla, que funciona a una densidad de píxeles que no funciona.
• Algunas cosas más que no me acuerdo.

Muy bueno! Gracias por el update!

Enviado desde mi Nexus 7 mediante Tapatalk

[l1nk3rn3l]

excelente los nuevos aportes...


tenemos una duda...


mirando g_video.c (linea 277)

creo que no es necesario estar destruyendo la ventana y el renderizador cada vez que llamamos a set_mode

eso crearia memory leaks y haria mas inestable el juego



1. solo se crea un solo renderizador y una sola ventana..(al iniciar el motor)
2. sdl_renderer no contiene atributos de dimension o medidas y demas por lo tanto para que destruirlo?
3. la ventana contiene esos atributos por lo tanto cada vez que cambia el modo cambiar los atributos de la ventana sin destruirla


SDL_SetWindowSize(Window, ScreenSizeX, ScreenSizeY);

y el clasico para modificar el borde

SDL_SetWindowBordered(SDL_Window* window, SDL_bool bordered)

las demas funciones SET para modificar la ventana

https://wiki.libsdl.org/CategoryVideo

internamente sdl2 tiene vinculado el renderer por lo tanto se modifica la ventana === se modifica el renderer automaticamente


para la creacion del renderer siempre se crearia a la primera con los atributos
mas usados   SDL_RENDERER_ACCELERATED

asi que en resumen se crearia la ventana y el renderer una sola vez en la funcion setmode indicando con un flag que ya se inicializo(inclusive si el usuario carga un fpg antes del setmode no pasaria nada que es el comportamiento normal de bennu
cargar el setmode/gr_init al inicio del libvideo--module_initialize

y cada vez que el juego llame al setmode solo se actualizaria la ventana con los nuevos atributos sin destruirla


-se ganaria en velocidad del juego(ya que sdl2 destruye todas las texturas asociadas al renderer con la lentitud que eso supone cargar y descargar texturas en un juego)
-no habrian crash en el juego porque no habrian memory leaks
-no aparecerian errores en pixtudio de textura no valida


hemos estado ocupados ya te echamos una mano....  y te pasamos el g_video.c    con el fix

[josebita]

Creo que tienes razón, sí.
Lo miro y trato de implementarlo.

Mil gracias.

excelente los nuevos aportes...


tenemos una duda...


mirando g_video.c (linea 277)

creo que no es necesario estar destruyendo la ventana y el renderizador cada vez que llamamos a set_mode

eso crearia memory leaks y haria mas inestable el juego



1. solo se crea un solo renderizador y una sola ventana..(al iniciar el motor)
2. sdl_renderer no contiene atributos de dimension o medidas y demas por lo tanto para que destruirlo?
3. la ventana contiene esos atributos por lo tanto cada vez que cambia el modo cambiar los atributos de la ventana sin destruirla


SDL_SetWindowSize(Window, ScreenSizeX, ScreenSizeY);

y el clasico para modificar el borde

SDL_SetWindowBordered(SDL_Window* window, SDL_bool bordered)

las demas funciones SET para modificar la ventana

https://wiki.libsdl.org/CategoryVideo

internamente sdl2 tiene vinculado el renderer por lo tanto se modifica la ventana === se modifica el renderer automaticamente


para la creacion del renderer siempre se crearia a la primera con los atributos
mas usados   SDL_RENDERER_ACCELERATED

asi que en resumen se crearia la ventana y el renderer una sola vez en la funcion setmode indicando con un flag que ya se inicializo(inclusive si el usuario carga un fpg antes del setmode no pasaria nada que es el comportamiento normal de bennu
cargar el setmode/gr_init al inicio del libvideo--module_initialize

y cada vez que el juego llame al setmode solo se actualizaria la ventana con los nuevos atributos sin destruirla


-se ganaria en velocidad del juego(ya que sdl2 destruye todas las texturas asociadas al renderer con la lentitud que eso supone cargar y descargar texturas en un juego)
-no habrian crash en el juego porque no habrian memory leaks
-no aparecerian errores en pixtudio de textura no valida


hemos estado ocupados ya te echamos una mano....  y te pasamos el g_video.c    con el fix

[josebita]

* El commit bb16c71 incluye los cambios que comentan, l1nk3rn3l, así como algunos más. Si notáis algo raro en el comportamiento, por favor avisad.
* He aprovechado para eliminar el parámetro de profundidad de color del set_mode, dado que el único modo soportado es el de 32 bits.
* Además he añadido un par de funciones a la mod_wm para activar y desactivar el salvapantallas.
* He eliminado la mod_blendop de la compilación por defecto, dado que no funciona.
* He añadido una función llamada map_colormod_set que hace las veces de blendop_tint: aplica un factor de escala a la forma en que se muestran los colores de un gráfico en particular.
* Necesito una documentación...

excelente los nuevos aportes...


tenemos una duda...


mirando g_video.c (linea 277)

creo que no es necesario estar destruyendo la ventana y el renderizador cada vez que llamamos a set_mode

eso crearia memory leaks y haria mas inestable el juego



1. solo se crea un solo renderizador y una sola ventana..(al iniciar el motor)
2. sdl_renderer no contiene atributos de dimension o medidas y demas por lo tanto para que destruirlo?
3. la ventana contiene esos atributos por lo tanto cada vez que cambia el modo cambiar los atributos de la ventana sin destruirla


SDL_SetWindowSize(Window, ScreenSizeX, ScreenSizeY);

y el clasico para modificar el borde

SDL_SetWindowBordered(SDL_Window* window, SDL_bool bordered)

las demas funciones SET para modificar la ventana

https://wiki.libsdl.org/CategoryVideo

internamente sdl2 tiene vinculado el renderer por lo tanto se modifica la ventana === se modifica el renderer automaticamente


para la creacion del renderer siempre se crearia a la primera con los atributos
mas usados   SDL_RENDERER_ACCELERATED

asi que en resumen se crearia la ventana y el renderer una sola vez en la funcion setmode indicando con un flag que ya se inicializo(inclusive si el usuario carga un fpg antes del setmode no pasaria nada que es el comportamiento normal de bennu
cargar el setmode/gr_init al inicio del libvideo--module_initialize

y cada vez que el juego llame al setmode solo se actualizaria la ventana con los nuevos atributos sin destruirla


-se ganaria en velocidad del juego(ya que sdl2 destruye todas las texturas asociadas al renderer con la lentitud que eso supone cargar y descargar texturas en un juego)
-no habrian crash en el juego porque no habrian memory leaks
-no aparecerian errores en pixtudio de textura no valida


hemos estado ocupados ya te echamos una mano....  y te pasamos el g_video.c    con el fix

[JaViS]

* El commit bb16c71 incluye los cambios que comentan, l1nk3rn3l, así como algunos más. Si notáis algo raro en el comportamiento, por favor avisad.
* He aprovechado para eliminar el parámetro de profundidad de color del set_mode, dado que el único modo soportado es el de 32 bits.
* Además he añadido un par de funciones a la mod_wm para activar y desactivar el salvapantallas.
* He eliminado la mod_blendop de la compilación por defecto, dado que no funciona.
* He añadido una función llamada map_colormod_set que hace las veces de blendop_tint: aplica un factor de escala a la forma en que se muestran los colores de un gráfico en particular.
* Necesito una documentación...

excelente los nuevos aportes...


tenemos una duda...


mirando g_video.c (linea 277)

creo que no es necesario estar destruyendo la ventana y el renderizador cada vez que llamamos a set_mode

eso crearia memory leaks y haria mas inestable el juego



1. solo se crea un solo renderizador y una sola ventana..(al iniciar el motor)
2. sdl_renderer no contiene atributos de dimension o medidas y demas por lo tanto para que destruirlo?
3. la ventana contiene esos atributos por lo tanto cada vez que cambia el modo cambiar los atributos de la ventana sin destruirla


SDL_SetWindowSize(Window, ScreenSizeX, ScreenSizeY);

y el clasico para modificar el borde

SDL_SetWindowBordered(SDL_Window* window, SDL_bool bordered)

las demas funciones SET para modificar la ventana

https://wiki.libsdl.org/CategoryVideo

internamente sdl2 tiene vinculado el renderer por lo tanto se modifica la ventana === se modifica el renderer automaticamente


para la creacion del renderer siempre se crearia a la primera con los atributos
mas usados   SDL_RENDERER_ACCELERATED

asi que en resumen se crearia la ventana y el renderer una sola vez en la funcion setmode indicando con un flag que ya se inicializo(inclusive si el usuario carga un fpg antes del setmode no pasaria nada que es el comportamiento normal de bennu
cargar el setmode/gr_init al inicio del libvideo--module_initialize

y cada vez que el juego llame al setmode solo se actualizaria la ventana con los nuevos atributos sin destruirla


-se ganaria en velocidad del juego(ya que sdl2 destruye todas las texturas asociadas al renderer con la lentitud que eso supone cargar y descargar texturas en un juego)
-no habrian crash en el juego porque no habrian memory leaks
-no aparecerian errores en pixtudio de textura no valida


hemos estado ocupados ya te echamos una mano....  y te pasamos el g_video.c    con el fix

Yo uso mucho el blendop para hacer gráficos "destellar" y otros efectos bastante comunes en los juegos , planeas algún reemplazo?

Enviado desde mi Nexus 7 mediante Tapatalk

[l1nk3rn3l]

excelente avance...


en modo sugerencia seria incluir .........   1 fuente de 32bits .....        por defecto usando la herramienta bin2c o bin2h

para que se escriban textos como el normal bennu  .. es una sugerencia


si podemos colaborarte de alguna forma, estamos disponibles

[josebita]

Yo uso mucho el blendop para hacer gráficos "destellar" y otros efectos bastante comunes en los juegos , planeas algún reemplazo?

Enviado desde mi Nexus 7 mediante Tapatalk

De momento la he quitado de la compilación por defecto dado que no funciona. Mi intención es tener algo similar, pero SDL no permite hacerlo por GPU...
Voy a mirarlo pero, según la wiki, los blendops no funcionan en 32bits. Si hay suerte y la información de la wiki está desactualizada, puede que conseguir que funcione sea fácil, pero si no, pues llevará más tiempo...
[Edito] Pues no, mira, los blendops no están soportados en 32bits, así que no hay solución inmediata.

excelente avance...


en modo sugerencia seria incluir .........   1 fuente de 32bits .....        por defecto usando la herramienta bin2c o bin2h

para que se escriban textos como el normal bennu  .. es una sugerencia


si podemos colaborarte de alguna forma, estamos disponibles

Sería lo suyo, sí. Si tenéis ganas de poneros a ello y me podéis mandar un parche, os lo agradecería.
De todas formas, mi intención es añadir soporte nativo para fuentes TTF mediante algo como ésto (que es muy ligero) o quizás SDL_ttf (que es más completo).

[josebita]

Por teneros un poco al día:

• Estoy trabajando en sacar el código de debugging fuera de la mod_debug. La idea es que la librería acepte comandos por red desde un debugger externo. El commit f963366 ya admite comandos externos, pero de momento está todo muy cogido por los pelos. En el directorio tools/debug_server/server.py hay una primera implementación de un servidor de debugging en Python. Ya digo que esto está lejos de estar terminado, pero empieza a funcionar.
• El commit 42f1b15 habilita la compilación en modo x86_64 de pxtb (el compilador) porque he comprobado que produce los mismos DCBs que el compilador i386.
• A ver si esta tarde habilito de nuevo la compilación de la mod_effects por defecto, que la tengo deshabilitada injustamente a la pobre.
• Tengo pensado cambiar la librería de expresiones regulares que está por debajo de mod_regex a TRE, que tiene licencia tipo BSD. Si todo va bien, no se debería notar nada al usar la mod_regex.

[josebita]

Por cierto, Javis, lo que sí se soporta es el additive blending, además del alpha blending normal.

[josebita]

Ya que estaba mirando cosas, me he puesto con la fuente del sistema, que buena falta le hacía.
El commit 3c07cd5 arregla el problema con la fuente del sistema, que ya se vuelve a poder utilizar con normalidad.

[JaViS]

Por cierto, Javis, lo que sí se soporta es el additive blending, además del alpha blending normal.

Muy bueno

Enviado desde mi Nexus 6 mediante Tapatalk

[l1nk3rn3l]

excelentes noticias...

[josebita]

Cosas que he hecho hoy:
* El commit e4eeabf añade un ejemplo de cómo se muestran los cuatro tipos de blending soportados por PixTudio: B_NOCOLORKEY, B_ALPHA (alpha blending), B_ABLEND (additive blending) y B_MBLEND (module blending: blending como producto de los colores). El nuevo modo (B_MBLEND) no está soportado para las funciones xput y demás, sólo para mostrado en pantalla (aunque acabaré añadiendo soporte para esas funciones en algún momento).
Tenéis un vídeo con el funcionamiento de los distintos modos de funcionamiento aquí:
https://vimeo.com/145459848
* El commit ea0f7ff añade soporte para vídeos cuyo audio es mono (un único canal), además de vídeo estereo y mejora el manejo de buffer underruns en el audio.
* Me he dado cuenta de un pequeño "bug" en la fuente del sistema: el fondo de la fuente es negro, cuando debería ser transparente. Dado que la fuente del sistema es ahora de 32 bits, igual intento buscar alguna otra fuente monoespaciada mona.

[josebita]

Venga, el commit 5b75111 completa la transición a la librería de expresiones regulares TRE. Es importante porque la anterior implementación tenía licencia GPL, lo cual no está permitido si quiero volver a dar soporte para iOS.
Hace algunas cosas chulas más que la anterior librería (permite hacer búsquedas aproximadas, además de búsquedas exactas). De momento esa funcionalidad no se puede usar desde PixTudio, pero todo llegará.

He probado la librería con los ejemplos de la wiki y parece funcionar bien, pero seguro que me dejo algo por el camino. He subido algún ejemplito un poco más completo en el git.
Lo que sí he cambiado es el comportamiento de regex_replace: la wiki dice que "\0 - \9 escape sequences are accepted in the replacement". Yo no hago eso. Si queréis hacer algo similar, debéis hacer mediante expresión regular.

Para un uso simple, podéis hacer, símplemente:

Código: [Seleccionar]

regex_replace("-", "Queso-Jamón", " y ");