Troca de efeitos sonoros

[diegoleao]

Eai blz! Estou tentando trocar os efeitos sonoros de exemplo que você deixou (os dois wav), e já tentei de tudo mas meu arquivo sempre é reproduzido como se tivesse com pitch errado, meio distorcido. E também, de vez em quando, escuto um pedaço dele tocando sem ter feito nenhuma chamada para isto (afinal estou usando seu código, e só mudei o arquivo .wav e recompilei, portanto não é nada no código).

Já tentei mudar a taxa de atualização do wav, chequei se estava parecido com o seu em termos de bitrate, mudei no software gold wave pra ficar menor, enfim... Já tentei outros arquivos .wav, sempre com os mesmos problemas. [edit: Agora inclusive, fui testar e até travou o game ao tocar os áudios então realmente tem algo errado]

Você sabe o processo correto para gerar um wav que é convertido corretamente pelo smconv do pvsneslib? Envio em anexo os wavs que estou querendo tocar. sounds.zip

[diegoleao]

Eu consegui algum sucesso a pouco mudando gradativamente o playback rate (Hz) do dano.wav até chegar em 16000Hz, por exemplo, quando o som ficou razoavelmente parecido dentro do game (ainda não igual). Se reduzir mais do que isto, volta a ficar distorcido, o que me é bem estranho... Alguma idéia do motivo deste "número mágico" dar certo?

O que me parece é que, como o áudio ajustado soa "high pitch" quando tocado em um player comum, o que fiz parece ter apenas aumentar o pitch, e como o game distorce para baixo, e o resultado final é um áudio que soa quase normal.

Ah, o problema do travamento sumiu após aumentar o valor do spcAllocateSoundRegion(?); de 39 para 100.

Então ficam estas duas dúvidas:

• Cada arquivo vai precisar de ajuste no playback rate para não tocar distorcido? Ou foi coincidência, e na verdade não resolvi o problema?
• Qual é a conta que devo fazer para saber que valor colocar em spcAllocateSoundRegion, para que caibam todos os sons?

Entendo se não souber bem, afinal não tem muito a ver com o código, mas se souber ajudará bastante.

PS: Áudios que funcionaram melhor vão abaixo. audios_funcionaram.zip

[odelot]

Fala Diego, blz? putz, eu não sei como te ajudar. O pvsneslib tem pouca documentação dessa parte de audio e o pouco que consegui foi na tentativa e erro. Não sei se vc vai continuar o projeto, mas fico feliz que ele pode estar te ajudando. Não sei se vc reparou, mas a colisão está feita de forma bem simples... e eu não espelhei quando a personagem flipa horizontalmente. Além disso, fui pelo caminho mais facil e usei um unico sprite de 64x64 e tive que fazer um resize no sprite do megadrive e não da pra fazer um sprite mais horizontal (tipo uma voadora).

Quando eu ainda estava mexendo nele, eu estava pensando em ou desenvolver o esquema de metasprite e criar uma ferramenta para fatiar e reusar sprites de 8x8 ou 16x16 ou em desenvolver mais da logica do jogo, como os sprites do rosto do personagem do lado da barra de vida e a morte do inimigo quando a vida chegar no 0.

[diegoleao]

Ah notei recentemente rs que se eu der um soco virado pra trás pega tb :) Mas tranquilo! Vou começar a olhar colisão hoje.

No meu caso estou fazendo um platformer, então estou lendo alguns artigos muito bons para ajudar: https://www.gamedev.net/tutorials/_/technical/game-programming/the-guide-to-implementing-2d-platformers-r2936/ https://jobtalle.com/2d_platformer_physics.html https://gamedevelopment.tutsplus.com/tutorials/basic-2d-platformer-physics-part-1--cms-25799

Intuitivamente eu já tinha chegado na solução de "AABB estáticos" quando vi o artigo (o chato de estudar retro é ver que suas idéias legais na verdade são só recriações da roda rs), mas vou tentar não cair na tentação de fazer tudo da minha cabeça.

Quanto a questão do tamanho do sprite, eu comecei a fazer algo dinâmico sem saber que não precisava rs Parei no meio, porque notei que a matemática é um pouco mais complexa quando começa-se a ter mais de um tamanho ao lado do outro. Acho que vou solucionar isto em C# e depois só portar. Vou criar uma grid dinamicamente na Unity e fazer meus testes lá. Mas por enquanto estou usando tiles de 32px e deve caber tudo que preciso.

PS: Eu planejo recriar seu demo como estudo, quando estiver pronto eu te mando para você ver as diferenças :) Valeu!

Ah, depois de ver seu demo rom com uma blaze do SOR4, me convenci que usar sprites/renders de alta qualidade redimensionados pode dar um feeling legal de "Donkey Kong Country". Até vou tentar ripar uns frames deste vídeo: https://www.youtube.com/watch?v=TG6lVNJSe04&feature=emb_title e só pra ver os personagens refeitos se movendo com fluidez sem a restrição de quantidade de frames.

[odelot]

Opa Diego, blz?

Po, legal vc estar fazendo um jogo plataforma. Eventualmente vc pode abrir um tópico no nesdev para postar novidades do jogo, eu gostaria de acompanhar ^.^

Realmente, tem que ficar esperto para não reinventar a roda. Contudo, algumas coisas do que vc encontra nos artigos de jogos 2d genéricos não se aplica ao SNES devido a sua limitação de processamento e memória. Embora os jogos usem AABB, não imagino que tenha um jogo que tenha uma árvore de AABB para tratar colisões.

Talvez uma boa referencia para um jogo de plataforma seja a física implementada no Sonic. Ela já foi bem documentada e é algo possível de ser computado pelo SNES. ACHO q é esse artigo http://info.sonicretro.org/Sonic_Physics_Guide que destrincha a física.

A colisão do meu demo é AABB mas que eu meio que defini na mão, ela abrange os personagens. Dai eu posso configurar se a AABB é um hitbox, que pode dar dano. No caso do soco, o AABB só abrange os braços da Blaze e não o corpo inteiro. Só que não fiz o flip da AABB quando o sprite flipa, por isso que vc consegue dar dano de costas kkkkk. como a maioria das AABB são um retângulo em pé no meio do sprite, nem precisa flipar que ele vai estar praticamente igual. Mas o hitbox do soco já não está centralizado e precisa ser flipado.

A Blaze do SOR4 eu peguei de um gif que os devs soltaram durante o desenvolvimento, que tinha o fundo branco. Ele só é possível porque não tem mais nenhum inimigo na tela, pq é muitooooo sprite. Toda a banda do DMA está sendo usada para fazer streaming dos frames da Blaze, não sobra para mais nada.

Se vc reparar, cada sprite da Blaze do SoR2 dura 5, 8 frames para mudar (propriedade proximoFrame). Mesmo assim, tem uma fila spr_queue para controlar atualização de sprites e um contador de dados que já enviei pelo DMA. Se eu já passei a quantidade de dado máxima, o sprite vai ficar na fila e só vai mudar no próximo frame. Então as vezes uma animação da Blaze que duraria 7 frames vai durar 8 pq não tinha como passar no frame anterior por falta de banda (usada por exemplo por um inimigo). O caso da Blaze do SOR4 ela mudava de sprite a cada 2 frames, não tinha muito espaço para ficar esperando na fila, por isso, só tinha ela mesmo no demo.

[diegoleao]

Ah sim, posto lá sim :) Mal posso ver a hora de ter algo mais elaborado rs Fiz muito progresso já.

Saquei sobre os algoritmos, vou ler este link aí agora que estou saindo do trabalho, hoje devo ficar até mais tarde mexendo na mini-engine aqui.

Sobre os sprites grandes tipo a Blaze do SOR4, pensei em talvez separar um espaço enorme da memória de sprites pra pre-load do personagem principal, e deixando só 2 slots pra fazer DMA de personagens menores, e um pouco pra sprites interativos (não poderia ser muito animados) pra entrarem por DMA (talvez após corredores vazios, que serviriam pra ganhar tempo pra carregar na memória "variável" de objetos da próxima parte da fase). O personagem principal, como fica o tempo todo na tela, teria o privilégio de ficar sempre alocado. Seria bastante sacrifício, sim, e o jogo teria que ser voltado para isto, claro. Não acha que funcionaria? Bom, de toda forma é só uma idéia, estou agora apenas me preocupando com coisas mais pé no chão :_)

Não tinha visto que vc tinha incluído esse contador de dados pra otimizar as transferências e até tratar os casos onde ela não é possível (não completamente), bem legal, quando chegar nesta parte vou prestar bem atenção em como foi feito.

PS: Sobre o rip do personagem do vídeo, pensei em fazer meio zoado mesmo, com fundo sem tranparência, só pra ver rodando, só um recorte do personagem prova de conceito. O tamanho seria próximo ao tamanho original do personagem no snes, mas com mais frames.

[odelot]

no caso da blaze do SoR4, a não ser que vc faça meta sprites e reaproveite bastante os sprites entre frames (não sei se a galera que fez o SoR4 se preocupou em reusar partes dos sprites entre frames), vai ficar bem difícil vc subir todos os frames do personagem na memoria do SNES. Na memória do SNES cabem 7 sprites de 64x64. Só a animação de idle da Blaze tem uns 12 frames. Não sei se daria para por toda as animações da Blaze em memória.