Vie Mar 11, 2011 11:35 am
Volviendo al programa:
Cuando algo no me convence del todo, lo mejor parar y recapacitar.
Muchos puntos del codigo no son optimos para el funcionamiento actual, pero son suficientemente validos para no modificarlos (a veces los proyectos mueren por el esfuerzo de mejorar algo que vuelve inestable el programa por semanas, te hace perder interes)
Casi todos estos "no me gusta pero no lo toco" nacieron en el cambio a doble-buffer real:
Al principio, era un falso doble-buffer, cada uno era independiente del otro. A efectos practicos, por el sincronismo con el haz de electrones unido a querer 50fps, era inutil. Eso si, sorprendia el efecto "dos mundos en uno": durante unos dias, al pulsar espacio, se cambiaba el buffer visible en pantalla. Cada buffer tenia sus propios bobs y mapa, y conseguias un cambio INSTANTANEO de juego, mientras que el otro seguia funcionando independiente en el "background". Era como cambiar de canal, cada pelicula seguia emitiendose, y tu elegias que querias ver. Chulo, pero inutil.
Al pasar a doble-buffer real surge un problema: las acciones se propagan en el tiempo! Algunas, antes inmediatas, ahora pueden durar CUATRO FRAMES!
ENCIMA, LA ACCION PUEDE HABERSE CANCELADO POR LA LOGICA-INTERACCIONES DEL JUEGO EN CUALQUIERA DE ESOS FRAMES! ESO IMPLICA QUE CIERTAS SUBACCIONES DEBEN REALIZARSE DE TODAS FORMAS, PERO OTRAS NO!!
Peor aun, determinados valores han de ser "copiados" al "otro buffer", mientras que otros no (ejemplo tonto: si en un frame un sprite se movio a la derecha, al empezar el siguiente frame, en otra memoria, debemos moverlo para igualar, y, si corresponde, añadir el movimiento extra del frame en curso... pero la posicion de memoria donde debe reponer el fondo, NO ha cambiado aun... es confuso a veces)
Si le unes que este juego tiene scroll, no es de pantalla estatica, te puedes volver loco con las combinaciones de "movimiento sprite"-"movimiento pantalla"-"frame-buffer en el que estoy", todas propagandose a los siguientes frames... ciertos trucos se hacen muy dificiles de sincronizar, MUUUUUCHO!
A que viene todo esto? Una de las cosas que no me convencen, y que es ademas muy glotona en recursos, es la activacion-desactivacion de los sprites en relacion a la posicion de la pantalla en el mapa. Por herencia del "falso doble buffer" ahora el sistema se compone de dos controles, uno a nivel de coordenadas de pantalla, y otro a coordenadas de mapa. Ya no es necesario este doble control, y liberare tiempo (mucho). Un par de rutinas me dan miedo al eliminar el control por coordenadas de pantalla, me va a costar ajustarlas de nuevo, pero merecera la pena.
Ademas me permitira hacer totalmente reutilizable la estructura "SPRITE", varios "BOBS" podran apuntar a los mismos "SPRITES" (si no solapan en pantalla, claro) sin efectos secundarios.
Y de regalo, simplificara mucho la creacion de "BOBS" sin sprite: no son graficos moviles, son "puntos del mapa" inteligentes (disparan, dañan, dan energia, lo que sea) pero que no consumen tiempo "grafico" de dibujado-borrado, o con un consumo minimo si los quieres animar. Vamos, los cañones-pinchos-puertas-etc de toda la vida.
Perdon por el toston, es que modificar el codigo da pereza y asi me fuerzo!
y la de Ulises, también 
