Xenocrisis para Super Nintendo/Famicom

dr apocalipsis escribió:

VempireX escribió:@Dr apocalipsis

🤣🤣🤣

🤣🤣🤣
Mejor así?
No hay nada como picarle al código para optimizar...😼 , te dejo el gatito a modo de fiera,

Te estás coronando, máquina.

Ese hack usa el MSU1 para reproducir la música, dejando libre toda la RAM del SPC para los efectos y las voces.

Buen ridículo te acabas de cascar después de venir perdonando vidas.

Picar código dice el figura.

...vale, entiendo, que eres de esos que si la snes lleva un chip de apoyo, es trampa y demas amarguras mentales...
Y claro, eso se hace solo, lo de que use el msu, quitar los "parones", quitar la mayoría de ralentizaciones, poder elegir a evil akuma y chunli clasica, que sea un hack ejecutado en emulador fiera!!! No? 🤣🤣🤣
Vas a dejar de hacerme perder el tiempo después de esta última contestación, SEEEGAAAAAAA!!!🤣🤣🤣

Qué bando es el que decís que está resentido?? 🙃

A ver, a mí lo que no me está quedando claro con todo lo que estáis contando es si el juego lo mueve la Super Nes tal cual o qué es lo que han hecho exactamente??

riffraff escribió:

dr apocalipsis escribió:

riffraff escribió:¿Dónde están tus excusas para justificar el flickering de los sprites de la serpiente?
¿Y tus ejemplos de menús de SNES con flickering?

El que va de "perdonavidas" seguramente seas tú, "máquina".

Uf, así mejor. Caretas fuera.

Ni con un bando ni con el otro, buen bingo te estás cascando.

Ni bingo ni pollas.

No se trata de "bandos", sino de tratar con respeto al resto de usuarios incluso cuando se equivocan, como tú.

Esto es muy fácil, figura, si entra menospreciando a otro usuario, I-rem, que ha sido en todo momento correcto y educado y sólo trata de aprender, que se atenga a que lo pongan en su sitio.

Y no vas tú a venir a dar lecciones de nada a nadie cuando tachas de "burradas" lo que te vas inventando que dicen los demás.

Así que relaja la raja.

@dr apocalipsis
En ningún momento e faltado el respeto al compañero, le e aclarado que se estaba equivocando en el porcentaje, cosa que tú has querido , y sigues queriendo, mal interpretar, metiendo mierda donde no la hay, así que como esto no es un emulador, es real life, te vas a la lista de ignorados, y reporte por seguir con tu proyecto de ensuciar absurdamente el hilo.

10 PRINT"dr apolipsis vs X"
20 GOTO10
RUN

offtopic:alguien que se lo pase sin continuar?

mcfly escribió:10 PRINT"dr apolipsis vs X"
20 GOTO10
RUN

offtopic:alguien que se lo pase sin continuar?

Este VS ya está ejecutando un parón permanente, xD
Contestando tu pregunta, solo a dobles y en fácil, solo tengo que reconocer, que no tengo pelotas.

VempireX escribió:...vale, entiendo, que eres de esos que si la snes lleva un chip de apoyo, es trampa y demas amarguras mentales...
Y claro, eso se hace solo, lo de que use el msu, quitar los "parones", quitar la mayoría de ralentizaciones, poder elegir a evil akuma y chunli clasica, que sea un hack ejecutado en emulador fiera!!! No? 🤣🤣🤣
Vas a dejar de hacerme perder el tiempo después de esta última contestación, SEEEGAAAAAAA!!!🤣🤣🤣

Si se está hablando de que hay un límite de memoria para cargar samples en el SPC700 de la Snes, que tiene dificultades para cargar nuevos samples en tiempo real sin congelar el sistema, y alguien concluye acertadamente que por eso hay parones al cargar voces, lo normal no es decirle que conoce poco de lo que habla y tratar de engañarle colando un hack que usa un chip externo para reproducir la música.

Y ahora reporta lo que quieras, que a tus faltas de respeto hay que añadir tu falta de honestidad.

Y, por supuesto, ya aparece el otro en comandilla a meter mierda.

Lautrec+ escribió:Qué bando es el que decís que está resentido?? 🙃

A ver, a mí lo que no me está quedando claro con todo lo que estáis contando es si el juego lo mueve la Super Nes tal cual o qué es lo que han hecho exactamente??

Estas preguntas aquí están fuera de lugar, aquí lo que importa es lo que es capaz de hacer la máquina aunque nunca lo haya hecho, pero como “yo” creo que es capaz, el juego que han hecho es una mierda, y más si lo comparas con el de Megadrive; no obstante en vez de intentar aprender, lo mejor es menospreciar las opiniones de los demás con explicaciones cogidas por pinzas .

GUSMAY escribió:

Lautrec+ escribió:Qué bando es el que decís que está resentido?? 🙃

A ver, a mí lo que no me está quedando claro con todo lo que estáis contando es si el juego lo mueve la Super Nes tal cual o qué es lo que han hecho exactamente??

Estas preguntas aquí están fuera de lugar, aquí lo que importa es lo que es capaz de hacer la máquina aunque nunca lo haya hecho, pero como “yo” creo que es capaz, el juego que han hecho es una mierda, y más si lo comparas con el de Megadrive; no obstante en vez de intentar aprender, lo mejor es menospreciar las opiniones de los demás con explicaciones cogidas por pinzas .

