Hilo de detalles y curiosidades de N64

BMBx64 escribió:Aún así menudo cuello de botella se iba a generar con eso

Se rumoreaba que la CPU iba a ir a 105Mhz, eso sería si el RCP fuera a 70Mhz

Expande esto porfa, creo que te lo he leído alguna vez y nunca he acabado de entender por qué la velocidad de un procesador tiene que "armonizar" con la del otro, o con la del bus de memoria.

Gracias

@Sexy MotherFucker
En el caso de N64 las frecuencias las provee el oscilador X2 Crystal para la mayoría de componentes, si entras en este vídeo puedes ver una pequeña descripción, además de un ligero overclock (no solo la CPU que es la que lleva el multiplicador)
https://www.youtube.com/watch?v=M2o-REsQx7s

Goldeneye parece que no saca bien el framerate, sobretodo en el segundo test que tiene en youtube donde aplica un +25%.

--
Aprovecho la respuesta para hablar de algunas funciones que he implementado en libdragon.. aunque intentaré volver a los aportes normales en las siguientes réplicas.

GET_PIXEL
No me ha parecido que ésta función esté disponible para el usuario final, así que he montado un churro tal que así.

En graphics.c:


Función: Permite obtener el color de un buffer (ej. de pantalla) en una posición X,Y, vale... para que quiero esto? Bueno se le pueden sacar muchas utilidades, como tener una tabla de colores y acceder fácilmente a uno, lo cual se puede ver en el típico menú de selección de coche donde puedes cambiarle el color utilizando un cuadro con un cursor.

O para esto..



Así que montamos un simple test:


Pasamos el ratón por encima de los colores y se van visualizando en el rectángulo, los colores se obtienen como valores de 16bits o 32bits, luego se extrae el componente RGB, pero no es necesario para las funciones internas.

La primera cosa que he visto es que el modo RGB en la libdragon para 16bits es 555 en lugar de 565, lo que vienen a ser 32768 colores en pantalla en lugar de 65K, concretamente en esta conversión:


Ese mismo código me ha servido para revertir un color con valor de 16bits y extraer los componentes RGB por separado:


Para saber como revertirlo primero tuve que encontrar el valor de las máscaras de RGB, ese "0xF800" es el valor hexadecimal de 63488 que tengo anotado a la derecha y como he sacado ese valor? Pues viendo que valores dejaba libdragon en su conversión de color:


OTRAS FUNCIONES
- Permitir al usuario tener acceso al buffer de pantalla para crear nuevas funciones.
- Se puede usar como mapa de colisiones, get_pixel lee en el momento exacto el estado del buffer, así que se podrían pintar zonas de "color" donde un personaje puede pasar o no y luego taparlas con el propio renderizado del juego.
- Efectos especiales: Se puede usar para copiar información de zonas concretas de la pantalla para efectos especiales, como poner un poco de deformación encima de una antorcha o para mover bloques, aunque sería mucho más rápido copiar y mover zonas de memoria del buffer.

CONTROLES
Joystick - Ratón
A - Pone fondo de pantalla sobre el color elegido
Z - Reset a fondo negro
R - Alterna color de las fuentes de blanco a negro

DESCARGA
Link mega

Vale, esto ha sido un tostonazo pero quería anotarlo en algún lado ya que apenas he encontrado información sobre conversiones de 16bit a RGB, también creo que pronto podré empezar a sacar demos con efectos gráficos avanzados con deformaciones, zooms y demás

Algo para alucinar es que libdragon no trae de serie poder girar a la izquierda un sprite/textura

@BMBx64 menudo cáncer la libdragon, y con razón la señal RGB en N64 es tan mediocre en algunos casos.

Gracias eternas por tu trabajo. No es mi máquina favorita, pero da esperanzas que con aportes de gente como tú la scene despegue en algo impresionante.

Felicidades, excelente hilo, de los pocos que me he leído entero. Soy nulo en cuestiones de programación y tales, pero es interesantisimo ver información técnica o comparaciones.

Un saludo para BMBx64, ojalá te animes y sigas haciendo hilos con la misma temática.

Se agradece , tengo pendiente una comparativa de Ocarina y Majoras Mask, también me han pedido por ahí que le eche un vistazo al Goemon.

@Sexy MotherFucker
Suele pasar, libdragon tiene cosas muy buenas, incluso algunas escritas en ensamblador, pero su fuerte no es estar orientada para juegos, más bien parece soporte básico y arranca desde ahí.

- No soporta ningún tipo de semitransparencia en 16bits, solo en 32bits (que es como poco el doble de lento)
- No se puede espejar un sprite
- No se puede rotar un sprite
- Tengo que probar la función de escalado pero me espero lo peor..
- No soporta centros virtuales

Con esas cosas arregladas ya tendríamos algo medianamente decente para hacer 2D, principalmente si se hacen por hardware, porque el RDP las soporta, si se implementan por software van a ser poco practicas, pero faltan más.

Como referencia para implementar funciones estoy usando Div2/Fenix/Bennu, un lenguaje cojonudo y muy fácil de usar, así que de paso puedo probar los tests en PC y asegurarme que va a funcionar exactamente igual en consola sin ir con la SD para arriba y abajo, he añadido 4 funciones:
- fget_angle (ej: para que una nave puede disparar en el ángulo del objetivo)
- fget_dist(devuelve distancia entre 2 puntos, en un beat em up por ejemplo si hay 2 jugadores, el enemigo puede saber el más próximo)
- get_distx y get_disty (estos sirven para el siguiente test)

DEFORMACIÓN
La imagen de la tele no se ve demasiado bien pero hay un gif más abajo, es una prueba del escenario en llamas de Last Blade 2 + deformación.


Como aún no tengo funciones de raster sobre el buffer he utilizado texturas horizontales gigantes (320x4), así puedo mover cada bloque por separado.

- Libdragon no permite texturas de más de 256 de ancho, imagino que de largo lo mismo, pasadas esa cifra vuelve a repetir la textura o la invierte, vale perfecto, ya tengo una idea de como invertir sprites engañando con el tamaño , de paso probamos el modo gráfico 256x240, con el framerate desbloqueado arroja más de 300fps, nada mal.

En lugar de usar tablas se calcula en tiempo real y los valores pueden modificarse con los siguientes controles para ver diferentes combinaciones:
C izq / C der = Cambiar onda
C arriba / C abajo = Cambiar radio
A / B = Modificar velocidad
R = Ocultar texto



DESCARGAR
https://mega.nz/#!UpIBkJBb!TqZc9F3V8lZSpkxQoYp_T_QbyrhSNQcu29zsYVEpews

Lo cual me lleva a pensar que tendría que hacer un hilo dedicado de programación en N64 y separarlo de este

BMBx64 escribió:...
Lo cual me lleva a pensar que tendría que hacer un hilo dedicado de programación en N64 y separarlo de este

