Bennu Game Development

Quería estrenar la nueva intro de Bennu con un proyecto, así que allí va una beta muy temprana de un módulo para tratamiento de cajas de diálogo móviles, que pueden ir junto con el personaje.

Detalles interesantes:

1) Incluye la intro de Bennu en formato .mpg, con todos los DLL y un .bat para ejecutar libremente.

2) Incluye un personaje que hace uso de una dialog box y puede moverse manteniendo sobre él el diálogo.

3) El 99% del código, incluido variables y comentarios están "in english" para que mis proyectos puedan ser internacionales... Primera vez que lo hago... Siempre he sido de "programar igual que se habla".

Las dialog box son un TYPE con varios valores por defecto, pero configurables en gráfico, fuente, tiempo de muestre, retraso entre líneas de texto, ec.

Le faltan varios detalles:

1) La función que convierte una string a dialog box calculando los saltos de línea.

2) Soportar write_in_map y hacerlo compatible con Bennu 3D ::)

3) Testear, depurar y mejorar todo lo posible...

Todo en 32 bits, la fuente también es posible cargarla en ttf, en la próxima versión incluyo un ejemplo.

DESCARGAR: http://trinit.es/DescargaDirecta/Dialog%20Boxes%200.0.2.zip (http://trinit.es/DescargaDirecta/Dialog%20Boxes%200.0.2.zip) (10Mb)

jojojo ya lo probé :)

karma++ y gracias amigo :)

Umn, no está mal
Pero a mi gusto la intro para ser intro es demasiado larga en tiempo yo tenia en mente una intro tipo la antigua de los juegos 3dfx que servía para que supieras que el juego era 3d pero no era nada pesada y muy rápida.
También no me gusta que me obligen a ver la intro completa, normalmente puedes darle a escape y llegar justo al último frame.
En cuanto al sonido queda bastante bien pero no termina justo cuando termina la intro y sigue un rato habría que ajustarlo.
Además faltarían los sonidos de ambiente, un sonido para el movimiento de las alas de bennu (como un zumbido al aire) y el de caída de las letras a la arena (un golpe seco).

Otra intro para ver a lo que me refiero podría ser la del cálico electrónico.

Veo que al final de 70MB lo has dejado en poco mas de 14,realmente muy bueno,es buena idea lo de los TextBox,ya lo hechare un vistacillo...

Nueva versión de los Dialog Boxes, ahora hay varios procesos que invocan aleatoriamente diálogos para probarlos, usan una ttf, aunque es posible cambiar la fuente desde dialog.prg


He implementado la división de palabras activa, aunque con un algoritmo "casero" que chequea los espacios y salta de línea si detecta espacio más allá del 70% de la cadena.

Veo que transcurrido un tiempo llegan a haber varios writes activos en pantalla (Y fuera de pantalla) y la cosa empieza a parpadear. La próxima mejora consistirá en no hacer write cuando el proceso se encuentre fuera de pantalla, y hacer que sea compatible tanto con C_SCROLL como con C_SCREEN.

También tengo que controlar las z... Quizás me base en write_in_map y map_block_copy para que los textos tengan la misma profundidad que la caja... Sería lo ideal ::)

Para map_block_copy: Creo recordar que las funciones para obtener la anchura y altura de un texto sólo funcionaban en base a la anchura de la fuente por defecto del sistema, ¿Alguien sabe algo al respecto?, lo comprobaré un día de éstos, por ahora la altura y anchura de caracter se da en una constante.

DESCARGAR v0.0.3: http://trinit.es/DescargaDirecta/Dialog%20Boxes%200.0.3.zip (http://trinit.es/DescargaDirecta/Dialog%20Boxes%200.0.3.zip)

Son 5Mb, he omitido la intro de Bennu para testear :P

TEXT_WIDTH (INT fuente, STRING texto)
TEXT_HEIGHT (INT fuente, STRING texto)
Esa es tu solución.

Por lo demás, muy curioso tu ejemplo de los módulos :)

Gracias Drumpi, es que recuerdo que lo probé con unas DLL de hace tiempo y devolvía valores referentes únicamente a la fuente por defecto... Por eso me preocupaba, lo volveré a probar, sería un alivio xD

¡¡¡PROBLEMA!!! :o

He implementado una funcionalidad interesante, ahora los textos de cada linea se imprimen sobre un gráfico usando write_in_map y map_block_copy, ganando mucho en eficiencia ya que no hay que redibujar los textos a cada frame. A groso modo es así:

FROM current_print = 0 TO current_line;
lines [ current_print ] = write_in_map ( dial.font ,
dial.line [ current_print ] , 1 );
map_block_copy ( file , graph , 0 , current_print*dial.font_height + _OFFSET_DEFAULT ,
lines [ current_print ] , 0 , 0 ,
graphic_info ( file , lines [ current_print ] , G_WIDTH ) ,
graphic_info ( file , lines [ current_print ] , G_HEIGHT ) ,
0
);
END

El problema es que map_block_copy recibe un último parámetro para indicarle que ignore el color transparente a la hora de copiar, y al ignorar el color transparente los write que usan fuentes ttf no se imprimen bien, lógicamente.

¿Alguien sabe si hay algún flag (O es fácil de implementar) para map_block_copy que le indique que se quieren ignorar sólamente los colores transparentes en 32 bits? Los TOTALMENTE transparentes me refiero...

Hasta encontrar solución a ello las dialog boxes sólo funcionarán con fnt... :-\

En cualquier caso ahora el rendimiento y el control de profundidad roza la perfección:


Incluso con boxes transparentes:

este problema es por los 32 bits?

tengo que revisar el tema del alpha en los 32 bits... estuve pensando, pero tengo que probarlo y hacerlo...

la cosa se resume asi...

pixel destino (RGBA)

pixel source (RGBA)

la cosa es que cuando se hace un put de un pixel sobre otro, se hace una fusion de un RGB sobre el otro, en base a los ALPHA de cada 1... entonces una vez aplicado, el ALPHA ya deja de tener sentido, puesto que si dejaramos alpha sobre los RGB ya con alpha aplicado entonces hariamos cagadas... el pixel seria en cada operacion mas transparente... incluso en el momento de dibujarlo en pantalla...

asi que la idea seria fusionar ambos RGB en base al menor de los 2 ALPHA y guardar este pixel fusionado con el ALPHA mayor... creo que esa podria ser la solucion al manejo de los 32 bits... pero lo pense muy por encima... quizas no sea lo correcto eso...

por otro lado, veo que los boxes son siempre del mismo tamaño, seria bueno que los crees dinamicamente.

La transparencia puede ser aditiva, sustractiva o simplemente una media de ambas... Podría haber un flag para controlarlo, en map_block_copy ya hay uno, aunque imagino que no es sólo para map_block_copy, el cambio afectaría a todo Bennu.

En el caso que me atañe, copio una fuente ttf (Con alpha) sobre un gráfico. El pixel resultante tiene que mantener el alpha del gráfico en todos los casos, pero dependiendo de los alphas de la fuente debería afectar de alguna forma, por ejemplo:

Se copia un pixel R=255, G=0, B=0, A=30 sobre el gráfico de fondo BLANCO R=255, G=255, B=255, A=255.

El resultado debería ser un pixel R=255, G=255-30, B=255-30...

Lo he comprobado con Gimp y eso es lo que yo deseo, pero harían falta flags porque puede haber muchos otros casos.

En cuanto al tamaño de los boxes, sí, había considerado esa idea, de formarlos por "tiles" o bien usar size_x y size_y, aunque con map_block_copy no es posible ya que afectaría también al texto :P

Gracias por las sugerencias ;D

EDIT: Aquí la versión actual, ahora mismo estoy metiendo una "consola" para que puedas introducir texto por teclado y el guerrero lo hable, usaré PUBLIC y esas cositas lindas.

DESCARGAR: http://trinit.es/DescargaDirecta/Dialog%20Boxes%200.0.4.zip

Oye muy bueno el test.
Por cierto pepáranos una mini aventurilla del pive este pa entretenernos probándolo, algo del estilo una aldea de un rpg, en el que hables con diferentes tios y te den pistas para conseguir una llave y abrir un cofre o una puerta y encontrarte con el final :D.

Estaba pensando en darle algo de jugabilidad, no es mala idea eso que propones, no sería nada complicado, pero tendré que rippear más animaciones de modelos md2 para los NPC xD

Ahora mismo ya es posible introducir textos por teclado y el tío los suelta alegremente, me gusta como está quedando. En cuanto tenga versión con alguna novedad interesante os lo subo.

si, hay que pensar bien el tema del alpha en los 32 bits... obviamente que dependeran de los flags seteados... pero el ejemplo que puse era en el caso del modo normal.

En las pruebas que estas dejando se ve muy bien...animo

Que chulos quedan los transparentes  ;)

