[Hack] Super Mario Kart - Fullscreen Edition [ACTUALIZADO a v1.5]

Responder
1, 2
Gracias por la nueva actualización @Psicopompo [beer]
psicopompo escribió:@yuragalo Gracias. Estáis siendo de mucha ayuda. 🤜🏻🤛🏻

El problema de Lakitu ya está solucionado, y de rebote, otro similar que ocurría en el modo de dos jugadores.

La velocidad respecto al original son prácticamente iguales en las pruebas que ha hecho la IA, aunque no a puesto a prueba todos los circuitos ni todas las situaciones. Las diferencias en dichas pruebas son mínimas. Igualmente voy a ver si se puede optimizar aún más, pero esto es ya por capricho.

Subiré el parche de aquí a un rato, cuando termine de comprobar algunas cosas. Pero ya no veo nada que haya que arreglar.

EDITO: Ya está actualizado el parche en el mensaje inicial. A ver si esta vez es el último. 😑

v1.3
  • Lakitu ya no asoma por la parte inferior de la pantalla. Primero hubo que corregir que su cabeza y su nube sobresalieran por abajo al desplazarse desde la parte superior o al volver a subir (por ejemplo, en Ghost Valley o durante las caídas al agua). Después aparecieron sus tres putos pelos, pequeñas piezas sobrantes que permanecían dibujadas tras abandonar la pantalla o después de un rescate, y que también han sido corregidas.
  • En 2P, la moneda de Lakitu y las monedas que pierde el jugador ahora se dibujan a la altura correcta, en lugar de aparecer 88 píxeles más abajo.
  • Se ha reducido la carga de CPU en 1P. En la salida de carrera más exigente de las probadas, el pico de uso baja del 95,7 % al 90,5 %, frente al 89 % de la versión original.


Que rápido lo has solucionado todo. Muchas gracias [oki]
Él, no. La IA [carcajad] Es broma ;)

Enhorabuena por el hack, es de los que realmente rompen moldes. Y en tiempo récord, a mi parecer.

No he podido probarlo todavía, pero por lo que comentan los compañeros, va fino fino, y espero poder jugarlo en la Wii, ya que no tengo flashcart en la SNES.

¿Te puedo hacer un encargo? XD
@Dene está muy wapo compa, más que recomendable; en mi caso al principio se me hizo extraño por el mayor campo de visión y la sensación de ángulo diferente de cámara pero te haces enseguida [beer]

Y una gran ventaja que le veo, no estar pendiente cada dos por tres del retrovisor, parece que no pero quita mucha presión en 150cc cuando están cada dos por tres dando porculo, ahora solo estar pendiente del sonido de los motores y ya.
@Dene Pídeselo a la IA, a ver si te lo hace. 😁 Es broma. 🕺🏼 Ahora en serio, pide por esa boquita. Si puedo, me pongo a ello. El problema es que justo ahora llevo cuatro proyectos a la vez: dos hacks y dos traducciones. Un de ellos, de hecho, es una sugerencia de varios usuarios.
La IA está muy bien pero no le quita ni un ápice de valor al trabajo, ganas, insistencia y demás a quien trabaja las cosas. En este caso yo no valoro que Psicopompo pueda o no ser un genio, que seguro que lo es. Es de valorar el trabajo y por supuesto el tener a bien compartir ese producto de su tiempo con todos nosotros. Ni con IA ni sin ella la gran mayoría de nosotros no hacemos un pong de los 70.
Este hack es uno de los mayores retos que había y ahora es realidad
@psicopompo Ya comienzan a circular gameplays por ahí.

Dejo uno, v1.2 (ya disponible v1.3) ;

La verdad es que tiene una pinta espectacular! @psicopompo [beer]

La SNES no la tengo aquí, pero en cuanto pueda, enchufo la rom en el RGB-Pi y lo cato en un CRT como se merece.
@Xfactor Gracias. 🤜🏻🤛🏻 No soy ningún genio, pero sí que hay que echarle horas. De hecho, en este proyecto casi echo la pota dos veces —y no es coña: empecé a tener sudores fríos y el estómago colapsó 😂— por la cantidad de horas que llevaba concentrado y pegado a la pantalla.

