[LA TERTULIA CLASICA 2] Pasen pasen again!!!

Final Fight es PORNO duro con actrices cañón. Es El Clásico por antonomasia, el "Benchmark" del género.

Double Dragon una película erótica de bajo presupuesto de los 60, con actrices chonis; ha envejecido fatal.
Terrible el porno ochentero petado de cirugías horribles y tetas de plástico antinaturales.

Rachel welch ftw.
Yo crecí con el Italiano de los 90 🇮🇹 Mario Salieri, Olívia del Río...

Sophie Evans también estuvo bien.

Fue poner el Plus en mi casa, y todos los Lunes hacía negocio de VHS en el recreo del Colegio.
@Sexy MotherFucker [qmparto] [qmparto] [qmparto]
Hay una ingenieria social brutal en forma de jamelgas que luego no oleremos en la vida( sin pagar en el 99% de casos xD), algo por pura estadistica al alcance de pocos, pero algo que apela a nuestos mas bajos instintos y sobretodo una herramienta para moldear la sociedad, esto no es una critica a ti, yo en tu lugar hubiera hecho lo mismo.
PD: No suicides tu cuenta, si hay que suicidar alguna cuenta, nos enviamos Mps y que parezca un accidente [beer] [qmparto]
@Segastopol hay que fusilar esta cuenta, hazme caso.

Pero se agradece el aprecio [oki]
Antes de fusilar nos debes muchos hilos que prometiste hace años de PSX VS Saturn 2D., otro hilo que prometistes de homenaje al csotn o de aquel de tu primera experiencia con un marinero...
Onil mi Pepito Grillo xD

Ya veré. En cualquier caso no me iria para siempre; volvería en forma de chapa a dar la chapa.
@Sexy MotherFucker volverás como Sexy Chaperfucker.
naxeras escribió:Las críticas a snes en el hilo oficial no son muy bien recibidas.


Me llevo este mensaje a uno mas adecuado para evitar off topics

Te confundes muchísimo, las críticas a snes campan a sus anchas sin problemas en cualquier hilo, es con las defensas a snes con las que se te echa encima el subforo como si fuese un ataque a megadrive, y no digo ya una critica a megadrive.

Si son hilos específicamente de megadrive, como el hilo del que procede este quote, enseguida te sueltan un "ya vienen", entre otra clases de reacciones.



Me sorprende que lo veais así, es justo al contrario. Literalmente me estoy llevando este tema de snes a un hilo genérico por algo, a pesar de que incluso el tema lo estais propiciando vosotros. Y aún así el tirón de orejas me lo voy a llevar yo (a pesar de que este es el hilo ON TOPIC para que los usuarios puedan feedbackear sobre la forma en que interaccionan en el sub foro para regularse un poco... que si me preguntan, creo que hace falta ese debate, encorsetais mucho a todo lo que no sea megadrive).

Sabes que es así.
Señor Ventura escribió:
naxeras escribió:Las críticas a snes en el hilo oficial no son muy bien recibidas.


Me llevo este mensaje a uno mas adecuado para evitar off topics

Te confundes muchísimo, las críticas a snes campan a sus anchas sin problemas en cualquier hilo, es con las defensas a snes con las que se te echa encima el subforo como si fuese un ataque a megadrive, y no digo ya una critica a megadrive.

Si son hilos específicamente de megadrive, como el hilo del que procede este quote, enseguida te sueltan un "ya vienen", entre otra clases de reacciones.



Me sorprende que lo veais así, es justo al contrario. Literalmente me estoy llevando este tema de snes a un hilo genérico por algo, a pesar de que incluso el tema lo estais propiciando vosotros. Y aún así el tirón de orejas me lo voy a llevar yo (a pesar de que este es el hilo ON TOPIC para que los usuarios puedan feedbackear sobre la forma en que interaccionan en el sub foro para regularse un poco... que si me preguntan, creo que hace falta ese debate, encorsetais mucho a todo lo que no sea megadrive).

Sabes que es así.


A ver Señor Ventura, no tienes pinta de mal tipo pero fanboy de SNES y un me invento teorias malinterpretando el hardware si eres un poco, yo te leo todos los post y aunque hay cosas que tienes razón otras no hay por donde cogerlas o se te ha desmentido (me viene a la cabeza cuando digiste que no se puede usar multiplexacion en megadrive para el pang porque patata).

SNES tiene cosas increibles, solo hay que ver los efectos de un chrono trigger (por decir uno) imposibles en megadrive para darte cuenta para qué se diseño la consola, cuales son sus fuertes y cuales sus puntos debiles o que tenian los creadores de la misma en mente cuando fue diseñada.

Eres un defensor acerrimo de SNES en cuanto se dice que ciertos juegos arcade hay que verlos cinemascope en la plataforma porque no da de si, haces gif falsos de que es por la relación de aspecto, estirando la versión de SNES y no reconociendo que la consola no da más en eso en concreto, o cuando piensas que la resolución no importa, o que todos los juegos de la consola no optimizaban los sprites poniendo ejemplos en personajes sin darte cuenta que tambien se usan sprites para otras cosas y por eso se decidió un 8x8 y 16x16 en vez de un 16x16 y un 32x32 (es un ejemplo).

Se que te gusta el tema pero en serio las teorias locas que dices prueba a hacer una demo ya veras como se te cae el castillo de naipes y te daras cuenta que pese a tener SNES mas del doble de catalogo que Megadrive y ser mas aprovechada esta por tanto durante su vida se ven las limitaciones que se ven.

Un Saludo y espero que no te tomes a mal el post que va de buenas.
Perdón por el offtopic, pero tengo la impresión de que se ha discutido bastante si Megadrive sería capaz de mover el Pang y me he ido perdiendo todas estas discusiones. Solo me llegan los ecos de la "batalla" xD

¿En serio hay gente que piensa que Megadrive no puede con el Pang?

La Amstrad GX 4000, una consola de 8 bits, tiene su versión del Pang corriendo a 60 fps (50 en PAL) y con opción de dos jugadores simultáneos. ¿Si una consola de 8 bits puede mover el juego, como no va a poder Megadrive? xD

Además, Pc Engine, consola que considero inferior en muchos aspectos a Megadrive tambien demostró que podía mover un Pang. Y en Amiga hay un Pang idéntico a la recreativa (o mejor)... y si se puede hacer en Amiga, se puede hacer seguro tambien en Megadrive.

Saludos y perdón de nuevo por el off topic.
Seideraco escribió:Perdón por el offtopic, pero tengo la impresión de que se ha discutido bastante si Megadrive sería capaz de mover el Pang y me he ido perdiendo todas estas discusiones. Solo me llegan los ecos de la "batalla" xD

¿En serio hay gente que piensa que Megadrive no puede con el Pang?

La Amstrad GX 4000, una consola de 8 bits, tiene su versión del Pang corriendo a 60 fps (50 en PAL) y con opción de dos jugadores simultáneos. ¿Si una consola de 8 bits puede mover el juego, como no va a poder Megadrive? xD

