Citação de: ajkmetiuk online Março 08, 2023, 17:11:42 PM
olá, já foi lançado, vc pode estar conferindo aqui:
http://www.romhacking.net.br/index.php?topic=2355.0
aliás, essa postagem poderia ser trancada, já que não foi reutilizada.

caralho, meus parabéns pra vocês, como não dizia nada aqui na pagina do projeto e nem mudaram o titulo achei que não tinha lançado ainda. Meus sinceros agradecimentos pelos serviços prestados a comunidade kkk não vejo a hora de jogar

Parabéns pelo projeto! Pra mim esse é um dos jogos de SNES que mais tava precisando de uma tradução. Parece que ta ficando perfeita. Só não entendi o porque das cores europa/japão nos botões se aqui no Brasil o snes tem os botões roxo/lavanda.

Seria legal garantir a compatibilidade com aquele hack pro segundo jogador controlar o cachorro.

Boa sorte!

Parabéns pela iniciativa! Já joguei esse jogo de cabo a rabo ano passado, tive muita vontade de traduzir ele.

Vi que ainda não começou a introdução, acho que vai ficar bom se fizer aquele texto escrito como se fosse um texto bíblico. O mesmo vale pras falas de alguns personagens, principalmente o diabo.

Falando nele, se não me engano na versão original ele seria chamado de Satanás, e na AGTP de "O caído". Na minha opinião Satanás se encaixa melhor na história e nos textos principalmente pro final do jogo.

Também sugiro um pouco mais de atenção na tradução das frases. Por exemplo o título da primeira parte "Meu coração estava totalmente inquieto" na verdade é uma passagem bíblica, e em cada tradução da bíblia aparece de forma diferente, como por exemplo "Meu coração ardia-me no peito" (NVI), "Incendeu-se dentro de mim o meu coração"(ARC), "E o meu coração ficou muito aflito"(NVLH), etc. Talvez seria bom escolher uma versão da bíblia e tirar todas as citações bíblicas dela para manter a consistência. Creio eu que a maioria aqui no brasil tem mais chances de reconhecer a versão ARC.

Enfim, boa sorte no projeto, se quiser alguém pra ajudar com o hacking ou revisão de textos pode mandar MP.

Hackear o MVS não é nada excepcionalmente difícil, a arquitetura dele é parecida com a do Mega Drive, em alguns sentidos é até mais fácil programar pro MVS por conta do seu poder imenso tanto na questão de gráficos quanto memória e processamento. Se não me engano o próprio KOF '02 tem funcionalidades de debugging inclusas na ROM, e acho que tbm da pra fazer debug pelo IDA Pro.

Pode ter certeza que qualquer um com tempo e habilidade pra fazer um "Remix" do KOF '02 ia querer fazer as suas próprias modificações do seu próprio jeito e não as que vocês propuseram. Então não tem jeito, é ou aprender m68k ou aprender m68k.

Ponteiros nada mais são que bytes que o jogo lê pra saber onde começam as strings. Por exemplo, um jogo tem duas strings, cada uma referente a um item:



Na ROM terá dois ponteiros, como o snes é little endian, ou seja, lê os bytes do menor para o maior, serão D118, que aponta para 0x18D1, e D718, que aponta para 0x18D7, organizados em uma tabela, junto com so próximos ponteiros, por exemplo:

D1 18 D7 18 DC 18 E0 18 (..) FE 18 02 19 06 19
(ponteiros de 2 bytes (16-bits))

ou talvez:

D1 18 00 D7 18 00 DC 18 00 E0 18 00 (...) FE 18 00 02 19 00 06 19 00
(ponteiros de 3 bytes (24-bits))

Depende muito do jogo, mas muitas vezes da pra encontrar a tabela só procurando D118 e achando algo que se pareça com essa estrutura.

Ao traduzir o jogo, o texto talvez fique assim:



A primeira string vai aparecer normalmente, pois o jogo vai começar a ler em 18D1 e só vai parar no endbyte no final da palavra, que no exemplo é 00.

A segunda string vai aparecer assim:

RA

Pois o ponteiro de ARMA ainda aponta pra 18D7, que agora é o final da palavra ARMADURA. É preciso achar esse ponteiro e mudar ele pra que aponte pra 18DA, e mudar o próximo também e assim sucessivamente até o final do bloco de texto.  Mas isso geralmente não é feito a mão, normalmente da pra usar tools que recalculam os ponteiros automaticamente de acordo com o novo texto.

Que bom que aprendeu breakpoints, pois a gente vai usar eles pra achar os ponteiros do simant, já que é um método mais certeiro do que pesquisando.

Vamos começar com o exemplo do "bota ovo". Primeira coisa a entender é que o processador não acessa o endereço na ROM diretamente, os bancos da ROM são mapeados a endereços no barramento do processador, no debugger chamado de "S-CPU BUS". Em ROMs LoROM, como é o caso do simant, cada banco vai de 8000 até FFFF, então dados que estão em 0xYY1100 por exemplo na ROM vão aparecer no barramento em 0xZZ9100 no S-CPU BUS. Não vou entrar em mais detalhes sobre isso pq é muita informação e vai alongar muito o tutorial mas se QUISER saber mais sobre o assunto pesquise  sobre o mapeamento da memória do SNES.

Sabemos que na ROM, a string "Bota ovo" está localizada em 0x8741. Abrindo o editor de memória do debugger do bsnes-plus, no modo S-CPU BUS, clicando no binóculos pra fazer uma pesquisa e digitando "Bota ovo"(entre aspas, pra especificar que é texto ascii ao invés de hexadecimal), podemos ver que ele está localizado em 0x18741, mas se clicar em localizar próximo, vai ver que o ele também está espelhado em 0x218741, 0x418741, 0x618741 e assim por diante. Isso se deve ao modo que a ROM é mapeada ao barramento. Pra saber de qual desse endereços o processador lê o texto, vamos fazer exatamente isso mas depois que o texto já apareceu na tela pelo menos uma vez. O texto que foi lido pelo processador vai ficar azul:



Nesse jogo o endereço é o primeiro e não um dos espelhados, mas em outros pode ser diferente!
Colocamos um breakpoint de leitura em 18741 no S-CPU BUS. Ele ativará ao abrir a caixa de ação da formiga.

00c4e4 lda [$79],y   [018741] A:6a01 X:0002 Y:0000 S:04eb D:0100 DB:00 nvMxdIZc V: 29 H: 75 F:32

Essa instrução está carregando o texto do endereço que está guardado em 0x179 (D=0100 + Y=0000 + 79 = 0179), 0x179 faz parte da memória RAM. Se olhar em 0x179 no S-CPU bus, vai ver nosso ponteiro, 41 87. Precisamos descobrir como esse ponteiro foi parar na memória RAM.

Vamos desativar o ponteiro anterior e criar um novo em 0x179, de ESCRITA, e em data vamos colocar 41.

Abrindo a caixa de ação da formiga de novo, o novo breakpoint vai disparar:

00c4db sty $79       [000179] A:6a79 X:0002 Y:8741 S:04eb D:0100 DB:00 nvMxdIzc V: 29 H: 46 F: 4

Esse comando guarda y, que é nosso ponteiro, em 0x179. Beleza, mas como Y virou 8741? Pra descobrir vamos ter que fazer um trace log, que é um arquivo com todas as instruções que o processador executou num intervalo de tempo, quanto maior o intervalo de tempo mais gigantesco o arquivo, então vamos tentar deixar esse intervalo o menor possível.

Com o breakpoint ainda ativo, a caixa de texto ação e o cursor em cima da formiga, clique em break, ative a opção trace s-cpu opcodes, clique em run, rapidamente abra a caixa de ação (o fps pode baixar bastante, pode ser preciso apertar o botão pra abrir a caixa varias vezes). O breakpoint vai disparar, desative trace s-cpu opcodes. Um arquivo será criado com o nome "nomedarom-trace.log". Se estiver num sistema unix use o less pra abrir, se for windows pode ser que alguns programas travem por ser muito longo o arquivo, mas enfim, pode pular direto pro final do arquivo:

