Minecraft: Java Edition troca backend de janela e entrada para SDL3

 (minecraft.net)
1 pontos por GN⁺ 23 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • O Snapshot 4 do Minecraft 26.3 substitui o backend de gerenciamento de janelas, entrada e integração de plataforma do GLFW pelo SDL3 e adota SDL scancode e keycode para entrada de teclado
  • Os atalhos de teclado passam a usar a posição física das teclas em vez de códigos por layout; no Linux, o Wayland é priorizado quando possível, e no macOS há suporte à janela nativa de candidatos de entrada
  • Foi adicionado um componente de dados para combustível personalizado de fornalha e de preparo de poções, permitindo configurar tempo de queima, número de usos e velocidade de cozimento/preparo com number provider
  • No data pack 111.0 e no resource pack 92.0, houve mudanças amplas em eventos de clique de placas, referências de loot table, gatilhos de avanços, propriedades de ambiente de spawn de mobs, configurações de geração de terreno e shaders
  • Há um erro conhecido de tela cheia exclusiva no Windows com múltiplos monitores e no Wayland; como versões de teste podem corromper mundos, é preciso fazer backup ou executar em uma pasta separada

Sistema de janela e entrada baseado em SDL3

  • A biblioteca de gerenciamento de janelas, entrada e integração de plataforma foi migrada do GLFW para o SDL3
    • A entrada de teclado usa SDL scancode para a posição física das teclas
    • Atalhos de edição de texto que variam conforme o layout do teclado usam SDL keycode
  • Os atalhos configuráveis agora funcionam com base em teclas físicas, e não em códigos dependentes do layout
  • A configuração de mouse Raw Input foi removida, e durante a jogabilidade o modo de mouse relativo é sempre usado
  • Tela cheia sem bordas passou a ser o modo padrão, e é possível alternar entre sem bordas e modo exclusivo sem reiniciar
    • No macOS, a tela cheia exclusiva não é mais suportada
    • O tamanho mínimo da janela é de 320×240 pixels
  • No Linux, o Wayland é usado nativamente com prioridade quando disponível
  • No macOS, ao manter uma tecla pressionada durante a entrada de texto, é exibido o pop-up nativo de acentos e candidatos

Problemas conhecidos de tela cheia

  • A tela cheia exclusiva no Windows pode causar travamentos em certas situações, especialmente em ambientes com múltiplos monitores
  • No Wayland, o jogo trava ao entrar em tela cheia exclusiva

Mudanças de jogabilidade e interface

  • Jogadores no modo espectador podem interagir com portais para se teleportar
  • Tatus não tentam se enrolar quando estão submersos em líquido
  • Agora é possível aplicar uma escala de GUI separada ao overlay de depuração
    • A configuração fica em Debug Options com F3 + F6
    • O padrão Auto mantém resolução mais alta que a GUI normal, e Unchanged usa a mesma escala da GUI normal
    • Também foram adicionados player_speed, que mostra a velocidade de deslocamento em blocos por tick, e a exibição da taxa de atualização da tela
  • A ordem dos minérios no inventário criativo foi reorganizada para materiais sem tier, materiais brutos por tier e materiais refinados por tier
    • Em blocos de construção, a ordem é minérios sem tier, minérios refinados por tier e itens da linha Copper, com os blocos de Copper, que são muitos, posicionados mais ao fim
    • A aba Natural Blocks foi organizada em Overworld → Nether → End

Combustíveis personalizados e componentes de item

  • minecraft:cooking_fuel define combustíveis para Furnace, Smoker e Blast Furnace
    • burn_time define os ticks de queima, e speed_multiplier define a velocidade de cozimento/fundição, ambos com minecraft:number_provider
  • minecraft:brewing_fuel define o número de usos e a velocidade de preparo do combustível do Brewing Stand
    • A antiga tag de item #brewing_fuel foi removida e não pode mais ser usada para registrar novo combustível de preparo
  • Receitas de Smoker e Blast Furnace passam a usar o mesmo tempo de cozimento da Furnace, e o aumento de velocidade é controlado por minecraft:cooking/speed_default no componente de combustível
  • Os campos de tempo de cozimento e de combustível de Furnace, Smoker e Blast Furnace mudaram de short para integer, e speed_multiplier foi adicionado
  • BrewTime e Fuel do Brewing Stand também mudaram para integer, com adição de total_brew_time, total_fuel e speed_multiplier
  • Os componentes de dados adicionados são os seguintes
    • minecraft:sign_text_front, minecraft:sign_text_back: armazenam o texto da frente e do verso de placas e o exibem na tooltip do item
    • minecraft:waxed: marcador sem campo que indica que o conteúdo recebeu cera
    • minecraft:cushion/color: aplica uma das 16 cores de corante a um Cushion colocado
    • minecraft:villager_food: define itens que aldeões podem comer e seus valores nutricionais
    • minecraft:mob_visibility: define de 0.0 a 10.0 o multiplicador do efeito de equipamentos sobre a distância de detecção de mobs; mesmo acumulado, o valor máximo de visão não passa de 10.0