Buen resumen....

Lautrec+ escribió:A ver, a mí lo que no me está quedando claro con todo lo que estáis contando es si el juego lo mueve la Super Nes tal cual o qué es lo que han hecho exactamente??

Probablemente (no se puede saber porque el juego no funciona en emuladores), tanto la CPU como el chip de sonido han sido reemplazados por el coprocesador del cartucho, por lo que de la SNES sólo queda el chip gráfico, el cual no se ha aprovechado demasiado bien (sobre todo por el flickering que hay cuando no debería haberlo).

dr apocalipsis escribió:Y no vas tú a venir a dar lecciones de nada a nadie cuando tachas de "burradas" lo que te vas inventando que dicen los demás.

Así que relaja la raja.

Lo de "superponer dos o más secciones de un mismo plano en la misma horizontal con HDMA", lo siento, pero es una burrada, y no he sido yo quien se lo ha inventado.

Yo no tengo raja que relajar.

Y seguimos esperando tu explicación de por qué la SNES no puede con la serpiente en vertical y tus ejemplos de menús con flickering

riffraff escribió:

Lautrec+ escribió:A ver, a mí lo que no me está quedando claro con todo lo que estáis contando es si el juego lo mueve la Super Nes tal cual o qué es lo que han hecho exactamente??

Probablemente (no se puede saber porque el juego no funciona en emuladores), tanto la CPU como el chip de sonido han sido reemplazados por el coprocesador del cartucho, por lo que de la SNES sólo queda el chip gráfico, el cual no se ha aprovechado demasiado bien (sobre todo por el flickering que hay cuando no debería haberlo).

dr apocalipsis escribió:Y no vas tú a venir a dar lecciones de nada a nadie cuando tachas de "burradas" lo que te vas inventando que dicen los demás.

Así que relaja la raja.

Lo de "superponer dos o más secciones de un mismo plano en la misma horizontal con HDMA", lo siento, pero es una burrada, y no he sido yo quien se lo ha inventado.

Yo no tengo raja que relajar.

Y seguimos esperando tu explicación de por qué la SNES no puede con la serpiente en vertical y tus ejemplos de menús con flickering

No, hombre, no. Yo he puesto ejemplos de las limitaciones de Snes que explican que tenga dificultades con esa serpiente en concreto, tal cual está diseñada. Lo máximo que se puede hacer sin un debugger, especular.

A ti no te saca nadie de que, como no se supera el límite de sprites por línea, es que la PPU no se aprovecha, y lo que tú decidas es o no una burrada. Eso justo después de proponer balas de 32x32.

Aquí el que tiene que demostrar que la Snes puede con esa serpiente exacta sin flickear eres tú.

Lo que sabemos con certeza es que Bitmap Bureau, con la ayuda de una CPU órdenes de magnitud superior a la de Snes, no lo ha conseguido.

A partir de ahí que cada cual escoja su bando. Porque sí que los hay. El de las fantasías y esto es así porque yo lo creo y el del crudo silicio que hace lo que puede.

Pero el menú flickea en español ¿eh?

dr apocalipsis escribió:No, hombre, no. Yo he puesto ejemplos de las limitaciones de Snes que explican que tenga dificultades con esa serpiente en concreto, tal cual está diseñada. Lo máximo que se puede hacer sin un debugger, especular.

Cuando decías que los menús tenían flickering "por despiste" no parecía "especulación", sino una afirmación en toda regla.

dr apocalipsis escribió:A ti no te saca nadie de que, como no se supera el límite de sprites por línea, es que la PPU no se aprovecha, y lo que tú decidas es o no una burrada. Eso justo después de proponer balas de 32x32.

Repito lo que dije hace unos posts que por lo visto no te apetece o no te interesa leer:

riffraff escribió:- Y la mayoría de las balas deberían caber en un sprite de 16x16, no de 32x32.
- Por lo que he oído, el juego utiliza sprites de 16x16 y de 32x32. Muchas balas caben en sprites de 8x8, pero aún así he preferido hacer las cuentas con lo que he oído.

Sólo he utilizado la palabra burrada cuando se proponían burradas.

dr apocalipsis escribió:Aquí el que tiene que demostrar que la Snes puede con esa serpiente exacta sin flickear eres tú.

He rebatido todos los ejemplos que has puesto de limitaciones de la SNES, incluído el del menú con flickering "por despiste".
Eres tú el que se va por los cerros de Úbeda cuando no eres capaz de tener razón.

dr apocalipsis escribió:Lo que sabemos con certeza es que Bitmap Bureau, con la ayuda de una CPU órdenes de magnitud superior a la de Snes, no lo ha conseguido.

Una vez más, repito lo que dije hace unos posts:

riffraff escribió:Yo no dije [que hayan metido flickering aposta], dije que seguramente lo hayan dejado pasar porque no les sea rentable arreglarlo.

El flickering del menú no tiene excusa.

dr apocalipsis escribió:A partir de ahí que cada cual escoja su bando. Porque sí que los hay. El de las fantasías y esto es así porque yo lo creo y el del crudo silicio que hace lo que puede.

¿Por qué sigues hablando de bandos?
¿Cuántos años tienes?