Además, Pc Engine, consola que considero inferior en muchos aspectos a Megadrive tambien demostró que podía mover un Pang. Y en Amiga hay un Pang idéntico a la recreativa (o mejor)... y si se puede hacer en Amiga, se puede hacer seguro tambien en Megadrive.

Saludos y perdón de nuevo por el off topic.


Me perdí esos debates, pero me parece absurdo plantear que algo tan estático y sencillo a nivel de logica (varios sprites dando botes y multiplicandose) sea incapaz de moverse en una Megadrive, ni que el pang ahora fuera el Crysis de consolas xDD

De hecho se pueden mirar millones de ejemplos en el catalogo de Mega de cosas mucho más complejas que un Pang.
naxeras escribió:(me viene a la cabeza cuando digiste que no se puede usar multiplexacion en megadrive para el pang porque patata).


Este es un poco el problema, yo no digo las cosas "porque patata", a boleo. Me puedo equivocar porque me centro en esas cosas que están dentro de la teoría, y me falta toda clase de conocimientos para llevar a cabo probarlas yo mismo, pero no digo las cosas sin un motivo real.

Me explico, multiplexar sprites en un juego cuya interacción consiste en disponer la jugabilidad verticalmente, y en el que cada objeto puede invadir cualquier zona horizontal, es un riesgo muy grande de parpadeos. No es que no puedas multiplexar en un pang de megadrive, pero es justo el tipo de juego que te lo impide bastante por diseño.

Si puedes retener bolas en la parte de arriba de la pantalla, entonces puedes multiplexarlas abajo, pero si van a moverse libremente por toda la pantalla, justo en el pang es un problema. Fíjate como en las demos de multiplexación todo se trata de filas horizontales de muchos sprites pequeñitos (o vertical de forma MUY controlada, es decir, sin un comportamiento aleatorio como son las bolas del pang), pero estamos hablando del ejemplo contrario, desplazamientos en vertical. Multiplexar impone unas condiciones muy concretas, no es porque patata.


También se habló de multiplexar los fragmentos del cuerpo de la serpiente del xeno crisis usando hdma sobre el dibujo en un plano, y se lió una buena. Resulta que está medio limitado, pero mi intuición fue buena, si que se puede si alternas fragmentos de un plano con sprites porque hay unos estados de espera, y el haz de electrones/line buffer no esperan... ¿el problema?, que era una ventajita de super nes, y, oh sorpresa, llegaron hasta los insultos. Con megadrive se puede teorizar sin espectativas de discusiones.

Tenemos que afrontar el hecho de que hay un gate keeping bastante pronunciado, y si te dejas ver demasiado llegan los señalamientos. Solo quería comentarlo porque no estoy de acuerdo con esa percepción de que las críticas a snes en su hilo oficial no son bien recibidas. Lo que si ha llegado a pasar es que han habido mosqueos por la evidencia de un doble rasero con la actitud, pero no por las críticas a la super nintendo, ni siquiera las infundadas.

naxeras escribió:Eres un defensor acerrimo de SNES en cuanto se dice que ciertos juegos arcade hay que verlos cinemascope en la plataforma porque no da de si, haces gif falsos de que es por la relación de aspecto, estirando la versión de SNES y no reconociendo que la consola no da más en eso en concreto, o cuando piensas que la resolución no importa, o que todos los juegos de la consola no optimizaban los sprites poniendo ejemplos en personajes sin darte cuenta que tambien se usan sprites para otras cosas y por eso se decidió un 8x8 y 16x16 en vez de un 16x16 y un 32x32 (es un ejemplo).


Es que snes está muy mal reconocida, no podemos negar que está muy infravalorada. Literalmente la gente cree que no tiene un rendimiento con el procesador que si tiene. Menor, no insuficiente. No es lo mismo.

No recuerdo exactamente la conversación de aquel gif, pero no hay que relacionar la ejecución del argumento con la esencia. No es nuevo que con una resolución menor, o cropeas, o redibujas para mantener la relación de aspecto a cambio de una pérdida de definición (aunque con la oportunidad de rellenar los dos márgenes superior e inferior con mas escenario que en la resolución de origen).

No se puede decir que todos los juegos de snes no optimizan el dibujado de los sprites, pero si que era muy común, y que capcom malgastaba sprites a espuertas que luego repercutían en el límite por scanline. Son hechos de facto, naxeras.


Los límites con los sprites están claros, pero todo es relativo. Tal y como está planteada su configuración de sprites resulta mas ventajosa para partículas, o condiciones de juego que le vienen mejor, como los parodius.

naxeras escribió:Se que te gusta el tema pero en serio las teorias locas que dices prueba a hacer una demo ya veras como se te cae el castillo de naipes y te daras cuenta que pese a tener SNES mas del doble de catalogo que Megadrive y ser mas aprovechada esta por tanto durante su vida se ven las limitaciones que se ven.


Creo que se puede afirmar que el 65816 recibía menos atención, y que está documentado por ahí que se programaba de forma indecuada para ella, lo cual no es precisamente aprovechar el sistema, y también que tener ¿posiblemente mas? de la mitad del catálogo underclockeando el procesador es literalmente desaprovecharlo.

Hasta donde llegué a echar un vistazo, la proporción era un 55%-45% de slow roms sobre fast roms, revisado hasta la letra F. Si extrapolas, podría haber una mayoría de slow roms, y aún que no fuese así, como mínimo si que se puede afirmar que la proliferación de slow roms fue grosera. Eso no es aprovechar un sistema.
@Señor Ventura

La Snes tendría que haber usado un 68000 de Motorola como la Megadrive, la Neo Geo, el Amiga, el System16 o el CPS. Sistemas que demostraron todos que el 68000 iba sobrado para mover los juegos de acción que vimos en esos sistemas.

Pero Nintendo por decisión de Yamauchi queria que la Snes fuera retrocompatible con NES así que optaron por el 65C816 porque era la CPU de 16 bits posterior al 6502, su evolución. Era compatible con las instrucciones del 6502 así que era estupendo para ejecutar juegos de NES. Pero al final se liaron y no pudieron hacerla retrocompatible... así que al final toda esa elección de CPU para nada.

Y mejor no hablar de la resolución de 256x224 frente a los 320x224 de Megadrive. Eso no tiene perdón de dios.

Por otro lado, la Snes es una consola excepcional, con muchísimos aspectos positivos. El colorido es increible, su paleta impresionante. El modo 7 fue una revolución y el sonido cojonudo si se aprovechaba bien y se hacían melodías específicas para la plataforma (en lugar de intentar ejecutar melodías creadas para otros sistemas).

Es una de las consolas con mejor reconocimiento de la historia de los videojuegos. Y sus juegos van a seguir siendo apreciados durante décadas. El otro día me puse otra vez con el Earhbound porque es una maravilla. Y seguro le daré caña de nuevo al Chrono Trigger porque es uno de los mejores juegos de todos los tiempos.

