3.1.- Volvemos otra vez.

¿Cómo tamo?

Nosotros bien gracias. Espero que hayáis esperado impacientes esta nueva lección porqué ello significaría que os está gustando la cosa.

Estamos en la tercera lección y si no hay cambios en nuestra planificación, en la mitad del curso. En este instante tenemos el enorme placer de anunciar los primeros artículos colaboración del CPV. Ya os anunciamos en la anterior entrega que había varias personas interesadas en ayudarnos, fruto de estos deseos ya hemos recibido las primeras colaboraciones. X-) 8X-)

Cómo habréis visto en el menú de la lección hemos incluido un artículo sobre las 3-D que seguramente será el primero de varios artículos sobre el tema y que están siendo realizados por Jose Miguel Espadero. Además de esta magnífica colaboración, algunas personas más (cómo Francisco Priego y Cristobal Saraiba) se hicieron eco de nuestra llamada de auxilio de la anterior lección y nos están echando una mano comentando y corrigiendo artículos, realizando gráficos, traduciendo programas y ¡Oh sorpresa! =X-O mandando encuestas.....

Sí, sí por fin hemos recibido encuestas, pocas, pero gratificantes en el apartado de consultas os haremos una síntesis, ¡Joba como suena esto! digamos un resumen de la opinión de la gente sobre el CPV.

En esta lección también hemos decidido la forma de distribución, de momento, la debemos considerar a todos los efectos provisional. Su continuidad o anulación depende completamente de vosotros, de vuestro interés y vuestras colaboraciones. Digamos que con este sistema vamos a poder evaluar si el enorme esfuerzo que estamos realizando los autores ( y más gente que hay por detrás) vale la pena.

Os voy a facilitar en este momento todas las direcciones de los sitios dónde tenemos conocimiento de que el CPV está disponible:

             SAKERY FOX BBS     ---->      Cuartel General

Teléfono  :  (91) 413 98 55     Dispone de un cómodo menú de dónde se
Fidonet   :     2:341/5         pueden conseguir las lecciones, leer las
Sysop     :   Alberto Ruiz      últimas noticias sobre el CPV y poner/dejar
Horario   :    24 Horas         mensajes y ficheros a los autores.
Velocidad :     28.800

                     DECKARD BBS          ALCAZAR BBs
                   (91) 643 10 67       (926) 55 09 03
                      2:341/52             2:341/79
                    Pedro de Paz       Jose Antonio Vico
                      24 Horas             24 Horas
                       28.800               28.800

                           y en INTERNET

   Servidores de FTP

        asterix.upm.fi.es    en el directorio pub/facultad/alumnos/juegos
       dulcinea.alcala.es          >>> dirección a confirmar <<<

Agradeceríamos a todos los Sysops y Roots que tengan o quieran tener las lecciones del CPV se pongan en contacto con los autores, a efectos de poder listar todos los centros de distribución.

        Nuestras direcciones son:

      Jesús Angel Sánchez Mena     Fidonet   ------> 2:341/5.65
      c\ Berlín 1                                            ^^
      28850 Torrejón de Ardoz               ¡Atención. Nueva dirección!
      Madrid
 

      Benjamín Moreno Palacios     Internet  ---> BMORENO@clio.ls.fi.upm.es
      c\ Estocolmo 1                              A910033@zipi.fi.upm.es
      28850 Torrejón de Ardoz
      Madrid
 

Nada más, nos gustaría que leyeseis atentamente el apartado de Distribución y Condiciones antes de que paséis a deglutir esta lección, se que es un plato irresistible pero si os gusta el CPV y queréis que continúe dedicarle unos minutillos. :) 8)


  

3.2.- Distribución y condiciones.

Abónese...

Bueno, ya tenemos decidida la forma de distribución que si tiene buena acogida será la definitiva. Nos gustaría poder definirla con una palabra cómo ShareWare, FreeWare, ComicWare, JokeWare, PostCardWare pero me Cachi-en-Ware, no se ajusta a ninguno de los anteriores. Os expondremos de que va el asunto y cada uno que lo defina como quiera:

- Las lecciones seguirán distribuyéndose completas por distintas BBS así cómo por Internet, únicamente nos reservaremos la entrega de algunos programas fuentes para 'animar' la participación de la gente, no descartando su posterior distribución, pero...

- A pesar de poner las lecciones en libre distribución. Nosotros preferimos que se soliciten las lecciones para ser recibidas por correo previo pago de 500 pesetas (más la voluntad) por lección. Algunos pensaréis que para que vais a pagar por las lecciones si las podéis conseguir "gratis", para los que penséis así os voy a dar unas pocas razones:

1- Muchos de vosotros obtenéis las lecciones bajándolas de alguna BBS, oséa, vía telefónica que como bien sabréis no es ni mucho menos una ganga, veamos, para un tamaño medio de las lecciones de digamos 600 Kb como en esta lección y teniendo en cuenta las distintas velocidades de transmisión y las tarifas telefónicas, el precio puede ir de aproximadente 200 pesetas, en el mejor de los casos a más de 700 para muchas otras combinaciones.

2- Por el módico precio de 100 duros recibiréis cada lección en vuestro buzón, en sobre de seguridad y en un diskette 3 1/2 HD.

3- Como en el disco sobrará espacio, incluiremos en él distintos programas y utilidades de dominio público,( por supuesto no haremos pirateo P-( ) que no tengan explícitamente prohibida esta forma de distribución y que puedan resultar interesantes.

4- Todos nuestros 'subscriptores' tendrán prioridad tanto en el envío de las lecciones cómo en la respuesta a sus consultas.

5- En las lecciones solicitadas por correo incluiremos todos, todos los fuentes de las lecciones, así cómo de los programas auxiliares VCPV (por ejemplo) y de las traducciones que estamos haciendo de los programas Pascal a C.

6- Además, a la gente que nos pida todas las lecciones por correo le enviaremos en la última entrega los fuentes del programa Hormigator (+10000 líneas de código ensamblador y Pascal) y (si las terminamos) unas librerías que estamos desarrollando los autores en C, con todas las funciones incluidas en el CPV y muchas más.

7- Aunque parezca mentira de las 500 pelas que cuesta cada lección, quitando gastos de envío, sobre y diskette, a los autores nos queda una módica cantidad que servirá como donativo pa' la causa. Desde luego no nos vamos a hacer ricos, pero por lo menos servirá para no perder dinero.

Podríamos daros más razones pero si con las anteriores no os vale no os lograríamos convencer ni con una pistola en la sién. ;-)

Como ya adelantamos en la anterior entrega, también se puede conseguir el CPV gracias a las colaboraciones y de hecho varias personas así han conseguido esta lección. En el apartado de Colaboraciones y Consultas más información.

Nada más, todo lo anterior depende de vuestra participación, si optáis por la solución fácil y menos buena para nosotros, el mantenimiento de la forma de distribución e incluso, en el peor de los casos, la existencia del CPV correría peligro, así que ya sabéis...

Para torear, gozar del CPV y casarse hay que mojarse

Que original verdad ;;;-), os facilitamos ahora las distintas formas para hacernos llegar vuestras peticiones:

- Giro Postal a nombre de cualquiera de los autores, indicando en los datos del remitente la dirección para el envío de la lección. Nuestras direcciones las podéis encontrar en la presentación de la lección.

- Mandar una carta de petición a cualquiera de los autores, dónde se indique claramente la dirección para el envío y la fecha y código de identificación de la trasferencia bancaria a alguna de las siguientes cuentas: - Información no incluida en la versión HTML -

Una vez validada la información sobre el ingreso se enviará la lección.

- Si os gusta el riesgo y la aventura podéis optar por mandar dinero en metálico en la carta de petición, pero no nos hacemos responsables de las posibles 'negligencias postales'.

Ya sabéis en cualquiera de las modalidades anteriores el importe mínimo válido es de 500 ptas, transporte, I.V.A., T.A.E., impuesto de matriculación, de lujo, de sociedades, Plan Renove I y II e impuestos de los impuestos incluido. ;-)

Bueno, expondremos ahora las condiciones del CPV, sabemos que son un rollete pero los autores debemos tener algo dónde agarrarnos:

** NECESARIO **   *** NECESARIO ***    *** NECESARIO ****   ** NECESARIO **

- El CPV se entrega 'Tal como está' o lo que es lo mismo con garantía 0.

- Los autores de los tutoriales declinamos toda responsabilidad sobre los problemas que éstos pudieran causar.

- Todas las rutinas que incluimos en los tutoriales han sido previamente ejecutadas en nuestras máquinas sin ningún problema, pero no aseguramos que 'corran' correctamente en otros ordenadores. El usuario se hace totalmente responsable de la ejecución y manipulación de los programas incluidos en las lecciones.

- Todos los artículos, rutinas y programas que aparecen en el tutorial habrán sido realizados por nosotros, salvo aquellos que incluyamos y nombremos cómo colaboraciones externas.

- Las rutinas que incluimos en este tutorial, podéis utilizarlas para vuestros propios programas, si éstos los pensáis distribuir, por favor acordaros de los autores. ;)

- Las lecciones distribuidas por las BBS y por Internet pueden y nos gustaría que fuesen distribuidas libremente.

- Las lecciones solicitadas por correo por petición o cómo gratificación a una colaboración NO DEBEN distribuirse de ninguna manera.

- Los autores del CPV no nos hacemos responsables de negligencias del servicio postal en el envío de las lecciones o los giros postales.

- Si alguna persona opta por enviar dinero en metálico será bajo su propia responsabilidad.

- Todos los artículos publicados en el CPV se atienen a estas condiciones.

** NECESARIO **   *** NECESARIO ***    *** NECESARIO ****   ** NECESARIO **
 

3.3.- Colaboraciones y consultas.