dr apocalipsis escribió:Pero el menú flickea en español ¿eh?

Sí. Y aún no has puesto ejemplos de menús de juegos de SNES con flickering, "máquina"

Para poder comparar esas versiones,en lo bueno y lo malo,hay que jugar a las dos.La versión de megadrive,es
la razón de que exista este juego.
Algunas entradas del hilo,son puro aporte de calidad.Se nota que han exprimido las diferentes versiones.Al menos,en youtube.

dr apocalipsis escribió:La serpiente no es más grande en Snes.
La pantalla es más pequeña en Snes.

Han pasado 30 años y seguimos con el bulo de que los sprites son más grandes en Snes.

La snes necesita menos tiles de sprites para adaptar la relación de aspecto de la serpiente con respecto a la pantalla de la versión original del juego, esto implica menos memoria, y menor carga del line buffer. Pierdes resolución, aunque no siempre se va a notar esa pérdida.

Se entiende perfectamente lo que significa, así que te agradecería que no contamines lo que digo.

riffraff escribió:Y repites el invento:

HDMA no permite superponer dos o más secciones de un mismo plano en la misma horizontal. Ése es el invento. Para nada "la posibilidad es real".

Claro que si, lo que pasa es que lo desconoces, y crees que ya lo sabes todo.

Mira, a mí me gusta bichear y discutir de cuestiones técnicas de máquinas antiguas, no meterme en rifirafes absurdos.

Es obvio que el menú con flickering en español es un despiste, porque la solución es extremadamente sencilla y no necesita de ninguna intervención divina para ser arreglado. Es más, lo más seguro es que, si llegamos a ver una revisión, se solucione con un simple cambio de formato. Es sólo aceptar que la Snes tiene límites, que la Megadrive no tanto, a la hora de hacer menús en español y adaptarse a ellos. Puede que hasta sin chip extra.

Porque la alternativa sería que lo hubiesen hecho por joder, ahí escondido en un idioma minoritario, para hacer la puñeta.

Y ese es tu caballo de batalla, por el que guardo el más mediocre interés y por el que no tengo ganas de documentar la infinitud de errores que se encontraban en traducciones de la época.

Todos los hemos visto.

Señor Ventura escribió:

dr apocalipsis escribió:La serpiente no es más grande en Snes.
La pantalla es más pequeña en Snes.

Han pasado 30 años y seguimos con el bulo de que los sprites son más grandes en Snes.

La snes necesita menos tiles de sprites para adaptar la relación de aspecto de la serpiente con respecto a la pantalla de la versión original del juego, esto implica menos memoria, y menor carga del line buffer. Pierdes resolución, aunque no siempre se va a notar esa pérdida.

Se entiende perfectamente lo que significa, así que te agradecería que no contamines lo que digo.

Si lo peor es que estamos defendiendo lo mismo, el redibujado para adaptaro a la menor resolución y formato 8:7.

Pero hablando con propiedad: Haciendo el sprite más pequeño y asumiendo la pérdida de detalle. Porque el sprite es ahora mismo igual, no mas grande.

Ceñirse a los datos, aunque sea a costa de llevarle la contraria a alguien, no es contaminar. Y no comprar un relato averiado tampoco.

Ni siquiera en este atemporal patio de recreo.

Un saludo.

@riffraff
No pierdas el tiempo, se nota a la legua que solo quiere crear conflictos, andará aburrido.

Volviendo al tema del hilo, una diferencia entre versiones que veo que no menciona nadie, en lo jugable, es que en está versión, puedes disparar y hacer esquiva sin necesidad de soltar el botón, en mega te obliga a soltar el botón, para luego pulsar y hacer la esquiva.

Señor Ventura escribió:

dr apocalipsis escribió:La serpiente no es más grande en Snes.
La pantalla es más pequeña en Snes.

Han pasado 30 años y seguimos con el bulo de que los sprites son más grandes en Snes.

La snes necesita menos tiles de sprites para adaptar la relación de aspecto de la serpiente con respecto a la pantalla de la versión original del juego, esto implica menos memoria, y menor carga del line buffer. Pierdes resolución, aunque no siempre se va a notar esa pérdida.

Se entiende perfectamente lo que significa, así que te agradecería que no contamines lo que digo.

No, no se entiende, y nadie está "contaminando" nada.

La serpiente en las dos versiones tienen el mismo número de pixels, por lo que son del mismo tamaño. Punto.

Señor Ventura escribió:

riffraff escribió:Y repites el invento:

HDMA no permite superponer dos o más secciones de un mismo plano en la misma horizontal. Ése es el invento. Para nada "la posibilidad es real".

Claro que si, lo que pasa es que lo desconoces, y crees que ya lo sabes todo.

Sé de lo que estoy hablando.

Como tú no lo sabes y no confías en mí, te propongo dos opciones:
- O bien implementas un ejemplo de HDMA superponiendo dos o más secciones de un mismo plano en la misma horizontal (no vas a ser capaz ni siquiera de montar un ejemplo de HDMA).
- O bien mencionas ejemplos de juegos de SNES que hayan superpuesto dos o más secciones de un mismo plano en la misma horizontal con HDMA (tampoco los vas a encontrar, porque no se puede).