Lo que sí hace falta es tener muy claro cuál es el destino, saber qué va a necesitar la IA en cada momento y adelantarse a ello, saber salir de un atasco cuando ni la propia IA sabe por dónde salir, intuir cuál puede ser el origen de un problema aunque no tengas ni puta idea de programación, editar gráficos —y esto me toca bastante, sobre todo en proyectos como el Momotaro Katsugeki o el Nekketsu Soccer MD, donde tuve que tirar mucho de pixel art—, tener paciencia, detectar errores y saber dónde buscarlos, proponer ideas creativas para adaptar lo que parece inadaptable, plantear ideas aunque inicialmente parezcan tonterías (esto desatasca muchísimo más de lo que se cree), seguir la cadena de razonamiento de la IA y frenarla en seco cuando ves que la va a cagar, cosa que todavía hace a menudo...

En definitiva, sin la IA no haces nada —hablo de Vibe Coding—, pero ella sola no saca adelante un proyecto ni de coña. No es simplemente pedir y esperar el resultado y, de hecho, ni siquiera es solo dirigir: hay que aportar bastante más de lo que se ve desde fuera. Y creo que todo el mundo puede hacerlo si se pone a ello con decisión.

Sobre este tipo de cosas estuvimos hablando en este hilo, y la cosa se calentó bastante. 🥊💢

@Kim Hwan Guay, así ya no tengo que subir yo uno para el usuario que lo había pedido. Gracias.
yuragalo escribió:@Dene está muy wapo compa, más que recomendable; en mi caso al principio se me hizo extraño por el mayor campo de visión y la sensación de ángulo diferente de cámara pero te haces enseguida [beer]

Y una gran ventaja que le veo, no estar pendiente cada dos por tres del retrovisor, parece que no pero quita mucha presión en 150cc cuando están cada dos por tres dando porculo, ahora solo estar pendiente del sonido de los motores y ya.


Más ganas me vienen de jugarlo. Igual lo podríamos proponer para juego del mes.

psicopompo escribió:@Dene Pídeselo a la IA, a ver si te lo hace. 😁 Es broma. 🕺🏼 Ahora en serio, pide por esa boquita. Si puedo, me pongo a ello. El problema es que justo ahora llevo cuatro proyectos a la vez: dos hacks y dos traducciones. Un de ellos, de hecho, es una sugerencia de varios usuarios.


Lo comenté en otro hilo, mi hack soñado sería el Bare Knuckle III con una banda sonora decente al estilo del SoR y SoR 2. Importante tomar como base la rom japonesa que es más justa con el jugador y el tema de los colores de la ropa.

No sé si es posible trasladar los temas de los primeros juegos, y ponerlos en los escenarios que mejor casen o si hay alguna remezcla hecha.

Dejando de lado la petición, porque en realidad tampoco soy nadie para ir pidiendo nada, desde tu experiencia, ¿te parece factible?

Saludos.
@psicopompo y algo de pasta si quieres resultados inmediatos...
@blade133bo Lo cierto es que no estoy invirtiendo nada en IA, ni un céntimo. En el pasado probé la suscripción de Claude, pero aún siendo de pago te dura un suspiro. Lo que hago es usar un montón de servicios para diferentes cosas. Por supuesto, con una suscripción de las de 200€ todo esto se agilizaría más.

@Dene Sí, leí que varios lo comentábais. A priori no creo que suponga demasiado problema (aunque siempre los hay). Le echaré un vistazo y haré alguna prueba, y si da buenos resultados ya os preguntaré sobre las pistas que queréis (a mí me da completamente igual mientras al menos sean de la saga). Pero primero quiero terminar unos cambios de última hora al Super Mario Kart porque estoy intentando que el tamaño de los personajes en función de la distancia sea más correcto.
@psicopompo Sería tremendo. 1000 gracias.
@psicopompo

Mil gracias por el curro. SMK es uno de mis juegos preferidos de siempre, y uno de los que más trillados tengo 👏🏻👏🏻👏🏻👏🏻👏🏻👏🏻

Con ganas de probarlo a ver qué tal la experiencia, aunque ya me hago una idea leyendo las impresiones del compañero @yuragalo, que creo que pilota bastante.
@psicopompo podrias agregar algun circuito de Mario Kart: Super Circuit, lanzado para Game Boy Advance en 2001 a este hack ?