Compatibilidade de placas e data packs

  • A versão do data pack subiu para 111.0
  • Comandos e eventos de clique em textos personalizados de placas não são mais executados por padrão ao clicar no bloco, e componentes de texto em placas novas também não são mais interpretados automaticamente
    • O novo campo allow_op_features tem valor padrão false; para restaurar o comportamento antigo, é preciso defini-lo explicitamente como true
    • Em placas salvas em versões anteriores e em minecraft:block_entity_data que contenha dados de placa, allow_op_features=true será aplicado
  • Após posicionar uma placa, a tela de edição só é mostrada quando um clique normal poderia abrir a edição, como quando a placa não está encerada e o texto da frente pode ser editado
  • Placas agora trocam os componentes minecraft:sign_text_front, minecraft:sign_text_back e minecraft:waxed
  • Os blocos seguros onde /spreadplayers pode posicionar jogadores são controlados pela block tag #entities_can_teleport_to

Referências de registro e mudanças em loot e avanços

  • Tipos de loot table com registro dedicado agora suportam referências a elementos de registro e tags
    • Campos de elemento único podem receber um ID com namespace ou um valor inline
    • Campos de lista podem receber valores inline, um ou mais IDs com namespace, listas de valores inline ou um ID de tag com #
    • Os alvos são advancement, item modifier, loot table, number provider, predicate, recipe e slot source
  • O tipo reference existente em predicate, item modifier e slot source foi removido por ter se tornado desnecessário
  • Vários campos de gatilhos de avanço agora podem receber não só predicate inline, mas também IDs de predicate com namespace
    • O comportamento implícito anterior de minecraft:all_of em listas de condições foi removido, então type agora deve ser especificado obrigatoriamente
    • Vários campos como block, recipe_id e loot_table foram alterados para o plural e passam a aceitar um único ID, uma lista ou uma tag
  • Em Loot Pool Entry, conditions foi renomeado para condition, e functions para modifier
  • Em Loot Function, conditions virou condition, e function, que indicava o tipo da função, mudou para type
    • Listas de condições inline não são mais aceitas; para o mesmo comportamento, é preciso declarar minecraft:all_of
  • Em Predicate, o campo de tipo condition foi renomeado para type, e minecraft:reference e minecraft:block_state_property foram removidos
    • O novo minecraft:match_block verifica juntos ID ou tag de bloco, estado, NBT, componentes e predicate de componentes
  • Number providers inline agora exigem sempre type explícito e não usam mais minecraft:uniform como valor padrão
  • Foram adicionados vários number providers Vanilla para fornecer tempo de queima por combustível de cozimento, velocidade padrão de cozimento/preparo e número de usos no preparo

Spawn de mobs e geração de mundo

  • A nova propriedade de ambiente minecraft:gameplay/natural_mob_spawns define spawn de mobs com pesos por categoria e spawn cost por entidade
    • Durante a colocação na geração do mundo, apenas Dimension e Biome aplicam essa propriedade
    • O modificador overlay prioriza a configuração de categoria da camada superior e o spawn cost da mesma entidade
  • minecraft:gameplay/creature_world_gen_spawn_probability define a probabilidade de repetição de spawn de mobs da categoria creature durante a geração do mundo com valor maior ou igual a 0 e menor que 1, com padrão 0.1
  • spawners, spawn_costs e creature_spawn_probability de Biome foram removidos e movidos para a nova propriedade de ambiente
  • A propriedade de ambiente de partículas ao redor agora interpola a probabilidade entre keyframes da timeline e suporta o modificador append, que concatena itens à lista de partículas de uma camada inferior
  • Em Noise Settings, as configurações de aquifer e de ore vein foram reorganizadas em um objeto opcional aquifers e uma lista ore_veins
    • Sem configuração, o respectivo aquifer ou ore vein não é gerado
    • Campos relacionados de density function foram movidos de noise_router para a nova estrutura
  • Foram adicionados a Density Function: sub, div, negate, lerp, floor, round, ceil, truncate, beardifier
    • Vários nomes de argumentos existentes foram alterados para value, left, right, input, noise
    • invert foi renomeado para reciprocal
    • final_density não recebe mais implicitamente o beardifier