dr apocalipsis escribió:Mira, a mí me gusta bichear y discutir de cuestiones técnicas de máquinas antiguas, no meterme en rifirafes absurdos.

Es obvio que el menú con flickering en español es un despiste, porque la solución es extremadamente sencilla y no necesita de ninguna intervención divina para ser arreglado. Es más, lo más seguro es que, si llegamos a ver una revisión, se solucione con un simple cambio de formato. Es sólo aceptar que la Snes tiene límites, que la Megadrive no tanto, a la hora de hacer menús en español y adaptarse a ellos. Puede que hasta sin chip extra.

Porque la alternativa sería que lo hubiesen hecho por joder, ahí escondido en un idioma minoritario, para hacer la puñeta.

Y ese es tu caballo de batalla, por el que guardo el más mediocre interés y por el que no tengo ganas de documentar la infinitud de errores que se encontraban en traducciones de la época.

Todos los hemos visto.

Señor Ventura escribió:

dr apocalipsis escribió:La serpiente no es más grande en Snes.
La pantalla es más pequeña en Snes.

Han pasado 30 años y seguimos con el bulo de que los sprites son más grandes en Snes.

La snes necesita menos tiles de sprites para adaptar la relación de aspecto de la serpiente con respecto a la pantalla de la versión original del juego, esto implica menos memoria, y menor carga del line buffer. Pierdes resolución, aunque no siempre se va a notar esa pérdida.

Se entiende perfectamente lo que significa, así que te agradecería que no contamines lo que digo.

Si lo peor es que estamos defendiendo lo mismo, el redibujado para adaptaro a la menor resolución y formato 8:7.

Pero hablando con propiedad: Haciendo el sprite más pequeño y asumiendo la pérdida de detalle. Porque el sprite es ahora mismo igual, no mas grande.

Ceñirse a los datos, aunque sea a costa de llevarle la contraria a alguien, no es contaminar. Y no comprar un relato averiado tampoco.

Ni siquiera en este atemporal patio de recreo.

Un saludo.

Quien te ha dicho que solo pasa en español?.
Te sacas teorías que piensas tu y las adjudicas a los demás

mcfly escribió:

dr apocalipsis escribió:Mira, a mí me gusta bichear y discutir de cuestiones técnicas de máquinas antiguas, no meterme en rifirafes absurdos.

Es obvio que el menú con flickering en español es un despiste, porque la solución es extremadamente sencilla y no necesita de ninguna intervención divina para ser arreglado. Es más, lo más seguro es que, si llegamos a ver una revisión, se solucione con un simple cambio de formato. Es sólo aceptar que la Snes tiene límites, que la Megadrive no tanto, a la hora de hacer menús en español y adaptarse a ellos. Puede que hasta sin chip extra.

Porque la alternativa sería que lo hubiesen hecho por joder, ahí escondido en un idioma minoritario, para hacer la puñeta.

Y ese es tu caballo de batalla, por el que guardo el más mediocre interés y por el que no tengo ganas de documentar la infinitud de errores que se encontraban en traducciones de la época.

Todos los hemos visto.

Señor Ventura escribió:
La snes necesita menos tiles de sprites para adaptar la relación de aspecto de la serpiente con respecto a la pantalla de la versión original del juego, esto implica menos memoria, y menor carga del line buffer. Pierdes resolución, aunque no siempre se va a notar esa pérdida.

Se entiende perfectamente lo que significa, así que te agradecería que no contamines lo que digo.

Si lo peor es que estamos defendiendo lo mismo, el redibujado para adaptaro a la menor resolución y formato 8:7.

Pero hablando con propiedad: Haciendo el sprite más pequeño y asumiendo la pérdida de detalle. Porque el sprite es ahora mismo igual, no mas grande.

Ceñirse a los datos, aunque sea a costa de llevarle la contraria a alguien, no es contaminar. Y no comprar un relato averiado tampoco.

Ni siquiera en este atemporal patio de recreo.

Un saludo.

Quien te ha dicho que solo pasa en español?.
Te sacas teorías que piensas tu y las adjudicas a los demás

Que si en inglés pasa.

dr apocalipsis escribió:

mcfly escribió:

dr apocalipsis escribió:Mira, a mí me gusta bichear y discutir de cuestiones técnicas de máquinas antiguas, no meterme en rifirafes absurdos.

Es obvio que el menú con flickering en español es un despiste, porque la solución es extremadamente sencilla y no necesita de ninguna intervención divina para ser arreglado. Es más, lo más seguro es que, si llegamos a ver una revisión, se solucione con un simple cambio de formato. Es sólo aceptar que la Snes tiene límites, que la Megadrive no tanto, a la hora de hacer menús en español y adaptarse a ellos. Puede que hasta sin chip extra.

Porque la alternativa sería que lo hubiesen hecho por joder, ahí escondido en un idioma minoritario, para hacer la puñeta.

Y ese es tu caballo de batalla, por el que guardo el más mediocre interés y por el que no tengo ganas de documentar la infinitud de errores que se encontraban en traducciones de la época.

Todos los hemos visto.




Si lo peor es que estamos defendiendo lo mismo, el redibujado para adaptaro a la menor resolución y formato 8:7.

Pero hablando con propiedad: Haciendo el sprite más pequeño y asumiendo la pérdida de detalle. Porque el sprite es ahora mismo igual, no mas grande.