En el tema de copiar pixels de 32 bits, si que habría que determinar el modo de trabajo, porque si un map_block_copy mezcla los colores ¿cómo haríamos para que un punto del mapa destino quede con un rgba=(255,0,0,128)? es decir, que se ponga rojo semi-transparente, sin mezclarse con el que había antes.
Al igual, tambien es posible que queramos que un pixel verde opaco (0,255,0,255) se mezcle con el rojo semi-transparente (255,0,0,128), dando un (128,,255,0,255)... o aditovo, o sustractivo... ¿o todo eso ya se hace con flags? (hoy estoy espeso).

Tengo por aqui un borrador de posibles metodos de mezcla, sobre papel.

He llegado a la conclusion de que los R G B se mezclan bien sea por media o bien por media ponderada (Respecto al alpha), tambien que el alpha puede afectar a los RGB de su mapa, que pueden hacerse medias del alpha, que pueden sumarse con limite 255 o bien restarse con limite 0...

Hay muchas formas de hacerlo, pero se hace necesario un flag que indique el metodo.

Por mi parte estoy implementando un map_block_mix ( ) que basado en map_clone y en las funciones de obtencion de color de un pixel hace exactamente lo que necesito. Lo hago como simple prueba, el metodo de mezcla de alphas deberia ser una global o bien un parametro mas, ya que puede hacerse de muchas formas y afectaria al funcionamiento general de Bennu...

Ahora mismo estoy en mi pueblo con wifi "prestado" y de fiesta, pero espero manteneros al corriente. La conclusion es que no es dificil mezclar colores en 32 bits si un flag indica como proceder a ello.

 media no sirve... que pasa si tengo un alpha en el destino de 0, y un alpha de 128 en el source? eso deberia quedar un alpha de 128... no se puede hacer una media de eso... y que tal si tengo un 128 en el target y un 10 el source? tampoco puedo promediar...

como sea, creo que no es tan simple... que pasa si por ejemplo, tenemos un fantasma que le damos un tiro de pintura, el fantasma un alpha de 64 y la pintura tiene un alpha de 255, en este caso el alpha que deberia quedar en la mancha es de 255...

ahora que tal si a ese mismo fantasma le damos un tiro que le volamos parte, y en el fantasma nos quedan un agujero completamente transparente (alpha 0) y algunos bordes de suavizado, que tendrian que dar alphas entre 0 y 64? aca no puede ir el mismo metodo que el anterior..,

yo creo que deberia usar los mismos flags que ya existen... A_BLEND, S_BLEND, NORMAL... etc... y que el alpha tenga en cuenta dichos valores... el problema esta en el normal...

en el primer caso actuaria con un NORMAL... y en segundo deberia usarse un S_BLEND...

estoy hablando muy en el aire, sin mirar el codigo... asi que puede que este diciendo alguna locura...

Quote from: Windgate on October 23, 2009, 10:52:07 PM
¡¡¡PROBLEMA!!! :o

He implementado una funcionalidad interesante, ahora los textos de cada linea se imprimen sobre un gráfico usando write_in_map y map_block_copy, ganando mucho en eficiencia ya que no hay que redibujar los textos a cada frame. A groso modo es así:

Code Select Expand

FROM current_print = 0 TO current_line;
lines [ current_print ] = write_in_map ( dial.font ,
dial.line [ current_print ] , 1 );
map_block_copy ( file , graph , 0 , current_print*dial.font_height + _OFFSET_DEFAULT ,
lines [ current_print ] , 0 , 0 ,
graphic_info ( file , lines [ current_print ] , G_WIDTH ) ,
graphic_info ( file , lines [ current_print ] , G_HEIGHT ) ,
0
);
END

Que grande eres, me gusta esta manera de mostrar textos. Buen trabajo Windgate, karma más que merecido!

He estado haciendo varias muestras sobre papel y veo 3 flags posibles para mezclar pixels con distintas transparencias de origen y destino ( Siento no poder subir la captura ahora mismo ).

Tienes razon, las distintas posibilidades son complejas, a ver si consigo hacer algo palpable y os informo con ejemplo + capturas. Ahora mismo con map_clone y unas funciones basadas en map_get_pixel, rgb, get_rgb y similares puedo solucionar el problema.

EDIT: Muchas gracias Blostec, tengo una buena base pero aun tengo que meter otros detalles al margen del soporte para 32 bits.

Os dejo la cabecera de la funcion map_block_mix ( ) que estoy implementando, por si quereis ir aportando sugerencias. Se salta la limitacion que tenia map_block_copy ( ) y que no permitia usar graficos de distinto fpg:

