Aún más ansiedad 
Solo 2 preguntas:
- sabemos que el juego saldrá en formato cartucho con un adaptador para CPC estándar y la serie Plus, ¿es correcto?
- ¿Hay una versión digital planeada para emuladores o sistemas FPGA?
18 Me gusta
Otra vez, pura porquería generada por IA…
:Tirado en el suelo llorando:
1 me gusta
¿No hay 4 jugadores en la misma pantalla? Devuélvanme el dinero que todavía ni me había gastado…
Rhino, de verdad que me he quedado sin palabras.
Mi más sincero RESPETO para ti en lo personal y para todos los que formaron parte de esto.
Empezando con Batman Forever en 2011, de verdad le has dado una nueva energía a la comunidad de CPC de tantas maneras.
¡Muchas gracias!
3 Me gusta
El juegazo ya está aquí, tal como se prometió.
Muchas gracias.
1 me gusta
Solo puedo decir:
pero qué cojones.
1 me gusta
A falta de verlo en CPC real, se muestra impresionante, ya queda menos 
2 Me gusta
¡Simplemente impresionante!
1 me gusta
¡¡¡Simplemente i n c r e í b l e!!!
1 me gusta
Se ve impresionante, pero ¿por qué pusiste a la máquina de generar bazofia (slopmachine) a hacer ese tráiler tan cutre?
Treinta segundos de vídeo funcionando en hardware real habrían sido aún más eficaces.
1 me gusta
el viejo cascarrabias va a refunfuñar 
No me convence lo de World Racing en el título. Real Racing Simulator suena mucho mejor. Y ya que estamos, ¿por qué no añadir Gran antes de Vespertino? ¡Ahí está! ¡Lo hemos clavado!
¡Dios mío, imagínate una versión en un cartucho estándar de Plus, con control total por mando, jugable en una GX4000 modificada a 128K 
! ¿Te lo imaginas?
1 me gusta
Vídeo interesante. Parece confirmar mi intuición.
A continuación, mis intuiciones y conjeturas. No pretendo juzgar ni restar méritos. El resultado es muy impresionante. ¡Bravo!
La estrategia general, en mi humilde opinión, tiene dos ejes
El Z80 no tiene caché de instrucciones. Cada instrucción cuesta mucho (en comparación con el i386 y posteriores, donde las instrucciones ejecutadas muchas veces dentro de un bucle pequeño son mucho más rápidas). El código Z80 rápido es aquel que tiene menos instrucciones ejecutadas por byte escrito. Por lo tanto, una regla de oro para la optimización de código en Z80 es: eliminar todas las instrucciones que no escriban bytes en el destino. Eliminar (desenrollar) bucles. Es sorprendente todo lo que puedes quitar si llevas este enfoque al extremo. De hecho, fue explorando estas ideas al límite como conseguí programar Sunny Day (for A Shadow Party) :: pouët.net
Una estrategia extrema de compensación entre memoria y CPU. Normalmente, el CPC no tiene suficiente memoria para llevar esta estrategia al extremo. Si cuentas con una ROM externa tan grande como quieras, puedes ir aún más lejos. Más detalles a continuación.
Detalles
Mirando el vídeo fotograma a fotograma con lupa, se aprecia que los coches se dibujan con granularidad de byte. El ancho se amplía a izquierda y derecha a saltos de dos píxeles. Cuando uno de ellos no se desea, es gris. Es invisible en los tramos grises de la carretera y visible en el resto. Esto permite rutinas de dibujado más sencillas y rápidas: limitarse a escribir bytes, sin máscaras ni manipulación de bits.
Aun así, se necesita una rutina de dibujado extremadamente rápida. Aplíquese la regla de oro anterior.
Si el coche no se mueve arriba o abajo (en particular el coche del jugador), la rutina es aún más simple y rápida.- Llevar estas decisiones al extremo, cueste lo que cueste en almacenamiento. Por eso esto solo funciona con un cartucho ROM. Se necesitan áreas enormes (de solo lectura).
Los enormes coches que giran en la pantalla de selección son simple compresión delta. La mayoría de los píxeles no cambian y las modificaciones se conocen de antemano, lo que hace que todo vaya rapidísimo. Cuando tienes un montón de bytes de ROM disponibles, simplemente haz eso. Nuevamente, es similar a Sunny Day (for A Shadow Party) :: pouët.net, donde el conjunto de bytes realmente escritos es n veces menor de lo que parece (si mal no recuerdo, n=6).- Todos los elementos animados se dibujan mediante «gráficos como código». El renderizado no llama a una rutina genérica de «dibujar algo» pasándole unos «datos específicos». En su lugar, «dibujar algo» consiste en llamar a una rutina especializada (por ejemplo, una rutina para cada coche en cada orientación concreta, una rutina para cada objeto a cada distancia). Las rutinas son código Z80 pregenerado, conceptualmente muy simple: solo escribir bytes, sin bucles ni nada de nada. (La técnica no es nueva, se ha usado en varias producciones. Yo la utilicé para las cosillas de las transiciones de nivel en Just Get 9).
- Una pista reveladora de la estrategia de «una vez que asumes que dispones de una ROM enorme, no pasa nada por tener necesidades descomunales de ROM» es la cantidad de vistas de cada objeto. En el vídeo, los autores afirman tener más de 5000 sprites. Cuando tienes una barbaridad de bytes y puedes generar miles de sprites renderizando el modelo digital de un coche, hazlo. El resultado es una representación increíblemente fluida y agradable de las posiciones 3D de los coches en la carretera.
Supongo que esto también se aplica al dibujado de la carretera. Tener una lista enorme de rutinas especializadas que simplemente dibujan una sección horizontal completamente terminada de la carretera. Llamar a la rutina adecuada para cada línea. Será más rápido que el ya de por sí veloz Chase HQ, que dibuja secciones toscas y luego las retoca para las líneas blancas de los carriles. Esto es, lógicamente, más complejo que un patrón repetitivo como el de Sub Hunter, y aun así ese juego demuestra que se pueden animar de forma fluida áreas enormes de la pantalla escribiendo (haciendo push de) bytes directamente.- También doble búfer, pero no para toda la pantalla. Una pantalla con sobreexploración (overscan) completa ocupa 24 KB de bytes útiles. Con ajustes específicos del CRTC y quizás alguna división de pantalla, esos 24 KB se pueden «empaquetar» (dejando el resto de la memoria no demasiado fragmentada). Dos búferes suponen 48 KB. Queda un área completa intercambiable de 16 KB para la conmutación de bancos (bank switching). Conmutas entre las infinitas páginas para acceder a la ROM física del cartucho. Incluso el código se puede replicar en las ROM.
Y… no estoy seguro al 100 % de que esto lo cubra todo. Quizá (probablemente) haya más secretos.
3 Me gusta
¡Muchas gracias por tus palabras!
1 me gusta
Un análisis interesante, ¡no diré si es acertado o no!
Pero tengo una pregunta… En este tipo de juegos, el ancho de la carretera suele ser mucho mayor que el ancho de la pantalla visible, ya que la carretera se desplaza a medida que te mueves lateralmente. ¿Las rutinas que propones, que dibujan cada línea horizontal, renderizarían únicamente el área visible? De ser así, ¿cuántas rutinas se necesitarían por cada línea horizontal para lograr un desplazamiento horizontal a nivel de píxel (pixel scrolling)? ¡Gracias!
Esto es sencillamente alucinante, va más allá de cualquier expectativa. ¡Simplemente increíble!
Felicitaciones a todo el equipo por este desarrollo tan fenomenal.
¿Habrá debates en el futuro sobre algunas de las técnicas utilizadas en el juego?
1 me gusta
Cuando escuché que el juego iba a usar miles de sprites prerrenderizados almacenados en ROM, supe que tendría una fluidez de escalado y rotación superior a cualquier cosa que se hubiera intentado antes, y al verlo por fin en movimiento, no decepciona en absoluto. El CPC puede hacer cosas impresionantes si le metes un montón de memoria, pero requiere muchísimo trabajo aprovecharla bien.
Lo que realmente me ha impresionado es el nivel de cuidado y atención que se le ha dedicado a la interfaz, los menús, etc. Esta es una parte del desarrollo de videojuegos que consume mucho tiempo y no siempre es divertida, pero aquí todo se ve sumamente pulido y con un diseño coherente que une todos los elementos.
Con semejante nivel de esfuerzo, solo queda esperar que la jugabilidad esté a la altura de su apartado visual. Veo bastantes coches en pantalla al mismo tiempo, lo cual es muy prometedor. No han escatimado en los coches rivales.
4 Me gusta
Bueno, ¿tú, el maestro programador del Batman Group, me estás haciendo una pregunta sobre programación? Seguro que hay truco. 
Y efectivamente, no he hecho ningún cálculo, por eso también escribí estratégicamente «un porrón de bytes», lo que aporta una conveniente «ambigüedad».
Vale, déjame pensar e intentar responder a tu pregunta. Tener rutinas especializadas que escriban una línea entera de carretera en todos los casos sería simple (tiempo constante, escribir 80 o incluso 96 bytes en overscan completo), pero requeriría un número extremadamente alto de rutinas. Una forma de reducirlo podría ser hacer PUSH de bytes del color del suelo desde la derecha, luego llamar a rutinas especializadas para escribir la carretera en sí y después hacer PUSH de algunos bytes más del color del suelo. Este modelo limita de algún modo el número de combinaciones, pero no puede dibujar cuando la carretera se extiende más allá de los bordes de la pantalla a la izquierda o a la derecha. Mmmh, hay otra opción que vuelve a limitar el número de rutinas, manteniendo la velocidad general rápida. ¿Qué tal una tabla en cascada de dos niveles?: para una geometría de línea dada, buscar en una lista de rutinas más cortas y llamar a estas rutinas. Tienen valores de bytes precalculados para dibujar todos los píxeles y su número es mucho menor. Esto cubrirá incluso situaciones en las que la línea de la carretera se extiende fuera de la pantalla por la izquierda y la derecha, sin cálculos en tiempo de ejecución. ¿He acertado, @Rhino ?
(atención, chiste a la vista 
) Giro inesperado: a lo largo de los años los teasers de Vespertino eran falsos, los autores preguntan a la gente en el foro, recopilan sus respuestas a lo largo de los años hasta que exista una IA lo suficientemente potente, para meterle las respuestas y sacar el trabajo real. 
Es broma. 
Volviendo a la realidad: ¡felicidades a todo el equipo por esta impresionante prod!
¡Después de todo este tiempo y tantos teasers, tengo muchísimas ganas de ver y jugar por fin a Vespertino!
1 me gusta