Bajo un océano de bits, mes XIV

Por Javier Albizu, 20 Febrero, 2019
Dejamos esto hace cuatro semanas con los ánimos a tope y lo retomamos un poco de aquella manera.

Después de la última entrada la cosa continuó mejorando un poco. Encontré un “fuga de memoria”1 en la clase dedicada a dibujar las imágenes y fui capaz de corregirla. Me las prometía muy felices hasta que llegó el momento de gestionar los eventos2 y determinar cómo iban a ser las interacciones con la aplicación.

Hasta el momento había trabajado con el código que se encargaba de estas tareas que venía en el curso, pero a la hora de tratar de hacer cosas distintas de cambiar un valor por otro la cosa se empezó a torcer.

Me explico.

Mi bucle principal es muy sencillo:

1 - Miro todo lo que pasa en el sistema y, mientras el valor “Salir” no tenga un valor verdadero, hago lo que se encuentra definido en un bucle infinito.

2 - Pregunto si se ha pulsado alguna tecla.

3 - Se cargan las músicas e imágenes del modo de juego que tenga seleccionado.

4 - Se vuelca todo eso en la pantalla principal.
5 - Le digo que no se flipe demasiado y que no pase de las 100 pintadas por segundo.

Hasta ahora no me había hecho falta precisión alguna a la hora de controlar la respuesta del teclado. Con que al pulsar una tecla esta asignase a una variable un valor concreto me era suficiente

Sólo había un estado posible.

Pero ahora, al ir al menú en sí mismo, la cosa se complica. Tenemos tres estados posibles:

Cada vez que pulso una tecla, el valor de “opcion” (sin tilde), tendría que aumentar o disminuir en uno. Sencillo, pero no hay manera.

Y no hay manera porque el procesador es muy rápido. Entre que pulso la tecla y la suelto pasan varios ciclos de reloj y la pantalla se ha redibujado más o menos entre 4 y 10 veces (acordaos que le he dicho que, como mucho, lo haga 100 veces por segundo, pero aún así es demasiado para esta manera de gestionar las cosas). Así que, cada golpe de teclado, implica que el valor de “opcion” se incremente o disminuya en ese número.

He hecho un apaño con la función “precision” (también sin tilde)… pero no es muy precisa que digamos y sigo atrapado en este punto desde el mes pasado.
La documentación de SDL a este respecto3 no me ha ayudado mucho, el código en el que me baso tampoco. La manera que tiene de controlar el movimiento del cursor no tiene nada que ver con la mía, y no quiero copiar tal cual la suya. Como suelo decir siempre por aquí, quiero entenderlo.

Y no deja de ser una pijada. A la hora de mover bichos por la pantalla esto no importa nada porque, a pesar de trabajar con la resolución de un Commodore 64, recorrer los 384 pixels de altura de la pantalla o los 272 de anchura es una tarea mucho más sencilla de gestionar, pero quiero que esto funcione de la manera en la que lo he decidido (o rehacerlo todo, pero que todo quede como yo decida en base a unas razones que considere razonadas y aceptables).

Por supuesto, podría buscar otras librerías para hacer esto, o podría ponerme a copiar a otros. Podría dedicarme a ver los vídeos de Jonathan Blow4 o Fran Gallego5. Podría mandarlo todo a paseo y meterme con Unity 8 Bits6. Mirar como afronta estos problemas un centenar de personas pero, por más cosas que me vayan descubriendo las píldoras de conocimiento que van soltando, quiero hacerlo a mi manera.

Y no hay mucho más que decir por ahora más allá de…
Continuará.

Enlaces:

1. Memorias a la fuga

2. Los eventos
- Event
- Event loop
- Event driven programming

3. SDL y los eventos
- SDL Events
- Handling the Keyboard

4. Jonathan Blow y sus Game Engina Programmng

5. Fran Gallego
- C++: Optimizando costes básicos de acceso a memoria
- Fuentes propias de texto y código absoluto
- Volatile
- Compiler Explorer/a>

6. Unity 8 Bits

El contenido de este campo se mantiene privado y no se mostrará públicamente.

Plain text

  • No se permiten etiquetas HTML.
  • Las direcciones de correos electrónicos y páginas web se convierten en enlaces automáticamente.
  • Saltos automáticos de líneas y de párrafos.