¿Se hubiese conseguido con el SVP un Doom superior al de SNES en Mega?

Archivado
1, 2, 3
Encuesta
¿Un Doom en Mega con chip de apoyo podría haber superado la versión de SNES?
62%
48
38%
30
Hay 78 votos.
Ver ordenados

@SuperPadLand el de 3DO tiene que mejorar simplemente poniéndolo a 240p con la palanca esa de los modelos japoneses raros.

El de Saturn es doloroso porque ves como unos mapas tan buenos se vuelven pesados por la lentitud del protagonista y de los petardeos/brusquedad del entorno en general.
Sexy MotherFucker escribió:no victimicemos al port de SNES porque en cuestión de optimización el resto estaba igual o peor (Saturn).


Si no puede hablarse de la situación del port de snes en el hilo del port de snes porque otros ports que no son el topic del hilo estaban igual o peor, entonces, ¿de que puede hablarse?.

Ante la pregunta de si se puede conseguir en megadrive un port superior al de snes, la respuesta obligada es que el port de snes tiene el suficientemente margen de mejora como para considerar que una megadrive no pudiera también tenerla.

Ponerle pegas a esto con otra clase de críticas no tiene demasiada relación, y menos aún las que ni siquiera se han mencionado, como lo de las multiplicaciones del ppu1.

Sexy MotherFucker escribió:Lo de "fantasía" iba referido precisamente a tus estimaciones de hasta donde llegan las posibilidades del tema, porque macho ahora estàs màs moderado desde que te echaron un par de jarrazos de agua fría al respecto, pero es que en el pasado cuando ésto se anunció te he leido comentarios en plan flipado como que esto iba a ser la segunda venida de Jesucristo a los 16 bits en plan de que esperabas no sé; un Star Fox a pelo comandado por el PPU1, nivel Super Scaler en los 128 sprites, o que sé yo, cuando lo único que tenemos en realidad es a ti en NESDEV hablando con un tío que dice que hay una especie de "backdoor" desde la CPU al PPU, de la cual hay muchas dudas acerca de su utilidad y alcance real.


Bueno, es que no había entrado a referirme sobre eso.

Pero si lo mencionas, hay que puntualizarlo. No solo es que esas multiplicaciones salen casi gratis, sino que pueden realizarse muchas mas de las que esa cpu por si solo podría hacer, o en su defecto manteniendo todos esos ciclos de reloj para hacer otras cosas.

La potencia extra que sacas es grande, de esto nadie ha puesto dudas sobre su existencia, o posibilidades, lo que dices no es cierto. Otra cosa es que luego las estimaciones fuesen demasiado optimistas, pero en todo caso criticar una estimación cuando todo apunta a que es ilusionante, solo porque finalmente luego no era realmente así, es verdaderamente ventajista, ¿como no vas a ser optimista cuando todo parece optimista?, es que es de coña crticarlo.

Ahora bien, nadie ha dicho que las estimaciones estaban equivocadas, así que dejemos de comportarnos como si esto fuese falso solo porque a ti te de igual la snes, y obviamente le das mas o menos crédito a algo dependiendo de si es megadrive o "la otra".


Que no pasa nada, pero se nota que no lo das por válido solo porque se trata de esta consola, y la única duda no es si esto es posible o no (porque es verídico), sino su alcance real. Como he dicho mas veces, hagas lo que hagas vas a desperdiciar la mayoría de las multiplicaciones que el PPU1 pueda calcular, así que todo queda en que simplemente puedes obtener gratis todas las que el propio 65816 pudiera ser capaz de hacer por si misma (o en su defecto gastar todo el tiempo posible en recoger las que el ppu1 haga), que por supuesto es una ganancia de potencia muy importante.

Si te vas al principio del todo, cuando todavía no conoces nada, y quieres soñar con que puedes usar toda la capacidad del PPU1, entonces si, nos ha jodido, es ridículo, pero no es justo, porque el resto del tiempo siempre se ha dejado claro de que va esto.

Sexy MotherFucker escribió:
-La velocidad de la ram de megadrive se va a tener que adaptar si o si a los 1,92mhz del bus del DMA, así que de nada sirven sus 5mhz y pico.


Yo ese tema no lo tengo NADA claro, así que voy a preguntar a alguien que sepa.


Si quieres leer o escribir en ram, lo vas a tener que hacer a la velocidad máxima que te permita el DMA, ni siquiera tienes que fiarte de mi, es que es de cajón.

Se me ocurre que el motivo por el que la ram funciona a 5mhz y pico, es porque a esa velocidad sincroniza mejor con el DMA que funcionando a 1,92mhz. Probablemente no me equivoque y por ahí vayan los tiros.


editado: sin tener ni puñetera idea de a que frecuencia funciona la ram de la megadrive, ni haberlo visto, ni nada, me lanzo y digo que funciona a 5,76mhz... ¿me equivoco? xD
@Señor Ventura la SNES no "me da igual", si así fuese no me pondría tan vehemente tanto atacando sus defectos, como luego derritiéndome con sus virtudes, siempre he dicho que tengo 1 relación Amor/Odio con esta consola, indiferencia no me causa ninguna, y muchos de mis juegos favoritos de esa generación se encuentran dentro de su catálogo, y estoy interesado en cualquier conocimiento/novedad sobre ella. Tengo una experiencia NOTABLE con el sistema (más que con MD de hecho) ya que aunque yo nunca la pedí me la regalaron en las navidades de 1992 y fue la consola con la que viví aquella generación, pudiendo por ejemplo establecer debate profundo sobre CUALQUIER Super Mario con CUALQUIER nintendero, sin serlo yo mismo, y sin tampoco militar en el bando de fans profundos del sistema, si bien sí soy un gran admirador y antagonista a partes iguales de sus virtudes y defectos.

