sgonzalez escribió:Los dos están hechos con Raster (por consiguiente chip de vídeo) y son un plano de MD, busca información acerca de la demo.
Entonces, ¿no son sprites?, ¿cuanto mantiene ocupado al motorola esa rutina?.
sgonzalez escribió:Ralph lo del juego comercial de Amiga era por ponértelo fácil, pero ya veo que tienes poco conocimiento acerca de la máquina.
A mi hablame de msx... no, bueno, ni por esas
sgonzalez escribió:El ejemplo del Turrican 3 de rotaciones, se puede ver claramente con un emulador que son sprites que hacen el giro de 360º, igual que los dragones del Flink, usad un emulador y lo comprobaréis.
¿Y un giro de 360º no es una rotación?
sgonzalez escribió:Puedo poner otro ejemplo... Arranca un Amiga 500 (misma CPU que megadrive) con el Deluxe Paint e intenta hacer zoom con una imagen y verás el tiempo que tarda el 68000 en escalar la imagen por software...verás que es posible, pero que es muy lento como para incluirlo en un juego.
Hombre, no es un ejemplo demasiado determinante. Un programa de dibujo no tiene las mismas prioridades que un juego, y bien puede darse el caso de que no sea el mejor ejemplo de optimización, porque no es tan prioritario el rendimiento, como el resultado.
sgonzalez escribió:Que os empeñais en repetir muuchas veces que con un motorola 68000 a 7Mhz en un juego se puede hacer escalado por Software.... que los programadores son unos dejados... (si los programadores os oyeran
) que sí, que hemos visto intros curiosas en Megadrive, demos que explotan el hard del Amiga 500 al máximo con polígonos, ampliaciones, zooms, etc. pero que en un juego con la CPU ocupada al máximo es muy difícil. Es mucho más viable recrear un sprite en múltiples posiciones y tamaños que escalarlo con una cpu tan lenta.
La escena del flink en la que aparecen los dragones, no ocupa al motorola al 100% ni de coña. Ni en limite de sprites, ni manejando fondos... en esa escena le queda margen, pero fijo. Viendo otros juegos en los que hay acción frenética, y objetos por todos lados moviendose sin parar, estoy convencido de que es así.
...y vuelvo al ejemplo del AoF de SNES. El plano es escalado por el modo7 de su VDP (por hardware), y los sprites son escalados por el 65816 (por software). Si realmente fuese lo que tu dices, superponiendo sprites de varios tamaños, en cada uno de los frames de animación, de cada uno de los personajes, con 16 megas
no alcanza ni de coña, y lo sabes.
Hacer eso con los sprites es un trabajo de chinos, a parte de que no interesaba meter cartuchos muy gordos. Con la memoria que requeriría hacer algo así, puedes sacar un street fighter de 200 personajes, y sin despeinarte xD
Alguien puso una vez un gif de todoh haciendo scaling (sin escenario ni nada, solo el personaje, ampliado, y en camara lenta). La rutina de escalado es un pelín rudimentaria, pero deja ver la suavidad con la que escala los sprites... simular eso a base de superponer sprites, significa repetir al menos 15 veces cada sprite, en todos y cada uno de los movimientos de todos y cada uno de los personajes... quizás no sea el equivalente a un juego de 200 personajes... sino de 400
Además, en zoom-out se nota la "pérdida de información", es decir, hay partes de los sprites que "desaparecen". Si fuera redibujado, el detalle sería máximo en todo momento.
Si alguien tuviera a mano ese gif, se acabaría la discusión. Es scaling, y es un 65816, en un juego comercial (IA's, musicas, sonidos, 50/60 frames según región, I/O, etc).