Creo que donde pone FullScreen Edition PSICOPOMPO tendria que poner:

FullScreen Edition - Hack developed by PSICOPONGO

Comentan en los videos lo siguiente:

Bien, pero hay una preocupación por la perspectiva.
Los personajes de delante tenían que ser pequeños y los
que estaban a su lado o al menos cuando nos acercábamos
debían hacerse más grandes.
Hay una inversión, de ahí este lado inquietante.
Ostras estoy suscrito al canal de Hack Games Longplay Channel, de hecho lo ha puesto nuestro compi @Kim Hwan, y cuando he visto que el autor era @psicopompo pensé: "¿Será o no será?" He venido aquí y sí era nuestro psicopompo y bueno que decirte muchas gracias por tu curro.

Es que hay que ponerse por mucho que se utilice IA (no sé si es el caso), no es tan fácil como decirle oye hazme un hack de Mario Kart que se vea a pantalla completa, hay que estar encima, siempre.

Saludos.
Alien_crrpt escribió:@psicopompo podrias agregar algun circuito de Mario Kart: Super Circuit, lanzado para Game Boy Advance en 2001 a este hack ?

Creo que donde pone FullScreen Edition PSICOPOMPO tendria que poner:

FullScreen Edition - Hack developed by PSICOPONGO

Comentan en los videos lo siguiente:

Bien, pero hay una preocupación por la perspectiva.
Los personajes de delante tenían que ser pequeños y los
que estaban a su lado o al menos cuando nos acercábamos
debían hacerse más grandes.
Hay una inversión, de ahí este lado inquietante.


Sí, estoy en ello. Espero tenerlo listo. El problema está en los rivales inmediatamente cercanos.

Sobre la firma, lo miraré. En realidad quería dejarla lo más discreta posible, pero hay quien se ha quejado de que en blanco no se lee bien. Al final la pondré más grande que el título y en fluorescente. 😂

@AlterNathan Este juego es bastante puñetero, sobre todo con el tema que estoy abordando ahora, el de la perspectiva de los personajes.
Gracias a ti, amigo.
@psicopompo Supongo que el resto de personajes toma el tamaño maximo , donde estaba el personaje con la pantalla dividida al principio. Por eso pasan de pequeños a grandes y luego a pequeños otra vez.

Para solucionarlo abria que bajarlos como hicistes con el personaje que controlamos. Suena muy facil, a ver que pasa en realidad.
@Alien_crrpt En realidad cambian de tamaño en función de la zona en la que estén respecto al jugador. Al ocupar ahora la pantalla entera, esas zonas de cambio de tamaño hay que redistribuirlas porque en el original el horizonte está muy abajo.

Para hacer bien el cálculo de dónde ha de cambiar de tamaño un rival hay que imaginar que ponemos el suelo del juego de frente, como si fuera una pared. Esto es lo que los programadores llaman proyección inversa (yo me enteré ayer, buscando información), en lugar de estar tumbado.

El espacio total de esa pared (la distancia real de la pista desde que el coche sale de la pantalla por abajo hasta que se pierde en el horizonte) mide X (lo que sea) de distancia real.

Si dividimos esa distancia real en partes iguales nos valdrá para posicionar de forma precisa la marca en la que los rivales van cambiando de tamaño mientras se alejan o tú les recortas distancia. Pero, claro, esta división solo nos vale en una pared para hacer el cálculo equitativo. En la realidad tenemos esa cosa llamada perspectiva. Así que, con las mediciones hechas, toca volver a inclinar el suelo en el Modo 7 para que esa lógica funcione en la perspectiva correcta. Al inclinar de nuevo el plano, esas líneas se comprimen y en las zonas más alejadas se dan más cambios de tamaño de manera más rápida. Ese es el motivo de que los rivales más cercanos tarden más en reducir su tamaño, por eso hay que recalcularlo.

Es decir, que no se trata simplemente de poner líneas horizontales a ojo y decir: "cuando un rival sobrepase esta línea reduce su tamaño". Sí, podría funcionar, pero no sería preciso. Toda esta mierda es la que toca readaptar a la pantalla completa.
@psicopompo
Aún no he podido probarlo pero anoche si vi un vídeo y también me fijé en lo del tamaño de los personajes rivales. Entiendo que es complicado, como comentas. No sé si ayudaría en algo usar como “template” algunas partes del código del F-ZERO, esencialmente entiendo que es un escenario muy similar. Supongo que ya estaba pensado, dado que son juegos hermanos, y que uno surgió como respuesta a la ausencia de 2P del primigenio.