Así que por favor, acepta las críticas que hacemos hacia Snes de manera constructiva. No se hacen como ataque a la consola sino como análisis de su hardware, de lo que puede o no puede hacer. Y todos sabemos que puede hacer mucho.

Saludos.
Señor Ventura escribió:...Si puedes retener bolas en la parte de arriba de la pantalla...

[qmparto]
Perdona el chiste fácil, con todo el respeto, se aprecian tus aportes y se nota la pasión, en ese aspecto un 10.
Pero a veces el exceso de pasión ciega, creo que @Naxeras ha sido muy correcto.
Igual que la Super no puede con un Final Fight Md pues la Mega no puede con un Donkey Kong o los efectos que ha mencionado anteriormente el compañero, tampoco hay que hacer un drama [beer]
A mí me parece que si usas el SA1, sí podrías sacar un Final Fight MD en Snes bastante decente. Lo único que sí que no podrías igualar es la resolución, que tendría que ser 256x224 frente a los 320x224 de Megadrive. Pero podría tener mucho mejor colorido y posiblemente mejor música.

Usas el SA1, un cartuchaco de 32 megabits y Snes sí que debería poder mover ese juego perfectamente igual que Megadrive.

Otra cosa es que no se considere justo o válido usar chips añadidos en el cartucho... aunque a mí si me parece bien. Starfox es un juego de Snes aunque lleve el ChipFX, Virtua Racing lo es de Megadrive aunque lleve el SVP... pues lo mismo con el SA1 y los juegos que lo llevan.

Saludos.
Seideraco escribió:A mí me parece que si usas el SA1, sí podrías sacar un Final Fight MD en Snes bastante decente. Lo único que sí que no podrías igualar es la resolución, que tendría que ser 256x224 frente a los 320x224 de Megadrive. Pero podría tener mucho mejor colorido y posiblemente mejor música.

Usas el SA1, un cartuchaco de 32 megabits y Snes sí que debería poder mover ese juego perfectamente igual que Megadrive.

Otra cosa es que no se considere justo o válido usar chips añadidos en el cartucho... aunque a mí si me parece bien. Starfox es un juego de Snes aunque lleve el ChipFX, Virtua Racing lo es de Megadrive aunque lleve el SVP... pues lo mismo con el SA1 y los juegos que lo llevan.

Saludos.

Ojo que el SA1 no ayuda con el límite de escritura de VRAM en cada fotograma. Puede que para mostrar 7 personajes en pantalla, aparte de un SA1 habría que meter bandas negras bien hermosas XD
Seideraco escribió:Perdón por el offtopic, pero tengo la impresión de que se ha discutido bastante si Megadrive sería capaz de mover el Pang y me he ido perdiendo todas estas discusiones. Solo me llegan los ecos de la "batalla" xD

¿En serio hay gente que piensa que Megadrive no puede con el Pang?

La Amstrad GX 4000, una consola de 8 bits, tiene su versión del Pang corriendo a 60 fps (50 en PAL) y con opción de dos jugadores simultáneos. ¿Si una consola de 8 bits puede mover el juego, como no va a poder Megadrive? xD


Corriendo a 60 Frames por segundo? donde? Una consola que solo salió en el mercado Europeo???
Donde has visto funcionar el Pang de GX4000 a 50 frames por segundo??
Pero si el hack del final fight 2 y 3 ya ponen 5 enemigos en pantalla a dos jugadores con optimización made in capcom, ¿por qué no va a poder con mas enemigos a 60fps?.

El hack de tmnt in time pone 8 o 9 enemigos a dos jugadores sin problemas.
grad1us escribió:
Seideraco escribió:Perdón por el offtopic, pero tengo la impresión de que se ha discutido bastante si Megadrive sería capaz de mover el Pang y me he ido perdiendo todas estas discusiones. Solo me llegan los ecos de la "batalla" xD

¿En serio hay gente que piensa que Megadrive no puede con el Pang?

La Amstrad GX 4000, una consola de 8 bits, tiene su versión del Pang corriendo a 60 fps (50 en PAL) y con opción de dos jugadores simultáneos. ¿Si una consola de 8 bits puede mover el juego, como no va a poder Megadrive? xD


Corriendo a 60 Frames por segundo? donde? Una consola que solo salió en el mercado Europeo???
Donde has visto funcionar el Pang de GX4000 a 50 frames por segundo??

Usando un emulador por ejemplo.Puedes hacerlo correr a 60 fps. He dicho 60 fps porque es la costumbre cuando un juego va perfecto, al pixel. Y he mencionado que en PAL obviamente va a 50 fps.

En Megadrive un Pang podría ir a 60 fps NTSC y a 50 fps PAL, igual que en la Amstrad GX4000.

Lo importante era constatar que el juego va perfecto en una Amstrad GX4000. No que hubiese un Pang a 60 fps en dicha consola.

Saludos.
Señor Ventura escribió:Pero si el hack del final fight 2.


@256x224 con bandas negras Cinemascope, pero sí, los mueve. Edit: es Lorom, le concedo 4 scanlines más con una Fast XD

Final Fight MD pone hasta 6 pero @320x224 y pantalla completa. Con la paleta rompiéndose por las esquinas, pero bueno, es uno de los males de la Mega Drive.
Señor Ventura escribió:Es que snes está muy mal reconocida, no podemos negar que está muy infravalorada. Literalmente la gente cree que no tiene un rendimiento con el procesador que si tiene. Menor, no insuficiente. No es lo mismo.


Pero como que la SNEs esta infravalorada y poco reconocida jajajaja, el mundo al revés.

La SNES tiene mas del doble de juegos que Megadrive y SNES fue programada por las mejores compañias del mundo de la época, con mayor presupuesto y en general con tamaños de ROM mayores siendo SNES mucho mas explotada que la Megadrive y ganó la generación.

Megadrive en general se usaron roms mas pequeñas (revisa los tamaños y alucina) y en general fue programada por estudios de tercera categoria o directamente amateur luchando con talento vs experiencia, presupuesto, apoyo y roms mas grandes.

Hablamos de SNES una consola de la empresa mas grande de videojuegos en su época, con thirds secuestradas, siendo programada por los mayores talentos del mundo en su época, la niña bonita.

Señor Ventura escribió:Pero si el hack del final fight 2 y 3 ya ponen 5 enemigos en pantalla a dos jugadores con optimización made in capcom, ¿por qué no va a poder con mas enemigos a 60fps?.

El hack de tmnt in time pone 8 o 9 enemigos a dos jugadores sin problemas.


FFMD en SNES se puede en Cinemascope bien gordote.

A snes si quieres animar unos sprites grandotes y tal tienes que tirar de cinemascope a saco o reducir el tamaño de los sprites, todo lo demás invents.