¿Con el tiempo me he hecho fan de la MD y me cae mejor ésta? Sí, yo nunca me he escondido.

¿Considero que el hard de la SNES está sobrevalorado? Totalmente.

Pero el sistema me interesa y mucho. Los que me tocáis las pelotas sois sus fans cuando entráis en modo demente xD

Me creo que exista una "backdoor" que conecta la CPU con el PPU1. Lo que no me creo es ninguna de las estimaciones que hagas tú, sobre todo las que hacías hace algunos meses y de las que ya has levantado un poco el pie del acelerador. Sabes que me caes bien y no tengo ningún problema personal contigo, pero como fan de la SNES tienes traca y yo reacciono ante ello xD

Si no puede hablarse de la situación del port de snes en el hilo del port de snes porque otros ports que no son el topic del hilo estaban igual o peor, entonces, ¿de que puede hablarse?.


Que sí hombre, pero es que a ti hay que echarte de comer aparte porque estás todo el santo día dando la puta matraca y sacando punta a cualquier cosa que se diga de la SNES, por eso mejor dejarte claro que su Doom no fue el único "pobrecito" sin depurar, es que ni siquiera es el peor ejemplo de ello (SATURN).

Sobre la memoria en cualquier caso Taiyou ya ha dejado claro que el Virtua Racing venía con 128 kb de ram, luego un hipotético Doom con el SVP podría hacer lo mismo.
Para mí no,si éso hubiese sido posible lo hubiesen hecho y no para el 32x.
No sé hasta qué punto el svp puede gestionar gráficos 2d al igual que el FX.
Cómo todo es teóricamente, para mí es un claro no.
@Sexy MotherFucker Voy a hacer un pequeño stop para poner esto que me he encontrado:

https://forums.anandtech.com/threads/mc ... t-40136542


La potencia en MIPS de las cpu's de muchos cacharros hasta el 2000. Está curioso.


P.D: Siempre he querido saber la proporción a escala entre el tamaño de los transistores entre los primeros procesadores, y los últimos de hoy en día. No me sorprendería si un transistor de z80 fuese como un coche, y un transistor de un i9 fuese en comparación como una pelota de tenis.
@Señor Ventura muy chula esa tabla. No se exactamente lo que son los Mips, pero llama la atención varias cosas :

1- Que la Atari2600 tenga igual que la Master System, y que la NES destaque un significativamente sobre la Master.

2- Cita a la TG16 como consola de 8 bits, y tiene más Mips que MD y SNES.

3- La diferencia brutal entre los 32 bits y los 16 bits, siendo muchísimo menor, pero muchísimo menor entre los 8 y los 16.
@Señor Ventura en la tabla esa hay muchos errores; por ejemplo el SH-2 que calza la CPS3 no rula a 65 Mhz ni de coña, no había procesadores de la familia Hitachi SH2 tan rápidos en la época. Los de CPS3 tienen un clock a 25 Mhz, los de la 32x a 23,11 Mhz, y los de Saturn a 28 coma nosecuantos.

Me da mí que el tema de los MIPS en muchos casos es un mejungue del de la suma de varios procesadores de la máquina de turno, no hay más que ver el conteo de Saturn el cual es mucho más que el de los do SH2 juntos.
@aranya los mips son millones de operaciones por segundo en inglés, es un dato que se usó durante mucho tiempo para ver que consola o CPU era más potente, pero hay muchos otros factores a tener en cuenta que pueden hacer que una consola con menos mips sea mejor gráficamente que otra con más, entre otras cosas porque cada generación de procesadores puede realizar diferentes tipos de operaciones que pueden ser mejores y también los programas que se miden para ver cuantos mips mueve una CPU pueden no estar aprovechando correctamente o de la misma forma todos los procesadores en los que se usa dando falsos errores.
@SuperPadLand gracias por la explicación.

Nuestras Master Systems tienen igual Mips que una Atari2600 jaja.
Esa lista esta hecha por ashrion, no? XD
O´Neill escribió:Esa lista esta hecha por ashrion, no? XD


XD

Pero aunque no te lo creas tiene lógica que la CPU de la Pc-Engine pudiese tener tanto rendimiento; aunque de menor potencia global (8 bits VS 16) el custom Ricoh que calza la pequeña de NEC goza de todas las ventajas de la CPU de SNES (incluso sus instrucciones tardan aun menos ciclos en ejecutarse) pero sin los cuellos de botella, ni pésima configuración de aquella, por lo que a 7.1 Mhz ese micro de 8 bits puede dar mucha guerra, no hay más que ver los shooters del sistema funcionando algunos a 336x224, 256x239, y tiran como un puto rayo con la pantalla petada de enemigos, colisiones, etc.

En cuanto a configuración de CPU:

PCE >> MD >> NG AES >> SNES.

En cuanto a potencia global evidentemente el M68k de NG AES sobre todas.