De nuevo gracias por el curro.
@aleroh @psicopompo de perspectiva no he notado nada, cuando estoy en carrera procuro fijarme solo en el circuito [tomaaa]

Por cierto, me dio por usar Bowser y el tema de Lakitu con este personaje sigue apareciendo cuando caes al vacío (nuse si influirá el tamaño de personaje), supongo que con DK Jr. pasará igual pero tengo que probar.

Como casi siempre suelo usar a Koopa Troopa no lo había visto [sonrisa]

PD: pues con DK no lo hace, probaré con el resto de corredores

PD2: solamente me lo hace con Bowser, asoma Lakitu un instante por debajo antes de hacer la animacion correcta.

EDITO: en versión 1.4 time trial los tiempos totales y récord no se muestran correctamente (puede que en las anteriores tampoco, me acabo de dar cuenta). Adjunto imagen y estado para snes9x
@yuragalo @aleroh @Alien_crrpt Gracias a todos. Ya lo tengo todo. A ver si puedo subir hoy el parche.

Sobre lo del tamaño, he estado midiendo todo píxel a píxel, y tengo que decir que la gente que comenta lo de esos cambios, se equivoca, pero con razón. Los sprites del juego son de 32x32, pero cuando los personajes giran, sus cuerpos se ven ligeramente más estrechos, dando esa impresión de que se han reducido, pero siguen midiendo 32x32 porque la anchura en esos casos la marcan las ruedas de los karts. Pero los sprites del juego son los que son, y ahí no puedo hacer nada.

En la vista a pantalla completa quizá esa ilusión óptica se acentúe más, pero es igual que en el original. Esta ilusión óptica es parecida a la del propio tamaño de Mario en pantalla partida. En este último caso, parece que Mario es más grande porque está pegado completamente al borde inferior de la pantalla, el horizonte está más bajo y la pantalla es más pequeña, pero el tamaño de Mario es exactamente el mismo.

Ejemplo 1:
Imagen Imagen
En ambas imágenes, Mario mide 28 x 30 px (dentro de un sprite de 32 x 32).

Ejemplo 2:
Imagen Imagen
Donkey, por defecto (al igual que en la vanilla), mide 30 px de ancho, pero solo 29 px en uno de sus frames al girar. Lo que realmente engaña no es ese píxel de diferencia, sino ver a los rivales algo más estrechos cuando giran el cuerpo, especialmente cuando están a nuestra altura o por detrás. Pero es que es así.

Todo eso no quita que el tamaño de los rivales tuviera que ajustarse, cosa que ya he hecho (aunque esas capturas son anteriores).
De lujo esas explicaciones [tadoramo] [tadoramo]
psicopompo escribió:@Alien_crrpt En realidad cambian de tamaño en función de la zona en la que estén respecto al jugador. Al ocupar ahora la pantalla entera, esas zonas de cambio de tamaño hay que redistribuirlas porque en el original el horizonte está muy abajo.

Para hacer bien el cálculo de dónde ha de cambiar de tamaño un rival hay que imaginar que ponemos el suelo del juego de frente, como si fuera una pared. Esto es lo que los programadores llaman proyección inversa (yo me enteré ayer, buscando información), en lugar de estar tumbado.

El espacio total de esa pared (la distancia real de la pista desde que el coche sale de la pantalla por abajo hasta que se pierde en el horizonte) mide X (lo que sea) de distancia real.

Si dividimos esa distancia real en partes iguales nos valdrá para posicionar de forma precisa la marca en la que los rivales van cambiando de tamaño mientras se alejan o tú les recortas distancia. Pero, claro, esta división solo nos vale en una pared para hacer el cálculo equitativo. En la realidad tenemos esa cosa llamada perspectiva. Así que, con las mediciones hechas, toca volver a inclinar el suelo en el Modo 7 para que esa lógica funcione en la perspectiva correcta. Al inclinar de nuevo el plano, esas líneas se comprimen y en las zonas más alejadas se dan más cambios de tamaño de manera más rápida. Ese es el motivo de que los rivales más cercanos tarden más en reducir su tamaño, por eso hay que recalcularlo.

