sobretodo los metal slug esos...
pero sin embargo creo que habrá algun arcade que otro a menos fps
Si son en consola o arcada ninguno, en ordenador es otra cosa.
No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.
It is an undisputed truth that the Atari ST gets the best out of coders. No dedicated hardware, just the CPU and a frame buffer! Some call it Spartan, others name it Power Without The Price, and a select few say `challenge accepted'! --- by spkr from smfx
En los juegos que menciono salen varios cuadros iguales seguidos (se puede comprobar capturando el vídeo). Si entre dos interrupciones de vblank el juego no termina el bucle principal, el siguiente cuadro será igual que el anterior. En el Metal Slug 2 es aún peor, porque aparte de estar capado a 30 fps, el código que lo hace está mal hecho. Aquí alguien que lo ha desensamblado y arreglado: http://daifukkat.su/blog/archives/20...ts_turbo_time/
Juegos de spectrum a 50pfs... ¿cual? Si lleva scroll yo diría que ninguno ya que no tenia scroll hardware, saquemos la calculadora.
La pantalla del scpectrum son 256x192, 6144 bytes la parte del bitmap, nada de los atributos.
Supongamos un juego que solo mueva un tercio de la pantalla (como estaba divida en tercios, bla bla....) serian 2.048 bytes, 2Kb justos.
Si queremos hacer a 50fps tendríamos que mover, 2KB x 50fps = 100Kbytes por segundo.
La cpu va a 4Mhz, 4000000 / (2048 * 50) = 39,06 ciclos de reloj para mover cada byte.
Teniendo en cuenta de que como minimo una intruccion en el z80 tardaba IIRC 4 ciclos de reloj nos salen un máximo de 10 instrucciones para cada byte, hay que tener en cuenta que un INC A, tardaba 4 ciclos pero un LD A,(HL) tardara mas por tener que leer de memoria.
Así que ... ni de coña.
Solo hay que comparar un juego de C64 con uno de spectrum en cuanto a suavidad de movimientos en los sprites y el scroll.
No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.
It is an undisputed truth that the Atari ST gets the best out of coders. No dedicated hardware, just the CPU and a frame buffer! Some call it Spartan, others name it Power Without The Price, and a select few say `challenge accepted'! --- by spkr from smfx
Drumpi (26/01/2016), futu-block (26/01/2016)
Hombre, alta velocidad tampoco . Lo cómodo del LDIR es que mueves bloques de memoria con muy pocas instrucciones (cargas BC, HL y DE con los valores adecuados, LDIR y a correr), pero tampoco es lo más rápido del mundo.
Lo más rápido que se conoce es usar directamente instrucciones PUSH jugando con el puntero de la pila, pero tiene su complicación. Aún y con eso, no conozco juegos con scroll que vayan totalmente a 50fps en un Spectrum. Con pantallas estáticas, si la memoria no me falla tenemos Majikazo (http://www.worldofspectrum.org/infos...cgi?id=0027624) y supongo que alguno más, pero pocos (¿tal vez los del Nirvana engine y similares que usan multicolor?).
Yo por lo que he entendido en la documentación de Unity, los cálculos de las detecciones de colisiones las lleva a cabo también la tarjeta gráfica, a través de la librería/motor de físicas. Por ejemplo, en esta parte de la documentación:
http://docs.unity3d.com/Manual/class-MeshCollider.html
Se hace mención que los mesh-colliders (colisiones basadas en mallas complejas) necesitan de los RigidBodys para hacer los cálculos, y estos van fuertemente ligados a la física (hasta el punto de que son los que indican que debe aplicarse físicas a ese objeto).
Otro detalle es que un objeto sin rigidbody sólo colisiona con otro objeto una vez (salvo que se den unas condiciones muy concretas, y eso no es aceptable).
Y además, sin las detecciones de colisión, no se podrían aplicar las fuerzas o los torques a los objetos de forma correcta.
Pero es eso: te dan toooooda la física ya hecha, que es lo que hace un engine, pero se mueven a muy bajo nivel, que es lo que hacen unas librerías. De ahí mi duda.
Lo que hay que entender es qué significaba "alta velocidad" para la época, porque lo mismo, esa velocidad aun era insuficiente.
PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%
LDIR es para copiar bloques de memoria pero no esta optimizado, solo ahorrabas memoria tardaba exactamente lo mismo que hacer un bucle.
-----Actualizado-----
Ademas que si quieres hacer scroll horizontal no te vale solo con hacer LDIR tienes que rotar los bytes, de hecho LDIR solo te vale para copiar el buffer interno a la memoria de pantalla ya que por la forma tan rara de ir la pantalla (por tercios y primero el primer scan de las 8 lineas de un tercio, despues el segundo scan, etc) tampoco te vale para hacer scroll vertical.
No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.
It is an undisputed truth that the Atari ST gets the best out of coders. No dedicated hardware, just the CPU and a frame buffer! Some call it Spartan, others name it Power Without The Price, and a select few say `challenge accepted'! --- by spkr from smfx
Marcadores