Por cierto comparar Final Fight MD con Final Fight 2 es absurdo, los personajes de FFMD tienen el doble de animaciones o más, tienen mejor IA y son sprites mucho mas grandes, por no hablar que FF2 de SNES es cinemascope y el FFMD es full screen, y para terminar FFMD esta hecho en C de forma amateur mientras que FF2 esta hecho por una de las mejores compañias de la época en un desarrollo AAA para la niñá bonita de la generación, con mucho mas presupuesto y en ensamblador... y espero que no venga nadie con gifs estirados por favor que supongo que ya hemos superado eso.

Megadrive mueve personajes a saco pero llega al limite de sprites por scanline muy facil con los personajes tumbados por eso los de paprium subieron mucho mas el numero de personajes que FFMD pero claro no los tumban y asi evitan los parpadeos con unos sprites ENORMES y bastante bien animados en muchos casos.


Un Saludo.
Sexy MotherFucker escribió:@Baek ya que estás por aquí te aprovecho:

¿A qué frecuencia de Hz van los ARCADES de Space Harrier y After Burner?

Gracias de antemano [oki]

Perdona la espera, que últimamente no vengo demasiado.

After Burner: 320*224 59.637405 hz
Space Harrier: 320*224 60.054389 hz
stormlord escribió:


Bonita multiplexación está haciendo nuestro querido ZX Spectrum.
@Baek eres el mejor, nunca me dejas tirado [oki]

¿Ves @chinitosoccer ?

After Burner de ARCADE rula prácticamente @60fps, y Space Harrier también. Y las conversiones de Saturn también
Sexy MotherFucker escribió:@Baek eres el mejor, nunca me dejas tirado [oki]

¿Ves @chinitosoccer ?

After Burner de ARCADE rula prácticamente @60fps, y Space Harrier también. Y las conversiones de Saturn también


Claro...pero Mame, un emulador, no en la PCB original, groovymame se pasa por el forro las frecuencias de barrido originales y "adapta" todo a resoluciones cercanas a los 60hz, R-Type es otro ejemplo, la PCB original va 50hz, pero en Groovymame muestra 56hz o algo por ahi.

Tengo un monitor arcade Taxan con OSD que muestra la frecuencia de barrido en pantalla, ademas de eso utilizo un Extron RGBxi 300 https://www.thatthingyoulove.com/produc ... -interface con display, es la única forma de saber los barridos originales, olvidate de emuladores, todos estan hechos pensando en la compatibilidad con la mayor cantidad de pantallas, siendo que solo los monitores arcade tenian ajuste de sincronía y stretcheo por medio de potes.
chinitosoccer escribió:
Sexy MotherFucker escribió:@Baek eres el mejor, nunca me dejas tirado [oki]

¿Ves @chinitosoccer ?

After Burner de ARCADE rula prácticamente @60fps, y Space Harrier también. Y las conversiones de Saturn también


Claro...pero Mame, un emulador, no en la PCB original, groovymame se pasa por el forro las frecuencias de barrido originales y "adapta" todo a resoluciones cercanas a los 60hz, R-Type es otro ejemplo, la PCB original va 50hz, pero en Groovymame muestra 56hz o algo por ahi.


Últimamente, se te va mucho la pelota, ¿eh?
@JaviMadri demasiado.

Es como hablar con alguien que se ha escapado del manicomio y él no lo sabe y vive su verdad todo convencido.
chinitosoccer escribió:
Claro...pero Mame, un emulador, no en la PCB original, groovymame se pasa por el forro las frecuencias de barrido originales y "adapta" todo a resoluciones cercanas a los 60hz, R-Type es otro ejemplo, la PCB original va 50hz, pero en Groovymame muestra 56hz o algo por ahi.

.

Según leo por ahí, el Rtype Arcade funciona a 55 Hz y a una elevada resolución de 384x256... lo cual me parece curioso y no lo sabía, pensaba que iría a 60 Hz o 60 fps como practicamente la mayoría de los juegos de la época.

Bueno, supongo que si el juego está diseñado de manera nativa para funcionar a ese framerate no debería haber problema. Aunque sean 50 o 55 Hz (50 o 55 fps).

Mi problema con el framerate va más por las adaptaciones de juegos diseñados a 60 hz al formato PAL a 50 hz. Eso me come por dentro porque tengo que jugar a un juego de una manera inferior a como fue diseñado. Pero no tengo ningún problema con los juegos a 50 o 55 FPS si se diseñan desde un principio para ir así.

"The R-Type arcade game runs at a native resolution of 384x256 pixels with a vertical refresh rate of approximately 55.02 Hz, a non-standard timing that presents challenges for modern display devices. This specific resolution and frequency were a result of the game's unique calibration on the Irem M72 System hardware to achieve a higher active line count than typical arcade titles of its time. "

Resolution and Frequency Breakdown
Resolution: 384 pixels wide by 256 pixels high.
Vertical Refresh Rate: 55.02 Hz.

He jugado a multitud de juegos creados a 50 hz 50 fps y la suavidad era total y absoluta. Bastante similar a jugar a 60 fps.

PD : Ignora comentarios personales ofensivos que te hagan en el foro. No sirven para nada y no llevan a nada.

Saludos.
Seideraco escribió:
chinitosoccer escribió:
Claro...pero Mame, un emulador, no en la PCB original, groovymame se pasa por el forro las frecuencias de barrido originales y "adapta" todo a resoluciones cercanas a los 60hz, R-Type es otro ejemplo, la PCB original va 50hz, pero en Groovymame muestra 56hz o algo por ahi.

.

Según leo por ahí, el Rtype Arcade funciona a 55 Hz y a una elevada resolución de 384x256... lo cual me parece curioso y no lo sabía, pensaba que iría a 60 Hz o 60 fps como practicamente la mayoría de los juegos de la época.

Bueno, supongo que si el juego está diseñado de manera nativa para funcionar a ese framerate no debería haber problema. Aunque sean 50 o 55 Hz (50 o 55 fps).

Mi problema con el framerate va más por las adaptaciones de juegos diseñados a 60 hz al formato PAL a 50 hz. Eso me come por dentro porque tengo que jugar a un juego de una manera inferior a como fue diseñado. Pero no tengo ningún problema con los juegos a 50 o 55 FPS si se diseñan desde un principio para ir así.

"The R-Type arcade game runs at a native resolution of 384x256 pixels with a vertical refresh rate of approximately 55.02 Hz, a non-standard timing that presents challenges for modern display devices. This specific resolution and frequency were a result of the game's unique calibration on the Irem M72 System hardware to achieve a higher active line count than typical arcade titles of its time. "

Resolution and Frequency Breakdown
Resolution: 384 pixels wide by 256 pixels high.
Vertical Refresh Rate: 55.02 Hz.

He jugado a multitud de juegos creados a 50 hz 50 fps y la suavidad era total y absoluta. Bastante similar a jugar a 60 fps.

PD : Ignora comentarios personales ofensivos que te hagan en el foro. No sirven para nada y no llevan a nada.