Es decir, que no se trata simplemente de poner líneas horizontales a ojo y decir: "cuando un rival sobrepase esta línea reduce su tamaño". Sí, podría funcionar, pero no sería preciso. Toda esta mierda es la que toca readaptar a la pantalla completa.



Según la explicación que me has dado, has duplicado la escala de la imagen principal, pero no la del plano de los enemigos (la zona que define si se ven grandes o pequeños). Si duplicas esa capa y la desplazas hacia abajo, el problema se solucionará. ( hablando desde el desconocimiento )

Viéndolo como una estructura por capas: ampliaste la capa visible, pero no la capa inferior, que controla el tamaño de los enemigos. Una vez que la escales, habrá que comprobar si hace falta recolocarla o no.

psicopompo escribió:@yuragalo @aleroh @Alien_crrpt Gracias a todos. Ya lo tengo todo. A ver si puedo subir hoy el parche.

Sobre lo del tamaño, he estado midiendo todo píxel a píxel, y tengo que decir que la gente que comenta lo de esos cambios, se equivoca, pero con razón. Los sprites del juego son de 32x32, pero cuando los personajes giran, sus cuerpos se ven ligeramente más estrechos, dando esa impresión de que se han reducido, pero siguen midiendo 32x32 porque la anchura en esos casos la marcan las ruedas de los karts. Pero los sprites del juego son los que son, y ahí no puedo hacer nada.

En la vista a pantalla completa quizá esa ilusión óptica se acentúe más, pero es igual que en el original. Esta ilusión óptica es parecida a la del propio tamaño de Mario en pantalla partida. En este último caso, parece que Mario es más grande porque está pegado completamente al borde inferior de la pantalla, el horizonte está más bajo y la pantalla es más pequeña, pero el tamaño de Mario es exactamente el mismo.

Ejemplo 1:
Imagen Imagen
En ambas imágenes, Mario mide 28 x 30 px (dentro de un sprite de 32 x 32).

Ejemplo 2:
Imagen Imagen
Donkey, por defecto (al igual que en la vanilla), mide 30 px de ancho, pero solo 29 px en uno de sus frames al girar. Lo que realmente engaña no es ese píxel de diferencia, sino ver a los rivales algo más estrechos cuando giran el cuerpo, especialmente cuando están a nuestra altura o por detrás. Pero es que es así.

Todo eso no quita que el tamaño de los rivales tuviera que ajustarse, cosa que ya he hecho (aunque esas capturas son anteriores).


Y tampoco has duplicado el tamaño de los rivales ni del personaje principal.

Resumen de la perspectiva de lo que está pasando:

Falta modificar la zona de ampliación y reducción: seguramente tengas que doblar el alto manteniendo el ancho, tal como doblaste las líneas. Y bajar la zona.

También falta modificar los sprites de los personajes; lo mismo: doblar el alto y mantener el ancho.
Podrias usar capturas de pantalla de la version de N64 y capturas de tu rom hack para calcular una proporcion aproximada. Ahora que los dos juegos tienen la misma resolucion. O mirar este Demake pasando el juego de Mario Kart 64 a SuperNes


Perdona que sea tan directo , es que siempre voy demasiado al grano. sorry. Muchas gracias por el pedazo de trabajo que estas haciendo.

Veo que ya has ajustado el tamaño de los rivales. Entonces con ganas de ver la nueva version en funcionamiento !!!
Da gusto leer este hilo. Gracias por el curro @psicopompo [beer]
@Alien_crrpt No termino de entender a lo que te refieres con lo de duplicar.
@psicopompo Le he pedido a Gemini que lo explique ella, ya que yo soy muy torpe explicándome (ahora sí lo ha dejado claro). A continuación, pongo dos explicaciones de por qué está fallando el aumento o disminución automática de los rivales según si están lejos o cerca de nosotros. Y me parece a mí que le está sucediendo lo mismo al personaje que manejamos, que se ha quedado con el tamaño mínimo.

Imagen


