Al fin he conseguido editar un sprite de una rom

Vaya que has prograsado bastante y quiero ser el primero en darte mis felicitaciones ...
No se todavia si lo sigas haciendo manualmente o si lo estes haciendo apoyado de alguna aplicacion especializada...ya que en mis pruebas (Tambien intento hacer algo como lo que estas haciendo) pero para mi desgracia soy malo para la edicion de tiles...

es increible, yo jamas seria capaz de hacerlo, sigue asi
¿de que juego es?

angel_gore escribió:Bueno, ayer estube un buen rato dandole vueltas y haciendo algunas pruevas que cababan en desatres:

(esta fué mi primera modificación, en la cual se me olvido pasar el valor "0000" del pixel del la imagen a "0" del número de color en la paleta (que por cierto es el color que indica la transparencia ^^) quedandome muchos huecos transparentes.

Pero bueno, hoy ya me puse más en serio y le añadí a la aplicación, que me estoy haciendo para que lea imágenes y devuelba valores hexadecimales para insertarlos directamente en el archivo con un editor hexadecimal, majores caracteristicas como que elabore ella sola una tabla (para no basarse en la tabla de las imágenes a modificar) y convertia todo (a falta de lo de la inversión de los caracteres, que eso lo hago con otro programa que tengo por ahi, aunque obiamente añadiré ese parametro en breves).

Lo único es que aún no he matizado los errores de la aplicación ni el aspecto así que por ahora no la compilaré y la subiré. Aunque eso si, entre las limitaciones tiene que solo lee imágenes de 8xX pixeles; es decir que lee imágenes que tengan 8 pixeles de altura y el resto pixeles de ancho (algo que no es un problema si se tiene el paint a mano) y que solo lee y modifica imágenes de 16 o menos colores (incluyendo el color transparente).


Aunque bueno, yo veo que esto va por buen camindo y teniendo en cuenta que las imágenes de 256 colores son mas sencillas de editar, quizás pronto las añada al programa. Y si me estudio el código mejor pueda hasta leer imágenes de cualquier pixel de altura y de anchura.


Bueno, aquí os dejo el resutado:




¿Que opinais? ^^


Saludos


PD: Sigue dependiendo del tahaxan para extraer las imágenes, pero vamos que lo que yo creo que realmente importa es el editarlas, que de eso no conozco ningun programa.

Que que opino!? Tio, te lo estás currando que no veas!!!! Sige asi y si conseguimos editar los sprites de algun juego te hacemos un monumento xD

Siiiigue! Siiiiigue!!!!

¿Os dáis cuenta del avance de lo que esto supone? Para empezar, todos aquellos grupos que hacen traducciones de juegos que nunca saldrán de Japón, podrán traducirse COMPLETAMENTE. Y también para hacer parodias de juegos (imaginad un juego con un personaje creado por vosotros o, incluso, vosotros mismos).

Leopoldo escribió:¿Os dáis cuenta del avance de lo que esto supone? Para empezar, todos aquellos grupos que hacen traducciones de juegos que nunca saldrán de Japón, podrán traducirse COMPLETAMENTE. Y también para hacer parodias de juegos (imaginad un juego con un personaje creado por vosotros o, incluso, vosotros mismos).

ya existe

Draw to life




el modificar los sprites es muy interesante para según que juegos...

pero se podria poner en un super mario por ejemplo a sonic?

o crear tus propios pokemons en el perla y diamante?

maneko escribió:pero se podria poner en un super mario por ejemplo a sonic?

o crear tus propios pokemons en el perla y diamante?

Se supone que si xD Aunque solo lo verías en el backup donde le hayas hecho el apaño.

PD: Molaría poner a sonic en el New Supermario bross.... si señor

Genial, me alegro de que progreses, espero que dentro de un tiempo podamos todos editar los sprites de manera más o menos sencilla ^_^.

Para hacer algo tipo "La lellenda de la Cerda" estaría muy bien

Solo dos cosas
- ¿Que juego es?
- Esto me suena... En Jump Ultimate Superstar traducido al español, los pop-ups de avisos que te salen (p.ej. al guardar un mazo) ya habian sido editados los sprites para que salieran en español...

Pues el juego en cuestión es el:
shaberu DS Oryouri Navi Marugoto Teikoku Hotel


Que va de recetas de cocina y tal (interesantes sobre todo las japonesas...).
Aunque bueno, principalmente lo traduzco porque me parece interesante y que jamás saldran juegos de este estilo en españa... Y porque si dios quiere el año que viene empiezo a trabajar en la cocina ^^.


No sabia que los de la traducción del jump ultimate super stars hubiesen modificado los sprites (lei sobre que iban a preguntar a unos italianos que como lo habian hexo, pero no explicaban nada... y como a ese juego no he jugado...).

Eso si, yo me olia que se podian modificar imágenes en los juegos de nds (al menos el que hacia el tahaxan sabia como... una pena que no volbiese a actualizar el programa, porque seguro que era mucho mejor que el apaño que me estoy haciendo), pero como no encontré información por la red pues me puse a experimentar y al menos creo que voy progresando ^^.
Además yo prefiero dar a conocer mis descubrimientos, porque si un dia dejo de entrar en el foro al menos alguien interesado en la edicion de imágenes pueda comprender como se editan y tal.

Bueno, ahora posteo un tutorial con mi programilla y todo para que la gente con una pequeña familiarización con los editores hexadecimales pueda modificar imágenes de 16 colores ^^.


Saludos

Como ya han dicho, ya se hizo algo parecido en el Jump Ultimate Stars. Sin embargo, conseguir que esto funcione bien y tener tutoriales sería increíble. Algunos juegos 2D serían perfectos para hacer modificaciones.

Si ya me pareció increíble lo que se podía editar el Pokémon Rubí y Zafiro (hasta hacer uno totalmente nuevo), esto también puede llegar a conseguir grandes cosas.

PD: tengo que pillarme un flashcart slot-2 de DS para jugar a algunos hackroms T_T (¿cuánto cuestan?)

Antes de que te vayan a "Reagañar" te comento que en los jump los graficos estan en "formato GBA" por ende en la mayoria de los casos cualquier editor de tiles compatible ayuda a la extracccion/insercion de graficos los cuales no es lo mismo editarlos desde cero que solamete extraer e insertar (Un editor de tiles ahorra un 90% el trabajo aunque no lo creas) ademas hay muchos juegos que simplemente son "indecompilables" como los touch detective por ejemplo (Juego que le traigo ganas a traducir) y simplemente por el formato en el que estan no es posible editarlos del modo facil....
Por ejemplo el "TilEd 2002" es uno de los editores que en algunos casos pueden ayudar a accelerar el trabajo y por si a alguien le interreza pueda experimentar las cosas de una manera mas facil..

seme ha ocurrido que tambien se podriasn traducir el osu tatakae ouendan el 1 y 2 estaria guapo

Si fuera cosa facil de hacer alguien ya lo hubiera hecho...Se oye mas facil de lo que en la realidad es ....
Lo unico "editable" hasta el momento son los logos de arranque (INIS Nintendo) y sobre lo demas no se que tipo de compresion maneje...

Dr Katts escribió:Antes de que te vayan a "Reagañar" te comento que en los jump los graficos estan en "formato GBA" por ende en la mayoria de los casos cualquier editor de tiles compatible ayuda a la extracccion/insercion de graficos los cuales no es lo mismo editarlos desde cero que solamete extraer e insertar (Un editor de tiles ahorra un 90% el trabajo aunque no lo creas) ademas hay muchos juegos que simplemente son "indecompilables" como los touch detective por ejemplo (Juego que le traigo ganas a traducir) y simplemente por el formato en el que estan no es posible editarlos del modo facil....
Por ejemplo el "TilEd 2002" es uno de los editores que en algunos casos pueden ayudar a accelerar el trabajo y por si a alguien le interreza pueda experimentar las cosas de una manera mas facil..

Si, desenpaquetables si que parecen si los archivos, pero eso no es del todo cierto, bien cierto es que el tahaxan no los lee ni es capaz de encontrar nada, pero si desenpaquetas con el ds lazy te aparecerá un archivo (al menos en el touch detective 2, que me he bajado para comprovar que le pasaba lo mismo que al ultimo juego de death note) que se llama data.bin (en la carpeta dat).
Ahora solo te propongo una cosa:
Haz una búsqueda hexadecimal y busca estos valores:

52 4C 43 4E compara lo que te aparece con las cabeceras de los NCLR

52 47 43 4E compara lo que te aparece con las cabeceras de los NCGR

52 43 53 4E Esta es la cabecera de un archivo NSCR, que yo no se muy bien para que sirve, pero se que el tahaxan si lo sabe.

52 4E 41 4E estos archivos aún no los se manejar (tampoco el tahaxan y son archivos NANR) MM aunque ahora que los estoy viendo en el editor hexadecimal parecen archivos de animación o algo (quizás sean probablemente archivos que cambien determinados colores de las paletas).

52 45 43 4E Estos son los NCER y se parecen a los NANR, puesto que comparten un significativo de numeros de bites iguales y creo que también son de animación.



MMM, joop hubiera molado mas que apareciesen imagenes en jpg o png xDD (que hay juegos que las tienen como el csi, junto con .pic e .img)



Bueno, con esta información lo que puedes hacer (es un método chapucero y de bastante tiempo) es crear los archivos que te aparecen con sus correspondietes extensiones .ncgr, .nclr, .ncsr y las otras dos pues por el momento como que dan igual. Normalmente un archivo acaba alla donde empieza otro y ten en cuenta que las imágenes han de ser multiplos de 64 (bits); 64 caracteres hexadecimales en las de 16 o menos colores y 128 en las de de 16 a 256 colores, y las paletas tendran siempre 256 colores (1024 caracteres hexadecimales)
Los creas y los guardas en la misma carpeta donde tienes el .bin de la desenpaquetación, la empaquetas lo abres con el tahaxan y en teoria deberias de poder ver las imágenes, (se que lleva mucho tiempo hacerlo, pero el resultado es mejor); de todas formas las cabeceras de los .nclr pueden guiarte acerca de que colores hay en que determinado "offset" que te puede venir bien para los editores de tiles.

Yo la vedad prové mucho el tile molester que dicen que es el mejor y tal y encima que le ponia una imagen facilonga .ncgr el muy... no mostraba nada coerente ¬¬.


Bueno, lo de los archivos .bin me di cuenta esta mañana y probablemente me toque hacer una aplicación que se dedique a extraer lodas las paletas y los archivos de imagenes de este tipo de archivos, pero por ahora no puedo entre que no tengo tiempo ni el suficiente conocimiento de programación como para conseguir abrir archivos hexadecimales sin que el muy .... .... interprete los 00 como 0A0C ¬¬.


Saludos

Ya habia pensado en una solucion parecida pero por desgracia en juegos como el touch detective si mueves inadecuadamente un bit la rom simplemente se colapsa ademas de que en este caso particular "rastrear" los datos del juego que necesitamos es una verdadera faena..(Y no es lo mismo reemplazar un archivo dañado que toda la rom a acusa de un error)
Ahora en el caso de los tile editors varian bastante en como procesan los graficos (Algunos tienen ventajas sobre otros) todos y cada uo de ellos....Ademas que en la NDS utilizan diversos "templates" osease que encontraras graficos en formato GBA o en Nes o simplemente en modo "1Bit per pixel! por ende "Ver" los graficos no es de usar un "filtro" determinado....
En pocas palabras es un asunto demasiado complejo como para "estandarizarlo"

Si me dices como tienen que ser las busquedas de los archivos, puede que pueda programar un programa sencillo en C que haga dichas busquedas y guarde los archivos, pero aviso, me tendrias que decir como hacer todo, yo solo te lo programo, que de formatos de DS ni idea ^^

Saludos

Dr Katts escribió:Ya habia pensado en una solucion parecida pero por desgracia en juegos como el touch detective si mueves inadecuadamente un bit la rom simplemente se colapsa ademas de que en este caso particular "rastrear" los datos del juego que necesitamos es una verdadera faena..(Y no es lo mismo reemplazar un archivo dañado que toda la rom a acusa de un error)
Ahora en el caso de los tile editors varian bastante en como procesan los graficos (Algunos tienen ventajas sobre otros) todos y cada uo de ellos....Ademas que en la NDS utilizan diversos "templates" osease que encontraras graficos en formato GBA o en Nes o simplemente en modo "1Bit per pixel! por ende "Ver" los graficos no es de usar un "filtro" determinado....
En pocas palabras es un asunto demasiado complejo como para "estandarizarlo"

MM es cierto que no se debe estandarizar la forma de manipular los sprites en la nds. Porque bien es cierto que por ahora los archivos que están contenidos en un bin son algo diferentes a los que no lo están, puesto que la cabecera a simple vista parece igual, pero justamente donde se indica la longitúd del archivo en los bin es muy diferente y he estado trasteando de varias formas para hayar alguna respuesta coherente y no la he encontrado :'(.
Y probablemente al no tener la cabecera igual el tahaxan no sea capaz de leer el archivo (seguramente que habria que modificarlo y tal para que lo pudiese reconocer...) De todas formas seguiré trasteando un poco con los .bin que son un poco complicados y entretenidos; pero bueno, al menos ya creo que le he dado sentido a todos los bytes de las cabeceras de los archivos de imágenes .NCGR que supongo que serán muy semejantes en el resto de archivos.
MMM también leyendo la cabecera del .bin me llevó al comienzo de la cabecera de un archivo de imagen (unos bites que los use como bites de posición) pero a pesar de darle muchas vueltas, no conseguí que me diera mas direcciones asique seguramente solo fue una coincidencia :'(.

otto_xd escribió:Si me dices como tienen que ser las busquedas de los archivos, puede que pueda programar un programa sencillo en C que haga dichas busquedas y guarde los archivos, pero aviso, me tendrias que decir como hacer todo, yo solo te lo programo, que de formatos de DS ni idea ^^

Saludos

Eso si que estaria bien, además por aqui tengo un programa que creo que leia los bin del metroid, que bueno, no sirve para extraer archivos de otros bin que no sean el metroid, pero seguramente si te ayuden a tener una idea de los procedimientos que se usan y tal para las búsquedas y extracciones hexadecimales ^^.

Además el lenguaje c es mucho más rápido manejando bytes e imágenes que el que vengo usando hasta ahora (VB)... y eso que me he propuesto muchas veces meterme en c/c++, pero siempre me exo atras...

Bueno, aunque primeramente deberia reconocer estudiar a fondo los archivos .bin; ya que mi idea seria hacer un programa que fuese buscando las cabeceras de los archivos de imagen leyendo la longitud y extrayendolos, pero por ahora la longitud me es un misterio ¬¬.

De todas formas si te interesa hacer un programa para leer/modificar imágenes de roms de nds puedes hexar un ojo a algunos de los tutoriales que puse:
http://www.elotrolado.net/hilo_Breve-tutorial-de-manipulacion-de-imagenes-de-roms---NCGR-y--NCLR-_960853
(en este mismo hilo pongo como aparecen las imágenes de 16 o menos colores y las paletas en hexadecimal).
Aunque aún no lo haya explicado (quizás porque no lo he provado mucho ya qu eno encuentro imágenes de 256 colores) creo que en este tipo de imágenes no se les da la vuelta a las parejas de bites (aunque lo que puede ser es que se invierta la posición de los bites de cada tile, pero yo creo que no es así, por lo tanto son mas fáciles de representar).

Si le consigo encontrar lógica a las longitudes de los archivos en los .bin y/o hayar una forma de que mantenga un modelo parecido a los archivos sueltos (en cuanto a bytes y tal, ya que en los .bin parece que hay bites de más en dichos archivos) contactaré contigo y te tartaré de explicar los prodecimientos que se hayan de hacer para consegir una buena extracción de los archivos, aunque aun no lo termino de ver tan claro como creia ver ayer.


Y bueno, como dice dr Katts, lo malo es si se modifica algun byte de más que se va la room al carajo. Por eso también intento leer las cabeceras de estos archivos .bin que es donde se suele indicar donde empieza y acaba cada archivo y donde acaba el bin...


Bueno, si te sirve de guia te dejo la descarga del archivo que lee los .bin del metroid (viene con codigo fuente):
http://warezhole.hacking-cult.org/upload/dsgraph.rar



Yo seguire estudiando estos archivos.


Saludos

Me gusta tu trabajo, yo antes mmodificaba roms a lo bestia, me gustaria mucho descubrir algun metodo para extrar las texturas de los juegos 3d como el metroid, aunque yo directamente modificaba valores hexadeximales a voleo y salian cosas chulas

angel_gore escribió:

MM es cierto que no se debe estandarizar la forma de manipular los sprites en la nds. Porque bien es cierto que por ahora los archivos que están contenidos en un bin son algo diferentes a los que no lo están, puesto que la cabecera a simple vista parece igual, pero justamente donde se indica la longitúd del archivo en los bin es muy diferente y he estado trasteando de varias formas para hayar alguna respuesta coherente y no la he encontrado :'(.
Y probablemente al no tener la cabecera igual el tahaxan no sea capaz de leer el archivo (seguramente que habria que modificarlo y tal para que lo pudiese reconocer...) De todas formas seguiré trasteando un poco con los .bin que son un poco complicados y entretenidos; pero bueno, al menos ya creo que le he dado sentido a todos los bytes de las cabeceras de los archivos de imágenes .NCGR que supongo que serán muy semejantes en el resto de archivos.
MMM también leyendo la cabecera del .bin me llevó al comienzo de la cabecera de un archivo de imagen (unos bites que los use como bites de posición) pero a pesar de darle muchas vueltas, no conseguí que me diera mas direcciones asique seguramente solo fue una coincidencia :'(.



Eso si que estaria bien, además por aqui tengo un programa que creo que leia los bin del metroid, que bueno, no sirve para extraer archivos de otros bin que no sean el metroid, pero seguramente si te ayuden a tener una idea de los procedimientos que se usan y tal para las búsquedas y extracciones hexadecimales ^^.

Además el lenguaje c es mucho más rápido manejando bytes e imágenes que el que vengo usando hasta ahora (VB)... y eso que me he propuesto muchas veces meterme en c/c++, pero siempre me exo atras...

Bueno, aunque primeramente deberia reconocer estudiar a fondo los archivos .bin; ya que mi idea seria hacer un programa que fuese buscando las cabeceras de los archivos de imagen leyendo la longitud y extrayendolos, pero por ahora la longitud me es un misterio ¬¬.

De todas formas si te interesa hacer un programa para leer/modificar imágenes de roms de nds puedes hexar un ojo a algunos de los tutoriales que puse:
http://www.elotrolado.net/hilo_Breve-tutorial-de-manipulacion-de-imagenes-de-roms---NCGR-y--NCLR-_960853
(en este mismo hilo pongo como aparecen las imágenes de 16 o menos colores y las paletas en hexadecimal).
Aunque aún no lo haya explicado (quizás porque no lo he provado mucho ya qu eno encuentro imágenes de 256 colores) creo que en este tipo de imágenes no se les da la vuelta a las parejas de bites (aunque lo que puede ser es que se invierta la posición de los bites de cada tile, pero yo creo que no es así, por lo tanto son mas fáciles de representar).

Si le consigo encontrar lógica a las longitudes de los archivos en los .bin y/o hayar una forma de que mantenga un modelo parecido a los archivos sueltos (en cuanto a bytes y tal, ya que en los .bin parece que hay bites de más en dichos archivos) contactaré contigo y te tartaré de explicar los prodecimientos que se hayan de hacer para consegir una buena extracción de los archivos, aunque aun no lo termino de ver tan claro como creia ver ayer.


Y bueno, como dice dr Katts, lo malo es si se modifica algun byte de más que se va la room al carajo. Por eso también intento leer las cabeceras de estos archivos .bin que es donde se suele indicar donde empieza y acaba cada archivo y donde acaba el bin...


Bueno, si te sirve de guia te dejo la descarga del archivo que lee los .bin del metroid (viene con codigo fuente):
http://warezhole.hacking-cult.org/upload/dsgraph.rar



Yo seguire estudiando estos archivos.


Saludos

Digamos que estoy malo y no puedo salir, ya tengo pasatiempo para esta tarde xDDDD

Vere que puedo hacer.

Saludos

Bueno, si quieres te pongo lo que tengo estudiado sobre las empaquetaciones en archivos .xap; que son los que contiene el juego de death note kira game, en la carpeta \data\data\window\menu

Es el único juego que he visto que los use, pero también he de decir que es con el que me acabo de dar cuenta que los tiene.

Bueno, aqui te pongo la información que saqué y que seguramente te pueda ser util si piensas hacer un programa que desenpaquete estos archivos. Bien estaria un programa que desenpaquetase todos los archivos de las roms que no es capaz de desenpaquetar el ds lazy ^^.

Espero que te sea util y te mantenga entretenido:

nombre_a.xap
contiene: NCER, NANR, NMCR y NMAR
Encabezado por
Esta cabecera:
58 61 70 41 04 00 04 00 00 00 00 00 50 00 00 00
45 43 4E 30 B0 00 00 00 B0 00 00 00 50 00 00 00
4E 41 4E 30 74 00 00 00 74 00 00 00 00 01 00 00
43 4D 4E 30 3C 00 00 00 3C 00 00 00 74 01 00 00
41 4D 4E 30 64 00 00 00 64 00 00 00 B0 01 00 00

Donde la primera linea:
58 61 70 41 04 00 04 00 00 00 00 00 50 00 00 00
Es la que encabeza todo.
En la cual el quinto byte (04) creo que representa le numero de archivos que linquea.
Y el decimotercer byte indica la longitud de la cabecera.


Donde la segunda linea:
45 43 4E 30 B0 00 00 00 B0 00 00 00 50 00 00 00
es la que indica la posicion del archivo NCER y su longitud
Donde el quinto y noveno byte (B0) representa la longitud del archivo NCER.
Y donde el decimotercer byte (50) indica la posición (en el archivo xap) del archivo NCER.


La tercera linea:
4E 41 4E 30 74 00 00 00 74 00 00 00 00 01 00 00
Indica la posicion y longitud del archivo NANR
Donde el quinto y noveno byte (74) representa la longitud del archivo NANR.
Y donde el decimotercer y decimocuarto byte (00 01 que invertida es 01 00) indica la posición (en el archivo xap) del archivo NANR.

La cuarta linea:
43 4D 4E 30 3C 00 00 00 3C 00 00 00 74 01 00 00
Indica la posicion y longitud del archivo NMCR
Donde el quinto y noveno byte (3C) representa la longitud del archivo NMCR.
Y donde el decimotercer y decimocuarto byte (74 01 que invertida es 01 74) indica la posición (en el archivo xap) del archivo NMCR.

La quinta linea:
41 4D 4E 30 64 00 00 00 64 00 00 00 B0 01 00 00
Indica la posicion y longitud del archivo NMAR
Donde el quinto y noveno byte (64) representa la longitud del archivo NMAR.
Y donde el decimotercer y decimocuarto byte (B0 01 que invertida es 01 B0) indica la posición (en el archivo xap) del archivo NMAR.


En conclusión, los cuatro primeros bytes de la 2ª,3ª,4ª y 5ª linea son tal que así:
4 bytes predefinidos que determinan el tipo de archivo (creo) que enlazan
Los siguiente 4 bytes que representan la longitud del archivo enlazado.
Los otros 4 bytes que representan también la longitud del archivo enlazado.
Y los últimos 4 bytes que representan la dirección del archivo enlazado.




nobre_g.xap
Contiene: NCGR y NCLR
Encabezado por esta cabecera
58 61 70 41 02 00 04 00 00 00 00 00 30 00 00 00
47 43 4E 30 B0 B8 00 00 B0 B8 00 00 30 00 00 00
4C 43 4E 30 40 06 00 00 40 06 00 00 E0 B8 00 00

Donde la segunda linea:
47 43 4E 30 B0 B8 00 00 B0 B8 00 00 30 00 00 00
Indica la posicion y longitud del archivo NCGR
Donde el quinto y sexto; y noveno y decimo byte (B0 B8 que invertido es B8 B0) representa la longitud del archivo NCGR.
Y donde el decimotercer byte (30) indica la posición (en el archivo xap) del archivo NCGR.

La tercera linea:
4C 43 4E 30 40 06 00 00 40 06 00 00 E0 B8 00 00
Indica la posicion y lontitud del archivo NCLR
Donde el quinto y sexto; y el noveno y décimo byte (40 06 que invertido es 06 40) representa la longitudi del archivo NCLR.
Y donde el decimotercer y decimocuarto byte (E0 B8 que invertido es B8 E0) indica la posición (en el archivo xap) del archivo NCLR.


Un modelo de busqueda:
Primero se lee la cabecera teniendo en cuenta estos parámetros:
58 61 70 41 XX 00 04 00 00 00 00 00 YY 00 00 00
XX es el numero de archivos que linquea
YY es la longitud de la cabecera (o donde empieza el primer archivo, vamos).


los cuatro primeros Bytes indican el tipo de archivo linqueado:
45 43 4E 30 (NCER)
4E 41 4E 30 (NANR)
43 4D 4E 30 (NMCR)
41 4D 4E 30 (NMAR)
47 43 4E 30 (NCGR)
4C 43 4E 30 (NCLR)
Los cuatro siguientes:
XX XX XX XX indican la longitud
Los cuatro siguientes:
XX XX XX XX indican la longitud
Y los cuatro últimos:
XX XX XX XX
Indican la posicion


A la hora de leer los bytes se tiene que tener en cuenta que:
12 seria 12 00 00 00
1234 seria 24 12 00 00
123456 seria 56 43 21 00
12345678 seria 78 56 43 21



Saludos

Wow, increible explicacion, voy a seguir leyendo y si me pongo te aviso con lo que saque

Saludos y gracias, muy interesante.

Debe estar muy bien,pero no lo veo T_T
Pero lo de poner tus propios personajes debe molar =)
Ya veo un sonic en el Jump Ultimate Stars...

gallito-12 escribió:Debe estar muy bien,pero no lo veo T_T
Pero lo de poner tus propios personajes debe molar =)
Ya veo un sonic en el Jump Ultimate Stars...

o un edit completo con personajes del smash

lestar escribió:
o un edit completo con personajes del smash

Pero atacaran con los ataques del JUMP