Ceñirse a los datos, aunque sea a costa de llevarle la contraria a alguien, no es contaminar. Y no comprar un relato averiado tampoco.

Ni siquiera en este atemporal patio de recreo.

Un saludo.

Quien te ha dicho que solo pasa en español?.
Te sacas teorías que piensas tu y las adjudicas a los demás

Que si en inglés pasa.

Si lees más atrás,pongo dos ejemplos donde hay flickeo en el menú y otros dos,donde no lo hay.
Esas teorías de conspiración o lo de la lengua minoritariia son solo tuyas.

mcfly escribió:

dr apocalipsis escribió:

mcfly escribió:Quien te ha dicho que solo pasa en español?.
Te sacas teorías que piensas tu y las adjudicas a los demás

Que si en inglés pasa.

Si lees más atrás,pongo dos ejemplos donde hay flickeo en el menú y otros dos,donde no lo hay.
Esas teorías de conspiración o lo de la lengua minoritariia son solo tuyas.

Es una chorrada y no pasa en inglés.

Si tanto os molesta, pues lo devolvéis.

No es motivo,en mi opnión,ni mucho menos,para devolver un juego.Pero resulta llamativo,que pueda pasar algo así,en 2024.

Que bonito hilo se está quedando, hay muchos números.

dr apocalipsis escribió:Es obvio que el menú con flickering en español es un despiste

No, no lo es, y por más que se te ha pedido que expliques por qué es tan obvio para ti, no has sido capaz de explicarlo. Lo más razonable (no obvio) es que no les ha dado la gana arreglarlo porque no les ha salido rentable, pero tú sigues con tus despistes.

dr apocalipsis escribió:Es sólo aceptar que la Snes tiene límites, que la Megadrive no tanto, a la hora de hacer menús en español y adaptarse a ellos. Puede que hasta sin chip extra.

La SNES puede mostrar menús sin flickering mucho más fácil que la Mega Drive, ya que al tener más fondos simultáneos, tiene menos motivos para usar sprites para menús.

Como no has sido capaz de mencionar juegos de SNES con menús con flickering, al ejemplo me remito

dr apocalipsis escribió:Porque la alternativa sería que lo hubiesen hecho por joder, ahí escondido en un idioma minoritario, para hacer la puñeta.

Una vez más, nadie ha dicho que lo hayan hecho por joder. Te estás montando la película tú solo.

dr apocalipsis escribió:Y ese es tu caballo de batalla, por el que guardo el más mediocre interés y por el que no tengo ganas de documentar la infinitud de errores que se encontraban en traducciones de la época.

Después de varias páginas, como no has sido capaz de encontrar ejemplos de menús con flickering, ahora de repente ya no tienes "el más mediocre interés". Bien, "máquina"

dr apocalipsis escribió:Es una chorrada y no pasa en inglés.

Si tanto os molesta, pues lo devolvéis.

Si no te gusta que se critique el port, no entres en el hilo.

Tú no eres quién para decirle a nadie lo que tiene que hacer con su dinero.

Pues eso.

Rifirafes.

dr apocalipsis escribió:Pues eso.

Rifirafes.

En español es con dos erres: https://dle.rae.es/rifirrafe

riffraff escribió:

dr apocalipsis escribió:Pues eso.

Rifirafes.

En español es con dos erres: https://dle.rae.es/rifirrafe

Se la ha comido el flickering de Snes.

dr apocalipsis escribió:

riffraff escribió:

dr apocalipsis escribió:Pues eso.

Rifirafes.

En español es con dos erres: https://dle.rae.es/rifirrafe

Se la ha comido el flickering de Snes.

Añade el italiano(otra lengua minoritaria),al flickering..

Qué bonita mi lista de ignorados. Desprende "¡¡¡SEEEGAAAAAA!!!" y Blast Processing por cada poro de su piel.

Este comentario parpadea como la serpiente.

Paprium escribió:Este comentario parpadea como la serpiente.

Este sería el de la versión de mega.Al estar en linea.

Si hay ports malos actualmente con juegos triple A de altísimo presupuesto programados por 1000 personas usando motores estándar; imagina un indie programado por un grupo pequeño con bajo presupuesto para un hardware antiguo y desfasado y no estándar sin herramientas ni entornos sencillos. Añadimos a la mezcla una máxima empresarial universal (máximo beneficio al mínimo coste posible) y tenemos resultados. No iban a ponerse a aprender cómo programar adecuadamente una SNES, les resultó más sencillo usar un ARM lo más barato y disponible posible que ejecute lo que quieren y de paso así poner palos en las ruedas a la piratería. Sencillo y barato.

Es una discusión que a poco que cualquiera sepa un mínimo de SNES y sus dificultades, y de cómo funciona la industria y este negocio, no debería ni tener lugar. Aquí yo aplicaría la máxima de mi viejo profesor de zoología en la facultad: no repetir ni centrarse en la base, porque se suponía que estando allí ya debías tener una base sólida de conocimientos y es sobre ellos que hay que seguir construyendo. A estas alturas cualquiera que sea habitual aquí o tenga interés en el retro de SNES, debe tener sí o sí esa base. Si no la tiene no es nuestra responsabilidad ni enseñarla ni mucho menos estar en debates circulares continuos sobre lo mismo en plan rotonda infinita.