Como ya os adelantamos en la anterior lección, hemos ideado un método para animar la participación de la gente y ofrecer otra alternativa para conseguir las lecciones por correo sin necesidad de 'cotizar'. Así pues:

Entre todas las personas que nos mande cualquier tipo de colaboración, (gráficos, sonidos, programas, artículos, correcciones, encuestas) se realizará un sorteo en cada lección y al ganador de éste, se le mandará gratuitamente por correo la lección en la que haya resultado ganador. Entre el resto de participaciones, seleccionaremos los mejores trabajos para que aparezcan en las lecciones del CPV y sus autores serán debidamente mencionados y figuraran con honores en los créditos de la lección.

Para la gente que vaya un poquito más lejos y nos mande programas y/o artículos, seremos más generosos. A toda persona que se le publique un artículo en el CPV, se le mandará por correo la lección donde se incluya su trabajo y si envía y son publicados más de tres artículos recibirá todo el CPV gratuitamente.

Por el momento Jose Miguel ya ha recibido la lección 3 completa por su artículo colaboración. Mas gente que han colaborado con nosotros, cómo Cristóbal Saraiba y Francisco Priego, traduciendo programas al C y todos los que nos han enviado encuestas, participarán, junto al resto de personas que nos ayuden, en el sorteo de la lección cuarta.

Hablaremos ahora un poco de las encuestas recibidas, por ahora no son muchas, de hecho se pueden contar con los dedos de la mano y algún apéndice más ;) pero como muestra es bastante válido.

Todos consideran al CPV como una herramienta de gran utilidad y con un entorno bastante agradable, en este aspecto las personas con ordenadores 386 destacan que tardan mucho en cargarse las lecciones, pero eso es difícil de solucionar, ya os contamos los problemas que nos causó el visualizador y lo difícil que resultaría modificarlo manteniendo la compatibilidad con el formato de los artículos, nuestro consejo es...

Paciencia hermanos, Roma no se hizo en dos días pero el VCPV sí.

De todos modos estamos pensando en realizar un visualizador en condiciones, que se incluiría en la última entrega y que permitiría acceder a todas las lecciones del CPV desde el mismo programa. Ya veremos .....

Respecto a la pregunta sobre otros cursos de estas características, en español seguimos sin conocer ninguno y que queréis que os digamos, es un hecho que nos alegra, ya que ser los primeros en algo hoy en día no es nada fácil. En cuanto a cursos o algo parecido en Inglis Pitinglis todos coincidís en destacar al PCGPE y algunos otro nombran a HelpPC y GDM, la verdad es que participamos plenamente en los elogios de la gente a estas magníficas herramientas, pero lo que no terminamos de creernos es que algunos de vosotros comparéis al CPV con esos tres peazo programas. Nosotros por lo menos, seguimos viéndolos como algo superior y consideramos al CPV como, algo novedoso en nuestro país pero simplemente 'resultón'.

En vuestros comentarios sobre los artículos también coincidís. Los consideráis acertados, diversos y que son tratados con rigor y amenidad. De esto último es de lo que nos sentimos más orgullosos, ya que teniendo en cuenta nuestra experiencia en la formación es todo un éxito conseguir destacar en esos aspectos.

Sobre los temas que más solicitáis hay de todo, algunos pedís artículos sobre la SVGA... ya nos gustaría a nosotros ya hablar de eso, pero andamos un poco peces en la alta resolución. Sirva como excusa barata, deciros que aunque últimamente se esta produciendo más programas de estas características, es un sistema gráfico minoritario en la programación de videojuegos.

Alguna petición formulada más 'humana' y atendida de buen gusto, es por ejemplo incluir más programas en C en las lecciones. Atendiendo a esta demanda, los autores hemos empezado a realizar algunos artículos en este lenguaje y también hemos solicitado ayuda para traducir todos los programas Pascal a C. Para esta lección hemos incluido en el directorio Traducci, todas las traducciones que nos han llegado hasta el momento, en próximas lecciones ya veremos ;-)

Otra sugerencia interesante fue proponer tareas para que vosotros podáis practicar en algo. Como veréis en algunos artículos ya os proponemos distintas tareas, estas las clasificaremos del 1 al 4 atendiendo a su dificultad. Los perfiles para cada nivel son:

                Dificultad  1 - Tirao                        O:-)
                            2 - Pichí, pichá                  :-/
                            3 - Complicadillo                 :-(
                            4 - Mu' chungo                   =8-X

Cada uno que se adapte a sus posibilidades, en el último apartado resumiremos todas las tareas propuestas en los artículos.

Nada más ya podéis pasar a zamparos los artículos. Golosssosss ;-9''
 
 

3.4.- El joystick.

Bueno, en este capítulo voy a hablaros en profundidad de otro tema fundamental en cualquier videojuego al que queráis imprimir algo de profesionalidad. Se trata, como no, del famoso Joystick. Sí, el famoso "mandito" que en programas de simulación aérea o en cualquier arcade es casi imprescindible para poder jugar en unas condiciones medianamente aceptables.

El realidad, hasta hace bien poco, no tuve la oportunidad de comprarme uno (últimamente están muy baratos, y por el módico precio de unas 2000 pesetillas podéis haceros con un joystick aceptable). Pero una vez que he descubierto sus posibilidades (sobre todo en juegos de simulación) ya no puedo vivir sin el. Además, casi todos los juegos comerciales incluyen la posibilidad de manejarlo y vosotros no podéis perder la ocasión de introducirlo en vuestros programas. Pero basta ya de charla y comencemos con un poco de historia. 8)

En la prehistoria (cuando el ordenador mas potente era un 8086). Los joysticks eran un objeto de lujo, y sus características eran mas bien mediocres. Los primeros joysticks que salieron al mercado eran digitales. Esto quiere decir (para los que no lo sepáis) que el joystick para una posición determinada, sólo nos daba información de si estabamos en ella (un 1) o no lo estabamos (un 0). Esto se traducía en que cuando movías el joystick hacia arriba, uno de los bit's del puerto de juegos (porque así es como se llama el puerto donde se conecta el bicho) se ponía a 1. A eso se reducía todo el trabajo de nuestro amigo.

En la actualidad son un poco mas complejos. Los PC's de la serie de los 80286 y superiores admiten en general los joysticks que se denominan analógicos. Estos, en oposición a los digitales, en lugar de retornar un 1 o un 0 para cada posición, devuelven un valor analógico (un valor comprendido entre 0 y un MAXIMO) para cada uno de los ejes, por lo cual, nosotros podemos saber si el joystick está "un poco arriba" o "muy arriba". 8)

                 MAXIMO X
                   |                               La posición de la palanca
                   | eje y                    en el joystick viene determinada
                   |                          por un par de coordenadas
                   |                          que son los valores analógicos
                   |      ejex                que nos devolverá el joystick
0   ---------------+---------------- MAXIMO Y            a través del puerto
                   |      .                                      de juegos.
                   |      .
                   |......x
                   |        (150,10)
                   |
                   0

Esto plantea unos cuantos problemas que a continuación explicaremos:

- ¿ Qué valor es el que corresponde al joystick cuando no esta  desplazado hacia ningún lado (es decir, el valor de los ejes en el centro) ?

- ¿ Cómo sabemos que valor corresponde a las esquinas y cuales a  lugares próximos al centro. ?

- ¿ Cómo podemos simular un joystick digital (que a menudo es lo que mas nos interesa) ?

Quedan estas dudas planteadas para que, una vez que conozcamos como se programa el joystick, podamos resolverlas. De todas maneras, os recomiendo que antes de seguir, le echéis un vistazo a la primera 'demo' que hemos preparado. Os aclarará las posibles dudas que todavía podáis tener sobre el comportamiento de los ejes.

Pulsa F2 para ejecutar el programa Joy-dem1.   - Posibilidad no disponible en la versión HTML-

En cuanto a la obtención de datos del puerto de juegos, hay (como siempre) varias formas de hacerlo. La primera de ellas es muy sencilla de obtener y es acceder a él mediante la interrupción 15h (ver capítulos de Introducción al PC. CPV-1) y gracias a unas subfunciones suyas podremos obtener información referente a la posición de los ejes del joystick. Las subfunciones que podemos utilizar son las que pongo a continuación:

        .Lectura de ejes:

            INT 15h

               entrada --->  AH = 84h
                             DX = 01h
               resultado ->  AX = valor eje Y
                             BX = valor eje X

        .Lectura de pulsadores:

            INT 15h

               entrada --->  AH = 84h
                             DX = 00h
               resultado ->  AL = si bit 4 igual a 0, botón 1 pulsado
                                  si bit 5 igual a 0, botón 2 pulsado

La otra manera consiste en obtener la información directamente del puerto de juegos, que es el 201h. El proceso para leer los ejes así como los botones varía bastante de la forma a la que habitualmente estamos acostumbrados (uno para cada cosa), ya que solo disponemos de un puerto del que leer. Cada bit de este puerto significa una cosa distinta:

                 7  6     5       4     3  2    1      0
                --------------------------------------------
                |  |  | boton1| boton2 |  |  | ejey | ejex |
                --------------------------------------------
                          0x201 (Puerto de juegos)

Los bits 6 y 7 son iguales que los del 5 y 4 pero para el segundo joystick, y lo mismo ocurre con los bits 3 y 2 con el 0 y el 1.

Los bits de 'boton1' y 'boton2' son fáciles de explicar, están a '0' cuando estén pulsados (OJO, a esto se le llama "lógica NEGATIVA") y a '1' cuando no lo estén. Pero los bits de 'ejex' y 'ejey' tienen mas historia. Su funcionamiento tiene relación con un condensador que os explicaré después. Pero lo mejor es que os lo explique diciendo lo que hay que hacer para leer los datos de los ejes. Supongamos por ejemplo que quiero leer el valor del eje X:

- Inicializaremos una variable contador a cero.

- Mandar un dato cualquiera al puerto 201h: Esto provoca la casi instantánea carga del condensador interno del puerto de juegos, que a continuación empezara a descargarse a través de las resistencias internas del joystick.

- Leer constantemente del puerto 201h, mirando si el bit 0 del dato obtenido, esta a '1' o a '0'

                . Si esta a uno : Incrementaremos nuestro contador.
                . Si esta a cero: Hemos terminado. El resultado estará almacenado en nuestra variable contador.

Lo que se hace en la práctica es leer los dos ejes a la vez, ya que una lectura de un valor de joystick bien puede haceros leer del puerto 800 o 900 veces, y sobre todo en un videojuego, si hay algo que no nos sobra es el tiempo. Para ello podemos seguir la misma técnica que antes solo que llevaremos dos contadores, uno para cada eje, que incrementaremos o no en nuestro bucle dependiendo de si el bit correspondiente esté a '1' o a '0'.

    . Valor Central

En un principio podríamos suponer que las coordenadas del centro (precisamente por ser el centro) deberían ser aproximadamente ejex=MAXIMO_X/2, y ejey=MAXIMO_Y/2, es decir, la mitad del máximo valor posible. Pero esto en la mayoría de los casos no es así. La explicación de esta rareza estriba en como esta construido el joystick. El núcleo de este aparato esta constituido por un circuito RC (condensador y resistencia). Cuando nosotros leemos del puerto de juegos, el joystick inicia un proceso de descarga del condensador a través de la resistencia, obteniendo así un valor u otro según el tiempo empleado en el proceso. Pero este tiempo no es lineal (para los interesados os diré que sigue una función exponencial). Así que no podemos esperar, leyendo los valores del joystick en reposo, obtener los valores medios.

Lo siguiente que podemos pensar, es que, si bien los valores no son los que cabría esperar, por lo menos serán los mismos en todos los joysticks. Pues bien, otra vez nos damos de bruces con la tecnología, ya que cada tipo de joystick tiene su valor medio, máximo y mínimo correspondiente. No queda otra solución que pedirle al jugador de nuestro videojuego nada mas comenzar que centre el joystick para nosotros poder obtener el valor medio. Es por esto que muchos de los juegos comerciales que soportan joystick te piden nada mas comenzar que centres el joystick y que pulses un botón.

   . Rango de valores de los ejes

Aunque en general, los valores máximo y mínimo se encuentran dentro de unos rangos mas o menos definidos, igual que antes, estos valores varían dependiendo del fabricante, de la velocidad del ordenador ..., por lo cual es conveniente obtenerlos antes de empezar a trabajar con el joystick De la misma manera que antes, diremos a nuestro jugador que coloque el joystick en la posición superior-izquierda y pulse el botón de disparo, en ese momento capturaremos los valores de los ejes y los guardaremos en unas variables. Procederemos de igual manera con la esquina inferior-derecha.

   . Simulación del joystick digital

Bueno, pues si pretendéis hacer un juego que use las propiedades analógicas del joystick (dígase X-wing) ;) ya tenéis bastante información.Pero en general lo que se pretende con el joystick es mover un muñeco por la pantalla, hacer que salte y que dispare. Para ello, nos importa un pepino si el joystick esta "un poco arriba" o esta "muy arriba", nos vale con saber que esta "arriba". Lo que pretendemos entonces es que nuestro aparato se comporte como un joystick digital. Para ello deberemos hacer lo siguiente:

- Tener almacenado en algún sitio el valor central para posteriores comparaciones.

- Tener almacenado en algún sitio la diferencia entre el valor máximo y el centro de cada eje para posteriores comparaciones.

- La función que nos dirá si el joystick está, por ejemplo, arriba podría ser la siguiente:

                int Arriba_Joy(void)
                {unsigned char ejex,ejey;

                  LeerEjes(&ejex,&ejey);
                  return(ejey>(centroy+(anchuray/factor)));
                }

Donde la variable "factor" nos dirá cómo de arriba debe estar el joystick para que obtengamos un valor de cierto: Si factor es 1 el joystick deberá estar arriba completamente para que la función devuelva cierto, mientras que si factor el grande, con que subamos un poco el joystick bastara.

Para que veáis esta simulación del joystick digital a través de uno analógico, os he preparado una demostración a través de la BIOS, y escrita esta vez en Pascal. Os servirá además para observar las diferencias  (velocidad, valores de los ejes...) entre la BIOS y el acceso al puerto 201h.

Pulsa F2 para ejecutar el programa Joy-dem2.- Posibilidad no disponible en la versión HTML-

Aunque en el ejemplo de arriba os he puesto dentro de la función 'Arriba_Joy' que se leían los ejes, en general no es esto lo que se hace, ya que si para cada comparación tuviéramos que estar leyendo de los ejes nuestro juego sería eterno. Como los juegos (y en general casi todos los programas) tienen casi siempre un bucle principal, lo que se hace es, al  principio de ese bucle, se leen los ejes UNA SOLA VEZ, y se almacena su resultado en alguna variable auxiliar, de manera que cuando queramos consultar algo, basta con mirar esas variables, ahorrándonos así un tiempo nada despreciable...

Habréis observado que mediante la interrupción 15 de la BIOS. Podemos detectar si hay o no un joystick instalado. Esto se puede implementar muy fácilmente a través del puerto 201h. Para ello debemos enviar un valor cualquiera al puerto, exactamente igual que cuando iniciábamos una lectura. Esto como ya sabemos provoca la carga del condensador que debería descargarse a través de las resistencias del joystick ..., pero ¿ y si no hay resistencias ?. En eso se basa el procedimiento. Consiste en almacenar el primer valor que recibamos nada mas enviarle algo al puerto 201h, y ver si este varía en un tiempo razonable. Si no cambia es que NO hay joystick instalado y si varía es que el condensador se esta descargando y esto significa que SI hay joystick instalado.

Seguramente también se os habrá planteado la siguiente duda:

¿Que es mejor, acceder al joystick mediante la BIOS, o directamente a través del puerto 201h ?. La respuesta es sin duda que es mejor acceder directamente. Ya que, no se porqué, la BIOS tarda como diez veces más que el acceso directo, y pretendiendo, como pretendemos, que nuestro juego vaya medianamente rápido, no podemos permitirnos esos lujos.

Otra última consideración, es que la rutina de lectura de ejes DEBE SER ESCRITA EN ENSAMBLADOR. Se que algunos de vosotros tembláis al oír la palabra 'ensamblador' pero en este caso es necesario. Como el proceso de descarga del condensador depende del tiempo, y este tiempo es muy pequeño, es necesario que nuestra rutina sea lo mas rápida posible, hasta el punto de que si no esta escrita en ensamblador (o por lo menos la parte relativa al bucle de lectura de los ejes) no funcionará.

Bueno, pues aquí se acaba el capitulo del joystick, como final os ofrezco esta demostración para que veáis lo que se puede hacer con el joystick, espero que os guste.

Pulsa F2 para ejecutar el programa Joy-dem3.   - Posibilidad no disponible en la versión HTML-
 


3.5.- Retrazado vertical.

El retrazado vertical es uno de los temas fundamentales que debe conocer todo programador de videojuegos, ya que tarde o temprano, vamos a tener que tratar con él. Todos los programadores 'experimentados' de videojuegos en PC comenzamos en este mundillo de la misma manera: nuestro primeros pinitos los realizamos en el área del modo texto creando aplicaciones sencillitas con los caracteres especiales ASCII, de ahí realizamos un salto bastante grande al modo gráfico y empezamos a sacar gráficos simples, formados de líneas y otras figuras, seguidamente comenzamos a visualizar pequeños sprites, y hasta aquí todo iba de maravilla, hasta que un día te das cuenta de un detalle, comienzas a mover una imagen por la pantalla y aprecias un pequeño parpadeo que se hace más notable cuantos más objetos muevas y/o cuantos más grandes sean estos. En ese momento te fijas en los juegos profesionales a los que te vas acercando y te das cuenta de que las imágenes en estas se presentan supernítidas... ¿Pero que pasa?...¿Magia?

Empiezas a repasar tu programa de arriba a abajo, consultas algunos libros de programación generales y nada, no encuentras la causa de la diferencia, finalmente se opta por los rezos y la magia negra, y na', ni con esas. La verdad es que hoy en día no es tan difícil conseguir la receta mágica, pero antes te las veías negras para aprender nuevos trucos. En el caso del retrazado vertical cuando ves lo sencilla que era la solución, te dan ganas de echarse a llorar. :,,(

Algunos de vosotros diréis:

 -¿Passsa tío, si tan sencilla es la historia, corta el rollo y suelta prenda?

A lo que el menda respondería:

 -Tranqui colega, es que a mi me van estas movidas.

La verdad es que el retrazado vertical es una de las pocas de cosas en la programación de VideoJuegos que con un mínimo esfuerzo (código) se consigue un gran resultado. En algunos de los programas suministrados me parece que controle el retrazado vertical y si os habéis mirado todos los fuentes al detalle, habréis encontrado la clave del dilema, no son más que dos instrucciones repeat-until. Pero una vez más hago de ogro y no quiero facilitaros la solución sin contaros una de mis historias, además considero fundamental el conocer la construcción de la pantalla para llegar a ser un buen programador "Junior" de videojuegos. :)

