Programación de videojuegos con sdl

[3dpoder]

Esta obra esta bajo una licencia attribution-noncommercial-noderivs 2.5 de Creative Commons. Para ver una copia de esta licencia, visite https://creativecommons.org/licenses/by-nc-nd/2.5/ o envíe una carta a Creative Commons, 559 Nathan Abbott way, Stanford, California 94305, usa.

Introducción.

Historia de los videojuegos.

La llegada del ordenador personal.

Sistemas operativos o la torre de babel.

Anatomía de un videojuego.

Entrada.

Visualización.

Sonido.

Comunicaciones.

Game loop.

Los cimientos de un videojuego.

La idea.

Los elementos del juego.

Manos a la obra.

Primeros pasos con SDL.

Trabajando con SDL.

Vídeo.

Cargando y mostrando gráficos.

Efectos especiales: transparencias y alpha-blending.

Otras funciones de interés.

Gestión de eventos.

Tipos de eventos.

Lectura de eventos.

Eventos del teclado.

Eventos de ratón.

Eventos del joystick.

Otros eventos.

Joystick.

Recopilando información sobre el joystick.

Leyendo el joystick.

Audio.

CD-rom.

El window manager.

Timming.

Librerías auxiliares para SDL.

Sdl_ttf.

Sdl_image.

Sdl_mixer.

Sonidos.

Música.

Sprites: héroes y villanos.

Control de sprites.

Implementando los sprites.

Utilizando nuestra librería.

Un universo dentro de tu ordenador.

Almacenando y mostrando tiles.

Diseñando el mapa.

Scrolling.

Enemigos, disparos y explosiones.

Tipos de inteligencia.

Comportamientos y máquinas de estado.

Disparos y explosiones.

Que comience el juego, enemigos.

Niveles.

Temporalización.

Pantalla inicial, puntuación y vidas.
¿Y ahora que?
Instalación de SDL.
Windows (vc++)
Linux.

De c a C++
Clases y objetos.

Herencia.

Polimorfismo.

Punteros y memoria.

Recursos.

Bibliografía.

Programación.

Programación de videojuegos.

Gráficos.

Enlaces.

Programación.

Programación de videojuegos.

Gráficos.

La imaginación es el motor de la creatividad, y la creatividad el motor de la inteligencia.

Muchas son las personas que opinan que la programación de ordenadores es una ciencia, otros lo ven como una ingeniería, sin embargo, algunos preferimos verla como un arte. Si tienes este libro entre tus manos, es porque te interesa la programación y también los videojuegos. Si es así, enhorabuena, porque estas a punto de entrar en un mundo realmente fascinante. La programación de videojuegos es muy diferente a la programación tradicional, requiere de una gran creatividad, pero también de una gran curiosidad y ganas de descubrir y, por que no, inventar cosas nuevas. De hecho, cuando creamos un videojuego, estamos creando un mundo nuevo, con su propio aspecto y sus propias leyes. En ese sentido el programador es como un dios dentro de ese mundo. La mayoría de las personas que se dedican a la programación se han planteado en algún momento el hacer un juego, y sin embargo, son pocos los programadores que se deciden a hacerlo. ¿hace falta algún don especial para hacer videojuegos? Probablemente no, pero hay muy buenos escritores de novelas que no son capaces de escribir poesía, y viceversa. En programación parece ocurrir lo mismo, hay programadores especialmente dotados para la programación de gestión y otros se desenvuelven mejor con una programación más cercana a la máquina.

Supondré que el lector ya postura conocimientos de programación, y más concretamente del lenguaje c. En el transcurso del libro, vamos a introducir las técnicas básicas utilizadas en la creación de videojuegos de forma práctica y a través de ejemplos, incluyendo el desarrollo de un juego completo. Vamos a utilizar para ello una librería multiplataforma llamada SDL (simple direct media layer) que nos va a permitir que nuestros juegos sean portables entre Windows, Linux, Macintosh, Beos y otros. También vamos a introducir ciertas características de la programación orientada a objetos (po) que nos ofrece C++, pero no debe preocuparse el lector desconocedor de la PO, porque dedicamos un apéndice completo para familiarizarnos con los elementos que vamos a usar de dicho lenguaje. La programación orientada a objetos es hoy necesaria a la hora de conseguir juegos de calidad profesional, por ello, introduciremos ciertos aspectos de este paradigma de programación.

