ZONA DE PRUEBAS

Sí, torpedo, es un auténtico jaleo, pero es un jaleo que me gusta, y es que si uso una rutina que ya esté hecha (cosa que ya he intentado) primero que no aprendo, y segundo que no se adapta bien a los desarrollos de cada uno.
Lo de los "dirty rectangles" esos ya los estaba usando yo, pero nu sabía que se llamaban así. Efestivamente yo sólo memorizo el trozo de fondo sobre el que se está pintando el sprite. Cuando quiero cambiar el sprite, entóns recupero ese trozo de fondo y endiño encima el sprite.
Esa mezcla la he intentado hacer con XOR, pero queda bastante fea a mi gusto. He probado con OR y mejora muchísimo. Pero eso sí, para restaurar hay que estar redibujando el fondo como bien dices.

Yo creo que tengo ya claros todos los concestos, salvo un temita: la colisión de 2 sprites. Si A está encima de B, y B está encima del fondo, cuando cambie B voy a restaurar el fondo cuando no estaba A, y eso es un poblema. Nu sé si me explico...

Efectivamente, Bubu, podrías colocar el pintado en la interrupción, pero puede darse el caso que comenta Namek de desborde de cuadro.

Por eso te comenté unos mensajes atrás la técnica de "lista de tareas", que he visto recientemente en un juego de la 2600.

La idea es clara, pero puede ser liosa de implementar. Pero al mismo tiempo libera al programador de ciertos problemas.

La vuelvo a poner aquí: en el bucle principal te ocupas de mover y actualizar el aspecto de los sprites, dejando apuntada la tarea de pintado a la rutina de interrupción. Así lo haces con todas las partes que requieran actualizarse en pantalla.

En la rutina de interrupción repasas todas las tareas que tienes que hacer: recuperación del fondo, borrado, pintado de sprite... hasta se podría poner lo de tocar sonido. Y... para evitar lo que comentan Mamek y jitursan, de desborde de cuadro, lo que yo he visto en ese programa es que la rutina de interrupción lleva la cuenta de los ciclos (de forma aproximada) que lleva cada tarea, de tal manera que si no le da tiempo a terminar todas las tareas en ese cuadro, deja las pendientes para el siguiente cuadro.

De forma más específica: intenta realizar las tareas que se le mandan, pero sin tener que agotar todos los recursos de la CPU (podríamos tener centenares de sprites en la pantalla, pero apenas tendríamos tiempo para actualizar sus posiciones/colisiones). Si no hay tiempo, se deja para la siguiente interrupción. La consecuencia es que hay momentos del juegos en que los sprites se actualizan a 50 cps, pero en otros momentos baja a 25 cps o incluso 20 cps. Mientras el motor de juego se ejecute a una velocidad constante, no importa "mucho" que de vez en cuando algún sprite aparezca "roto" por algún sprite que pase por encima de él.

El caso más especial e impresionante que he visto de este truco es el juego de arcade Defender.

Si lo arrancas con el MAME, pulsas el tabulador para sacar el panel de control, vas a "Slider control" y le subes el Overclock CPU a 140 % o incluso más.

En una situación normal, cuando el procesador se queda sin tiempo para pintarlo todo (creo recordar que había un límite de 60 elementos gráficos en pantalla), lo que hace es "teletransportar" a los enemigos que no le da tiempo a pintar "al otro lado" del escenario, que es un truco que suelen usar los jugadores más profesionales: cuentan que muchos enemigos desaparecerán en situaciones de más estrés de la máquina.

Pero... aumentando la velocidad de CPU, el resultado es espectacular. El juego no va el doble de rápido. Lo que vemos es que le da tiempo al procesador a pintar todos los detalles, y por lo tanto, no desaparecen los sprites, y el juego se vuelve mucho más fluido (y difícil, al no desaparecer los enemigos).

Bubu escribió:Yo creo que tengo ya claros todos los concestos, salvo un temita: la colisión de 2 sprites. Si A está encima de B, y B está encima del fondo, cuando cambie B voy a restaurar el fondo cuando no estaba A, y eso es un poblema. Nu sé si me explico...

La tecnica habitual es:

1.- Copiar los cuadros del fondo que se van a preservar antes de pintar nada.
2.- Se dibujan los Sprites.
3.- Se calculan nuevas posiciones.
4.- Se espera el barrido vertical
5.- Se recuperan los cuadros preservados para borrar los sprites, y vuelta a empezar...

De esta forma da igual si se pisan los sprites o no, aunque esta tecnica va mejor con doble buffer.

Gracias, torpedos. Voy a por ello.

Hay algo que me inquieta... Cuando en pantalla hay 2 ó más sprites, y además estos pueden colisionar, hay que tener un buffer del background COMPLETO, ¿nor? Pienso que así por lo siguiente: si sólo guardo el trozo de background donde tengo mis sprites, entóns, cuando un sprite se vaya a mover a un cuadro donde haya otro sprite, ¿qué fondo guardo ahora?

Bubu escribió:Hay algo que me inquieta... Cuando en pantalla hay 2 ó más sprites, y además estos pueden colisionar, hay que tener un buffer del background COMPLETO, ¿nor? Pienso que así por lo siguiente: si sólo guardo el trozo de background donde tengo mis sprites, entóns, cuando un sprite se vaya a mover a un cuadro donde haya otro sprite, ¿qué fondo guardo ahora?

Ya te explique esto en un post anterior, primero se guardan todos los fondos sin ningún sprite pintado.