Seu carrinho está vazio no momento!
Fazer jogos para a Web usando Godot 4.x ainda não é tão fácil. Infelizmente, são necessárias revisões sérias para melhorar a experiência dos desenvolvedores no processo.
A Godot 4.3 promete ser um dos melhores lançamentos recentes para exportações para a Web. Um dos maiores problemas relacionados a isso foi devidamente corrigido: exportações single-thread.
A implementação da API SharedArrayBuffers deveria revolucionar a Web, e de fato o fez. Essa API permite compartilhar memória entre Web Workers (que são os “threads” nativos da Web).
Infelizmente, vivemos na mesma linha do tempo que inclui as explorações Spectre e Meltdown.
O resultado disso é que os navegadores reduziram bastante onde e como você pode usar essa API. Ou seja, os navegadores hoje em dia exigem que os sites sejam isolados de origem cruzada. Quando isolado, ele libera o potencial do SharedArrayBuffers, mas a que custo?
Ao custo de não poder fazer chamadas remotas para outros sites. Adeus monetização do jogo. Adeus interagindo com uma API externa.
Durante o desenvolvimento do Godot 4 apostou-se muito no uso de threads com SharedArrayBuffers.
Quando todos os navegadores lançaram versões estáveis com SharedArrayBuffer, os desenvolvedores da Godot decidiram simplificar tudo em torno do multi-threading.
Mas eles acabaram subestimando a dificuldade de configurar as chamadas remotas.
No final do desenvolvimento do Godot 4.2, a Fundação buscou maneiras de suportar a capacidade de compilar jogos Godot sem usar threads, a fim de exportá-los sem os incômodos cabeçalhos COOP/COEP.
Isso não foi fácil porque o 4.0 foi feito pensando nos threads. Felizmente, com a ajuda do guru de threads Pedro J. Estébanez (@RandomShaper), conseguiram domar a fera e reimplementar as compilações de thread único.
Isso trouxe alguns benefícios inesperados como o fim dos problemas de exportação Web com dispositivos Apple (macOS e iOS).
No entanto, a reintegração do single-thread também introduziu um bug:
A compilação single-thread criou distorções no áudio dos jogos, tornando-os impossíveis de jogar em máquinas de baixo custo, como laptops ou telefones, ou em máquinas de última geração com altas taxas de quadros.
A reprodução de fluxo de áudio de thread único da Web com Godot 4.2 é muito ruim. É um pouco melhor no Godot 3.x, mas o problema também existe.
O resgate para esta situação virá com a reimplementação do Sample Audio Playbak.
O uso samples para jogos não é uma ideia nova. Na verdade, durante muito tempo, foi a forma de reproduzir som e música em consolas de jogos.
Como eles não tinham poder de processamento para fazer a mixagem na CPU, os desenvolvedores podiam enviar clipes de áudio (daí o termo “sample”) para um chip especial e dizer como e quando reproduzi-los.
Como o chip de áudio estava operando sozinho, o som nunca ficaria atrasado nem falharia se o jogo estivesse travando (lagging).
Desde o início do projeto de reimplementação, a equipe da Godot se preocupou em buscar uma forma mais intuitiva ao invés de simplesmente portar o recurso.
Então , o suporte a samples foi inserido diretamente através da API dos Streams de áudio permitindo ao desenvolvedor selecionar na propriedade “Playback Type” a opção Sample.

Fonte: https://godotengine.org/article/progress-report-web-export-in-4-3/
*Imagem do jogo Open Source Catburglar de @JohnGabrielUK
Deixe um comentário