Un saludo!

Falkiño escribió:Si hay ports malos actualmente con juegos triple A de altísimo presupuesto programados por 1000 personas usando motores estándar; imagina un indie programado por un grupo pequeño con bajo presupuesto para un hardware antiguo y desfasado y no estándar sin herramientas ni entornos sencillos. Añadimos a la mezcla una máxima empresarial universal (máximo beneficio al mínimo coste posible) y tenemos resultados. No iban a ponerse a aprender cómo programar adecuadamente una SNES, les resultó más sencillo usar un ARM lo más barato y disponible posible que ejecute lo que quieren y de paso así poner palos en las ruedas a la piratería. Sencillo y barato.

Es una discusión que a poco que cualquiera sepa un mínimo de SNES y sus dificultades, y de cómo funciona la industria y este negocio, no debería ni tener lugar. Aquí yo aplicaría la máxima de mi viejo profesor de zoología en la facultad: no repetir ni centrarse en la base, porque se suponía que estando allí ya debías tener una base sólida de conocimientos y es sobre ellos que hay que seguir construyendo. A estas alturas cualquiera que sea habitual aquí o tenga interés en el retro de SNES, debe tener sí o sí esa base. Si no la tiene no es nuestra responsabilidad ni enseñarla ni mucho menos estar en debates circulares continuos sobre lo mismo en plan rotonda infinita.

Un saludo!

Se agradece alguien sensato de vez en cuando por aquí

Falkiño escribió:Si hay ports malos actualmente con juegos triple A de altísimo presupuesto programados por 1000 personas usando motores estándar; imagina un indie programado por un grupo pequeño con bajo presupuesto para un hardware antiguo y desfasado y no estándar sin herramientas ni entornos sencillos. Añadimos a la mezcla una máxima empresarial universal (máximo beneficio al mínimo coste posible) y tenemos resultados. No iban a ponerse a aprender cómo programar adecuadamente una SNES, les resultó más sencillo usar un ARM lo más barato y disponible posible que ejecute lo que quieren y de paso así poner palos en las ruedas a la piratería. Sencillo y barato.

Es una discusión que a poco que cualquiera sepa un mínimo de SNES y sus dificultades, y de cómo funciona la industria y este negocio, no debería ni tener lugar. Aquí yo aplicaría la máxima de mi viejo profesor de zoología en la facultad: no repetir ni centrarse en la base, porque se suponía que estando allí ya debías tener una base sólida de conocimientos y es sobre ellos que hay que seguir construyendo. A estas alturas cualquiera que sea habitual aquí o tenga interés en el retro de SNES, debe tener sí o sí esa base. Si no la tiene no es nuestra responsabilidad ni enseñarla ni mucho menos estar en debates circulares continuos sobre lo mismo en plan rotonda infinita.

Un saludo!

Resumiendo, menudo coñazo con el flickering xD.

A jugar compañeros. Eso estaba, está y estará siempre en los juegos.

Falkiño escribió:No iban a ponerse a aprender cómo programar adecuadamente una SNES

Pues tócate los webs entonces, como dijo Lars Ulrich, necesitas a un batería que te enseñe a tocar la guitarra... Bien podían haberse pasado por EOL a pedir consejo, que aquí todo dios sabe de programación.

Menos cachondeos señores

@AtomicRobot-nik16 , la filosofía es esa, máximo beneficio con el menor esfuerzo posible.

A mi no me importa que se se explique cosas desde la parte técnica.Pero estaría bien demostrar lo que se dice con ejemplos.Porque así cada uno puede puede inventar/suponer,sin poder afirmar y llegar a dudar de la credibilidad de los demás(formas a parte).Ya hace muchos años,que decidí creer en lo que veo y pasar de conjeturas y rumores.
Hay cosas que son obvias y otras más difíciles de explicar( o de entender para algunos).

En lo relativo a esta versión(que parece que solo lo tenemos dos personas de aquí),de momento,me quedo en el boss de la quinta(forest),sin continuar y en fácil.Los niveles seis y siete,pegan un bajón de diseño,en cuanto a calidad de escenarios y enemigos.A nivel técnico,en lo bueno,se han incluido voces en la intro y estas suenan muy nítidas durante el juego.Se han incluído efectos en el suelo de la cuarta pantalla y efecto de lluvia en la quinta y no hay parones al empezar el nivel.Y,mención especial,al magnífico control consecuencia del diseño del mando de snes..
En lo negativo,la adaptación a la resolución ha disinuido la parte jugable de los escenarios,hay flickering en algunos idiomas en el menú de mejoras y hay más flickeo que en otras versiones.

@sevenator willkommen bei eol

Pues yo no podré probar esta versión porque ya tengo la de Mega, que es mi principal plataforma retro, y no se puede emular, me quedaré con las ganas. Pero sí creo que pusieron toda la carne en el asador en esa versión y todo lo demás son adaptaciones que intentar ser fieles a la primera sin aprovechar demasiado las características de los demás. Y creo que lo han hecho para rentabilizar el proyecto con mínimo esfuerzo. Lo de la música clama al cielo. Llevan todas la misma que la de Mega Drive a fuerza de meter la Banda sonora en mp3. Eso sí, se nota que los samples están a más calidad y suenan mas nítidos. Los fallos es por una adaptación con el mínimo esfuerzo, estoy seguro de que se podía haber hecho mejor. Al menos han adaptado la resolución, pero comiéndose un cacho de pantalla. Supongo que para hacerlo en condiciones tendrían que haber rehecho todos los gráficos y no estaban por la labor.

