Progreso lento, planes interesantes.

La vida es lo que te interrumpe mientras codeas.
Ya se ha superado el tema de pinchar en los sprites.
Ahora tengo que implementar las llamadas a los eventos-acciones. No creo que me cueste mucho. Seguramente haré un par de escenas de ejemplo.
Ahora estoy pensando en construir el sistema de interfaz, que serán dos bandas negras para convertir el juego en una especie de película "cinemascope". En estas bandas aparecerá la puntuación, los mensajes y las descripciones, los diálogos, etc.
Para las escenas de lucha tengo grandes planes y una colaboración. El engine contará con una característica muy interesante.

Más noticias pronto.

ping?

pong!

Píxeles de SDL_Surface y eventos de sprite.

Al final era más fácil de lo que yo creía. Hay un ejemplo en la documentación de libSDL que explicaba perfectamente cómo hacerlo. Copiaré el código con muy pocos cambios. Así, la detección de sprites pinchados se queda de la siguiente manera:

1.- Crear propiedad privada del sprite que sea un SDL_Surface con tamaño igual al de la superficie de la pantalla y 8 bits de profundidad con flag SWSURFACE. Esta superficie será la máscara.
2.- Cuando se cree un frame del sprite, crear una copia del frame a 8 bits como "sombra", también con flag SWSURFACE
3.- cuando se pida un tick del sprite (actualización de animación y frame para hacer blitting a la pantalla), rellenar la superficie máscara de un color concreto (¿rosa? ¿verde fosforito? ¿azul puro?) y hacer blit de la sombra del frame actual sobre la superficie máscara.
4.- para saber si el ratón ha pinchado sobre nuestro sprite, sacamos el color del pixel donde está el ratón de la máscara. Si no es el color de fondo asignado, hemos pinchado en nuestro sprite y disparamos evento de usuario de SDL, que a su vez disparará una o varias acciones de la lista de acciones de la escena.

A ver si esta tarde o mañana lo programo.

No he avanzado mucho...

... desde el último post. Pero tengo una buena excusa; he estado con Ubuntu 7.10 probando, reprobando y poniendo más a prueba. Y sólo tiene dos problemas para mí:

• El controlador de intel para las Xorg detecta el DPI demasiado grande que no concuerda con los ajustes de Gnome. Así, las barras de ventana, a cargo de compiz, salen con letras muy grandes respecto del resto del apartado gráfico, a cargo de Gnome. Es molesto, pero no es importante. Se arregla añadiendo la opción "-dpi 96" en el menú Sistema ==> Administración ==> Ventana de entrada ==> Seguridad ==> Configurar Servidor X ==> Comando.
• Se agota la batería de mi portátil en tres horas escasas. Claro, que no tengo un portátil muy bueno, pero creo que es poco tiempo. Deben mejorar bastante en el consumo de energía.

El resto del sistema simplemente funciona como debe.

Máscaras de sprites

Me están costando más de lo que suponía.
Leer un pixel de una superficie SDL tiene su miga, ya que la información de los pixeles sólo es accesible directamente desde la memoria. Y además, si la superficie es de tipo "HWSURFACE", está en la memoria de la tarjeta gráfica, lo que hace las lecturas lentas. Y no podría leer pixeles fuera de rango sin hacer costosas comprobaciones antes.
Ahora mismo estoy creando un sistema de "sombra" de los sprites, en la que creo una superficie "SWSURFACE" de acceso rápido equivalente a la superficie de la pantalla, pero en la que sólo "bliteo" una copia del sprite que también es "SWSURFACE". Todo esto con sólo 8 bits de profundidad para hacer el bliteo lo más rapido posible.
Cuando quiera leer el pixel donde se encuentra el ratón, tengo que bloquear la superficie "sombra", haciendo una lectura de este estilo:

Uint8 *bufp;//Avanzamos en bloques de 8 bits en vez de 1 byte
SDL_LockSurface(superficie);
            bufp = (Uint8 *)superficie->pixels + y*superficie->pitch/2 + x;
// realizamos comparación de bufp con un valor generado por la función
// SDL_MapRGB para saber si hemos tocado nuestro sprite
SDL_UnlockSurface(superficie);

Siendo "superficie" un SDL_Surface.

Más noticias pronto :)

Punteros de ratón.

El ratón tiene punteros que indican la acción activa en ese momento.
Para "usar", un par de engranajes. Para "ver", una lupa. Para "coger", una mano. Para "disparar", una mirilla. Y por supuesto, un puntero normal.

Lo siguiente serán eventos disparados por los sprites. Pero antes debo decidir cómo gestiono las máscaras de los sprites... Esto me va a costar un poco más, pero una vez resuelto este tema, ya se podrán crear juegos simples.

Música en las escenas y futuro

He programado un pequeño gestor de sonido y ahora las escenas tienen música de fondo. Pronto código y binario.
Lo siguiente va a ser los modos de interacción (ver, usar, coger) con el ratón, eventos generados por los sprites, presentación de texto, efectos de sonido...