[spoiler]009334 lda [$1c],y   [018732] A:0003 X:0b0a Y:0003 S:04ed D:0100 DB:00 nvMxdIzc V: 84 H:323 F:37
009336 iny                    A:0041 X:0b0a Y:0003 S:04ed D:0100 DB:00 nvMxdIzc V: 84 H:334 F:37
009337 xba                    A:0041 X:0b0a Y:0004 S:04ed D:0100 DB:00 nvMxdIzc V: 84 H:337 F:37
009338 lda [$1c],y   [018733] A:4100 X:0b0a Y:0004 S:04ed D:0100 DB:00 nvMxdIZc V: 85 H:  2 F:37
00933a xba                    A:4187 X:0b0a Y:0004 S:04ed D:0100 DB:00 NvMxdIzc V: 85 H: 14 F:37
00933b tay                    A:8741 X:0b0a Y:0004 S:04ed D:0100 DB:00 nvMxdIzc V: 85 H: 19 F:37
00933c jsr $c4d8     [00c4d8] A:8741 X:0b0a Y:8741 S:04ed D:0100 DB:00 NvMxdIzc V: 85 H: 23 F:37
00c4d8 jsr $c4bb     [00c4bb] A:8741 X:0b0a Y:8741 S:04eb D:0100 DB:00 NvMxdIzc V: 85 H: 34 F:37
00c4bb rep #$20               A:8741 X:0b0a Y:8741 S:04e9 D:0100 DB:00 NvMxdIzc V: 85 H: 46 F:37
00c4bd txa                    A:8741 X:0b0a Y:8741 S:04e9 D:0100 DB:00 NvmxdIzc V: 85 H: 51 F:37
00c4be sep #$20               A:0b0a X:0b0a Y:8741 S:04e9 D:0100 DB:00 nvmxdIzc V: 85 H: 55 F:37
00c4c0 asl a                  A:0b0a X:0b0a Y:8741 S:04e9 D:0100 DB:00 nvMxdIzc V: 85 H: 60 F:37
00c4c1 asl a                  A:0b14 X:0b0a Y:8741 S:04e9 D:0100 DB:00 nvMxdIzc V: 85 H: 64 F:37
00c4c2 asl a                  A:0b28 X:0b0a Y:8741 S:04e9 D:0100 DB:00 nvMxdIzc V: 85 H: 67 F:37
00c4c3 rep #$20               A:0b50 X:0b0a Y:8741 S:04e9 D:0100 DB:00 nvMxdIzc V: 85 H: 71 F:37
00c4c5 lsr a                  A:0b50 X:0b0a Y:8741 S:04e9 D:0100 DB:00 nvmxdIzc V: 85 H: 76 F:37
00c4c6 lsr a                  A:05a8 X:0b0a Y:8741 S:04e9 D:0100 DB:00 nvmxdIzc V: 85 H: 80 F:37
00c4c7 lsr a                  A:02d4 X:0b0a Y:8741 S:04e9 D:0100 DB:00 nvmxdIzc V: 85 H: 83 F:37
00c4c8 sep #$20               A:016a X:0b0a Y:8741 S:04e9 D:0100 DB:00 nvmxdIzc V: 85 H: 87 F:37
00c4ca ldx $2c       [00012c] A:016a X:0b0a Y:8741 S:04e9 D:0100 DB:00 nvMxdIzc V: 85 H: 92 F:37
00c4cc sta $0c00,x   [000c00] A:016a X:0000 Y:8741 S:04e9 D:0100 DB:00 nvMxdIZc V: 85 H:100 F:37
00c4cf inx                    A:016a X:0000 Y:8741 S:04e9 D:0100 DB:00 nvMxdIZc V: 85 H:110 F:37
00c4d0 xba                    A:016a X:0001 Y:8741 S:04e9 D:0100 DB:00 nvMxdIzc V: 85 H:113 F:37
00c4d1 ora $89       [000189] A:6a01 X:0001 Y:8741 S:04e9 D:0100 DB:00 nvMxdIzc V: 85 H:118 F:37
00c4d3 sta $0c00,x   [000c01] A:6a79 X:0001 Y:8741 S:04e9 D:0100 DB:00 nvMxdIzc V: 85 H:124 F:37
00c4d6 inx                    A:6a79 X:0001 Y:8741 S:04e9 D:0100 DB:00 nvMxdIzc V: 85 H:144 F:37
00c4d7 rts                    A:6a79 X:0002 Y:8741 S:04e9 D:0100 DB:00 nvMxdIzc V: 85 H:147 F:37
00c4db sty $79       [000179] A:6a79 X:0002 Y:8741 S:04eb D:0100 DB:00 nvMxdIzc V: 85 H:158 F:37[/spoiler]

O Y vira 8741 após o comando tay, que nada mais faz do que colocar o valor de A em Y. O A vira 8741 após os comandos lda, não precisa fazer os cálculos pq o debugger já nos diz de cara que o 8741 veio de 0x18732 (entre colchetes). 0x18732 no barramento do processador corresponde ao endereço 0x8732 na ROM, que é logo antes do texto em questão! Em 0x8732 temos 41 87, que é nosso ponteiro, logo antes temos 34 87, que é o ponteiro de "Cava ninho", mais adiante temos os ponteiros 63 87 até b7 87, que são os ponteiros do próximo bloco, e assim por diante.

Sim, nesse caso de os ponteiros serem misturados no texto complica um pouco as coisas, mas a coisa toda segue o seguinte formato:

número de ponteiros que seguem, ponteiros, strings, números de ponteiros que seguem, ponteiros, strings ...

Por exemplo, em 0x8755 temos o segundo "Bota ovo", seguido do endbyte FF, seguido do byte 06, que diz que o que segue são seis ponteiros, seguido dos seis ponteiros, seguido das seis strings que correspondem aos seis ponteiros. Da pra editar tudo a mão respeitando esse padrão, mas não recomendo muito não.

Pra ser sincero não sei como extrair esse texto com o cartographer, com o abcde deve ter algum jeito simples mas nunca usei, vale olhar a documentação dele com atenção e procurar tutoriais. Recomendo também use esse tutorial pra encontrar o restante dos ponteiros do jogo.

Algum hacker que tem experiência com o abcde pode te ajudar melhor daqui pra frente, ou algum certo hacker bom das tool pode fazer uma pra extração e reinserção específica pra esse jogo.

Na tabela da pra mapear todos os caracteres acentuados pros mesmos não acentuados, traduzir o script extraído e inserir normalmente na rom sem os acentos, aí depois da fonte acentuada da pra só mudar a tabela e reinserir sem ter que mexer no texto de novo.

Citação de: Lansk online Agosto 22, 2022, 19:49:23 PM
Oi, gente. Infelizmente eu não sei fazer nada disso. Eu acho que eu deveria ter começado pelo NES ao invés do SNES, já que a maioria dos gráficos é descomprimida.
Desculpa ter tomado muito o tempo de vocês, mas eu não sei se eu vou conseguir aprender essas partes mais complicadas.

Cara, pra ser sincero realmente essa parte é meio complicada. Na minha opinião, o melhor caminho é começar aprendendo a lógica dos ponteiros, encontrar eles e usar para extrair o texto. Isso é algo que vai te dar mais habilidade e confiança pra mais depois trabalhar com os gráficos. E também é mais importante do que os gráficos, pq vai te permitir mudar o tamanho das frases, por exemplo "botar ovo" ao invés de "bota ovo".

Importante ressaltar pros iniciantes que dd é uma ferramenta extremamente perigosa e o mau uso dela pode obliterar seus sistemas de arquivos. Não é à toa o apelido de disk destroyer.

Olha a VRAM em hexadecimal e coloca um breakpoint pra quando eles forem escritos na VRAM. Quando esse breakpoint ativar, pode olhar na WRAM que eles vão ta lá, aí pega o endereço e faz outro breakpoint como o Anime_World falou. Eles ficam na WRAM por um intervalo de tempo bem curto.

Alguém sabe se esse jogo tem alguma dificuldade acima do normal em ser traduzido? Algo muito fora do comum? Tipo Terranigma que tem os ponteiros embutidos como parâmetros dos eventos.

Tem algo assim que dificulte muito a tradução, ou ninguém nesses anos todos traduziu ainda só porque não mesmo?

Citação de: João13 online Agosto 10, 2022, 16:10:44 PM

Citação de: badnest online Agosto 10, 2022, 12:42:20 PM

Citação de: huskie online Agosto 08, 2022, 16:12:25 PM
Faltou indicar a região do jogo que está sendo traduzido (J), (E), (U). Pessoalmente, estou baixando a versão (E) -européia- pois é a que roda convertida no PS4.

Problema é que Rule of Rose europeu não tem opção de 60hz, aí complica bastante pra quem vai jogar no PS2 mesmo no tubão. Tenho um tubo trinorma mas não troco os 60hz do NTSC pelas cento e poucas linhas de resolução a mais do PAL.

Compartilho da mesma opinião. Na minha a imagem meio que ficava com o brilho piscando levemente, resolvi mexendo no chip Matrix, no OPL deve ter algo pra resolver também, de resto só fica a questão do frame rate que tem um cap de 25 (30 no NTSC) e 50 (60 no NTSC).

Esse efeito do brilho piscando é pq como são só 50 frames nosso olho consegue ver o tubo apagando entre cada frame. A 60hz o próximo frame é desenhado antes de dar tempo do tubo apagar. Em monitores de PC mesmo, que apagam muito rápido, tem que deixar a tela a pelo menos 85hz pra não ver piscar.

Essa solução do Matrix/OPL/GSM converte o 512i do PAL pra 448i do NTSC, ou seja, ou a imagem acaba cortada ou esmagada na vertical perdendo muita qualidade. E o framerate é aumentado pra 60 no seco, sem aumentar o número de frames em si, o que faz o movimento da imagem ficar todo "travado".

Citação de: huskie online Agosto 08, 2022, 16:12:25 PM
Faltou indicar a região do jogo que está sendo traduzido (J), (E), (U). Pessoalmente, estou baixando a versão (E) -européia- pois é a que roda convertida no PS4.

Problema é que Rule of Rose europeu não tem opção de 60hz, aí complica bastante pra quem vai jogar no PS2 mesmo no tubão. Tenho um tubo trinorma mas não troco os 60hz do NTSC pelas cento e poucas linhas de resolução a mais do PAL.

Daora... vou jogar no console de certeza quando lançar

Citação de: Kunio Urameshi online Agosto 01, 2022, 21:20:38 PM
Meu Deus, essa série Kunio-kun é das favoritas, obrigado e continue seu projeto incrível
Uma pergunta, você é gringo :) ? ----> https://www.romhacking.net/community/7347/

Valeu!! É das minhas favoritas também, conheci ela quando tinha 11 anos... na época brigava o tempo todo na escola e acabei me identificando muito.

No momento estou trabalhando em três traduções ao mesmo tempo, então pode demorar um tempinho ainda... Mas da pra esperar um lançamento nos próximos meses.

Sou br mesmo, de SC, mas esse perfil no romhacking.net é meu sim.

Citação de: RodrigoF. online Agosto 02, 2022, 03:41:42 AM
Interessante. Não conhecia a franquia. Parabéns aos envolvidos. 

No momento sou o único envolvido (além da equipe AGTP que fez a tradução pro inglês, claro), mas se algum hacker foda quiser entrar no projeto pra ajudar com gráficos comprimidos e tilemaps favor mandar MP. Iria agilizar bastante o lançamento.

ATUALIZAÇÃO

Já dei cabo dos gráficos comprimidos, agora de hacking falta só os tilemaps eu acho

Fala, Lansk. Fiz uns testes e descobri que de fato é uma outra fonte. Risquei a fonte toda e os caracteres cinza de fato nunca mudam, nenhum deles. A outra hipótese seria o jogo carregar os caracteres de katakana ao invés de hiragana nesses casos por algum motivo, mas sendo que nenhum dos caracteres muda de jeito nenhum acho que podemos descartar ela.

Aqui estou visualizando a segunda fonte no debugger do bsnes-plus:



O motivo mais provável pra ti não conseguir ver ela no tile molester é que ela esteja comprimida. Mas não deixe isso te desanimar. O mais fácil acho que seria colocar essa fonte, descomprimida, no final da rom, com os acentos, e adicionar um "desvio" em ASM pro jogo ler a fonte descomprimida injetada. Algum hacker mais experiente pode te ajudar com isso.

Isso, claro, se a fonte de fato estiver comprimida; essa fonte está em 2bpp ao invés de 1bpp como a outra, então pode ser também que fuçando mais a rom no tile molester em algum modo 2bpp ache ela.

Pra traduzir os gráficos comprimidos também seria um procedimento parecido com o que falei:
Injetar os gráficos descomprimidos e já traduzidos no final da rom e fazer o jogo ler eles ao invés dos comprimidos em inglês. Ou pelo menos até onde eu sei esse é o jeito mais usado.

Legal, já joguei um pouco antes, é bem aberto e divertido. Na vida real n tenho medo de aranha, mas nesse jogo bate um desespero jkkkkk

Citação de: Lansk online Junho 24, 2022, 16:18:44 PM
1: Eu percebi que em algumas partes os textos não mudaram para a forma acentuada depois da edição. Elas permanecem com a forma original, como se eu não tivesse alterado os tiles das fontes. Como eu sou iniciante e não entendi o porquê disso ocorrer, essas partes ficaram sem acentuação.

Faz um tempo que eu não jogo mas acho que o jogo tem duas fontes.

Se precisar de ajuda ou quiser tirar alguma dúvida sobre os ponteiros/extração do texto pode mandar mp ou postar aqui mesmo, boa sorte no projeto!