Saludos.

te veo muchas veces enlazar los hz y los fps, como si fueran de la mano, asi que desde mi practicamente ignorancia, te pregunto, si ntsc es 60hz/60 fps y pal es 50hz/50fps, porque el super mario bros va igual en ntsc o en pal? o el ninja ryukenden y el shadow warrios?
si pones el super mario pal a 60hz o el shadow warriors van a toda castaña, nada que ver con la rom ntsc
Un montón de juegos arcade funcionan a frecuencias no estándar, por eso es complicado emularlos sin stuttering o captúralos con re-escaladores.

Por ejemplo Mortal Kombat mismamente tambien es ~54Hz

Tomax_Payne escribió:te veo muchas veces enlazar los hz y los fps, como si fueran de la mano, asi que desde mi practicamente ignorancia, te pregunto, si ntsc es 60hz/60 fps y pal es 50hz/50fps, porque el super mario bros va igual en ntsc o en pal? o el ninja ryukenden y el shadow warrios?
si pones el super mario pal a 60hz o el shadow warriors van a toda castaña, nada que ver con la rom ntsc


Los FPS, los Hz y la velocidad del juego no tienen nada que ver.
Son tres cosas diferentes y desligadas entre ellas.

Los FPS es la cantidad de imágenes que hay por segundo en tu juego.
Los Hz la cantidad de veces que la pantalla se refresca por segundo.
La velocidad es simplemente el tiempo de ejecución de tu juego.

Y aquí cualquier combinación es posible, un juego puede funcionar a 30FPS a una frecuencia de 60Hz y un 100% de velocidad y otro juego puede funcionar a 60FPS a una frecuencia de 60Hz pero a una velocidad del 50% porque está entrando en Slowdown.

Tampoco es lo mismo un Slowdown que una perdida de Frames.


Lo normal e ideal es que tu juego funcione al mismo Framerate que a su frecuencia, ya que si estos dos valores no cuadran puedes tener problemas diferentes como frames repetidos que crean stutering o escroles bruscos y otras mil cosas.
Tomax_Payne escribió:te veo muchas veces enlazar los hz y los fps, como si fueran de la mano, asi que desde mi practicamente ignorancia, te pregunto, si ntsc es 60hz/60 fps y pal es 50hz/50fps, porque el super mario bros va igual en ntsc o en pal? o el ninja ryukenden y el shadow warrios?
si pones el super mario pal a 60hz o el shadow warriors van a toda castaña, nada que ver con la rom ntsc

Cuando se adapta un juego NTSC 60 fps a PAL 50 fps se puede hacer de dos maneras.

Una es mantener todos los frames originales, los 60 fps que se ejecutan por segundo en la versión NTSC. Tienes que mostrar esos 60 fps pero en más tiempo que un segundo pues en PAL solo puedes mostrar 50. El resultado es que el juego va más lento. Al mantener todos los frames pues no se pueden mostrar a la misma velocidad y nos comemos juegos un 17% más lentos.

Este es el método usado habitualmente. Lo más común.

Pero hay algunos casos donde la conversión se hace bien, ajustando los frames para quitar algunos y mostrar solo 50 fps a 50 hz en PAL. Se pierden frames por el camino, hay menos fluidez... pero da igual si el juego va a 50 fps porque sigue siendo un elevado framerate en el que se pueden ver los juegos muy bien y fluidos.

Esto es lo que se hizo en la conversión del Metal Gear Solid 2 de Ps2, que va practicamente igual en PAL que en NTSC. Sin embargo el Devil May Cry PAL es un dolor porque usaron el primer método para adaptar a PAL. Y va lentorro como él solo.

Supongo que esos casos que comentas son tambien convertidos usando el segundo método. Por eso van igual de velocidad en PAL que en NTSC.

Saludos.
Seideraco escribió:
Tomax_Payne escribió:te veo muchas veces enlazar los hz y los fps, como si fueran de la mano, asi que desde mi practicamente ignorancia, te pregunto, si ntsc es 60hz/60 fps y pal es 50hz/50fps, porque el super mario bros va igual en ntsc o en pal? o el ninja ryukenden y el shadow warrios?
si pones el super mario pal a 60hz o el shadow warriors van a toda castaña, nada que ver con la rom ntsc

Cuando se adapta un juego NTSC 60 fps a PAL 50 fps se puede hacer de dos maneras.

Una es mantener todos los frames originales, los 60 fps que se ejecutan por segundo en la versión NTSC. Tienes que mostrar esos 60 fps pero en más tiempo que un segundo pues en PAL solo puedes mostrar 50. El resultado es que el juego va más lento. Al mantener todos los frames pues no se pueden mostrar a la misma velocidad y nos comemos juegos un 17% más lentos.

Este es el método usado habitualmente. Lo más común.

Pero hay algunos casos donde la conversión se hace bien, ajustando los frames para quitar algunos y mostrar solo 50 fps a 50 hz en PAL. Se pierden frames por el camino, hay menos fluidez... pero da igual si el juego va a 50 fps porque sigue siendo un elevado framerate en el que se pueden ver los juegos muy bien y fluidos.

Esto es lo que se hizo en la conversión del Metal Gear Solid 2 de Ps2, que va practicamente igual en PAL que en NTSC. Sin embargo el Devil May Cry PAL es un dolor porque usaron el primero método para adaptar a PAL. Y va lentorro como él solo.

Supongo que esos casos que comentas son tambien convertidos usando el segundo método. Por eso van igual de velocidad en PAL que en NTSC.

Saludos.


No, tu comentario está mal.

El Slowdown presente en algunos juegos PAL de la época no tiene que ver con que "conserven todos los frames", eso para empezar es imposible, no puedes mostrar 60 frames en una ventana de 50.

La razón es el VBLANK.
Los juegos clásicos se desarrollan con el rasterizado de frames como unidad de medida para toda la lógica del juego, es decir:
La lógica del juego y los frames están relacionados 1:1 ya que el siguiente frame se procesa durante el VBLANK.

La forma rápida de adaptar una consola de 60Hz a 50Hz era ralentizar el VBLANK, cada frame y cada proceso del juego se ejecuta a una velocidad inferior para encajarlo en la ventana de 50 en lugar de 60.

Los juegos clásicos PAL que funcionan a la misma velocidad del NTSC es porque están reprogramados para correr más rápido, es decir, todo va al 120% de lo que debería pero manteniendo el VBLANK a 50.

VBlank and vertical interrupt
VBlank is a longer period than HBlank, and so the vertical interrupt can contain more code. The vertical interrupt is typically when a game will load new data to VRAM, CRAM and VSRAM via DMA. VBlank reliably occurs 60 times a second (50 times a second on PAL consoles), so game logic and music is often tied to it to keep things running at a constant pace. This is done by running a certain amount of code during a frame, then waiting for a vertical interrupt before running it again.
-Giru- escribió:
No, tu comentario está mal.