Pero ey que no pasa nada, los multiplicadores del PPU1 revertirán todo lo de arriba [burla2]
Sexy MotherFucker escribió:Me creo que exista una "backdoor" que conecta la CPU con el PPU1. Lo que no me creo es ninguna de las estimaciones que hagas tú, sobre todo las que hacías hace algunos meses y de las que ya has levantado un poco el pie del acelerador. Sabes que me caes bien y no tengo ningún problema personal contigo, pero como fan de la SNES tienes traca y yo reacciono ante ello xD


No he hecho ninguna estimación. Esto funciona de una manera, y la cantidad de procesamiento que se pueda ganar con ello no se ha definido, ni con precisión, ni sin ella.

Tampoco necesito que me crea nadie. Escribo porque me apetece, y ya está, pero cuando no estoy diciendo nada tampoco es necesario que me recuerden mi reputación a todas horas.

El hilo trata de un port del doom de snes, y mi respuesta fué que si el doom de snes tiene margen de mejora, con una cpu inferior, y un super fx inferior al svp, entonces un port a megadrive optimizado hasta que no quede margen de mejora, con su cpu superior, y su svp superior al super fx, no tiene por qué no mejorar el actual doom de snes.

Esto en el hipotético caso de que el svp sirva para esta clase de tareas. Es lo que he dicho, y no otra cosa.

En definitiva, no me cansa, pero muchas veces entendeis lo que os parece, y me soltais que acabais por no creer ninguna de mis estimaciones y de mis cálculos por lo que creeis que digo, y no por lo que realmente digo.

Tu mismo lo has escrito: tengo traca, y molesta lo que escribo XD

Sexy MotherFucker escribió:Que sí hombre, pero es que a ti hay que echarte de comer aparte porque estás todo el santo día dando la puta matraca y sacando punta a cualquier cosa que se diga de la SNES, por eso mejor dejarte claro que su Doom no fue el único "pobrecito" sin depurar, es que ni siquiera es el peor ejemplo de ello (SATURN).


Nadie ha dicho que el doom de snes sea el único port con prisas (pobre randy linden, el trabajo que se pegó no fué precisamente liviano ^^u).

Para hablar de "sobreestimaciones" no entremos mucho en este foro tampoco, que aquí se dice mucho que la megadrive es casi como una neo geo, y que podría tirar con el mismísimo doom de pc a pelo, y ahí ya no reaccionais tanto [careto?]

Sexy MotherFucker escribió:Sobre la memoria en cualquier caso Taiyou ya ha dejado claro que el Virtua Racing venía con 128 kb de ram, luego un hipotético Doom con el SVP podría hacer lo mismo.


Yo me refería a un uso mas general. Usualmente los cartuchos no llevaban nada mas que la rom.

Sexy MotherFucker escribió:Pero ey que no pasa nada, los multiplicadores del PPU1 revertirán todo lo de arriba


Bueno, yo nunca hablé de eso.

Pero si, cuando un programa requiera de un uso suficiente de multiplicaciones, o pueda beneficiarse de ello, la snes se cobra una ventaja.

P.D: La cpu de la neo geo no creo que sea peor que la de megadrive, mas bien al contrario.
@Señor Ventura
P.D: La cpu de la neo geo no creo que sea peor que la de megadrive, mas bien al contrario.


Yo hablaba de la configuración de acuerdo a su diseño global, no de la potencia, obviamente un M68k @12 > 7'67.
Sexy MotherFucker escribió:Yo hablaba de la configuración de acuerdo a su diseño global, no de la potencia, obviamente un M68k @12 > 7'67.


Se ha leído y entendido perfectamente.
Señor Ventura escribió:@Sexy MotherFucker Voy a hacer un pequeño stop para poner esto que me he encontrado:

https://forums.anandtech.com/threads/mc ... t-40136542


La potencia en MIPS de las cpu's de muchos cacharros hasta el 2000. Está curioso.


P.D: Siempre he querido saber la proporción a escala entre el tamaño de los transistores entre los primeros procesadores, y los últimos de hoy en día. No me sorprendería si un transistor de z80 fuese como un coche, y un transistor de un i9 fuese en comparación como una pelota de tenis.


Vaya bestia la PS2 ¿no?
@AxelStone pero luego es como una lagartija que te ve y sale corriendo.
O´Neill escribió:@AxelStone pero luego es como una lagartija que te ve y sale corriendo.


Me consta que los programadores se quejaban amargamente XD . Respecto al tema del hilo, el SVP me parece una pena que llegó en esa época en que Sega ya estaba en la dinámica de tirar de la cadena con todo (Mega CD, SVP, 32X...). Salió solo el VR, sin contenido adicional, y arreando. En contraposición Nintendo le sacó mucho más partido al FX, con juegos de todos los géneros.

Así que si fuera por impacto en el mundillo, está claro que el SVP pasó con más pena que gloria, mientras que el FX aportó un buen lote de títulos de calidad.
aranya escribió:@Señor Ventura muy chula esa tabla. No se exactamente lo que son los Mips, pero llama la atención varias cosas :

1- Que la Atari2600 tenga igual que la Master System, y que la NES destaque un significativamente sobre la Master.

2- Cita a la TG16 como consola de 8 bits, y tiene más Mips que MD y SNES.

3- La diferencia brutal entre los 32 bits y los 16 bits, siendo muchísimo menor, pero muchísimo menor entre los 8 y los 16.


