Soy un ignorante del Spectrum, así que seguramente esto que voy a decir es un disparate, pero por si acaso lo suelto. El caso es que más de una vez he oído comentar que el Spectrum tenía 8 colores, pero tiene un bit de brillo que permite pintar esos 8 colores más brillantes y así tener 16. La pregunta es: ¿No se podría usar eso para tener 2 tonos de rojo distintos, uno para el tronco y otro para las tortugas?
La diferencia entre brillo sí y no es demasiado sutil como para que destaque uno sobre otro. Los 16 colores (15, porque el negro no presenta brillo) por hardware pueden convertirse en 255 colores por sofware, ya que si pones píxeles 1 y 0 muy cercanos entre sí, y los 1 los colores con rojo p.ej. y los 0 con amarillo, obtienes un naranja virtual.
Voy a intentar hacer así los troncos a ver si consigo un color marrón más o menos guay.
En cuanto al tema de optimización y C vs lenguaje de ensamble, a día de hoy lo más recomendable es escribir en C el grueso de los programas y optimizar únicamente en lenguaje de ensamble las rutinas que más tiempo de CPU consumen. Por ejemplo, no tiene mucho sentido invertir el tiempo extra que requiere programar los menús en lenguaje de ensamble, ya que no habrá diferencias apreciables de rendimiento y además los menús son un elemento en los que no pasaremos casi tiempo.
Tienes razón, lo que pasa es que al principio esto lo utilicé para crearme mis librerías en ASM personalizadas, y una de ellas es la de hacer menús. Yo sólo tengo que enviar posiciones, textos y colores, y los menús se hacen en 20 segundos. Sí, a lo mejor C también y así no tendría ni que haberme hecho mis librerías, pero entonces no aprendo, no sé cómo van las tripas de todo esto. El proyecto es sobre todo para aprender yo a hacer un juego. ;-)
Por otro lado, como decía el gurú de la optimización Michael Abrash en su libro \"Zen of Code Optimization: The Ultimate Guide to Writing Software That Pushes PCs to the Limit\", más importante que programar en lenguaje de ensamble es diseñar (o re-diseñar) inteligentemente los algoritmos. Michael Abrash afirma que mientras que pasar una rutina de C a lenguaje de ensamble puede conseguir factores de mejora como mucho de 10 (lo cuál está muy bien), un rediseño inteligente de un algoritmo puede conseguir mejoras en un factor de 100 o más. Un ejemplo perfecto es lo que comentas Bubu de cómo vas a hacer el scroll al pixel de los troncos, evitando andar trasteando con desplazamientos y más instrucciones. Rediseñando de manera inteligente el algoritmo (independientemente de en qué lenguaje programes) has logrado una mejora que seguro es mayor que si pasases de C a ASM una rutina con desplazamientos.
Y aquí viene mi principal poblema del frogger. Actualmente tengo implementado el algoritmo \"preshifted\", es decir, los gráficos los almaceno en memoria desplazados uno a uno los píxeles, porque en su momento vi que 48KB daban para esto, y como hay demasiadas figuras que desplazar (muchos coches en la carretera, muchos troncos y tortugas en el río), pues este algoritmo es el más rápido para ello.
Pero cuando la rana se suba a un tronco, tendré un sprite sobre otro, y por tanto van a parpadear (murrápido).
Por eso quiero probar (por probar) otro algoritmo aunque sólo sea para el río, el de ir shifteando online.
Después de este tocho, en cualquier caso, el proyecto es relativamente sencillo, lo suficiente como para hacerlo por entero en ASM, así que si el tiempo no es un factor que te escasee, pues tampoco hay problema en hacerlo en este lenguaje.
Uy, ahí está el tema. Tengo hijos, trabajo inteso y de muchas horas, etc, y tiempo es de lo que menos tengo. De hecho me pongo sólo a partir de las 12 de la noche, y suelo acabar entre la 1 y las 2 de la noche, porque a las 6.50 estoy en planta todos los días.
De todas formas no me parece tan sencillo, máxime cuando el Spectrum tiene una velocidad que te puede limitar el desplazamiento de los sprites. Ahí es donde reside el mayor handicap. Fíjate que la mayoría de los juegos comerciales tienen muy muy pocos sprites simultáneos desplazándose de pixel en pixel.
Salu2, y gracias por tus comments, nunca considero disparates cosas así :-)