El Slowdown presente en algunos juegos PAL de la época no tiene que ver con que "conserven todos los frames", eso para empezar es imposible, no puedes mostrar 60 frames en una ventana de 50.

La razón es el VBLANK.
Los juegos clásicos se desarrollan con el rasterizado de frames como unidad de medida para toda la lógica del juego, es decir:
La lógica del juego y los frames están relacionados 1:1 ya que el siguiente frame se procesa durante el VBLANK.

La forma rápida de adaptar un juego a 60Hz a 50Hz era ralentizar el VBLANK, cada frame y cada proceso del juego se ejecuta a una velocidad inferior para encajarlo en la ventana de 50 en lugar de 60.

Los juegos clásicos PAL que funcionan a la misma velocidad del NTSC es porque están reprogramados para correr más rápido, es decir, todo va al 120% de lo que debería pero manteniendo el VBLANK a 50.

Me parece que no te has enterado de nada al leer mi anterior mensaje. No estoy diciendo que se mostraran los 60 fps NTSC dentro de un segundo a 50 HZ PAL. Eso sería absurdo.

Se usa más de un segundo para mostrar esos 60 fps en PAL por lo que al tardar más de un segundo en mostrar los mismos frames en PAL que en NTSC pues el juego va más lento.

Lee mejor antes de ponerte a decirle a la gente que está equivocada.

El segundo método es precisamente lo que comentas de reprogramar los juegos para adaptarlos al formato PAL... y la manera de que vayan "más rápidos" es quitar frames y ejecutar el juego a 50 hz. Se muestra por tanto el juego a la misma velocidad pero mostrando menos frames cada segundo.

Ya tenía en cuenta todo el asunto del VBlank sin mencionarlo siquiera. Mi manera de explicarlo no lo necesita.

Saludos.
No lo termino de pillar, los FPS se pueden poner y quitar? Porque si pongo el Sonic jap y de momento lo paso a 50, como sabe el juego que frames quitar? Porque el juego que veo es el mismo pero más lento, no veo que salten frames (eso solo me ha pasado con el super Mario world, que cada x tiempo glitchea para juntar video y audio). Algo se me escapa.
Tu comentario sigue sin tener ningún sentido.

¿Cómo vas a usar más de 1 segundo para mostrar "todos los FPS" cuando literalmente FPS significa "frame por segundo"?

¿Y por esa lógica por qué la música va más lenta también?



Los FPS es información que se puede perder y no pasa nada, no afecta al rendimiento ni a la velocidad del juego, solo a la suavidad visual del jugador.


Los juegos PAL de la época no van más lentos o más rápidos porque quiten o añadan frames. Van más lentos porque la lógica del juego está ligada a cada uno de esos frames, así que si en un segundo tu personaje da 60 pasos por segundo en NTSC en PAL da solo 50 pasos.


Tomax_Payne escribió:No lo termino de pillar, los FPS se pueden poner y quitar? Porque si pongo el Sonic jap y de momento lo paso a 50, como sabe el juego que frames quitar? Porque el juego que veo es el mismo pero más lento, no veo que salten frames (eso solo me ha pasado con el super Mario world, que cada x tiempo glitchea para juntar video y audio). Algo se me escapa.


Si y no.

Ligamos frames a velocidad porque las consolas clásicas aplicaban la lógica del juego entre frames.

Sonic a 50Hz va a 50 Frames porque la consola se está ralentizando un 18% para hacer el modo 50Hz.
No tiene que ver con los frames, tiene que ver qué para pasar de 60hz a 50hz lo ralentizaron todo.

Los juegos que no se ralentizan en PAL es porque su lógica interna está modificada para ir al 120%, por eso si los pones en una consola Jap van a toda hostia de rápido.
Tomax_Payne escribió:No lo termino de pillar, los FPS se pueden poner y quitar? Porque si pongo el Sonic jap y de momento lo paso a 50, como sabe el juego que frames quitar? Porque el juego que veo es el mismo pero más lento, no veo que salten frames (eso solo me ha pasado con el super Mario world, que cada x tiempo glitchea para juntar video y audio). Algo se me escapa.


El juego no sabe nada. El juego está programado para ejecutarse de una manera concreta y si no lo ejecutas de esa manera pues irá diferente a como debería ir y fue diseñado.

El Sonic JAP va a 60 fps en NTSC. Hasta aquí claro, ¿ok?

Si tienes ese juego y en un emulador lo configuras a 50 hz... ese juego tendrá que ejecutarse pero solo podrá mostrar 50 imágenes por segundo pues el PAL va a esa frecuencia/velocidad. Así que el juego irá más lento al tener que adaptarse al formato PAL de 50 hz.

Lo mismo sucede al revés si coges un juego PAL 50 HZ y lo ejecutas a 60 Hz. Pues el juego irá más rápido de cómo debería ir.

Tambien hay que tener en cuenta que hay juegos que van a 30 fps NTSC 60 hz como el Sonic Spinball y que al pasarse a PAL pues se ponen a 25 fps PAL 50 hz.

@-Giru- Obviamente me refiero a mostrar todos los frames. No puedes mostrar los 60 frames NTSC que se muestran por segundo en NTSC dentro de un segundo PAL que muestra 50 frames. Esto es de perogrullo y me parece increible que estés perdiendo el tiempo discutiendo sobre esto.

Saludos.
@Seideraco

Es que tu lógica de "Mostrar todos los frames" sigue sin tener ningún sentido.

Si entendemos un juego de Mega Drive como un juego de mesa en el que cada frame es un turno, si bajas la frecuencia de 60 turnos por segundo a 50 turnos por segundo el juego va a desarrollarse más lentamente. Punto.

No hay alternativas, no puedes saltarte 10 turnos como decías en tu primer comentario, no pueden quedar turnos a deber, simplemente se ejecuta más lento porque has bajado el ratio. No hay más. Y eso es porque la lógica del juego está ligada al VBLANK.
-Giru- escribió:@Seideracotiemp
Es que tu lógica de "Mostrar todos los frames" sigue sin tener ningún sentido.

Si entendemos un juego de Mega Drive como un juego de mesa en el que cada frame es un turno, si bajas la frecuencia de 60 turnos por segundo a 50 turnos por segundo el juego va a desarrollarse más lentamente. Punto.

No hay alternativas, no puedes saltarte 10 turnos como decías en tu primer comentario, no pueden quedar turnos a deber, simplemente se ejecuta más lento porque has bajado el ratio. No hay más. Y eso es porque la lógica del juego está ligada al VBLANK.

Estamos diciendo lo mismo con distintas palabras. Solo que yo incluyo el VBLANK y todo lo que has dicho de la lógica del juego en el término reprogramar el juego para que mantenga velocidad pero mostrando menos frames por segundo. Porque si quieres mantener velocidad pasando un juego 60 fps NTSC a 50 fps PAL, por huevos, tienes que quitar frames.