No soy un experto, pero sí se varias cosas:

- En esa tabla están mezclando algunas cosas (aparentemente), pues meten distintos chips de distintas tecnologías y propósitos en cada máquina.
- MIPS es millones de instrucciones por segundo.
- Las consolas de "32 bits" tenían todas procesadores RISC (reduced instruction set) que son muy distintos de los anteriores. Las instrucciones son más sencillas, pero mucho más rápidas. Es decir, hace menos en cada instrucción, pero van muy rápido, aunque necesitarás varias para hacer los mismo.
- Los mips, como casi todas las "medidas" de potencia que se han usado a lo largo de los años, bits, mhz, flops, etc, son sumamente engañosos. Especialmente, si sumas todos los "chips" que tiene un sistema, porque uno puede tener una cpu de 10 mips y un chip sonoro de 2, y otro tener justo al revés ¿cuál crees que podrá hacer más?
Sexy MotherFucker escribió:@Señor Ventura
P.D: La cpu de la neo geo no creo que sea peor que la de megadrive, mas bien al contrario.


Yo hablaba de la configuración de acuerdo a su diseño global, no de la potencia, obviamente un M68k @12 > 7'67.


Es que leo que haces dos menciones, la primera en cuanto a cpu, poniendo a la de md delante, y la segunda en cuanto a diseño global, poniendo a la neo geo delante.

Por configuración de cpu yo entiendo a la capacidad que tiene por si misma, mas aún cuando haces la distinción después con respecto al diseño global.

eknives escribió:Se ha leído y entendido perfectamente.


Pues yo debo ser tontito, porque veo entendible su post de esa forma XD
@issus Exactamente, las unidades de medida como los MIPS solo valen para comparar con certeza 2 procesadores de la misma familia. A partir de ahí, cada arquitectura es un mundo. Las CPU CISC es normal que tengan pocos MIPS, ya que cada operación es compleja, y las CPU RISC tendrán muchos MIPS pues ejecutan instrucciones simples.

De todos modos ojo, el RISC no llegó específicamente con las 32bit, los 68000 son procesadores RISC así que es normal también un buen índice de MIPS.
AxelStone escribió:Vaya bestia la PS2 ¿no?


El problema de la ps2 es que era solo cpu. No tenía GPU... o mejor dicho, era solo media GPU.

issus escribió:- En esa tabla están mezclando algunas cosas (aparentemente), pues meten distintos chips de distintas tecnologías y propósitos en cada máquina.
- MIPS es millones de instrucciones por segundo.
- Las consolas de "32 bits" tenían todas procesadores RISC (reduced instruction set) que son muy distintos de los anteriores. Las instrucciones son más sencillas, pero mucho más rápidas. Es decir, hace menos en cada instrucción, pero van muy rápido, aunque necesitarás varias para hacer los mismo.
- Los mips, como casi todas las "medidas" de potencia que se han usado a lo largo de los años, bits, mhz, flops, etc, son sumamente engañosos. Especialmente, si sumas todos los "chips" que tiene un sistema, porque uno puede tener una cpu de 10 mips y un chip sonoro de 2, y otro tener justo al revés ¿cuál crees que podrá hacer más?


Los MIPS de esa lista se refieren únicamente a los de la cpu de esos hardwares.

Solo con la potencia que necesita la snes para mover un plano en modo 7, excede con mucho las cantidades típicas que se indican ahí para cualquier hardware de 16 bits.

AxelStone escribió:@issus Exactamente, las unidades de medida como los MIPS solo valen para comparar con certeza 2 procesadores de la misma familia. A partir de ahí, cada arquitectura es un mundo. Las CPU CISC es normal que tengan pocos MIPS, ya que cada operación es compleja, y las CPU RISC tendrán muchos MIPS pues ejecutan instrucciones simples.

De todos modos ojo, el RISC no llegó específicamente con las 32bit, los 68000 son procesadores RISC así que es normal también un buen índice de MIPS.


Por descontado, una instrucción de una arquitectura de cpu no igual de eficiente que en el resto de casos. Para ver la diferencia entre una turbo grafx y una snes si es mas o menos válido para hacerse una idea, para el resto de casos, solo es un detalle.

Solo decir que la cpu de la turbografx no estará tan lejos de la cpu de la snes si emplean instrucciones de 16 bits mas contínuamente que de 8 bits... pero en global si diría que es ligeramente mas potente. A los mismos 7,16mhz el 65816 de la snes si que tendría bastante ventaja... de hecho sería una barbaridad de cpu en cuanto a eficiencia, seguramente no demasiado lejos del 68000 del megacd, o de la neo geo. No cerca, pero no lejos.
No
No encuentro el hilo del autor que estaba haciendo ingeniería inversa al SVP para correr código propio y preguntarle ¿Alguno recuerda el nombre?
@SuperPadLand , el compi @Taiyou ya respondió en este mismo hilo.

Saludos

Taiyou escribió:
kusfo79 escribió:El que puede aportar por aquí es el maestro @Taiyou


Uy tampoco te creas XD.