1º Explicacion:
La imagen es una infografía dividida en cuatro paneles que explica visualmente por qué los enemigos en el hack de Mario Kart SNES tienen un tamaño incorrecto y cómo solucionar el problema de la escala matemática al pasar a pantalla completa.

* **Arriba a la izquierda (Perspectiva original en pantalla partida):** Muestra cómo funciona el juego original de Super Nintendo. La pantalla está dividida por la mitad. La lógica matemática que calcula si un enemigo debe verse grande o pequeño (Scaling Logic) está limitada y configurada exclusivamente para funcionar dentro del recuadro de la mitad superior.


* **Arriba a la derecha (Intento actual a pantalla completa):** Ilustra el error que estás experimentando. Aunque has logrado que la pista (el circuito en Modo 7) ocupe toda la pantalla, los enemigos como Bowser siguen atrapados en la lógica antigua. El juego sigue calculando su tamaño basándose en el límite de la antigua pantalla superior, por lo que se ven diminutos y mal posicionados en relación con el nuevo entorno.


* **Abajo a la izquierda (Explicación por capas):** Muestra el origen técnico del problema visualizándolo en 3D. Tienes una "Capa Visual" (la pista) que ya ocupa el 100% de la pantalla, pero por debajo existe una "Capa de Lógica" invisible. Esta capa de lógica sigue dividida en dos zonas antiguas (zona superior e inferior) y no coincide con la imagen que estás viendo.


* **Abajo a la derecha (Solución correcta):** Representa lo que hay que hacer a nivel de código o datos. Debes unificar esa capa lógica invisible y estirarla verticalmente para que abarque toda la pantalla, al igual que hiciste con la imagen de la pista. Al aplicar una única zona de escala continua, el juego calculará correctamente que el enemigo es muy pequeño en el horizonte y debe ir haciéndose progresivamente más grande hasta llegar a la parte inferior de tu nueva pantalla completa.


2º Explicacion:
----------------------------
Explicacion de como antuan el aumento o disminutcion del tamaño de los rivales segun en que linea de la pantalla se encuentre de las 224 lineas

Esta infografía es una guía técnica excelente que detalla cómo funciona el "Modo 7" de la SNES y los desafíos que presenta para un "hack" de pantalla completa. A continuación, te explico detalladamente lo que sucede con el escalado de los rivales si no se corrige la lógica, basándonos en la línea de escaneo (scanline) en la que se encuentran, dado que la pantalla tiene un total de 224 líneas desde arriba hasta abajo:

El Efecto de las Líneas de Escaneo en un Hack No Corregido
Como se muestra en el Panel 1 (Perspectiva original de pantalla partida), el juego original está dividido físicamente y lógicamente en la línea ~112. Las matemáticas que calculan el tamaño de los rivales (Scaling Logic) solo están programadas para funcionar en la mitad superior de la pantalla (líneas 0 a 111). La mitad inferior (líneas 112-223) no tiene esta lógica porque antes solo mostraba un mapa estático.

Si no se corrige esta lógica, esto es lo que sucede:

Zona Superior (Líneas de Escaneo 0 a ~111): Escalado Distorsionado y Diminuto

Como se ve en el Panel 2 (Intento actual: Modo 7 a pantalla completa), el fondo de Modo 7 (la pista) se ha estirado verticalmente para ocupar toda la pantalla.

Sin embargo, la lógica de escalado de los rivales (como Boxer) sigue "atrapada" en los parámetros de la pantalla pequeña original.

Consecuencia por línea: Un rival que esté, por ejemplo, en la línea 50, se calculará con el tamaño que tendría en la línea 50 de la pantalla partida (donde parecería estar a la mitad de la pista). Pero en la pantalla completa estirada, la línea 50 está mucho más cerca del horizonte. El resultado es que el rival se ve diminuto, mucho más pequeño de lo que dictaría la perspectiva de la pista estirada. A medida que se acerca (baja por las líneas), crecerá, pero muy poco a poco, mucho menos de lo que debería. (Esto es lo que visualiza el Panel 2 con un Boxer "diminuto"). Un rival en el horizonte (líneas 0-20) sería casi invisible o un solo píxel.

La "Línea del Corte" (Línea de Escaneo ~112): El Fin abrupto de la Lógica