Con lo del SFA 2 de snes, se sabe desde hace eones que en ese caso, los parones eran para descomprimir los samples. No sé si llevaba más datos comprimidos. Por eso llevaba un chip SDD-1, para hacer esas tareas de descompresión. En los hacks, han metido la BSO en wav tirando de MSU-1 en un sd2snes, tengo ese hack en el mío. Ya no hay nada que descomprimir, o al menos, menor cantidad de datos ya que prescindimos de la BSO, así que ya no hay parones.

Falkiño escribió:Si hay ports malos actualmente con juegos triple A de altísimo presupuesto programados por 1000 personas usando motores estándar; imagina un indie programado por un grupo pequeño con bajo presupuesto para un hardware antiguo y desfasado y no estándar sin herramientas ni entornos sencillos. Añadimos a la mezcla una máxima empresarial universal (máximo beneficio al mínimo coste posible) y tenemos resultados. No iban a ponerse a aprender cómo programar adecuadamente una SNES, les resultó más sencillo usar un ARM lo más barato y disponible posible que ejecute lo que quieren y de paso así poner palos en las ruedas a la piratería. Sencillo y barato.

Es una discusión que a poco que cualquiera sepa un mínimo de SNES y sus dificultades, y de cómo funciona la industria y este negocio, no debería ni tener lugar. Aquí yo aplicaría la máxima de mi viejo profesor de zoología en la facultad: no repetir ni centrarse en la base, porque se suponía que estando allí ya debías tener una base sólida de conocimientos y es sobre ellos que hay que seguir construyendo. A estas alturas cualquiera que sea habitual aquí o tenga interés en el retro de SNES, debe tener sí o sí esa base. Si no la tiene no es nuestra responsabilidad ni enseñarla ni mucho menos estar en debates circulares continuos sobre lo mismo en plan rotonda infinita.

Un saludo!

No estoy de acuerdo con eso de que snes es un hardware desfasado. Solamente fue tan avanzado que todavía no ha nacido la generación de programadores que descifren su poder real. En cuanto la doten del idioma de programación perfecto para sus circuitos, se disparará su poder y por fin ese fórmula 1 podrá salir a pista. Ahora mismo es como el capitán américa cuando estaba latente congelado en el hielo

@Johibe En el SFA2 los parones no son para descomprimir nada. Si fuera así no habría parones ya que el chip de descompresión hace muy bien su trabajo. Por lo que dice MVG en su video parece ser que los samples eran más grandes de lo necesario y eso hacía que tardara más tiempo en cargarlos. Con el patch de MSU-1 se hace streaming directamente y se salta este paso. Por lo que dice seguramente no se preocuparon mucho del tema de sonido debido a que la máquina estaba ya "muerta" y querían sacarlo lo antes posible. Seguramente se podría hacer un patch mejor que no tire de MSU-1 y cargue samples al vuelo tal como se hizo en Actraiser, o incluso reducir el tamaño de estos si fuera necesario.

Xfactor escribió:

Falkiño escribió:Si hay ports malos actualmente con juegos triple A de altísimo presupuesto programados por 1000 personas usando motores estándar; imagina un indie programado por un grupo pequeño con bajo presupuesto para un hardware antiguo y desfasado y no estándar sin herramientas ni entornos sencillos. Añadimos a la mezcla una máxima empresarial universal (máximo beneficio al mínimo coste posible) y tenemos resultados. No iban a ponerse a aprender cómo programar adecuadamente una SNES, les resultó más sencillo usar un ARM lo más barato y disponible posible que ejecute lo que quieren y de paso así poner palos en las ruedas a la piratería. Sencillo y barato.

Es una discusión que a poco que cualquiera sepa un mínimo de SNES y sus dificultades, y de cómo funciona la industria y este negocio, no debería ni tener lugar. Aquí yo aplicaría la máxima de mi viejo profesor de zoología en la facultad: no repetir ni centrarse en la base, porque se suponía que estando allí ya debías tener una base sólida de conocimientos y es sobre ellos que hay que seguir construyendo. A estas alturas cualquiera que sea habitual aquí o tenga interés en el retro de SNES, debe tener sí o sí esa base. Si no la tiene no es nuestra responsabilidad ni enseñarla ni mucho menos estar en debates circulares continuos sobre lo mismo en plan rotonda infinita.

Un saludo!

No estoy de acuerdo con eso de que snes es un hardware desfasado. Solamente fue tan avanzado que todavía no ha nacido la generación de programadores que descifren su poder real. En cuanto la doten del idioma de programación perfecto para sus circuitos, se disparará su poder y por fin ese fórmula 1 podrá salir a pista. Ahora mismo es como el capitán américa cuando estaba latente congelado en el hielo

Que curioso.He leído lo mismo de otros sistemas.