FUNCTION int map_block_mix ( int file_o , int graph_o , int ox , int oy , int width , int height ,
int file_d , int graph_d , int dx , int dy , int mode )
BEGIN
graph_o = map_clone ( file_o , graph_o );
graph_d = map_clone ( file_d , graph_d );
       ...

El ultimo parametro mode aportara distintos comportamientos que decidire a medida que vaya haciendo pruebas, tambien podeis sugerir diferentes metodos de mezcla de colores para ese parametro.

EDIT: Por cierto, al usar map_clone asumo que devolvera un entero con el nuevo grafico generado, y estara en la file 0... ¿Como lo veis? Tambien se podrian aportar distintos valores de mode para hacer que se mezcle sobre el grafico original... Se agradecen sugerencias :)

Maldita sea, veo que map_put_pixel también trabaja ignorando el alpha... ¿No hay alguna forma "fácil" de saltarse eso o alguna otra función que pueda usar?

Por ahora estaba "reprogramando" el map_block_copy para luego añadirle diferentes métodos de mezcla de alphas, el código lo tengo así:

FROM x = ox TO ox + width; // For all pixels at original map ( x , y )
FROM y = oy TO oy + height;
pixel = map_get_pixel ( 0 , graph_o , x , y );
map_put_pixel ( 0 , graph_d , dx + x - ox , dy + y - oy , pixel );
END
END

accediendo directamente al mapa...

¿Accediendo al mapa como fichero te refieres o usando alguna otra función de Bennu?

creo que se refiere a map_get_pixel y map_put_pixel.

creo que splinter se refiere mediante el buffer del mapa, así accedo yo a la hora de transformar un gráfico a otra profundidad de color.

sería
POINTER MAP_BUFFER ( LIBRERÍA, GRÁFICO ) 
Devuelve un puntero al buffer del gráfico

ya desde aquí con get_rgba(color

• , &rojo,&verde,&azul,&alpha)
  obtendrás los componentes de color.

Gracias Prg, es que map_put_pixel y map_get_pixel trabajan en 16 bits, probaré lo que dices.

me referia a lo que señalo prg.

get y put tambien funcionan con 32bits...

¿Quieres decir que map_get_pixel y map_put_pixel tambien funcionan en 32 bits?

Ahora mismo tengo asi la funcion y no me respeta los alpha, al menos al hacer el map_put_pixel me lo hace ignorando el alpha.

¿Puede deberse a que el file 0 al que van todos los mapas que pasan por map_clone es de 16 bits? Quizas sea por eso que no me va...

FUNCTION map_block_mix ( int file_o , int graph_o , int ox , int oy , int width , int height ,
int file_d , int graph_d , int dx , int dy , int mode )
PRIVATE
int pixel;
BEGIN
graph_o = map_clone ( file_o , graph_o ); // We clone maps to avoid overwrite originals
graph_d = map_clone ( file_d , graph_d );
FROM x = ox TO ox + width; // For all pixels at original map ( x , y )
FROM y = oy TO oy + height;
pixel = map_get_pixel ( 0 , graph_o , x , y );
map_put_pixel ( 0 , graph_d , dx + x - ox , dy + y - oy , pixel );
END
END
RETURN graph_d;
END

dije que funciona en 32 bits, no que tome el alpha... el alpha lo pone siempre a 255...

Ah, amigo, ok, entiendo. En cualquier caso me quedo con la duda de si el file 0 a donde van a parar los maps clonados con map_clone tiene 16 o 32 bits o si depende del mapa que se clone, si alguien lo sabe que lo diga, por cultura general de Bennu mas que nada :P

Quotecreo que splinter se refiere mediante el buffer del mapa, así accedo yo a la hora de transformar un gráfico a otra profundidad de color.

sería
POINTER MAP_BUFFER ( LIBRERÍA, GRÁFICO ) 
Devuelve un puntero al buffer del gráfico

ya desde aquí con get_rgba(color
, &rojo,&verde,&azul,&alpha)
obtendrás los componentes de color.

Probare a hacerlo asi, accediendo al buffer del grafico, a ver si puedo acceder tanto en lectura como en escritura. Tengo varios proyectos a medias, os mantendre al corriente.

Creo que map_clone mantiene la profundidad de color del gráfico original, si no, no sería un clon.
Puedes probarlo con un pequeño código aparte con la propiedad g_depth de graphic_info.