Pues ahora que dice eso y visto que usas cosas del lenguaje div/fenix/bennu para libdragon, me he acordado que vi que BoMbErLiNk (creo que a muchos os sonará) esta haciendo un editor de Tiles para PC y Nintendo 64 (Se llama Tileditor64)

http://forum.bennugd.org/index.php?topi ... 5#msg68705

Igual entre los dos os podeis ayudar

Ya parecen que estan saliendo copias de juegos de n64

¿Pronto veremos mods que funcionen en n64?? xD
Lo digo porque encontre esto
https://nintendocn.es.aliexpress.com/st ... 5.1.lTiQGN

Y el master quest nunca salio en n64

Como sean como las repros chinas de Snes al final acabaran jodiendo la consola igual...

@John3d
Pues de momento me fui a preguntar a los foros de krikzz, incluso en nesdev sin mucha suerte, la scene en N64 es inexistente tal como dicen , igual me vendría bien pasar por los foros de bennu

Pero ya he conseguido implementar el espejado por hardware , luego cuando tenga un rato hago un ejemplo (o edito este post si nadie responde ).

ESPEJADO POR HARDWARE
En lugar de espejar la textura al cargarla he pensado que sería más inteligente al dibujarla, así puedes usar cosas como simetría axial sin recargar la textura (ej. con la mitad de un árbol lo volteas y haces la otra, o una montaña)

Para extraer los datos he tenido que hacerle debug a libdragon, he creado las funciones rdp_command y rdp_send que permiten comunicarse directamente con el RDP (son simplemente un wrapper, ya vienen en la librería), esto me permite desde código normal poder hacer pruebas internas, sin tener que recompilar la librería en cada intento (y luego el ejemplo con ella)

Las texturas parece que usan potencia de 2 lo cual permite compatibilidad directa con el espejado del RDP, el mario son 16x31, que redondea hacia 16x32, si fuera 16x34 lo haría a 16x64, en los huecos redondeados se visualiza basura, así que hay que hacer un set de las variables s/t acorde.


El rendimiento es exactamente el mismo con espejado que sin él, así que lo he dejado siempre activado y he reducido aún más algunas funciones, rdp_load inicialmente era así:
rdp_load_texture (uint32_t texslot, uint32_t texloc, mirror_t mirror_enabled, sprite_t *sprite)

Ahora solo acepta la ruta del sprite y pista (además es más rápida):
rdp_load_texture ( sprite_t *sprite )

Los flags del espejado son como lo hacen Fenix/Bennu (nuevamente):
0 - Normal
1 - Horizontal
2 - Vertical
3 - Ambos

Cambios realizados en rdp.c:


Y en la función de dibujado, primero realice un fix, si un sprite sale por la izquierda hasta el punto que queda completamente fuera la consola se cuelga, esto es algo que el programador debe controlar, por rendimiento es tontería ir cargando texturas que no se van a ver y intentar pintarlas para que se descarten por no entrar en el buffer, pero cuando el debug y trazado de errores es casi inexistente mejor que exista:


Aquí el trozo que realiza el espejado, he intentado utilizar desplazamiento de bits en lugar de multiplicar y el mínimo de código posible, la diferencia entre un flags 3 y un flags 0 (sin espejar) es casi inexistente.


Función:


Probamos la función de escalado conjuntamente con el espejado, puess scale_y... bien no?


Oh noes, ya decía yo.. scale_x descuadra, lo bueno es que funciona mal incluso sin mi código, voy a tener que investigar como arreglarlo.


Pero me esperaba un resultado mucho peor, el fix parece sencillo y ya tendríamos scaling complejo (doble eje con precisión de coma flotante) y espejado por hardware.

Flash-Original escribió:Ya parecen que estan saliendo copias de juegos de n64

¿Pronto veremos mods que funcionen en n64?? xD
Lo digo porque encontre esto
https://nintendocn.es.aliexpress.com/st ... 5.1.lTiQGN

Y el master quest nunca salio en n64

Las roms de Master Quest corren en una N64 usando el flashcard, al parecer no programaron los juegos para GC sino que programaron un emulador de N64. Y sí, lo más probable es que si salen mods, ports, etc viendo lo que ya hay para NES y SNES también acabarán sacándo para N64. El problema es que pocas tradus, mods, etc hay para N64 (Yo me conformaba con roms modificadas para eliminar los filtros gráficos y algún hack 16:9)

@Calculinho

Pero no sabia que ya se podian hacer copias que esa era la cosa..

Flash-Original escribió:@Calculinho

Pero no sabia que ya se podian hacer copias que esa era la cosa..

Bueno, yo no sabía que ya se hacían; pero no creo que haya tenido dificultad más que pillar las roms de GameCube y volcarlas a una memoria rom. Lo digo porque en el flashcard de N64 es lo que se hace. A lo mejor si les escribes y les pasas la rom de algo que quieras te hacen un cartucho con la misma, he leído que juegos de NES, SNES,etc traducidos a mucha gente se los han hecho. Yo estoy tentado a pedir que me hagan un Sweet Home traducido al inglés

hasta donde yo se, no hay repros de N64 por que no se conoce ninguna eprom compatible.

@BMBx64 sólamente
Ánimo y a seguir así. Queremos ver esa demo!!!

@BMBx64 Me mola lo que veo y lo que leo tanto tecnico como el resultado
¿como se hace para las animaciones de los sprites?

Flash-Original escribió:@BMBx64 Me mola lo que veo y lo que leo tanto tecnico como el resultado
¿como se hace para las animaciones de los sprites?

He montado una herramienta en Windows que lo hace todo, le estoy haciendo interfaz que es más fea que pegarle a un padre, pero funcional, dame unos días y la haré pública.


Lo que hace:
- Crea texturas de N64 a partir de un PNG
- Lee una carpeta PNG y convierte todos los PNG que encuentra en textura
- Trocea en dimensiones compatibles con la TMEM de N64
- Si el sprite es impar, deja un espacio para hacerlo par
- Verticalmente trocea en múltiplos de 2, que es como funciona la libdragon, recorta 4,8,16,32, 64 etc
- Optimiza tamaño, si puede colar un sprite como textura única lo hace, si no puede utiliza los principios de máxima prioridad a rellenar TMEM para hacer el mínimo de llamadas, si el sprite es de 256x256 te lo trocea en 256x8 en modo 16bits (4KB) si es modo 32bits lo hará a 256x4, el programa ajusta según la profundidad de color.
- Todos los archivos que crea los renombra por orden estratégico, que es esto?

A la hora de cargar los sprites desde N64 sería un coñazo si cada uno se llamara diferente, que los vas a llamar uno a uno ocupando cientos de líneas? La idea es llamarlos numéricamente, desde distintas carpetas si son diferentes personajes, algo así:


- Permite separar en carpetas cada sprite por separado, dado que 1 solo sprite podría estar compuesto de muchas texturas
- Puede incluir también el png recortado, en caso de que queramos ver qué ha hecho la herramienta
- Tiene 2 modos de recortado, PNG a sprite da por hecho todo lo anterior, PNG a tilemap interpreta de otra manera
* Con el tilemap no se utiliza el máximo del ancho posible, utiliza dimensiones de tipo 64x32 o tamaños personalizados, dado que entiende que se trata de un fondo "tileado" y no de un sprite
- Si añadimos la opción incluir código, además nos hará un array del mapa que hemos montado con todas las posiciones de los tiles, este modo además analiza los tiles recortados y los compara, si el tile es repetido los descarta, es decir, esta función convierte automáticamente una imagen PNG en un tilemap con el tileset preparado y hasta el código necesario preparado, solo hay que montar un scroll para visualizarlo.

--
Esto es la primera etapa de la herramienta, la segunda es visualizar "qué ha hecho", en ella podemos ver la composición de los sprites, separados con rectángulos (como la imagen del SOTN), pero también podemos añadir animación y visualizarla, con ticks de animación personalizados.

Además, utiliza la cabecera de hslices y vslices para puntos de control, que son funciones que he eliminado que pertenecen a stride (cargar texturas grandes y recortarlas en tiempo real, pero que repercuten en el rendimiento), así podemos alinear desde esta herramienta los sprites y la libdragon que he editado interpretará automáticamente los nuevos centros leyendo esos hslices y vslices en la consola, sin tener que trabajar con coordenadas extra.

@BMBx64
Cuando lo subas trasteare
Si incluyes el codigo fuente para saber mas o menos que hace cada cosa te lo agradeceria para entender un poco mas
¿Lo del audio se ha podido separar del programa principal?No se puede dividir en subrutinas para que cargue archivos de manera constante quiero decir de un audio en vez de cargar los 45kb que seria el audio que cargue constantemente 1kb del sonido aprovechando la cache que alababan mucho la rapidez de la consola

En el e3 han mostrado el nuevo Mario Odyssey donde puedes controlar o poseer enemigos con la gorra, resulta que un hábil programador también ha metido eso en Super Mario 64

Dejo el vídeo:
https://www.youtube.com/watch?v=YGcsVQB1NAA

--
@Flash-Original
Para el audio tengo código del RSP que correría paralelamente al de la CPU, el RSP no deja de ser otro MIPS pero sin multiplicación, división y algunas cosas más que quitaron para hacer espacio en el chip para otras funcionalidades más basadas en cálculos de vértices.

Lo otro que dices.. carga en segundo plano? El audio en la libdragon coge una fuente y la vuelve a copiar en otro lado para leerla, cuando lo hace mete interrupciones para no pisar memoria, no es lo más óptimo, pero yo dejaría el audio para el final

BMBx64 escribió:En el e3 han mostrado el nuevo Mario Odyssey donde puedes controlar o poseer enemigos con la gorra, resulta que un hábil programador también ha metido eso en Super Mario 64

Dejo el vídeo:
https://www.youtube.com/watch?v=YGcsVQB1NAA

Joe, qué crack..

@gynion @BMBx64 Ya te digo... Vaya fiera!