XFactor escribió:No estoy de acuerdo con eso de que snes es un hardware desfasado. Solamente fue tan avanzado que todavía no ha nacido la generación de programadores que descifren su poder real. En cuanto la doten del idioma de programación perfecto para sus circuitos, se disparará su poder y por fin ese fórmula 1 podrá salir a pista. Ahora mismo es como el Capitán América cuando estaba latente congelado en el hielo

No me extraña. El mundo de la retro informática está lleno de curiosas curiosidades, para curiosos que les encanta la curiosidad. Así que sí, curiosamente estoy de acuerdo

@MasterDan Gracias por la información, se ve que tenía una idea equivocada. Probablemente de lo que dijo la Hobby Consolas hace casi 30 años, jeje.

MasterDan escribió:@Johibe En el SFA2 los parones no son para descomprimir nada. Si fuera así no habría parones ya que el chip de descompresión hace muy bien su trabajo. Por lo que dice MVG en su video parece ser que los samples eran más grandes de lo necesario y eso hacía que tardara más tiempo en cargarlos. Con el patch de MSU-1 se hace streaming directamente y se salta este paso. Por lo que dice seguramente no se preocuparon mucho del tema de sonido debido a que la máquina estaba ya "muerta" y querían sacarlo lo antes posible. Seguramente se podría hacer un patch mejor que no tire de MSU-1 y cargue samples al vuelo tal como se hizo en Actraiser, o incluso reducir el tamaño de estos si fuera necesario.

La causa es el driver de sonido.

@Señor Ventura ¿cómo van los ejemplos de juegos de SNES que hayan superpuesto dos o más secciones de un mismo plano en la misma horizontal con HDMA?
¿Y tu demo?

Creo que hemos tenido un pequeño error de comunicación: estaba esperando a que contases cual es el motivo por el que no es posible.

No hacía falta que te explicara yo nada para que aportaras ejemplos de juegos de SNES que hayan superpuesto dos o más secciones de un mismo plano en la misma horizontal con HDMA.

Tampoco hacía falta que te explicara yo nada para que hicieras una demo, pero bueno, como no has sido capaz de ninguna de las dos cosas, te explico:

HDMA permite cambiar el estado de la PPU (entre otras cosas) al inicio de cada línea horizontal de la pantalla (en el H-Blank).
Si un fondo es visible sólo en una línea horizontal de la pantalla, con HDMA puedes replicarlo en todas las horizontales, una vez por horizontal.

Lo que no permite HDMA es replicar el mismo fondo en la misma horizontal, ya que se ejecuta sólo antes de renderizar la horizontal, no muchas veces por horizontal.

Si tu invento fuera posible, desde el 1990 han pasado muchos años para que lo mostraran multitud de juegos y demos.

Pero es que aunque fuera posible, las secciones de la serpiente se superponen, por lo que la PPU tendría que "rebobinar" (volver hacia atrás) para pintar todas las secciones con el mismo fondo. Una burrada, vamos.

Una vez más, si no confías en mí, te invito a que menciones ejemplos de juegos de SNES que hayan superpuesto dos o más secciones de un mismo plano en la misma horizontal con HDMA, o bien a que implementes tu propia demo.

Buenas
A mí me gustaría que los que tengan el juego en casa ya, y le dieran candela jugando, se pongan en contacto conmigo por privado, para poder hablar de un problema del juego, y contrastar opiniones; por ejemplo por discord, (es tema de audio), y una vez sacadas las conclusiones, comentarlas por aqui abiertamente, saludos retrocompis.

"Esto no se puede hacer porque no se puede hacer" no es una explicación válida. Lo que te estoy diciendo es que para poder decir que conoces a la perfección el funcionamiento de algo hasta el punto de reirte de alguien, lo mínimo esperable es, ya ni siquiera un diagrama pormenorizado, sino que dejes claro cuales son sus conceptos básicos como para explicar por qué no es posible, pero en lugar de eso incluso tu explicación sobre lo que es el hdma es MUY vaga.

Con estos preámbulos te permites dar lecciones. Yo no puedo dar lecciones, y aún así puedo dejar en evidencia que has sido arrogante sin podértelo permitir.


HDMA es un bus que comparte físicamente su espacio con el DMA, pero entra en funcionamiento mediante un registro indicado en su propia tabla ($420C). Basta con cambiar el valor de un bit para activar una "cola de tareas" al final de cada scanline, y es el principal responsable de que el primer scanline de la snes no forme parte de la particuar resolución activa (256x239), ya que es el período de tiempo en que esa tabla está siendo formateada para su utilización al principio de cada frame,

Las transferencias quedan programadas al principio de la pantalla activa, y cada una de las 224 o 239 transferencias se realizan mediante 8 canales, lo que permite cambiar el estado de 8 registros de los ppu's en una sola transferencia horizontal, y la clave para el efecto que comento podría estar en la capacidad del HDMA de cambiar sus registros con una IRQ vertical.

Mal explicado, pero a nada que entiendas de que va esto una vez que he mencionado las IRQs, a grandes rasgos lo único que te distancia de hacer cosas extremadamente complejas, es la capacidad de la cpu para hacer interrupciones... PERO, eso se soluciona con un procesador de apoyo.



¿Quieres un ejemplo de un juego comercial, que no es lo que estoy comentando de la serpiente del xeno crisis, pero que comparte concepto?. Ahí va: