Fuente Radiant Historia

Lugar donde se intentarán resolver problemas específicos
Responder
Avatar de Usuario
gadesx
Administrador
Administrador
Mensajes: 1984
Registrado: 24 Ene 2011, 16:43
Ubicación: El puche
Contactar:

Mensaje por gadesx » 16 Ago 2011, 17:51

Ahora pasan calor en el desierto, pero en cristiano XDDDDDDDD
¿la tabla es de esas con todos los caracteres japos tambien?

Skye
Mensajes: 95
Registrado: 03 Ago 2011, 20:09

Mensaje por Skye » 16 Ago 2011, 20:49

Sí, tiene caracteres japoneses.

CUE, la verdad, no sé qué decir... xD Muchas gracias, genial, eres el amo, etc... xD

Avatar de Usuario
CUE
Administrador
Administrador
Mensajes: 5520
Registrado: 24 Ene 2011, 16:52

Mensaje por CUE » 17 Ago 2011, 08:03

Éstas son las fuentes (japonesa, occidental, occidental modificada). El problema de siempre es que los caracteres tienen su ancho propio, que no sé dónde se almacena y no me apetece buscar más, así que lo que he hecho es reemplazar caracteres no usados, o eso espero, por los que se necesitan, cada uno de ellos con el ancho apropiado:
[img]http://img585.imageshack.us/img585/2158/fntj1.png[/img] [img]http://img580.imageshack.us/img580/8739/fntu1.png[/img] [img]http://img220.imageshack.us/img220/4664/nuevou1.png[/img]

Estos son los catacteres nuevos y los que han sido sustituidos:

Código: Seleccionar todo

á - K   E1 - 4B
é - W   E9 - 57
í - `   ED - 60
ó - X   F3 - 58
ú - Z   FA - 5A
ü - $   FC - 24
ñ - ~   F1 - 7E
¡ - |   A1 - 7C
¿ - }   BF - 7D
Un ejemplo de dos textos en unicode:

Código: Seleccionar todo

[00000001]
...What you see here is the
public beating of a traitor.
{FD14}{end}

[00000002]
Oh, are you a traveler?
...You probably shouldn't be
seeing this, then.{end}

...

[000002BD]
救南虜位増質滅密{FD14}{end}

[000002BE]
浅色救ペンダント虜位増質滅密{FD14}{end}

[000002BF]
ツボ佐堕ベルト虜位増質滅密{FD14}{end}

...
Un ejemplo de los mismos textos en ASCII:

Código: Seleccionar todo

[00000001]
...What you see here is the
public beating of a traitor.
{FD14}{end}

[00000002]
Oh, are you a traveler?
...You probably shouldn't be
seeing this, then.{end}

...

[000002BD]
{FE28}{FB4E}{FE3C}{FC7B}{FE25}{FE63}{FE39}{FE1F}{FD14}{end}

[000002BE]
{FCDE}{FC63}{FE28}{F7}{DD}{EA}{DD}{C3}{FE3C}{FC7B}{FE25}{FE63}{FE39}{FE1F}{FD14}{end}

[000002BF]
{C1}{F3}{FBF9}{FE1B}{F2}{D8}{C3}{FE3C}{FC7B}{FE25}{FE63}{FE39}{FE1F}{FD14}{end}

...
Luego más, que tengo que ir a ganar los garbanzos del mes.

Skye
Mensajes: 95
Registrado: 03 Ago 2011, 20:09

Mensaje por Skye » 17 Ago 2011, 13:04

¿En qué offset empieza la fuente?

Avatar de Usuario
CUE
Administrador
Administrador
Mensajes: 5520
Registrado: 24 Ene 2011, 16:52

Mensaje por CUE » 17 Ago 2011, 13:31

En un offset mayor o igual que 0x00000000 y menor que 0x2186C38 para la versión americana (cabronazo que soyyyyyyyy) :twisted:

Cuando ponga lo de los textos lo explico, que va todo en el mismo paquete, y al mismo precio.


EDITADO: 0x016A2F0C para la USA y 0x016A31B0 para la JAP (si en el fondo no soy malo, el problema es que soy demasiado profundo y se tarda en llegar al fondo)

Avatar de Usuario
CUE
Administrador
Administrador
Mensajes: 5520
Registrado: 24 Ene 2011, 16:52

Mensaje por CUE » 18 Ago 2011, 11:04

Parche para poner la fuente en 'Data.bin': http://www.megaupload.com/?d=KSSKNK4E
Simple extractor de textos: http://www.megaupload.com/?d=ER9PMP1U

La fuente se mete con un simple parche xdelta. Al aplicarlo se genera 'new_Data.bin', que es donde está la fuente modificada según lo explicado en el otro post. No me apetecía cambiar el nombre a 'Data.bin', así que eso que te toca hacer. Va todo incluido, el parche, el xdelta y un simple batch que lo hace todo.

Los textos, más concretamente toda la carpeta 'msg\' del fichero se sacan con el extractor. He puesto dos versiones, una ASCII, que es la que se deberá usar, y otra UNICODE, que muestra los caracteres japoneses y extrae otras cositas.

La carpeta 'msg' se compone de (version USA):
- la fuente, un simple gráfico raw (0x016A2F0C)
- 1 fichero LOG con la correspondencia UNICODE entre los caracteres de la fuente (0x016AE30C)
- 59 ficheros de texto (0x016AED10)
- 1 fichero HTM en japonés que no parece tener sentido (0x016C1A6C)
- 13853 ficheros de texto (0x016C38F8)

La versión ASCII sólo saca los ficheros de texto, que no es paja. Sacarlos es simple, basta con posicionarse en el principio de un fichero y empezar a leer, sabiendo cómo están estructurados (longitud, IDs, offsets, y todo eso ya explicado). El final del texto es un 0xFF, aunque a veces hay más, así que saltamos todos los 0xFF que haya al final, alineamos a 4 bytes, y así ya estamos en el inicio del siguiente fichero. Hay que hacer esto dos veces, pues el HTM está entre medias y nos fastidia el invento.

Los caracteres se tratan fácilmente, y basta con ver la imagen de la fuente para saberlo:
- el 0x00 es un espacio en blanco
- del 0x01 al 0x20 se muestran en hexadecimal (no sé si habrá alguno)
- del 0x21 al 0x7E se muestra el ASCII correspondiente
- del 0x7F al 0xF9 se muestran en hexadecimal
- el 0xFF indica que es el final del texto/fichero

Los códigos restantes, del 0xFA al 0xFE, indican que son caracteres de 2 bytes, siendo los 0xFAXX los correspondientes al segundo set de la imagen (los 256 caracteres que hay después de esos 6 '=', justo los que corresponderían a esos códigos. Los siguientes serían los 0xFBXX, después los 0xFCXX y después los 0xFEXX. Los 0xFDXX son caracteres especiales, y sólo he visto 2:
- 0xFD00, que es un salto de línea
- 0xFD14, que será algo, pero no me interesa

Al final de cada texto he incluido el offset dividido entre 4 y la longitud, para poder buscar esos datos en el IDX.

Una cosa que se podría hacer, y que yo, para no variar, he pasado totalmente, es tomar los nombres de los ficheros del NDX, pues parece que están en el mismo orden que los datos del BIN. Yo he puesto como nombre el offset de inicio de cada fichero.

La versión UNICODE saca los textos en UNICODE (obvio, ¿no?). Ahí no hay ASCIIs, así que las letras "entendibles" que salen son las correspondientes a la tabla 'Halfwidth and Fullwidth' (http://jrgraphix.net/r/Unicode/FF00-FFEF), que son las mismas letricas que en ASCII, pero a lo japonés. Además, se saca el fichero HTM y la correspondencia entre caracteres. Otra cosa que hace es que detecta si es el 'Data.bin' USA o el JAP, que tienen los datos en distinto sitio, además de que no tienen el mismo número de ficheros.

Ésta es la version ASCII del programa, y con todo lo explicado no debería haber problemas para interpretarlo:

Código: Seleccionar todo

#include <stdio.h>
#include <stdlib.h>

#define BINNAME    "Data.bin"
#define FOLDERNAME "ascii"

unsigned char *Load&#40;char *fn&#41;;
void Extract&#40;unsigned char *fb, unsigned int start, unsigned int count&#41;;

int main &#40;void&#41; &#123;
  unsigned char *fb;

  fb = Load&#40;BINNAME&#41;;

  if &#40;mkdir&#40;FOLDERNAME&#41; > 0&#41; exit&#40;-1&#41;;

  Extract&#40;fb, 0x016AED10,    59&#41;;
  Extract&#40;fb, 0x016C38F8, 13853&#41;;

  free&#40;fb&#41;;

  return&#40;0&#41;;
&#125;

unsigned char *Load&#40;char *fn&#41; &#123;
  FILE *fp;
  unsigned int fs;
  unsigned char *fb;

  if &#40;&#40;fp = fopen&#40;fn, "rb"&#41;&#41; == NULL&#41; exit&#40;-1&#41;;
  fs = filelength&#40;fileno&#40;fp&#41;&#41;;
  if &#40;&#40;fb = &#40;char *&#41; malloc&#40;fs&#41;&#41; == NULL&#41; exit&#40;-1&#41;;
  if &#40;fread&#40;fb, 1, fs, fp&#41; != fs&#41; exit&#40;-1&#41;;
  if &#40;fclose&#40;fp&#41; == EOF&#41; exit&#40;-1&#41;;

  return&#40;fb&#41;;
&#125;

void Extract&#40;unsigned char *fb, unsigned int start, unsigned int count&#41; &#123;
  FILE *fp;
  char fn&#91;256&#93;;
  unsigned int *data;
  unsigned char *text;
  unsigned int len, num;
  unsigned short ch;

  while &#40;count--&#41; &#123;
    sprintf&#40;fn, "%s/%08X.txt", FOLDERNAME, start&#41;;
    printf&#40;"%s\n", fn&#41;;

    if &#40;&#40;fp = fopen&#40;fn, "wb"&#41;&#41; == NULL&#41; exit&#40;-1&#41;;

    data = &#40;int *&#41;&#40;fb + start&#41;;

    len = *data++;
    num = &#40;len - 4&#41; / 8;
    fprintf&#40;fp, "start=%08X\r\ntotal=%08X\r\n", start, num&#41;;

    text = fb + start + len + 4; // por si num es cero

    while &#40;num--&#41; &#123;
      fprintf&#40;fp, "\r\n&#91;%08X&#93;\r\n", *data++&#41;;
      text = fb + start + len + 4 + *data++;
      while &#40;&#40;ch = *text++&#41; != 0xFF&#41; &#123;
        if      &#40;!ch&#41;       fprintf&#40;fp, " "&#41;;
        else if &#40;ch < 0x20&#41; fprintf&#40;fp, "&#123;%02X&#125;", ch&#41;;
        else if &#40;ch < 0x7F&#41; fprintf&#40;fp, "%c", ch&#41;;
        else if &#40;ch < 0xFA&#41; fprintf&#40;fp, "&#123;%02X&#125;", ch&#41;;
        else &#123;              // FAnn, FBnn, FCnn, FEnn, FD00, FD14
                            ch = &#40;ch << 8&#41; | *text++;
                            if &#40;ch == 0xFD00&#41; fprintf&#40;fp, "\r\n"&#41;;
                            else              fprintf&#40;fp, "&#123;%04X&#125;", ch&#41;;
        &#125;
      &#125; 
      fprintf&#40;fp, "&#123;end&#125;\r\n"&#41;;
    &#125;

    fprintf&#40;fp, "\r\n%08X&#58;%08X\r\n", start / 4, text - fb - start&#41;;

    if &#40;fclose&#40;fp&#41; == EOF&#41; exit&#40;-1&#41;;

    len = text - fb - start;       // longitud real del fichero
    while &#40;*text++ == 0xFF&#41; len++; // saltamos los 0xFF finales
    len = &#40;len + 3&#41; & -4;          // ajustamos a 4 bytes

    start += len;
  &#125;
&#125;
Ahora sólo quedaría hacer el proceso inverso: coger los ficheros con los textos y volverlos a meter. Como no se conoce la estructura del IDX, tendrá que ser del mismo tamaño que originalmente, por lo que habrá que controlar su longitud. A mí esas cosas no me gustan, así que te lo dejo a tí.

Skye
Mensajes: 95
Registrado: 03 Ago 2011, 20:09

Mensaje por Skye » 18 Ago 2011, 14:34

Al cambiar un offset por otro en el idx y corregir el tamaño, funciona sin problemas. Se podría o hacer los archivos tan grandes como queramos y corregir todos los punteros, o intercambiar offsets cuando se necesite algún archivo más grande...
Lo que me está sacando de quicio son los dos bytes después del tamaño, que parece que van a su bola. Eso sí, si se te ocurre cambiarlos, el texto no aparece, sólo aparece el sprite del personaje un momento y enseguida cambia al siguiente texto.
Algo extraño que también pasa al cambiar los offsets: con el original, el texto aparecía en la memoria en el offset 0x215F824, pero al cambiarlo aparece en 0x22ACAC8. Sin embargo funciona igual, por lo que no debe ser importante...
Y si cambias los offsets sin corregir el tamaño, te aparece un poco de texto y un montón de nombres de archivo... xD

El extractor y la fuente funcionan genial, muchas gracias :)

Avatar de Usuario
CUE
Administrador
Administrador
Mensajes: 5520
Registrado: 24 Ene 2011, 16:52

Mensaje por CUE » 18 Ago 2011, 14:48

Me temo que no es tan simple como dices. Al cambiar un offset debes cambiar el de todos los ficheros que le siguen.

Imagina que tenemos tres ficheros:
- A de 0x1000 bytes en el offset 0x000000 (ocupa desde 0x000000 hasta 0x00FFFF)
- B de 0x2000 bytes en el offset 0x001000 (ocupa desde 0x001000 hasta 0x02FFFF)
- C de 0x3000 bytes en el offset 0x003000 (ocupa desde 0x003000 hasta 0x05FFFF)

Ahora modificamos A y el nuevo tamaño es 0x1800, lo que nos debería dejar:
- A de 0x1800 bytes en el offset 0x000000 (ocupa desde 0x000000 hasta 0x017FFF)
- B de 0x2000 bytes en el offset 0x001800 (ocupa desde 0x001800 hasta 0x037FFF)
- C de 0x3000 bytes en el offset 0x003800 (ocupa desde 0x003800 hasta 0x067FFF)

Como ves, hemos tenido que cambiar los offsets de todos los ficheros que siguen a A.

En el juego es más complicado, pues los offsets no están ordenados, así que tendrías que buscar uno a uno todos los offsets de todos los ficheros para poder actualizar correctamente cuando cambien las longitudes. Y luego rezar para que no haya alguna otra historia de por medio.

Skye
Mensajes: 95
Registrado: 03 Ago 2011, 20:09

Mensaje por Skye » 03 Oct 2011, 19:11

Pueeees estos días me he puesto a trazar el código asm con el no$gba (sí, soy masoca) y tras mucho dolor de cabeza, algo he conseguido sacar. Otra cosa es que sea útil, pero lo pongo aquí por si acaso ^^
Lo primero, el idx se carga en la memoria en 02178648.
Bueno, hice un ramdump y apunté dónde está nuestro puntero dividido por 4 del primer texto (00DE705D), y sumando el 02000000 de la ram está en 021950C4. Hala, breakpoint on read y a ver qué pasa...
Y así, poniendo breakpoints aquí y allá... llego a lo interesante ^^

El juego coge nuestro "puntero" de 6 bytes (los del principio del idx), carga 4 de esos 6 bytes, y le hace un logical shift left 6 (se puede hacer en la calculadora del windows). Sólo coge los últimos 4 bytes del resultado. (00E53540). Luego le hace un right shift, de 7 esta vez, y lo suma a 02178648 (donde empieza el idx). Y sale 021950B2.
Luego entra en un bucle donde va sumando a ese offset hasta que consigue que dos registros sean iguales. No he seguido muy bien esa parte, pero parece que tiene que ver con esos dos bytes después del tamaño que me fastidiaban tanto.
Luego miraré esa parte con más tranquilidad...

Después de esto tendré que ver cómo sabe qué puntero cargar :O lo que me espera...
Por cierto en este caso el puntero era 4C0394D58A00. Sólo usa los primeros 4 bytes para lo de arriba, el que queda lo carga en otro registro y hace otras cosas en las que no me he fijado.

EDIT
Ya sé cómo acaba en la dirección correctaaaaa :)
Y sí, tenía que ver con esos dos bytes. Mucho que ver. Resulta que el juego guarda la ruta del archivo que quiere importar. Pues si sumamos el segundo byte al offset del nombre de archivo y vemos a qué valor hexadecimal corresponde esa letra, es el mismo que el primer número. El juego usa eso para comprobar si está en el puntero correcto :)
Ejemplo:
La ruta del archivo es msg/ja/Event/evt001/501/002.msg
El segundo byte de nuestro puntero es 19 (25 en decimal)
El carácter número 25 es un 0, y en ascii se representa con 30.
Miramos el primer byte y... hala! es 30!! :)

Avatar de Usuario
CUE
Administrador
Administrador
Mensajes: 5520
Registrado: 24 Ene 2011, 16:52

Mensaje por CUE » 05 Oct 2011, 11:06

En pocas palabras: ¿lo qué?

Me pillas totalmente en off, justo en esos momentos donde el poco tiempo que tengo lo uso para un proyecto que espero sacar pronto, pero para nada más, y no me he enterado de nada. No seas mala y pon imágenes, que ahora mismo no me acuerdo de nada de la estructura del juego, y eso que me han preguntado por otro que usa el mismo sistema de archivos.

Skye
Mensajes: 95
Registrado: 03 Ago 2011, 20:09

Mensaje por Skye » 05 Oct 2011, 19:13

No sé dónde voy a poner imágenes xD

Desde el principio:
El juego tiene 3 archivos: el Data.bin, el Data.idx, y el Data.ndx.

En el bin están todos los textos/gráficos/etc empaquetaditos, mientras que en el ndx está la estructura de ficheros y los nombres de archivo. El idx no tenía ni pies ni cabeza, al menos para mí xD Bueno, citándote:
CUE escribió:Lo único que tengo apuntado del idx es que empieza con:
- 4 bytes con el número de elementos (son 0x800)
- 4 bytes a 0
Luego vienen los elementos, que son dos valores de 3 bytes que no sé qué son, donde el primero va en orden creciente:

Código: Seleccionar todo

- 006011 0009B0
- 006113 000F74
- 006279 000DB0
- 006391 006F24
- 00647D 008100
- 0065F5 000600
- 006769 0001FC
- 006939 000168
Luego descubriste que si el offset de algún archivo en el bin se divide por 4 y se busca el resultado en el idx, aparece seguido del tamaño del archivo en cuestión.

Ejemplo: Un texto comienza en 0x175C378 en el bin. Se divide por 4 y sale 5D70DE. Buscamos DE705D (little endian) en el idx y encontramos esto:
DE 70 5D 00 30 00 00 00 35 14
Donde los 4 primeros bytes son el offset dividido por 4, los 4 siguientes son el tamaño, y luego hay 2 más que no sabíamos que eran.

Bueno, ahora las novedades:
Para empezar, el juego carga el idx enterito en la memoria, y empieza en el offset 02178648.

Sobre los elementos del principio: ¿Son 2 valores de 3 bytes, no? Pues por lo que he visto en el código asm, para el primer texto del juego (el del desierto):
Coge el elemento D5 94 03 4C 8A 00 (está en el idx en 0x1262)
Carga 4 de esos 6 bytes. (4C0394D5)
Le hace un logical shift left de 6, que es lo mismo que multiplicar por 2^6=64=40h. Como el resultado es mayor de 4 bytes, coge los 4 últimos bytes (00E53540)
A eso le hace un logical shift right de 7, o divide por 2^7=128=80h, y sale 1CA6A. Esto lo suma a la dirección del idx: 02178648+1CA6A=021950B2

Esa no es la dirección de nuestro puntero. ¿Qué hace el juego? Pues un bucle. Hala:

Primero: Tiene la ruta del archivo guardadita en la ram, concretamente en 027E3720. En este caso es: msg/ja/Event/evt001/501/001.msg

Segundo: ¿Te acuerdas de esos 2 bytes en el idx después del tamaño? Esos que no parecían pintar nada, pero en cuanto se cambian se fastidia el juego. Pues aquí es donde se usan:

Recordemos lo del idx: DE 70 5D 00 30 00 00 00 35 14
Nuestros 2 bytes son 35 y 14, o little endian 14 y 35. En fin, ¿para qué sirven? Pues si sumamos el primer byte (14) al offset de la ruta de nuestro archivo de texto (027E3720) obtenemos 027E3734. En ese offset hay un carácter, en este caso es un 5. ¿Qué es 5 en ascii? 35. ¿Qué es nuestro segundo byte? 35. ^^
He comprobado esto cambiando el 35 14 por 76 08 y funciona sin problemas ^^

¿Cómo llega el juego a esos valores? A ver cómo explico esto sin pegar el asm... Voy a probar con pseudo-código:

Código: Seleccionar todo

FILEPATH_OFFSET = 027E3720

offset1 = 021950B2
offset1 = offset1+1
flag = 1
flagstart = 1
add = 0

while flag&#58;
      offset2 = offset1
      offset1 = offset1+4
      if add != 0&#58;
            offset1 = offset1+4

      byte1 = 1 byte desde offset1
      flag = 0
      byte2 = 1 byte desde offset1+1
      byte2 = 1 byte desde FILEPATH_OFFSET+byte2
      
      if byte2 == byte1&#58;
            pass
      else&#58;
            flag = flagstart
     
      offset1=offset1+2
      byte1=1 byte desde offset1
      offset1=offset1+1
      if byte1 == 0&#58;
            add=add+1
Esto es lo que hace el asm "traducido" a pseudo python, seguro que se puede hacer mil veces mejor.

Cuando sale del bucle porque está en el offset correcto, entonces es cuando empieza a cargar desde el offset2, multiplica por 4, etc.

¿Mejor así? xD

Avatar de Usuario
CUE
Administrador
Administrador
Mensajes: 5520
Registrado: 24 Ene 2011, 16:52

Mensaje por CUE » 05 Oct 2011, 21:01

Me sigues pillando espeso, pero ya he visto algo para que simplifiques el proceso:
Skye escribió:...Coge el elemento D5 94 03 4C 8A 00 (está en el idx en 0x1262)
Carga 4 de esos 6 bytes. (4C0394D5)
Le hace un logical shift left de 6, que es lo mismo que multiplicar por 2^6=64=40h. Como el resultado es mayor de 4 bytes, coge los 4 últimos bytes (00E53540)
A eso le hace un logical shift right de 7, o divide por 2^7=128=80h, y sale 1CA6A. Esto lo suma a la dirección del idx: 02178648+1CA6A=021950B2...
Nunca te fíes de lo que haga el ensamblador, que a veces suele hacer cosas de más. De entrada, parece que se trata de 3 bytes y no de 4, y a esos 3 bytes es a los que hay que dividir entre 2, el resto es parafernalia para poner a 0 los bits superiores. Esto suele pasar porque el ARM no es capaz de leer 3 bytes de golpe, así que coge 4 y el desplazamiento de bits a veces es más rápido que hacer un AND 0x00FFFFFF.

Lo otro ya lo pillo. Es, o parece ser, una chapucera forma de control consistente en poner el carácter X que aparece en la posición Y del nombre, y se guarda como X-Y. ¿Ves como en dos líneas lo podías haber explicado en vez de hacerme leer todo? ;)

Pero sigue estando el problema de que, si no recuerdo mal, las entradas no tenían longitud fija y había algunas con más bytes que otras.

Skye
Mensajes: 95
Registrado: 03 Ago 2011, 20:09

Mensaje por Skye » 06 Oct 2011, 19:30

Bueno, creo que sé cómo llega el juego al primer puntero (los de 6 bytes). Y... tiene que ver con la ruta del archivo xD Ya tenemos los 3 archivos (bin,ndx,idx) conectados xD Qué cosas más raras hacen los de atlus...
Como parece que no gusta leer (xD) voy a intentar hacerlo cortito.

Se va al offset donde guarda la ruta del archivo. Lee un carácter. Multiplica ese carácter por 25 y le suma el mismo carácter. Lee el siguente. Multiplica el resultado de lo anterior por 25 y le suma el carácter nuevo. Sigue así hasta llegar al final de la ruta.
Al valor resultante de todas esas multiplicaciones, le hace un AND con 7FF. El resultado de eso lo suma al offset de inicio de punteros (vamos, al idx saltándose los primeros 8 bytes). Y ya está.

Y en efecto hay entradas con más bytes que otras...
He visto entradas sin los bytes de control y entradas con los bytes de control dos veces o.O y era un texto normalito.

Avatar de Usuario
CUE
Administrador
Administrador
Mensajes: 5520
Registrado: 24 Ene 2011, 16:52

Mensaje por CUE » 07 Oct 2011, 08:41

Si he entendido bien, sería algo así como

Código: Seleccionar todo

hash = nombre&#91;0&#93; * 25 + nombre&#91;0&#93;;
for &#40;i = 1; nombre&#91;i&#93;; i++&#41; hash = hash * 25 + nombre&#91;i&#93;;
hash &= 0x7FF;
(¿ves como se dice lo mismo sin tantas letras de 'para leer'?)

¿Y no será?

Código: Seleccionar todo

hash = 0;
for &#40;i = 0; nombre&#91;i&#93;; i++&#41; hash = hash * 25 + nombre&#91;i&#93;;
hash &= 0x7FF;
La segunda forma es la clásica de generar un hash a partir de un nombre, con lo que siempre se hace referencia a un número en vez de a todos sus caracteres. Así es mucho más sencillo de tratar.

Skye
Mensajes: 95
Registrado: 03 Ago 2011, 20:09

Mensaje por Skye » 07 Oct 2011, 21:11

Estaba yo intentando hacer un programa para eso, pero no conseguía el mismo resultado final.
Resulta que es culpa de estos dos:

Código: Seleccionar todo

cmp r14,#0x5A
addls r14,r14,#20
El segundo se ejecuta cuando le da la gana, parece. Por ejemplo cuando r14 es 45.

Responder