PD: Off topic total el Super Mario Odyssey ... tiene una pintaaaaa que [

Super Mario Odyssey para mi ha sido de lo mejor del e3 (junto con dragon ball)

Alguien tiene alguna tarjeta de este tipo?


Para no andar sacando la tarjeta del slot del Everdrive en cada compilación he pillado esta tarjeta SD con Wifi, la cosa es que es un poco desastre, viene mal configurada y en general es problemática, pero he conseguido apañarla "más o menos" para pasar archivos de forma bastante rápida.

De momento desde upload.cgi, que el explorador es muy lerdo y se pone a subir a 5Kb/s porque sí.., si reemplazo los archivos no tengo ni que resetear la consola desde el menú, lo cual está genial, aunque lo suyo es que hubiera pillado el cartucho con USB pero quién me iba a decir hace 5 años que me metería en estos berenjenales


--
La herramienta de sprites en un par de días la tendré lista, voy a enseñar un par de ejemplos de lo que hace en modo tilemap.

Esto es un mapa completo de la primera fase de SMB.


La herramienta trocea en tiles el mapa y genera un array que nos lo entrega como code.c con toda la información necesaria para generarlo, cada vez que trocea un tile lo compara con otros que se hayan extraído para ver si son iguales, anula los que sean vacíos, además los compara también con tiles invertidos, si descomponemos la imagen de SMB en tiles únicos nos da este resultado (la herramienta genera estos tilesets como demostración):


Pero la consola se iba a morir haciendo tiles de 8x8, su chip no está diseñado para funcionar de esa forma, así que vamos a probar qué pasa con 16x16.. pues oye tampoco está mal, incluso subiendo a 32x32 dado que hay mucho azul y patrón seguiríamos ahorrando en tiles repetidos a la vez que aceleramos el pintado, los tiles contra más grandes en N64 mejor.


Mirando en las 16bits.. con Goldenaxe 2, este sería el mapa original.


Tiles únicos de 16x16 (hay bastantes tiles invertidos, como el tio en la puerta)


Pero vamos a lo que importa, qué pasa con Castlevania SOTN? Si nos fijamos en el escenario del Mario las hierbas en realidad son las nubes con distinto color, esto de momento no puedo aplicarlo en la herramienta, porque libdragon ni tiene soporte de paletas, ni de transparencias de momento y sería problemático, pues lo que hace SOTN es reusar muchos tiles pero cambiándoles o bien el tono, más claro o oscuro, o hace un alpha sobre un fondo negro (ojo que la imagen son 2 planos en realidad, pero el mismo caso pasa en planos únicos).


Con la imagen descompuesta como vemos el resultado no es óptimo.


Mirando más a fondo lo que arroja code.c podemos ver muy pocos tiles repetidos.


Conclusión para una demo corta de SOTN? Yo usaría tiles de 64x32, a fuerza bruta, usando los 4KB y que optimice en espacio lo que pueda, lo cual me lleva a pensar en añadir compresión con la zlib que tiene variantes en Goldeneye y otros juegos.

impresionante la habilidad que tienes para programar, y excelente hilo, vi tu publicación en el foro del everdrive 64 y probé el sountrack de SOTN que es de lo mejor, uno de los mejores soundtracks de castlevania siempre me queje por que konami no saco el juego en el 64, supongo que por las limitaciones del espacio principalmente y que mejor que quieras hacer un mini demo de SOTN eres un crack !

Es interesante ver lo que había que hacer para mostrar un aparentemente simple escenario en aquellas consolas. Ahora supongo que eso será más fácil en sistemas actuales.

Sí, ahora la potencia es tal que para 2D podrías hacerlo todo con la cpu a fuerza bruta.

Dejo la herramienta que he estado haciendo y termino con el tostonazo, para lo siguiente a raíz de otro hilo me gustaría repasar el The World is not Enough

La herramienta para el que quiera usarla ha cambiado un poco, es igual de fea pero tiene más cosas.


Entrada: Carpeta png, ahí se lanzan todos los pngs a convertir, la herramienta no hace caso a otros archivos o subdirectorios dentro de png.
Salida: Carpeta sprite, ahí se crearan las texturas de N64.

INCLUDE CODE
Añade toda la información necesaria para programar algo a raiz de los sprites o tiles generados.

INCLUDE PNG
Incluye además replicas en png por si queremos ver como fue el recorte, además de otras funciones.

USE ZLIB
Comprime las texturas usando zlib, las texturas comprimidas pasan a llevar la extensión zsprite, las no comprimidas son .sprite, esto requiere la zlib compilada en N64 para ser cargadas.

GROUP / SEPARATED
Esto es para agrupar todas las texturas dentro de la carpeta sprite, o de cada png crear una carpeta invidual donde meter todos sus cortes.

OPTIMIZE
Función de recorte optimizada para encajar con el tamaño TMEM de la consola con el mínimo de llamadas posibles, un ejemplo del tipo de recortes que crea según el tamaño del sprite:


Todo esto va sujeto a los limites de la libdragon:
Horizontalmente: Solo pueden ser texturas par, si se encuentra una impar automáticamente genera un espacio para hacerla par.
Verticalmente: Solo en múltiplos, estos tamaños: 4,8,16,32,64,128,256
Máximo: 256 de ancho o 256 de alto

OPTIMIZE L/R
Una vez se ha establecido el tamaño de los recortes esto recorre la textura buscando huecos vacíos y vuelve a recortar para reducir tamaño innecesario.


Optimize L: Optimiza desde la izquierda, puede causar fallos de alineamiento, pero eso es algo que he resuelto en la librería.
Optimize R: Es seguro de usar, ningún efecto secundario.

Resultados:
Textura original de 68x69 de 32bits: 18,3KB
Textura convertida de 68x72 (9 trozos * 8 de alto): 19,1KB (aumentamos espacio por hacerla compatible)
R: 14,8KB
L+R: 11,2KB
Zlib: 1,60KB

O para entenderlo de otra forma, he escogido un personaje entero medianamente grande (160 frames):
Textura convertida: 1,80MB
R: 1,51MB
L+R: 1,30MB
Zlib: 230KB

Bueno pues esto ya empieza a pintar mejor no? Lo que no puede ser es que 1 solo personaje nos coma casi 2MB del cartucho, o esa enorme cantidad de memoria RAM, hay que recordar que la consola stock es de 4MB, incluso 1,30MB es una cifra demasiado alta por las dichosas texturas de 16bits.

RGB
Pinta el fondo de la imagen como transparente con el color solicitado, esos sprite sheets de color rosita? Vemos su RGB en el paint, los introducimos y se borran automáticamente en el recorte

PNG TO TILEMAP
Lo enseñado en el post anterior.

Si include png está activado se crean copias del mapa completo, se crean copias de los tiles y del tileset.
Si include code está activado se crean code.c y flags.c (si aplicable)

CHECK TILE
Esto comprueba si el tile está repetido vertical o horizontalmente y lo excluye de la lista de tiles, no antes anotándolo en flags.c

- Los tiles completamente transparentes se ignoran, como pueden ser las partes de cielo vacías diseñadas para que se vean otros planos por detrás
- Si check tile y include code son desactivados, el mapa de tiles va a ser troceado al completo, esto es porque no habría manera de saber su array.

PNG TO SPRITE
Tras convertir las texturas salta al editor de animaciones.


El editor es muy simple pero funcional, de momento no permite cajas de colisiones ni otras cosas pero ya se andará.

- Frame es el número de animación, el png en concreto se indica a la derecha, junto al número de texturas que lo componen, cuando empieza y cuando termina.
- Tick es el tiempo de animación, 60 ticks = 1 segundo.
- CP x / CP y los puntos de control que controlan el centro de la imagen, se pueden editar desde la caja, desde los botones o arrastrando directamente en el sprite.
- View se compone de 3 botones, el centro es el frame actual, el de la izquierda es el frame anterior en modo ghost para referencia, debo saber donde estaba el pie para volver a poner el siguiente frame? Ahí, el botón de la derecha es para ver el próximo frame, sin saltar de animación.
- Rect enseña todos los rectángulos de los que está compuesto un sprite.
- Flip voltea el sprite por si tenemos manía o creemos que el otro lado de la cara le queda mejor.
- BG es el fondo, generalmente para encontrar "sprites agujereados", muchas veces nos equivocamos con las transparencias.

CONTROLES:
- F1 tamaño de ventana original
- F2 tamaño al doble para no quedarse miope
- Flechas izq / der para cambiar de frame de animación
- Flechas arriba/abajo/rueda del ratón, para hacer zoom, el zoom no es 100% preciso
- En las cajas se pueden introducir números con solo dejar el ratón encima
- Ratón para todo lo demás, agarrar sprite, agarrar fondo para mover cámara, pulsar

Si include png está activado esto creará:
- animcp.c, el archivo contiene arrays de todo lo editable

El programa además genera:
- animcp_save.dat, esto es un archivo de sesión para seguir editando sin perder nada, se puede cambiar de nombre para reemplazarlo si más adelante se requiere.

* Dentro de sprite se guardan CP x / CP y para que la libdragon lo lea automáticamente.

Habéis llegado hasta aquí? Bien! dejo la descarga, la herramienta está programada en BennuGD y corre en Windows, es decir cualquiera puede trastear con ella y decirme que le parece

DESCARGA
https://mega.nz/#!5xhz3ZjJ!1o08nQeowclRa5nei-QzEIOzEQ0oCHOrDg-RH9geheE

El código necesario para hacerlo rular en N64, mis edits en rdp.c y rdp.h, recordad que está sin finalizar y existen bugs en scale, recomendable usar rdp_cp_sprite.

DESCARGA
https://mega.nz/#!k04GhJ5Y!E6OJQvDMwFGJeSFr_uTHRT4Hkx_AR0uJPFkM8iBMctE

vaya es muy buena herramienta, bastante útil lo de las transparencias usando el rgb para no andar usando otros editores lo único que no entendi es como hacerlo funcionar en el n64 una vez que tengo alguna animación.

@john D9
Hola y bienvenido

Son texturas de N64 que puedes usar con la libdragon (en la página 3 de este hilo hay un tutorial), pero antes de hacerlo, reemplazamos los archivos rdp.c y rdp.h que es el código que he editado de la librería para dar soporte a puntos de control, espejado por hardware, etc

De todas formas en el hilo de nesdev se ha pasado a participar marshall (autor de 64drive, mod HMDI,etc) y me ha comentado que hay un SDK mucho más potente en desarrollo para N64 con soporte de hilos, con mejor rendimiento y me invitó a pasarme por el canal irc que tienen, así que igual estaba perdiendo el tiempo con esta librería, tengo que ver que se cuece y ya traeré novedades.

La herramienta es igualmente necesaria , si llegas a compilar la librería puedo pasarte un ejemplo de como usar rdp_cp_sprite, que es la función que se usa para cargar sprites con puntos de control.

--

Aprovecho y dejo el "análisis" del segundo juego de Bond para N64

007: THE WORLD IS NOT ENOUGH
Este juego ya partía del éxito de Goldeneye, EA se había hecho con los derechos de James Bond y Eurocom iba a programar el juego usando un nuevo engine, estaría al nivel de las expectativas?

Lo primero que salta a la vista es la ausencia del tema principal de James Bond que sí estaba en Goldeneye o incluso en juegos anteriores, como The Duel de Mega Drive, por lo visto tras el éxito arrollador de Goldeneye los royalties se pusieron por las nubes y no fue rentable hacer la inversión.

Así que entramos en sonido, no me digas que por defecto viene en mono? Una de las novedades es la inclusión de voces en las intros que venían comprimidas gracias a una tecnología de Factor 5 que emplea el juego.


Es por tanto inevitable andar comparando este título con Goldeneye pues en muchos aspectos se basa en él, las fases están divididas por misiones, cada misión tiene un número de objetivos, el número de objetivos viene marcado por el nivel de dificultad, de igual manera tenemos (Agent, Secret Agent, 00 Agent)


Por otro lado tenemos la mano de EA que siempre da su "toque" a los juegos, así que el menú del juego viene patrocinado por Motorola, esto es como cuando estás viendo el telediario, el presentador se va para la derecha y ahora intenta venderte unas gafas de sol, ni falta decir que la idea del reloj de Bond en el menú de Goldeneye era una idea genial.


Pasando al juego hay cosas buenas y no tan buenas, los escenarios están trabajados y en muchos casos tienen una distancia de dibujado enorme, en otros casos son las texturas o la iluminación lo que sorprende, escenarios como este no están nada mal.


Los NPC reflejan sombras en el suelo y en muchos casos el suelo es también reflectante, con la consecuente carga gráfica, los modelados varían según el tipo de personaje y aunque estarían en un promedio de 700 polígonos (sumando sombra) no están al nivel de Perfect Dark ni tampoco usan un esqueleto para animación, los brazos se notan pegados al cuerpo como piezas independientes.


Los escenarios se cargan por secciones, el funcionamiento de las puertas es un tanto sospechoso, en Goldeneye viene un golpe de aire y se cierran, aquí si te quedas en la sala, puede que la puerta se quede abierta hasta que te alejes lo suficiente del sitio para cerrarse.

En las mesas podemos encontrar tazas de té, portafolios, bolis, ratones, teclados, teléfonos y todo tipo de detalles alrededor de la habitación, aunque a un precio, casi nada se puede destruir y yo soy Bills el dios de la destrucción, así que es algo que decepciona un poco viniendo de un juego donde todo arde y explota a lo Michael Bay, pero eso si, no toques la pantalla del ordenador, es el diablo.


En ese sentido hay un poco de inconsistencia, una mesa de cristal? A prueba de balas, sin embargo luego puedo romper los cristales de este vehículo (el cual por cierto está recreado por dentro, eso le da un punto extra, en esa generación se llevaban los cristales ahumados)


Vale, esto ya me gusta más, todo cae por los suelos, hasta los cuadros, me recuerda a Die Hard Vendetta este escenario.


Si lo sé no digo nada.. me iluminas esa zona al fondo, hay una puerta verdad? No es que el gif se repita, es que pasa un metro a cada 4 segundos y yo estoy esperando el mio pero no llega, a diferencia de Goldeneye aquí hay objetivos que si los fallas te sacan del nivel (yo quiero estudiar la zona y saber porqué he fallado) o muertes instantáneas como ésta, el tren puede arrollarte, buen efecto de blur sobre el tren por cierto, o quizás sea tan solo una textura borrosa?


Pero vamos a los puntos realmente negativos, la IA y las animaciones, en Goldeneye los enemigos fallan más que una escopeta de feria, empiezan a hacer el lerdo y a tirarse por los suelos, la finalidad de todo esto es darte tiempo para que puedas apuntar o incluso fallar en sus piruetas, sin embargo aquí el amigo tiene una precisión del 100% en ojo, nivel Agent (fácil), si nos alejamos capaz y falla algún disparo, la animación de recarga parece meramente aleatoria, su movimiento va en plan un pasito palante un pasito patrás, si se juntan 4 enemigos nos podemos imaginar qué pasa en este juego, pero lo peor en si no es la actuación sino también la búsqueda, en Goldeneye oyen y buscan al objetivo, aquí puedes cerrar la puerta con el enemigo dentro y ahí se queda, es como si hubiera script para cada enemigo o situación en concreto, salvo excepciones.


Y ese script no se puede romper, el NPC en lugar de recalcular su posición arrastra a Bond porque es más fácil.


Que te levantas? Toma supositorio, esa es mi venganza por pesado, lo mejor es la animación, cuando muere se invierte y se queda tal y como estaba.


Lo cierto es que las animaciones son muy cómicas y afortunadamente también tienen daño localizado, ahora vas a bailar.


Pero quiero ver la animación de la mano.. oh wait, que los enemigos reciben 5 tiros en el pie y tu mueres de un solo tiro en la mano? Era la mano buena no? Si el juego te dice "minimizar las bajas civiles" quiere decir que no mates a ninguno, en Goldeneye tenías un margen por si se te iba el dedo.


Ah vale que ahora te has ido al cuarto de baño, lo has dejado perfumado y me avisas de que no entre, no puede ser.. si un enemigo te mata aquí no ha pasado nada? Tiene sentido, ahora vendrá el inspector de homicidios a determinar que no fue Bond.


Algo que no he comentado es que la primera fase es en Bilbao, son duros de la hostia, aquí los cuadros no se caen y un calambrazo eléctrico es un simple dolor de cabeza (me recuerda a los tribals del Jet Force Gemini).


Las animaciones tienen tan pocos frames que es difícil darse cuenta de lo que pasa, sobretodo al disparar rápido y tras el impacto se deslizan como en una pista de patinaje.


Vamos a verlo en cámara lenta, en el segundo tiro vuelve a su posición incial, saltándose por donde iba, en Goldeneye las animaciones no solo son mucho más suaves, sino que tienen aceleración, respetan el ángulo y estado encadenando unas con otras (mayoritariamente).


En resumen, tiene algunos detalles de calidad, en ese sentido se nota que es un juego moderno de la etapa final de N64, es entretenido y variado, pero le falta esa chispa, esa picardía, en fin esa genialidad que tiene Goldeneye.

@BMBx64 Grandisos comentarios. Seguimos esperando la comparativa del ocarina con el majora's

BMBx64 escribió:De todas formas en el hilo de nesdev se ha pasado a participar marshall (autor de 64drive, mod HMDI,etc) y me ha comentado que hay un SDK mucho más potente en desarrollo para N64 con soporte de hilos, con mejor rendimiento y me invitó a pasarme por el canal irc que tienen, así que igual estaba perdiendo el tiempo con esta librería, tengo que ver que se cuece y ya traeré novedades.

La verdad es que una N64 orientada a las 2D, y mas aún con las ventajas del cartucho, tiene pinta de que no tendrá nada que ver a todo lo visto en psone y saturn.

Como siempre un gran análisis técnico @BMBx64 .

Nivelazo como siempre BMBx64

A mí el TWINE no me acabó de convencer, aunque no lo jugué en su día y sólo he echado unas partidas rápidas. Notaba cosas raras a la hora de apuntar y la respuesta a los disparos era muy rara.
Cuando VGF publicó su traducción al castellano pensé que sería una buena oportunidad para darle a fondo, pero todavía lo tengo pendiente.
Por lo que pude ver, los niveles suelen ser bastante lineales y se van abriendo nuevas zonas según lo necesita el guión. Esto te permite meter las situaciones concretas que quieras y hacer el juego más espectacular (los famosos scripts), y puede que por eso el comportamiento de los enemigos sea tan hermético. También tengo la sensación de que no se puede volver hacia atrás en la mayoría de los casos, lo que elimina ese componente sandbox que tienen los shooters de Rare en los que te dedicas a hacer el cafre por el nivel sin límite de tiempo.
Por último, probé los mapas multijugador pero la mayoría me parecieron muy poco interesantes por ser muy repetitivos y pequeños.

Gráficamente tiene detalles muy ambiciosos como sombras y reflexiones en los enemigos. Algo que ni Perfect Dark se atrevió a intentar, seguramente porque la carga gráfica ya era muy elevada, el framerate justito y sólo de pensar en el modo cooperativo corriendo en alta resolución te tendría que venir otra consola para hacer SLI en lugar de un Expansion Pak, jeje.
Gráficamente también intenta que "todo" sea 3D. Los mangos de las puertas, los marcos de las ventanas... En algunos casos una textura en buena resolución podría quedar mejor y ser más eficaz, pero se agradece el esfuerzo.
Hablando de texturas. Es un juego que abusa mucho de texturas de 64x64 en 16 colores. A priori parece una buena opción porque son texturas con más resolución de lo habitual en N64 y si no se requiere gran variedad de color como en paredes de ladrillo, suelos pavimentados, césped, rocas... esos 16 colores son suficientes. El problema es que no tienes espacio en la caché para hacer mipmapping y eso hace que todo se vea pixelado. El juego me dio la impresión de que tampoco tiene anti-aliasing, lo que lo empeora todo. Y tampoco es buena idea usar este tipo de texturas para los rostros de los personajes, ya que aunque tengas más resolución la falta de colores te permite mostrar menos detalles y el resultado es muy cartoon y poco realista.

Sogun escribió:Nivelazo como siempre BMBx64

Es un juego que abusa mucho de texturas de 64x64 en 16 colores. A priori parece una buena opción porque son texturas con más resolución de lo habitual en N64 y si no se requiere gran variedad de color como en paredes de ladrillo, suelos pavimentados, césped, rocas... esos 16 colores son suficientes. El problema es que no tienes espacio en la caché para hacer mipmapping y eso hace que todo se vea pixelado. El juego me dio la impresión de que tampoco tiene anti-aliasing, lo que lo empeora todo. Y tampoco es buena idea usar este tipo de texturas para los rostros de los personajes, ya que aunque tengas más resolución la falta de colores te permite mostrar menos detalles y el resultado es muy cartoon y poco realista.

En teoría si debería poder hacerlo,64*64*4 bits (16 colores) son 2 KB,no podría hacer mip-mapping si fueran de 8 bits de profundidad (256 colores) ya que sería 64*64*8 bits igual a 4 KB y llenaría todo el cache, a lo mejor me equivoco.Por cierto¿ la N64 no soporta texturas indexadas en profundidades de bits raras? , como el Amiga que soportaba 5 y 6 bits (32 y 64 colores), a lo mejor se podría rascar algo por ahí.

Salud.

Qué gran hilo y qué grandes recuerdos! Me suscribo y felicito al OP y otros compis por tal curro.
Aún recuerdo la marcianada de poner nuestras caras en el Perfect Dark con el transfer pack y la cámara de la gameboy. No recuerdo si lo llegamos a conseguir o no pero recuerdo muchas risas.
Esta semana me plantearé si la desempolvo, si me bajo emulador para pc o gpd win pero el perfect dark va a caer...

dirtymagic escribió:

Sogun escribió:Nivelazo como siempre BMBx64

Es un juego que abusa mucho de texturas de 64x64 en 16 colores. A priori parece una buena opción porque son texturas con más resolución de lo habitual en N64 y si no se requiere gran variedad de color como en paredes de ladrillo, suelos pavimentados, césped, rocas... esos 16 colores son suficientes. El problema es que no tienes espacio en la caché para hacer mipmapping y eso hace que todo se vea pixelado. El juego me dio la impresión de que tampoco tiene anti-aliasing, lo que lo empeora todo. Y tampoco es buena idea usar este tipo de texturas para los rostros de los personajes, ya que aunque tengas más resolución la falta de colores te permite mostrar menos detalles y el resultado es muy cartoon y poco realista.

En teoría si debería poder hacerlo,64*64*4 bits (16 colores) son 2 KB,no podría hacer mip-mapping si fueran de 8 bits de profundidad (256 colores) ya que sería 64*64*8 bits igual a 4 KB y llenaría todo el cache, a lo mejor me equivoco.Por cierto¿ la N64 no soporta texturas indexadas en profundidades de bits raras? , como el Amiga que soportaba 5 y 6 bits (32 y 64 colores), a lo mejor se podría rascar algo por ahí.

Salud.

El problema es que las texturas a color de 4 y 8 bits utilizan 2 Kb para la paleta de colores y los otros 2 Kb para la textura en sí. Una textura de 4 bits en escala de grises sí que hace mipmapping porque no tiene paleta y después puedes pintar los vértices de los polígonos para darle color. Esto se hace en mucho juegos y queda bastante bien.

La N64 no es de mis consolas favoritas; más que nada porque no la tuve en su momento, como la SMS, pero cada post de @BMBx64 hace interesante y divertido cualquier detalle de la maquina y juegos que destripe.

The world is not enough también salió para psx y creo recordar que funcionaba a una resolución horizontal mayor que la standard de sus juegos.

El juego tenía las mismas misiones que la versión de n64 aunque era bastante diferente. Bff no se con cual me quedaría

Con misión imposible me pasa igual, en mi infancia tuve la versión de n64 pero ahora la versión de psx me parece algo mejor.

ashurek escribió:@BMBx64 Grandisos comentarios. Seguimos esperando la comparativa del ocarina con el majora's

Sí, lo tengo anotado junto al Goemon, en el caso de Majoras lo tengo pendiente en 3DS y estoy esperando a pasarmelo allí antes de trastear

Señor Ventura escribió:La verdad es que una N64 orientada a las 2D, y mas aún con las ventajas del cartucho, tiene pinta de que no tendrá nada que ver a todo lo visto en psone y saturn.

Calculo que solo estoy accediendo a un 40% de potencia de la consola, en cuanto empiece a usar el RSP para comunicarse directamente con el RDP, a usar texturas de 4bit que son 4 veces más rápidas de cargar y sobretodo todas las virguerías que puede hacer el RDP en efectos gráficos, hilos para hacer trabajar paralelamente a la CPU/RSP/RDP y código especializado para usar bien los 24KB de cache de la CPU el rendimiento se va a disparar.

Martajuru escribió:The world is not enough también salió para psx y creo recordar que funcionaba a una resolución horizontal mayor que la standard de sus juegos.

El juego tenía las mismas misiones que la versión de n64 aunque era bastante diferente. Bff no se con cual me quedaría

Con misión imposible me pasa igual, en mi infancia tuve la versión de n64 pero ahora la versión de psx me parece algo mejor.

El de PSX no lo he jugado pero he visto vídeos y parece un poco distinto, tiene los derechos de la banda sonora original y hasta de la película, pone escenas de vídeo, aunque a mi me cansan un poco los samples repetitivos que han metido en las fases, igual me lo bajo para ver si la IA es igual de lela, por lo que he visto es bastante cómico lanzarles una granada y ver como reculan todos a la vez.

En N64 hay un modo "hi color" que estuve mirando y no incrementaba el tamaño de las texturas ni la resolución de pantalla, tengo que revisar si por un caso no activa el bit del modo 32bits de color, en ese caso si que sería una sobrada.

---

Buscando cosas me he topado con este blog de un tío que está haciéndole ingeniería inversa al World Driver Championship, ya tiene extracciones de algunos coches, circuitos y otras cosas.


Dejo su web:
http://jaytheham.com/tink/?cat=7

--

Para la versión 1.1 de "Sprite64" tengo algunas novedades pensadas:

* Soporte de colisiones:
- Hurtbox, cajas de referencia (hasta 4 cajas individuales por sprite)
- Hitbox, cajas de ataque ("idem)
- Ausencia de hurtbox (el frame es invencible)

Lo que vendría a ser esto (las rojas son hitbox):


* "Custom CP"
- Puntos de control personalizados, ponerle un cuchillo en la mano al protagonista, determinar desde donde sale la bala de un arma, etc

Todo esto se haría en base a los sprites previamente alineados.

BMBx64 escribió:Calculo que solo estoy accediendo a un 40% de potencia de la consola, en cuanto empiece a usar el RSP para comunicarse directamente con el RDP, a usar texturas de 4bit que son 4 veces más rápidas de cargar y sobretodo todas las virguerías que puede hacer el RDP en efectos gráficos, hilos para hacer trabajar paralelamente a la CPU/RSP/RDP y código especializado para usar bien los 24KB de cache de la CPU el rendimiento se va a disparar.

Háblame de números estimados con todo el sistema haciendo uso del hardware al 100%

Ya que no son sprites, ¿algún tipo de fill rate?, ¿por scanline?, ¿fill rate total en pixels?, ¿número de "planos" estimados en un ejemplo real?, ¿uso y eficiencia del 2D+3D?, ¿ancho de banda?.

Y mas importante, ¿hubo algún arcade con un rendimiento 2D equivalente al estimado en la N64?.

Danos salseoooooo

Si ningun juego exprimio al maximo la n64

Tenian que hacer malabares para meterlo en un cartucho de 512mbits

Sogun escribió:

dirtymagic escribió:

Sogun escribió:Nivelazo como siempre BMBx64

Es un juego que abusa mucho de texturas de 64x64 en 16 colores. A priori parece una buena opción porque son texturas con más resolución de lo habitual en N64 y si no se requiere gran variedad de color como en paredes de ladrillo, suelos pavimentados, césped, rocas... esos 16 colores son suficientes. El problema es que no tienes espacio en la caché para hacer mipmapping y eso hace que todo se vea pixelado. El juego me dio la impresión de que tampoco tiene anti-aliasing, lo que lo empeora todo. Y tampoco es buena idea usar este tipo de texturas para los rostros de los personajes, ya que aunque tengas más resolución la falta de colores te permite mostrar menos detalles y el resultado es muy cartoon y poco realista.

En teoría si debería poder hacerlo,64*64*4 bits (16 colores) son 2 KB,no podría hacer mip-mapping si fueran de 8 bits de profundidad (256 colores) ya que sería 64*64*8 bits igual a 4 KB y llenaría todo el cache, a lo mejor me equivoco.Por cierto¿ la N64 no soporta texturas indexadas en profundidades de bits raras? , como el Amiga que soportaba 5 y 6 bits (32 y 64 colores), a lo mejor se podría rascar algo por ahí.

Salud.

El problema es que las texturas a color de 4 y 8 bits utilizan 2 Kb para la paleta de colores y los otros 2 Kb para la textura en sí. Una textura de 4 bits en escala de grises sí que hace mipmapping porque no tiene paleta y después puedes pintar los vértices de los polígonos para darle color. Esto se hace en mucho juegos y queda bastante bien.

¿Entonces las paletas ocupan siempre 2KB?,si usas solo 1bit (2 colores),y es blanco y negro sin paleta no gastaría los 2 KB ,pero si en vez de esos colores son rojo y azul,si que gastaría paleta,¿no?.
A mi el Mip-mapping que hace la N64 y DC,me parece horrendo,casi prefiero que no lo haga.

Salud.

Señor Ventura escribió:Háblame de números estimados con todo el sistema haciendo uso del hardware al 100%

Ya que no son sprites, ¿algún tipo de fill rate?, ¿por scanline?, ¿fill rate total en pixels?, ¿número de "planos" estimados en un ejemplo real?, ¿uso y eficiencia del 2D+3D?, ¿ancho de banda?.

Y mas importante, ¿hubo algún arcade con un rendimiento 2D equivalente al estimado en la N64?.

Danos salseoooooo

Sin saber como es el 100% eso es mojarse mucho

Aún así más que la potencia importa el ingenio, he puesto este scroll tileado de 16x16 (lento) del Mario a 320x240 (más lento) a ver cual era el rendimiento en la consola usando el "40%".

Aún con todas las optimizaciones: 171fps, que no está mal, reemplazas esos tiles planos por cualquier textura de 16bits y el rendimiento sería el mismo, utilizas tiles de 32x32, aumenta, tiles de 64x32 aumenta aún más, zonas transparentes? más, modo 256x240? Todavía más, prescindes de los 240 y pintas solo 224 o 208, todavía más.

Pero digo vamos más allá, elimino el fondo azul y lo hago transparente, la composición del tile ahora enumerará el cielo como 0 y lo ignorará, entonces pinto el color azul con fillcolor, que va a hacer exactamente lo mismo que la "textura de azul plano", resultado:


Por scanline no se puede sacar nada, las maquinas de esa generación ya utilizan un buffer o pantalla completa y luego lo envían a vídeo, para no quedarse sin hacer nada mientras tanto usan doble o incluso triple buffer para ir generando la próxima escena sin tener que esperar.

Yo calculo que con el "40%" podría hacer un Metal Slug a 60fps usando los 8MB de RAM probablemente por el gasto de las texturas de 16bits, me gustaría comprobarlo de hecho.

dirtymagic escribió:¿Entonces las paletas ocupan siempre 2KB?,si usas solo 1bit (2 colores),y es blanco y negro sin paleta no gastaría los 2 KB ,pero si en vez de esos colores son rojo y azul,si que gastaría paleta,¿no?.
A mi el Mip-mapping que hace la N64 y DC,me parece horrendo,casi prefiero que no lo haga.

Salud.

La consola tiene el siguiente bitdepth:
0 - textura 4bit
1 - textura 8bit
2 - textura 16bit (RGB555)
3 - textura 32bit

Desconozco si hay triquiñuelas para usar otros formatos de textura, luego cada textura tiene un modo de color distinto, los que comentas usan TLUT, la tabla de colores en los 2KB superiores, no sé si hay forma de hacer accesible esa zona de memoria con ese modo activado para otra cosa que no sea comprobar la tabla.

No veas cómo controlas

BMBx64 escribió:Yo calculo que con el "40%" podría hacer un Metal Slug a 60fps usando los 8MB de RAM probablemente por el gasto de las texturas de 16bits, me gustaría comprobarlo de hecho.

Estaría chula una ampliación de 16MB en lugar de 4MB

¿Y deben ser texturas de 16 bits?, si un objeto completo del metal slug dificilmente superará los 256 colores, ¿no?.

Señor Ventura escribió:

BMBx64 escribió:Yo calculo que con el "40%" podría hacer un Metal Slug a 60fps usando los 8MB de RAM probablemente por el gasto de las texturas de 16bits, me gustaría comprobarlo de hecho.

Estaría chula una ampliación de 16MB en lugar de 4MB

¿Y deben ser texturas de 16 bits?, si un objeto completo del metal slug dificilmente superará los 256 colores, ¿no?.

Es interesante esa valoración de 40% + Expansión pack = Metal Slug.

La Saturn consigue un MS casi exacto con la expansión de 1 MB. Pierde los mismos frames que en Neo Geo CD tengo entendido (nada tan grave como la desolación pixelada de la versión PlayStation), faltan las mismas voces (absurdamente), se ralentiza en los mismos sitios, y en las pantallas de carga sale el mismo mono haciendo malabares; luego el port desde NG CD está más que cantado.

En cuanto porcentaje de potencia que emplea la Saturn para moverlo es difícil de discernir; porque de entrada una c.p.u está desactivada al no requerir de transformaciones de geometría profundas, pero que igualmente se podría emplear para otras cosas. De igual manera las bestiales capacidades de scaling y rotación del VDP 2 están muertas de risa en Metal Slug, el cual usan para los backgrounds y escupir el output final.

Con la expansión de 4 MB y una conversión personalizada otro gallo hubiese cantado. Pero ojito que MS en Saturn es MUY disfrutable, y sólo canta si jugaste mucho al ARCADE, y/o emulaciones.

P.D: Sigo anclado a un móvil y sin tiempo :__

@Sexy MotherFucker No se, algo no me cuadra cuando una N64 necesita mas ram ejecutando ese metal slug desde un cartucho con mucho mas ancho de banda que una saturn.

Hay algo que se me escapa.

@Señor Ventura no te puedo ayudar, ahora en mis ratos libres estoy leyéndome un debate follacerebros en Sega16 sobre la PUTA ATARI JAGUAR vs Saturn vs PlayStation vs Nintendo 64 vs 3D0 vs LA PUTA AMIGA CD 32, y se me está derritiendo el cerebro no ya por toda la información a bajo nivel que desconocía de la propia Saturn, si no por el hecho de que existan fanboys de la Jaguar reivindicando sus puntos fuertes respecto a las otras xDDDDD

O sea me he dado cuenta de que Rusty y yo somos gente normal haciendo apología de las partículas y backbuffer de la Ps2 a su lado xDD

Mamasita, habemus gente pa tó...

@Señor Ventura
Necesita 8MB para que yo pueda hacer una recreación usando el SDK libre ahora mismo (la libdragon), digo 8MB porque no sé la cifra exacta, pero serían casi seguro más de 4MB, si uso la libultra podría usar directamente las paletas de 4bits y acceder a todo el hardware, pero ese SDK es el oficial y te arriesgas a tener problemas con la distribución.

Ten en cuenta que toda la información de tiles va a ocupar 4 veces más si se usan texturas de 16bits en RAM y luego está la ineficacia, los Metal Slug de Saturn o PSX salen de la fuente original, yo tendría que extraer los mapas o bien de la rom o intentar sacarlos de una imagen y montar todo el sistema de sprites, donde también perdería espacio.

En Neogeo los sprites están montados en tiles de 16x16 a 16 colores, encadenados de forma vertical, la forma en que yo hago los sprites (por velocidad) es horizontal en lugar de vertical y al máximo espacio, para recargar menos la tmem.

Echa un ojo a como de eficaz sería montar la fase a raíz de esto y cuanto debería optimizar.


La carga en streaming del cartucho no la veo muy aplicable con la libdragon porque solo tira de un hilo, el rato que se tira cargando congela la ejecución (libultra si trae multihilo), si bien podría hacer como PSX y meter loading tras el desbloqueo de cámara (sería una carga mucho más rápida, igual casi invisible), pero lo ideal sería poder ejecutar sin loading.

@Sexy MotherFucker Yo también ando algo disperso, a ver si para los dos siguientes meses del verano consigo tener mas tiempo para mi.

@BMBx64 Osea, que son limitaciones del SDK... ya me parecía raro que fuese tan obligatorio gastar memoria de esa forma.
De todos modos, es una llave, ¿habría posibilidades de que la N64 admitiese mas memoria ram en su ampliación?, ¿cual sería su límite hipotético?.

editado: ¿La caché de texturas de 4KB no la puedes salvar con nada?.

Señor Ventura escribió:@Sexy MotherFucker Yo también ando algo disperso, a ver si para los dos siguientes meses del verano consigo tener mas tiempo para mi.

@BMBx64 Osea, que son limitaciones del SDK... ya me parecía raro que fuese tan obligatorio gastar memoria de esa forma.
De todos modos, es una llave, ¿habría posibilidades de que la N64 admitiese mas memoria ram en su ampliación?, ¿cual sería su límite hipotético?.

editado: ¿La caché de texturas de 4KB no la puedes salvar con nada?.

En teoría los 4 KB de cache es para poder hacer el filtrado bilinear,ya que necesita 4 ciclos para hacerla y el ancho de banda de la memoria RAM no es suficiente rápida, tal vez sin hacer el filtrado se pueda cargar texturas de mayor tamaño desde la RAM ,aunque igual no lo permite el SDK o la propia estructura de la consola.

Salud.