A ver, el SVP tiene un problema de cuello de botella bastante gordo: los gráficos que genera el chip en Virtua Racing se graban en una RAM externa (también en el cartucho) de 128KB. Pero para mostrarse en pantalla esos datos tienen que llegar al VDP de la Mega Drive, con lo que hace falta moverlos del cartucho a la VRAM (por DMA). El DMA es rápido pero no tan rápido como para mover datos como para llegar a 60fps, por eso en el caso de Virtua Racing el juego va a 15fps. He leído a desarrolladores homebrew que afirman que se podría llegar a 30fps con rutinas optimizadas de DMA, pero ahí ya me pierdo (de Mega Drive en sí no tengo mucha idea).

Dicho eso... cuando saqué los timings de las instrucciones mientras corren en el SVP, la gente de comunidades como Plutiedev parecían bastante sorprendidos y decían que el DSP que lleva el SVP es comparable a los SH2 de la 32X. Cuando el chip ejecuta instrucciones desde su memoria interna (no desde la ROM, que tiene accesos más lentos de lectura) va a más o menos 23MHz (con multiplicaciones en un ciclo de reloj además). Yo creo que con eso te montas un DOOM bastante cercano al de PC, si eres capaz de superar el problema del DMA que mencioné arriba.

Después ya entraría el tema de límites de espacio para los niveles, gráficos, etc... que eso ya es otra historia. Pero estoy seguro de que si alguien se pusiese nos sorprendería.

Aprovecho la mención para recordaros que tengo herramientas rudimentarias para desarrollar en el SVP (en hardware real) en este repositorio por si alguien está muy loco y se anima XD.


Por cierto:

que sepamos,el SVP solo mueve poligonos,entonces para un doom no creo que sirva
quiza en megacd si,teniendo en cuenta que lleva un motorola mas rapido que el de megadrive y lleva un modo 7....
en 32x debió existir algo mucho mejor que lo que sacaron,aun asi,lo que sacaron ya es muy superior al de snes...


Todo lo que hace el SVP es por software, el DSP en sí no tiene ni idea de lo que es un polígono (lo único que proporciona el chip realmente es un multiplicador de 16bits apañado). Tienes ejemplos de rutinas 3D en la wiki del repositorio que he enlazado antes (en el firmware interno que descubrí había rutinas básicas de rotación 3D para quads que no se llegaron a usar en el Virtua Racing al final).

Taiyou
Como molaria q un grupo de programadores se pusiera a hacer el doom con el svp,
Seguro q podrian sacar un cartucho con el chip emulado rn una minifpga sin q se dispare el precio [looco]
@PDragoon no lo había visto, gracias!
Yo por mi parte, decir que he seguido el hilo desde el principio del mismo, y quería dar las gracias a todos los que han aportado su visión sobre las posibilidades del chip a lo largo del mismo.

Siempre es un placer aprender sobre estas cosas para alguien como yo que no tiene ni idea. Mil gracias.

PD: Voté sí.
Doom en md/genesis con svp? si, superior al de snes? mmm...similar si, pero superior? en el papel pareciera que si, pero depende de varios aspectos del svp que aun desconozco. Por ejemplo puede el svp manejar roms superior a los 2MB?, las instrucciones, etc

En cuanto a los colores se puede acudir al uso de S/H para obtener mas colores adicionales,no solo incrementas el numero de colores sino que tambien el numero de "pasos" de los colores de 8 a 15. Eso es algo que ya he ideado hace un tiempo y consiste en usar un plano de fondo y el plano de sprites para generar hasta 60 colores(ademas de simular mas usando dhiter) usando 2 paletas, quedando 2 paletas mas, una para el arma y otra para la cara del jugador y el hud, pudiendo haber unos 90 colores en total, en el mejor de los casos.

Por los momentos dejo esto hasta aqui, pero mañana o el sabado voy a extenderme mucho mas para hablar sobre muchas cosas mas, por ejemplo sobre el doom de snes (sobre todo sobre el source code), sobre el sfx, el DMA , MIPS, un posible doom en una md/genesis sin chip [fiu] , etc...

[bye]
Una prueba de concepto E1M1 que me parece impresionante:
https://youtu.be/UGbrrrLdmrk

Le agregamos vitaminas SVP junto al talento de gente como gasega68k y... [babas] Yo lo veo!

Un saludo!
Me impresiona mas el doom de pc en megadrive a 1 frame cada 3 segundos, que cualquier pseudo doom mas fluído a cambio de un resultado gráfico que solo se parece al juego en detalles casi inexistentes.
@gasega68k , por fin opiniones con conocimiento de causa [tadoramo] . Esperando tus análisis y muchas gracias por compartir tu experiencia aquí sobre estos temas tan interesantes.

Interesante lo del número de COLORES en Mega Drive :-| .
@AxelStone
La arquitectura del motorola 68000 es cisc, no risc.
Que polémica con los colores... por poder, puede mostrar 512 colores reales en pantalla.
@Señor Ventura por cierto; viendo a Gasega por aquí me ha dado por leerle un poco y resulta que hace tiempo desmintió lo del límite de mapeo en Mega Drive: de facto la consola puede con roms de hasta 80 megabits sin necesidad de un mapper, que es casualmente la cifra que alcanza Paprium.

Fue justo aquí:

Megadrive/Genesis puede manejar mas de 32 mbit sin mapper, lo que sucede es que otras areas son usadas para sega cd, 32x, IO, VDP, z80 area, etc.

Esto es una parte del "memory map":
$000000-$3fffff = 4MB (ó 32mbit). este es el espacio para la ROM (cartucho).
$400000-$7fffff = 4MB (ó 32mbit). este espacio es usado para Sega/Mega cd.
$800000-$9fffff = 2MB (ó 16mbit). este espacio es usado para 32x.
...
Se puede usar todo este espacio para un total de 80MB sin mapper, si usas el espacio $400000-$7fffff, obtendrias 64mbit, pero ya no podrias usar sega/mega cd, ahora si usas el espacio $800000-$9fffff obtendrías los 80mbit, pero ya pierdes la posibilidad de usar 32x


hilo_ho-paprium-para-megadrive_2226898_s700#p1744728166

Y si lo dice este tío hay que creérselo.
@Sexy MotherFucker , según eso Paprium usa mapper sí o sí porque el juego está hecho para poder usar la Mega-CD como inteligencia artificial para el segundo jugador controlado por la máquina, así que según lo que dice, el juego usaría 32 megas mapeables con la MCD conectada al menos.
@stormlord sí bueno; Paprium es caso aparte, está dopado hasta las cejas de todo, sólo lo comentaba casualmente. En cualquier caso está bien ir aireando ese mito.

Da que pensar lo que por ejemplo podría haber sido un Super Street Fighter II en una MD a pelo con 1 ROM de 64 megabits en lugar de con el mapper/parche de 40 Megabits, podría haber salido prácticamente al mismo precio; aunque bueno ese juego lo que necesitaba más bien era una reprogramación desde 0 [+risas]
Sexy MotherFucker escribió:.... aunque bueno ese juego lo que necesitaba más bien era una reprogramación desde 0 [+risas]

Lamentablemente así es.
Según parece el super FX 2 puede direccionar 16 megas, pero la cpu puede añadir 32 megas mas (donde podría tener cabida todo el audio, menús, sprites, escenas de transición, y todo lo que no es estrictamente la parte "in game" en si), de forma que los mapas y toda la parte jugable podría contar con mas detalles.
Creo que es el único vídeo que hay en youtube sobre este doom.

Bueno, me tarde un poco mas de lo que pensaba... :p

Hola a todos, quisiera empezar por el Doom de Snes, desde que Randy Linden (el programador del juego) libero el codigo fuente del juego, me di a la tarea de leerlo con al menos dos cosas en mente, bueno en realidad tres: curiosidad, ver o ayudar a mejorar el rendimiento del juego, y la posibilidad de un port a Md/Genesis.
Gracias a este source (bueno tambien por otro source "librado", el del starfox) comencé por aprender sobre el chip fx, en realidad no fue tan dificil, una vez que aprendes a programar un cpu es mucho mas facil aprender otro, aunque sea muy diferente.
Algunos datos del sfx: 16 registros de 16 bits, r0 a r15, todos menos el registro r15 que es el PC (contador de programa), se pueden usar como registros de uso general, algunos de ellos se usan en instrucciones especificas por ejemplo la intruccion PLOT usa los reg. r1 y r2, las intrucciones de multiplicacion como fmult y lmult usan r4 y r6, etc.
Tambien hay otros registros especificos, por ejemplo como el PC es de 16 bits(esto significa que solo puede direcionar 64KB) hay un registro llamado RomB para seleccionar uno de los "bancos" de 64KB.

El sfx tiene una cache de 512 bytes que es una memoria rapida y que solamente cuando el codigo se ejecuta en esta ram es que se ejecuta mas rapido, es decir cuando una instruccion se dice que se ejecuta en un ciclo solo es posible en esta memoria cache, en este momento no recuerdo bien pero creo que es de 3 ciclos cuando lo hace en la Ram/Rom del juego.
Por lo que he visto del source de Doom, todas las rutinas importantes que requieren que se ejecuten rapido como el render/dibujado de las texturas de las paredes, de los sprites (objetos, enemigos...), rutinas de BSP, etc, se ejecutan en la cache.

Este juego pudo haber funcionado mas rapido, pero hay varias causas que lo impiden, una es la limitante de 2MB de la rom, otra es el uso del modo 3 que es un modo de 256 colores, con una resolucion de 216 x 144(en el area vision)que en realidad es de 108 x 144 porque cada 2 pixeles en X es el mismo, "gracias" a esto se duplico la cantidad de memoria que en realidad se necesitaria y por esto se necesita mas tiempo para actualizar un nuevo frame, limitando el framerate a un maximo de 20fps por mas que se mejore el engine.

Sobre la limitante de los 2MB de la rom: al principio no entendia muy bien el codigo de render/dibujado de las texturas de paredes, despues de un tiempo y al leer otras partes del source entendi que estaban comprimidas las texturas con un tipo de RLE, y es que no habia otra forma ya que aun asi solo para las texturas y sprites del juego(que estan comprimidas) ya se ocupan casi la mitad del juego (unos 900KB) y casi la otra mitad de la rom estan en los niveles :O . Aunque la rutina de descomprimir RLE son "rapidas" aun asi hubiera sido mucho mas rapido si no estuviera comprimido.


Al haber usado el modo 3 que es un modo con 8 bitplanes (256 colores) el uso de la instruccion PLOT se hace necesaria, pero para este caso no es muy eficiente, lo que tengo entendido sobre el PLOT es que primero esta intruccion dependiendo del modo de color (2bit, 4bit o 8bit)se ejecutara en unos 40 ciclos por pixel en el peor de los casos(en algunos sitios he visto que hablan de 80?), ahora cuando se dibuja en el mismo espacio de un area de 8x1 pixels, es decir en X de 0 a 7, 8 a15, 16 a 31...,etc y en la misma linea Y, la ejecucion del PLOT sera mucho mas rapida(creo que 1 ciclo), por ejemplo un PLOT que dibuja un pixel a X=9 y Y=20 y luego el siguiente PLOT para dibujar otro pixel esta en X=10 y Y=20, este segundo PLOT se ejecutara mucho mas rapido, pero el problema es que en Doom los pixeles se dibujan en columnas(es decir de arriba hacia abajo) y cuando ya vas a dibujar en la siguente columna ya no sera tan rapido, porque no estara en el mismo espacio de 8x1.

Si se hubiese usado el modo 7 seria mucho mejor, pero seria necesario una pequeña reduccion en la resolucion (unos 108x136), ademas si el sfx permitiera mas de 2MB en rom.

Quizas lo que vaya a decir ahora pueda causar polemica, pero hacer un port de este engine a MD/genesis sin chip no es tan descabellado, si se hace bien optimizado y ademas por no ser necesario comprimir ya que no estaria iimitado a 2MB, quizas funcionaria algo similar al actual de snes aunque con una resolucion menor, y obviamente tambien seria necesario una ram extra en el cartucho.

Como han dicho otros, los procesadores RISC como el sfx, las instrucciones son mas simples comparandolo con procesadores CISC, y generalmente se necesitan mas instrucciones para hacer lo mismo, por eso no es "justo" hacer comparaciones de MIPS entre 2 tipos diferentes de procesadores.


Tambien hay otros codigos fuentes diponibles de Doom, pero hay uno que por lo menos a mi me parece que es mas interesante y que se podria portar mas facil es uno de GBA que se viene haciendo mas recientemente.

Sobre el SVP, como dije antes aun no conozco lo suficiente sobre este chip, pero en teoria deberia ser mas eficiente que el sfx, y ademas que este chip solo se haya usado en un juego poligonal no significa no puede hacer otras cosas, es solo otro cpu mas como el sfx y ambos se pueden programar lo que uno quiere que haga.

Señor Ventura escribió:Este es un terreno farragoso. Snes tiene todas las ventajas aquí.

Cuando necesitas exceder 64KB, una memoria mas lenta con el doble de capacidad siempre va a ser mejor opción, por los siguentes motivos:
-No puedes tirar de ancho de banda para borrar/escribir mas veces un dato para compensar una memoria de menor capacidad.
-La velocidad de la ram de megadrive se va a tener que adaptar si o si a los 1,92mhz del bus del DMA, así que de nada sirven sus 5mhz y pico.
-La ram de la snes es lo suficientemente rápida teniendo en cuenta que encaja perfectamente con la velocidad de su bus: no hay cuellos de botella (las quejas con la ram de la snes se deben a que si fuese a 3,58mhz, el DMA podría ser también a 3,58mhz, no que existan cuellos de botella con respecto al DMA, porque no los tiene).

? De donde sacas eso de los 1.92mhz ? La Ram no esta "limitada" a 1.92mhz, y que tiene que ver el DMA aqui?
La ram de snes si esta limitada a 2.68mhz, esto quiere decir que aunque se usen fastrom (3.58mhz) acceder a la ram y/o ejecutar codigo en ram siempre sera a 2.68mhz.

Una pregunta, Ventura porque insistes tanto en las multiplicaciones del ppu? de verdad sabes como funciona?, es decir, eso siempre ha estado ahi, y por lo que te leo a veces me parece que tienes una idea errada de lo que es.

Bueno ya lo dejo hasta aqui, si me falto algo, o recuerdo algo mas que queria decir, vuelvo a escribir por aqui en uno o dos dias quizas.


Ah se me olvidaba, en unos dias quizas muestre algo (videos o imagenes) del nuevo engine de starfox de MD/Genesis.

Saludos.
gasega68k escribió:por lo que te leo a veces me parece que tienes una idea errada de lo que es.


Como ya he dicho, soy responsable de mis palabras, no de lo que nadie quiera entender.

Básicamente porque no he dicho nada, ni he entrado en detalles con los que afirmar si estos están mal.


Después de leer cosas como que snes+sfx=megadrive, yo creo que ya vale con la broma de que ventura no tiene ni idea.


Podría añadir un par de detalles a lo que has comentado (cosas que he leído de otros, no vaya nadie a pensar que los demás también están en este mundo para desarrollar algo), pero, ¿para que?, si este foro se merece bastante poco XD
En las normas pone que los usuarios deben respetarse entre sí, y el foro procurar que eso sea así. ¿Hasta qué punto es justo que al foro no se le respete, pero luego se pida su apoyo cuando vamos de ofendiditos?

Aquí no somos socios ninguno, ni estamos pagando cuota. Esto es gratis. En todo caso, es el foro el que no merece tener a lamers.

gasega68k escribió:Ah se me olvidaba, en unos dias quizas muestre algo (videos o imagenes) del nuevo engine de starfox de MD/Genesis.

Saludos.


Muchas ganas de verlo. Gracias a la gente que curráis en contenido y en aportes como estos. [Ooooo]
@_ThEcRoW Perdón tiene usted razón, estaba confundido por la cantidad tan pequeña de códigos que tiene comparado con el 8086, si mal no recuerdo, 58 vs 400, un número muy bajo más propio de un RISC.