Pero vamos, por cojones. No tiene otra ,¿eh?

La diferencia es que yo no te voy diciendo a tí que estás equivocado. Estás diciendo lo mismo con otras palabras.

Saludos.
Seideraco escribió:
-Giru- escribió:@Seideracotiemp
Es que tu lógica de "Mostrar todos los frames" sigue sin tener ningún sentido.

Si entendemos un juego de Mega Drive como un juego de mesa en el que cada frame es un turno, si bajas la frecuencia de 60 turnos por segundo a 50 turnos por segundo el juego va a desarrollarse más lentamente. Punto.

No hay alternativas, no puedes saltarte 10 turnos como decías en tu primer comentario, no pueden quedar turnos a deber, simplemente se ejecuta más lento porque has bajado el ratio. No hay más. Y eso es porque la lógica del juego está ligada al VBLANK.

Estamos diciendo lo mismo con distintas palabras. Solo que yo incluyo el VBLANK y todo lo que has dicho de la lógica del juego en el término reprogramar el juego para que mantenga velocidad pero mostrando menos frames por segundo. Porque si quieres mantener velocidad pasando un juego a 60 fps NTSC a 50 fps PAL, por huevos, tienes que quitar frames.

Pero vamos, por cojones. No tiene otra ,¿eh?

La diferencia es que yo no te voy diciendo a tí que estás equivocado. Estás diciendo lo mismo con otras palabras.

Saludos.


Ahí quería yo llegar, claro que hay otra.

Nadie quita frames, nadie añade frames, volviendo al ejemplo anterior del juego de mesa, lo que puedes hacer en la versión de 50 turnos por segundo es que las fichas se muevan más rápido por las casillas para que en un segundo acaben en la misma posición que la versión que va a 60 turnos por segundo.


Los frames no son relevantes, no incluyen información de valor, solo están para añadir fluidez al movimiento, se pueden perder y no pasa nada.
-Giru- escribió:Ahí quería yo llegar, claro que hay otra.

Nadie quita frames, nadie añade frames, volviendo al ejemplo anterior del juego de mesa, lo que puedes hacer en la versión de 50 turnos por segundo es que las fichas se muevan más rápido por las casillas para que en un segundo acaben en la misma posición que la versión que va a 60 turnos por segundo.


Los frames no son relevantes, no incluyen información de valor, solo están para añadir fluidez al movimiento, se pueden perder y no pasa nada.

Terminas mostrando menos fluidez y menos imágenes en PAL que en NTSC.

Si quieres mantener la velocidad de un juego NTSC que muestra 60 imágenes cada segundo en formato PAL donde se muestran 50 imágenes cada segundo, te guste o no, te subas por las paredes o no, pierdes 10 imágenes. Y con esa pérdida de imágenes se pierde fluidez.

Y esto es así porque son matemáticas puras. Si haces una buena adaptación de NTSC a PAL manteniendo velocidad pierdes frames. Por huevos. Y si haces una mala adaptación sin preocuparte pues dejas todos los frames que se generan en NTSC... pero los tendrás que mostrar usando más de un segundo en PAL. Concretamente necesitarás un 17% del siguiente segundo. y esto se va solapando continuamente por lo que al final estás mostrando un juego un 17% más lento.

De nuevo me reafirmo que estamos diciendo lo mismo con distintas palabras. Pero yo no tengo el ego tan grande como para ir diciéndole a los que explican todo esto con otras palabras distintas a las mías que están equivocados.

Saludos.
-Giru- escribió:Un montón de juegos arcade funcionan a frecuencias no estándar, por eso es complicado emularlos sin stuttering o captúralos con re-escaladores.

Tuve una placa del Seibu Cup Soccer que era un porculeo continuo. 54hz, tenía que andar tocando el menú de servicio de la tele para ajustar la imagen, y necesidad de -5V para tener sonido. Ala por ahí, hace unos años la vendí.
No, no estamos diciendo lo mismo, porque tú estás ligando FPS a conceptos erróneos.
Pequeños matices que cambian mucho el significado de lo que estás exponiendo.

Sobre esto gira todo tu error del concepto:

Seideraco escribió: Y si haces una mala adaptación sin preocuparte pues dejas todos los frames que se generan en NTSC... pero los tendrás que mostrar usando más de un segundo en PAL. Concretamente necesitarás un 17% del siguiente segundo. y esto se va solapando continuamente por lo que al final estás mostrando un juego un 17% más lento.


Es un error gordo.

Si comparamos PAL 50 contra NTSC 60 siempre vas a perder esos 10 frames, siempre. Hagas una buena o una mala adaptación como tú dices.

En el Sonic PAL en cada segundo se pierden 10 FPS, siempre.

Lo que no se pierden son los 10 Interrupts del VBLANK que son los que hacen que la lógica del juego avance. Estos simplemente se ejecutan cada menos tiempo y por eso el juego va más lento.
-Giru- escribió:No, no estamos diciendo lo mismo, porque tú estás ligando FPS a conceptos erróneos.
Pequeños matices que cambian mucho el significado de lo que estás exponiendo.

Sobre esto gira todo tu error del concepto:

Es un error gordo.

Si comparamos PAL 50 contra NTSC 60 siempre vas a perder esos 10 frames, siempre. Hagas una buena o una mala adaptación como tú dices.

En el Sonic PAL en cada segundo se pierden 10 FPS, siempre.

Lo que no se pierden son los 10 Interrupts del VBLANK que son los que hacen que la lógica del juego avance. Estos simplemente se ejecutan cada menos tiempo y por eso el juego va más lento.

Pero si me acabas de dar la razón.

Aparte, lo que estás haciendo es como si viniera un pavo y te dijera a tí que estás equivocado. Que las adaptaciones de NTSC a PAL no se hacen como tu dices, sino que lo que se hace es editar ciertos registros en la CPU programando en ensamblador y mediante esos registros, ajustas el framerate del juego para que se mantenga la velocidad al adaptar de NTSC a PAL.

Vamos, lo mismo que tú estás diciendo pero entrando aún más en detalle.

Pues eso es lo que tú estás haciendo. Yo no he querido entrar en detalles del Vblank. Lo simplifico que para sea sencillo de entender por TODO el mundo.

Si tienes un juego que muestra 60 imágenes por segundo en NTSC a 60 hz y lo quieres llevar PAL que muestra 50 imágenes por segundo y mantener la velocidad a la que se ejecuta el juego... por cojones pierdes frames. Los tienes que descartar. Si no los descartas y los sigues mostrando lo que tendrás entonces es un juego un 17% más lento. No mantendrás por tanto la velocidad del juego.

Y en esto, en esta programación, están esos ajustas durante el Vblank y la lógica del juego que llevas comentando desde hace varios mensajes.

Así que sí, estamos diciendo lo mismo pero tú te ennervias en que haya gente que lo explica de manera diferente de cómo te gusta explicarlo a tí.

Pues muy bien que lo veo. Saludos.
Seideraco escribió:
Si tienes un juego que muestra 60 imágenes por segundo en NTSC a 60 hz y lo quieres llevar PAL que muestra 50 imágenes por segundo y mantener la velocidad a la que se ejecuta el juego... por cojones pierdes frames. Los tienes que descartar. Si no los descartas y los sigues mostrando lo que tendrás entonces es un juego un 17% más lento. No mantendrás por tanto la velocidad del juego.


Que no, que no los puedes seguir mostrando, que es imposible.

Que tú estás creando una falsa dicotomía en la que:

A- Quitas 10 frames pero mantienes velocidad.

B- Mantienes todos los frames pero va más lento.

Y ese planteamiento es erróneo.

Primero: esos 10 frames los pierdes siempre, en cualquier escenario.

Segundo: tú método A no se puede hacer en ninguna consola clásica que funcione por VBLANK, no puedes mantener la velocidad, es imposible.
Puedes modificar el código para que el juego funcione más rápido, pero no tienes otra opción.

Tercero: según tu dicotomía, los juegos PAL adaptados en consolas NTSC van un 120% más rápido porque corren a 72FPS, un absurdo.
-Giru- escribió:Que no, que no los puedes seguir mostrando, que es imposible.

Que tú estás creando una falsa dicotomía en la que:

A- Quitas 10 frames pero mantienes velocidad.

B- Mantienes todos los frames pero va más lento.

Y ese planteamiento es erróneo.

Primero: esos 10 frames los pierdes siempre, en cualquier escenario.

Segundo: tú método A no se puede hacer en ninguna consola clásica, no puedes mantener la velocidad, es imposible, puedes modificar el código para que el juego funcione más rápido, pero no tienes otra opción.

Tercero: según tu dicotomía, los juegos PAL adaptados en consolas NTSC van un 120% más rápido porque corren a 72FPS, un absurdo.


Yo estoy diciendo las cosas como considero que debo explicarlas y comentarlas por el foro. Si no te gusta mi manera de verlo pues lo siento pero no voy a cambiar de manera de pensar por tí. De igual modo que no espero que tú lo hagas por mí.

Y no, no pierdes frames si adaptas un juego de NTSC a PAL sin mantener la velocidad. Los frames los tienes igual, pero se muestran más lentamente. Por tanto, los juegos van igual de fluidos pero se muestran más lentos.

Si adaptas los juegos NTSC a PAL para mantener velocidad pues pierdes frames que la consola no tiene que procesar. Que no los vas a ver, ni más rápido ni más lentamente. No van a estar.

Y punto no tiene más. Si te gusta bien y si no tambien porque es lo que hay. O mantienes velocidad perdiendo frames intermedios o pierdes velocidad mostrando los mismos frames en NTSC que en PAL, aunque sea usando más de un segundo para mostrar esos 60 frames que en NTSC se mostrarían en un segundo.

Saludos.
Mola.Expñicad el caso inverso.Un.juego hecho PAL,pasarlo a NTSC.
Seideraco escribió:Y no, no pierdes frames si adaptas un juego de NTSC a PAL sin mantener la velocidad. Los frames los tienes igual, pero se muestran más lentamente. Por tanto, los juegos van igual de fluidos pero se muestran más lentos.


¿Entiendes que FPS significa frames por segundo y que los segundos son una unidad de tiempo absoluta? ¿no?

Osea, es imposible que entre 60 frames por segundo y 50 frames por segundo no se pierdan 10 frames por cada segundo.

Lo que se muestra más lentamente es la lógica del juego en sistemas clásicos, porque antes de cada frame es cuando se ejecuta. Olvídate de los frames, lo importante aquí es el tiempo de ejecución.

Seideraco escribió:Si adaptas los juegos NTSC a PAL para mantener velocidad pues pierdes frames que la consola no tiene que precesar. Que no los vas a ver, ni más rápido ni más lentamente. No van a estar.

Pero esto es una barbaridad, no puedes saltarte interrupts, que lo pienses ya me hace ver donde está tu problema.

Olvídate otra vez de los frames. Si adaptas un juego clásico PAL para que funcione a la velocidad NTSC lo que vas a hacer es que Mario en lugar de avanzar 1 pixel por paso avance 1.2 píxeles por paso.

Seideraco escribió:Y punto no tiene más. Si te gusta bien y si no tambien porque es lo que hay.
...



Tío, de verdad, no tienes razón.

Haz el esfuerzo un segundo de leer esto que voy a ponerte y si sigues opinando lo mismo doy carpetazo y dejo el tema.

Voy a poner un ejemplo práctico:

Imaginemos que tenemos un juego, voy a poner por ejemplo el Counter Strike para PC.

Yo actualmente abro el Counter Strike y puedo tener perfectamente 600 FPS, mi monitor es de 60Hz así que de esos 600 FPS yo solo voy a ver 60.

Aunque el juego me funcione a 600 FPS corre a la misma velocidad que si me fuera a 60 FPS o a 30 FPS, los FPS no están afectando a la velocidad del juego, solo a lo que yo "jugador" veo en pantalla.

Aquí tenemos un ejemplo claro de que: Lógica del juego ≠ FPS ≠ Hz.

Esto es posible porque el rendimiento de la lógica del juego no se ve afectado por mi GPU.


Ahora, imaginémonos que el Counter Strike está programado de tal manera que la lógica del juego está vinculada a los frames por segundo. Si yo muevo el juego a 600 FPS el juego va a moverse muchísimo mas rápido que si yo lo juego a 60 o a 30.

A las consolas clásicas les pasa algo parecido a este hipotético caso.

Las consolas clásicas (Pre Dreamcast) utilizan todos sus recursos en mostrar un frame y antes del frame siguiente, en el VBLANK, procesan la lógica del siguiente frame.


Esto quiere decir que si yo tengo una lógica que en cada actualización da un paso y funciona bajo 60 actualizaciones por segundo, al final de un segundo he dado 60 pasos.

Si modifico esa tasa para que en lugar de 60 actualizaciones sean 50 por segundo, al final de un segundo habré dado 50 pasos en lugar de 60.

Pero, si yo le digo que en cada una de esas 50 actualizaciones en lugar de avanzar lo que avanza un paso normal avance 1,2 pasos, al final del segundo habré avanzado 60. Al igual que la otra.

No es porque me he comido 10 pasos, es porque en cada paso he avanzado un 0.2 extra.

mcfly escribió:Mola.Expñicad el caso inverso.Un.juego hecho PAL,pasarlo a NTSC.


Es lo mismo, pero al revés.
Pones unos gif como sexyfucker porque no me entero de na.
Si pongo un juego pal (shadow warriors) en mi famicom, el juego va bien y la música a toda pastilla, se cuelga en la 2° fase. Serían los 50 frames rulando a 60, pero de dónde salen los 10 frames extras? Es ahí donde me pierdo, esos 10 frames que están o no según los hz
10454 respuestas