Esta línea es el límite donde termina la lógica original. Al cruzar esta línea, el juego no sabe qué hacer.

Zona Inferior (Líneas de Escaneo ~112 a 223): "Escalado Congelado" y Sin Perspectiva

Como visualiza el Panel 3 (Explicación: Capas y lógica dual), la capa lógica simplemente no existe para estas líneas inferiores.

Consecuencia por línea: Al cruzar la línea del corte (línea ~112), es muy probable que el juego "congele" el último valor de escalado válido. Esto significa que el rival dejará de crecer. Se moverá de lado a lado por la pantalla, pero con un tamaño de sprite estático, como un cartón recortado. Si cruza esta línea y sigue bajando (acercándose más), no crecerá, lo cual rompería completamente la inmersión y la perspectiva 3D del Modo 7. (Por ejemplo, si un Boxer pequeño pasara la línea 112, se quedaría pequeño el resto de la pista). El Panel 3 lo llama "ZONA INFERIOR (SIN ESCALADO)". Si el rival se acercara más allá de esta línea, su tamaño no cambiaría.

En resumen: Sin la corrección, los rivales se moverían por un mundo Modo 7 que tiene una perspectiva completa (como se ve en el Panel 2), pero sus sprites se comportarían de forma errática. Serían demasiado pequeños en la mitad superior y se "congelarían" en tamaño al cruzar el límite antiguo de la mitad de la pantalla, volviéndose imágenes de tamaño fijo en un mundo que sigue teniendo perspectiva.

La Solución Correcta (Panel 4) es unificar y re-escalar verticalmente la lógica para que sea continua de la línea 0 a la 223, permitiendo que el rival crezca progresivamente y de forma correcta en perspectiva, desde ser diminuto en el horizonte hasta tener un tamaño completo cerca de la parte inferior de la pantalla.
@Alien_crrpt

Gracias por tomarte el tiempo de preparar la explicación, pero, por lo que hemos comprobado en el código, el problema no consiste exactamente en una capa de escalado dividida que haya que fusionar. Mode 7 transforma el fondo, mientras que los karts utilizan once tamaños de sprite predefinidos, seleccionados según su profundidad proyectada. El selector revisado no tiene un corte en la antigua mitad de la pantalla.

He ajustado la distribución de esos tamaños para la vista fullscreen, y así dar más recorrido a los tamaños grandes y concentrar los pequeños cerca del horizonte, evitando que los rivales parezcan diminutos demasiado pronto. En la versión vanilla esto daba igual porque la perspectiva era casi plana, pero con la inclinación en la fullscreen no es coherente.

El reparto de tamaños de la v1.3 estaba heredado, en gran medida, de la vanilla, y quedaba de la siguiente forma:

v1.3 con el reparto (parcial) de la versión vanilla
Imagen

En realidad, hice bastantes pruebas para ajustar bien el reparto, pero la IA metió la gamba y calculaba solo cuatro cambios de tamaño, no los once que realmente son y las divisiones que realiza no reflejaban una exponencial, que es lo que había que aplicar para los once tamaños.

Reparto geométrico:
Imagen

Son una representación de los límites de tamaño, no dos capas internas del juego.

Ya he validado este reparto, corregido el fallo de Lakitu en Ghost Valley reportado por @yuragalo y otra cosa que he visto en el modo a dobles (la sombra de Lakitu al dar la salida en el P2 no salía —el mamón ha estado en la mitad de los errores que me he encontrado 😂—). En un rato actualizo el parche. 👍🏻

@yuragalo Solo me das alegrías, cabrón. 😆 Ahora miro lo de la tabla de resultados en el Time Trial.

Ya está solucionado. He comprobado que el arreglo no afectara a los resultados de la carrera normal, pero están bien. Dadme un momento y subo la v1.5.

Imagen

EDITO: Ya he actualizado el parche a la v1.5. A ver si esta vez es la buena.

También he subido este vídeo al mensaje inicial.

@psicopompo Muchas gracias. Le metes modo online y hacemos un torneo.

Lo que siento , es que al estirar la pantalla , parece que les falta mas resolucion o aumento de los personajes. Como si se ubiesen quedado pequeños , al ampliar la pantalla.

Imagen
78 respuestas
Responder
1, 2
Volver a Consolas clásicas