No obstante la arquitectura RISC es antigua, tanto como la CISC, son filosofías diferentes simplemente.
gynion escribió:En todo caso, es el foro el que no merece tener a lamers.


Ni un mensaje ha tardado el primero en demostrar lo que digo.

En un foro en el que a la mas mínima siempre hay alguien dispuesto a insultarte o afear tus aportes, no se puede sentir que se merezca el esfuerzo de compartir nada.

Si esto te ofende, entonces no te comportes así. Mas que molestarte debería hacer reflexionar, porque las cosas no se dicen por nada, que los demás también son personas.
@Señor Ventura

No he mencionado a nadie. He leído que este foro merece bastante poco, y he dado mi opinión contraria, diciendo que lo que no merecen es tener a lamers que espantan a los programadores serios. Nada más. Como soy parte del foro, opino sin más.

Si tienes una idea nefasta del foro será porque hay mucho lamer, ¿no?
Es una idea constructiva, de verdad, para mejorar esto: menos hablar y más aportar. Y hasta aquí el off-topic.

Como tú mismo dices, " soy responsable de mis palabras, no de lo que nadie quiera entender."
El código fuente del doom de megadrve está en github.

No estaba equivocado, hay dos versiones, una que funciona en una megadrive de stock (1 frame cada 2 a 3 segundos), y otra que se sirve del FPGA para acelerar un poquito su rendimiento (1 a 2 frames por segundo).

Luego hay un tercer doom que se procesa enteramente desde el FPGA, que es la que se ejecuta a 30fps y 512 colores.


Doom port for Genesis/MegaDrive. Based on linux doom sources.
use Mega EverDrive PRO to run it
doom*.wad file from original game required. Put it to the game folder. Teseted with wad files from doom and doom2

doom-68k.md: This version does not have any optimizations and not use fpga for acceleration. Literally work on bare Genesis hardware as is.
Extended-SSF mapper used for available RAM expansion.
performance: one frame per 2-3 sec

doom-ed.md: This version has some optiomizations in code and use fpga for acceleration.
Math operations (mul/div) and few heavy rendering operations was accelerated using fpga.
8bit linear framebuffer transformation to 4-bit Genesis tile format by fpga "on the fly".
performance: 1-2 fps

This demos completely unplayable due the low fps and lack of palette transformation. I believe it can be done much better if i would have infinity time for working over fun stuff like that, but i gonna stop at this point
@Señor Ventura desconocía el de la versión que se apoya en la FPGA, pero no enteramente ¿Qué hace exactamente ahí la FPGA? ¿Actuar como una CPU o GPU de apoyo, pero no mucho?

El que funcionaba a 30fps y 512 colores ya se sabía que corría en la FPGA, aparte de por la sobrada de lo bien que se ve porque no es posible ejecutar esa versión en un flashcard ni chino ni varios de los caros de everdrive (no sé si hay algún último modelo que sí). Lo que me sorprende a estas alturas es que no se hayan puesto ya a meter emuladores en las FPGA para que la consola haga de "reproductor VHS" y la gente pueda pollagordear con que Megadrive/SNES podía correr juegos de PSX.
@gasega68k

Muy interesante, tu comentario, por fin se lee algo de DOOM en snes con conocimiento de causa (leyendo y estudiando el código fuente).

De lo señalado, me genera la duda de, si a tu criterio, ¿es posible mejorar u optimizar el juego en super nes?, ¿es decir consideras que hay campo de mejora? y si conoces si hay alguna persona o grupo que este trabajando en mejorar este port?

En el canal de modern vintage, en el cual el youtuber es programador señaló de forma casi categórica que no es posible mejora alguna.

Sobre el teórico port de doom a genesis, suena bastante interesante pero parece inevitable contar con hardware extra (en el caso Ram).

@Señor Ventura

Hace mucho que te leo (creo que incluso cuando tu usuario era ralph) y en general me parecen interesantes tus comentarios, pero resulta evidente tu desconocimiento del tema, no obstante, tienes aires de saber mucho por haber leído y repetir cosas que parecen en ocasiones sacadas de contexto o de plano sin sentido.

En el comentario de gasega68k se te hace preguntas claras que puedes responder, ya que sabes tanto, sobre el funcionamiento de la ram de snes o de la megadrive y del funcionamiento de los multiplicadores del ppu pero obviamente ignoras o decides no contestar con argumentos del tipo "este foro se merece bastante poco"

Ya que tienes las ganas de leer y aprender respecto del funcionamiento de la consola, te invito a que estudies sobre el tema y aprendas algo de programación. Algunos usuarios del foro así lo han hecho como Discoyer que es realmente un gusto leer sus opiniones y posts en general.

Por último, hace unos años era impensable tener juegos como mario kart o fzero funcionando en megadrive, lo mismo de un star fox que tiene el chip fx. Sin embargo, se ha demostrado mediante demos y juegos beta que al final lo impensable no es tan imposible.

Por otra parte, los ports de doom que hay para megadrive, claramente dice que se requiere de los wad originales y no tiene ninguna optimización, lo mismo o peor sería si se intentara lo mismo con snes.


Saludos
ChepoXX escribió:Saludos


Saludos.
101 respuestas
Archivado
1, 2, 3
Volver a Consolas clásicas