Respecto a al grafismo utilizado en el juego de ejemplo que desarrollaremos durante el libro, he utilizado la librería de sprites GPL de Ari Feldman (https://www.arifeldman.com/), al cual agradezco, y ánimo a seguir ampliando.

Antes de acabar, quiero hacer una aclaración. Este no es un libro sobre programación y uso de SDL. Es un libro sobre programación de videojuegos, por lo tanto, no esperes una exhaustiva referencia sobre SDL. Iremos descubriendo los diferentes aspectos de esta librería según los necesitemos en nuestro camino a la creación de un videojuego, es por ello que habrá elementos de la librería que no formaran parte de los temas cubiertos por este libro.

Quiero, finalmente, dejar patente el objetivo que siempre he perseguido mientras escribía el presente texto: mantener las cosas simples, sin entrar en tecnicismos innecesarios que distraigan al programador menos formal del objetivo final, que es dotarle de las herramientas necesarias para expresar toda su creatividad en forma de videojuego. No me cabe duda que hay cientos o miles de potenciales buenos programadores de juegos que, aun teniendo los conocimientos de programación necesarios, no han podido acceder a una información clara y carente de formalismos más propios de un texto universitario. Espero que este sea un libro para todos, aunque ello signifique sacrificar en precisión y formalidad. El intentar trasladar la información contenida en el libro a un lenguaje sencillo y accesible me ha resultado a veces ciertamente una difícil tarea, por lo que pido excusas si en algún momento no he conseguido expresar las ideas con la suficiente simplicidad y claridad.

Puede contactar con el autor en la dirección de correo electrónico.



Allá donde el tiempo pierde su memoria, grandes hombres y mujeres construyeron nuestro futuro.

La prehistoria de los videojuegos, se remonta a 1958. Bill Nighinbotthan presenta en una feria científica un aparato que permite, mediante unos potenciómetros, mover una raqueta en un tubo de rayos catódicos. Bill no fue capaz de intuir el basto potencial que aquel pequeño aparato tenía. Basándose en este aparato, Nolan Bushnell crea en 1972 un videojuego llamado pong. Nollan, que sí es capaz de ver las posibilidades de este nuevo mercado, funda atari, pero antes, Nollan ya había comercializado su primer videojuego: computer space. Años más tarde, en 1976, un empleado de atari llamado Steve Jobs, ayudado por Steve Wozniak, crean un videojuego llamado breakout. Dos años después, ambos dejaran atari para crear Apple computer y pasar a la historia de la informática.



Steve Wozniak y Steve Jobs en su garaje, california. 1976.

Es en 1978 cuando Taito lanza al mercado el famoso space Invaders. Este juego era capaz de almacenar las puntuaciones máximas, convirtiéndose en todo un clásico.

En los siguientes años, comienzan a aparecer en el mercado nuevos videojuegos de excelente calidad, y que se convertirán en clásicos.

Juegos como Donkey Kong, Frogger, Galaga, PacMan,

En la década de los 80, los ordenadores personales comienzan a popularizarse, y ponen en manos de particulares la posibilidad, no sólo de jugar a videojuegos creados para estos ordenadores, sino que ahora cualquiera puede adentrarse en el mundo de la programación de videojuegos. Estos pequeños ordenadores de 8 bits hicieron las delicias de miles de aficionados a la informática. En España se hizo muy popular el Sinclair Spectrum. Un pequeño ordenador muy económico con un procesador Z80 y una memoria de 48 kilobytes. Otros ordenadores similares fueron el Amstrad 464, MSX y Commodore 64.



Commodore 64

De esta época tenemos juegos tan recordados como Manic miner, Xevious, jet set Willy, Arkanoid y otros. A finales de los 80, surgen grupos de programadores en el norte de Europa que comienzan a crear pequeñas joyas de la programación que intentaban exprimir el potencial de estas pequeñas máquinas al máximo. Concretamente estos grupos se crean en torno a la máquina de Commodore, gracias a sus posibilidades gráficas y de sonido, algo más avanzadas que la de sus competidores de la época. Estos pequeños programas es lo que hoy se ha dado en llamar demos. Son por tanto los creadores de la actual demoscene.

En la década siguiente, aparecen ordenadores más potentes. Son equipos con microprocesadores de 16 bits y tienen entre 512 kbs y 1 Mb de memoria. Quizás el más popular de estos fue el amiga 500, también de Commodore, aunque sin olvidar al atari st o al Acorn Archimedes. Estos ordenadores tenían unas capacidades gráficas muy superiores a sus antecesores. Podían utilizar 4096 colores simultáneos, y su capacidad de sonido también comenzaba a ser bastante espectacular. De esta época son juegos como Defender of the Cro, Barbarian, Elvira, Lemings y Maniac mansión.

Paralelamente a esta evolución, otro ordenador iba ganando adeptos a marchas forzadas. Sus capacidades gráficas y de sonido no eran mejores que la de sus competidores, de hecho, eran bastante inferiores, sin embargo, lograron hacerse poco a poco con el mercado de los ordenadores personales, hasta el punto de reinar casi en solitario (con permiso del Apple Macintosh). Evidentemente hablamos del PC. Afortunadamente, al convertirse en el sistema mayoritario, sus capacidades gráficas y de sonido comienzan a avanzar a pasos agigantados. Una fecha clave es abril de 1987, cuando IBM presenta en el mercado la tarjeta gráfica VGA. Dejando obsoletas a las legendarias Ega y Cga. A la VGA la seguiría la svga, y después toda un abanico de tarjetas con cada vez más memoria y aceleración gráfica 3d, llegando hasta las actuales Vodoo, las GeForce de Nvidia y las Radeon de Ati, con unas capacidades gráficas fuera de lo común a un precio muy asequible. Como es normal, esta época esta marcada por juegos como Quake, Counter-Strike.
(Half Life), Heretic, Warcraft y Hexen.

El ordenador PC, comercializado por IBM en el año 1982, ha pasado por varias etapas de existencia. Aquellos primeros PC iban equipados con el sistema operativo PC Dos, que no era más que una versión de IBM del msdos de Microsoft. En los tiempos del msdos la programación de videojuegos era bastante compleja, hacían falta grandes conocimientos de lenguaje ensamblador y de la estructura interna de la máquina, así como de la tarjeta de video y de sonido. Toda la programación se hacía directamente sobre el hardware. Es fácil imaginar los inconvenientes, había que preparar el juego para que funcionara con muchos modelos de tarjeta gráfica y también para los diferentes modelos de tarjetas de sonido (adlib, gravis ultrasound (gus), Sound Blaster). Es decir, hacer un juego, por simple que éste fuera, requería un esfuerzo muy alto, sin contar con que no siempre toda la información necesaria para acceder al hardware estaba al alcance de todo el mundo.

La llegada de Windows tampoco mejora demasiado el panorama, ya que no permite un acceso directo al hardware y su rendimiento gráfico es pobre. El acceso a los recursos del sistema también varía de un sistema operativo a otro. Se hace imprescindible, pues, crear una interfaz común para el desarrollo de videojuegos que permita el acceso estandarizado y con una interfaz común a los recursos del sistema. Algunas de estas propuestas son OpenGL y DirectX (éste último sólo para sistemas Windows).

En el caso de OpenGL, se nos ofrece una interfaz multiplataforma, sin embargo, se limita a ofrecernos una interfaz de acceso a gráficos (especializada en 3d, aunque con posibilidades de 2d) y no nos permite el acceso a otros recursos del sistema (teclado, sonido, joystick, timmers).

DirectX, sin embargo, está compuesto por varias subinterfaz con el so y el hardware, como directdraw (gráficos 2d), Direct3D (gráficos 3d), directinput (entrada y salida), directplay (capacidades de comunicación en redes TCP/IP), directsound (acceso a hardware de sonido) y algún que otro componente más. Como vemos, DirectX tiene gran cantidad de capacidades, pero presenta dos inconvenientes. El primero es que sólo es válido para sistemas Windows, y el segundo es que por la propia naturaleza de la programación en Windows, su uso es algo engorroso y no apto para programadores con poca experiencia con las apis de Windows y más concretamente con la interfaz com+.

Afortunadamente, la empresa Loki games, ante la necesidad de hacer portables los juegos de Windows a Linux y a otros sistemas operativos, crean una librería multiplataforma llamada SDL (simple directmedia layer), que nos ofrece acceso a los recursos de la máquina (gráficos, sonido, entrada/salida, timming,) mediante una interfaz coherente e independiente del so. SDL, además, nos permite utilizar la interfaz OpenGL para gráficos 3d.

Por: Alberto García serrano.

Puedes bajarte todo el manual en formato pdf [URL=https://www.foro3d.com/attachments/79611d121839303aquí.-ayudarias-a-hacer-un-curso-gratis-para-crear-videojuegos-3d-ebook-programacion_de_videojuegos_con_sdl.pdf[/url].

[3dpoder]

somos nuestra memoria, somos ese quimérico museo de formas inconstantes, ese montón de espejos rotos.

Jorge Luis Borges.

Cada vez que juegas a tu videojuego preferido, dentro del ordenador están ocurriendo muchas cosas. Se hace patente que un factor importante en un juego es que se mueva con soltura y a buena velocidad. Todos los elementos del juego parecen funcionar de forma independiente, como con vida propia y a la vez. Sin embargo, esto es sólo una apariencia, ya que dentro del programa se van sucediendo las diferentes fases de ejecución de forma secuencial y ordenada. En este capítulo vamos a tratar de dar una visión general y sin entrar en detalles de implementación de la anatomía de un videojuego. Vamos a ver qué partes lo componen y cómo se relacionan.

Un videojuego necesita comunicarse con el jugador a través de un dispositivo de entrada, como un joystick o un teclado. La programación del sistema de entrada/salida puede parecer a priori algo fácil de implementar y, de hecho, lo es. Sin embargo, si no queremos ver cómo nuestro estupendo juego se hace poco jugable para el jugador hay que cuidar mucho este aspecto. Una mala respuesta del juego ante una pulsación del teclado puede hacer frustrante la experiencia de juego para el jugador. Otro factor importante es el soporte de una variedad de dispositivos de entrada. Algunos jugadores preferirán usar el teclado al ratón y viceversa. Si además queremos que nuestro juego tenga un toque profesional, hay que dar la posibilidad al jugador de que defina las teclas con las que quiere jugar, además de dar soporte a los diferentes tipos de teclados internacionales.

La misión de esta capa es la de convertir el estado interno del juego en una salida gráfica. Ya sea en 2d o 3d, la calidad gráfica es un factor importante. Normalmente, el programador trabaja con unos gráficos creados por el mismo, y cuya calidad dependerá de las dotes artísticas de éste. En una siguiente fase, un artista gráfico crea y sustituye estas imágenes por las definitivas. Uno de los elementos principales de un buen juego es un buen motor gráfico, capaz de mover una gran cantidad de sprites en un juego 2d o una gran cantidad de polígonos (triángulos) en el caso de un juego en 3d. En el capítulo 6 veremos que es un sprite.

En el diseño del motor gráfico, siempre hay que llegar a un compromiso entre la compatibilidad y el rendimiento. Hay tarjetas gráficas en el mercado con unas capacidades casi sobrenaturales, pero que no son estándar, sin embargo, tampoco podemos dar la espalda a los jugadores profesionales que equipan sus ordenadores con la última aceleradora 3d del mercado.



El sonido es un aspecto al que, a veces, no se le da la importancia que merece. Tan importante como unos buenos gráficos es un buen sonido. Tanto el sonido como la banda sonora de un juego son capaces de transmitir una gran cantidad de sensaciones al jugador, y eso es, al fin y al cabo, lo que se busca. Tanto como la calidad, la buena sincronización con lo que va sucediendo en pantalla es de suma importancia.

Cada vez más, los juegos en red van ganando en adeptos. La comunicación se realiza normalmente sobre redes TCP/IP. Esto nos permite jugar contra otros jugadores situados en nuestra propia red local o en internet. La comunicación entre máquinas se lleva a cabo mediante la programación de sockets. Afortunadamente SDL nos probé de herramientas muy potentes para este tipo de comunicación, aunque esto es algo que queda fuera del alcance de este libro.



El game loop o bucle de juego es el encargado de dirigir en cada momento que tarea se está realizando. En la figura 2.1, podemos ver un ejemplo de game loop. Es sólo un ejemplo y, aunque más o menos todos son similares, no tienen por qué tener exactamente la misma estructura. Analicemos el ejemplo. Lo primero que hacemos es leer los dispositivos de entrada para ver si el jugador ha realizado alguna acción. Si hubo alguna acción por parte del jugador, el siguiente paso es procesarla, esto es, actualizar su posición, disparar, dependiendo de que acción sea. En el siguiente paso realizamos la lógica de juego, es decir, todo aquello que forma parte de la acción del juego y que no queda bajo control del jugador, por ejemplo, el movimiento de los enemigos, cálculo de trayectoria de sus disparos, comprobamos colisiones entre la nave enemiga y la del jugador, etc. Fuera de la lógica del juego quedan otras tareas que realizamos en la siguiente fase, como son actualizar el scroll de fondo (si lo hubiera), activar sonidos (si fuera necesario), realizar trabajos de sincronización, etc. Ya por último nos resta volcar todo a la pantalla y mostrar el siguiente frame. Esta fase es llamada fase de render.

Normalmente, el game loop tendrá un aspecto similar a lo siguiente:
Int done = 0;
While (.done) {
// leer entrada.
// procesar entrada (si se pulsó Esc, done = 1)
// lógica de juego.
// otras tareas.
// mostrar frame }.

Antes de que entremos en el game loop, tendremos que hacer un múltiples tareas, como inicializar el modo gráfico, inicializar todas las estructuras de datos, etc.



los cimientos de un videojuego.

Como toda buena obra de arte, un buen videojuego comienza con una buena idea, pero no basta con eso, hay que hacer que esa idea se transforme en una realidad. Es este capítulo vamos a desarrollar un pequeño juego que ilustre las fases y las ideas implicadas en el diseño. Desde el momento que el diseño de un videojuego no es una ciencia exacta, sino que tiene mucho de arte, este capítulo ha de tomarse como una guía general. Como aún no hemos visto nada sobre SDL ni sobre programación gráfica, vamos a crear un juego de aventuras tipo conversacional. Los que llevéis más tiempo en esto de los ordenadores, conoceréis ya cómo funcionan estos juegos (algunos recordarán la aventura original y don quijote por nombrar dos de ellos). Básicamente, el ordenador nos describe de forma textual los escenarios sobre los que nos movemos. Podemos dar ordenes a nuestro protagonista mediante frases que el ordenador interpreta. Por ejemplo, podemos dar una orden como: coger amuleto. Algunos de estos juegos podían interpretar frases muy complejas, pero nosotros nos limitaremos a dos palabras con la forma verbo nombre. Por ejemplo: ir norte o usar llave.
la idea.

Hoy en día no basta con unos impresionantes gráficos y un buen sonido para hacer un juego. Es muy importante tener una idea sobre la que se asiente el juego, o lo que es lo mismo, un buen argumento. Inventar una historia en la que pueda sumergirse el jugador y sentirse parte de ella es un trabajo más de un escritor que de un programador. Es por ello que en las empresas dedicadas a los videojuegos, hay personas dedicadas exclusivamente a escribir guiones e historias. Como supongo que, eres un buen programador y como para ser buen programador hay que ser una persona creativa, estoy seguro que no te costara conseguir una buena idea. Si la musa no te inspira, siempre puedes hacer remakes de otros juegos (intenta poner algo de tu propia cosecha para mejorarlo), basarte en alguna película o algún libro (Poe puede haber inspirado los escenarios de algunos de los juegos más terroríficos), hacer algún juego con temática deportiva o incluso basarte en algún sueño o pesadilla que hayas tenido (y no me digas que Doom no parece sacado de la pesadilla de un programador adolescente).

Pasemos a la practica. Vamos a crear un argumento para nuestro juego de ejemplo:
Fernando es un chico de 17 años, su vida es aparentemente normal. Su vecina Carolina, con la que trata de salir desde los 11 años, tiene una especial atracción por todo lo paranormal. No lejos de sus casas hay una vivienda que según cuentan esta embrujada y a la cual llaman la mansión del terror. Según Carolina, todo aquél que entra queda atrapado y sin salida posible. Fernando, que además de no creer en fantasma es muy dado a las bravuconadas, ha hecho una apuesta con Carolina. Si consigue salir de la casa, ira con el al baile de fin de curso. Fernando ha entrado por una ventana, que se ha cerrado de golpe cortando su única salida. ¿conseguirá Fernando salir de la mansión del terror? ¿conseguirá Fernando ir al baile con Carolina? Todo depende de ti ahora.

Como puedes ver, tampoco hay que ser un gran literato para crear una historia. Aun siendo una historia muy simple, se consigue que el jugador tenga una meta y luche por algo. Si tienes la suerte de saber dibujar, puedes incluso crear un story board con los detalles de la historia y los escenarios del juego.
los elementos del juego.

Los detalles son importantes y hay que tenerlos claros.
¿cómo va a ser la mansión? ¿cuántas habitaciones tiene? ¿Qué objetos podemos encontrará ¿cómo conseguimos ganar? ¿cuales son las dificultades?
Es necesario hacerse todo este tipo de preguntas para tener claro cómo va a desarrollarse una partida. Empecemos por nuestra misión. Para ganar, hemos de lograr salir de la casa. Para ello hemos de conseguir la llave que abre la puerta de la misma. Vamos a crear una mansión de pequeño tamaño, con sólo 9 habitaciones (utilizaremos un mapa de 3x3). Veamos cómo queda el mapa.



Hemos numerado las habitaciones de la casa para tener una referencia inequívoca de cada una. Una vez tenemos claro el mapa, situamos los objetos que nos permitirán cumplir nuestra misión:
Objeto 1 - hueso - esta en la habitación 2. Objeto 2 - llave - esta en la habitación 3. Objeto 3 - escalera - esta en la habitación 9. Objeto 4 - perro - esta en la habitación 9.

Y una lista de reglas sobre cómo usarlos:
Habitación 3 - para coger la llave hay que tener la escalera, ya que la llave esta sobre la lámpara del techo.

Habitación 9 - para poder coger la escalera hay que darle un hueso al perro rabioso.

Habitación 8 - para abrir la puerta y salir de la mansión hay que tener la llave.

Ya con el mapa finalizado, los objetos y su función dentro del juego, vamos a ver qué ordenes podemos darle a nuestro protagonista y sobre que objetos.

Coger - hueso, llave, escaleras. Dar - hueso. Usar - llave. Ir.

Es importante definir bien que acciones son válidas sobre cada objeto. Ahora que hemos pensado y plasmado por escrito los elementos del juego, es el momento de pasar a la acción empezar a escribir código.
manos a la obra.

Una de las claves a la hora de hacer un buen programa es partir de unas buenas estructuras de datos. Han de permitirnos cierta flexibilidad y a su vez no deben ser demasiado complejas de manejar. Empecemos por el mapa. La unidad básica más para poder describir el mapa es una habitación, así que, vamos a crear el mapa en memoria como una serie de habitaciones. Para describir una habitación usaremos la siguiente estructura de datos:
// estructura de datos para las // habitaciones structure habitación {
Char desc[25;
Int norte;
Int sur;
Int este;
Int oeste; } habitaciones[1.

Hemos creado un array de 10 habitaciones (de 0 a 9. Aunque usaremos 9. Del 1 al 9), que son precisamente las habitaciones que tiene nuestro mapa. Si recuerdas, en el mapa pusimos una numeración a cada habitación. Esta numeración ha de coincidir con su índice en el array. Veamos el significado de cada campo.

El primero es la descripción textual de la habitación. Aquí describimos lo que el jugador puede ver. Esta descripción es siempre fija, por lo que omitiremos indicar si hay algún objeto en la habitación, ya que estos podrían cambiar de sitios o ser cogidos y ya no estar en la habitación.

Los siguientes cuatro campos son los de dirección, correspondientes a norte, sur, este y oeste, e indican a la habitación que llegaremos si optamos por dar la orden de movernos en una de éstas direcciones. Veamos con un ejemplo:
// habitación 4 strcpy(habitaciones[.desc,estas en el pasillo.), habitaciones[.norte=1, habitaciones[.sur=7, habitaciones[, este=5, habitaciones[.oeste=0.

El primer campo no necesita mucha explicación, simplemente muestra el texto descriptivo de dónde se haya el jugador. Los cuatro siguientes nos indican que si el jugador decide ir al norte, llegara a la habitación 1, si decide ir al sur llegara a la habitación 7 y así sucesivamente. Si ponemos uno de estos campos a 0, significa que el jugador no puede moverse en esa dirección. Por lo tanto, si en nuestro programa tenemos una variable llamada habitación actual en la que se almacena la habitación en la que se encuentra el jugador en este preciso instante, para hacer el movimiento usaremos algo como:
Habitación actual=habitaciones[habitación actual].norte.

Simple, ¿no? Sigamos con otra estructura de datos importante: la encargada de describir los objetos. Echemos un vistazo:

// estructuras de datos para los objetos.

Struct objeto { int estado; // estado del objeto char desc1[8; // descripción para estado 1 char desc2[8; // descripción para estado 2
Int hab; // habitación en la que se.
// encuentra int.

Lo tengo; // indica si.

Tengo este objeto //
En mi inventario }
Objetos [;


al igual que con las habitaciones, hemos creado un array de 5 elementos para los objetos (aunque usaremos 4. Del 1 al 4). Veamos el significado de los campos de la estructura. El campo estado es para objetos que pueden tener dos estados diferentes. Por ejemplo, imagina una linterna, que podría estar encendida o apagada. Los campos desc1 y desc2, contienen la descripción del objeto cuando está en estado 1 y cuando está en estado 2. En desc1 habría algo como una linterna apagada y en desc2 tendríamos una linterna encendida. Puede que un objeto sólo tenga un estado, por ejemplo, una llave. En este caso el campo desc2 puede dejarse vació o contener el mismo texto que desc1, ya que nunca será mostrado.

El campo hab, indica en que habitación se encuentra el objeto, y el campo lotengo si esta a 0 significa que el jugador no postura este objeto y si esta a 1 es que lo tiene en su inventario. El siguiente ejemplo inicia un objeto del juego:
// perro objetos[perro], estado=1, strcpy(objetos[perro].desc1,un perro rabioso), strcpy(objetos[perro].desc2,un perro comiéndose un hueso), objetos[perro].hab=9, objetos[perro].lotengo=0.

Este código inicia el objeto perro. Por claridad hemos usado la constante perro en lugar de usar directamente su posición en el array. En el caso del perro, una vez que le damos el hueso, pasa al estado 2, en el que ya no es peligroso.

Ahora que ya tenemos definidas las estructuras de datos, vemos como quedaría el game loop de nuestro juego.
// inicialización de estados while (.done) {
// mostramos información de la habitación.
// leemos la entrada del jugador.
// procesamos la entrada del jugador }.

En la inicialización de estados establecemos los valores iniciales de las variables que van a definir el estado del juego. Por ejemplo, la variable habitación actual, indica en que habitación nos encontramos. Tenemos que darle un valor inicial, que es la habitación donde comienza el jugador la partida. En este caso, la habitación 1.

Ya dentro del game loop, la primera tarea es mostrar la descripción del lugar donde se haya el jugador. Para este juego, conviene poner esta fase al principio del bucle, sin embargo, en otros (como en el caso de 1945, que desarrollaremos en los siguientes capítulos) nos convendrá más situarlo en la parte final del mismo.

Hay tres informaciones que necesita el jugador: la descripción de la habitación, si se encuentra algún objeto en la misma y por último, cuáles son las salidas válidas de la estancia.

Empecemos por el principio. El siguiente código es el encargado de mostrar la descripción de la habitación:
// descripción printf(\n\n%s, habitaciones[habitación actual].desc).

Como ves, no tiene nada de complicado. Simplemente escribe por pantalla la descripción de la habitación contenida en la estructura de datos que vimos antes. El siguiente paso es mostrar los objetos que hay en la habitación, si es que hubiera alguno.
// mostramos si hay algún objeto for (i=1, i<=nobjetos, i++) {
If (objetos[.hab == habitación actual) { printf(\nTambién puedes ver ), // mostramos la descripción del objeto según // su estado if (objetos[, estado == 1) {
Printf(%s, objetos[.desc1), } else { printf(%s, objetos[.desc2),
} } }.

Con el bucle for comprobamos cada uno de los objetos. Si está en la habitación en la que se encuentra el jugador en ese preciso instante, muestra la descripción del objeto según su estado. Ya sólo nos resta mostrar las direcciones posibles que el jugador puede tomar.
// mostramos las posibles salidas printf(\nPuedes ir dirección ), if (habitaciones[habitación actual].norte.= 0)
Printf (norte ), if (habitaciones[habitación actual].sur.= 0) printf (sur ), if (habitaciones[habitación actual], este.= 0) printf (este ), if (habitaciones[habitación actual].oeste.= 0) printf (oeste).

Si el campo de dirección de la estructura de datos de la habitación contiene un valor distinto a 0, significa que ese camino lleva a otra habitación distinta y, por lo tanto, es una salida valida.

Lo siguiente que se hace en el game loop, es leer la entrada del jugador. Como habíamos dicho antes, y con el fin de simplificar, la entrada del usuario constara de dos palabras: un verbo y un objeto sobre el que realizar la acción.
// leemos la entrada del jugador printf(\n>>> ), scanf(%s%s, erbo, nombre),
Scanf leerá dos palabras separadas por un espacio, que es justamente lo que necesitamos. Por último, queda por procesar la entrada del jugador.
// coger if (.strcmp(verbo,coger)) {
Acción = 0;
// hueso.

If (.strcmp(nombre,hueso) objetos[hueso].hab == habitación actual) {
Acción = 1;
Objetos[hueso].hab=0;
Objetos[hueso].lotengo=1;
Printf(\nHas cogido el hueso.),
} }.

Este fragmento de código muestra cómo se procesa la entrada del jugador, en concreto para el verbo coger y el objeto hueso. Antes de realizar cualquier acción, debemos asegurarnos de que el objeto está en la habitación en la que se encuentra el jugador. Si todo es correcto, actualizamos la estructura de datos del objeto hueso e informamos al jugador de que se realizó la acción.

La variable acción es lo que se llama una variable tipo bandera o flag. Su misión es informar que se ha realizado una acción o no, en un punto más adelantado del código. Necesitamos saber si se realizó alguna acción para informar convenientemente al jugador en caso de no poder llevar a cabo su orden. Si hemos cogido un objeto, ya no está en ninguna habitación, esto lo indicamos poniendo a 0 el campo hab de la estructura de datos del objeto. El código completo del juego queda así.
// la mansión del terror // programación de videojuegos con SDL // (c) Alberto García serrano.
#include <stdio, h> #include <string, h>.
/*** declaración de estructuras de datos ***/.
#define hueso 1 #define llave 2 #define escalera 3 #define perro 4.
// estructuras de datos para los objetos.

Struct objeto { int estado; // estado del objeto char desc1[8; // descripción para estado 1 char desc2[8; // descripción para estado 2 int hab; // habitación en la que se encuentra int lotengo; // indica si tengo este objeto en mí inventario.
} objetos[.
// estructura de datos para las habitaciones.

Struct habitación { char desc[25, int norte, int sur, int este, int oeste.
} habitaciones[1.

Void main() {.
/*** inicialización de estructuras de datos ***/.
// inicialización de objetos.
// hueso objetos[hueso], estado=1, strcpy(objetos[hueso].desc1,un hueso), strcpy(objetos[hueso].desc2,un hueso), objetos[hueso].hab=2, objetos[hueso].lotengo=0.
// llave objetos[llav, estado=1, strcpy(objetos[llav.desc1,una llave sobre la lámpara), strcpy(objetos[llav.desc2,una llave sobre la lámpara), objetos[llav.hab=3, objetos[llav.lotengo=0.
// escalera objetos[escalera], estado=1, strcpy(objetos[escalera].desc1,una escalera), strcpy(objetos[escalera].desc2,una escalera), objetos[escalera].hab=9, objetos[escalera].lotengo=0.
// perro objetos[perro], estado=1, strcpy(objetos[perro].desc1,un perro rabioso), strcpy(objetos[perro].desc2,un perro comiendo un hueso), objetos[perro].hab=9, objetos[perro].lotengo=0.
// datos del mapa.
// habitación 1 strcpy(habitaciones[.desc,estas en una habitación pintada de blanco. Junto a ti.

Puedes ver una cama y una mesita de noche.), habitaciones[.norte=0, habitaciones[.sur=4, habitaciones[, este=0, habitaciones[.oeste=0.
// habitación 2 strcpy(habitaciones[.desc,estas en una habitación pintada de verde. Junto a ti puedes ver.

Una cama y una mesita de noche.), habitaciones[.norte=0, habitaciones[.sur=5, habitaciones[, este=0, habitaciones[.oeste=0.
// habitación 3 strcpy(habitaciones[.desc,estas en el salón de la casa. Puedes ver una gran mesa rodeada.

De sillas.), habitaciones[.norte=0, habitaciones[.sur=6, habitaciones[, este=0, habitaciones[.oeste=0.
// habitación 4 strcpy(habitaciones[.desc,estas en el pasillo.), habitaciones[.norte=1, habitaciones[.sur=7, habitaciones[, este=5, habitaciones[.oeste=0.
// habitación 5 strcpy(habitaciones[.desc,estas en el pasillo.), habitaciones[.norte=2, habitaciones[.sur=8, habitaciones[, este=6, habitaciones[.oeste=4.
// habitación 6 strcpy(habitaciones[.desc,estas en el pasillo.), habitaciones[.norte=3, habitaciones[.sur=9, habitaciones[, este=0, habitaciones[.oeste=5.
// habitación 7 strcpy(habitaciones[.desc,estas en el típico servicio, con sus típicas piezas.), habitaciones[.norte=4, habitaciones[.sur=0, habitaciones[, este=0, habitaciones[.oeste=0.
// habitación 8 strcpy(habitaciones[.desc,estas en la entrada de la casa. Puedes ver la puerta cerrada.), habitaciones[.norte=5, habitaciones[.sur=0, habitaciones[, este=0, habitaciones[.oeste=0.
// habitación 9 strcpy(habitaciones[.desc,estas en la cocina.), habitaciones[.norte=6, habitaciones[.sur=0, habitaciones[, este=0, habitaciones[.oeste=0.
/*** inicialización del estado de juego. ***/.
// variable que indica la habitación en la que estamos int habitación actual = 1.
// variable que indica cuantos objetos hay int nobjetos = 4.
/*** game loop ***/.

Char verbo[3, nombre[3, int i, acción, int done = 0.
While (.done) {.
// mostramos información de la habitación.
// descripción printf(\n\n%s, habitaciones[habitación actual].desc).
// mostramos si hay algún objeto for (i=1, i<=nobjetos, i++) {.

If (objetos[.hab == habitación actual) { printf(\nTambién puedes ver ), // mostramos la descripción del objeto según su estado if (objetos[, estado == 1) {.

Printf(%s, objetos[.desc1), } else { printf(%s, objetos[.desc2), } } }.
// mostramos las posibles salidas printf(\nPuedes ir dirección ), if (habitaciones[habitación actual].norte.= 0).

Printf (norte ), if (habitaciones[habitación actual].sur.= 0) printf (sur ), if (habitaciones[habitación actual], este.= 0) printf (este ), if (habitaciones[habitación actual].oeste.= 0) printf (oeste).
// leemos la entrada del jugador printf(\n>>> ), scanf(%s%s, erbo, nombre).
// procesamos la entrada del jugador.
// coger if (.strcmp(verbo,coger)) { acción = 0.
// hueso.

If (.strcmp(nombre,hueso) objetos[hueso].hab == habitación actual) { acción = 1, objetos[hueso].hab=0, objetos[hueso].lotengo=1, printf(\nHas cogido el hueso).
}.
// llave.

If (.strcmp(nombre,llave) objetos[llav.hab == habitación actual) { acción = 1; // para coger la llave necesitamos la escalera if (objetos[escalera].lotengo == 1) {.

Objetos[llav.hab=0, objetos[llav.lotengo=1, printf(\nTras subirte a la escalera, alcanzas la llave).
} else { printf(\nNo alcanzo la llave. Está demasiado alta.), } }.
// escaleras.

If (.strcmp(nombre,escalera) objetos[escalera].hab == habitación actual) { acción = 1, if (objetos[perro], estado == 2) {.

Objetos[escalera].hab=0, objetos[escalera].lotengo=1, printf(\nHas cogido las escaleras).
} else { printf(\nEl perro gruñe y ladra y no te deja cogerlo.), } }.

If (acción == 0) printf(\nNo puedes hacer eso).
}.
// dar if (.strcmp(verbo,dar)) { acción = 0.
// hueso if (.strcmp(nombre,hueso) objetos[hueso].lotengo == 1 objetos[perro].hab ==
Habitacionactual) { acción = 1, objetos[hueso].lotengo=0, objetos[perro], estado=2, printf(\nEl perro coge el hueso y se retira a comérselo tranquilamente).
}.

If (acción == 0) printf(\nNo puedes hacer eso.), }.
// usar if (.strcmp(verbo,usar)) { acción = 0.
// hueso.

If (.strcmp(nombre,llave) objetos[llav.lotengo == 1 habitación actual == { acción = 1, printf(\nEnhorabuena. Has escapado de la mansión del terror.), done = 1.
}.

If (acción == 0) printf(\nNo puedes hacer eso.), }.
// ir if (.strcmp(verbo,ir)) { acción = 0.
// norte.

If (.strcmp(nombre,norte) habitaciones[habitación actual].norte.= 0) { acción = 1, habitación actual=habitaciones[habitación actual].norte.
}.
// sur.

If (.strcmp(nombre,sur) habitaciones[habitación actual].sur.= 0) { acción = 1, habitación actual=habitaciones[habitación actual].sur.
}.
// este.

If (.strcmp(nombre,este) habitaciones[habitación actual], este.= 0) { acción = 1, habitación actual=habitaciones[habitación actual], este.
}.
// oeste.

If (.strcmp(nombre,oeste) habitaciones[habitación actual].oeste.= 0) { acción = 1, habitación actual=habitaciones[habitación actual].oeste.
}.

If (acción == 0) printf(\nNo puedes hacer eso.), }.
} }.

Esta obra esta bajo una licencia attribution-noncommercial-noderivs 2.5 de Creative Commons. Para ver una copia de esta licencia, visite http://creativecommons.org/licenses/by-nc-nd/2.5/ o envíe una carta a Creative Commons, 559 Nathan Abbott way, stanford, california 94305, usa.

Por: Alberto García serrano.

[3dpoder]

Iniciar el camino es fácil, finalizarlo también. Lo meritorio es recorrerlo.

Antonio si utilizas Windows, Linux o cualquier otro sistema operativo, SDL te va a ahorrar un montón de trabajo y de dolores de cabeza. El apéndice a esta dedicado a la instalación de la librería para ambos sistemas operativos, así que, si aún no lo tienes instalado es un buen momento para saltar a dicho apéndice e instalarlo. En este capítulo, vamos a introducirnos en el manejo de esta librería. No describiremos todas y cada una de las partes que la componen, ya que para ello necesitaríamos un libro dedicado a ello en exclusiva. Veremos, sin embargo, lo más importante y lo necesario para poder construir un videojuego.

SDL es el acrónimo de simple directmedia layer. Al igual que DirectX en Windows, SDL nos ofrece una completa Api para el desarrollo de juegos, demos y todo tipo de aplicaciones multimedia con independencia del sistema operativo y la plataforma. Actualmente SDL soporta Linux, Windows, Beos, Mac OS, Mac OS X, Freebsd, Openbsd, bsd/os, Solaris, y Irix. Aunque tiene portes no oficiales a Windows ce, Amigas, atari, Qnx, Netbsd, Aix, Osf/Tru64, y Symbianos.

SDL está compuesto por subsistemas separados que nos ofrecen soporte a diferentes partes del hardware.

Es nuestra interfaz con el hardware de video. Nos permite operación básicas como la inicialización de modos gráficos, trabajo con colores y paletas de color, manejo de surfaces, colores transparentes, alpha blending y otras (veremos que significan estos términos cuando profundicemos en el subsistema de video).

Es el subsistema encargado de todo lo que tenga que ver con la reproducción de sonidos. Nos va a permitir reproducir archivos.wav de forma relativamente sencilla de eventos.

Los eventos son la base de la interactividad. Los necesitamos para saber si el jugador quiere mover la nave a la izquierda o, por el contrario quiere hacer un disparo. Básicamente nos va a permitir conocer el estado del teclado y del ratón en cualquier momento.



Seguramente te estarás preguntando por que no se controla el joystick desde el subsistema de eventos. Yo también me lo pregunto y ciertamente no encuentro una buena razón para ello. Probablemente la razón sea que existen multitud de sistemas diferentes de joystick en el mercado, quizás los suficientes para justificar un módulo separado. En cualquier caso, gracias a este subsistemas, nuestros juegos podrán ser controlados mediante un joystick.



Efectivamente, SDL nos permite el acceso a todas las funciones del cdrom. Las posibilidades son muy atractivas. Por ejemplo, si distribuyes tu juego en CD, éste puede tener una pista sonora y reproducirla en background mientras el jugador juega. Interesante ¿no?



Sin duda sabes lo que es la multitarea. Puedes ejecutar múltiples programas al mismo tiempo. La idea de hilo (hilo en español) es similar. Son pequeños procesos que se lanzan simultáneamente, pero que pertenecen a un mismo programa padre. Por ejemplo, un juego puede tener un hilo encargado de reproducir una música y otro que va calculando la posición de los enemigos. Cada sistema operativo nos ofrece su propia forma de trabajar con los hilos, pero SDL se jacta de ofrecer una Api multiplataforma para manejo de hilos.



Es posible que alguna vez hayas probado alguno de esos juegos antiguos (muy antiguos) de cuando los PC corrían a 8 o 11 Mhz en tu flamante Pentium IV. Si el juego no había tenido en cuenta la velocidad del ordenador, probablemente lo veras funcionar tan rápido que serás incapaz de jugar. Si el juego hubiera estado bien diseñado, habría tenido en cuenta esta eventualidad, ya que no todos los ordenadores funcionan a la misma velocidad. SDL nos ofrece acceso a timers de alta resolución (o al menos de una resolución aceptable) para hacer que nuestro juego trabaje a la misma velocidad con independencia de la máquina en la que se ejecute.



Además, de estos subsistemas básicos, SDL tiene ciertas extensiones que nos harán la vida más fácil, como son sdl_image que permite trabajar con múltiples formatos de archivos gráficos, sdl_ttf para manejo de fuentes true type, sdl_net para acceso a redes TCP/IP y sdl_mixer que mejora sustancialmente el subsistema de audio de SDL.

Trabajando con SDL.

Es hora de ponerse manos a la obra y poner a trabajar al compilador.

Antes de llamar a cualquier función de SDL, hay que inicializarla y para ello se utiliza la función sdl_init(uint32 flags). Veamos con un ejemplo.
#include <stdlib, h> #include SDL.h.

Main(){ if (sdl_init(sdl_init_audio|sdl_init_video)< 0) { printf(no se puede iniciar SDL: %s\n,sdl_geterror()).

Exit(1).
}.

Atexit(sdl_quit), }.

En este fragmento de código hay varias cosas interesantes. Empecemos por la función sdl_init. Como parámetro acepta un argumento de tipo uint32. Como te dije antes, SDL es multiplataforma, por lo que tiene definidos una serie de tipos de datos que serán iguales con independencia del sistema en el que corra. La u quiere decir que el tipo de datos es sin signo (unsigned), int, como podrás adivinar es porque es un entero y 32, porque es un entero de 32 bits. Si en vez de u, usamos la s (signed) estaremos hablando de un entero con signo. Para el número de bits, los posibles valores son 8,16,32 o 64. Así, por ejemplo, uint16, hará referencia a un entero de 16 bits. Veamos en detalle los parámetros que hemos pasado a sdl_init(). Sdl_init_audio|sdl_init_video. Con este parámetro le decimos a SDL que sólo queremos inicializar el subsistema de audio y de video. Los posibles valores son:
Sdl_init_video.

Sdl_init_audio.

Sdl_init_timer.

Sdl_init_cdrom.

Sdl_init_joystick.

Sdl_init_everything.

Los parámetros se pasan separados por la barra vertical (|). Si quisiéramos inicializar además del audio y el video el cdrom, los parámetros serían los siguientes:
Sdl_init_audio|sdl_init_video|sdl_init_cdrom.

Si lo queremos activar todo, pasaremos como único parámetro sdl_init_everything. Una vez inicializado SDL, si necesitamos inicializar otro subsistema podemos hacerlo con la función sdl_initsubsystem(uint32 flags) de la siguiente manera.
// inicializamos el cdrom.

If (sdl_initsubsystem(sdl_init_cdrom) == 1) {.

Printf(no se puede iniciar el cdrom: %s\n,sdl_geterror()).

Exit(1), }.

Como habrás adivinado, la función sdl_geterror() devuelve el último error interno de SDL en formato cadena. Cuando una aplicación SDL es inicializada, se crean dos archivos, stderr, txt y stdout, txt. Durante la ejecución del programa, cualquier información que se escriba en la salida de error estándar se escribe en el archivo stderr, txt. Igualmente, cualquier información que se escriba en la salida estándar se guardará en el archivo stdout, txt. Esto nos va a ser de gran ayuda a la hora de depurar programas. Una vez finalizada la ejecución, si estos archivos están vacíos son borrados automáticamente, si no, estos permanecen intactos.

Al igual que inicializamos SDL, cuando hemos terminado el trabajo hemos de cerrarlo. La función encargada de esta tarea es sdl_quit(). En nuestro programa de ejemplo hemos usado la siguiente la línea atexit(sdl_quit). La función atexit() toma como parámetro a otra función a la que llama justo antes de que finalice la ejecución del programa. En nuestro caso, antes de que finelice nuestro programa (ya sea por un error o porque el usuario forzó la salida) se llamara a la función sdl_quit(). Una de las particularidades de atexit() es que la función a la que debe llamar no tiene que tener parámetros ni devolver nada.

En el caso de que queramos finalizar sólo un subsistema de SDL usaremos la función sdl_quitsubsystem(uint32 flags). Por ejemplo, si quisiéramos desactivar el subsistema de cdrom usaríamos la siguiente línea:
Sdl_quitsubsystem(sdl_init_cdrom).

Video.

La primera tarea que tenemos que acometer antes de empezar a mostrar información gráfica en la pantalla es establecer el modo de video. SDL nos lo pone fácil con la función.

Sdl_setvideomode (). La función tiene la siguiente forma:
Sdl_surface *sdl_setvideomode (int width, int height, int bpp, uint32
Flags).

Esta función devuelve un puntero del tipo sdl_surface. En SDL la surface o superficie es el elemento básico que utilizamos para construir los gráficos de nuestro juego. Imagina una superficie como un rectángulo que contiene información gráfica, por ejemplo, de nuestra nave. La única superficie que es visible, es decir, que vemos en la pantalla del ordenador, es ésta que nos devuelve la función sdl_setvideomode ().

Los parámetros witdth y height son la anchura y la altura de la superficie en píxeles. Es decir, la resolución de la pantalla. En teoría aquí podemos poner cualquier cosa, pero evidentemente el hardware ha de soportar dicha resolución. Si la resolución no es soportada, SDL intentara poner una resolución valida lo más cercana a la requerida. Un poco más adelante veremos una función que nos permitirá conocer cuáles son los modos válidos. Con el parámetro bpp le indicamos a SDL cuantos bits por píxeles queremos establecer, es decir, la profundidad de color. Valores típicos son 8, 16, 24 y 32. Hoy en día no tiene sentido trabajar con 8, ya que sólo nos proporciona 256 colores posibles, además, habría que trabajar con paletas en vez de con color real. En este libro no vamos a cubrir el trabajo con paletas, ya que es tedioso y dudo que realmente lo necesites alguna vez.

El último parámetro es flags, que es un campo de bits. Estos son los posibles valores y su significado.

Sdl_swsurface : crea la superficie de vídeo en la memoria principal crea la superficie en la memoria de vídeo, sdl_hwsurface : modo de Blit asíncrono, sdl_asyncblit : mejora el rendimiento en máquinas con más de un procesador, aunque puede disminuirlo en máquinas con una sólo procesador, sdl_anyformat : fuerza el uso de los bpp de la surface actual, sdl_hwpalete : hay que usarlo cuando queramos crear la superficie en una ventana, sdl_doublebuf : da a SDL acceso exclusivo a la paleta de color, sdl_fullscren : sólo valido con sdl_hwsurface. Permite el uso del doble buffer. Intenta poner el modo a pantalla completa, sdl_opengl : crea un contexto OpenGL en la superficie, sdl_openglblit : igual que la anterior, pero permite que SDL haga el render 2d, sdl_resizable : crea un ventana que puede cambiar de tamaño, sdl_noframe : crea una ventana, pero sin borde.


He aquí un ejemplo práctico del uso de sdl_setvidemode ().

Sdl_surface *screen.

Scren = sdl_setvideomode (640,480,24,sdl_swsurface| sdl_doublebuf), if (screen == null){ fprintf(stderr, no se puede establecer el modo \ de video 640x480: %s\n, sdl_geterror()), exit(1), }.

Le hemos pedido a SDL que establezca un modo de video con una resolución de 640x480 píxeles y 24 bits de color (true color). Además, le solicitamos que use la memoria de vídeo y una estrategia de doble buffer para repintado.

Antes hemos dicho que la superficie que nos devuelve sdl_setvideomode es la única visible. Sin embargo, es seguro que necesitaremos crear y utilizar superficies intermedias para almacenar gráficos, construir escenas, etc. Estas superficies no pueden ser directamente mostradas por pantalla, pero sí copiadas en la superficie principal (visible). A este proceso lo llamamos bit blitting y veremos más abajo cómo se realiza esta operación. La manera de crear una nueva superficie es mediante la función sdl_creatergbsurface que crea una superficie vacía y lista para usar. El formato de esta función es.

Sdl_surface *sdl_creatergbsurface (uint32 flags, int width, int height, int depth, uint32 rmask, uint32 gmask, uint32 bmask, uint32 amask).

A simple vista parece algo complicada, así que, vamos a detenernos un poco en ella. Como puedes observar, esta función nos devuelve un puntero a una superficie, al igual que hacía la función sdl_setvideomode. Los parámetros width y height tienen el mismo significado que en sdl_setvideomode, y depth es lo mismo que bpp (me pregunto por que no han mantenido la misma nomenclatura). Los posibles valores para flags son:
Sdl_swsurface : crea la superficie de vídeo en la memoria principal.

Sdl_hwsurface : crea la superficie en la memoria de vídeo, sdl_srcolorkey : permite el uso de transparencias (Color Key), sdl_srcalpha : activa el alphablending.

Un poco más adelante veremos más claramente el significado de las dos última opciones. Nos queda rmask, gmask, bmasque y amask. Estos parámetros son un poco más complejos de comprender sin entrar en mucho detalle en las estructuras de datos internas de SDL, en concreto en la estructura sdl_pixelformat. Baste decir que la r, la g, la b y la a con la que empiezan cada uno de estos parámetros vienen de red, green, blue y alpha respectivamente. Rmask, por ejemplo, es la máscara de bits que representa al color rojo puro. Recuerda que un color cualquiera viene dado por la mezcla de los colores rojo, verde y azul, por lo tanto, rmasque serían los bits que es necesario activar para conseguir el color que tiene un 100% de rojo, un 0% de verde y un 0% de azul. Lo mismo es válido para el resto de parámetros. Veamos un ejemplo de uso de esta función.

Rmasque = 0xf000000, gmasque = 0x00f0000, bmasque = 0x0000f00, amask = 0x000000f, surface = sdl_creatergbsurface (sdl_swsurface, 640, 480, 24, rmask, gmask, bmask, amask), if(surface == null) {.

Printf(error al crear la superficie).

Exit(1), }.

Cargando y mostrando gráficos.

Vale, todo esto está muy bien, pero ¿cuándo vamos a empezar a ver algo?
Esta bien. Pasemos directamente a un ejemplo completo. La figura3.1 muestra el resultado de ejecutar el programa ejemplo3_1.



Figura3.1.
/************************************************** *************** ejemplo3_1.
(C) 2003 by Alberto García serrano programación de videojuegos con SDL ************************************************** ****************/.
#include <stdio, h> #include <stdlib, h> #include <sdl.h>.

Int main(int argc, char *argv) {.

Sdl_surface *image, *screen, sdl_rect dest, sdl_event event, int done = 0.

Atexit(sdl_quit).
// iniciar SDL.

If (sdl_init(sdl_init_video) < 0) { printf(no se pudo iniciar SDL: %s\n,sdl_geterror()), exit(1).
}.
// activamos modo de video screen = sdl_setvideomode (640,480,24,sdl_hwsurface), if (screen == null) {.

Printf(no se puede inicializar el modo gráfico: \n,sdl_geterror()), exit(1), }.
// cargamos gráfico image = sdl_loadbmp(nave, bmp).

If (image == null) { printf(no pude cargar gráfico: %s\n, sdl_geterror()), exit(1).
}.
// definimos donde dibujaremos el gráfico // y lo copiamos a la pantalla, dest.x = 100, dest, y = 100, dest.w = image>w, dest, h = image>h, sdl_blitsurface (image, null, screen, &dest).
// mostramos la pantalla sdl_flip(screen).
// liberar superficie sdl_fresurface (image).
// esperamos la pulsación de una tecla para salir while (done == 0) { while (sdl_pollevent(&event)) { if (event, type == sdl_keydown) done = 1; } }.

Return 0; }.

Hay una gran cantidad de cosas en este código que aún no hemos visto, pero no querría seguir mostrándote una larga lista de funciones y ejemplos incompletos. Vamos a usar este programa para introducir nuevas capacidades de SDL.

La primera parte del programa debería ya resultarte familiar. En ella inicializamos SDL y también el modo gráfico. La primera función desconocida que encontramos es sdl_loadbmp(). El formato de esta función es:
Sdl_surface *sdl_loadbmp(const char *file).

Su funcionamiento es realmente sencillo. Sólo tiene un parámetro, que es el nombre (y Path) de un fichero gráfico en formato.bmp (bitmap). Si la función tiene éxito nos devuelve una superficie del tamaño del gráfico que acabamos de cargar, si no, devuelve null. En nuestro ejemplo, hemos declarado la variable *image de tipo sdl_surface para que albergue la superficie cargada.

La siguiente función que nos llama la atención es:
Int sdl_blitsurface (sdl_surface *src, sdl_rect *srcrect, sdl_surface *dst, sdl_rect *dstrect).

Esta función copia zonas rectangulares de una superficie a otra. Vamos a usarla para copiar el gráfico que hemos cargado anteriormente en la superficie image en la superfivie visible (screen). Es decir, para mostrar el gráfico en la pantalla.

Si observamos los parámetros, hay dos de tipo sdl_surface y otros dos del tipo sdl_rect. El primer tipo ya lo conocemos, en concreto son los parámetros src y dst, que son la superficie fuente y la de destino respectivamente. El parámetro srcrect define la zona o porción rectangular de la superficie desde la que queremos copiar. Dstrect es la zona rectangular de la superficie de destino en la que vamos a copiar el gráfico. El tipo sdl_rect tiene la siguiente forma:
Typedef structure{.

Sint16 x, y.

Uint16 w, h; } sdl_rect.

Esta estructura define un rectángulo. Como seguramente adivinaras x e y son la posición de la coordenada superior izquierda del rectángulo mientras que w y h son la anchura y la altura del triángulo, respectivamente. Veamos en detalle como usamos esta estructura:
Sdl_rect dest.

Dest.x = 100, dest, y = 100, dest.w = image>w, dest, h = image>h, sdl_blitsurface (image, null, screen, &dest).

Hemos declarado la variable dest y a continuación hemos definido el área rectangular de destino al que vamos a copiar el gráfico. En nuestro ejemplo, vamos a copiar el gráfico en la posición (100,100) de la superficie de destino. Para conocer el tamaño de la superficie del gráfico que hemos cargado podemos acceder a los campos w y h de la estructura sdl_surface de dicho gráfico.

Fíjate en el segundo parámetro, al que hemos dado el valor null. Con esto le indicamos a SDL que queremos copiar toda la superficie en la que se haya el gráfico.

Algún avispado lector se preguntara que ocurre si los campos w y h de los parámetros srcdest y dstrect no coinciden. Realmente no ocurre nada, ya que los campos w y h de dstrect no se utilizan. Por último, decir que si la copia tiene éxito la función devuelve el valor 0, y -1 en caso contrario.

Otra utilidad de la estructura sdl_rect es la de dibujar rectángulos en la pantalla mediante la función sdl_fillrect. Ilustrémoslo con un ejemplo:
Sdl_rect dest, dest.x = 0, dest, y = 0, dest.w = screen>w, dest, h = screen>h, sdl_fillrect(screen,&dest,sdl_maprgb(screen>format ,0,0,0)).

Esta función dibuja un cuadrilátero en una superficie con el color indicado. En el ejemplo se dibuja un rectángulo de color negro del tamaño de la superficie (pantalla), o lo que es lo mismo, borra la pantalla. El formato de la función es:
Int sdl_fillrect(sdl_surface *dst, sdl_rect *dstrect, uint32 color).

El primer parámetro es la superficie de destino, el siguiente parámetro es de tipo sdl_rect y define el rectángulo. Por último, hay que indicar el color de relleno. Un poco más adelante comprenderemos el uso de sdl_maprgb.

Sigamos con la siguiente función:
Int sdl_flip(sdl_surface *screen).

Si estamos usando doble buffer (como es el caso de nuestro ejemplo), esta función intercambia los buffers, es decir, vuelca el contenido del buffer secundario al principal. Si tiene éxito devuelve 0, si no, devuelve -1. Si no usáramos doble buffer o nuestro hardware no lo soportara, tendríamos que usar sdl_updaterect(screen,0,0,0,0) en lugar de sdl_flip(). El formato de esta función es:
Void sdl_updaterect(sdl_surface *screen, sint32 x, sint32 y, sint32 w, sint32 h).

Su misión es asegurar que el área que especifiquemos (sus parámetros deben serte ya familiares) sea actualizada.

Como te veo con cara rara, quizás sea este el momento de explicar en que consiste eso del doble buffer.

Imagina que tienes que volcar a la pantalla los gráficos de tu juego. Primero pondrías el fondo (calculando previamente que porción del fondo tienes que mostrar), mostrarías las naves enemigas (calculando su posición previamente) y después dibujarías al héroe de tu juego. Entre el primer y el último gráfico que dibujas en pantalla puede pasar un tiempo bastante grande (informáticamente hablando). Durante este tiempo, la imagen del monitor ha tenido tiempo de actualizarse varias veces (retraso vertical). Desgraciadamente, cuando esto ocurre aparecen parpadeos y guiños (flicking) indeseados y muy molestos. Mediante la técnica del doble buffer, todo el pintado se hace en una pantalla virtual, y sólo cuando esta todo pintado, volcamos su contenido a la pantalla real (flipping). Este proceso de volcado se hace además de forma sincronizada con el retraso vertical del monitor para evitar los parpadeos.

Es importante (sobre todo en un lenguaje como c/C++) liberar los recursos que ya no vamos a necesitar. En nuestro ejemplo usamos la función sdl_fresurface () para liberar (borrar) la superficie que contiene la imagen cargada. Su formato es:
Void sdl_fresurface (sdl_surface *surface).

La misión de las siguientes líneas es esperar la pulsación de una tecla cualquiera antes de acabar. Veremos más en profundidad su significado cuando tratemos los eventos.

Efectos especiales: transparencias y alphablending.

El hecho de que seamos capaces de mostrar el gráfico de un avión en la pantalla es un paso importante, pero seamos realistas: no es demasiado espectacular. De hecho, ese recuadro rojo alrededor del avión es bastante antiestético ¿no? Ciertamente sí. Alguien puede haber ya pensado en una solución (salomónica, me atrevería a apuntar), que es hacer que ese horrible recuadro rojo sea de color negro, al igual que el fondo. Realmente es una solución, si te gustan los juegos con fondos de pantalla algo monótonos. Como siempre SDL viene al rescate. Echemos un vistazo a la siguiente función:
Int sdl_setcolorkey(sdl_surface *surface, uint32 flag, uint32 key).

Esta función nos permite designar un color en la superficie, que pasamos como parámetro, y que tendrá el comportamiento de un color transparente. Es decir, que no se pintara cuando hagamos el blitting. La función nos devuelve 0 si todo fue bien y -1 en otro caso. El parámetro flag sólo puede tomar tres valores posibles:
* 0 para desactivar una transparencia previamente activada.
* sdl_srcolorkey para indicar que el tercer parámetro de la función corresponde al color que queremos que sea transparente y.
* sdl_rleacel que permite usar codificación RLE en la superficie para acelerar el blitting.

O.

Este último flag sólo puede usarse en combinación con sdl_srcolorkey, es decir, sólo se permiten tres valores posibles: 0, sdl_srcolorkey, sdl_srcolorkey| sdl_rleacel. El tercer parámetro es el color, que queremos que sea transparente. Hay que tener en cuenta que el color ha de estar en el mismo formato de píxel (píxel format) que la superficie. Lo habitual es utilizar la función sdl_maprgb para conseguir el valor del color que buscamos. Veamos un ejemplo:
Sdl_setcolorkey(image, sdl_srcolorkey|sdl_rleacel, sdl_maprgb(image>format,255,0,0)).

Añade esta línea al ejemplo anterior después de la carga del gráfico. Si ejecutas ahora el programa veras el avión sin ese feo marco rojo alrededor.



Figura3.2.

Lo que hemos hecho es, ni más ni menos, que decirle a SDL que el color rojo de la superficie que contiene el avión va a ser el color transparente. Como ves, esta función no tiene ningún secreto, aunque nos falta aclarar el funcionamiento de la función sdl_maprgb.

Uint32 sdl_maprgb(sdl_pixelformat *fmt, uint8 r, uint8 g, uint8 b).

Existe un campo en la estructura sdl_surface (contiene la información de una superficie) llamado format que define el formato del píxel (píxel format) de la superficie. Dependiendo del formato que tenga el píxel (número de bits por píxeles) la representación de un color concreto es diferente. Esta función nos devuelve el color solicitado en el formato de píxel que le pasamos como primer parámetro. Observa que puedes obtener el formato de píxel de una superficie accediendo a su campo format (image>format). Los otros tres parámetros son las componentes de rojo, verde y azul (formato RGB) del color que queremos. En nuestro caso, el color rojo es (255,0,0). Ahora que podemos usar colores transparentes, vamos a dar un paso más y vamos a utilizar una de las características más espectaculares de SDL: el alphablending o alpha para los amigos. Gracias al alphablending podemos hacer que una superficie sea translúcida, es decir con cierto nivel de transparencia. Este nivel de transparencia tiene un rango de 0 a 255. Donde 0 es transparente y 255 es totalmente opaco. Como una imagen vale más que mil palabras, vamos a ver un nuevo ejemplo en la figura3.3.
/******************************************* ejemplo3_2.
(C) 2003 by Alberto García serrano programación de videojuegos con SDL *******************************************/.
#include <stdio, h> #include <stdlib, h> #include <sdl.h>.

Int main(int argc, char *argv) {.

Sdl_surface *image, *screen, sdl_rect dest, sdl_event event, int i, done = 0.

Atexit(sdl_quit).
// iniciar SDL.

If (sdl_init(sdl_init_video) < 0) { printf(no se pudo iniciar SDL: %s\n,sdl_geterror()), exit(1).
}.
// activamos modo de video screen = sdl_setvideomode (640,480,24,sdl_hwsurface), if (screen == null) {.

Printf(no se puede inicializar el modo gráfico: \n,sdl_geterror()), exit(1), }.
// cargamos gráfico image = sdl_loadbmp(nave, bmp).

If (image == null) { printf(no pude cargar gráfico: %s\n, sdl_geterror()), exit(1).
}.
// definimos color para la transparencia sdl_setcolorkey(image,sdl_srcolorkey|sdl_rleacel,s dl_maprgb(image>format,255,0,0)).
// vamos a dibujar 100 gráficos.

For (i=1, i<=100, i++) { // ajustamos el canal alpha sdl_setalpha (image,sdl_srcalpha|sdl_rleacel, Rand() % 255).
// definimos donde dibujaremos el gráfico // y lo copiamos a la pantalla, dest.x = Rand() % 640, dest, y = Rand() % 480, dest.w = image>w, dest, h = image>h, sdl_blitsurface (image, null, screen, &dest).
}.
// mostramos la pantalla sdl_flip(screen).
// liberar superficie sdl_fresurface (image).
// esperamos la pulsación de una tecla para salir while (done == 0) { while (sdl_pollevent(&event)) { if (event, type == sdl_keydown) done = 1; } }.

Return 0; }.

El resultado de ejecutar el programa ejemplo3_2 es el siguiente:


La función encargada de realizar este trabajo tiene la siguiente forma:
Int sdl_setalpha (sdl_surface *surface, uint32 flag, uint8 alpha).

Como ves, es muy parecida a sdl_setcolorkey. En el caso del parámetro flag, los posibles valores son 0, para desactivar el alpha, sdl_srcalpha para indicar que el tercer parámetro de la función es el alpha que queremos aplicar a la superficie y sdl_rleacel que se aplica junto a sdl_srcalpha para activar la aceleración RLE. El tercer parámetro es el nivel de alpha que queremos aplicar. Puede variar de 0 a 255. Esta función devuelve 0 si todo fue bien, y -1, en caso de error, otras funciones de interés.

No quisiera terminar esta sección sobre el video en SDL sin presentarte algunas funciones más que sin duda antes o después te serán útiles.

Vamos a empezar por un par de funciones que nos van a permitir definir zonas de clipping.

O recorte. Veamos en que consiste el clipping con un ejemplo. Supongamos que vamos a hacer un simulador de vuelo. En la parte inferior de la pantalla estarán los mando del avión, en la parte superior habrá indicadores, y finalmente en la parte central de la pantalla esta la zona donde se desarrolla la acción del juego. En cada ciclo de juego, hay que redibujar esta zona, pero no el resto de la pantalla (panel de control, indicadores). Con la función sdl_setcliprect podemos decirle a SDL que cualquier operación gráfica que se realice quedará dentro de este rectángulo. Si el gráfico es mayor que este recuadro, se recorta. El formato de la función es:
Void sdl_setcliprect(sdl_surface *surface, sdl_rect *rect).

El primer parámetro es la superficie sobre la que queremos efectuar el clipping, y el segundo ya debería serte familiar, es el rectángulo dentro del cual queremos permitir el volcado gráfico.

Añade las siguientes líneas al ejemplo anterior justo después de la inicialización del modo gráfico.

Sdl_rect clip_rect.

Clip_rect.x=100, clip_rect, y=100;
Clip_rect.w=440, clip_rect, h=280, sdl_setcliprect(screen,&clip_rect).

Básicamente definimos un área rectangular de clipping que comienza en la posición (100,100) y tiene una anchura de 440 píxeles y una altura de 280 píxeles.



Figura3.4.

Para conocer que área de clipping tiene una superficie podemos usar la siguiente función:
Void sdl_getcliprect(sdl_surface *surface, sdl_rect *rect).

Como ves, el formato es idéntico al de sdl_setcliprect, con la diferencia de que está función rellenara la estructura rect con los datos del área de clipping.

La siguiente función en la que vamos a detenernos es la siguiente:
Sdl_surface *sdl_convertsurface (sdl_surface *src, sdl_pixelformat *fmt, uint32 flags).

Su misión es básicamente convertir una superficie al mismo formato de píxel que otra. Esto acelera las operación de blitting, ya que si dos superficies tienen diferente formato de píxel, SDL hace la conversión cada vez durante el blitting. El primer parámetro es la superficie que queremos convertir. El segundo, es el formato del píxel de la superficie a la que queremos convertir la primera. Como ya vimos antes, el formato del píxel de una superficie se encuentra en el campo format de la superficie (superficie>format). El tercer parámetro puede contener exactamente los mismo valores que la función sdl_creatergbsurface que vimos al principio de esta sección.

Por último, (por ahora) quiero presentaros la siguiente función:
Sdl_videoinfo *sdl_getvideoinfo (Void).

Su misión es devolvernos información sobre el modo de video actual. Si aún no se ha inicializado un modo de video, nos devuelve el mejor modo disponible (siempre según SDL). Esta función no tiene parámetros, y devuelve el resultado en una variable de tipo sdl_videoinfo, que tiene la siguiente estructura:
Typedef structure{ uint32 hw_available:1, uint32 wm_available:1, uint32 blit_hw:1, uint32 blit_hw_c:1, uint32 blit_hw_a:1, uint32 blit_sw:1, uint32 blit_sw_c:1, uint32 blit_sw_a:1, uint32 blit_fill, uint32 video_mem, sdl_pixelformat *vfmt.
} sdl_videoinfo.

El significado de cada campo es el siguiente:
Hw_available indica si se pueden crear superficies en memoria de video.
Wm_available indica si hay un manejador de ventanas disponible.

Blit_hw indica si el blitting hardware hardware esta acelerado, blit_hw_c indica si el blitting con transparencias hardware - hardware esta acelerado, blit_hw_a indica si el blitting con alpha hardware - hardware esta acelerado, blit_sw indica si el blitting software hardware esta acelerado, blit_sw_c indica si el blitting con transparencias software - hardware esta acelerado, blit_sw_a indica si el blitting con alpha software - hardware esta acelerado, blit_fill indica si el reellenado de color esta acelerado, video_mem cantidad de memoria total en kilobites. Vfmt puntero a la estructura sdl_pixelformat que contiene el formato de píxel del.

Sistema gráfico.

En el tintero nos dejamos muchas cosas sobre el video, pero ya tenemos las herramientas necesarias para comenzar a programar videojuegos. En la documentación de la librería SDL puedes encontrar información sobre muchos más tópicos que no hemos tratado aquí, como trabajo con paletas de color, acceso directo a las superficies, etc. Con los conocimientos que ahora tienes deberías poder seguir sin problema está documentación, gestión de eventos.

La gestión de eventos de SDL es realmente cómoda y fácil de usar. Seamos sinceros, si te las has visto con el sistema de eventos de Windows, SDL te va a parecer un juego de niños. El subsistema de eventos de SDL se inicia junto al subsistema de video, por lo que no hay que inicializarlo expresamente. Todo esto está muy bien, pero ¿Qué es un evento? Bien, en general, un evento es algo que sucede durante la ejecución del programa.
¿Algo que sucede? ¿Qué respuesta es esa? Vale, vale, espera que te explique. En SDL, un evento esta asociado a una acción del usuario sobre la aplicación que se está ejecutando. Como sabes, para interactuar con un ordenador usamos periféricos de entrada, como un teclado, un ratón, tipos de eventos.

Teclado.

El teclado es el principal dispositivo de entrada, aunque algunos se empeñen en que sea el ratón. Ahora, mientras tecleo estas líneas, lo estoy utilizando, y no puedo imaginar un dispositivo más cómodo para esta tarea.

Cada vez que pulses una tecla, SDL crea un evento que indica, no sólo que se pulsó una tecla, también cual fue. Más concretamente SDL lanza un evento cada vez que se pulsa una tecla y también cuando de suelta. También nos informa sobre si hay alguna tecla especial pulsada como Control, Alt o shift.

Ratón.

El otro gran dispositivo de entrada es el ratón, quizás más adecuado para ciertos tipos de juegos que el teclado. Hay dos tipos de eventos que devuelve el ratón, uno referente al movimiento y el otro referente al estado de los botones. En lo referente al movimiento, SDL nos informa sobre la posición del puntero, así como de la distancia que ha recorrido desde el último evento de ratón. En lo referente a los botones, el evento contiene información sobre si se ha pulsado o se ha soltado un botón del ratón, y por supuesto, cuál de ellos fue.

Joystick.

Sin duda, el joystick es el rey de los periféricos para jugar. Sin embargo, en el PC no existe un estándar, y hay multitud de ellos. Debido a esto, SDL tiene un subsistema completo dedicado al joystick. Desgraciadamente, y quizás por no ser un periférico estándar, no está muy extendido. Los eventos que se generaran van a depender del joystick. En principio los principales son el movimiento del joystick y la pulsación de los botones. Algunos joystick pueden generar otro tipo de eventos, pero vamos a centrarnos en estos dos, que son lo más comunes.

Otros eventos.

También podemos conocer eventos relacionados con el sistema operativo, y que nos van a ser muy útiles. Sin duda el más importante es el que nos indica que se va a cerrar el juego (o que se va a cerrar la ventana del juego). Otros importantes son los referidos al cambio de tamaño de la ventana (si es que nuestro juego se está ejecutando en una ventana) o el que nos indica que debemos redibujarla (por cualquier motivo relacionado con el so, como, por ejemplo, que se superpuso una ventana de otra aplicación,), lectura de eventos.

Podemos interrogar al sistema por los eventos de tres formas posibles. Podemos esperar a que ocurra cierto evento para realizar una acción concreta, por ejemplo, un programa puede quedar a la espera de que pulsemos un botón en un cuadro de diálogo.

También podemos acceder al hardware directamente y leer el estado del dispositivo. Esto no te lo aconsejo a no ser que te guste hacer las cosas de la forma más difícil.

El tercer método es el llamado polling. Con este método los eventos se van almacenando, y pueden ser consultados en el momento que nos convenga. Esto cuadra muy bien con la forma en que funciona un juego. Acuérdate del game loop, en el que leíamos la entrada del jugador, la procesábamos, hacíamos cálculos, movimientos o cualquier otra cosa y vuelta a empezar.

La función que nos permite leer el siguiente evento disponible es:
Int sdl_pollevent(sdl_event *event).

Esta función devuelve 1 si había un evento pendiente y 0 en caso contrario. Si hay algún evento disponible se almacena en el parámetro event. Como veremos a continuación, hay diferentes tipos de evento. Afortunadamente todos tiene un campo en común, que es el campo type (en realidad es una unión de c que contiene las diferentes estructuras para los diferentes eventos), por lo que podemos consultar el tipo de evento del que se trata. En el ejemplo3_1 y ejemplo3_2 puedes ver un ejemplo de cómo se utiliza esta función, eventos del teclado.

Cada vez que se produce un evento de teclado (pulsar o soltar una tecla) este se almacena en la estructura sdl_keyboardevent que tiene la siguiente forma:
Typedef structure{.

Uint8 type.

Uint8 state.

Sdl_keysym keysym; } sdl_keyboardevent.

El campo type puede tomar los valores sdl_keydown o sdl_keyup para indicar si el evento corresponde a una pulsación o si por el contrario se soltó la tecla.

El campo state es redundante con el primero, ya que, contiene exactamente la misma información, por lo que podemos ignorarlo tranquilamente. Para los más curiosos, los valores posibles de este campo son sdl_presed o sdl_released.

El siguiente campo nos indica cual fue la tecla pulsada. Este campo es de tipo sdl_keysym que es una estructura que tiene el siguiente formato:
Typedef structure{.

Uint8 scancode.

Sdlkey sym.

Sdlmod mod.

Uint16 unicode; } sdl_keysym.

El primer campo es un código que genera el teclado (es decir, un código generado por el hardware). Puede cambiar de un sistema a otro, por lo que si quieres que tú juego pueda ejecutarse en otras plataformas será mejor que no lo uses. El campo sym es el más interesante de la estructura, ya que, contiene un código identificativo de la tecla pulsada, pero al contrario que scancode, este código es generado por SDL y por lo tanto es igual en todas las plataformas. A continuación se muestra el listado de códigos sym.









El campo mod (de modificador) es un campo de bits que nos hablan del estado de ciertas teclas especiales como Control, alt, shift, etc. Su posibles valores son:
Kmod_none ningún modificador.

Kmod_num Num Lock esta pulsado.

Kmod_caps capslok esta pulsado.

Kmod_lctrl control izquierdo esta pulsado.

Kmod_rctrl control derecho esta pulsado.

Kmod_rshift shift derecho esta pulsado.

Kmod_lshift shift izquierdo esta pulsado.

Kmod_ralt Alt derecho esta pulsado.

Kmod_lalt Alt iquierdo esta pulsado.

Kmod_ctrl cualquier control esta pulsado.

Kmod_shift cualquier shift esta pulsado.

Kmod_alt cualquier Alt esta pulsado.

El último campo contiene el carácter unicode de la tecla pulsada. Por defecto este campo no se rellena, ya que la traducción conlleva cierta sobrecarga, por lo que asegúrate de activarlo sólo si lo necesitas. Para activar este campo usamos la siguiente función:
Int sdl_enableunicode (int enable).

Esta función devuelve el anterior estado antes del cambio. El parámetro enable pude tomar tres valores: 0 para desactivar la traducción unicode, 1 para activarla y -1 para dejar el estado como esta. Esto nos sirve para conocer el estado mediante el valor de retorno de la función.

Si los 9 bits más altos del código están a 0, es un carácter ascii. El siguiente código nos devuelve el carácter ASCII en la variable ch (en caso de que no sea un carácter unicode).

Char ch, if ((keysym.unicode & 0xf80) == 0) {.

Ch = keysym.unicode & 0 por 7f; }else {.

Printf(es un carácter unicode.\n), }.

Tanto en el ejemplo3_1, como en el ejemplo3_2 de la sección anterior sobre el video, puedes ver un ejemplo de lectura del teclado. Ahora deberías poder entender este código sin ningún problema.

Podemos, además de consultar el teclado mediante eventos, hacer una consulta directa al teclado para conocer su estado actual. Es cómo hacer una fotografía del estado del teclado en un momento dado. La siguiente función realiza esta tarea:
Uint8 *sdl_getkeystate (int *numkeys).

Esta función nos devuelve un puntero a un array con el estado de cada una de las teclas del teclado. En el parámetro numkeys se devuelve el tamaño de este array. Normalmente le pasaremos el valor null como parámetro. Para consultar este array utilizamos las mismas constantes de teclado que vimos antes. Si la tecla estaba pulsada el valor almacenado en la posición del array correspondiente a la tecla es 1, si no estaba pulsada, será 0. Veamos con un ejemplo.

Uint8 *keys, keys=sdl_getkeystate (null).

If (keys[sdlk_up] == 1) {arriba (),} if (keys[sdlk_down] == 1) {abajo (),} if (keys[sdlk_left] == 1) {izquierda (),} if (keys[sdlk_right] == 1) {derecha (),} if (keys[sdlk_lshift] == 1) {disparo (),}.

Eventos de ratón.

Tal y como comentamos al inicio de esta sección, el ratón puede proporcionar dos tipos de eventos. El referente al movimiento y el referente a la pulsación de los botones. Cuando sucede un evento de movimiento de ratón, el subsistema de eventos nos devuelve una estructura de tipo sdl_mousemotionevent.

Typedef structure{ uint8 type, uint8 state, uint16 x, y, sint16 xrel, yrel.
} sdl_mousemotionevent.

El primer campo ya lo conocemos. Su único posible valor es sdl_mousemotion. El campo state devuelve el estado de los botones del ratón. Es una campo de bits que puede ser consultado cómodamente con la macro sdl_buton(), pasando como parámetro 1,2 o 3 para indicar botón izquierdo, central o derecho. X e y son las coordenadas del ratón. Xrel e yrel son la posición relativa respecto al último evento de ratón.

El otro tipo de evento relacionado con el ratón es el referente a la pulsación de los botones. Cuando se pulsa un botón del ratón se crea un evento del tipo sdl_mousebuttonevent.

Typedef structure{ uint8 type, uint8 button, uint8 state, uint16 x, y.
} sdl_mousebuttonevent.

El campo type puede tomar los valores sdl_mousebutondown o sdl_mousebutonup para indicar si se pulsó o se soltó el botón. El campo button puede tomar los valores sdl_buton_left, sdl_buton_midle, sdl_buton_right para indicar que se pulsó (o se soltó) el botón izquierdo, central o el derecho. El campo state contiene la misma información que el campo type, por lo que podemos ignorarlo. Sus posibles valores son sdl_presed o sdl_released. Por último, los campos x e y contienen las coordenadas del ratón en el momento que se produjo el evento, eventos del joystick.

En esta sección vamos a ver cómo el subsistema de eventos se comunica con el joystick. Cuando lleguemos a la sección del subsistema de gestión del joystick entraremos más en profundidad. Vamos a ver sólo dos de los eventos del joystick, el referente al movimiento del joystick y el referente a la pulsación de los botones. El primero de ellos genera un evento del tipo sdl_joyaxisevent que tiene la siguiente forma:
Typedef structure{ uint8 type, uint8 which, uint8 axis, sint16 value.
} sdl_joyaxisevent;
El campo type contiene el valor sdl_joyaxismotion. El segundo campo nos indica que joystick produjo el evento, si es que tenemos más de uno conectado al ordenador. El campo axis nos dice que eje se movió, y por último, value nos devuelve el valor de este movimiento dentro del rango que va de 32768 hasta 32767.

El otro tipo de evento relacionado con el joystick es.

Sdl_joybuttonevent.

Typedef structure{ uint8 type, uint8 which, uint8 button, uint8 state.
} sdl_joybuttonevent.

El campo type puede tomar los valores sdl_joybutondown o sdl_joybutonup. Los dos campos siguientes son idénticos al del evento sdl_joyaxisevent. El último campo puede tomar los valores sdl_presed o sdl_released. Para poder utilizar la gestión de eventos del joystick hemos de activar esta opción antes con la siguiente función:
Int sdl_joystickeventstate (int state).

Los posibles valores de state son sdl_query, sdl_enable o sdl_ignore. Con la primera consultamos el estado actual (activado o desactivado). Las otras dos opciones son para activar y desactivar la lectura del joystick mediante eventos. Si como parámetro le pasamos sdl_query a la función, nos devolverá el estado actual, si no, nos devolverá el nuevo estado. En la sección dedicada al joystick profundizaremos más, otros eventos.

Uno de los eventos más importantes es sdl_quitevent. Este evento sucede cuando el sistema operativo quiere cerrar la aplicación (ya sea porque el usuario ha cerrado la ventana del juego o porque simplemente el so lo decidió así por alguna oscura razón).

Typedef structure{ uint8 type } sdl_quitevent.

La estructura sólo tiene el campo type, que tomara el valor sdl_quit. Cuando se recibe este evento, hay que realizar las operación necesarias para cerrar la aplicación, como liberar memoria, guardar datos.

El siguiente evento que vamos a ver es sdl_exposeevent ya que tiene exactamente la misma forma que sdl_quitevent.

Typedef structure{ uint8 type } sdl_exposeevent.

El campo type contendrá el valor sdl_videoexpose. Este evento se genera cuando el gestor de ventanas (Windows, KDE,) ha realizado alguna modificación en las ventanas (ya sea por que el usuario ha movido alguna ventana o por que simplemente el gestor de ventanas a realizado un refresco) y nuestra aplicación necesita ser redibujada.

Relacionado también con el gestor de ventanas tenemos el evento.

Sdl_resizeevent.

Typedef structure{ uint8 type, int w, h.
} sdl_resizeevent.

Este evento se genera cuando la ventana cambia de tamaño (si es que el juego se está ejecutando en una ventana). Normalmente, si esto sucede tendremos que recalcular la posición de los elementos del juego. El campo type contiene el valor sdl_videoresize. Los campos w y h son la nueva anchura y altura de la ventana.

Vamos a terminar con el evento sdl_activeevent. En un entorno multiventana, el usuario puede pasar de una aplicación a otra. La forma de conocer si tenemos la atención del usuario es mediante este evento.

Typedef structure{ uint8 type, uint8 gain, uint8 state.
} sdl_activeevent.

El primer campo tendrá el valor sdl_activevent. El campo gain valdrá 1 si la aplicación a retomado la atención o 0 si la perdíó. Por último, pero no por ello, menos importante tenemos el campo state, que nos amplía más información sobre el campo gain. Sus posibles valores son: sdl_apmousefocus si se ganó (o perdió, según el campo gain) el foco del ratón, es decir, si el ratón entró (o salió) del área de la ventana de nuestra aplicación. Sdl_apinputfocus si se ganó (o perdió) el foco de entrada por teclado. Sdl_apactive si la aplicación fue maximizada (o minimizada), joystick.

Ya hemos visto cómo se puede consultar el joystick mediante la consulta de eventos. En esta sección vamos a profundizar en el uso del joystick. Al igual que con el teclado, el joystick también puede ser consultado de forma directa. Además, de conocer el estado del joystick, nos puede interesar conocer otras informaciones, como, por ejemplo, cuantos joystick hay conectados (si es que hay alguno), que características tiene, cuantos botones.

Vamos a centrarnos exclusivamente en los ejes y en los botones del joystick. El concepto de eje es muy simple. Cuando movemos la palanca de mando hacia arriba o hacia abajo, estamos moviendo el joystick sobre el eje vertical. De la misma forma, al mover el mando de forma lateral lo movemos sobre el eje horizontal. Por lo tanto, un joystick clásico tiene dos ejes. Si en vez de un joystick clásico tenemos un paddle (recuerda el clásico juego de raquetas pong, con un mando giratorio que movía la raqueta), este sólo constara de un eje. Para poder utilizar el joystick desde SDL tenemos que inicializarlo con el flag sdl_init_joystick. Antes de entrar en las funciones que nos van a permitir consultar los estados del joystick, vamos a ver algunas dedicadas a mostrar información sobre él, recopilando información sobre el joystick.

Lo primero que necesitamos saber es si hay algún joystick conectado al ordenador, y en su caso, cuantos hay. La siguiente función nos probé esta información:
Int sdl_numjoysticks(Void).

El valor devuelto por esta función es el número de joystick conectados al ordenador. Otra información que puede sernos útil es la siguiente:

Const char *sdl_joystickname (int index).

Nos devuelve un puntero a una cadena que contiene el nombre del joystick o su driver. El parámetro index es el número de joystick queremos consultar.

Una vez que conocemos el número de joystick conectados al ordenador, es el momento de utilizarlos. Lo primero que hay que hacer es abrirlos.

Sdl_joystik *sdl_joystickopen(int index).

Como en la anterior función, index es el número del joystick queremos abrir. La función devuelve un puntero del tipo sdl_joystick. No vamos a entrar en detalle sobre esta estructura de datos. Simplemente saber que el tipo devuelto es el que usaremos en las siguientes funciones para referirnos al joystick acabamos de abrir.

Como abras adivinado, SDL dispone de otra función para cerrar el joystick.

Void sdl_joystickclose (sdl_joystik *joystick).

Como parámetro hay que pasarle el puntero que nos devolvió la función sdl_joystickopen al abrir el joystick. Es importante que cerremos el joystick antes de finalizar el programa (en realidad es importante que cerremos todo lo que inicialicemos en un programa).

Si tenemos más de un joystick conectados, nos puede resultar interesante saber cuáles están abiertos y cuáles no. La función sdl_joystickopened nos ofrece esta información:
Int sdl_joystickopened(int index).

El parámetro index es el número de joystick queremos consultar. Esta función devuelve 1 si el joystick consultado esta abierto y 0 en caso contrario.

Nos queda ver un par de funciones vitales antes de entrar en harina.

Int sdl_joysticknumaxes(sdl_joystik *joystick),
Int sdl_joysticknumbuttons(sdl_joystik *joystick).

Estas funciones nos devuelven el número de ejes y el número de botones respectivamente que tiene el joystick. Como parámetro le pasamos el joystick queremos consultar (el valor devuelto por sdl_joystickopen).

Leyendo el joystick.

Como comentamos al principio de la sección, nos vamos a centrar en la lectura de los ejes y de los botones. Si quieres profundizar, puedes remitirte a la documentación de SDL.

Antes de consultar el estado del joystick, hay que hacer una llamada a la función sdl_joystickupdate.

Void sdl_joystickupdate (Void).

Esta función, que no toma ni devuelve ningún parámetro, actualiza el estado de los joystick abiertos. Antes de cada lectura de estado hay que hacer una llamada a esta función.

El estado de los ejes del joystick lo consultamos con la siguiente función:
Sint16 sdl_joystickgetaxis(sdl_joystik *joystick, int axis).

Como parámetros le indicamos el joystick y el eje que queremos consultar. Nos devolverá el valor del estado del eje. Este valor estará entre 32768 y 32768. Para la consulta de los botones utilizaremos la función.

Uint8 sdl_joystickgetbutton(sdl_joystik *joystick, int button).

Esta función es similar a la anterior, sólo que en vez del eje a consultar, le pasamos el botón a consultar. El valor devuelto puede ser 1, el botón esta pulsado y 0 en caso contrario. El siguiente ejemplo (ejemplo3_3) muestra el uso del joystick.
/***************************************** ejemplo3_3.
(C) 2003 by Alberto García serrano programación de videojuegos con SDL *****************************************/.
#include <stdio, h> #include <stdlib, h> #include <sdl.h>.

Int main(int argc, char *argv) {.

Sdl_surface *image, *screen, sdl_rect dest, sdl_event event, sint16 joyx, joyy, sdl_joystik *joystick, int done = 0, int x y, button.

Atexit(sdl_quit).
// iniciar SDL.

If (sdl_init(sdl_init_video|sdl_init_joystick) < 0) { printf(no se pudo iniciar SDL: %s\n,sdl_geterror()), exit(1).
}.
// activamos modo de video screen = sdl_setvideomode (640,480,24,sdl_hwsurface), if (screen == null) {.

Printf(no se puede inicializar el modo gráfico: \n,sdl_geterror()), exit(1), }.
// activa el joystick.

If (sdl_numjoysticks() >= 1) { joystick = sdl_joystickopen(0), sdl_joystickeventstate (sdl_enable).
}.
// cargamos gráfico image = sdl_loadbmp(nave, bmp).

If (image == null) { printf(no pude cargar gráfico: %s\n, sdl_geterror()), exit(1).
}.
// definimos color para la transparencia sdl_setcolorkey(image,sdl_srcolorkey|sdl_rleacel,s dl_maprgb(image>format,255,0,0)).

X = y = 100, button = 0.
While (done == 0) {.
// borramos la pantalla dest.x=0, dest, y=0, dest.w=640, dest, h=480, sdl_fillrect(screen,&dest,sdl_maprgb(screen>format ,0,0,0)).
// definimos donde dibujaremos el gráfico // y lo copiamos a la pantalla, dest.x = x, dest, y = y, dest.w = image>w, dest, h = image>h, sdl_blitsurface (image, null, screen, &dest).
// mostramos la pantalla sdl_flip(screen).
// lectura directa del joystick joyx = sdl_joystickgetaxis(joystick, 0), joyy = sdl_joystickgetaxis(joystick, 1).

If (joyy < 10) {y=5;} if (joyy > 10) {y+=5;} if (joyx < 10) {x=5;} if (joyx > 10) {x+=5;}.
// lectura de eventos while (sdl_pollevent(&event)) {.
// salir del programa si se pulsa el botón del joystick if (event, type == sdl_joybutondown) { done = 1; }.
// salir del programa si se pulsa una tecla // o se cierra la ventana if (event, type == sdl_keydown || event, type == sdl_quit).

Done = 1; } }.
// liberar superficie sdl_fresurface (image).
// cerramos el joystick if (sdl_joystickopened(0)) { sdl_joystickclose (joystick), }.

Return 0; }.

Este ejemplo muestra nuestro ya familiar avión y, además nos permite moverlo con el joystick por la pantalla. Para ilustrar las dos formas de acceder al joystick (mediante consulta de eventos o de forma directa), hacemos la consulta de los ejes (movimiento) mediante consulta directa y la lectura del botón del joystick la hacemos mediante la consulta de eventos. Para salir sólo hay que pulsar cualquier tecla o el botón del ratón, audio.

Créeme, no querrás depender exclusivamente del subsistema de audio de SDL para el sonido de tu juego. En comparación con el resto de los subsistemas, el audio de SDL es bastante espartano (y no precisamente porque sea del sur del peloponeso). Afortunadamente, hay una librería llamada sdl_mixer que nos va a hacer la vida más fácil. La vamos a utilizar en el juego que desarrollaremos en próximos capítulos, y a menos que alguien tenga una acentuada tendencia masoquista, la mayor parte de los juegos creados con SDL la usan. Vamos a pasar de puntillas sobre este subsistema, y en el próximo capítulo presentaremos sdl_mixer y sus virtudes. Empecemos por la estructura de datos sdl_audiospec.

Typedef structure{.

Int freq.

Uint16 format.

Uint8 channels.

Uint8 silence.

Uint16 samples.

Uint32 size.

Void (*call-back)(Void *userdata, uint8 *stream, int len).

Void *userdata; } sdl_audiospec.

Esta estructura especifica el formato de audio que vamos a utilizar. Veamos más detalladamente cada campo.

El primero es freq, que especifica la frecuencia (en hertzios) de reproducción del sample. Valores habituales son 11025 (calidad telefónica), 22050 (calidad radiofónica) o 44100 (calidad CD).

El campo format especifica el formato del sample (bits y tipo). Los posibles valores son:
Audio_u8 sample de 8 bits sin signo audio_s8 sample de 8 bits con signo audio_u16 o audio_u16lsb sample de 16 bits sin signo en formato littlendian. Audio_s16 o audio_s16lsb sample de 16 bits con signo en formato littlendian. Audio_u16msb sample de 16 bits sin signo en formato bigendian. Audio_s16msb sample de 16 bits con signo en formato bigendian. Audio_u16sys audio_u16lsb o audio_u16msb dependiendo del peso de tu sistema (big o Little endían) audio_s16sys audio_s16lsb o audio_s16msb dependiendo del peso de tu sistema (big o Little endían).

El campo channels indica el número de canales de audio. Pueden ser 1 para mono y 2 para estéreo.

El campo silence, es un valor calculado que representa el valor para silencio.

El siguiente campo es samples, y contiene el tamaño del buffer de audio en samples.

El campo size, es el tamaño del buffer, pero esta vez en bytes. Es un campo calculado, así que, no debemos preocuparnos por el. El campo que sigue es un puntero a una función de retrollamada, que es la función llamada cuando es necesario reproducir el sonido. Efectivamente, tal y como estas pensando, somos nosotros los encargados de desarrollar esta función. Su cometido es rellenar el buffer contenido en el puntero stream, con una cantidad de bytes igual a len. En principio puede parecer que no es una tarea demasiado compleja ¿verdad? Está bien, si quieres reproducir un solo sonido aislado es probable que no, pero el 99% de las veces necesitarás mezclar varios sonidos (por ejemplo, una música con una explosión, o simplemente un disparo y una explosión). Aunque SDL nos ofrece una forma de hacerlo, no es demasiado efectivo, de hecho, si quieres una calidad decente, tendrás que programar tu propia función de mezcla, y créeme, no querrás tener que hacerlo.

El campo userdata es el mismo que se le pasa a la función de retrollamada. Podemos pasar información a nuestra función en caso necesario. Vayamos ahora con las funciones de manejo de audio.

Int sdl_openaudio (sdl_audiospec *desired, sdl_audiospec *obtained).

Tal y como habrás adivinado, esta función abre el dispositivo de audio. Como parámetros tiene dos punteros de tipo sdl_audiospec. En el primero le solicitamos las especificaciones con las que queremos trabajar. Esta función intentara abrir el dispositivo de audio con las especificaciones que le pidamos, aunque esto no siempre será posible. En cualquier caso, obtained apuntara a las especificaciones finales que la función ha podido conseguirnos. Si todo fue bien, nos devolverá 0, en caso contrario, 1.

Como casi todo en SDL (y también en la vida cotidiana), todo lo que abrimos, hay que cerrarlo. La función encargada de esto es:
Void sdl_closeaudio (Void).

Como no tiene ningún parámetro ni devuelve ningún valor, es una candidata perfecta para usarla con la función atexit.

Una vez abierto es dispositivo de audio, necesitamos una función para iniciar y para el audio. Aquí la tenemos:
Void sdl_pauseaudio (int pause_on).

Cuando pasamos como parámetro el valor 0, activamos la reproducción de sonido. Si pasamos un 1, hacemos una pausa.

Por último, veamos un par de funciones que nos permiten el trabajo con archivos en formato.wav:
Sdl_audiospec *sdl_loadwav(const char *file, sdl_audiospec *Spec, uint8 **audio_buf, uint32 *audio_len).

Void sdl_frewav(uint8 *audio_buf).

La primera función carga un archivo en formato.wav en memoria. El primer parámetro es una cadena con el nombre del archivo. Si todo fue bien, nos devolverá un puntero a la estructura sdl_audiospec del fichero.wav. En audio_buf se encuentra la información del sample, y en audio_len su tamaño. Como ves, todo listo para pasárselo a la función de retrollamada. La segunda función libera el espacio ocupado por el sample. El ejemplo3_4 nos aclara un poco la forma de utilizar el subsistema de audio. Lo que hace es reproducir un sonido aleatorio. Este código es muy sencillo y permite ver cómo utilizar la función de retrollamada. En el próximo capítulo aprenderemos cómo hacer sonar a SDL con la ayuda de sdl_mixer.
/***************************************** ejemplo3_4.
(C) 2003 by Alberto García serrano programación de videojuegos con SDL *****************************************/.
#include <stdlib, h> #include <sdl, h>.

Sdl_surface* superficie, sdl_event event, sdl_audiospec* deseado, sdl_audiospec* obtenido, int done.
// declaración de la función de retrollamada Void retrollamada (Void* userdata,uint8* buffer, int len).

Int main(int argc, char* argv) {.
// inicializamos SDL.

If (sdl_init(sdl_init_video|sdl_init_audio) < 0) { printf(no se pudo inicializar SDL.\n), exit(1).
}.
// inicializamos modo de video // (en Windows es necesario para que funcione el audio) if ((superficie = sdl_setvideomode (640,480,0,sdl_anyformat)) == null) {.

Printf(no se pudo inicializar la ventana.\n), exit(1), }.
// alojamos espacio para almacenar las estructuras deseado=new sdl_audiospec, obtenido=new sdl_audiospec.
// especificaciones deseadas deseado>freq=11025, deseado>format=audio_s16sys, deseado>channels=1, deseado>samples=4096, deseado>call-back=retrollamada, deseado>userdata=null.
// abrimos el dispositivo de audio.

If(sdl_openaudio (deseado, obtenido)<0) { printf(no puedo abrir el dispositivo\n), deleete deseado, deleete obtenido, exit(1).
}.

Atexit (sdl_closeaudio).

Deleete deseado.
// empieza a sonar. Sdl_pauseaudio (0).
// esperamos a que cierren la aplicación done = 0, while (.done) {.

If(sdl_pollevent(&event)==0) if(event, type==sdl_quit) done=1; }.

Deleete deseado.

Return(0), }.
// función de retrollamada // simplemente llena el buffer con información aleatoria, Void retrollamada (Void* userdata,uint8* buffer, int len) {.

Int i, for(i=0, i<len, i++) buffer[=Rand()%256; }.

Cdrom.
¿Te imaginas poder reproducir la música de tu juego desde una pista de audio del mismo CD en el que está grabado? Esto es realmente sencillo de hacer, ya que SDL nos ofrece acceso al dispositivo cdrom de forma sencilla. Como el resto de subsistemas de SDL, hay que indicar que queremos utilizar el subsistema de cdrom al inicializar SDL. Hay dos estructuras de datos que nos van a proporcionar información sobre el CD.

Typedef structure{.

Int id.

Cdstatus status.

Int numtracks.

Int cur_track.

Int cur_frame.

Sdl_cdtrak track[sdl_max_tracks+; } sdl_cd.

El campo id es un identificador único que identifica a cada CD. El campo status es un tipo enumerado que contiene los posibles estado del CD.

Cd_trayempty no hay ningún CD en el cdrom cd_stoped el CD esta detenido cd_playing el CD esta reproduciendo cd_paused el CD está en pausa cd_error hay un error el siguiente campo numtracks contiene el número de pistas del CD, cur_trak contiene la pista actual, y cur_frame es el frame actual dentro de la pista. Un frame es una medida interna del CD. Dado que el CD puede almacenar tanto audio como datos, no es posible usar como patrón de medida el tiempo o la capacidad. Un frame equivale aproximadamente a 2 kilobytes. Por último, tenemos un array con la información de cada pista. Una pista va descrita por la siguiente estructura:
Typedef structure{ uint8 id, uint8 type, uint32 length, uint32 offset.
} sdl_cdtrack.

El campo id es el número de la pista. El campo type puede tomar los valores sdl_audio_track o sdl_data_track. El primero nos indica que es una pista de audio, y el segundo que es una pista de datos. Los otros dos campos nos indican el tamaño de la pista en frames, y la posición de inicio de la pista también en frames. Antes de poder utilizar el CD, tenemos que tener alguna información al respecto, como el número de CD o el nombre asociado al dispositivo. Los dos funciones siguientes nos posibilitan recopilar dicha información:
Int sdl_cdnumdrives(Void).

Const char *sdl_cdname (int drive).

La primera función nos devuelve el número de cdroms conectados al sistema. La segunda nos devuelve una cadena con el nombre del cdrom. Como parámetro recibe el número del cdrom que queremos consultar. Como era de esperar, antes de poder utilizar el cdrom hay que abrirlo. La función encargada de esto es la siguiente:
Sdl_cd *sdl_cdopen(int drive).

Como parámetro le pasamos el cdrom que queremos abrir, y nos devolverá un puntero a una estructura sdl_cd con la información del CD. La función que cierra el cdrom es.

Void sdl_cdclose (sdl_cd *cdrom).

Como parámetro le pasamos el valor devuelto por sdl_cdopen al abrir el CD.

La función que nos permite conocer el estado del CD es sdl_cdstatus.

Cdstatus sdl_cdstatus(sdl_cd *cdrom).

Nos devolverá el estado actual del cdrom. Los posibles valores son los mismos que puede tomar el campo status de la estructura sdl_cd.

Las siguientes dos funciones que vamos a presentar nos permiten reproducir pistas del CD.

Int sdl_cdplay(sdl_cd *cdrom, int start, int length).

Int sdl_cdplaytracks(sdl_cd *cdrom, int start_track, int start_frame, int ntracks, int nframes)),
La primera función comienza la reproducción del CD en el frame indicado por start y durante los frames indicados por length. Si hay algún problema con la reproducción devuelve -1, si la reproducción tuvo éxito devolverá 0.

La función sdl_cdplaytracks reproduce una o varias pistas. Con el parámetro start_trak le indicamos la pista de inicio, y numtracks el número de pistas a reproducir. El parámetro start_frame es el frame, dentro de la pista, donde queremos iniciar la reproducción. Por último, nframes es el número de frames de la última pista que queremos reproducir.

Seguramente querrás poder comenzar la reproducción en un determinado momento expresado en tiempo en vez de en frames. Puedes usar la siguiente fórmula que nos devuelve la duración en segundos.

Longitud en frames / cd_fps.

La constante cd_fps contiene los frames por segundos del cdrom. Para finalizar, y antes de que veamos un ejemplo sobre el manejo del cdrom, vamos a ver cuatro funciones que requieren poca expliacción:
Int sdl_cdpause (sdl_cd *cdrom), int sdl_cdresume (sdl_cd *cdrom), int sdl_cdstop(sdl_cd *cdrom), int sdl_cdeject(sdl_cd *cdrom).

La primera función pone en pausa la reproducción del CD, mientras que sdl_cdresume continúa con la reproducción. Si queremos parar la reproducción usaremos la función sdl_cdstop, y con sdl_cdeject expulsaremos la bandeja del cd_rom.

El ejemplo siguiente reproduce la primera pista del CD que se encuentre en la primera lectora del sistema.
/***************************************** ejemplo3_5.
(C) 2003 by Alberto García serrano programación de videojuegos con SDL *****************************************/.
#include <stdlib, h> #include <sdl, h>.

Sdl_surface* superficie, sdl_event event, sdl_cd *cdrom, int pista = 0, int done.

Int main(int argc, char* argv) {.
// inicializamos SDL.

If (sdl_init(sdl_init_video|sdl_init_cdrom)<0) { printf(no se pudo inicializar SDL.\n), exit(1).
}.
// inicializamos modo de video.

If ((superficie = sdl_setvideomode (640,480,0,sdl_anyformat)) == null) { printf(no se pudo inicializar la ventana.\n), exit(1).
}.
// abrimos el primer cdrom del sistema.

If((cdrom = sdl_cdopen(0))<0) { printf(no puedo abrir el dispositivo\n), exit(1).
}.
// status CD CD sdl_cdstatus(cdrom).
// iniciamos la reproducción de la primera pista del CD.

If ((sdl_cdplay(cdrom, cdrom>track[pista].offset, cdrom>track[pista].length)) < 0) { printf(no puedo reproducir el CD\n), exit(1).
}.
// esperamos a que cierren la aplicación done = 0, while (.done) {.

If(sdl_pollevent(&event)==0) if(event, type == sdl_quit) done=1; }.
// detenemos la reproducción y cerramos el cdrom sdl_cdstop(cdrom), sdl_cdclose (cdrom), return(0).
}
El window manager.

Un window manager o gestor de ventanas es un programa que nos permite ejecutar aplicaciones dentro de ventanas, realizar acciones como cortar y pegar entre aplicaciones, mover y cambiar el tamaño de las ventanas, etc. En el caso de Windows, el gestor de ventanas forma parte del propio sistema operativo. En otros entornos, como Linux, podemos trabajar con el gestor de ventanas que más nos guste, como KDE o Gnome por nombrar los dos más conocidos. Habrás notado que todas las aplicaciones que hemos realizado hasta ahora, al ejecutarse mostraban el nombre sdl_app en la ventana. Este es el nombre por defecto. Podemos cambiar este nombre mediante la siguiente función:
Void sdl_wm_setcaption(const char *title, const char *icon).

Donde el primer parámetro es el título de la aplicación y el segundo el nombre del icono. En Windows este segundo parámetro no se utiliza. Podemos conocer los valores actuales con la siguiente función.

Void sdl_wm_getcaption(char **title, char **icon).

Para cambiar el icono de la aplicación podemos utilizar la función.

Void sdl_wm_seticon(sdl_surface *icon, uint8 *mask).

El primer parámetro es una surface que contiene el icono. En Windows este icono ha de tener una resolución de 32x32 píxeles. El segundo parámetro es un puntero a un array conteniendo la máscara de bits para el icono (esto es usado para definir la forma del icono y sus partes transparentes). Si como valor pasamos null, las transparencias estarán definias por el Color Key de la superficie. Veamos un ejemplo simple:
Sdl_wm_seticon(sdl_loadbmp(icon, bmp), null).

Si queremos minimizar la aplicación mientras se ejecuta, usaremos la función.

Int sdl_wm_iconifywindow(Void).

Si no se pudo minimizar la aplicación, esta función devolverá el valor 0.

Timming.

Vamos a terminar esta introducción a SDL con el control de tiempo. Dejamos sin tratar todo lo referido a multitarea y programación de hilos. Hay que saber bien lo que se está haciendo y tener, al menos, unos sólidos conocimientos sobre multitarea y sistemas operativos para sacar provecho a esta capacidad de SDL. Afortunadamente, no nos va a ser necesaria para crear videojuegos.

Lo que sí nos va a hacer falta es poder controlar el tiempo. Es una tarea esencial, ya que no todos los ordenadores funcionan a la misma velocidad. Si no controláramos el tiempo, nuestro juego funcionaría bien en algunos ordenadores, pero en otros (los más rápidos) iría a una velocidad endiablada. Vamos con la primera función.

Uint32 sdl_getticks(Void).

Esta función devuelve el número de milisegundos transcurridos desde que se inicializó SDL. Gracias a ella podemos controlar el tiempo transcurrido entre dos instantes dados dentro del programa, y por lo tan, controlar la velocidad del juego. Cuando desarrollemos el nuestro durante los próximos capítulos, podremos ver cómo controlar la velocidad de juego con esta función.

La función siguiente nos permite detener la ejecución del juego durante un tiempo determinado. Veamos que forma tiene.

Void sdl_delay(uint32 ms).

Como parámetro le pasamos a la función el número de milisegundos que queremos esperar. Dependiendo del sistema operativo, la espera será más o menos exacta, pero por regla general el error puede ser de 10ms.

Esta obra esta bajo una licencia attribution-noncommercial-noderivs 2.5 de Creative Commons. Para ver una copia de esta licencia, visite http://creativecommons.org/licenses/by-nc-nd/2.5/ o envíe una carta a Creative Commons, 559 Nathan Abbott way, stanford, california 94305, usa.

Por: Alberto García serrano.

[3dpoder]

Librerías auxiliares para SDL


el uso de las facultades que me concedió la naturaleza es el único placer que no depende de la ayuda de la opinión ajena.

Ugo foscolo.

Afortunadamente, además de las funciones que forman la librería SDL, podemos contar con una serie de librerías externas que nos van a ayudar bastante a la hora de programar nuestro juego. Las cuatro librerías auxiliares más habituales.

Son sdl_image, sdl_mixer, sdl_ttf y sdl_net. En el juego de ejemplo de este libro utilizaremos sdl_mixer para la reproducción del sonido y la música, y sdl_ttf para el manejo de fuentes de letra. Sdl_net es una librería que nos permite la conexión a redes TCP/IP, y es utilizada para crear juegos multijugador en red. Sdl_image es una curiosa librería con una única función, que nos permite trabajar con múltiples formatos gráficos, sdl_ttf.

Es muy posible que hayas echado de menos alguna función en SDL para escribir texto en la pantalla gráfica. La librería sdl_ttf nos permite, básicamente, dibujar el texto que deseemos en una superficie utilizando la fuente de letra que queramos. La fuente de letra tiene que ser en formato ttf (true type font). Como ya viene siendo habitual, lo primero que tenemos que hacer es inicializar la librería.

Int tf_init(Void).

Esta función devolverá 0 si se realizó correctamente la inicialización y -1 en caso contrario. Como algún avispado lector ya habrá supuesto, la función inversa tiene la siguiente forma:
Void tf_quit(Void).

Al no recibir ni devolver esta función ningún valor, es una candidata perfecta para utilizarla junto con la función atexit().

El siguiente paso es abrir la fuente que queremos utilizar, es decir, cargarla desde disco. Las dos siguientes funciones nos permiten abrir una fuente de letra.

Tf_font * tf_openfont(const char *file, int ptsize), tf_font * tf_openfontindex(const char *file, int ptsize, long index).

Ambas funciones devuelven un puntero a un tipo tf_font. No es necesario que entremos en detalle sobre su estructura interna, ya que nos vamos a limitar a pasar este puntero a las funciones encargadas de realizar el pintado del texto. El primer parámetro es el fichero a cargar (una fuente ttf). El segundo es el tamaño de la fuente. En la segunda función, tenemos además un parámetro adicional que es la fuente que queremos usar en caso de que el archivo ttf contenga más de un tipo de letra. Cuando hayamos terminado de utilizar la fuente hemos de cerrarla con la siguiente función.

Void tf_close (tf_font *font).

La función requiere poca explicación. Simplemente pasamos como parámetro la fuente que queremos cerrar.

El proceso de dibujar el texto en una superficie se llama render. Hay un total de 12 funciones dedicadas a este fin. Vamos a ver sólo 3 de ellas por ser las más habituales.

Sdl_surface * tf_rendertext_solid(tf_font *font, const char *text, sdl_color FG).

Sdl_surface * tf_rendertext_shaded(tf_font *font, const char *text, sdl_color FG, sdl_color bg).

Sdl_surface * tf_rendertext_blended(tf_font *font, const char *text, sdl_color FG).

Básicamente son iguales. Lo único que las diferencia es la calidad con la que es renderizado en texto. La primera función es la que ofrece menor calidad, y la última la que más. A mayor calidad, mayor tiempo necesita la función para realizar su cometido. Estas funciones devuelven un puntero a una superficie que contiene el texto dibujado. El parámetro font es un puntero a una fuente ya abierta con tf_openfont o tf_openfontindex. El parámetro text es la cadena de texto que queremos imprimir en la pantalla. El paramertro FG es el color de la fuente y bg es el color de fondo. Obsérvese que los colores se pasan a la función en formato sdl_color. Antes de ver un ejemplo completo del uso de sdl_ttf, vamos a ver un par de funciones que pueden sernos de utilidad.

Int tf_getfontstyle (tf_font *font).

Int tf_setfontstyle (tf_font *font, int style).

Estas funciones permiten conocer y seleccionar el estilo de texto que deseemos. Los posibles estilos son tf_style_bold para estilo negrita, tf_style_italic, para estilo italica, y tf_style_underline para estilo subrayado. El estado normal es tf_style_normal. El siguiente programa es un ejemplo de uso de sdl_ttf.
/************************************************** ************************* ejemplo4_1.
(C) 2003 by Alberto García serrano programación de videojuegos con SDL ************************************************** *************************/.
#include <stdio, h> #include <stdlib, h> #include <sdl.h> #include sdl_ttf, h.

Int main(int argc, char *argv) {.

Sdl_color bgcolor, fgcolor, sdl_rect rectángulo, sdl_surface *screen,*ttext, tf_font *fuente, const char texto[1=hola mundo, char msg[1, sdl_event event, int done = 0.
// inicializamos SDL.

If (sdl_init(sdl_init_video) < 0) { printf(no se pudo iniciar SDL: %s\n,sdl_geterror()), return 1.
}.
// inicializamos modo de video screen = sdl_setvideomode (640,480,24,sdl_hwsurface|sdl_doublebuf), if (screen == null) {.

Printf(no se puede inicializar el modo gráfico: \n,sdl_geterror()), return 1; }.

Atexit(sdl_quit).
// inicializamos sdl_ttf.

If (tf_init() < 0) { printf(no se pudo iniciar sdl_ttf: %s\n,sdl_geterror()), return 1.
}.

Atexit(tf_quit).
// carga la fuente de letra fuente = tf_openfont(ariblk, ttf,20).
// inicia colores para el texto fgcolor, r=200, fgcolor, g=200, fgcolor, b=10.

Bgcolor, r=255, bgcolor, g=0, bgcolor, b=0.

Sprintf(msg,%s, texto), ttext = tf_rendertext_shaded(fuente, msg, fgcolor, bgcolor), rectángulo, y=100, rectángulo.x=100, rectángulo.w=ttext>w, rectángulo, h=ttext>h.
// usamos color rojo para la transparencia del fondo sdl_setcolorkey(ttext,sdl_srcolorkey|sdl_rleacel, sdl_maprgb(ttext>format,255,0,0)).
// volcamos la superficie a la pantalla sdl_blitsurface (ttext,null, screen,&rectángulo).
// destruimos la fuente de letra tf_closefont(fuente).
// liberar superficie sdl_fresurface (ttext).
// esperamos la pulsación de una tecla para salir while (done == 0) { while (sdl_pollevent(&event)) { if (event, type == sdl_keydown) done = 1; } }.

Return 0; }.



Esto es lo que deberíamos ver al ejecutar el programa de ejemplo. Lo primero que hacemos es cargar la fuente arial black. Usando la función tf_rendertext_shade, creamos una superficie con el color de fondo rojo. Antes de hacer el blitting a la pantalla, establecemos el color rojo como transparente.

Sdl_image.

La librería sdl_image es extremadamente simple, de hecho, sólo tiene una función.

Sdl_surface * img_load(const char *file).

Esta función tiene exactamente el mismo cometido que sdl_loadbmp, es decir, cargar una imagen y almacenarla en una superficie. Recordemos, sin embargo, que sdl_loadbmp sólo podía cargar archivos en formato bmp. Afortunadamente, la función img_load puede manejar ficheros en formato bmp, pnm, (*.xpm), LBM, pcx, gif, (*.jpg), (*.png) y tga. Veamos a sdl_image en acción con un ejemplo.



/************************************************** ************************* ejemplo4_2.
(C) 2003 by Alberto García serrano programación de videojuegos con SDL ************************************************** *************************/.
#include <stdio, h> #include <stdlib, h> #include <sdl.h> #include sdl_image, h.

Int main(int argc, char *argv) {.

Sdl_surface *image, *screen.

Sdl_rect dest.

Sdl_event event.

Int done = 0.

Atexit(sdl_quit).
// iniciar SDL.

If (sdl_init(sdl_init_video) < 0) {.

Printf(no se pudo iniciar SDL: %s\n,sdl_geterror()).

Exit(1).
}.
// activamos modo de video.

Scren = sdl_setvideomode (640,480,24,sdl_hwsurface).

If (screen == null) {.

Printf(no se puede inicializar el modo gráfico: \n,sdl_geterror()).

Exit(1).
}.
// cargamos gráfico.

Image = img_load(Teapot.jpg).

If (image == null) {.

Printf(no pude cargar gráfico: %s\n, sdl_geterror()).

Exit(1).
}.
// definimos donde dibujaremos el gráfico.
// y lo copiamos a la pantalla.

Dest.x = 0.

Dest, y = 0.

Dest.w = image>w.

Dest, h = image>h.

Sdl_blitsurface (image, null, screen, &dest).
// mostramos la pantalla.

Sdl_flip(screen).
// liberar superficie sdl_fresurface (image).
// esperamos la pulsación de una tecla para salir while (done == 0) { while (sdl_pollevent(&event)) { if (event, type == sdl_keydown) done = 1; } }.

Return 0; }
Sdl_mixer.

No voy a volver a recordarte lo tedioso que es trabajar con el subsistema de audio de SDL. Sdl_mixer nos va a facilitar la tarea. Una de las mayores ventajas de sdl_mixer es que se encarga de realizar la mezcla de los canales de audio de forma automática. También puedes especificar tu propia función de mezcla, pero esto cae fuera del ámbito de este libro. Sdl_mixer distingue entre la reproducción de sonidos y la reproducción de la música del juego (para la que reserva un canal exclusivo). Los formatos válidos para la música son wav, voc, mod, s3m, it, xm, ogg vorbis, mp3 y midi.

Para poder utilizar sdl_mixer, tendrás que inicializar el subsistema de audio de SDL, es decir, al inicializar SDL con sdl_init, tendrás que incluir el flag sdl_init_audio. Lo primero que hemos de hacer es inicializar la librería.

Int mix_openaudio (int frequency, uint16 format, int channels, int chunksize).

Los parámetros de esta función son similares a los de la estructura sdl_audiospec.

El primero es freq, que especifica la frecuencia (en hertzios) de reproducción del sample. Valores habituales son 11025 (calidad telefónica), 22050 (calidad radiofónica) o 44100 (calidad CD).

El parámetro format especifica el formato del sample (bits y tipo). Los posibles valores son:
Audio_u8 sample de 8 bits sin signo audio_s8 sample de 8 bits con signo audio_u16 o audio_u16lsb sample de 16 bits sin signo en formato littlendian. Audio_s16 o audio_s16lsb sample de 16 bits con signo en formato littlendian. Audio_u16msb sample de 16 bits sin signo en formato bigendian. Audio_s16msb sample de 16 bits con signo en formato bigendian. Audio_u16sys audio_u16lsb o audio_u16msb dependiendo del peso de tu sistema (big o Little endían) audio_s16sys audio_s16lsb o audio_s16msb dependiendo del peso de tu sistema (big o Little endían)
El parámetro channels indica el número de canales de audio. Pueden ser 1 para mono y 2 para estéreo. Para chunksize, el valor habitual es 4096 según la documentación oficial de SDL. En breve veremos lo que es un chunk.

Esta función devuelve -1 si hubo algún error, y 0 en caso de que todo vaya bien. La función complementaria a mix_openaudio es la siguiente:
Void mix_closeaudio (Void).

Que recomiendo usar con atexit(). La misión de esta función, como bien debes saber, es finalizar la librería sdl_mixer, sonidos.

Te estarás preguntando que es eso de un chunk. Básicamente un chunque es un sonido.

O efecto sonoro. Sdl_mixer hace una abstracción y almacena cada efecto en un chunk. No vamos a entrar en detalles innecesarios, baste decir que la estructura de datos para almacenar estos chunks se llama mix_chunk. Una vez cargado un sonido en un chunk, la reproducción del sonido se llevara a cabo mediante un canal de audio, el cual, podremos especificar manualmente o dejar que sdl_mixer lo seleccione automáticamente. Cada canal puede reproducir simultáneamente un sólo sonido. Afortunadamente se soporta la reproducción de múltiples canales simultáneos, o lo que es lo mismo, de múltiples sonidos simultáneos.

Sin más preámbulos veamos esta bonita función:
Mix_chunque *mix_loadwav(char *file).

Sólo hay que indicarle a la función el archivo que queremos cargar. Si hubo algún error, la función devolverá null y en caso contrario tendremos un puntero a un tipo mix_chunk.

Cuando ya no necesitemos el sonido, es buena práctica liberar los recursos que utiliza. Lo hacemos con:
Void mix_frechunk(mix_chunque *chunk).

Basta con pasar como parámetro el chunque ha liberar. Respecto a los chunks, nos falta por ver una función.

Int mix_volumechunk(mix_chunque *chunk, int volume).

Efectivamente, esta función establece el volumen de reproducción del sonido. El volumen está dentro del rango de 0 a 128. Ahora que tenemos el sonido cargado en un chunk, podemos reproducirlo mediante un canal de audio. La función encargada de tal menester es:
Int mix_playchannel(int channel, mix_chunque *chunk, int loops).

Esta función reproduce el sonido apuntado por el puntero chunque en el canal señalado por el parámetro channel. El parámetro loops indica cuántas veces ha de repetirse el sonido. Si sólo queremos reproducirlo una vez, pasamos 0 como valor. Con -1 se reproducirá indefinidamente. Si queremos que sdl_mixer selecciones el canal de forma automática (es lo mejor, a no ser que quieras utilizar grupos de canales) hay que pasar - 1 como valor para el canal. Es conveniente informar a sdl_mixer de cuantos canales queremos utilizar. Lo hacemos con:
Int mix_allocatechannels(int numchannels).

Lo normal es que le pasemos tantos canales como sonidos simultáneos queramos poder reproducir. Te aconsejo que no te quedes corto. Por otro lado, mientras más canales, más recursos requerirá el audio.

Además, de mix_playchannel, disponemos de tres funciones más para reproducir sonidos.

Int mix_playchanneltimed(int channel, mix_chunque *chunk, int loops, int ticks).

Int mix_fadeinchannel(int channel, mix_chunque *chunk, int loops, int ms).

Int mix_fadeinchanneltimed(int channel, mix_chunque *chunk, int loops, int ms, int ticks).

La primera función es idéntica a mix_playchannel, con la diferencia de que el sonido se reproducirá durante los milisegundos indicados en el parámetro ticks.

La segunda función también realiza la reproducción del sonido, pero con un efecto de fade ascendente, es decir, el volumen del sonido ira aumentando desde 0 hasta el que corresponda al chunque de forma gradual. El tiempo que transcurrirá en ese aumento de volumen lo indicamos en con el parámetro ms. Este tiempo se expresa en milisegundos.

Por último, la tercera función no requiere demasiada explicación, ya que es la unión de las dos anteriores.

Mientras se reproduce un sonido, podemos pausarlo momentáneamente o pararlo. Las siguientes funciones nos permiten controlar la reproducción.

Void mix_pause (int channel).

Void mix_resume (int channel).

Int mix_haltchannel(int channel).

Int mix_fadeoutchannel(int channel, int ms).

Los nombres de las funciones son bastante descriptivos. Todas aceptan como parámetro un canal. La primera función pone en estado de pausa el canal indicado, mientras que la segunda función reanuda su reproducción. Las dos últimas funciones paran la reproducción del canal, con la diferencia de que mix_haltchannel para la reproducción en seco y mix_fadeoutchannel hace un efecto de fade contrario al de mix_fadeinchannel. Esta última función, además del canal, acepta un segundo parámetro que es el tiempo en milisegundos que durara el efecto de fade.

A veces nos puede ser útil conocer el estado de un canal concreto. Las siguientes funciones nos ayudan en este cometido.

Int mix_playing(int channel).

Int mix_paused(int channel).

La primera función devolverá 1 si el canal que pasamos como parámetro se está reproducciendo actualmente y 0 en el caso de que esté en silencio. La segunda función devolverá 1 si el canal se está reproduciendo y 0 si está en pausa. El siguiente código de ejemplo reproduce un sonido y espera a que el usuario pulse una tecla para terminar.
/************************************************** ************************* ejemplo4_3.
(C) 2003 by Alberto García serrano programación de videojuegos con SDL ************************************************** *************************/.
#include <stdio, h> #include <stdlib, h> #include <sdl.h> #include sdl_mixer, h.

Int main(int argc, char *argv) {.

Sdl_surface *screen, sdl_event event, mix_chunque *sonido, int done = 0, int canal.

Atexit(sdl_quit).
// iniciar SDL.

If (sdl_init(sdl_init_video|sdl_init_audio) < 0) { printf(no se pudo iniciar SDL: %s\n,sdl_geterror()), exit(1).
}.
// activamos modo de video screen = sdl_setvideomode (640,480,24,sdl_hwsurface), if (screen == null) {.

Printf(no se puede inicializar el modo gráfico: %s \n,sdl_geterror()), exit(1), }.
// inicializamos sdl_mixer.

If(mix_openaudio (22050, audio_s16, 2, 4096)) { printf(no se puede inicializar sdl_mixer %s\n,mix_geterror()), exit(1).
}.

Atexit(mix_closeaudio).
// cargamos sonido sonido = mix_loadwav(explosión.wav).

If (sonido == null) { printf(no pude cargar sonido: %s\n, mix_geterror()), exit(1).
}.
// reproducción del sonido. // esta función devuelve el canal por el que se reproduce el sonido canal = mix_playchannel(1, sonido, 0).
// esperamos la pulsación de una tecla para salir while (done == 0) { while (sdl_pollevent(&event)) { if (event, type == sdl_keydown) done = 1; } }.
// liberamos recursos mix_frechunk(sonido).

Return 0; }
Música.

Como dijimos anteriormente, sdl_mixer reserva un canal exclusivo para la música. Además, nos da soporte a múltiples formatos. Para cargar un archivo de música utilizamos la función mix_loadmus.

Mix_music *mix_loadmus(const char *file).

Mediante el parámetro file, especificamos el archivo de música que queremos cargar. La función nos devuelve un puntero de tipo mix_music, que es parecido a mix_chunk, pero que nos permite almacenar música. Para liberar los recursos utilizamos la siguiente función.

Void mix_fremusic(mix_music).

La reproducción de la música puede llevarse a cabo mediante alguna de las dos funciones siguientes.

Int mix_playmusic(mix_music *music, int loops) int mix_fadeinmusic(mix_music *music, int loops, int ms).

Estas dos funciones son muy similares a mix_playchannel y mix_fadeinchannel. De hecho, la única diferencia es que el primer parámetro es una música en lugar de un sonido. El resto de parámetros es exactamente igual.

El volumen de la música se puede establecer con la función mix_volumemusic.

Int mix_volumemusic(int volume).

El rango valido para el volumen va de 0 a 128. El control de la música puede llevarse a cabo con las funciones siguientes.

Void mix_pausemusic() Void mix_resumemusic() int mix_haltmusic() int mix_fadeoutmusic(int ms).

Estas funciones han de serte ya familiares, ya que son similares a las utilizadas para controlar la reproducción de sonidos. Las dos primeras nos permiten pausar y reanudar la reproducción de la música. Observa que no tiene ningún parámetro ni devuelven ningún valor. Las dos últimas funciones paran la reproducción. Si hubo algún problema al intentar parar la reproducción devolverán -1, en caso contrario devolverán el valor 0. La última función además nos permite realizar la parada de la música de forma gradual (fadeout) teniendo que proveerle los milisegundos que deseamos que dure el fade.

La música, a diferencia de los sonidos simples, permiten mayor control. Además, de reproducir, pausar y parar la música podemos situar la reproducción en el lugar que deseemos. Contamos con dos funciones que nos permiten realizar esta tarea.

Void mix_rewindmusic() int mix_setmusicposition(double position).

La primera función es muy sencilla. Su misión es volver la reproducción de la música al principio.

La segunda función nos permite situar la posición de reproducción en el lugar deseado. La posición dependerá directamente del formato del archivo de música, pudiendo ser el tiempo en milisegundo para archivos de música digitalizada o la posición del patrón o el compás si es un archivo mod o midi. Vamos a terminar el capítulo de la música mostrando unas funciones que nos permiten conocer el estado del canal de música.

Int mix_playingmusic().

Int mix_pausedmusic().

Mix_musictype mix_getmusictype (const mix_music *music).

Las dos primeras son similares a las utilizadas en la reproducción de sonidos vista en la sección anterior y no requieren mayor explicación. La tercera sí es nueva para nosotros. Nos permite conocer el formato del archivo musical que le pasamos como parámetro (o el que se está reproduciendo si music vale null). El valor devuelto es de tipo mix_musictype, y puede tomar los siguientes valores: mus_wav, mus_mod, mus_mid, mus_og, mus_mp3. Si el valor devuelto es mus_none, significa que no hay ninguna música en reproducción. Si el valor devuelto es mus_cmd, significa que la reproducción no la está llevando a cabo sdl_mixer, sino un reproductor externo.

El siguiente código de ejemplo carga un archivo de música en formato midi y lo reproduce hasta que se pulse una tecla.
/************************************************** ************************* ejemplo4_4.
(C) 2003 by Alberto García serrano programación de videojuegos con SDL ************************************************** *************************/.
#include <stdio, h> #include <stdlib, h> #include <sdl.h> #include sdl_mixer, h.

Int main(int argc, char *argv) {.

Sdl_surface *screen, sdl_event event, mix_music *música, int done = 0, int canal.

Atexit(sdl_quit).
// iniciar SDL.

If (sdl_init(sdl_init_video|sdl_init_audio) < 0) { printf(no se pudo iniciar SDL: %s\n,sdl_geterror()), exit(1).
}.
// activamos modo de video screen = sdl_setvideomode (640,480,24,sdl_hwsurface), if (screen == null) {.

Printf(no se puede inicializar el modo gráfico: %s \n,sdl_geterror()), exit(1), }.
// inicializamos sdl_mixer.

If(mix_openaudio (22050, audio_s16, 2, 4096)) { printf(no se puede inicializar sdl_mixer %s\n,mix_geterror()), exit(1).
}.

Atexit(mix_closeaudio).
// cargamos la música música = mix_loadmus(música, Mid).

If (música == null) { printf(no pude cargar música: %s\n, mix_geterror()), exit(1).
}.
// reproducción la música. // esta función devuelve el canal por el que se reproduce la música canal = mix_playmusic(música, 1).
// esperamos la pulsación de una tecla para salir while (done == 0) { while (sdl_pollevent(&event)) { if (event, type == sdl_keydown) done = 1; } }.
// paramos la música mix_haltmusic().
// liberamos recursos mix_fremusic(música).

Return 0; }.

Esta obra esta bajo una licencia attribution-noncommercial-noderivs 2.5 de Creative Commons. Para ver una copia de esta licencia, visite http://creativecommons.org/licenses/by-nc-nd/2.5/ o envíe una carta a Creative Commons, 559 Nathan Abbott way, stanford, california 94305, usa.

Por: Alberto García serrano.

[3dpoder]

Sprites: héroes y villanos


Enséñame un héroe y te escribiré una tragedia, francisscottfitzgerald.

Durante los capítulos siguientes vamos a profundizar en los diferentes aspectos concernientes a la programación de videojuegos. Ya dispones de las herramientas necesarias para emprender la aventura, así que, siéntate cómodamente, flexiona tus dedos y prepárate para la diversión. Para ilustrar las técnicas que se describirán en los próximos capítulos, vamos a desarrollar un pequeño videojuego. Va a ser un juego sin grandes pretensiones, pero que nos va a ayudar a entender los diferentes aspectos que encierra este fascinante mundo. Nuestro juego va a consistir en lo que se ha dado en llamar shooter en el argot de los videojuegos. Quizás te resulte más familiar matamarcianos. En este tipo de juegos manejamos una nave que tiene que ir destruyendo a todos los enemigos que se pongan en su camino. En nuestro caso, el juego va a estar ambientado en la segunda guerra mundial, y pilotaremos un avión que tendrá que destruir una orda de aviones enemigos. El juego es un homenaje al mítico 1942.



Este capítulo vamos a dedicar a los sprites. Seguro que alguna vez has jugado a space Invaders. En este juego, una nave situada en la parte inferior de la pantalla dispara a una gran cantidad de naves enemigas que van bajando por la pantalla hacia el jugador. Pues bien, nuestra nave es un sprite, al igual que los enemigos, las balas y los escudos. Podemos decir que un sprite es un elemento gráfico determinado (una nave, un coche,) que tiene entidad propia y sobre la que podemos definir y modificar ciertos atributos, como la posición en la pantalla, si es o no visible, etc. Un sprite, pues, tiene capacidad de movimiento. Distinguimos dos tipos de movimiento en los sprites. El movimiento externo, es decir, el movimiento del sprite por la pantalla, y el movimiento interno o animación.

Para posicionar un sprite en la pantalla hay que especificar sus coordenadas. Es como el juego de los barcos, en el que para identificar un cuadrante hay que indicar una letra para el eje horizontal (lo llamaremos eje y) y un número para el eje horizontal (al que llamaremos eje x). En un ordenador, un punto en la pantalla se representa de forma parecida. Tenemos un eje horizontal (eje x) y otro vertical (eje y). La esquina superior izquierda representa el centro de coordenadas. La figura siguiente muestra el eje de coordenadas en una pantalla con una resolución de 320 por 200 píxeles.



Un punto se identifica dando la distancia en el eje X al lateral izquierdo de la pantalla y la distancia en el eje y a la parte superior de la pantalla. Las distancias se miden en píxeles. Si queremos indicar que un sprite está a 100 píxeles de distancia del eje vertical y 150 del eje horizontal, decimos que está en la coordenada (100,150).

Imagina ahora que jugamos a un videojuego en el que manejamos a un hombrecillo (piensa en juegos como pitfall o renegade). Al mover a nuestro hombrecillo, podemos observar cómo mueve las piernas y los brazos según avanza por la pantalla. Éste es el movimiento interno o animación. La siguiente figura muestra la animación del sprite de un gato.



Otra característica muy interesante de los sprites es que nos permiten detectar colisiones entre ellos. Esta capacidad es realmente interesante si queremos conocer cuando nuestro avión ha chocado con un enemigo o con uno de sus misiles, control de sprites.

Vamos a realizar una librería (y cuando digo pequeña, quiero decir realmente pequeña) para el manejo de los sprites. Luego utilizaremos esta librería en nuestro juego. Por supuesto, también puedes utilizarla en tus propios juegos, así como ampliarla, ya que, cubrira solo aspectos básicos en lo referente a sprites.

Realizaremos la librería en C++ en lugar de c. Podríamos haberla creado completamente en c, pero considero conveniente introducir, aunque sea poco, algo de programación orientada a objetos para que te vayas familiarizando. Observaras que es mucho más fácil reutilizar esta librería en tu propio código gracias a la PO. Consulta el apéndice b dedicado a C++ si no estas familiarizado con esto de los objetos y las clases. Prometo no utilizar más PO en el resto del libro (más de un lector lo lamentara, pero prefiero hacer el libro lo más accesible posible).

Dotaremos a nuestra librería con capacidad para movimiento de sprites, animación (un soporte básico) y detección de colisiones.

En el diagrama de clases de nuestra librería (figura 5.4.) observamos que hay sólo dos clases. Si no sabes lo que es un diagrama de clases, te bastara saber que cada caja representa a una clase, y que la parte superior de la caja describe las variable miembro de la clase mientras que la parte inferior describe los métodos.

La clase cframe será la encargada de contener un gráfico (superficie) independiente. Tiene un sólo miembro de clase, img, que será la encargada de almacenar la superficie, y dos métodos, load para cargar el gráfico y unload para liberar los recursos de la superficie. La razón por la que hemos utilizado dos clases es porque un mismo gráfico podría formar parte de dos sprites diferentes (imagina dos explosiones distintas que comparten los mismos fotogramas).



La clase csprite representa a un sprite. Observa que tiene dos constructores (un ejemplo del polimorfismo en acción). Al crear un objeto de tipo csprite podemos indicar el número de frames (fotogramas) que tendrá el sprite. Si creamos el objeto sin pasar ningún parámetro, el sprite tendrá un sólo frame. Añadiendo múltiples frames, podremos crear sprites animados. Una vez que ya no necesitamos nuestro sprite, podemos llamar al método finalice () que se encarga de llamar al método unload() de cada uno de los frames que forman parte del sprite, es decir, se encarga de liberar los recursos gráficos (superficies). La forma de añadir frames a nuestro sprite es mediante la función addframe (). Sólo tenemos que pasar como parámetro el frame que queremos añadir a la animación del sprite. Con el método selframe () podemos seleccionar el frame actual, es decir, el que será dibujado. Para crear la sensación de movimiento interno, tendremos que ir dibujando nuestro sprite e ir cambiando el frame seleccionado cada vez. Para realizar la animación desde nuestro programa, hemos de conocer el número de frames que tiene el sprite. El método frames() nos informa sobre cuantos frames tiene el sprite actualmente.

Profundicemos en los métodos que nos permiten mover el sprite por la pantalla. Con los métodos setx() y sety() especificamos la posición del sprite en la pantalla. Con los métodos addx() y addy() podemos indicar un desplazamiento del sprite en pantalla tomando como punto de referencia la situación actual, es decir, addx(5) moverá el sprite 5 píxeles en el eje a la derecha, mientras que addx(10) lo moverá 10 píxeles a la izquierda.

Seguramente, necesitaremos en algún momento conocer información del sprite, como su posición o su tamaño. Los métodos getx() y gety() nos informaran sobre la posición en la que está el sprite. Los métodos getw() y geth() nos permiten conocer el tamaño del sprite en horizontal y en vertical respectivamente.

El método siguiente es draw(), y realiza la función más básica de un sprite, es decir, dibujarlo. Este método simplemente dibuja el sprite en la posición y con el frame actual. Toda la información necesaria (posición, frame,) esta almacenada en miembros privados del objeto.

Por último, el método colisión() nos permite comprobar si el sprite ha colisionado con otro. Sólo hemos de pasarle como parámetro el sprite con el que queremos comprobar la posible colisión.

Implementando los sprites.

La clase cframe es la encargada de cargar un gráfico que posteriormente será vinculado al sprite. Sus dos métodos son realmente sencillos.
// método para cargar el frame Void cframe:load(char *Path) {.

Img=sdl_loadbmp(Path).
// asignamos el color transparente al color rojo. Sdl_setcolorkey(img,sdl_srcolorkey|sdl_rleacel, sdl_maprgb(img>format,255,0,0)), img=sdl_displayformat(img).
}.
// método para liberar el frame Void cframe:unload(){.

Sdl_fresurface (img), }.

El método load() carga un archivo en formato bmp mediante la función sdl_loadbmp. Nuestros sprites van a tener como color transarente el rojo (255,0,0). Como es habitual, recurrimos a la función sdl_setcolorkey para tal fin. La función sdl_displayformat se encarga de realizar una conversión del gráfico cargado al formato de la pantalla. Esto agiliza el proceso blitting al no tener que realizar conversiones cada vez que dibujamos el sprite.

El método unload() libera los recursos ocupados por el frame utilizando la función sdl_fresurface.

Fácil ¿no? Como puede observar, esta clase no tiene ningún misterio.

La clase csprite es algo más grande, pero igual de sencilla. Cuando creamos un sprite, tenemos que indicar el número de frames que contendrá (o que podrá contener como máximo). Necesitamos hacer esto para reservar el espacio necesario en el array de frames. Vamos a colocar este código en el constructor de la clase.

Csprite:csprite (int nf) {.

Sprite=new cframe[nf].

Nframes=nf.

Cont=0; }.

Además, de reservar los elementos necesarios en el array de frames, inicializamos la variable nframes que contiene el número de frames máximo del sprite y la variable cont, que almacenara el número de frames que se van añadiendo.

Para liberar los recursos haremos uso del método unload() de la clase frame. Sólo hemos de llamar este método por cada frame del sprite.

Csprite:finalice () { int i.

For (i=0, i<=nframes1, i++) sprite[.unload(), }.

Ya estamos listos para ir añadiendo frames a nuestro sprite, el método addframe () toma como parámetro un frame y lo añade al array de frames. Antes de añadir el frame hemos de comprobar que no añadimos más frames que el máximo que permite el sprite (el valor que especificamos al crear el sprite). Por cada frame añadido incrementamos la variable cont.

Void csprite:addframe (cframe frame) {.

If (cont<nframes) {.

Sprite[cont]=frame.

Cont++.
} }.

Los métodos que nos permiten establecer y consultar la posición del sprite son realmente simples. Las variables miembro de la clase que contienen este estado del sprite son posx y Posy.

Void setx(int x) {posx=x;} Void sety(int y) {Posy=y;} Void addx(int c) {posx+=c;} Void addy(int c) {Posy+=c;} int getx() {return posx;} int gety() {return Posy;}.

Para conocer el tamaño del sprite hemos de recurrir a consultar el tamaño del frame actual. Nótese que si un sprite está formado por frames de distintos tamaños (lo cual es posible, aunque no habitual), el tamaño devuelto será el del frame seleccionado.

Int getw() {return sprite[estado].img>w;} int geth() {return sprite[estado].img>h;}.

Para seleccionar el frame actual, es decir, el que será dibujado en la próxima llamada al método draw(), utilizamos la variable miembro estado. Esta variable la utilizaremos para almacenar el frame actual o estado del sprite.

Void csprite:selframe (int nf) { if (nf<=nframes) { estado=nf; } }.

El método frames() simplemente consulta la variable miembro cont, que contiene el número de frames añadidos hasta el momento.

Int frames() {return cont;}.

El método draw() utiliza la función sdl_blitsurface para dibujar el sprite. Tenemos que proveer al método con la superficie sobre la que queremos realizar el blitting. De las variables miembro posx y Posy obtenemos la posición en la que tenemos que dibujar el sprite, y de la variable estado, el frame que debemos dibujar.

Void csprite:draw(sdl_surface *superficie) { sdl_rect dest.

Dest.x=posx.

Dest, y=Posy.

Sdl_blitsurface (sprite[estado].img,null, superficie,&dest), }.

Nos resta dotar a nuestra librería con la capacidad de detectar colisiones entre sprites. La detección de colisiones entre sprites puede enfocarse desde varios puntos de vista. Imaginemos dos sprites, nuestro avión y un disparo enemigo. En cada vuelta del game loop tendremos que comprobar si el disparo ha colisionado con nuestro avión. Podríamos considerar que dos sprites colisionan cuando alguno de sus píxeles visibles (es decir, no transparentes) toca con un píxel cualquiera del otro sprite. Esto es cierto al 100%, sin embargo, la única forma de hacerlo es comprobando uno por uno los píxeles de ambos sprites. Evidentemente esto requiere un gran tiempo de computación, y es inviable en la practica. En nuestra librería hemos asumido que la parte visible de nuestro sprite coincide más o menos con las dimensiones de la superficie que lo contiene. Si aceptamos esto, y teniendo en cuenta que una superficie tiene forma cuadrangular, la detección de una colisión entre dos sprites se simplifica bastante. Sólo hemos de detectar el caso en el que dos cuadrados se solapen.



En la primera figura no existe colisión, ya que no se solapan las superficies (las superficies están representadas por el cuadrado que rodea al gráfico). La segunda figura muestra el principal problema de este método, ya que nuestra librería considerara que ha habido colisión cuando realmente no ha sido así. A pesar de este pequeño inconveniente, este método de detección de colisiones es el más rápido. Es importante que la superficie tenga el tamaño justo para albergar el gráfico. Este es el aspecto que tiene nuestro método de detección de colisiones.

Int csprite:colisión(csprite sp) { int w1, h1,w2, h2,x1, y1,x2, y2.
W1=getw(), // ancho del sprite1 h1=geth(), // altura del sprite1 w2=sp, getw(), // ancho del sprite2 h2=sp, geth(), // altura del sprite2.

X1=getx(), // pos. X del sprite1 y1=gety(), // pos. Y del sprite1 x2=sp, getx(), // pos. X del sprite2 y2=sp, gety(), // pos. Y del sprite2.

If (((x1+w1)>x2) && ((y1+h1)>y2) && ((x2+w2)>x1) && ((y2+h2)>y1)) { return true; } else { return false; } }.

Se trata de comprobar si el cuadrado (superficie) que contiene el primer sprite, se solapa con el cuadrado que contiene al segundo.

Hay otros métodos más precisos que nos permiten detectar colisiones. Voy a presentar un método algo más elaborado. Consiste en dividir el esprite en pequeñas superficies rectangulares tal y como muestra la próxima figura.



Se puede observar la mayor precisión de este método. El proceso de detección consiste en comprobar si hay colisión de alguno de los cuadros del primer sprite con alguno de los cuadrados del segundo utilizando la misma comprobación que hemos utilizado en el primer método para detectar si se solapan dos rectángulos. Se deja como ejercicio al lector la implementación de este método de detección de colisiones (pista: tendrás que añadir a la clase sprite un array de elementos del tipo sdl_rect que contenga cada uno de los cuadrados). A continuación se muestra el listado completo de nuestra librería. Esta compuesta por dos archivos: el archivo de cabeceras csprite, h y el de implementación csprite, cpp.

Csprite, h.
#ifndef csprite_h_ #define csprite_h_.
#define true 1 #define false 0.
// cframe representa un frame independiente de un sprite, class cframe { public:
Sdl_surface *img; Void load(char *Path), Void unload().
}.
// la clase csprite está formada por un array de frames, class csprite { private:
Int posx, Posy, int estado, int nframes, int cont.

Public: cframe *sprite, csprite (int nf), csprite (), Void finalice (), Void addframe (cframe frame), Void selframe (int nf), int frames() {return cont;} Void setx(int x) {posx=x;} Void sety(int y) {Posy=y;} Void addx(int c) {posx+=c;} Void addy(int c) {Posy+=c;} int getx() {return posx;} int gety() {return Posy;} int getw() {return sprite[estado].img>w;} int geth() {return sprite[estado].img>h;} Void draw(sdl_surface *superficie), int colisión(csprite sp).
}.
#endif /* csprite_h_ */.

Csprite, cpp.
#include <sdl.h> #include csprite, h.
// sprite class implementation.

Void cframe:load(char *Path) { img=sdl_loadbmp(Path).
// asignamos el color transparente al color rojo. Sdl_setcolorkey(img,sdl_srcolorkey|sdl_rleacel, sdl_maprgb(img>format,255,0,0)), img=sdl_displayformat(img).
}.

Void cframe:unload(){ sdl_fresurface (img), }.

Csprite:csprite (int nf) { sprite=new cframe[nf], nframes=nf, cont=0.
}.

Csprite:csprite () {.

Int nf=1, sprite=new cframe[nf], nframes=nf, cont=0.
}.

Void csprite:finalice () { int i.

For (i=0, i<=nframes1, i++) sprite[.unload(), }.

Void csprite:addframe (cframe frame) {.

If (cont<nframes) { sprite[cont]=frame, cont++.
} }.

Void csprite:selframe (int nf) { if (nf<=nframes) { estado=nf; } }.

Void csprite:draw(sdl_surface *superficie) { sdl_rect dest.

Dest.x=posx, dest, y=Posy, sdl_blitsurface (sprite[estado].img,null, superficie,&dest).
}.

Int csprite:colisión(csprite sp) { int w1, h1,w2, h2,x1, y1,x2, y2.
W1=getw(), // ancho del sprite1 h1=geth(), // altura del sprite1 w2=sp, getw(), // ancho del sprite2 h2=sp, geth(), // alto del sprite2 x1=getx(), // pos. X del sprite1 y1=gety(), // pos. Y del sprite1 x2=sp, getx(), // pos. X del sprite2 y2=sp, gety(), // pos. Y del sprite2.

If (((x1+w1)>x2)&&((y1+h1)>y2)&&((x2+w2)>x1)&&((y2+h2 )>y1)) { return true.
} else { return false; } }
Utilizando nuestra librería.

En el ejemplo5_1 hay un listado completo de un programa que utiliza la librería que acabamos de desarrollar. Al ejecutarlo vera la siguiente ventana.



Podemos manejar el avión con las teclas del cursor o con el joystick. En la parte superior hay un avión enemigo parado. Si colisionamos con el acaba el programa.
/************************************************** ************************* ejemplo5_1.
(C) 2003 by Alberto García serrano programación de videojuegos con SDL ************************************************** *************************/.
#include <stdio, h> #include <stdlib, h> #include <sdl.h> #include csprite, h.

Sdl_surface *screen, cframe fnave, cframe fmalo, csprite nave (1), csprite malo (1), sdl_rect rectángulo, sdl_joystik *joystick, int joyx, joyy, int done=0.
// estructura que contiene la información // de nuestro avión structure minave {.

Int x, y; } jugador.
// estructura que contiene información // del avión enemigo structure navenemiga {.

Int x, y; } enemigo.
// dibuja los esprites en la pantalla Void drawscene (sdl_surface *screen) {.
// borramos el avión dibujado // en el frame anterior rectángulo.x=nave, getx(), rectángulo, y=nave, gety(), rectángulo.w=nave, getw(), rectángulo, h=nave, geth(), sdl_fillrect(screen,&rectángulo,sdl_maprgb(screen >format,0,0,0)).
// dibuja avión nave, setx(jugador.x), nave, sety(jugador, y), nave, draw(screen).
// dibuja enemigo malo, setx(enemigo.x), malo, sety(enemigo, y), malo, draw(screen).
// ¿ha colisionado con la nave? If (malo, colisión(nave) == true) { done=1; }.
// mostramos todo el frame sdl_flip(screen), }.
// inicializamos estados.

Void inicia () { jugador.x=300, jugador, y=300, enemigo.x=100, enemigo, y=100.
}.

Void finaliza () {.
// finalizamos los sprites nave, finalice (), malo, finalice ().
// cerramos el joystick if (sdl_joystickopened(0)) { sdl_joystickclose (joystick), } }.
// preparamos los esprites int initsprites() {.

Fnave, load(minave, bmp).

Nave, addframe (fnave).

Fmalo, load(nave, bmp).

Malo, addframe (fmalo).

Return 0; }.

Int main(int argc, char *argv) {.

Sdl_event event, uint8 *keys.

If (sdl_init(sdl_init_video|sdl_init_joystick) < 0) { printf(no se pudo iniciar SDL: %s\n,sdl_geterror()), return 1.
}.

Scren = sdl_setvideomode (640,480,24,sdl_hwsurface).

If (screen == null) { printf(no se puede inicializar el modo gráfico: \n,sdl_geterror()), return 1.
}.

Atexit(sdl_quit).

Inicializa ().

Initsprites().
While (done == 0) {.
// dibujamos el frame.

Drawscene (screen).
// consultamos el estado del teclado.

Keys=sdl_getkeystate (null).
// consultamos el estado del joystick.

Sdl_joystickupdate ().

Joyx = sdl_joystickgetaxis(joystick, 0).

Joyy = sdl_joystickgetaxis(joystick, 1).

If ((keys[sdlk_up] || joyy < 10) && (jugador, y > 0)) {jugador, y=jugador, y(5),} if ((keys[sdlk_down] || joyy > 10) && (jugador, y < 460)) {jugador, y=jugador, y+(5),} if ((keys[sdlk_left] || joyx < 10) && (jugador.x > 0)) {jugador.x=jugador.x(5),} if ((keys[sdlk_right] || joyx > 10) && (jugador.x < 620)) {jugador.x=jugador.x+(5),}.
While (sdl_pollevent(&event)) {.

If (event, type == sdl_quit) {done=1;}.

If (event, type == sdl_keydown || event, type == sdl_joybutondown) {.

If (event.key.keysym, sym == sdlk_escape) { done=1; }.
} }.
}.

Finaliza (), return 0.
}
En este ejemplo hay algunas diferencia con respecto a los anteriores. En la función main() hay un bucle while que se parece bastante a un game loop. Después de inicializar la posición de los aviones mediante la función inicia () y cargar e inicializar los sprites en la función initsprites(), entramos en un bucle en el que lo primero que hacemos es llamar a la función drawscene (), que se encarga de dibujar los dos sprites en la pantalla. Acto seguido, consultamos el teclado y el joystick para comprobar si hay que realizar algún movimiento en nuestro avión, y en caso afirmativo, aplicamos dicho movimiento. La función drawscene () es realmente la única que se encarga de dibujar los sprites. Esta función es llamada en cada iteración del game loop. Cada vez que se pintan los sprites, decimos que se ha dibujado un frame. Lo primero que hace es borrar el cuadrado que ocupaba el avión en el frame anterior (realmente pintar un cuadro de color negro). Si no hiciéramos esto, el avión dejaría un feo rastro al moverse (puedes probar a quitar estas líneas y ver el efecto). Lo siguiente que hacemos es actualizar las coordenadas del sprite y dibujarlo con el método draw(). Hemos almacenado esta información en dos estructuras que contienen las coordenadas tanto de nuestro avión como del avión enemigo.

Después del pintado, comprobamos la colisión de la nave enemiga con la nuestra. Si se produce la colisión, salimos del game loop poniendo la variable done a 1.

La clase initsprites() también es interesante. En ella cargamos los frames que van a formar parte de los sprites (1 sólo frame en este caso), y acto seguido lo añadimos al sprite.

[3dpoder]

un universo dentro de tu ordenador.


Cuando quieres realmente una cosa, todo el universo conspira para ayudarte a conseguirla, paulo Coelho.

En el segundo capítulo, ya desarrollamos un sencillo juego para el que creamos un pequeño mundo. La mansión del terror. Todo lo aplicado en el capítulo segundo es perfectamente válido. Si quisiéramos rehacer el juego, pero esta vez de forma gráfica y manejando un personaje que se mueve a través de las habitaciones, tendríamos que modificar un poco las estructuras de datos. En aquel juego, la descripción de las estancias de la mansión se presentaba al jugador en forma de texto. Ahora, si queremos representar gráficamente las habitaciones, hemos de conocer la situación de los elementos que la componen. Deberíamos añadir a la estructura de datos un array de los elementos que componen la habitación. Tendría el aspecto siguiente:
// estructura de datos que describe un // elemento de una habitación structure item {.

Sdl_surface *img.

Int posx.

Int Posy.
}.
// estructura de datos para las habitaciones.

Struct habitación {.

Struct item elemnto[max_element.

Int norte.

Int sur.

Int este.

Int oeste.
}.

La estructura item describe un elemento individual de la habitación, como una cama, una mesa o una silla. Tiene tres elementos en la estructura que la describen. Por un lado sus dos coordenadas dentro de la habitación, y por supuesto, un gráfico con el que representar el objeto. En la estructura habitación, sólo hemos hecho un cambio. Hemos sustituido el campo que contenía el texto descriptor de la habitación por un array de elementos de tipo item. Un posible código que mostrara los elementos contenidos en una habitación podría tener el siguiente aspecto.

Sdl_rect dest, structure habitación rom[num_rom.
// mostrar elementos de la habitación for (int i=1, i<=max_elements, i++) {.

Dest.x = rom[hab_actual].elemento[.posx, dest, y = rom[hab_actual].elemento[.posx, sdl_blitsurface (rom[hab_actual].elemento[.img, null, screen.
&dest), }.

Como ves, la elección de una buena estructura de datos es fundamental a la hora de hacer un buen diseño. Créeme, puede ser la diferencia entre un código limpio y elegante.

O un spaghetticode (código mal estructurado). Y todo esto sin contar con los dolores de cabeza que tendrás que sufrir para hacerlo funcionar. Hacer buenas estructuras de datos es algo parecido a un arte y se mejora con la experiencia. Sólo un consejo: mantén las cosas simples. La estructura de datos tiene que permitir que el código que hace uso de ella sea lo más sencillo y simple posible.

Este primer intento de crear un mundo visual parece bueno. Algunos antiguos juegos como atic atac han utilizado técnicas similares a estas.

atic atac en un ZX Spectrum.

El problema es que probablemente se consigue poco detalle visual. En nuestro juego vamos a utilizar una técnica distinta basada en tiles. En español Tile significa baldosa o azulejo. Esto nos da una idea de en que consiste la técnica. La idea es construir la imagen a mostrar en la pantalla mediante tiles de forma cuadrada, como si enlosamos una pared. Mediante tiles distintos podemos formar cualquier imagen. La siguiente figura pertenece al juego uridium, un juego de naves o shooter de los años 80 parecido al que vamos a desarrollar.



Las líneas rojas dividen los tiles empleados para construir la imagen, almacenando y mostrando tiles.

En nuestro juego vamos a manejar mapas sencillos. Van a estar compuestos por mosaicos de tiles simples. Algunos juegos tienen varios niveles de tiles (llamados capas). Por ahora, vamos a almacenar la información sobre nuestro mapa en un array de enteros tal como este.

Int mapa[10 = { 0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,2,0,0,0,0, 0,0,1,0,0,0,0,1,0,0, 2,0,0,0,0,0,0,0,0,0, 0,0,0,0,1,0,0,0,2,0, 0,0,0,0,0,0,0,0,0,0, 0,2,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,1,0,0, 0,0,1,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0}.

Este array representa un array de 10 por 10 tiles. Vamos a utilizar los siguientes tiles, cada uno con un tamaño de 64x64 píxeles.

tiles utilizados en nuestro juego.

Para cargar y manejar los tiles vamos a apoyarnos en la librería de manejo de sprites que desarrollamos en el capítulo anterior.

Cframe tile1, cframe tile2, cframe tile3, csprite suelo[.

Tile1.load(tile0.bmp), suelo[.addframe (tile1).

Tile2.load(tile1.bmp), suelo[.addframe (tile2).

Tile3.load(tile2.bmp), suelo[.addframe (tile3).

Hemos creado un array de tres sprites, uno por cada Tile que vamos a cargar. El proceso de representación del escenario consiste en ir leyendo el mapa y dibujar el sprite leído en la posición correspondiente. El siguiente código realiza este proceso.

Int i,x y, t.
//dibujar escenario for (i=0, i<10, i++) {.

For (j=0, j<10, j++) { t=mapa[i*10+j]; // cálculo de la posición del Tile x=j*64, y=(i1)*64.
// dibujamos el Tile suelo[t].setx(x), suelo[t].sety(y), suelo[t].draw(screen).
} }.

El mapa es de 10 por 10, así que, los dos primero bucles se encargan de recorrer los tiles. La variable t, almacena el valor del Tile en cada momento. El cálculo de la coordenada de la pantalla en la que debemos dibujar el Tile tampoco es complicada. Al tener cada Tile 64x64 píxeles, sólo hay que multiplicar por 64 el valor de los contadores i o, correspondiente a los bucles, para obtener la coordenada de pantalla. Seguidamente se muestra el código completo del ejemplo6_1.
/************************************************** ************************* ejemplo6_1.
(C) 2003 by Alberto García serrano programación de videojuegos con SDL ************************************************** *************************/.
#include <stdio, h> #include <stdlib, h> #include <sdl.h> #include csprite, h.
// mapa de tiles // cada Tile tiene 64x64 píxeles // una pantalla tiene 10 por 10 tiles int mapa[10= {0,0,0,0,0,0,0,0,0,0.
0,0,0,0,0,2,0,0,0,0, 0,0,1,0,0,0,0,1,0,0, 2,0,0,0,0,0,0,0,0,0, 0,0,0,0,1,0,0,0,2,0, 0,0,0,0,0,0,0,0,0,0, 0,2,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,1,0,0, 0,0,1,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0}.

Sdl_surface *screen, cframe fnave, cframe fmalo, cframe tile1, cframe tile2, cframe tile3, csprite nave (1), csprite malo (1), csprite suelo[, sdl_rect rectángulo, sdl_joystik *joystick, int joyx, joyy, int done=0.
// estructura que contiene la información // de nuestro avión structure minave {.

Int x, y; } jugador.
// estructura que contiene información // del avión enemigo structure navenemiga {.

Int x, y; } enemigo.
// dibuja los esprites en la pantalla Void drawscene (sdl_surface *screen) { int i,x y, t.
//dibujar escenario for (i=0, i<10, i++) {.

For (j=0, j<10, j++) { t=mapa[i*10+j]; // cálculo de la posición del Tile x=j*64, y=(i1)*64.
// dibujamos el Tile suelo[t].setx(x), suelo[t].sety(y), suelo[t].draw(screen).
} }.
// dibuja avión nave, setx(jugador.x), nave, sety(jugador, y), nave, draw(screen).
// dibuja enemigo malo, setx(enemigo.x), malo, sety(enemigo, y), malo, draw(screen).
// ¿ha colisionado con la nave? If (malo, colisión(nave) == true) { done=1; }.
// mostramos todo el frame sdl_flip(screen).
}.
// inicializamos estados.

Void inicia () { jugador.x=300, jugador, y=300, enemigo.x=100, enemigo, y=100.
}.

Void finaliza () {.
// finalizamos los sprites nave, finalice (), malo, finalice (), suelo[.finalice (), suelo[.finalice (), suelo[.finalice ().
// cerramos el joystick if (sdl_joystickopened(0)) { sdl_joystickclose (joystick), } }.
// preparamos los esprites int initsprites() {.

Fnave, load(minave, bmp).

Nave, addframe (fnave).

Fmalo, load(nave, bmp).

Malo, addframe (fmalo).

Tile1.load(tile0.bmp).

Suelo[.addframe (tile1).

Tile2.load(tile1.bmp).

Suelo[.addframe (tile2).

Tile3.load(tile2.bmp).

Suelo[.addframe (tile3).

Return 0; }.

Int main(int argc, char *argv) {.

Sdl_event event, uint8 *keys.

If (sdl_init(sdl_init_video|sdl_init_joystick) < 0) { printf(no se pudo iniciar SDL: %s\n,sdl_geterror()), return 1.
}.

Scren = sdl_setvideomode (640,480,24,sdl_hwsurface), if (screen == null) { printf(no se puede inicializar el modo gráfico: \n,sdl_geterror()).

Return 1; } atexit(sdl_quit), inicia (), initsprites().
While (done == 0) { // dibujamos el frame drawscene (screen).
// consultamos el estado del teclado.

Keys=sdl_getkeystate (null), // consultamos el estado del joystick sdl_joystickupdate ().

Joyx = sdl_joystickgetaxis(joystick, 0).

Joyy = sdl_joystickgetaxis(joystick, 1), if ((keys[sdlk_up] || joyy < 10) && (jugador, y > 0)) {jugador, y=jugador, y(5),} if ((keys[sdlk_down] || joyy > 10) && (jugador, y < 460)) {jugador, y=jugador, y+(5),} if ((keys[sdlk_left] || joyx < 10) && (jugador.x > 0)) {jugador.x=jugador.x(5),} if ((keys[sdlk_right] || joyx > 10) && (jugador.x < 620)) {jugador.x=jugador.x+(5),}.
While (sdl_pollevent(&event)) { if (event, type == sdl_quit) {done=1;} if (event, type == sdl_keydown || event, type == sdl_joybutondown) {.

If (event.key.keysym, sym == sdlk_escape) { done=1; } } } }.

Finaliza ().

Return 0; }.

El resultado de ejecutar este código de ejemplo se muestra en la próxima figura. El programa hace exactamente lo mismo que el del anterior capítulo, es decir, podrás mover el avión por la pantalla hasta colisionar con el avión enemigo. La diferencia es que, ahora tenemos un bonito fondo en lugar de aquel color negro.

nota que hemos eliminado el código necesario para borrar la anterior posición del avión en su movimiento. Al redibujar todo el fondo cada vez, ya no es necesario, ya que se actualiza la pantalla completa.

Diseñando el mapa.

El código anterior es válido siempre que no se den dos condiciones. La primera es que el mapa no ocupe la pantalla, y la segunda es que el mapa no sea demasiado complejo. Imagina tener que hacer inmensos y complejos arrays de enteros para representa un gran mapa.

Habitualmente, los programadores de videojuegos usan lo que se llaman editores de mapas. Un editor de mapas nos permite diseñar nuestro mapa de forma visual. Así vamos viendo cómo va quedando mientras lo diseñamos. Hay dos opciones, o desarrollar uno propio (no es demasiado complejo, aunque lo parezca) o utilizar alguno existente. Por ahora optaremos por la segunda opción. Hay algunos buenos programas editores de mapa, pero nosotros vamos a utilizar en este libro uno llamado mappy, que es sencillo, flexible, y sobre todo, gratuito. Puedes descargarlo de la siguiente dirección web: http://www.tilemap.co.uk/mappy.php.

Este programa permite configurar el formato del fichero que genera, con lo que nos sirve perfectamente. El formato que vamos a utilizar no puede ser más sencillo. Es un fichero binario (ojo, no de texto) en el que cada byte representa una posición consecutiva del mapa (un elemento del array en el anterior programa). Nuestro mapa va a tener 10x40 tiles, es decir, 10 tiles en horizontal y 40 en vertical. Por lo tanto, si cada Tile está representado por un byte, el archivo para el mapa ocupara exactamente 400 bytes. Para que mappy pueda generar este tipo de archivo hay que configurarlo editando en archivo mapwin. Ini. Más concretamente hay que cambiar la línea MapType=lw4h4a41 por ésta otra MapType=la11. No voy a entrar en detalle sobre este fichero de configuración, pero si tienes curiosidad puedes consultar el manual de mappy.

Veamos paso a paso como creamos un mapa para nuestro juego. Ejecuta el programa y selecciona new map, del menú file. Aparecerá un diálogo preguntándote si quieres utilizar el diálogo avanzado o el sencillo. Pulsa no para usar el sencillo.



Introduce los valores que ves en la figura, es decir, 64 píxeles tanto de anchura como de altura para los tiles. En la anchura de tiles ponemos 10 y en la altura 40. Seguidamente pulsa ok.

Ahora vamos a cargar los tiles. Lo mejor es nombrar los tiles como tile1.bmp, tile2.bmp, tilen.bmp, etc. Así luego no tendremos problema con el orden de los tiles. Para cargar los tiles en el programa seleccionamos import, del menú file. Se nos abrirá un diálogo para seleccionar un archivo. Cargamos el primer tile. Nos aparecerá un diálogo que reza: make all imported graphics into new block structures? Respondemos que sí y repetimos este proceso para todos los tiles del juego. Los tiles que se van cargando se van situando en la ventana del laterar derecho. A partir de ahí sólo tienes que seleccionar el Tile que quieres dibujar y situarlo en la ventana central en el lugar deseado.

edición de un mapa con mappy.

Una vez que hemos terminado el diseño del mapa, hemos de grabarlo seleccionando save as, del menú file. Podemos grabar el archivo con dos extensiones diferentes: fmp y. Map. El formato. Fmp es el formato interno de mappy, y el formato. Map es nuestro formato (el que definimos al editar el archivo mapwin. Ini). Si lo grabamos exclusivamente en nuestro formato, es decir. Map, mappy no será capaz de volver a leerlo, así que, lo mejor es guardarlo en formato. Fmp y seguidamente volver a guardarlo en formato. Map. Cargar el mapa desde nuestro juego es sumamente sencillo. Las siguientes líneas realizan esta tarea.
#define maxmap 400 char mapa[40, file *f.
// carga del mapa.

If((f=fopen(map, map,r)).= null) { c=fread(mapa,maxmap,1, f), fclose (f).
}.

El array mapa, contiene ahora toda la información del mapa.

Scrolling.

Se hace evidente que un mapa de 10x40 tiles no cabe en la pantalla. Lo lógico es que según se mueva nuestro avión por el escenario, el mapa avance en la misma dirección. Este desplazamiento del escenario se llama scrolling. Si nuestro avión avanza un Tile en la pantalla, hemos de dibujar el escenario, pero desplazado (offset) un tile. Desafortunamente, haciendo esto exclusivamente, veríamos como el escenario va dando saltos, y lo que buscamos es un scroll suave. El siguiente fragmento de código cumple este cometido.
#define maxmap 400 indice=maxmap100, indice_in=0.
// movimiento del escenario (scroll) indice_in+=2, if (indice_in>=64) {.

Indice_in=0, indice=10; }.

If (indice <= 0) { indice=maxmap100; // si llegamos al final, empezamos de nuevo, indice_in=0.
}.
//dibujar escenario for (i=0, i<10, i++) {.

For (j=0, j<10, j++) { t=mapa[indice+(i*10+j)]; // cálculo de la posición del Tile x=j*64, y=(i1)*64+indice_in.
// dibujamos el Tile suelo[t].setx(x).

Suelo[t].sety(y), suelo[t].draw(screen), } }.

Este código está basado en el ejemplo6_1. Como diferencia encontramos dos nuevas variables. La variable índice contiene el desplazamiento (en bytes) a partir del cual se comienza a dibujar el mapa. La variable indice_in, es la encargada de realizar el scroll fino. Al dibujar el tile, se le suma a la coordenada y el valor de la variable indice_in, que va aumentando en cada iteración. Cuando esta variable alcanza el valor 64, es decir, la altura del tile, ponemos la variable a 0 y restamos 10 a la variable índice, o lo que es lo mismo, el offset a partir del que dibujamos el mapa. Se realiza una resta porque la lectura del mapa la hacemos de abajo a arriba (del último byte al primero). Recuerda que el mapa tiene 10 tiles de anchura. Es por eso que restamos 10 a la variable índice. Una vez que llegamos al principio del mapa, comenzamos de nuevo por el final, de forma que se va repitiendo el mismo mapa de forma indefinida. Ten en cuenta que las primeras 10 filas del mapa tienen que ser iguales que las 10 últimas si no quieres notar un molesto salto cuando recomienza el recorrido del mapa. En el ejemplo6_2 vemos el código completo.
/************************************************** ************************* ejemplo6_2.
(C) 2003 by Alberto García serrano programación de videojuegos con SDL ************************************************** *************************/.
#include <stdio, h> #include <stdlib, h> #include <sdl.h> #include csprite, h.
#define maxmap 400.

Sdl_surface *screen, cframe fnave, cframe fmalo, cframe tile1, cframe tile2, cframe tile3, csprite nave (1), csprite malo (1), csprite suelo[, sdl_rect rectángulo, sdl_joystik *joystick, char mapa[40, int joyx, joyy, int done=0, int índice, indice_in, file *f.
// estructura que contiene la información // de nuestro avión structure minave {.

Int x, y; } jugador.
// estructura que contiene información // del avión enemigo structure navenemiga {.

Int x, y; } enemigo.
// dibuja el escenario Void drawscene (sdl_surface *screen) { int i,x y, t.
// movimiento del escenario (scroll) indice_in+=2, if (indice_in>=64) {.

Indice_in=0, indice=10; }.

If (indice <= 0) { indice=maxmap100; // si llegamos al final, empezamos de nuevo, indice_in=0.
}.
//dibujar escenario for (i=0, i<10, i++) {.

For (j=0, j<10, j++) { t=mapa[indice+(i*10+j)]; // cálculo de la posición del Tile x=j*64, y=(i1)*64+indice_in.
// dibujamos el Tile suelo[t].setx(x), suelo[t].sety(y), suelo[t].draw(screen).
} }.
// dibuja avión nave, setx(jugador.x), nave, sety(jugador, y), nave, draw(screen).
// dibuja enemigo malo, setx(enemigo.x), malo, sety(enemigo, y), malo, draw(screen).
// ¿ha colisionado con la nave? If (malo, colisión(nave) == true) { done=1; }.
// mostramos todo el frame sdl_flip(screen).
}.
// inicializamos estados.

Void inicia () { int c.

Jugador.x=300, jugador, y=300, enemigo.x=100, enemigo, y=100.

Indice=maxmap100.

Indice_in=0.
// carga del mapa.

If((f=fopen(map, map,r)).= null) { c=fread(mapa,maxmap,1, f), fclose (f).
}.
}.

Void finaliza () {.
// finalizamos los sprites nave, finalice (), malo, finalice (), suelo[.finalice (), suelo[.finalice (), suelo[.finalice ().
// cerramos el joystick if (sdl_joystickopened(0)) { sdl_joystickclose (joystick), } }.
// preparamos los esprites int initsprites() {.

Fnave, load(minave, bmp).

Nave, addframe (fnave).

Fmalo, load(nave, bmp).

Malo, addframe (fmalo).

Tile1.load(tile0.bmp).

Suelo[.addframe (tile1).

Tile2.load(tile1.bmp).

Suelo[.addframe (tile2).

Tile3.load(tile2.bmp), suelo[.addframe (tile3).

Return 0; }.

Int main(int argc, char *argv) {.

Sdl_event event, uint8 *keys.

If (sdl_init(sdl_init_video|sdl_init_joystick) < 0) { printf(no se pudo iniciar SDL: %s\n,sdl_geterror()), return 1.
}.

Scren = sdl_setvideomode (640,480,24,sdl_hwsurface).

If (screen == null) { printf(no se puede inicializar el modo gráfico: \n,sdl_geterror()), return 1.
}.

Atexit(sdl_quit).

Inicializa ().

Initsprites().
While (done == 0) {.
// dibujamos el frame drawscene (screen).
// consultamos el estado del teclado keys=sdl_getkeystate (null).
// consultamos el estado del joystick sdl_joystickupdate ().

Joyx = sdl_joystickgetaxis(joystick, 0), joyy = sdl_joystickgetaxis(joystick, 1).

If ((keys[sdlk_up] || joyy < 10) && (jugador, y > 0)) {jugador, y=jugador, y(5),} if ((keys[sdlk_down] || joyy > 10) && (jugador, y < 460)) {jugador, y=jugador, y+(5),} if ((keys[sdlk_left] || joyx < 10) && (jugador.x > 0)) {jugador.x=jugador.x(5),} if ((keys[sdlk_right] || joyx > 10) && (jugador.x < 620)) {jugador.x=jugador.x+(5),}.
While (sdl_pollevent(&event)) { if (event, type == sdl_quit) {done=1;} if (event, type == sdl_keydown || event, type == sdl_joybutondown) {.

If (event.key.keysym, sym == sdlk_escape) { done=1; } } } }.

Finaliza ().

Return 0; }.

Esta obra esta bajo una licencia attribution-noncommercial-noderivs 2.5 de Creative Commons. Para ver una copia de esta licencia, visite http://creativecommons.org/licenses/by-nc-nd/2.5/ o envíe una carta a Creative Commons, 559 Nathan Abbott way, stanford, california 94305, usa.

Por: Alberto García serrano.

[3dpoder]

enemigos, disparos y explosiones



Perdona siempre a tu enemigo. No hay nada que le enfurezca más, Oscar wilde.

En los ejemplos del anterior capítulo, nuestro avión enemigo esta inmóvil. En este capítulo vamos a hacer que nuestros enemigos cobren vida propia.

Existen múltiples técnicas relacionadas con la inteligencia artificial (ia) y que.

Son ampliamente utilizadas en programación de juegos. La inteligencia artificial es un tópico lo.

Suficientemente extenso como para rellenar varios libros del tamaño del que tienes ahora entre manos. Aun así, exploraremos algunas sencillas técnicas que nos permitirán dotar a los aviones enemigos de nuestro juego de una chispa vital. También vamos a hacer disparar a los aviones enemigos y al nuestro, explosiones incluidas.

Tipos de inteligencia.

Hay, al menos, tres tendencias dentro del campo de la inteligencia artificial.

Redes neuronales.

Algoritmos de búsqueda.

Sistemas basados en conocimiento.

Son tres enfoque diferentes que tratan de buscar un fin común. No hay un enfoque mejor que los demás, la elección de uno u otro depende de la aplicación.

Una red neuronal trata de simular el funcionamiento del cerebro humano. El elemento básico de una red neuronal es la neurona. En una red neuronal, un conjunto de neuronas trabajan al unísono para resolver un problema. Al igual que un niño tiene que aprender al nacer, una red de neuronas artificial tiene que ser entrenada para poder realizar su cometido. Este aprendizaje puede ser supervisado o no supervisado, dependiendo si hace falta intervención humana para entrenar a la red de neuronas. Este entrenamiento se realiza normalmente mediante ejemplos. La aplicación de las redes neuronales es efectiva en campos en los que no existen algoritmos concretos que resuelvan un problema o sean demasiado complejos de computar. Donde más se aplican es en problemas de reconocimiento de patrones y pronósticos.

El segundo enfoque es el de los algoritmos de búsqueda. Es necesario un conocimiento razonable sobre estructuras de datos como árboles y grafos. Una de las aplicaciones interesantes, sobre todo para videojuegos, es la búsqueda de caminos (pathfinding). Seguramente has jugado a juegos de estrategia como Starcraft, age of Empires y otros del estilo. Puedes observar que cuando das la orden de movimiento a uno de los pequeños personajes del juego, éste se dirige al punto indicado esquivando los obstáculos que encuentra en su camino. Este algoritmo de búsqueda en grafos es llamado a*. Tomemos como ejemplo el mapa de la mansión del capítulo 2. Suponiendo que el jugador está en la habitación 1, éste es el árbol de los posible caminos que puede tomar para escapar de la mansión.

39.

Cada círculo representa un nodo del árbol. El número que encierra es el número de habitación. Si quisiéramos encontrar la salida, usaríamos un algoritmo de búsqueda (como, por ejemplo, a*) para recorrer todos los posibles caminos y quedarnos con el que nos interesa. El objetivo es buscar el nodo 8, que es el que tiene la puerta de salida. El camino desde la habitación 1 es: 1 4 5 8. El algoritmo a* además de encontrar el nodo objetivo, nos asegura que es el camino más corto. No vamos a entrar en más detalle, ya que, cae fuera de las pretensiones de este libro profundizar en la implementación de algoritmos de búsqueda.

Por último, los sistemas basados en reglas se sirven, valga la redundancia, de conjuntos de reglas y hechos. Los hechos son informaciones relativas al problema y a su universo. Las reglas son precisamente eso, reglas aplicables a los elementos del universo y que permiten llegar a deducciones simples. Veamos un ejemplo:
Hechos: las moscas tienen alas. Las hormigas no tienen alas.

Reglas: si (x) tiene alas, entonces vuela.

Un sistema basado en conocimiento, con estas reglas y estos hechos es capaz de deducir dos cosas. Que las moscas vuelan y que las hormigas no.

Si (la mosca) tiene alas, entonces vuela.

Uno de los problemas de los sistemas basados en conocimiento es que pueden ocurrir situaciones como estas.

Si (la gallina) tiene alas, entonces vuela.

Desgraciadamente para las gallinas, éstas no vuelan. Puedes observar que la construcción para comprobar reglas es muy similar a la construcción if/then de los lenguajes de programación.

Comportamientos y máquinas de estado.

Una máquina de estados esta compuesta por por una serie de estados y una serie de reglas que indican en que casos se pasa de un estado a otro. Estas máquinas de estados nos permiten modelar comportamientos en los personajes y elementos del juego. Vamos a ilustrarlo con un ejemplo. Imagina que en el juego de la mansión del terror del capítulo 2 hay un zombie. El pobre no tiene una inteligencia demasiado desarrollada y sólo es capaz de andar hasta que se pega contra la pared. Cuando sucede esto, lo único que sabe hacer es girar 45 grados a la derecha y continuar andando. Vamos a modelar el comportamiento del zombie con una máquina de estados. Para ello primero tenemos que definir los posibles estados.

Andando (estado 1).

Girando (estado 2).

Las reglas que hacen que el zombie cambie de un estado a otro son las siguientes.

Si está en el estado 1 y choca con la pared pasa al estado 2.

Si está en el estado 2 y ha girado 45 grados pasa al estado 1.

Con estos estados y estas reglas podemos construir el grafo que representa a nuestra máquina de estados.

figura 7.2.

La implementación de la máquina de estado es muy sencilla. La siguiente función simula el comportamiento del zombie.

Int ángulo.

Void zombie () { int state, ángulo_tmp.
// estado 1.

If (state == 1) { andar(), if (colisión()) {.

State=2, ángulo_tmp=45; } }.
// estado 2.

If (state == 2) { ángulo_tmp=ángulo_tmp1, ángulo=ángulo+1, if (ángulo_tmp <= 0) {.

State=1; } } }.
Éste es un ejemplo bastante sencillo, sin embargo, utilizando este método podrás crear comportamientos inteligentes de cierta complejidad. En el programa ejemplo7_1 el avión enemigo va a tener un movimiento lateral, de lado a lado de la pantalla de forma indefinida. La máquina de estados es la siguiente.

Llega a límite derecho de la pantalla.

llega a límite izquierdo de la pantalla.

Figura 7.3.

Disparos y explosiones.

Ahora que nuestro aviones enemigos son capaces de comportarse tal y como queremos que lo hagan, estamos muy cerca de poder completar nuestro juego. Lo siguiente que vamos a hacer es añadir la capacidad de disparar a nuestro avión. También vamos a ver cómo gestionar la explosión de la nave enemiga cuando es alcanzada. Lo primero que necesitamos es una estructura de datos para contener la información de los disparos.
// estructura que contiene información // de los disparos de nuestro avión.

Struct disparo { int x, y; } bala[maxbalas+.

La constante maxbalas contiene el número máximo de balas simultaneas que nuestro avión puede disparar. Por lo tanto, tenemos un array de balas listas para utilizar. Cada vez que pulsamos la tecla de disparo, hemos de utilizar uno de los elementos de este array para almacenar la información del disparo, por lo tanto la primera tarea es encontrar un elemento libre (que no se esté usando) dentro del array. Una vez encontrado, hemos de inicializar el disparo con la posición del avión. La función creadisparo () realiza este trabajo.

Void creadisparo () {.

Int libre=1.
// ¿hay alguna bala libre? For (int i=0, i<=maxbalas, i++) { if (bala[.x==0) libre=i; }.
// hay una bala.

If (libre>=0) { bala[libr.x=nave, getx(), bala[libr.y=nave, gety()15.
} }.

Para saber si una bala esta o no libre, usaremos su coordenada x. Si vale 0 asumiremos que está libre, si no, es un elemento del array en uso y tendremos que buscar otro. En cada vuelta del game loop, hemos de dibujar los disparos activos si es que los hubiera, el código siguiente se encarga de ello.

Void muevebalas() { int i.

For (i=0, i<=maxbalas, i++) {.
// si la pos.x del disparo no es 0, // es una bala activa, if (bala[.x.= 0) {.

Bala[.y=bala[.y5.
// si el disparo sale de la pantalla la // desactivamos if (bala[, y < 0) { bala[.x=0; } } } }.

Hemos de recorrer todo el array de balas para localizar cuales de ellas necesitan ser actualizadas en la pantalla. Si la coordenada x del disparo es distinta de 0, la bala esta activa y hay que moverla en el eje y (sentido ascendente). Es importante comprobar si la bala sale de la pantalla para poder liberar el elemento del array que ocupa, ya que si no, pronto nos quedaríamos sin poner disparar porque no habría elementos libres en el array.

Nos resta dibujar los disparos. De nuevo, necesitamos recorrer todo el array de disparos y dibujar los que están activos.
// dibuja disparos for (i=0, i<=maxbalas, i++) {.

If (bala[.x.= 0) { mibala, setx(bala[.x), mibala, sety(bala[.y), mibala, draw(screen).
} }.

La misión de los disparos es, como ya sabes, destruir el avión enemigo. Lo lógico es que el avión impactado salte por los aires y produzca una explosión. Vamos a utilizar la siguiente estructura de datos para contener la explosión.
// estructura que contiene información // de la explosión structure explosión {.

Int activo,x y, nframe; } exp.

Además, de las coordenadas de la explosión, necesitamos un campo que nos indique si la explosión esta activa. El sprite utilizado para la explosión tiene alguna diferencia con los utilizados hasta ahora. Este sprite está formado por los 7 frames que componen la animación de la explosión. El campo nframe contiene el frame que se está mostrando en la actualidad, por lo tanto, en cada repintado de la imagen, hemos de incrementar nframe para crear el efecto de animación. Cuando esta variable llega a 7, es decir, el número de frames que componen la animación, nos indica que la explosión ha terminado, por lo que hay que desactivarla. El código siguiente realiza la tarea de dibujar la explosión.
// dibujar explosión.

If (exp, activo==1) { explode, selframe (exp, nframe), explode, setx(exp.x), explode, sety(exp, y), explode, draw(screen), exp, nframe=exp, nframe+1, if (exp, nframe>=7) {.

Exp, activo=0, done=1; } }.

La explosión ha de activarse cuando el sprite del avión enemigo colisione con una bala. Al producirse el impacto, hemos de eliminar el avión enemigo para que no siga dibujándose y activar la explosión. Las coordenadas de la explosión serán las mismas que las que tenía la nave enemiga.
// ¿ha colisionado el disparo con la nave?
If (malo, colisión(mibala) == true) { enemigo, estado=0, exp, activo=1, exp, nframe=1.

Exp.x=enemigo.x, exp, y=enemigo, y; }.

Tienes el código completo en el programa ejemplo7_1.

figura 7.4.
/************************************************** ************************* ejemplo7_1.
(C) 2003 by Alberto García serrano programación de videojuegos con SDL ************************************************** *************************/.
#include <stdio, h> #include <stdlib, h> #include <sdl.h> #include csprite, h.
#define maxmap 400 #define maxbalas 8.

Sdl_surface *screen, cframe fnave, cframe fmalo, cframe tile1, cframe tile2, cframe tile3, cframe labala, cframe ex1, cframe ex2, cframe ex3, cframe ex4, cframe ex5, cframe ex6, cframe ex7, csprite nave (1), csprite malo (1), csprite suelo[, csprite mibala (1), csprite explode (, sdl_rect rectángulo, sdl_joystik *joystick, char mapa[40, int joyx, joyy, int done=0, int índice, indice_in, file *f.
// estructura que contiene la información // de nuestro avión structure minave {.

Int x, y; } jugador.
// estructura que contiene información // del avión enemigo structure navenemiga {.

Int x y, estado; } enemigo.
// estructura que contiene información // de los disparos de nuestro avión structure disparo {.

Int x, y; } bala[maxbalas+.
// estructura que contiene información // de la explosión structure explosión {.

Int activo,x y, nframe; } exp.

Void muevenave () {.
// estado 1. Movimiento a la derecha, if (enemigo, estado == 1) {.

Enemigo.x=enemigo.x+2, if (enemigo.x>600) enemigo, estado=2; }.
// estado2. Movimiento a la izquierda.

If (enemigo, estado == 2) { enemigo.x=enemigo.x2, if (enemigo.x<40) enemigo, estado=1.
} }.

Void muevebalas() { int i.

For (i=0, i<=maxbalas, i++) {.
// si la pos.x del disparo no es 0, // es una bala activa, if (bala[.x.= 0) {.

Bala[.y=bala[.y5.
// si el disparo sale de la pantalla la desactivamos if (bala[, y < 0) { bala[.x=0; } } } }.
// dibuja el escenario Void drawscene (sdl_surface *screen) { int i,x y, t.
// movimiento del escenario (scroll) indice_in+=2, if (indice_in>=64) {.

Indice_in=0, indice=10; }.

If (indice <= 0) { indice=maxmap100; // si llegamos al final, empezamos de nuevo, indice_in=0.
}.
//dibujar escenario for (i=0, i<10, i++) {.

For (j=0, j<10, j++) { t=mapa[indice+(i*10+j)]; // cálculo de la posición del Tile x=j*64, y=(i1)*64+indice_in.
// dibujamos el Tile suelo[t].setx(x), suelo[t].sety(y), suelo[t].draw(screen).
} }.
// dibuja avión nave, setx(jugador.x), nave, sety(jugador, y), nave, draw(screen).
// dibuja enemigo.

If (enemigo, estado.= 0) { malo, setx(enemigo.x), malo, sety(enemigo, y), malo, draw(screen).
}.
// dibuja disparos for (i=0, i<=maxbalas, i++) {.

If (bala[.x.= 0) { mibala, setx(bala[.x), mibala, sety(bala[.y), mibala, draw(screen).
} }.
// dibujar explosión.

If (exp, activo==1) { explode, selframe (exp, nframe), explode, setx(exp.x), explode, sety(exp, y), explode, draw(screen), exp, nframe=exp, nframe+1, if (exp, nframe>=7) {.

Exp, activo=0, done=1; } }.
// ¿ha colisionado con la nave? If (malo, colisión(nave) == true) { done=1; }.
// ¿ha colisionado el disparo con la nave?
If (malo, colisión(mibala) == true) { enemigo, estado=0, exp, activo=1, exp, nframe=1, exp.x=enemigo.x, exp, y=enemigo, y.
}.
// mostramos todo el frame sdl_flip(screen).
}.

Void creadisparo () {.

Int libre=1.
// ¿hay alguna bala libre? For (int i=0, i<=maxbalas, i++) { if (bala[.x==0) libre=i; }.
// hay una bala.

If (libre>=0) { bala[libr.x=nave, getx(), bala[libr.y=nave, gety()15; }.
}.
// inicializamos estados.

Void inicia () { int i, c.

Jugador.x=300, jugador, y=300, enemigo.x=100, enemigo, y=100, explode, finalice (), indice=maxmap100, indice_in=0.

Enemigo, estado=1.

Exp, activo=0.
// inicializamos el array de balas.

For (i=0, i<=maxbalas, i++) { bala[.x=0, bala[.y=0.
}.
// carga del mapa.

If((f=fopen(map, map,r)).= null) { c=fread(mapa,maxmap,1, f), fclose (f).
}.
}.

Void finaliza () {.
// finalizamos los sprites nave, finalice (), malo, finalice (), mibala, finalice ().

Suelo[.finalice (), suelo[.finalice (), suelo[.finalice ().
// cerramos el joystick if (sdl_joystickopened(0)) { sdl_joystickclose (joystick), } }.
// preparamos los esprites int initsprites() {.

Fnave, load(minave, bmp).

Nave, addframe (fnave).

Fmalo, load(nave, bmp).

Malo, addframe (fmalo).

Tile1.load(tile0.bmp).

Suelo[.addframe (tile1).

Tile2.load(tile1.bmp).

Suelo[.addframe (tile2).

Tile3.load(tile2.bmp).

Suelo[.addframe (tile3).

Labala, load(balas, bmp).

Mibala, addframe (labala).

Ex1.load(explode1.bmp).

Explode, addframe (ex1).

Ex2.load(explode2.bmp).

Explode, addframe (ex2).

Ex3.load(explode3.bmp).

Explode, addframe (ex3).

Ex4.load(explode4.bmp).

Explode, addframe (ex4).

Ex5.load(explode5.bmp).

Explode, addframe (ex5).

Ex6.load(explode6.bmp).

Explode, addframe (ex6).

Ex7.load(explode7.bmp).

Explode, addframe (ex7).

Return 0; } int main(int argc, char *argv) {.

Sdl_event event, uint8 *keys.

If (sdl_init(sdl_init_video|sdl_init_joystick) < 0) { printf(no se pudo iniciar SDL: %s\n,sdl_geterror()), return 1.
}.

Scren = sdl_setvideomode (640,480,24,sdl_hwsurface).

If (screen == null) { printf(no se puede inicializar el modo gráfico: \n,sdl_geterror()), return 1.
}.

Atexit(sdl_quit).

Inicializa ().

Initsprites().
While (done == 0) {.
// movemos el avión enemiga muevenave ().
// movemos los disparos muevebalas().
// dibujamos el frame drawscene (screen).
// consultamos el estado del teclado keys=sdl_getkeystate (null).
// consultamos el estado del joystick sdl_joystickupdate ().

Joyx = sdl_joystickgetaxis(joystick, 0), joyy = sdl_joystickgetaxis(joystick, 1).

If ((keys[sdlk_up] || joyy < 10) && (jugador, y > 0)) {jugador, y=jugador, y(5),} if ((keys[sdlk_down] || joyy > 10) && (jugador, y < 460)) {jugador, y=jugador, y+(5),} if ((keys[sdlk_left] || joyx < 10) && (jugador.x > 0)) {jugador.x=jugador.x(5),} if ((keys[sdlk_right] || joyx > 10) && (jugador.x < 620)) {jugador.x=jugador.x+(5),} if (keys[sdlk_lshift]) {creadisparo (),}.
While (sdl_pollevent(&event)) { if (event, type == sdl_quit) {done=1;} if (event, type == sdl_keydown || event, type == sdl_joybutondown) {.

If (event.key.keysym, sym == sdlk_escape) { done=1; } } } }.

Finaliza ().

Return 0; }.

Esta obra esta bajo una licencia attribution-noncommercial-noderivs 2.5 de Creative Commons. Para ver una copia de esta licencia, visite http://creativecommons.org/licenses/by-nc-nd/2.5/ o envíe una carta a Creative Commons, 559 Nathan Abbott way, stanford, california 94305, usa.

Por: Alberto García serrano.

[3dpoder]

que comience el juego.



Todo comienzo tiene su encanto, Goethe.

A estas alturas estas casi preparado para comenzar a hacer tu propio juego. Seguro que ya tienes alguna idea en mente, pero antes, vamos a finalizar el que tenemos entre manos. Todavía nos quedan por ver algunos detalles, que aun siendo pequeños, no dejan de ser importantes. Es este capítulo vamos a completar todos los aspectos del juego y a ofrecer su listado completo. Por cierto, aún no le hemos puesto un nombre. Lo llamaremos 1945, como homenaje al juego 1942.

Enemigos.

Nuestro juego va a tener tres tipos de aviones enemigos. El primer tipo son los kamikaze, que se lanzaran en diagonal por la pantalla en dirección de nuestro avión tratando de impactar con nosotros. El segundo tipo, los cazas, realizaran una maniobra de aproximación, y cuando nos tengan a tiro, lanzaran un proyectil para después comenzar una acción evasiva. El tercer tipo es el avión jefe, con el que tendremos que enfrentarnos al final de cada nivel, y al que necesitaremos disparar 100 veces para poder destruirlo. Además, varios de estos enemigos se encontraran a la vez en pantalla. Para manejar los aviones enemigos necesitamos mejorar la estructura de datos que utilizamos en el capítulo anterior.

Struct navenemiga {.

Int activo,x y, dx, dy, tipo, estado, impactos, nframe; } enemigo[.

Como podrá haber un máximo de 7 enemigos a la vez en la pantalla, creamos un array de 7 elementos. El campo activo, nos indicara si se está utilizando ese elemento del array actualmente o, por el contrario esta libre para poder utilizarlo (igual que hacíamos con el array de disparos). Los campos x e y son las coordenadas del avión. Los campos DX y dy son importantes: indican la dirección del avión para su movimiento. Estos valores se suman a las coordenadas del avión en cada frame. Veamos mejor con un ejemplo. Si queremos que nuestra nave se mueva de arriba a abajo de forma vertical, a una velocidad de 3 píxeles por frame, daremos los siguientes valores a estos campos:
Dx = 0 dy = 3.

La operación que se realiza en cada frame es:
X = x + DX y = y + dy.

Con lo que las coordenadas del avión quedarán actualizadas a la nueva posición. Dándole un valor de -3 a dy conseguiremos que el avión ascienda en vez de descender por la pantalla, y dándole un valor de 3 tanto a DX como a dy conseguiremos que se mueva de forma diagonal descendente. El campo tipo nos indican qué tipo de enemigo es. Si vale 0 será un caza, si vale 1 será un kamikaze y si vale 3 será el avión jefe. El campo estado nos indica el estado del avión. Lo utilizaremos en el caza para saber si su estado es el de acercarse para disparar o el de dar la vuelta para huir. El campo impactos indica el número de impactos que ha sufrido el avión. Lo utilizaremos con el avión jefe al que sólo podremos destruir después de 100 impactos. Por último, el campo nframe lo utilizaremos para almacenar el frame actual dentro de la animación. En concreto, lo utilizaremos en el caza para realizar la animación de looping que realiza para huir después de soltar el proyectil.

La función siguiente será la encargada de ir creando enemigos.

Void creaenemigo () { int libre=1.
// ¿hay algún enemigo libre? For (int i=0, i<=nmalos, i++) { if (enemigo[.activo==0) libre=i; }.
// hay un enemigo dispuesto.

If (libre>=0) { enemigo[libr.activo=1, enemigo[libr.nframe=0, enemigo[libr.x=Rand(), if (enemigo[libr.x > 640).

Enemigo[libr.x=(int)enemigo[libr.x % 640, enemigo[libr.tipo=Rand(), if (enemigo[libr.tipo >= 2).

Enemigo[libr.tipo=(int)enemigo[libr.tipo % 2; // 2 tipos de enemigos (0,1).

If (enemigo[libr.tipo==0) { enemigo[libr.y=30, enemigo[libr.dx=0, enemigo[libr.dy=5, enemigo[libr, estado=0.
}.

If (enemigo[libr.tipo==1) { enemigo[libr.y=30, if (enemigo[libr.x>nave, getx()) {.

Enemigo[libr.dx=3; } else {.

Enemigo[libr.dx=3; } enemigo[libr.dy=5.

Enemigo[libr, estado=0; }.
} }.

Al igual que hacíamos con los disparos, al encontrar un elemento libre del array de enemigos, lo ponemos activo e inicializamos su estado. La coordenada x inicial del avión se calcula de forma aleatoria. También establecemos de forma aleatoria qué tipo de enemigo es (tipo 1, es decir, el caza o 2, que es el kamikaze). Dependiendo del tipo de enemigo, inicializamos sus coordenadas (x e y) y sus parámetros de movimiento (dx y dy). La función de movimiento sólo ha de actualizar las coordenadas del avión de la siguiente forma.

Enemigo[.x=enemigo[.x+enemigo[.dx, enemigo[.y=enemigo[.y+enemigo[.dy.

Durante el juego, vamos a generar un avión enemigo cada 20 ciclos de juego (o lo que es lo mismo, 20 vueltas del game loop). Para saber cuándo tenemos que generar un enemigo utilizamos la fórmula ciclos%20. Para crear un jefe, en cambio, esperamos 5000 ciclos (ciclos%5000).

En lo referente a los disparos enemigos, la técnica es exacta a la utilizada en el anterior capítulo con dos diferencias. La primera es que usamos un array de disparos, igual que hacemos con los enemigos, y la otra es que introducimos en la estructura de datos un campo llamado time. La función de este campo es controlar el tiempo para saber cuándo hacer parpadear el disparo. El disparo enemigo parpadea cada 5 ciclos para hacerlo más visible.

Niveles.

Cualquier juego que se precie tiene que tener niveles. El avión jefe es el guardián del siguiente nivel. Para crear los niveles, vamos a seguir unas simples normas. Los mapas y demás archivos necesarios para los niveles van a estar almacenados en una estructura de directorios como sigue:
/levels/.
/level1.
/level2.
/leveln.

Es decir, dentro del directorio level crearemos un subdirectorio por cada nivel. Dentro de cada uno de estos subdirectorios almacenaremos un archivo llamado map, map con la descripción del mapa. Otro archivo llamado level, dsc que contendrá en formato texto el número de tiles que compone el mapa menos 1, es decir, si tiene 7 tiles, este archivo contendrá el valor 6. Por último, estarán aquí también todos los tiles que componen el mapa nombrados como tile0.bmp, tile1.bmp, etc. El siguiente código se encarga de cargar un nivel.

Void loadlevel(int l) {.

Initestados().

Leveltime=100.
// cargar mapa (10x40) char tmplevel[5, int i, c, ntiles.

Sprintf(tmplevel,levels/level%d/map, map, l).

If((f=fopen(tmplevel,r)).= null) { c=fread(mapa,maxmap,1, f), fclose (f).
}.
// cargar tiles del suelo sprintf(tmplevel,levels/level%d/level, dsc, l), if((f=fopen(tmplevel,r)).= null) {.

Fgets(tmplevel,255, f), ntiles=atoi (tmplevel), fclose (f).
}.

For (i=0, i<=ntiles, i++) { sprintf(tmplevel,levels/level%d/tile%d, bmpl, i), frsuelo[.load(tmplevel), suelo[.addframe (frsuelo[).
} }.

A esta función le pasamos como parámetro el nivel que queremos cargar. Ella se encarga de carga el mapa en memoria y de cargar los tiles (como sprites). Al comenzar a jugar en un nivel, nos aparecerá superpuesto en la pantalla el nivel que estamos jugando de forma parpadeante durante algunos segundos. La variable leveltime indica el tiempo en ciclos que se mostrara el nivel. Este es el código que realiza este trabajo.
// muestra el nivel en el que estamos jugando.

If ((leveltime>=1) && leveltime%2) { sprintf(msg,level %d, level), ttext = tf_rendertext_shaded(fuente, msg, fgcolor, bgcolor), rectángulo, y=240, rectángulo.x=310, rectángulo.w=ttext>w, rectángulo, h=ttext>h, sdl_setcolorkey(ttext,sdl_srcolorkey|sdl_rleacel, sdl_maprgb(ttext.
>format,255,0,0)), sdl_blitsurface (ttext,null, screen,&rectángulo), }.

Cada 2 ciclos mostramos (leveltime%2) el mensaje, de forma que dará la apariencia de paradeo, temporización.

Controlar la velocidad del juego es importante. No podemos permitirnos que nuestro juego se ejecute a una velocidad diferente en dos máquinas distintas. Vamos a servirnos de dos funciones para realizar este control.

Void resettimebase () {.

Ini_milisegundos=sdl_getticks(), }.

Int currenttime () {.

Fin_milisegundos=sdl_getticks().

Return fin_milisegundosini_milisegundos; }.

La función resettimebase () utiliza la función sdl_getticks para almacenar el tiempo en milisegundos transcurridos desde la inicialización de SDL. Este valor, es utilizado por la función currenttime () para calcular cuantos milisegundos han transcurrido desde la llamada a resettimebase (). El procedimiento de control es el siguiente. Al principio del game loop realizamos una llamada a resettimebase () para inicializar el contador. Al finalizar el game loop utilizamos el siguiente código.

Do {.

Frametime=currenttime (), } while (frametime<30).

Este bucle se ejecutara mientras no hayan transcurrido, al menos, 30 milisegundos. Es decir, nos aseguramos de que no se van a producir más de un frame cada 30ms. De esta forma, si ejecutamos nuestro juego en un ordenador muy rápido, la velocidad se mantendrá constante e igual a la de otro ordenador más lento, pantalla inicial, puntuación y vidas.

Al jugador hay que ofrecerle información de, al menos, dos datos: las vidas que le restan y la puntuación que ha conseguido hasta al momento. La puntuación se almacena en una variable global llamada score. El código que la muestra en pantalla es el siguiente.
// dibuja la puntuación sprintf(msg,%d, score), ttext = tf_rendertext_shaded(fuente, msg, fgcolor, bgcolor), rectángulo, y=5, rectángulo.x=530, rectángulo.w=ttext>w, rectángulo, h=ttext>h, sdl_setcolorkey(ttext,sdl_srcolorkey|sdl_rleacel, sdl_maprgb(ttext.
>format,255,0,0)), sdl_blitsurface (ttext,null, screen,&rectángulo).

Este código no necesita demasiada explicación. Simplemente comentar que utilizamos la función sprintf() para pasar el valor de la puntuación, que es de tipo int, a una cadena de texto tipo char.

El número de vidas se va a mostrar al jugador de forma gráfica con pequeños aviones. Tantos como vidas tengamos. Este código dibuja los aviones (almacenados en el sprite life) cada 22 píxeles.
// dibuja las vidas del jugador.

For (i=1, i<=jugador, vidas, i++) {.

Life, setx(10+(i*22)).

Life, sety(5).

Life, draw(screen), }.

Es habitual ofrecer al jugador una vida extra cuando consigue algún objetivo concreto. En nuestro caso, vamos a regalar una vida cada 2000 puntos.
// ¿vida extra?
If (score % 2000 == 0 && score > 0) {.

Score+=10.

Jugador, vidas++; }.

Por último, lo que le falta a nuestro juego es una portada. Al ejecutar el juego, haremos aparecer una pantalla de presentación y esperaremos la pulsación de una tecla o del botón del joystick para empezar a jugar. Para ello tenemos una variable llamada estado. Si estado vale 0, el game loop muestra la pantalla de presentación, si vale 1, quiere decir que estamos jugando y muestra el juego. Este es el código completo del juego.



/************************************************** ************************* 1945.
(C) 2003 by Alberto García serrano programación de videojuegos con SDL ************************************************** *************************/.
#include <stdio, h> #include <string, h> #include <stdlib, h> #include <time, h> #include <sdl.h> #include sdl_mixer, h #include sdl_ttf, h #include csprite, h.
// mapa.
#define maxtiles 10 #define maxmap 400.

Char mapa[40.

Sdl_surface *screen, sdl_rect rect, cframe fnave, cframe fmalo1_1, cframe fmalo1_2, cframe fmalo1_3, cframe fmalo1_4, cframe fmalo1_5, cframe fmalo2, cframe fmalo3, cframe bala, cframe ex1, cframe ex2, cframe ex3, cframe ex4, cframe ex5, cframe ex6, cframe ex7, cframe dis, cframe dis2, cframe vida, cframe pant, cframe frsuelo[maxtile, cframe flevel, csprite slevel(1), csprite suelo[maxtile, csprite pantalla (1), csprite explode (12), csprite nave (1), csprite malo2(1), csprite malo3(1), csprite malo1(5), csprite mibala (1), csprite dispene (2), csprite life (1), int ciclos, leveltime, int índice, indice_in, int nexplosiones=7, nmalos=6, nbalas=6, ndispenemigos=7, mibalax[, mibalay[, int done=0, estado=0, conjefe=0, level=1, score=0, uint32 ini_milisegundos, fin_milisegundos, frametime, sint16 joyx, joyy, mix_music *música, mix_chunque *explosión,*disparo, sdl_joystik *joystick, tf_font *fuente, sdl_surface *ttext, sdl_color bgcolor, fgcolor, sdl_rect rectángulo, file *f.

Struct minave { int activo,x y, idas, time.
} jugador.

Struct navenemiga { int activo,x y, dx, dy, tipo, estado, impactos, nframe; } enemigo[.

Struct explosión { int activo,x y, nframe; } exp[.

Struct disparo { int activo,x y, dx, dy, estado, time; } Disp[.

Int dx=2, dy=2.

Void creaexplosion(int), Void creadispenemigo (int), Void resettimebase (Void), Void creajefe (Void), Void loadlevel(int), int currenttime (Void).

Void drawscene (sdl_surface *screen) { int i, jt,x, y, char msg[3.
// movimiento del escenario (scroll) indice_in+=2, if (indice_in>=64) {.

Indice_in=0, indice=10; }.

If (indice <= 0) { indice=maxmap100; // si llegamos al final, empezamos de nuevo, indice_in=0.
}.
//dibujar escenario for (i=0, i<10, i++) {.

For (j=0, j<10, j++) { t=mapa[indice+(i*10+j)]; // cálculo de la posición del Tile x=j*64, y=(i1)*64+indice_in.
// dibujamos el Tile suelo[t].setx(x), suelo[t].sety(y), suelo[t].draw(screen).
} }.
// dibuja nave.

If (jugador, activo==1) { nave, setx(jugador.x), nave, sety(jugador, y), nave, draw(screen).
}.

If (jugador, activo==2 && jugador, time%2==0) { nave, setx(jugador.x), nave, sety(jugador, y), nave, draw(screen).
}.
// dibuja enemigo for (i=0, i<=nmalos, i++) { if (enemigo[.activo==1) {.

If (enemigo[.tipo==0) { malo1.setx(enemigo[.x), malo1.sety(enemigo[.y), malo1.selframe (enemigo[.nframe).

Malo1.draw(screen), // ¿ha colisionado con la nave? If (malo1.colisión(nave) == true && jugador, activo==1) {.

Jugador, vidas, creaexplosion(255), jugador, time=30, jugador, activo=0.
}.
}.

If (enemigo[.tipo==1) { malo2.setx(enemigo[.x), malo2.sety(enemigo[.y), malo2.draw(screen), // ¿ha colisionado con la nave? If (malo2.colisión(nave) == true && jugador, activo==1) {.

Jugador, vidas, creaexplosion(255), jugador, time=30, jugador, activo=0.
}.
}.

If (enemigo[.tipo==3) { malo3.setx(enemigo[.x), malo3.sety(enemigo[.y), malo3.draw(screen), // ¿ha colisionado con la nave? If (malo3.colisión(nave) == true && jugador, activo==1) {.

Jugador, vidas, creaexplosion(255), jugador, time=30, jugador, activo=0.
} }.
} }.
// dibujamos las explosiones for (i=0, i<=nexplosiones, i++) {.

If (exp[.activo==1) { explode, selframe (exp[.nframe), explode, setx(exp[.x), explode, sety(exp[.y), explode, draw(screen), exp[.nframe=exp[.nframe+1, if (exp[.nframe>=7) {.

Exp[.activo=0; } } }.
// dibujamos los disparos for (i=0, i<=nbalas, i++) {.

If (mibalax[) { mibala, setx(mibalax[), mibala, sety(mibalay[), mibala, draw(screen).
// ¿hay colisión con alguna nave? For (int j=0, j<=nmalos, j++) { if (enemigo[j].activo==1) {.

Switch (enemigo[j].tipo) {.

Case 0: // comprobamos impacto con nave tipo 0 malo1.setx(enemigo[j].x), malo1.sety(enemigo[j].y), if (mibala, colisión(malo1) == true) {.
// le hemos dado creaexplosion(j), enemigo[j].activo=0, mibalax[=0, score=score+10.
} break.

Case 1: // comprobamos impacto con nave tipo 1 malo2.setx(enemigo[j].x), malo2.sety(enemigo[j].y), if (mibala, colisión(malo2)) {.
// le hemos dado creaexplosion(j), enemigo[j].activo=0, mibalax[=0, score=score+10.
} break.

Case 3: // comprobamos impacto con nave tipo 3 malo3.setx(enemigo[j].x), malo3.sety(enemigo[j].y), if (mibala, colisión(malo3)) {.
// le hemos dado enemigo[j].impactos++, mibalax[=0; // 100 impactos para destruir al jefe if (enemigo[j].impactos >=100) {.

Creaexplosion(j), enemigo[j].activo=0, score=score+100, conjefe=2; // el jefe ha muerto leveltime=100; // tiempo hasta el cambio de nivel level++.
} } break.
}.
} }.
} }.
// dibujamos los disparos enemigos for (i=0, i<=ndispenemigos, i++) {.

If (disp[.activo==1) { dispene, setx(disp[.x), dispene, sety(disp[.y), // parpadeo del disparo cada 5 ciclos Disp[.time++, if (disp[.time>=5) {.

Disp[.time=0.

If (disp[, estado==0) { dispene, selframe (1), Disp[, estado=1.
} else { dispene, selframe (0), Disp[, estado=0.
} } dispene, draw(screen).
// ¿nos han dado?
If (dispene, colisión(nave) && jugador, activo==1) { jugador, vidas, creaexplosion(255), jugador, time=30, jugador, activo=0.
} } }.
// dibuja las vidas del jugador.

For (i=1, i<=jugador, vidas, i++) { life, setx(10+(i*22)), life, sety(5), life, draw(screen).
}.
// dibuja la puntuación sprintf(msg,%d, score), ttext = tf_rendertext_shaded(fuente, msg, fgcolor, bgcolor), rectángulo, y=5, rectángulo.x=530, rectángulo.w=ttext>w, rectángulo, h=ttext>h, sdl_setcolorkey(ttext,sdl_srcolorkey|sdl_rleacel, sdl_maprgb(ttext>format,255,0,0)), sdl_blitsurface (ttext,null, screen,&rectángulo).
// muestra el nivel en el que estamos jugando.

If ((leveltime>=1) && leveltime%2) { sprintf(msg,level %d, level), ttext = tf_rendertext_shaded(fuente, msg, fgcolor, bgcolor), rectángulo, y=240, rectángulo.x=310, rectángulo.w=ttext>w, rectángulo, h=ttext>h, sdl_setcolorkey(ttext,sdl_srcolorkey|sdl_rleacel, sdl_maprgb(ttext.
>format,255,0,0)), sdl_blitsurface (ttext,null, screen,&rectángulo), }.
// mostramos todo el frame sdl_flip(screen), }.

Void muevenaves() {.

Int i.
// esperamos a que el jugador esté preparado para seguir jugando // después de perder una vida, if (jugador, activo==2) {.

Jugador, time.

If (jugador, time<=0) { jugador, time=0, jugador, activo=1.
} }.
// decrementamos el contador de tiempo de nuestra nave en el caso // de a ver sido destruidos. Si el tiempo ha pasado, el jugador continua, if (jugador, activo==0) {.

Jugador, time.

If (jugador, time<=0) { jugador, time=50, if (jugador, vidas==0).

Estado=0.

Jugador, activo=2, jugador.x=320, jugador, y=400.
} }.
// actualizamos la posición de las balas for (i=0, i<=nbalas, i++) { if (mibalax[) { mibalay[=(mibalay[)10.
// ¿ha salido la bala de la pantalla? If (mibalay[<=10) { mibalax[=mibalay[=0.
}.
} }.
// animación (interna) de los sprites for (i=0, i<=nmalos, i++) { if (enemigo[.activo == 1) {.
// animación del enemigo tipo 0 (loop) if (enemigo[.tipo == 0 && enemigo[, estado == 1) { if (enemigo[.nframe < malo1.frames()) enemigo[.nframe++; } } }.
// movimiento de los enemigos for (i=0, i<=nmalos, i++) {.

If (enemigo[.activo == 1) { enemigo[.x=enemigo[.x+enemigo[.dx, enemigo[.y=enemigo[.y+enemigo[.dy.
// movimiento enemigo tipo 0 if (enemigo[.tipo == 0) {.

If (enemigo[, estado==0 && enemigo[.y>240) { creadispenemigo (i), enemigo[.dy=3, enemigo[.dx=0, enemigo[, estado=1.
}.
}.
// movimiento del jefe.

If (enemigo[.tipo == 3) { // reglas para el movimiento lateral, if (enemigo[.x>500) enemigo[.dx=3, if (enemigo[.x<20) enemigo[.dx=3.
// un disparo cada 30 ciclos if (.(ciclos%30)) { creadispenemigo (i), }.
}.
// ¿salió la nave de la pantalla? If (enemigo[.y>480 || enemigo[.y<50) enemigo[.activo=0; } }.
// movimiento de las balas enemigas for (i=0, i<=ndispenemigos, i++) {.

If (disp[.activo==1) { Disp[.x=disp[.x+disp[.dx, Disp[.y=disp[.y+disp[.dy.
// ¿ha salido de la pantalla? If (disp[.y>480) Disp[.activo=0; } }.
}.

Void creadisparo () { int libre=1.
// ¿hay alguna bala libre? For (int i=0, i<=nbalas, i++) { if (mibalax[==0) libre=i; }.
// hay una bala.

If (libre>=0) { mibalax[libr=nave, getx(), mibalay[libr=nave, gety()15.
}.
// sonido del disparo mix_playchannel(1, disparo,0), }.

Void creaenemigo () { int libre=1.
// ¿hay algún enemigo libre? For (int i=0, i<=nmalos, i++) { if (enemigo[.activo==0) libre=i; }.
// hay un enemigo dispuesto.

If (libre>=0) { enemigo[libr.activo=1, enemigo[libr.nframe=0, enemigo[libr.x=Rand(), // pos.x aleatoria if (enemigo[libr.x > 640).

Enemigo[libr.x=(int)enemigo[libr.x % 640, enemigo[libr.tipo=Rand(), // tipo de enemigo aleatorio if (enemigo[libr.tipo >= 2).

Enemigo[libr.tipo=(int)enemigo[libr.tipo % 2; // 2 tipos de enemigos (0,1).
// tipo caza.

If (enemigo[libr.tipo==0) { enemigo[libr.y=30, enemigo[libr.dx=0, enemigo[libr.dy=5, enemigo[libr, estado=0.
}.
// tipo kamikaze.

If (enemigo[libr.tipo==1) { enemigo[libr.y=30, if (enemigo[libr.x>nave, getx()) {.

Enemigo[libr.dx=3; } else {.

Enemigo[libr.dx=3; } enemigo[libr.dy=5, enemigo[libr, estado=0.
}.
} }.

Void creajefe () { int libre=1.

Enemigo[libr.activo=1, enemigo[libr.tipo=3, enemigo[libr.y=100, if (enemigo[libr.x>nave, getx()) {.

Enemigo[libr.dx=3; } else {.

Enemigo[libr.dx=3; } enemigo[libr.dy=0.

Enemigo[libr, estado=0, enemigo[libr.impactos=0.
}.

Void creaexplosion(int) {.

Int libre=1.

For(int i=0, i<=nexplosiones, i++) { if (exp[.activo==0) libre=i; }.

If (libre>=0) {.

If (j.=255) { // si = 255 la explosión es para el jugador exp[libr.activo=1, exp[libr.nframe=1, exp[libr.x=enemigo[j].x, exp[libr.y=enemigo[j].y.
} else { exp[libr.activo=1, exp[libr.nframe=1, exp[libr.x=jugador.x, exp[libr.y=jugador, y.
} }.
// sonido de explosión mix_playchannel(1, explosión,0), }.

Void creadispenemigo (int) { int libre=1.

For(int i=0, i<=ndispenemigos, i++) { if (disp[.activo==0) libre=i; }.

If (libre>=0) { Disp[libr.activo=1, if (enemigo[j].x>nave, getx()) {.

Disp[libr.dx=3; } else {.

Disp[libr.dx=3; } Disp[libr.dy=3, Disp[libr.x=enemigo[j].x+30, Disp[libr.y=enemigo[j].y+20, Disp[libr, estado=0, Disp[libr.time=0.
} }.

Void initestados() {.

Int i.

Jugador, activo=1, jugador, vidas=3, jugador.x=320, jugador, y=400.
// inicializamos el array de balas.

For (i=0, i<=nbalas, i++) { mibalax[=0, mibalay[=0.
}.
// inicializamos el array de enemigos for (i=0, i<=nmalos, i++) { enemigo[.activo=0; }.
// inicializamos el array de explosiones for (i=0, i<=nexplosiones, i++) { exp[.activo=0; }.
// inicializamos el array de disparos enemigos for(i=0, i<=ndispenemigos, i++) { Disp[.activo=0; }.
// inicia colores para el texto fgcolor, r=200, fgcolor, g=200, fgcolor, b=10.

Bgcolor, r=255, bgcolor, g=0, bgcolor, b=0.
// posición inicial en el mapa indice=maxmap100, indice_in=0.

Ciclos=0, conjefe=0; }.

Void loadlevel(int l) {.

Initestados().

Leveltime=100.
// cargar mapa (10x40) char tmplevel[5, int i, c, ntiles.

Sprintf(tmplevel,levels/level%d/map, map, l).

If((f=fopen(tmplevel,r)).= null) { c=fread(mapa,maxmap,1, f), fclose (f).
}.
// cargar tiles del suelo sprintf(tmplevel,levels/level%d/level, dsc, l), if((f=fopen(tmplevel,r)).= null) {.

Fgets(tmplevel,255, f), ntiles=atoi (tmplevel), fclose (f).
}.

For (i=0, i<=ntiles, i++) { sprintf(tmplevel,levels/level%d/tile%d, bmpl, i), frsuelo[.load(tmplevel), suelo[.addframe (frsuelo[).
} }.

Void inicia () { // carga la fuente de letra fuente = tf_openfont(ariblk, ttf,20).
// activa el joystick.

If (sdl_numjoysticks() >= 1) { joystick = sdl_joystickopen(0), sdl_joystickeventstate (sdl_enable).
}.
// carga la música y los sonidos música = mix_loadmus(sounds/rwvalkyr, Mid), explosión = mix_loadwav(sounds/explosión.wav), disparo = mix_loadwav(sounds/disparo.wav).
} Void finaliza () {.
// destruimos la fuente de letra tf_closefont(fuente).
// destrimos la música mix_fremusic(música).
// cerramos el joystick if (sdl_joystickopened(0)) { sdl_joystickclose (joystick), }.
}.

Int initsprites() {.

Int i.
// inicializamos el generador de números aleatorios srand((unsigned)time (null)).
// inicializamos el array de balas.

For (i=0, i<=nbalas, i++) { mibalax[=0, mibalay[=0.
}.
// inicializamos el array de enemigos for (i=0, i<=nmalos, i++) { enemigo[.activo=0; }.
// inicializamos el array de explosiones for (i=0, i<=nexplosiones, i++) { exp[.activo=0; }.

Pant, load(pics/pantalla, bmp).

Pantalla, addframe (pant).

Ex1.load(pics/explode1.bmp), explode, addframe (ex1).

Ex2.load(pics/explode2.bmp), explode, addframe (ex2).

Ex3.load(pics/explode3.bmp), explode, addframe (ex3).

Ex4.load(pics/explode4.bmp), explode, addframe (ex4).

Ex5.load(pics/explode5.bmp), explode, addframe (ex5).

Ex6.load(pics/explode6.bmp), explode, addframe (ex6).

Ex7.load(pics/explode7.bmp), explode, addframe (ex7).

Dis, load(pics/dispene, bmp), dispene, addframe (dis).

Dis2.load(pics/dispene2.bmp), dispene, addframe (dis2).

Fnave, load(pics/minave, bmp), nave, addframe (fnave).

Fmalo1_1.load(pics/enemy1_1.bmp), malo1.addframe (fmalo1_1).

Fmalo1_2.load(pics/enemy1_2.bmp), malo1.addframe (fmalo1_2).

Fmalo1_3.load(pics/enemy1_3.bmp), malo1.addframe (fmalo1_3).

Fmalo1_4.load(pics/enemy1_4.bmp), malo1.addframe (fmalo1_4).

Fmalo1_5.load(pics/enemy1_5.bmp), malo1.addframe (fmalo1_5).

Fmalo2.load(pics/nave2.bmp), malo2.addframe (fmalo2).

Fmalo3.load(pics/gordo, bmp), malo3.addframe (fmalo3).

Bala, load(pics/balas, bmp), mibala, addframe (bala).

Vida, load(pics/life, bmp), life, addframe (vida).

Return 0.
}.

Void resettimebase () {.

Ini_milisegundos=sdl_getticks(), }.

Int currenttime () {.

Fin_milisegundos=sdl_getticks(), return fin_milisegundosini_milisegundos; }.

Int main(int argc, char *argv) {.

Sdl_event event, uint8 *keys, int salir=0.

If (sdl_init(sdl_init_video|sdl_init_audio|sdl_init_j oystick) < 0) { printf(no se pudo iniciar SDL: %s\n,sdl_geterror()), return 1.
}.

Scren = sdl_setvideomode (640,480,24,sdl_hwsurface|sdl_doublebuf|sdl_fullsc ren).

If (screen == null) { printf(no se puede inicializar el modo gráfico: \n,sdl_geterror()), return 1.
}.

Atexit(sdl_quit).

If (mix_openaudio (mix_default_frequency,mix_default_format,1,4096) < 0) { printf(no se pudo iniciar sdl_mixer: %s\n,mix_geterror()), return 1.
}.

Atexit(mix_closeaudio).

If (tf_init() < 0) { printf(no se pudo iniciar sdl_ttf: %s\n,sdl_geterror()), return 1.
}.

Atexit(tf_quit).

Inicializa ().

Initsprites().
While (done == 0) {.

Switch (estado) {.

Case 0:
Initestados(), pantalla, setx(0), pantalla, sety(0), pantalla, draw(screen).

Sdl_flip(screen).
// desactivamos la música (si estaba activada) mix_haltmusic().
While (estado==0 && done==0) {.
While (sdl_pollevent(&event)) {.

If (event, type == sdl_quit) {done=1;}.

If (event, type == sdl_keydown || event, type == sdl_joybutondown) {.

If (event.key.keysym, sym == sdlk_escape) { done=1.
} else { score=0, estado=1, loadlevel(1).
// activamos la música.

Mix_playmusic(música,1).
}.
}.
} }.

Break.

Case 1:
// inicializamos el timer para control de tiempo. Resettimebase ().

Ciclos++.
// cada 20 ciclos se crea un enemigo if ((.(ciclos % 20)) && conjefe==0) { creaenemigo (), }.
// ¿final de fase?
If (ciclos>=5000 && conjefe==0) { // creamos la nave jefe, creajefe (), conjefe=1.
}.
// tiempo desde que se destruye al jefe // hasta que cambiamos de nivel, if ((conjefe == 2) && (leveltime<= 0)) {.

If (level>2) level=1.

Loadlevel(level), }.

Muevenaves(), drawscene (screen).
// ¿vida extra?
If (score % 2000 == 0 && score > 0) { score+=10, jugador, vidas++.
}.
// consultamos el estado del teclado keys=sdl_getkeystate (null).
// consultamos el estado del joystick sdl_joystickupdate ().

Joyx = sdl_joystickgetaxis(joystick, 0), joyy = sdl_joystickgetaxis(joystick, 1).

If ((keys[sdlk_up] || joyy < 10) && (jugador, y > 0)) {jugador, y=jugador, y(5),} if ((keys[sdlk_down] || joyy > 10) && (jugador, y < 460)).
{jugador, y=jugador, y+(5),} if ((keys[sdlk_left] || joyx < 10) && (jugador.x > 0)) {jugador.x=jugador.x(5),} if ((keys[sdlk_right] || joyx > 10) && (jugador.x < 620)).
{jugador.x=jugador.x+(5),} if (keys[sdlk_lshift] && jugador, activo.=0) {creadisparo (),}.
While (sdl_pollevent(&event)) {.
// evento del botón del joystick if (event, type ==sdl_joybutondown && jugador, activo.= 0) { creadisparo (), }.
// evento de cierre del programa if (event, type == sdl_quit) {done=0;}.
// evento pulsación de tecla if (event, type == sdl_keydown) {.

If (event.key.keysym, sym == sdlk_escape) {estado=0;}.
}.
}.
// esperamos a que transcurran al menos 30 ms para // generar el siguiente frame, y evitar así // que el juego se acelere en máquinas muy rápidas.

Do { frametime=currenttime (), } while (frametime<30).

Break; } }.

Finaliza ().

Return 0; }.
¿y ahora que?

Ahora te queda la mayoría del camino por recorrer. Si este libro cumple bien el objetivo con el que fue escrito, espero haberte hecho dar los primeros pasos en la dirección correcta. Me voy a permitir un último consejo: haz tu propio juego. No es necesario que sea muy complejo, lo realmente importante es que lo termines. Y recuerda que la mejor forma de aprender a programar es ¡programando. Tampoco te hará mal leer código ajeno. Explora todo el código que puedas. Hay montones de juegos de código abierto.

Vivimos unos buenos tiempos para los que tenemos curiosidad y ganas de aprender. Internet nos ofrece acceso a gran cantidad de información que está disponible a un click de distancia. El apéndice c puedes encontrar numerosos recursos sobre programación de videojuegos. También hay muy buenos libros en el mercado, quien sabe, puede que nos encontremos de nuevo en una segunda parte de este libro. Según te vayas introduciendo en este mundo descubrirás que cada vez te falta más y más por aprender. No te desanimes. La programación de juegos esta compuesta por muy diferentes aspectos, como la IA, gráficos 3d, programación de audio, y no puedes ser un experto en todos.

Quizás el siguiente paso sea entrar en el mundo de las tres dimensiones y SDL ofrece un buen soporte para OpenGL. Todo lo aprendido en este libro es la base y es aplicable en los juegos 3d, aunque, por supuesto, tendrás que seguir aprendiendo y recorriendo el camino antes de crear tu primer juego en tres dimensiones. No utilices atajos, es peor, créeme.

Cuando lleves algún tiempo en esto, es probable que quieras dedicarte profesionalmente a la creación de los videojuegos. Aquí los currículums valen de poco, al menos, si estas intentando meter la cabeza en el mundillo. Tu carta de presentación será tu trabajo, así que, prepara algunas demos de tus juegos y prepárate a mandarlas a todas las compañías que puedas encontrar. Te advierto que, o lo haces por vocación, o lo pasaras mal. Crear un juego comercial es como una Carrera de fondo, tienes que disfrutar realmente con lo que haces. Piensa que un juego comercial medio puede llevar un año de trabajo para su finalización, pero si es lo que quieres, hazlo y no te dejes influir por lo que nadie te cuente.

Dice Oscar wilde en el retrato de Dorian Gray:
porque influir en una persona es darle la propia alma. Esa persona deja de pensar sus propias ideas y de arder con sus pasiones. Sus virtudes dejan de ser reales. Sus pecados, si es que los pecados existen, son prestados. Se humilde en el eco de la música de otro, en un actor que interpreta un papel que no se ha escrito para él. La finalidad de la vida es el propio desarrollo. Alcanzar la plenitud de la manera más perfecta posible, para eso estamos aquí.

Arde con tus propias pasiones y.

Disfruta.

Esta obra esta bajo una licencia attribution-noncommercial-noderivs 2.5 de Creative Commons. Para ver una copia de esta licencia, visite http://creativecommons.org/licenses/by-nc-nd/2.5/ o envíe una carta a Creative Commons, 559 Nathan Abbott way, stanford, california 94305, usa.

Por: Alberto García serrano.

[3dpoder]

.




Instalación de SDL


La dirección web oficial del proyecto SDL es http://www.libsdl.org allí podrás encontrar gran cantidad de información, documentación y aplicaciones desarrolladas con SDL. Las direcciones directas para descargar SDL y sus librerías auxiliares son:
Librería SDL http://www.libsdl.org/download1.2.php sdl_mixer http://www.libsdl.org/projects/sdl_mixer/ sdl_ttf http://www.libsdl.org/projects/sdl_ttf/ sdl_image http://www.libsdl.org/projects/sdl_image/.

En este apéndice vamos a ver cómo utilizar estas librerías tanto en Windows (con VC++) como en Linux (con GC).

Windows (vc++).

Lo primero que necesitamos es tener instalado el compilador de c. Supondré que utilizas visual C++ 6.0, ya que es el más extendido y utilizado en entornos Windows. Si tienes otro compilador, los pasos a realizar serán similares, aunque ya dependerá de cada caso. Lo mejor es consultar la documentación de tu compilador.

El primer paso es descargar las librerías necesarias. Asegúrate que sean las development libraries. Si utilizas VC++ existe una versión especial de las librerías, por ejemplo, el archivo que debes descargar para VC es sdldevel1.2.6vc6.zip. Una vez descargado lo descomprimes en el directorio raíz. Ahora debes tener un directorio llamado \sdl1.2.6\. En lugar de 1.2.6, podrían ser otros valores dependiendo de la versión de la librería.

Arranca VC++ y selecciona la opción new, del menú file. Podrás ver la ventana de nuevo proyecto. En la pestaña Project selecciona Windows 32 application, escribe el nombre del proyecto en el cuadro de texto Project name, y selecciona el directorio donde quieres almacenarlo en location. Seguidamente pulsa el botón ok. En la siguiente ventana nos pregunta qué tipo de aplicación queremos crear. Seleccionamos un proyecto vacío (an Empty Project) y pulsamos el botón finish. Ya tenemos nuestro proyecto creado. Ahora vamos a configurar el proyecto para poder utilizar las librerías de SDL.



Ventana de nuevo proyecto en VC++.

selecciona la opción settings, del menú Project. Veras como aparece una ventana de configuración. Selecciona la pestaña c/C++, aparecerá un campo desplegable llamado category. Selecciona code generation en este desplegable. En el desplegable llamado use runtime library, selecciona multithreaded dll.



Ventana de configuración c/C++>code generation.

El siguiente paso es seleccionar la opción preprocessor en el desplegable category. En el campo additional include directories, incluimos la ubicación del directorio include que hay dentro del directorio de SDL. En este caso es c:\sdl1.2.6\include.



Ventana de configuración c/C++>reprocessor.

Ahora vamos a configurar el enlazador (linker) del compilador para que pueda enlazar las librerías. Pulsamos la pestaña enlace, y seleccionamos input. El cuadro de texto object/library modules añadimos sdlmain, lib y SDL, lib. En caso de que queramos utilizar otras librerías, como, por ejemplo, sdl_mixer, hemos de añadirlas también aquí. En el campo aditional library Path, vamos a añadir la ubicación de las librerías. En este caso c:\sdl1.2.6\lib. Una vez hecho esto, pulsamos el botón ok y ya tenemos todo listo.



Ventana de configuración enlace>input.

Vamos a añadir código a nuestro proyecto. Selecciona la opción new, del menú file. Veremos una ventana que nos permite seleccionar el tipo de archivo. Asegúrate que está seleccionada la pestaña file. En la ventana selecciona C++ source file. En el campo file name, introduce el nombre del archivo. En este caso lo llamaremos main, c. Seguidamente pulsamos ok.



Nuevo archivo.

Ahora tendremos una ventana de edición lista para empezar a teclear. Introduce el siguiente código que utilizaremos para probar la librería.
#include <stdio, h> #include <stdlib, h> #include <sdl.h>.

Int main(int argc, char *argv) {.

Sdl_surface *screen.

Sdl_event event.

Int done = 0.

Atexit(sdl_quit).
// iniciar SDL.

If (sdl_init(sdl_init_video) < 0) {.

Printf(no se pudo iniciar SDL: %s\n,sdl_geterror()).

Exit(1).
}.
// activamos modo de video.

Scren = sdl_setvideomode (640,480,24,sdl_hwsurface).

If (screen == null) {.

Printf(no se puede inicializar el modo gráfico: \n,sdl_geterror()), exit(1), }.
// esperamos la pulsación de una tecla para salir while (done == 0) { while (sdl_pollevent(&event)) { if (event, type == sdl_keydown) done = 1; }.
}.

Return 0; }.

Una vez introducido el código, pulsamos f7 para compilar el programa. Si todo va bien, VC++ nos informara que no ha habido ningún error. Si no es así repasa el código.

Como por defecto VC++ está en modo debug, el compilador nos habrá creado un directorio llamado debug en el directorio donde se encuentra el proyecto. Dentro de este directorio encontramos un ejecutable. Éste es nuestro programa ya compilado, sólo nos resta un paso. Para que los programas que utilizan SDL funcionen, hemos de copiar el archivo SDL.dll en el mismo directorio donde se encuentre el programa ejecutable (o añadirlo al directorio \Windows\system32). Ya está listo para su ejecución pulsando doble click sobre él. Si todo ha ido bien, veras una ventana en negro. Pulsa cualquier tecla para cerrar el programa.

Observa que si actualizas la versión de SDL, o intentas cargar un proyecto que utilice otra versión distinta a la que tienes instalada, tendrás que actualizar la ubicación de las cabeceras y las librerías en el proyecto. Por ejemplo, si antes tenías tus cabeceras en c:\sdl1.2.4\include y te actualizas a la versión 1.2.6 de SDL, tendrás que cambiar la ubicación en la configuración a c:\sdl1.2.6\include.

La instalación de las librerías auxiliares es muy sencilla. Descarga la versión especifica para VC++, y copia los archivos de cabecera (*.h) al directorio include de SDL (c:\sdl1.2.6\include) y las librerías (*.lib) al directorio lib de SDL (c:\sdl1.2.6\lib). Asegúrate de copiar el archivo dll de la librería (por ejemplo, sdl_mixer, dll) en el directorio donde se encuentre el archivo ejecutable.

Linux.

Tal y como hicimos con Windows, lo primero que tenemos que hacer es localizar el paquete que nos conviene descargar. Si tu distribución Linux esta basada en Red Hat o trabaja con paquetes en formato rpm, tendrás que bajarte los paquetes que finalizan con la extensión.rpm. La instalación de un paquete rpm se hace de la siguiente manera (siempre como usuario root).

Rpm -ivh nombre_paquete.

Por ejemplo, si el paquete que has descargado es sdl1.2.61.i386.rpm, la línea que realiza la instalación es:
Rpm -ivh sdl1.2.61.i386.rpm.

Si tu distribución esta basada en debían, podrás utilizar la utilidad apt para descargar e instalar SDL. La siguiente línea descarga e instala SDL.

Aptget install libsdl1.2dev.

Esta línea podría variar dependiendo de la última versión de SDL disponible. Es conveniente ejecutar la línea siguiente antes para asegurarte que descargas la última versión.

Aptget update.

Seguidamente, para conocer que versiones y que librerías para SDL hay disponibles utiliza la siguiente línea.

Aptcache search SDL.

Una vez instalado SDL, las librerías deberían estar instaladas en el directorio /usr/lib, y los archivos de cabecera en /usr/include/sdl.

No vamos a entrar en detalle en el funcionamiento del compilador GC, simplemente te mostraré las líneas necesarias para realizar la compilación.

Para realizar una compilación utilizando librerías dinámicas, compila el programa de la siguiente forma.

Gcc l/usr/lib lsdl lpthread i/usr/include/sdl d_rentrant main, cpp csprite, cpp o ejemplo6_1.

El modificador -l permite indicar la ubicación de las librerías, y el modificador -i indica la ubicación de los archivos de cabecera. El modificador -l, nos permite indicar al compilador que librerías queremos enlazar con nuestro programa. Si quisiéramos enlazar la librería principal de SDL y también sdl_mixer utilizaríamos -lsdl -lsdl_mixer. Por último, indica los archivos fuente que quieres compilar (main, cpp y csprite, cpp) y el nombre del archivo ejecutable que quieres generar después del modificador -o. Si no entiendes el resto de modificadores no te preocupes, déjalos tal cual, ya que si no, no funcionara el archivo ejecutable. Para realizar una compilación enlazando las librerías estáticas, hazlo de la siguiente forma.

Gcc l/usr/lib lsdl lpthread lm l/usr/x11r6/lib lx11 lxext ldl i/usr/include/sdl d_rentrant main, cpp csprite, cpp o ejemplo6_1.

Para ejecutar el programa ya compilado usamos.
/ejemplo6_1.



De c a C++


Que tengas este libro entre tus manos, significa que tienes unos conocimientos mínimamente razonables de programación. Probablemente estarás familiarizado con el lenguaje c. En el presente capítulo voy a tratar de hacer una introducción a la programación orientada a objetos en C++. Evidentemente, para hacer una buena introducción necesitaríamos todo un libro. En la bibliografía hay algunos muy buenos que te servirán para profundizar. El objetivo, pues, de este apéndice es acercar la PO en C++ a los programadores conocimientos previos de c. Nos centraremos en los aspectos más relevantes y, desgraciadamente, por la extensión limitada de la presente obra, dejaremos de lado las características más complejas o menos útiles de este lenguaje. Ni que decir tiene que si ya eres un experto en C++, puede prescindir alegremente este apéndice.

Puede que en estos momentos te estés preguntando si es realmente necesario utilizar C++ y si c no es suficiente. Rotundamente sí. Puedes acometer el desarrollo de juegos razonablemente complejos en c, sin embargo, la PO nos aporta ciertamente una serie de ventajas que hemos de tener muy en cuenta a la hora de sentarnos a programar, como:
* una mayor abstracción de datos.
* más facilidad para la reutilización de código.
* mantenimiento y extensión de las aplicaciones más fácil.
* mayor potencia (herencia y polimorfismo).
* modelado de problemas reales de forma más directa.

Quizás todo esto te suene un poco ajeno a la forma a la que estas acostumbrado a programar, e incluso puede que ni te suenen algunos de estos conceptos, pero al finalizar el capítulo, deberán serte familiares.

Todo esto suena bien, pero ¿Qué es un objeto? Trataré, sin entrar en demasiados formalismos, explicarlo de la forma más intuitiva posible. Si te pido que pienses en un objeto, seguramente pensaras en un lápiz, una mesa, unas gafas de sol, un coche o cualquier otra cosa que caiga dentro de tu radio de visión. Esta es la idea intuitiva de objeto. Algo físico y material. En PO, el concepto de objeto no es muy diferente. Una de las diferencias básicas evidentes es que un objeto en C++ puede hacer referencia a algo abstracto.

Como en el ejemplo del coche, un objeto puede estar compuesto por otra clase de objetos, como ruedas, carrocería, etc. Este concepto de clase de objeto es importante. Un objeto siempre pertenece a una clase de objetos. Por ejemplo, todas las ruedas, con independencia de su tamaño, pertenecen a la clase rueda. Hay muchos objetos rueda diferente que pertenecen a la clase rueda. Cada una de estas ruedas diferentes se llaman instancias de la clase rueda. Tenemos, pues, instancias de la clase rueda que son ruedas de camión, ruedas de coches o ruedas de moto.

Volvamos al ejemplo del coche. Vamos a definir otra clase de objeto, la clase coche. La clase coche define a algo que está compuesto por objetos (instancias) de la clase rueda, la clase carrocería, la clase volante, etc. Ahora vamos a crear un objeto de la clase coche, al que llamaremos coche_rojo. En este caso hemos instanciado un objeto de la clase coche y hemos definido uno de sus atributos, el color, al que hemos dado el valor de rojo. Vemos pues que un objeto puede Poser atributos. Sobre el objeto coche podemos definir también acciones u operación posibles. Por ejemplo, el objeto coche, entre otras cosas, puede realizar las operación de acelerar, frenar, girar a la izquierda, etc. Estas operación que pueden ser ejecutadas sobre un objeto se llaman métodos del objeto.

Podemos hacer ya una primera definición de lo que es un objeto. Es la instancia de una clase de objeto concreta, que está compuesta por atributos y métodos. Esta definición nos muestra ya una de las tres principales características que definen a la PO. Me refiero al encapsulamiento, que no es, ni más ni menos, que la capacidad que tiene un objeto de contener datos (atributos) y código (métodos).

Clases y objetos.

Veamos en la práctica cómo se declara una clase y se instancia un objeto en C++. Podríamos afirmar que, en C++, una clase es algo muy similar a una estructura de c en la que además de almacenar datos, podemos añadir las funciones (métodos) que harán uso de estos datos. Siguiendo con el ejemplo anterior, vamos a declarar la clase coche.
// declaración de la clase coche.

Class coche {.
// atributos de la clase coche.

Int velocidad.
// métodos de la clase coche.

Void acelerar(int velocidad).

Void frenar(), }.

En este ejemplo hemos declarado la clase coche. Lo primero que puede chocar al programador de c es la forma de incluir comentarios en el código. C++ permite seguir usando comentarios al estilo de c, pero también añade una nueva forma de hacerlo mediante las dos barras //. C++ interpreta que lo que sigue a las dos barras y hasta el final de la línea es un comentario.

La declaración de la clase coche muestra claramente dos partes diferenciadas. Por un lado, tenemos la declaración de los atributos de la clase (también llamados datos miembro de la clase), que en este caso describe la velocidad del coche. Podemos decir que las variables miembro de una clase definen el estado del objeto (en este caso el estado del coche esta formado exclusivamente por su velocidad). Ni que decir tiene que esto es un ejemplo muy simplificado y que una clase que tratara de describir el comportamiento de un coche sería mucho más compleja. La segunda parte de la declaración contiene los métodos (funciones) que nos van a permitir realizar operación o acciones sobre el objeto. En el caso de la clase coche hemos definido un método acelerar() que nos va a permitir acelerar el coche hasta una determinada velocidad. El método frenar() va a hacer que la velocidad sea 0, es decir, que el coche se pare. Esta es la forma en que se implementa un método en C++. Las siguientes líneas implementan el método frenar() y acelerar().

Void coche:frenar() {.
// ponemos a 0 el valor del atributo velocidad.

Velocidad = 0; }.

Void coche:acelerar(int velocidad) {.
// actualizamos la velocidad.

This, velocidad = velocidad; }.

Se puede observar que declarar un método es muy similar a declarar una función en c, salvo que es necesario indicar a que clase corresponde el método. Esto se hace añadiendo el nombre de la clase seguido de dobles dos puntos antes del nombre del método. En el método acelerar, puedes observar que en vez de nombrar directamente a la variable velocidad, hemos utilizado this, velocidad. El motivo, como seguramente estarás suponiendo, es que la variable que hemos pasado como parámetro al método se llama igual que la variable miembro de la clase. Con this, velocidad informamos a C++ de que nos referimos a la variable miembro, en caso contrario interpretara que nos referimos a la variable recibida como parámetro.

Ya sabemos cómo declarar una clase y como implementarla. Nos resta conocer cómo utilizarla. No podemos utilizar una clase directamente. Una clase es como un patrón a partir del cual se crean (instancian) objetos deribados de ella. La forma de crear un objeto coche es declarando el objeto, tal y como haríamos con una variable.

Coche micoche.

Ahora sí tenemos un objeto llamado micoche, que es una instancia de la clase coche y que podemos empezar a utilizar.

Para hacer uso de un método del objeto micoche, procedemos de la siguiente forma.
// primero aceleramos hasta 100 km/h micoche, acelerar(100).
// y después frenamos micoche, frenar().

Como ves, el acceso a un método es simple, sólo hay que anteponer el nombre del objeto al que nos referimos seguido de un punto y el nombre del método. De la misma forma podemos acceder directamente a los atributos o variables miembro del objeto.
// establecemos la velocidad directamente micoche, velocidad = 100.

Tengo que decir que ésta no es la manera más conveniente de proceder. La mejor decisión de diseño de clases es esconder las variables miembro para que no sean visibles desde fuera de la clase, y ofrecer los métodos necesarios para manejarlas. Así, siempre podemos filtrar desde los métodos los valores que toman los atributos. No queremos que nadie haga algo como micoche, velocidad = 1000. No sería nada bueno para el coche. Para especificar quién tiene acceso y quién no a las variables miembro y a los métodos utilizamos los modificadores de acceso. Hay tres modificadores:
Public. Permite el acceso sin restricciones.

Private. Sólo se permite el acceso desde dentro de la clase.

Protected. Permite sólo el acceso desde dentro de la clase o desde una.

Subclase. Un poco más abajo veremos lo que es una subclase, pero antes veamos un ejemplo de uso de los modificadores.
// declaración de la clase coche class coche {.
// atributos de la clase coche.

Private:
Int velocidad.
// métodos de la clase coche.

Public:
Void acelerar(int velocidad).

Void frenar(), }.

Al declarar la clase de esta forma, el atributo velocidad no es accesible desde fuera de la clase, es decir, no podríamos hacer algo como micoche, velocidad=100. La única forma de escribir en la variable coche es hacerlo mediante los métodos acelerar() y frenar().

Al instanciar un objeto, nunca podemos estar seguro de cual es su estado (el valor de sus atributos). Necesitamos un mecanismo que nos permita inicializar un objeto con los valores deseados. Esto podemos hacerlo mediante el uso de constructores. Un constructor es un método especial de la clase que se ejecuta de forma automática al instanciar la clase. Veamos sobre un ejemplo.
// declaración de la clase coche.

Class coche {.
// atributos de la clase coche.

Private:
Int velocidad.
// métodos de la clase coche.

Public:
Coche ().

Void acelerar(int velocidad).

Void frenar(), }.

Coche:coche () {.
// inicializamos la velocidad a 0.

Velocidad = 0; }.

Observa que el constructor tiene exactamente el mismo nombre que la clase (incluida la primera letra mayúscula). Otra cosa a tener en cuenta es que un constructor no devuelve ningún valor, ni siquiera Void. Cuando instanciemos un objeto de la clase coche, se ejecutara el código del constructor de forma automática, sin necesidad de invocar el método constructor. En este caso, inicia la variable velocidad a 0.

Al igual que una clase puede tener un constructor (en realidad puede tener más de uno, pero no adelantemos acontecimientos), también puede tener un destructor (en el caso del destructor sólo uno). En el destructor podemos añadir código que será ejecutado justo antes de que el objeto sea destruido de forma automática (sin necesidad de invocarlo), por ejemplo, por una salida fortuita del programa. Un destructor se declara igual que un constructor, pero anteponiendo el símbolo de tilde delante (~).
// destructor de la clase coche coche:~coche () { if (velocidad.= 0) velocidad = 0; }.

Este destructor se asegura de que si el coche está en movimiento, su velocidad se reduzca a 0.

Herencia.

No sé de color tienes los ojos, pero puedo asegurar que del mismo color que alguno de tus ascendentes. Este mecanismo biológico fue descrito por mendel (armado con una buena dosis de paciencia y una gran cantidad de guisantes) y se llama herencia. La herencia se transmite de padres a hijos, nunca al revés. En PO, la herencia funciona igual, es decir, en un sólo sentido. Mediante la herencia, una clase hija (llamada subclase) hereda los atributos y los métodos de su clase padre. Vamos a verlo mejor con un ejemplo. Imaginemos que queremos crear una clase llamada cochepolicia, que además de acelerar y frenar pueda activar y desactivar una sirena. Podríamos crear una clase nueva llamada cochepolicia con los atributos y clases necesarios tanto para frenar y acelerar como para activar y desactivar la sirena. En lugar de eso, vamos a aprovechar que ya tenemos una clase llamada coche y que ya contiene algunas de las funcionalidades que queremos incluir en cochepolicia. Veamos sobre un ejemplo.

Class cochepolicia:public coche {.

Private: int sirena.

Public:
Sirenaon() { sirena=1; }.

Sirenaof() { sirena=0; } }.

Observa cómo hemos implementado los métodos sirenaon() y sirenaof() dentro de la misma clase. Esto es completamente valido, y se suele utilizar cuando el código del método es pequeño, como en este caso. Lo primero que nos llama la atención de la declaración de la clase es su primera línea. Tras el nombre de la clase, hemos añadido dos puntos seguidos de la clase padre, es decir, de la que heredamos los métodos y atributos. El modificador public hace que los métodos y atributos heredados mantengan sus modificadores de acceso originales. Si queremos que se hereden como protegidos, utilizaremos el modificador protected. Ahora la clase cochepolicia postura dos atributos, velocidad, que ha sido heredado y sirena, que ha sido declarado dentro de la clase cochepolicia. Con los métodos sucede exactamente igual. La clase hija ha heredado acelerar() y frenar() y, además le hemos añadido los métodos sirenaon() y sirenaof(). Un objeto instancia de cochepolicia pude utilizar sin ningún problema los métodos acelerar() y frenar() tal y como hacíamos con los objetos instanciados de la clase coche.

Es posible heredar de dos o más clases a la vez. Esto se llama herencia múltiple. Para heredar de más de una clase, las enumeramos separadas por comas detrás de los dos puntos. Sinceramente, a no ser que te guste el riesgo, la herencia múltiple, si no se tiene cuidado, te traerá más dolores de cabeza que otra cosa.

Polimorfismo.

El polimorfismo es otra de las grandes característica de la PO. La palabra polimorfismo deriva de poli (múltiples) y del término griego morfos (forma). Es decir, múltiples formas.

Vamos a verlo con un ejemplo. Supongamos que queremos dotar al método frenar de más funcionalidad. Queremos que nos permita reducir hasta la velocidad que queramos. Para ello le pasaremos como parámetro la velocidad, pero también sería útil que frenara completamente si no le pasamos ningún parámetro. El siguiente código cumple estos requisitos.
// declaración de la clase coche.

Class coche { // atributos de la clase coche int velocidad.
// métodos de la clase coche Void acelerar(int velocidad), Void frenar(), Void frenar(int velocidad).
}.

Void coche:frenar() { // ponemos a 0 el valor del atributo velocidad velocidad = 0.
}.

Void coche:frenar() { // ponemos a 0 el valor del atributo velocidad velocidad = 0.
}.

Void coche:frenar(int velocidad) { // reducimos la velocidad if (velocidad < this, velocidad).

This, velocidad = velocidad; }.

Como ves tenemos dos métodos frenar. En c, esto causaría un error. Cuando llamemos al método frenar(), C++ sabrá cual tiene que ejecutar dependiendo de si lo llamamos con un parámetro de tipo entero o sin parámetros. Esto que hemos hecho se llama sobrecarga de métodos. Podemos crear tantas versiones diferentes del método siempre y cuando sean diferentes.

El constructor de una clase también puede ser sobrecargado.

Punteros y memoria.

C++ añade un nuevo operador para reservar memoria y crear punteros. Se trata del operador new. Este operado reserva la memoria para contener un tipo de datos determinado, y devuelve y puntero a la memoria reservada.
// creamos un puntero de tipo coche // ojo, no creamos un objeto coche, sólo un puntero coche *micoche.
// creamos un objeto coche y devolvemos // un puntero al objeto micoche = new coche.
// llamada a un método del objeto micoche>acelera (100), // liberar memoria deleete coche.

Lo primero que hemos hecho es declara un puntero de tipo coche. En este momento no hemos creado ningún objeto, sino un puntero. El encargado de crear el objeto es el operador new, que además de crear la instancia devuelve un puntero al objeto recién creado.

La siguiente línea llama al método acelera (), pero observa que en vez de un punto usamos los caracteres > (signo de resta seguido del signo mayor que). Siempre que trabajamos con un puntero a un objeto sustituimos el punto por >.

Por último, para liberar los recursos reservados por new, utilizamos el operador deleete, que va a liberar la memoria ocupada por el objeto coche.

Hemos visto en éste apéndice las características más importantes de C++ relacionadas con la PO, sin embargo, este lenguaje es mucho más extenso y no podemos hacer una completa introducción por problemas de espacio. Si has sido capaz de asimilar la información de este apéndice me doy por contento por ahora, aunque mi consejo es que, sigas profundizando en este lenguaje.



Recursos

bibliografía
programación.

Programación orientada a objetos con C++. 2ª edición. Fco. Javier ceballos ed. Rama. ISBN: 8478972684.

Programación en c. Mitchell waite/Stephen prata ed. Anaya. ISBN: 8476143745.

Programación en Linux con ejemplos. Kurt wall ed. Prentice hall. ISBN: 987946009x.

Visual C++ 6 Jon bates/tim tomkins ed. Prentice hall. ISBN: 8483220776.

Programación de videojuegos.
Windows game programming for dummies, second edition. André lamothe. Ed. Idg books. ISBN: 0764516787.

OpenGl game programming. Dave astle/Kevin Hawkings/André Lamothe. Ed. Learning express ISBN: 0761533303.

Ai techniques for game programming.

Mat buckland. Ed. Learning express ISBN: 193184108x.

Beginning Direct3D game programming, 2nd edition. Wolfgang f. Engel. Ed. Learning express ISBN: 193184139x.

Gráficos.

Computer graphics, principales and practice. Foley/van dam/feiner/hughes ed. Addison Wesley ISBN: 0201121107.

OpenGl(r) programming guide: the oficial guide todo learning OpenGL, versión 1.2 (3rd edition). Mason wo y otros ed. Addisonwesley ISBN: 0201604582.

OpenGl superbible, second edition (2nd edition). Richard s. Wright jr./Michael r. Swet. Ed. Waite group press ISBN: 1571691642.

Programación multimedia avanzada con DirectX Constantino Sánchez ballesteros ed. Rama ISBN: 8478973427.

Enlaces.

Programación. http://www.dcp.com.ar/. http://www.programación.net/. http://www.planetiso.com/. http://www.mindview.net/books/ticp/thinkingincp2e.html

Programación de videojuegos. http://www.flipcode.com/. http://www.gamedev.net/ http://www.Gamasutra.com/ http://gpp, netfirms.com/ http://www.gametutorials.com/ http://wwwcsstudents, stanford.edu/~amitp/gameprog.html
Gráficos. http://nehe, gamedev.net/ http://www.OpenGl.org/ http://www.shaderx.com/Direct3D.net/index.html http://www.geocities.com/siliconvall...390/index.html.

índice alfabético

A.

Algoritmos de búsqueda, 106 alphablending, 32 atexit, 25 audio, 51.

B.

Bit blitting, 27.

C.

C++, 143 cdrom, 56.

Ch.

Chunk, 70.

C.

Clases, 144 códigos sym, 40 colisiones, 81.

Deleete, 54, 149 disparos, 108.

E.

Enemigos, 117 event, 40 explosiones, 108.

G.

Game loop, 10 gestión de eventos, 38.

H.

Herencia, 147.

I.

Img_load, 66 inteligencia artificial, 105.

L.

Linux, 141.

M.

Mapas, 98 mappy, 98 máquinas de estado, 107 mix_allocatechannels, 70 mix_closeaudio, 69 mix_fadeinchannel, 71 mix_fadeinchanneltimed, 71 mix_fadeinmusic, 73 mix_fadeoutchannel, 71 mix_fadeoutmusic, 73 mix_frechunk, 70 mix_fremusic, 73 mix_getmusictype, 74 mix_haltchannel, 71 mix_haltmusic, 73 mix_loadmus, 73 mix_loadwav, 70 mix_openaudio, 69 mix_pause, 71 mix_paused, 71 mix_pausedmusic, 74 mix_pausemusic, 73 mix_playchannel, 70 mix_playchanneltimed, 70 mix_playing, 71 mix_playingmusic, 74 mix_playmusic, 73 mix_resume, 71 mix_resumemusic, 73 mix_rewindmusic, 73 mix_setmusicposition, 73 mix_volumechunk, 70 mix_volumemusic, 73.

N.

New, 148 niveles, 119.

O.

Objetos, 144.

P.

Pantalla inicial, 121 polimorfismo, 147 puntuación, 121 punteros, 148.

R.

Ratón, 39 red neuronal, 105.

S.

Scrolling, 100 SDL, 23 sdl_activeevent, 46 sdl_audiospec, 51 sdl_blitsurface, 30 sdl_buton, 44 sdl_cd, 56 sdl_cdclose, 57 sdl_cdeject, 57 sdl_cdname, 56 sdl_cdnumdrives, 56 sdl_cdopen, 57 sdl_cdpause, 57 sdl_cdplay, 57 sdl_cdplaytracks, 57 sdl_cdresume, 57 sdl_cdstatus, 57 sdl_cdstop, 57 sdl_cdtrack, 56 sdl_closeaudio, 52 sdl_convertsurface, 37 sdl_creatergbsurface, 27 sdl_delay, 61 sdl_enableunicode, 43 sdl_exposeevent, 46 sdl_fillrect, 31 sdl_flip, 31 sdl_fresurface, 31 sdl_frewav, 52 sdl_getcliprect, 37 sdl_geterror, 25 sdl_getkeystate, 43 sdl_getticks, 60 sdl_getvideoinfo, 38 sdl_image, 66 sdl_init, 24 sdl_initsubsystem, 25 sdl_joyaxisevent, 45 sdl_joybuttonevent, 45 sdl_joystickclose, 47 sdl_joystickeventstate, 45 sdl_joystickgetaxis, 48 sdl_joystickgetbutton, 48 sdl_joystickname, 47 sdl_joysticknumaxes, 48 sdl_joysticknumbuttons, 48 sdl_joystickopen, 47 sdl_joystickopened, 48 sdl_joystickupdate, 48 sdl_keyboardevent, 40 sdl_keysym, 40 sdl_loadbmp, 30 sdl_loadwav, 52 sdl_maprgb, 31, 33 sdl_mixer, 69 sdl_mousebuttonevent, 44 sdl_mousemotionevent, 44 sdl_numjoysticks, 47 sdl_openaudio, 52 sdl_pauseaudio, 52 sdl_pixelformat, 27 sdl_pollevent, 40 sdl_quit, 25 sdl_quitevent, 45 sdl_quitsubsystem, 25 sdl_rect, 30 sdl_resizeevent, 46 sdl_setalpha, 36 sdl_setcliprect, 36 sdl_setcolorkey, 32 sdl_setvideomode, 26 sdl_surface, 30 sdl_ttf, 62 sdl_updaterect, 31 sdl_videoinfo, 38 sdl_wm_getcaption, 60 sdl_wm_iconifywindow, 60 sdl_wm_setcaption, 60 sdl_wm_seticon, 60 sistemas basados en reglas, 106 sprites, 76.

T.

Teclado, 39 temporización, 120 this, 145 tiles, 93 timming, 60 transparencias, 32 tf_close, 63 tf_font, 63 tf_getfontstyle, 63 tf_init, 62 tf_openfont, 62 tf_openfontindex, 62 tf_quit, 62 tf_rendertext_blended, 63 tf_rendertext_shaded, 63 tf_rendertext_solid, 63 tf_setfontstyle, 63.

V.

Vidas, 121 video, 26 visual C++, 137.
W.
Window manager, 60.

Esta obra esta bajo una licencia attribution-noncommercial-noderivs 2.5 de Creative Commons. Para ver una copia de esta licencia, visite http://creativecommons.org/licenses/by-nc-nd/2.5/ o envíe una carta a Creative Commons, 559 Nathan Abbott way, stanford, california 94305, usa.

Por: Alberto García serrano.