Independientemente de la tarjeta de vídeo, la construcción de una pantalla funciona de la misma manera en todas ellas. Los monitores utilizados en el entorno PC son todos del tipo 'Rasted Scan Device' en los cuales la pantalla se compone de un gran número de puntos pequeños ordenados en una retícula rectangular. Al construir la imagen, un haz de electrones que genera el monitor (llamado por esta característica CRT o Tubo de Rayos Catódicos) recorre cada punto y se activa o apaga para cada pixel, excitando o no las partículas de fósforo que componen la pantalla. En monitores monocromos únicamente un haz de electrones es necesario para generar las imágenes, sin embargo, en un monitor en color ya son necesarios tres haces, uno para cada color elemental RGB, la combinación de estos rayos y la variación de las intensidades de los mismos provocan la visualización de un color u otro, dependiendo del tipo de monitor los posibles colores a mostrar serán más o menos.

Un problema de esta tecnología es que las partículas de fósforo se mantienen ionizadas (brillan) durante un corto espacio de tiempo y similar a lo que pasaba con las memorias DRAM (ver artículo timer, lección 2), se necesita regenerar la pantalla varias veces por segundo, esta frecuencia varía entre 50-70 Hz (regeneraciones/segundo) y como es lógico a mayor frecuencia mayor calidad.

La regeneración o reconstrucción de la pantalla comienza desde la esquina superior izquierda (punto de vista del usuario) de donde el haz se mueve hacia la derecha hasta el final de la línea momento en el que se produce un retrazado horizontal, en este momento el haz se desplaza desde el final de la línea al comienzo de la siguiente. Cuando ya se han generado todas las líneas se produce nuestro esperado retrazado vertical momento en el cual el rayo de electrones se dirige desde la esquina inferior derecha hasta su posición inicial. Me gustaría destacar tres asuntos sobre el retrazado y la regeneración de la pantalla:

- Cuando los retrazados se producen el haz de electrones es desconectado para que no se visualice la línea de retorno.

- El tiempo que se tarda en recuperar la información necesaria para continuar visualizando la imagen es mayor que el tiempo que consumen los retrazados, debido a esta causa y a que el haz de electrones no se puede parar ni posicionar en posiciones determinadas, es necesario crear unas zonas llamadas de overscan a la derecha y abajo de la pantalla, donde se sigue generando la imagen (un fondo de color) mientras se recupera nueva información.

- El fósforo de la pantalla es una sustancia degradable y una excitación continuada de las partículas provoca el deterioro de las mismas, de esta consecuencia nos protegen los protectores de pantalla, los modos de funcionamiento de los mismos van desde simplemente apagar el haz de electrones hasta verdaderas obras de arte de la animación, el objetivo de estos protectores es no mantener imágenes fijas en pantalla que es lo que de verdad 'quema'. :)

Ya sabemos lo que es el retrazado vertical, ahora os diré para que utilizarlo. Nuestro primer objetivo es impedir que podamos cambiar una imagen mientras se estaba dibujando la anterior, esto provoca la visualización de 'dos mitades de imágenes' simultáneamente es dos posiciones diferentes y con contenidos diferentes, si este efecto se repite una y otra vez se produce el parpadeo de la pantalla, si nosotros esperamos a que se produzca un retrazado vertical para cambiar las imágenes nos aseguraremos de no interrumpir la generación de ningún dibujo. La segunda consecuencia, y no menos importante, de controlar el retorno del haz es el hecho de que al esperar en nuestros programas la realización de un retrazado, estamos a la vez sincronizándonos con la frecuencia de regeneración de la pantalla (50-70 Hz), como esta frecuencia es independiente de la velocidad de nuestro procesador, estaremos 'estandarizando' la velocidad de nuestro programa para todos los tipos de máquina.

Pasemos a la práctica, para conocer cuando se está produciendo un retrazado tenemos que consultar el registro de estado de la VGA número $3DA, el cual indica entre otras cosas si se esta produciendo un retorno del haz. Os presento a continuación la configuración de dicho puerto:

Puerto de estado Vga. Número $3DA

         7   6   5   4   3   2   1   0
       ---------------------------------
       | ? | ? | ? | ? | 0 | ? | ? | 0 |
       ---------------------------------
                         |           |
                         |           ------> Actividad del retrazado
  Retrazado vertical  <---                    0 = Actualmente no hay
   0 = No activo                                  retrazado activo.
   1 = Activo                                 1 = Actualmente activo
                                                  retrazado horizontal o
                                                  vertical.

Luego para sincronizarnos con el retrazado vertical tendremos que incluir las sentencias siguientes en nuestros programas. Con ellas primero esperamos a que no esté activo el retrazado y después a que esté activo. Con ello nos aseguramos que esperar al comienzo de un retrazado completo.

   Repeat until port[$3DA] and 8 <> 8; (* Retrazado no activo *)
   Repeat until port[$3DA] and 8 =  8; (* Retrazado activo. Ahora!, Ahora! *)

La correspondiente rutina en ensamblador sería:

   Procedure EsperaRetrazado; assembler;
   label et1, et2;
   asm
        mov dx, 3DAh           ; Mueve a un registro la dirección del puerto
   et1:
        in  al,dx              ; Lee del puerto y deposita el valor en al
        and al,08h             ; Comprueba el cuarto bit del registro
        jnz et1                ; Si está activo el retrazado esperamos
   et2:
        in  al,dx              ; Volvemos a leer
        and al,08h             ; Volvemos a comprobar
        jz  et2                ; Si no está activo esperamos
   end;

y ya está, esto es todo el código. Como veis evitar el parpadeo no tiene ningún misterio desde el punto de vista del programa, pero detrás de esos repeat o de la pequeña rutina asm, hay mucha más sustancia que con este artículo os he pretendido mostrar.

En la demostración del artículo del modo 13h 3/3, os mostraré cómo se controla el retrazado en combinación con otras técnicas gráficas, allí veréis el resultado de controlar el retorno del haz.

Ya os he comentado en la presentación de esta lección que una de la propuestas recibidas que más nos ha gustado es la de mandaros deberes, ;) para empezar en este artículo os voy a proponer dos tareas, que están muy relacionadas con los temas que acabamos de tratar. La verdad que para ser las primeras propuestas voy a poner el nivel bastante alto, pero como os dije al principio, que cada uno se adapte a su capacidad.
 

La primera propuesta para este artículo la considero de nivel 2, y se trata de realizar un protector de pantalla para DOS, las claves para realizar este programa son las siguientes:

-Lo que haga el protector de pantalla cuando se active es lo de menos el caso es que no se queda la pantalla fija, y ser posible realice alguna animación agradable y que no necesite de acceso a disco.

-Al ser un protector es imprescindible que antes de activarlos salvéis el contenido de la pantalla, para ello tendréis que obtener el modo de vídeo actual y salvar la memoria correspondiente.

-El modo de activación del protector depende del programa que hagáis, para empezar podíais crear un protector transiente que forme parte de otro programa, si optáis por una solución mas general y queréis realizar un programa residente DOS, el asunto se complica mucho más y elevaréis el nivel del desafío de 2 a 3-4.

La segunda propuesta sobre el retrazado es de nivel 4 y consiste en:

En muchas tarjetas VGA y si así esta habilitado, existe la posibilidad de provocar una interrupción hardware (IRQ 2) cada vez que comience un retrazado vertical. Situando un controlador propio para que atienda a esa interrupción, podemos tener un proceso demonio al igual que hicimos con la IRQ 0 y el sonido, para que este caso se encargue por ejemplo de restaurar los fondos de nuestros sprites, actualizar marcadores o algo así. El problema de esta tarea es que hay que programar distintos registros de la VGA para habilitar la interrupción y que la rutina controladora debe ser muy, muy rápida o sea emsamblador. Para los que os atreváis con esta propuesta y queráis más información os remito a uno de los pocos libros donde he visto implementado este tema se trata de:

          Video Systems (Sistemas de Video) de Richard Wilton

No se si se habrá publicado una edición en castellano, pero para quién se atreva con este desafío el idioma no creo que sea el mayor problema. ;) La verdad es que ambas tareas son muy difíciles pero ya sabéis, la mayoría de vosotros tomaros estos desafíos como una cosa mu' bunita, mu' interesante, que se puede hacer y ya está.

Para los que os pongáis manos a la obra, ni que decir tiene que nos gustaría recibir vuestros trabajos. Con un mínimo de calidad estos serán publicados en el CPV, ya que podrán estar mejor o peor hechos pero ver que hay gente que nos escucha y nos dedica tiempo es un hecho que amortiza todo nuestro esfuerzo, nos anima a continuar y estimula al resto de la gente a participar. :)
 


3.6.- El modo 13h 3/3.

Con este artículo vamos a dar la puntilla al modo 13h. En la anterior lección estudiamos la forma de almacenar imágenes en disco (archivos Cel), vimos donde guardar las imágenes una vez leídas (punteros y memoria dinámica) visualizamos sprites por pantalla sin respetar el fondo y os conté cómo realizar animaciones con varios sprites. Ahora vamos a aprender cómo visualizar sprites respetando el fondo con nuestras rápidas rutinas en ensamblador y distintas técnicas para realizar las animaciones, doble sprite, pantalla virtual, fondo permanente...  pero vayamos por partes.

Para empezar con esta entrega os voy a contar cómo presentar sprites en pantalla respetando el fondo. Con la técnica de visualización presentada en la anterior entrega (visualizar el sprite fila a fila) al dibujar nuestro sprite machacábamos el fondo de la pantalla y en el caso de que éste no fuese del mismo color que el fondo del muñequito, se distinguía la forma rectangular del sprite. La solución para este contratiempo está en forzar una trasparencia al visualizar el sprite, esto lo conseguiremos de la siguiente manera: cuando dibujemos una imagen en un nuestro programa de dibujo utilizaremos un fondo todo del mismo color (generalmente se utiliza el color negro y la primera posición de la tabla de colores, pero podemos variar estas condiciones siempre y cuando lo controlemos en nuestra rutina) así, cuando nos llevemos la imagen a la pantalla sabremos si el siguiente punto que vamos a dibujar forma parte del sprite o del fondo del mismo, si es un punto del fondo hacemos como si ésta parte del sprite fuese trasparente y no nos llevamos ese punto a la pantalla dejando esta tal como está, en otro caso ponemos el punto en su posición.

Para poder controlar esta circunstancia tenemos que visualizar la imagen punto a punto y esto sólo significa una cosa, que como sigamos trabajando en base a LAN nos vamos a hacer viejos esperando mientras mostramos un sprite. Se nos hace im-pres-cin-di-ble trabajar en ensamblador y de esta manera optimizar el código. Como no estamos en un curso de ensamblador sino de programación de videojuegos no voy a entrar en detalle ahora acerca de como realizar esas rutinas, simplemente os remito al programa demostración de este artículo dónde suministro los fuentes, como siempre, exhaustivamente comentados. También me gustaría destacar que aunque nuestras rutinas son suficientemente rápidas no son óptimas, ni mucho menos, y seguro que existen rutinas mucho mejores. En el propio lenguaje ensamblador existen muchos trucos para optimizar el código (trabajar lo más posible con registros, evitar trabajar con las instrucciones de pila, emplear las instrucciones lógicas, optimizar los bucles.....) estoy pensando en dedicar un artículo completo a presentaros algunas de estas técnicas, pero quizás sea algo demasiado profesional y fuera de nuestros objetivos, en todo caso, vosotros tenéis la última palabra. Con la nueva forma de distribución, tenéis la posibilidad de demostrarnos con vuestras colaboraciones vuestro interés. ;)

Ya os he comentado como visualizar un sprite respetando el fondo, bien, si queremos mostrar el sprite en otra posición sólo tendremos que utilizar la rutina anterior para otras coordenadas gráficas. Pero si hacemos esto así, a las bravas, tendremos un problema, se nos quedará una copia del gráfico que hemos visualizado en la anterior posición. Pues claro, al visualizar un gráfico con esta técnica, respetamos el fondo de la parte correspondiente a la zona trasparente de nuestro sprite, pero el resto del dibujo machaca todo lo que hubiera debajo de él, entonces ¿cómo hacer que en nuestros juegos los sprites se muevan a sus anchas y el fondo permanezca inalterable? Hasta el momento ese efecto ya lo hemos conseguido en dos programas del CPV, el programa Animacio y en Dardos.

En Animacio utilice una técnica bastante sencilla, como las imágenes se sucedían de derecha a izquierda lo que hice fue: al capturar el sprite, cogí n caracteres pixels más de fondo a la derecha del sprite, donde n es el decremento de la coordenada x en cada paso, de esta manera al visualizar una  imagen en la nueva posición el propio sprite machacaba el resto que dejaba el  gráfico anterior. Quizás sea la técnica más sencilla para conseguir animaciones, pero está limitada a utilizar un fondo del mismo color que el del sprite y a utilizar la visualización de gráficos sin respetar el fondo.

En Dardos emplee una técnica más avanzada conocida como Doble Sprite. Esta técnica se apoya en una idea simple, para cada sprite que vayamos a utilizar tendremos que definirnos otra variable (sprite) con el mismo tamaño  para, antes de visualizar nuestro gráfico, salvar en esa variable el contenido de la pantalla. Utilizando esta técnica el proceso para realizar una animación sería el siguiente:
 

1- Salvar en la variable de fondo, el contenido de la pantalla que ocupa la posición donde vamos a visualizar el sprite.

2- Visualizar nuestro sprite en su posición, (respetando el fondo).

3- Una vez pasado un retardo o realizadas otras tareas, restaurar el fondo original salvado en la variable. (mostrar sin respetar el fondo)

4- Se repite el paso 1 para la nueva posición del sprite.


En definitiva el proceso del doble sprite se compone de tres pasos básicos, salvar, visualizar y restaurar.

Todo lo anterior lo tendríamos que realizar para cada cambio de imagen lo que supone un gran trasiego de sprites y fondos en la pantalla de vídeo, tantos como muñequitos tengamos revoloteando por ahí. En el artículo del retrazado vertical os comenté que al visualizar gran número de imágenes en posiciones diferentes se produce un parpadeo a causa de la construcción ininterrumpida de la pantalla. Para evitar este efecto es necesario utilizar varias páginas (pantallas) de vídeo para visualizar una pantalla mientras trabajamos sobre otra. En algunos modos de vídeo EGA, VGA existen ya de por sí varias páginas de vídeo, pero en nuestro querido modo 13h no disponemos de páginas extras y toda la memoria de vídeo está ocupada por una única página.

A partir de la próxima lección (y como habréis comprobado ya, solemos  cumplir todas nuestras promesas ;) veremos como crearnos un modo tweaked (especial) basado en el modo 13h, con el que conseguiremos una organización de la memoria de vídeo dónde contaremos con ¡¡¡cuatro!!! páginas de vídeo, de 320x200x256, alucinante verdad, =8-O,, todo llegará tranquilos. :)

Mientras tanto vamos a ver cómo conseguir páginas extras software en el modo 13h. La solución es 'fácil', crearnos una variable, que se situará en memoria convencional, con la misma estructura que la pantalla. Esta variable se conoce cómo pantalla virtual y será una matriz de 320x200 bytes. Sobre esta variable trabajaremos como si se tratase de la pantalla real, de hecho podremos utilizar todas las rutinas explicadas hasta el momento con sólo cambiar la dirección de destino , es decir, sustituir A000:0000 por el segmento y el desplazamiento de nuestra variable, el resto de las rutinas se dejará intacto. La característica principal de esta técnica es que no se visualizan las modificaciones que estemos haciendo sobre la pantalla y que ganaremos en velocidad debido a que el acceso a la memoria convencional es más rápido que a la memoria de vídeo.

Para hacer visibles los cambios tendremos que llevarnos toda la pantalla virtual a la memoria de vídeo de una vez, ¿Cuando realizar este intercambio? pues bien, vosotros veréis, tenéis para pensarlo unos milisegundos ;;;))), la verdad que tendremos que hacerlo periódicamente y a una gran velocidad luego no nos podremos entretener. Un ejemplo de rutina que realice un volcado de una pantalla virtual en la memoria de vídeo podría ser la siguiente:

procedure VolcarPantalla; assembler;
label bucle1,bucle2;
asm
        push ds                    (*Salva los registros de segmento*)
        push es

        lds  si, PantallaVirtual   (*Ponemos en ds:si la dirección de la *)
                                   (* pantalla virtual*)
        mov  ax,0A000h             (*En es:di la dirección de la memoria de*)
        mov  es,ax                 (* vídeo*)
        xor  di,di                 (* di = cero *)

        mov  cx,32000              (*Tamaño de la pantalla en words*)
        cld                        (*Indica que se incremente los registros*)
                                   (* de desplazamiento*)
        rep  movsw                 (*Mueve el número de words indicado en*)
                                   (* cx de ds:si a es:di *)

        pop  es                    (* Recupera los registros de segmento*)
        pop  ds
end;

Si controlamos el retrazado vertical para realizar la copia justo mientras se produce el retorno del haz, conseguiremos unas animaciones super-nítidas y sincronizaremos nuestros programas con la velocidad de refresco de los monitores. La anterior rutina es tan rápida que quizás no ganemos nada con controlar el retrazado al volcar la pantalla y seguro que perdemos en velocidad.

Las pantallas virtuales no solamente se pueden utilizar para evitar parpadeos sus posibilidades son mucho más amplias. Como os expliqué antes, la técnica del doble sprite consiste en almacenar los fondos para cada sprite que visualizaremos en unas variables para su posterior restauración, si el número de sprites a visualizar es elevado tendremos un gran número de variables 'sueltas' y quizás nos convendría tener una pantalla virtual más para almacenar el fondo de manera permanente, que además de ser una solución más compacta, ofrece otras ventajas importantísimas.

- El proceso para restaurar el fondo se simplificará mucho ya que ahora sólo necesitaremos conocer las coordenadas de un sprite, su anchura y altura para reponer el fondo, moviendo el bloque correspondiente desde la pantalla de fondo. En el programa demostración os muestro una rutina llamada MoverBloque que realiza esta tarea de una manera bastante eficiente.

- Al tener el fondo estático en una variable podemos utilizarlo para realizar scroll de pantalla, pero esto es otra historia, que como dijo Conan, será contada en una próxima lección. :)

Bien recapacitemos: utilizar pantallas virtuales es: más nítido, más  rápido, más eficiente, más compacto, con más posibilidades, en definitiva más  mejor... ¡¡¡ genial !!!... Pero como suele pasar toda virtud también tiene  un defecto asociado y en nuestro caso la pega es el gasto de memoria. Cada pantalla nos va a consumir 64 Kb y si utilizamos 2 la memoria será 138... Que no, que no se me ha olvidado multiplicar, era para ver si estabais atentos quedamos que son 128 Kb, a esto habrá que sumar las variables generales y el código del programa, vamos que cuando en el artículo de la cacharrería os comente que yo me tenía que pegar para conseguir 5 Kb de memoria convencional no os mentí.

Una vez contada la historia paso ahora a daros unos consejos técnicos. Para definir unas variables para almacenar las pantallas virtuales la primera estructura en la que pensaríamos todos sería algo así como:

      var PantallaVirtual:Array[1..64000] of byte;   (* Pascal *)

      unsigned char PantallaVirtual[64000];          /*   C    */

Craso error, con estas variables de 64000 bytes estaríamos llenando la zona de memoria de 64 Kb que los compiladores suelen destinar para almacenar las variables del programa y seguramente nuestros programas harían crack. La solución traerá de cabeza a más de uno, utilizar punteros y memoria dinámica. Al utilizar apuntadores la memoria que se consumirá en nuestra pequeña zona de memoria será la necesaria para almacenar una dirección, 4 bytes para el MS-DOS, el grueso de la información, a lo que apunta el puntero, se almacenará fuera de ese segmento y siempre respetando el tamaño máximo de 640 Kb. Para asignar la memoria dinámicamente utilizaríamos alguna de las siguientes funciones:

      procedure GetMem(var P:Pointer; Size:Word)     (* Pascal *)

      void *malloc(size_t size)                      /*   C    */

La memoria asignada dinámicamente debe ser liberada explícitamente, mediante una orden del usuario, ya que de otra manera permanecerá inaccesible al resto de programas aunque nuestro programa finalice su ejecución y sería así hasta que el ordenador se inicializase de nuevo. Las instrucciones que deberemos utilizar para liberar la memoria serán:

      procedure FreeMem(var P:Pointer; Size:Word)     (* Pascal *)

      void free(void *block)                          /*   C    */

Para terminar con el artículo os presento el programa demostración dónde como siempre implemento lo explicado anteriormente y que además de ayudaros a entender las distintas técnicas de visualización os mostrará la  utilidad del control del retrazado vertical. El control del haz es realizado antes del cambio de paleta.

Pulse F2 para ejecutar el programa PANTVIRT.  - Posibilidad no disponible en la versión HTML-

Después de presentaros la demostración sólo me queda mandaros alguna  tarea, la verdad es que en este artículo lo tengo fácil. Lo que os propongo es realizar distintos programas, a modo de demos, utilizando las rutinas y técnicas explicadas hasta el momento, para 'animar' lo que vosotros queráis. La dificultad para este desafío la sitúo en uno o dos ya que, lo tenéis todo hecho, sólo debéis haceros con unos gráficos y 'enganchar' todo. :)

Aunque la trilogía de artículos sobre el modo 13h acabe con esta entrega no significa ni mucho menos que dejemos de utilizarlo, todo lo contrario, el modo 13h es la base para el CPV y en el se basarán la mayoría de los juegos de cada mes así como otras series de artículos sobre efectos especiales, scrolling.... Por lo tanto convendría que entendieseis bien las bases para trabajar en este modo explicadas hasta el momento, además os servirá como preparación para lo que se nos viene encima el 'modo X'.=8-,,X
 

3.7.- Algoritmos de colisión.

Vamos a hablar de un tema en el que más de uno de vosotros estáis interesados, para que veáis que las encuestas sirven para algo ;) El tema es los Algoritmos de colisión y aunque el nombre impresiona y suena a una cosa muy complicada la verdad es que no es así.

Como habéis visto, hasta ahora la mayoría de nuestras demostraciones son animaciones de objetos que se podrían superponer unos sobres otro y no pasaría nada. Por el momento os hemos enseñado como sacar imágenes por pantalla y eso es importante, lógico, si queréis hacer un juego lo primero que debéis tener son los muñecos en pantalla, pero no menos importante es poder conocer cuando los sprites se dan de leches y evitar que se visualicen unos sobre otros.

Los algoritmos de colisión son el conjunto de técnicas y estructuras que hacen posible la detección de eventos en los programas, por ejemplo cuando un muñeco toca el suelo, cuando una bala impacta en la jeta del malo, cuando cruzamos una puerta.... Seguro que sólo con deciros esto a más de uno se le ocurren 4 ó 5 métodos y rutinillas para conseguir estos objetivos y algunas de estas técnicas será mejor que la nuestra ;) En verdad el tema de los algoritmos de colisión es como el de los algoritmos para ordenar un lista de elementos, donde existen multitud de técnicas y cualquiera de ellas puede ofrecer una solución eficiente a nuestras necesidades.

Hasta el momento hemos utilizado dos técnicas distintas. En Dardos, como ya os explique, el algoritmo de colisión consistía en comprobar el color  del punto dónde había impactado el dardo y dependiendo de ese valor sabríamos en que zona de la diana habíamos acertado. Esta técnica es bastante eficiente para algunos tipos de juegos, pero normalmente es inviable tener controlados todos los colores que forman el fondo y los sprites de la pantalla, luego en principio la descartaremos.

En el programa demostración del modo 13h 3/3 también detectábamos eventos en la pantalla, el método era controlar las coordenadas del sprite y dependiendo de la posición obrar de una manera u otra. Este método sí se  utiliza más pero su uso está restringido a comprobar si los muñecos están dentro de la pantalla y cosas cómo por ejemplo, comprobar la coordenada vertical y forzar un efecto de gravedad. Aunque esto último más que algoritmo de colisión es un algoritmo de control de posición, nosotros no vamos a diferenciar ambos tratamientos.

La técnica de colisión que más utilizamos nosotros es la conocida como el método de los recuadros. Este consiste en asociar a cada sprite un recuadro, 4 coordenadas que generalmente coinciden con la posición X, posición Y, posición X más anchura del sprite, posición Y más altura del sprite. Esto en código sería algo así como:

Type TipoRecuadro = record
                     x1,y1,x2,y2: Integer
                    end;

Para detectar las colisiones entre los sprites comprobamos en cada iteración del bucle principal del programa (digamos después de volcar la pantalla virtual) si se ha producido alguna intersección entre los recuadros.  Dependiendo de los objetos que hayan colisionado actuaremos de una manera u otra. Generalmente son dos los tipos de colisión a controlar, los impactos entre distintos sprites y los contactos entre los sprites y los objetos 'sólidos' del fondo de la pantalla. Una rutina que detecte estas intersecciones podría ser la siguiente:
 

function HayInterseccion(Rec1,Rec2:TipoRecuadro):boolean;
var Anchura1, Anchura2, Altura1, Altura2, AnchuraMayor, AlturaMayor:integer;
begin
 Anchura1 := Rec1.x2 - Rec1.x1 + 1;         (*Anchura del primer recuadro*)
 Altura1 := Rec1.y2 - Rec1.y1 + 1;          (*Altura del primer rec.*)
 Anchura2 := Rec2.x2 - Rec2.x1 + 1;         (*Anchura del segundo rec.*)
 Altura2 := Rec2.y2 - Rec2.y1 +1;           (*Altura del  ....*)

 if Rec2.y1 > Rec1.y1 then               (*Guardamos la mayor altura*)
  AlturaMayor := Altura1
 else
  AlturaMayor := Altura2;

 if Rec2.x1 > Rec1.x1 then               (*Guardamos la mayor anchura*)
  AnchuraMayor := Anchura1
 else
  AnchuraMayor := Anchura2;

 (*Formula para el control de una intersecci¢n entre recuadros*)

 HayInterseccion := (ABS(Rec1.x1 - Rec2.x1) < AnchuraMayor) and
                    (ABS(Rec1.y1 - Rec2.y1) < AlturaMayor);
end;

Como veis no son más que unas pocas restas y comparaciones. Yo ya os he contado como detectar las colisiones a vosotros os toca ahora decidir que os gustaría hacer con estas rutinas. Como siempre os facilito un programa demostración para que afiancéis vuestros conocimientos y os sirva de base para realizar vuestro primeros programillas. En este caso he representado un juego que sonará a todo el mundo, 'er komekokos'. ;) La siguiente demostración puede ser un buen primer paso para realizar un jueguecillo completo.

Pulsa F2 para ejecutar el programa Colision.   - Posibilidad no disponible en la versión HTML-

Espero que a los que solicitasteis ayuda os haya gustado este artículo y podáis realizar alguna aplicación. Esperamos impacientes noticias vuestras. :)
 

3.8.- En busca del fuego.

Al igual que hemos hecho para el modo gráfico 13h y con el sonido con el speaker, vamos a comenzar ahora una serie de artículos que versarán sobre un mismo tema, los efectos especiales. Estos artículos mostrarán algunas de las muchas técnicas que se utilizan para la creación de demos y que pueden ser aplicadas en el mundo de los videojuegos. Cabe ahora volver a hacer un voto de humildad en el cual los autores del CPV, nos autocalificamos como novatos tanto en la formación como en la programación de videojuegos y demos. En este último campo no hemos hecho ninguna incursión y los programas que realizaremos como complemento a los artículos, serán nuestras primeras chapuzillas en este mundo luego, darnos un poco de tregua ¿ Vale ? :)

Quizás esta serie de artículos haya comenzado ya con la técnica de fundido presentada en la anterior lección y yendo un poquito más lejos, con el programa Marcador que utilizaba el juego de caracteres de la VGA.

Pero tratamos ahora unos trucos 'más serios ', para abrir boca empezaremos con dos efectos fuego. La verdad es que ambos trucos están muy relacionados y de hecho, el primero de ellos 'me salió' =8-O intentando conseguir el segundo.

Os cuento ahora los pasos necesarios para realizar el primer efecto. Lo primero que debemos hacer es generar una paleta de colores adecuada, que para nosotros será, una escala de tonalidades que va desde el negro al rojo. Este gradiente consume en nuestro caso, un total de 100 colores, aunque este número es variable. Una vez generada la paleta, visualizamos los 100 colores de la misma de arriba a abajo y empezando por el negro, de forma que ocupen toda la pantalla. Una vez mostrada la paleta visualizaremos un número (25000 por ejemplo) de puntos en posiciones y de color aleatorio cuya función os explicaré más adelante.

Hasta aquí tenemos lo que podemos llamar la plantilla de nuestra futura pantalla, una vez realizados todos estos pasos queda darle el toque final, el perejil, que es el filtrado de la imagen. El filtro que aplicó a la imagen es conocido como filtro average o media aritmética y consiste en sustituir en toda la imagen el color de un punto por la media aritmética de todos los puntos que le rodean ( 8 salvo en los laterales) este proceso es muy utilizado en áreas como la visión artificial o la captura de imágenes. En ellas el efecto que se persigue es eliminar los ruidos que forman parte de las imágenes. Estas perturbaciones se suelen presentar como valores en una escala muy diferente del resto de los puntos de la pantalla y con el filtro de average se intenta atenuar estos valores extraños. En nuestro programa no es este el efecto que buscamos, sino todo lo contrario, a partir de mucho puntos aleatorios (ruidos) introducidos a propósito, propagar el efecto de estos puntos a los de alrededor causando un efecto interesante.

Una vez generada la imagen sólo queda visualizar unos cuantos sprites de créditos y jugar un poco con la paleta para darle vidilla al asunto. Para ello hacemos una copia de la paleta original y atenuamos o aumentamos los 100 colores fuego de la misma para dar una sensación de calor latente, barbacoa, brasitas para las sardinitas o algo así ;)

Os presento a continuación el programa demostración que ya os adelante en la anterior lección, pero esta vez, os muestro los pasos intermedios para que veáis las fases de la construcción de la pantalla:

Pulse F2 para ejecutar el programa FX_Fueg1 - Posibilidad no disponible en la versión HTML-

El efecto que os voy a presentar a continuación es uno de los más utilizados por los programadores de demos, dígase Future Crew, Vangelis Team, Asphixia... y a partir de ahora por vosotros, ;)  se conoce como fuego virtual. Existen distintos métodos para conseguir este efecto, los más importantes son mediante fractales y mediante filtros de pantalla. En este artículo os presentaré la segunda técnica. Sobre el tema fractal estoy pensando realizar algún artículo, si os interesa el tema haznos llegar tu opinión y/o/u tu colaboración. :)

Como os dije al principio el fuego virtual es una mejora sobre el primer efecto que os he mostrado, que además de utilizar el filtro average presenta otras características que os voy a exponer:

- En el primer programa se construía una única pantalla y el efecto animado se conseguía variando la paleta de colores. Sin embargo en el fuego virtual mediante filtros, la animación se compone de una sucesión de imágenes que deben ser presentadas rápidamente en secuencia según son generadas. Debido a esta característica es muy recomendable utilizar pantallas virtuales y unas rápidas rutinas de visualización, para evitar parpadeos y agilizar los procesos respectivamente.

- La paleta de colores debe contener una mayor y mas gradual escala de colores fuego, que vaya del negro al anaranjado pasando por el rojo, para dar una mayor realidad al asunto. En nuestro caso utilizaremos 200 colores.

- La construcción de cada pantalla se realiza de una manera diferente. Los pasos que se deben seguir para generar las pantallas son los siguientes:
 

1 - Colocamos en cada posición de la última línea de la pantalla, el primer o el último color de nuestra paleta fuego, que si habéis seguido hasta aquí mis indicaciones se deben corresponder con el color negro o un amarillo anaranjado. Este pequeño conjunto de valores lo podemos considerar la chispa de nuestro fuego virtual.

2 - Aplicamos el filtro average a la pantalla (real o virtual). El filtrado será semejante al realizado en el programa anterior pero con dos salvedades: que la media aritmética calculada para un punto no se sitúa en esa situación sino que se pone en la línea superior (elevando el fuego) y que al valor calculado habrá que restarle una constante (atenuación del fuego)

3 - En el caso de utilizar pantallas virtuales cómo en el ejemplo aquí realizaremos el volcado de la pantalla.

4 - Volvemos al paso 1


Cómo habréis visto en estos pasos. En cada iteración del bucle se realiza: un proceso en la última línea, un filtro average a toda la pantalla y un volcado de la imagen, todos estos pasos consumen tiempo y si este es elevado nuestra fogatilla perderá 'toa la grasia' y la vivacidad.

La solución es la de siempre 'trabajar con 0s y 1s', uséase en ensamblador, para optimizar el código. Para este efecto no he querido complicar en exceso el programa y mi objetivo en este, como en el resto de demostraciones del CPV, no es alardear de conocimientos, ni hacer programas óptimos y suntuosos, sino todo lo contrario simplificar los procesos para que todo el mundo coja la idea y a partir de ahí que cada uno se curre la optimización de sus aplicaciones. ;) Os propongo esto último como una de vuestras demandadas tareas, la situaremos en un nivel de dificultad 3. }:))))

La solución que utilicé yo para acelerar el programa evitando optimizar el código fue sencilla:

- Primero. No trabajar a pantalla completa y utilizar sólo parte de la misma para reducir el número de puntos a filtrar.

- Segundo. En vez de trabajar en base a pixels, trabajar en base a conjuntos de pixel (5x5 por ejemplo) para disminuir de la misma forma el nº de elementos a procesar.

- Tercero. Al calcular la media aritmética para el filtrado de imagen utilizar algunos (5) de los puntos que rodean al elemento procesado en vez de usar los 8 colindantes.

- Cuarto. Al volcar la pantalla virtual a la real, mover únicamente la parte animada de la imagen.

Realizando todos los pasos anteriores, nos quedará una fogatilla muy mona, que al no ocupar toda la pantalla nos permite utilizar el resto de la pantalla para visualizar un fondo. Este, no debe interferir en el proceso de animación y así, sin ralentizar nuestro programa, conseguiremos adornarlo.

Bien, a continuación os presento el programa demostración dónde aunque parezca mentira siguiendo todos los pasos que os he comentado se consigue un efecto cómo el siguiente:

Pulse F2 para ejecutar el programa FX-Fueg2  - Posibilidad no disponible en la versión HTML-

Pues esto se acabo, con la demostración dejaremos el tema del fuego virtual porqué esto empieza a oler a chamusquina. Todavía no sabemos que efecto trataremos en la próxima lección pero lo que os garantizo es que las posibilidades que estamos barajando son todas interesantísimas, lo veremos entonces. :)


3.9.- 3D - Tipos de coordenadas.


- Por José Miguel Espadero -

Todo el mundo sabe que los objetos en la realidad tienen 3Dimensiones. A las imágenes generadas por un ordenador simulando estas tres dimensiones se las llama tridimensionales o más comúnmente 3D. Dentro del campo de los gráficos por ordenador, cada una de estas figuras se denomina un modelo 3D. El proceso de creación de un modelo 3D se conoce como modelado y si además a tales modelos se les añaden características que no son exclusivas de su forma, tales como sombras, reflejos, texturas, etc.. se dice que estamos aplicando un proceso de acabado o Rendering.

Es importante reseñar que el acabado es un conjunto de técnicas que se aplican a objetos ya modelados, por lo que dejaremos las mismas para los últimos capítulos del curso.

Aunque existen en el mercado programas bastante buenos capaces de generar modelos 3D (como el POV o Persistence Of Vision) se tratará en el curso de explicar los conceptos básicos de forma asimilable por todos y se rehuirá el uso de tales programas, como viene siendo común en la filosofía del CPV.

Así pues seremos nosotros quienes programemos todas las técnicas explicadas y también toda una serie de programas que nos ayudarán a generar los modelos 3D de forma automática, así como a transformarlos en modelos distintos mediante fórmulas matemáticas del nivel de COU (ya puedes ir desempolvando el libro). :)

La codificación de todas las técnicas se hará en Pascal, como viene siendo habitual en el resto de las lecciones, pero al contrario que estas nosotros usaremos las funciones gráficas avanzadas de los BGI, pues no podremos detenernos a codificar funciones complicadas como FillPoly, que será la función usada por excelencia a partir del trabajo con caras.

La forma de trabajar estará basada en Orientación a Objetos, pero no se usarán las funciones del Borland Pascal por considerarse del todo fuera de nivel.

El orden en que se tratarán los objetos será el clásico en matemáticas:

     Punto -> Segmento de Recta -> Cara -> Poliedro -> Modelo 3D.

Aprenderemos a tratar cada uno de estos elementos y representarlos por la pantalla. Posteriormente aprenderemos como se agrupa cada elemento para generar el siguiente de la lista y programaremos demos orientadas a su uso por separado, pero siempre necesitando de los elementos anteriores y las fórmulas aplicadas a estos.

Al final seremos capaces de generar tanto escenas en 3D como animaciones en tiempo real (generando los modelos que intervienen en ellas) y también a capturar los gráficos de la pantalla para tratarlos posteriormente como sprites y acelerar al máximo la velocidad de presentación.

En cuanto a requerimientos, en los gráficos por ordenador hay una máxima que tiene especial aplicación en el campo 3D : Cuanto Más Mejor. Sin embargo todos los programas funcionarán (aunque no a velocidad aceptable) en cualquier 286 con una VGA color y un par de megas de disco duro. Lo de la velocidad tiene su explicación : Todas las operaciones de proyección 3D necesitan ser en Punto Flotante, o Real, o como queráis llamarlo, pero son lentas para cualquier ordenador sin coprocesador (la verdad es que hay que estar un poco chalao para dedicarse a 3D sin tener 80x87 correspondiente).

En las lecciones del curso se necesitarán imágenes para clarificar los ejemplos, que se activarán como si se tratasen de demos (con la tecla F2).

Y hablando de demos...

Pulse F2 para ejecutar el programa DEMO3D  - Posibilidad no disponible en la versión HTML-

Bueno, una vez que ya habéis alertado a todos los vecinos, empecemos el tema de las 3D hablando sobre los Tipos de coordenadas.

Para poder representar los puntos, que son los elementos más básicos de nuestra escala, nos referiremos a ellos mediante sus coordenadas. Si alguien os pregunta cuantas coordenadas tiene un punto 3D, seguro que vosotros no tardaréis en responder que tiene tres (muy listillos...), pero si la pregunta es como representar estos puntos sobre la pantalla, seguro que a la mayoría de vosotros le parecen que son demasiadas para tratarlas.

Por ello distinguiremos tres clases diferentes de Coordenadas:
 


    O,P  -> Coordenada X                M  -> Visualiza los ejes
    Q,A  -> Coordenada Y                N  -> Representación alámbrica
    8,2  -> Coordenada Z                B  -> Tabla de coordenadas
    S,F  -> Angulo de deriva
    F,C  -> Angulo de caída
    X,P  -> Angulo de balanza           ESPACIO -> para Salir

Pulsa F2 para ejecutar el programa Miron. - Posibilidad no disponible en la versión HTML-
 


Bueno, pues resulta que mediante "simples" funciones matemáticas vamos a obtener por fín cualquier punto 3D, sobre la pantalla (y en el color que queramos además), con lo que parecería que habríamos terminado con el primer problema, pero...

Pero resulta que hemos pasado de un modelo totalmente teórico a otro físico "a lo bruto", olvidando que los pixels de la pantalla no son cuadrados ni redondos ni nada parecido, con lo que los modelos se ven estirados verticalmente:

Pulsa F2 para ver un "cuadrado" sobre el monitor. - Posibilidad no disponible en la versión HTML-

No se vayan todavía señores: que la solución está de nuevo en el mismo libro (para aquellos que sigan sin buscarlo: "eres más cabezón que el mirón"). Si hacemos un cambio de variable desde nuestra pantalla rectángular, de vértices (0, 0)-(GetMaxX, GetMaxY), a otra pantalla (0,0)-(800, 600), resulta que la segunda tiene proporciones 800:600 = 4:3, que es la misma que la de la pantalla de vuestro monitor, luego seguro que un cuadrado expresado en coordenadas 800 x 600 se ve cuadrado (y un circulo redondo), sin importar el modo en que estemos trabajando.

Los modos gráficos con más resolución tienden a poseer coordenadas con la relación 4:3, como el 640 x 480 o el 800 x 600, pero estos modos nos darán pocos colores cuando nos metamos en procesos de acabado y además, harían que al pasar programas 3D de un ordenador a otro los modelos se viesen más pequeños en un 800x600 que en un 640x480, o que imágenes que se ven en el 800x600 caigan fuera de la pantalla en el 640x480. Así pues: Nueva resolución de nuestra pantalla = 800x600, aunque se trate de una CGA o Hercules ¿OK?.

Y ya puestos a cambiar variables, ¿por qué no hacer coincidir el hasta ahora marginado punto (0,0), que al fin y al cabo es la casa de nuestra mascota, con el centro de la pantalla?. Pues como soy muy bueno os doy las fórmulas de marras:

             SX := round ((X+399)*(GetMaxX/800));
             SY := round ((Y+299)*(GetMaxY/600));

Con lo que conseguimos una traslación al rectángulo (-399,-299) - (400,300), base a la cual me referiré en todo momento a partir de ahora.

Estas fórmulas se deberán aplicar a cualquier punto del que tengamos sus coordenadas de pantalla. Como la relación GetMaxX/800 permanece constante mientras no cambiemos de modo gráfico, lo más inteligente es meter ambos 'factores de proporción' en sendas variables tipo Real, para no perder la exactitud que necesitaremos en todo momento, de forma que sólo se calculen al iniciar el modo gráfico y nos den unos milisegundillos de oro en tiempo de ejecución.

Pulsa F2 para ver un cuadrado sobre el monitor en coordenadas 800 x 600. - Posibilidad no disponible en la versión HTML-

>-------------------------------- Cortar aquí -------------------------------<

Bueno espero que os haya gustado este artículo de Jose Miguel, a nosotros por lo menos nos ha encantado. Si queréis poneros en contacto con el autor podéis dirigiros a su dirección o a cualquiera de las nuestras, en este último caso le haremos llegar vuestras cuestiones inmediatamente.

José Miguel Espadero   a920352@zipi.fi.upm.es

Dirección de JASM-BMP  Pulsa F4


3.10.- El juego del mes.

Aliens.


Para este número hemos decidido realizar una versión de un videojuego hiperconocido. Aliens invaders está basado en una de las creaciones pioneras en el mundo de las máquinas recreativas llamada Space Invaders. En este juego controlabamos a una nave espacial que se enfrentaba en solitario a infinidad de ordas enemigas.

Aliens invaders es una versión CPVriana con la que hemos intentado representar, lo más fielmente posible, el desarrollo de la máquina original.La idea del juego original era muy sencilla y adictiva, prueba de esto último es que todavía se sigue viendo el Space Invaders en bastantes salones recreativos. Simplemente se trata de superar, una tras otra, a distintas formaciones enemigas que van apareciendo en una pantalla estática. Nuestra nave se podía desplazar de izquierda a derecha por el fondo de la misma y disparar, un único disparo cada vez, contra las escuadrillas enemigas que se separaban de la formación general para intentar alcanzarnos con sus disparos o chocar contra nosotros.

El juego es simplemente esto e implementarlo en un PC no es una tarea excesivamente difícil. Se trata de manejar algunas rutinas de visualización de sprites, de control de teclado rápido, de sonido background por el speaker control de joystick y control de colisión. Todas estas técnicas ya han sido explicadas en el CPV y la dificultad estriba unicamente en saber 'arrejuntar' todo el código para que funcione el invento.

En esta ocasión el lenguaje que hemos utilizado para programar el juego es C. Además de esto, solicitamos ayuda a nuestro grafista para realizar una 'pequeña' presentación. Con todo ello nos ha quedado un juego bastante completito que esperamos os guste. El manejo es simple tenéis la opción de utilizar el joystick, el teclado o si sois muy habiles los dos a la vez ;-). El sonido se puede desactivar con la tecla F1. El juego consta de 10 niveles, a ver si os lo terminais....

Pulsa F2 para ejecutar el programa Aliens Invaders - Posibilidad no disponible en la versión HTML-

Los que no hayáis solicitado la lección por correo, habréis visto que no están disponible los fuentes del programa. Espero que captéis la indirecta y os animéis a colaborar con el CPV de cualquiera de las formas ya comentadas, bien realizando artículos, programas, traducciones... o bien solitando las lecciones por correo por 500 pelillas. El caso es participar de alguna manera cohones.... ;-)
 


3.11.- Y este cuento se acabó.

En este apartado final comenzaremos resumiendo todas las tareas propuestas en los artículos de la lección y añadiremos algunas más que se nos han ocurrido:

          Tarea                      Dificultad        Artículo relacionado

 Protector de pantalla para DOS          2             Retrazado vertical
 Proceso demonio para la IRQ 2           4             Retrazado vertical
 Animaciones para el modo 13h            1                  Modo 13h
 Técnicas para detectar colisiones       3             Algoritmos de colisión
 Optimación de los programas fuego       3              Efectos Especiales
 Traducciones C-Pascal Pascal-C          1                    CPV

Otra tarea de dificultad 0,1 que podéis hacer es enviarnos la siguiente encuesta. (con las respuestas claro) ;). Además de ayudarnos, ya sabéis, participaréis en el sorteo para la lección 4.

        1. ¿Cómo te enteraste de la existencia del CPV?
             A - A través de un amigo
             B - Vi un mensaje en una BBS
             C - Lo vi anunciado en el teletexto de TVE
             D - Me entere a través de las News de Internet
             E - Un chico alto y moreno me dio un diskette con las lecciones
                 me dijo que lo distribuyera y yo me quede con el diskette.

        2. Si NO eres tu uno de los 50 afortunados de la letra E anterior
           ¿Cómo has conseguido la lecciones del CPV?

        3. Sobre la nueva forma de distribución ...
           ¿Que te parece?
           ¿Cómo la llamarías ;-)?

        4. El precio de 500 pesetas con el que se puede conseguir cada lección
           por correo ¿Lo consideras acertado?

        5. De lo visto hasta el momento en las lecciones...
           ¿Qué es lo que te gusta más?

        6. ¿Qué es lo menos bueno?

        8. Sobre las futuras lecciones del CPV....
           ¿Que tema de los expuestos al comienzo esperas con más impaciencia?

        9. ¿Que temas añadirías o cuales te gustaría ver ampliados?

       10. Observaciones generales sobre el CPV

Bien antes de despedir esta tercera lección recapacitemos sobre que ha sido el CPV hasta el momento y que temas han sido (mejor o peor) comentados:

   Teoría general     Perif. de entrada          Speaker          Modo 13h
  ----------------   -------------------    -----------------  --------------
  Hardware del PC           Teclado          Speaker básico        Puntos
  Prog. de sistemas     Teclado avanzado    Sonido background     Sprites
  Teoría del sonido          Ratón           Timer 8253/8254   Téc. Avanzadas
                            Joystick

   Form. gráficos     Efectos especiales         Varios            Juegos
  ----------------   --------------------   ------------------  -------------
         PCX            Paleta gráfica      Alg. de colisión       Dardos
                         Fuego virtual       Caracteres VGA      Marcianitos
                                            3D - Coordenadas

  Nº de artículos técnicos         : 21
  Nº de programas demostración     : 32
  Tamaño de artículos              : 270 Kb
  Tamaño de fuentes                : 310 Kb
  Tamaño de programas y gráficos   : Más de 2.5 Mb
 

Como veis es bastante grande el esfuerzo que hemos hecho y también consideramos el resultado más que notable. Si queréis que se añadan más artículos a estos apartados y que se creen nuevos cómo el Modo X, Soundblaster , Scrolling, RayTracing, Comunicaciones, mas formatos gráficos, más efectos especiales, lo tienes fácil, solicita las lecciones por correo y/o colabora con los autores

Para terminar nos gustaría dar las GRACIAS a todas las personas que están colaborando con nosotros en la producción del CPV:

 


[ Anterior | Índice | Siguiente ]

La última versión de este texto se podrá encontrar en Internet, en la dirección:
www.nachocabanes.com