Gráficos e principais correções de bugs

  • A versão do resource pack subiu para 92.0
  • Foram adicionados shaders com suporte a transparência independente de ordem (order-independent transparency) e a definição OIT_ALWAYS_WRITE_DEPTH
  • core/integrate_depth.fsh integra ao buffer de profundidade principal o buffer de profundidade do HUD 3D e de gizmos sempre exibidos por cima
  • Os principais problemas corrigidos incluem:
    • Problemas de atalhos e entrada em teclados não QWERTY e com entrada em macOS/CJK
    • Travamentos na renderização de mapas no Improved Transparency, além de problemas com vidro, objetos semitransparentes, partículas e exibição da borda do mundo
    • Travamentos causados por projéteis fora da altura do mundo e pela colocação de colmeias na altura mínima
    • Problemas ao salvar/carregar heightmaps da geração do mundo e dessincronização da posição de mobs após tick sprint
    • Problemas com posicionamento, cor, nome personalizado, tempo de combustível e colisão de Cushion
    • Problemas com dano e voo do Ender Dragon, uso de portais por espectadores e detecção de blocos seguros em /spreadplayers

Instalação e cuidados para teste

  • O Snapshot é para Minecraft: Java Edition e pode ser instalado ativando Snapshot na aba Installations do Minecraft Launcher
  • Como versões de teste podem corromper mundos, é preciso fazer backup ou executá-las em uma pasta diferente da dos mundos principais
  • Também é fornecido um Minecraft server jar multiplataforma
  • Bugs podem ser reportados no Minecraft issue tracker, e opiniões podem ser enviadas pelo site de Feedback

Leituras relacionadas

1 comentários

 
GN⁺ 23 시간 전
Opiniões no Hacker News

  • A implementação LWJGL desse binding foi escrita por um integrante da equipe do modpack GTNH, completando novamente o ciclo vanilla→modded→vanilla https://github.com/LWJGL/lwjgl3/pull/1033

    • Exagerando um pouco, dá para dizer que o GTNH contribuiu mais para o Minecraft do que a Microsoft. Não digo isso só porque contribuí um pouco diretamente; o cuidado e a quantidade de trabalho envolvidos são impressionantes
    • Fico curioso para saber quantos dos desenvolvedores atuais do Minecraft já foram modders no passado e quantos ainda atuam como modders

  • Recentemente migrei o jogo Tribal Trouble(https://github.com/bondolo/tribaltrouble) de GLFW para SDL3, e no geral foi uma refatoração tranquila. Houve alguns problemas com tela cheia exclusiva e tela cheia de desktop, mas no fim foram resolvidos
    Também escrevi uma demo para testar e documentar o tratamento complicado de modos de tela. O jogo é em Java, como Minecraft, mas usei C na demo para deixá-la o mais simples possível

    • Tribal Trouble, fazia muito tempo que eu não ouvia esse nome. Lembro que os desenvolvedores disseram ter escolhido Java porque queriam usar uma linguagem estranha ou incomum para desenvolvimento de jogos
    • Fico curioso se havia algum problema com GLFW, ou por qual motivo foi escolhida a migração para SDL3

  • A tela cheia exclusiva no Windows tem um problema conhecido que pode travar o jogo, especialmente com múltiplos monitores, e no Wayland ele trava só de entrar nesse modo. Ambos normalmente parecem bugs bloqueadores que justificariam adiar um snapshot, então espero que sejam corrigidos antes do lançamento estável

    • Um snapshot é a distribuição, tal como está, do estado atual da branch principal, incluindo bugs bloqueadores
      Eu vejo as expectativas de estabilidade mais ou menos nesta ordem: versão de suporte de longo prazo, versão estável, release candidate, beta, alfa, snapshot, commit recém-mergeado, PR não mergeado, PR em rascunho. Um bug grande deve adiar um release candidate ou beta, e um bug crítico deve impedir o próprio merge, mas não há motivo para adiar um snapshot por causa de um bug que passou no CI e foi mergeado
      Um snapshot é mais parecido com cortar e distribuir periodicamente o estado atual para que usuários possam executar e dar feedback sem precisar compilar a main por conta própria
    • Se fosse uma versão estável, poderia ser adiada, mas não há motivo para adiar um snapshot. É preciso distribuí-lo no estado atual para descobrir por telemetria com que frequência os problemas conhecidos acontecem, e também encontrar problemas ainda desconhecidos antes da versão estável
      Nunca houve promessa de que snapshots não teriam bugs; pelo contrário, essa é a premissa
    • O Minecraft deve usar tela cheia sem bordas há muito tempo, a menos que se configure algo separadamente. Ao longo dos últimos 10 anos ou mais, várias plataformas, serviços e apps vêm abandonando a tela cheia exclusiva
    • Hoje em dia, renderização em uma janela em tela cheia é mais comum do que tela cheia exclusiva. O gerenciador de janelas geralmente aplica à janela em tela cheia que está em primeiro plano as mesmas otimizações que antes eram aplicadas apenas ao modo exclusivo
    • É um snapshot, então esse tipo de problema pode acontecer, e é bem provável que seja corrigido no próximo snapshot

  • Fico imaginando como um pai técnico que não conhece nada de Minecraft deveria montar um servidor familiar em 2026. As crianças atualmente jogam no iPad e, às vezes, em um MacBook antigo e em um PC com Windows

    • Existem duas edições de Minecraft: Java e Bedrock. As versões para mobile, console e Windows Store são baseadas em Bedrock; a versão baixada diretamente do site é a Java
      É possível operar um servidor Java padrão e usar o Geyser para converter o protocolo Bedrock em tempo real. Clientes Bedrock mais restritos podem exigir métodos alternativos, mas dá para administrar tudo tendo como base um servidor Java, que oferece mais opções
    • As orientações online de tuning de JVM para Minecraft muitas vezes são antigas ou erradas, então é melhor ignorá-las
      Basta usar uma JVM recente, aumentar a memória máxima até um limite aceitável e usar ZGC. Há orientações que ajustam várias flags sem justificativa, ou combinam configurações conflitantes, como tamanho da região eden e meta de tempo de pausa
      O ZGC tem latência muito baixa e sofre menos degradação de desempenho quanto maior o heap, mas é melhor mantê-lo abaixo de 32 GB para preservar a compressão dos headers de objetos. JVMs recentes também melhoram o uso de memória e o desempenho geral
    • Basta seguir o guia de configuração de servidor vanilla da edição Java. A edição Java só roda em Windows, macOS e Linux, mas considero que ela tem menos bugs e é melhor do que a Bedrock
      Se precisar de mais desempenho, instale fabric e lithium. É melhor evitar mods como Paper, Spigot e Purpur, pois eles podem quebrar farms automatizadas
    • O Minecraft em celulares e tablets é mais fechado e limitado do que a edição Java, então há menos opções
      Usei itzg/docker-minecraft-server de forma estável por vários anos, e gostei do fato de a imagem cuidar de tudo sem precisar instalar dependências uma a uma. Também existem imagens de servidor Bedrock, mas não consegui fazê-las funcionar corretamente
      Para operar da forma mais simples, todos precisam usar a edição Java em Windows, Mac ou Linux; caso contrário, há a opção de pagar pelo Realms, um servidor hospedado
    • Considerando a preferência das crianças por jogar no iPad, vale olhar também o Realms. Pelo que sei, ele oferece um servidor para 10 pessoas por cerca de US$ 7, mas as assinaturas Java e Bedrock são separadas e os planos também são fragmentados em vários níveis
      Dependendo do objetivo do servidor familiar, pode não ser adequado, mas é a forma mais fácil para as crianças jogarem juntas de modo rápido e simples. Já vi crianças que insistiram por muito tempo em ficar no Bedrock, depois migraram para Java e se arrependeram de não ter mudado antes

  • Icculus publicou um ótimo vídeo sobre portar um jogo do SDL2 para o SDL3, e o vídeo do port de Doom está aqui: https://www.youtube.com/watch?v=ixdeGhsoxy8

    • Eu não sabia que Chocolate Doom estava sendo portado para SDL3, nem que o próprio Icculus estava trabalhando nisso. Entre os ports de Doom que conheço, Woof! já fez a transição: https://github.com/fabiangreffrath/woof

  • É surpreendente ver o Minecraft se aproximando cada vez mais de um motor de jogo próprio do que de um simples jogo

  • Fico curioso se o motivo para deixar o GLFW está documentado. Tenho um projeto que usa GLFW, então sempre acabo pensando se SDL seria uma escolha melhor

    • Nesta atualização, o suporte a Wayland passou a funcionar sem trabalho adicional. Antes era preciso usar contornos e, mesmo aplicando-os, novos problemas continuavam surgindo, mas eu não me preocupava muito porque me contentava em rodar via XWayland
      O SDL3 tem suporte a Wayland sólido por padrão. No Minecraft, o GLFW era usado apenas para criação de janelas, ícone na barra de tarefas, tela cheia e entrada, enquanto o resto era tratado com OpenGL bruto, então a transição também foi fácil. Agora, com suporte até a Vulkan, dá para usar uma stack totalmente moderna no desktop Linux e no Steam Deck
    • O SDL oferece suporte a mobile, enquanto o GLFW não, então talvez a ideia seja unificar a base de código por plataforma
      O SDL3 funciona até no Android 4.2, e eu já fiz um app com SDL3 e ImGui sem Java
    • Um dos motivos é o suporte a IME (método de entrada)
    • O SDL é quase uma camada de plataforma que pode ser usada em praticamente qualquer lugar. Ele oferece janelas, gráficos, áudio, entrada, rede e threads, enquanto o GLFW oferece apenas janelas, contexto gráfico e entrada, então é preciso providenciar as outras bibliotecas por conta própria
      Pode não fazer muita diferença em todos os projetos, mas o SDL oferece mais recursos e também mais portabilidade
    • Mesmo sem OpenGL ou Vulkan, dá para criar um jogo 2D completo usando apenas a API do SDL

  • O jogo de ritmo osu! também migrou recentemente do SDL2 para o SDL3 e teve grandes melhorias de desempenho e latência. A adoção do SDL3 parece um pouco lenta, e também é curioso que o Minecraft tenha usado GLFW até agora
    Em especial, depois da migração para SDL3, a latência que ocorria quando o cliente do Discord ficava aberto durante a execução do osu! desapareceu; lembro de ter visto isso em um vídeo de desenvolvimento no YouTube

    • Em algumas distribuições Linux, sdl2-compat e sdl12-compat são as implementações padrão do SDL2 e 1.2, então em muitos casos já se está usando SDL3 indiretamente. Graças a isso, mais apps funcionam nativamente em Wayland, com latência menor que no XWayland, e o suporte a controles também melhora
      O Ubuntu 24.04 não incluiu SDL3 desde o início, e isso parece ser um dos motivos pelos quais a adoção está mais lenta do que o esperado, já que o SDL3 é mais recente do que parece
    • O osu! dá suporte aos três principais sistemas operacionais de desktop e também a iOS e Android, e levou cerca de 2 anos para migrar para SDL3 tentando manter recursos como Wayland de forma nativa. Esta transição parece ter chegado pela primeira vez a uma etapa final de fato
    • Várias APIs mudaram no SDL3, o que torna a adoção mais difícil, especialmente quando se passa por uma biblioteca de bindings

  • O SDL2 já mostrava sinais de envelhecimento, especialmente na abstração de APIs de GPU incluindo Vulkan e Metal, então a migração para SDL3 faz sentido. Também fico curioso se os problemas antigos de latência de entrada e Alt+Tab na edição Java no Linux serão resolvidos com a mudança da camada de janelas e entrada

    • Na verdade, o alvo da migração não era o SDL2, mas sim o GLFW, então, ao escolher algo novo, é natural optar pelo SDL3

  • Para dar suporte ativo a mods, parece melhor usar uma linguagem em que descompilação e modificações em runtime sejam fáceis, como Java ou C#, ou então usar JVM e .NET CLR
    Se você considerar também os modders ao fazer mudanças internas, acaba obtendo uma ótima API de modding praticamente sem custo adicional

    • Para um jogo com muitos mods, o que realmente é necessário é apenas uma base de usuários suficientemente grande. Para modders dedicados, um pouco de patch binário ou injeção de DLL não é um obstáculo