Minecraft: Java Edition cambia los backends de ventana y entrada a SDL3

 (minecraft.net)
1 puntos por GN⁺ 23 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Minecraft 26.3 Snapshot 4 reemplaza GLFW por SDL3 como backend de gestión de ventanas, entrada e integración de plataforma, e introduce scancodes y keycodes de SDL para la entrada de teclado
  • Las asignaciones de teclas usan la posición física de la tecla en lugar de códigos específicos de cada distribución de teclado; en Linux se prioriza Wayland cuando sea posible y en macOS se admiten ventanas nativas de candidatos de entrada
  • Se agregan componentes de datos para combustibles personalizados de hornos y de pociones, que permiten configurar el tiempo de combustión, la cantidad de usos y la velocidad de cocción o preparación mediante number providers
  • En data packs 111.0 y resource packs 92.0 cambian ampliamente los eventos de clic en carteles, las referencias a loot tables, los triggers de avances, las propiedades de entorno de generación de mobs, la configuración de generación de terreno y los shaders
  • Hay problemas conocidos de crashes en pantalla completa exclusiva con múltiples monitores en Windows y en Wayland; las versiones de prueba pueden dañar mundos, por lo que conviene hacer copias de seguridad o ejecutarlas en una carpeta separada

Sistema de ventanas y entrada basado en SDL3

  • Se cambió de GLFW a SDL3 la biblioteca de gestión de ventanas, entrada e integración de plataforma
    • La entrada de teclado usa SDL scancode para la posición física de las teclas
    • Para atajos de edición de texto que cambian según la distribución del teclado se aplican SDL keycode
  • Las asignaciones de teclas funcionan con base en teclas físicas, no en códigos de tecla específicos de cada distribución
  • Se eliminó la opción de mouse Raw Input, y durante el juego siempre se usa el modo de mouse relativo
  • La pantalla completa sin bordes pasó a ser el modo de pantalla completa predeterminado, y se puede alternar entre modo sin bordes y exclusivo sin reiniciar
    • En macOS ya no se admite la pantalla completa exclusiva
    • El tamaño mínimo de ventana es de 320×240 píxeles
  • En Linux, cuando esté disponible, se prioriza Wayland de forma nativa
  • En macOS, al mantener presionada una tecla durante la entrada de texto se muestra el popup nativo de acentos y candidatos

Problemas conocidos de pantalla completa

  • La pantalla completa exclusiva en Windows puede causar crashes del juego en ciertas situaciones, especialmente en entornos con múltiples monitores
  • En Wayland, el juego crashea al entrar en pantalla completa exclusiva

Cambios de juego e interfaz

  • Los jugadores en modo espectador pueden interactuar con portales para teletransportarse
  • Los armadillos no intentan enrollarse cuando están sumergidos en líquido
  • Se puede aplicar una escala de GUI independiente al overlay de depuración
    • Se configura en Debug Options con F3 + F6
    • El valor predeterminado Auto mantiene una resolución más alta que la GUI normal, y Unchanged coincide con la escala de la GUI normal
    • También se agregaron player_speed, que muestra la velocidad de movimiento en bloques por tick del jugador, y un indicador de tasa de refresco de la pantalla
  • Se reordenaron los minerales del inventario creativo en materiales sin tier, materiales de tier sin refinar y materiales de tier refinados
    • Los bloques de construcción van en el orden de minerales sin tier, minerales de tier refinados y familia de Copper; los bloques de Copper con muchos ítems se ubican más atrás
    • La pestaña Natural Blocks se organiza en el orden Overworld → Nether → End

Combustibles personalizados y componentes de ítems

  • minecraft:cooking_fuel define combustibles para Furnace, Smoker y Blast Furnace
    • burn_time especifica la cantidad de ticks de combustión y speed_multiplier la velocidad de cocción o fundición, cada uno como minecraft:number_provider
  • minecraft:brewing_fuel define la cantidad de usos y la velocidad de preparación del combustible de Brewing Stand
    • La etiqueta de ítems #brewing_fuel existente fue eliminada, por lo que ya no puede usarse para registrar nuevos combustibles de preparación
  • Las recetas de Smoker y Blast Furnace usan el mismo tiempo de cocción que Furnace, y la mejora de velocidad queda a cargo de minecraft:cooking/speed_default del componente de combustible
  • Los campos de tiempo de cocción y combustible de Furnace, Smoker y Blast Furnace cambiaron de short a integer, y se agregó speed_multiplier
  • BrewTime y Fuel de Brewing Stand también cambiaron a integer, y se agregaron total_brew_time, total_fuel y speed_multiplier
  • Los componentes de datos agregados son los siguientes
    • minecraft:sign_text_front, minecraft:sign_text_back: guardan el texto frontal y posterior de un cartel y lo muestran en el tooltip del ítem
    • minecraft:waxed: marcador sin campos que indica que el contenido fue encerado
    • minecraft:cushion/color: aplica uno de 16 colores de tinte al Cushion colocado
    • minecraft:villager_food: define los ítems que pueden comer los aldeanos y sus valores nutricionales
    • minecraft:mob_visibility: especifica entre 0.0 y 10.0 la proporción en que el equipo afecta la distancia de detección de los mobs; incluso al acumularse, la visión máxima no supera 10.0

Compatibilidad de carteles y data packs

  • La versión de data pack sube a 111.0
  • Los comandos y eventos de clic del texto personalizado en carteles no se ejecutan por defecto al hacer clic en el bloque, y los componentes de texto de los carteles nuevos tampoco se interpretan automáticamente
    • El valor predeterminado del nuevo campo allow_op_features es false; para restaurar el comportamiento anterior debe establecerse explícitamente en true
    • A los carteles guardados en versiones anteriores y a minecraft:block_entity_data que contenga datos de carteles se les aplica allow_op_features=true
  • La pantalla de edición del cartel tras colocarlo solo se muestra cuando puede abrirse con un clic normal, por ejemplo si no está encerado y se puede editar el texto frontal
  • Los carteles intercambian los componentes minecraft:sign_text_front, minecraft:sign_text_back y minecraft:waxed
  • Los bloques seguros donde /spreadplayers puede colocar jugadores se controlan con la etiqueta de bloques #entities_can_teleport_to

Referencias de registros y cambios en loot y avances

  • Los tipos de loot table con registro dedicado admiten referencias a elementos de registro y etiquetas
    • Los campos de un solo elemento pueden recibir un ID namespaced o un valor inline
    • Los campos de lista pueden recibir valores inline, uno o varios ID namespaced, listas de valores inline o ID de etiqueta con #
    • Los destinos son advancement, item modifier, loot table, number provider, predicate, recipe y slot source
  • Los tipos reference existentes de predicate, item modifier y slot source ya no son necesarios y fueron eliminados
  • Varios campos de los triggers de avances pueden recibir no solo predicates inline, sino también ID namespaced de predicates
    • Se eliminó el comportamiento implícito de minecraft:all_of en las listas de condiciones existentes, por lo que ahora debe especificarse type
    • Varios campos block, recipe_id y loot_table pasaron a plural y admiten un ID único, una lista o una etiqueta
  • En Loot Pool Entry, conditions cambió de nombre a condition y functions a modifier
  • En Loot Function, conditions cambió a condition, y function, que indicaba el tipo de función, pasó a llamarse type
    • Ya no se aceptan listas de condiciones inline; para el mismo comportamiento debe especificarse minecraft:all_of
  • En Predicate, el campo de tipo condition cambió a type, y se eliminaron minecraft:reference y minecraft:block_state_property
    • El nuevo minecraft:match_block comprueba conjuntamente ID o etiqueta de bloque, estado, NBT, componentes y predicate de componentes
  • Los number providers inline siempre deben especificar type, y ya no usan minecraft:uniform como valor predeterminado
  • Se agregaron varios number providers Vanilla que ofrecen tiempos de combustión por combustible de cocción, velocidades predeterminadas de cocción y preparación, y cantidad de preparaciones

Generación de mobs y de mundos

  • La nueva propiedad de entorno minecraft:gameplay/natural_mob_spawns define generación de mobs ponderada por categoría y spawn cost por entidad
    • Durante la colocación de la generación del mundo, solo Dimension y Biome aplican esta propiedad
    • El modificador overlay aplica con prioridad la configuración de categoría de la capa superior y el spawn cost de la misma entidad
  • minecraft:gameplay/creature_world_gen_spawn_probability especifica una probabilidad de repetición de generación de mobs de la categoría creature durante la generación del mundo como mayor o igual que 0 y menor que 1; el valor predeterminado es 0.1
  • spawners, spawn_costs y creature_spawn_probability de Biome fueron eliminados y movidos a las nuevas propiedades de entorno
  • La propiedad de entorno de partículas ambientales interpola la probabilidad entre keyframes de la línea de tiempo y admite el modificador append, que concatena elementos a la lista de partículas de capas inferiores
  • En Noise Settings, la configuración de aquifer y ore vein se reorganizó en un objeto opcional aquifers y una lista ore_veins, respectivamente
    • Si no hay configuración, no se genera el aquifer u ore vein correspondiente
    • Los campos de density function relacionados se movieron de noise_router a la nueva estructura
  • Se agregaron sub, div, negate, lerp, floor, round, ceil, truncate y beardifier a Density Function
    • Varios nombres de argumentos existentes cambiaron a value, left, right, input y noise
    • invert cambió de nombre a reciprocal
    • final_density ya no suma implícitamente beardifier

Gráficos y principales correcciones de errores

  • La versión de resource pack sube a 92.0
  • Se agregaron shaders compatibles con transparencia independiente del orden (order-independent transparency) y la definición OIT_ALWAYS_WRITE_DEPTH
  • core/integrate_depth.fsh integra el buffer de profundidad del HUD 3D y de los gizmos que se muestran siempre encima en el buffer de profundidad principal
  • Los principales problemas corregidos son los siguientes
    • Problemas de asignación de teclas y entrada relacionados con teclados no QWERTY y entrada macOS/CJK
    • Crashes al renderizar mapas con Improved Transparency, y problemas de visualización de vidrio, objetos translúcidos, partículas y el borde del mundo
    • Crashes causados por proyectiles fuera de la altura del mundo y colmenas colocadas en la altura mínima
    • Problemas al guardar y cargar heightmaps de generación de mundo y desincronización de la posición de mobs después de tick sprint
    • Problemas de colocación, color, nombre personalizado, tiempo de combustible y detección de colisiones de Cushion
    • Problemas de daño y vuelo del Ender Dragon, uso de portales por espectadores y determinación de bloques seguros en /spreadplayers

Instalación y precauciones de prueba

  • La Snapshot es para Minecraft: Java Edition y se instala activando Snapshot en la pestaña Installations del Minecraft Launcher
  • Las versiones de prueba pueden dañar mundos, por lo que se debe hacer una copia de seguridad o ejecutarlas en una carpeta distinta a la de los mundos principales
  • También se ofrece el Minecraft server jar multiplataforma
  • Los bugs pueden enviarse al Minecraft issue tracker, y los comentarios al sitio de Feedback

Lecturas relacionadas

1 comentarios

 
GN⁺ 23 시간 전
Opiniones de Hacker News

  • La implementación de LWJGL de este binding fue escrita por un miembro del equipo del modpack GTNH, completando otra vez el ciclo vanilla→modded→vanilla https://github.com/LWJGL/lwjgl3/pull/1033

    • Exagerando un poco, se podría decir que GTNH ha contribuido más a Minecraft que Microsoft. No lo digo solo porque yo mismo aporté un poco; el nivel de dedicación y la cantidad de trabajo invertido son sorprendentes
    • Me pregunto cuántos de los desarrolladores actuales de Minecraft fueron modders en el pasado y cuántos siguen activos como modders hoy

  • Hace poco migré el juego Tribal Trouble(https://github.com/bondolo/tribaltrouble) de GLFW a SDL3, y en general fue una refactorización bastante llevadera. Hubo algunos problemas con la pantalla completa exclusiva y la pantalla completa de escritorio, pero al final se resolvieron
    También escribí un demo para probar y documentar el manejo de modos de pantalla complicados. El juego, como Minecraft, está hecho en Java, pero el demo está en C para mantenerlo lo más simple posible

    • Tribal Trouble, qué nombre tan viejo. Recuerdo que los desarrolladores dijeron que eligieron Java porque querían usar un lenguaje raro o poco común para hacer juegos
    • Me pregunto si había algún problema con GLFW, o por qué decidieron hacer la migración a SDL3

  • La pantalla completa exclusiva en Windows puede romper el juego, especialmente con varios monitores, y en Wayland hay un problema conocido donde solo entrar ya lo rompe. Ambos parecen bugs bloqueantes como para posponer un snapshot, así que ojalá se arreglen antes del lanzamiento oficial

    • Un snapshot es simplemente distribuir tal cual el estado actual de la rama principal, incluso con bugs bloqueantes incluidos
      Yo pondría el nivel esperado de estabilidad en este orden: edición con soporte a largo plazo, versión estable, candidata de lanzamiento, beta, alfa, snapshot, commit recién mergeado, PR sin mergear, PR en borrador, etc. Si es un bug grande, puede retrasar una candidata o una beta, y si es crítico debería impedir el merge; pero no hay razón para retrasar un snapshot por un bug que pasó CI y ya fue mergeado
      Un snapshot se parece más a cortar y publicar periódicamente el estado actual para que la gente pueda ejecutarlo y dar feedback sin tener que compilar main por su cuenta
    • Si fuera el lanzamiento oficial, se podría retrasar, pero no hay razón para retrasar un snapshot. Hay que publicarlo tal como está para ver por telemetría con qué frecuencia ocurre el problema conocido, y también para descubrir antes del lanzamiento oficial otros problemas que todavía no se conocen
      Un snapshot nunca prometió estar libre de bugs; más bien se asume lo contrario
    • Minecraft probablemente ha usado pantalla completa sin bordes desde hace mucho tiempo, salvo que se configure aparte. En los últimos más de 10 años, muchas plataformas, servicios y apps han ido dejando de lado la pantalla completa exclusiva
    • Hoy en día es más común renderizar en una ventana a pantalla completa que usar pantalla completa exclusiva. El gestor de ventanas normalmente aplica a la ventana en primer plano a pantalla completa las mismas optimizaciones que antes solo se aplicaban al modo exclusivo
    • Como es un snapshot, son problemas que pueden pasar, y seguramente los arreglen en el siguiente snapshot

  • Me pregunto cómo debería hacer en 2026 un papá técnico que no sabe nada de Minecraft para montar un servidor familiar. Sus hijos juegan ahora en iPad y a veces en una MacBook vieja o una PC con Windows

    • Minecraft tiene dos ediciones, Java y Bedrock. La versión móvil, consola y la de Windows Store están basadas en Bedrock, y la que se descarga directamente desde el sitio web es la edición Java
      Puedes correr un servidor Java estándar y usar Geyser para traducir en tiempo real el protocolo de Bedrock. Puede que los clientes Bedrock, por sus limitaciones, necesiten algunos rodeos, pero así puedes administrar todo alrededor de un servidor Java, que ofrece más opciones
    • Las guías en línea de ajuste de JVM para Minecraft suelen estar desactualizadas o ser incorrectas, así que conviene ignorarlas
      Basta con usar una JVM moderna, subir la memoria máxima tanto como sea aceptable y usar ZGC. Hay guías que tocan varias flags sin fundamento o meten a la vez configuraciones que se contradicen, como el tamaño de Eden y el tiempo objetivo de pausa
      ZGC tiene latencia muy baja y pierde menos rendimiento cuanto más grande es el heap, pero conviene dejarlo en menos de 32 GB para mantener la compresión de headers de objetos. Una JVM moderna también mejora el uso de memoria y el rendimiento general
    • Solo hay que seguir cómo configurar un servidor vanilla de Java Edition. La edición Java solo corre en Windows, macOS y Linux, pero en mi opinión tiene menos bugs y es mejor que Bedrock
      Si hace falta más rendimiento, instala fabric y lithium. Conviene evitar mods como Paper, Spigot o Purpur porque pueden romper las granjas automáticas
    • Minecraft en teléfonos y tabletas es más cerrado y limitado que la edición Java, así que hay menos opciones
      He usado itzg/docker-minecraft-server durante años sin problemas, y me gustó que la imagen se encargara de todo sin tener que instalar dependencias una por una. También hay una imagen de servidor Bedrock, pero no logré hacerla funcionar bien
      La forma más sencilla de operarlo es que todos usen la edición Java en Windows, Mac o Linux; si no, queda la opción de pagar por el servidor alojado Realms
    • Considerando la preferencia de los niños por jugar en iPad, también vale la pena mirar Realms. Según entiendo, ofrece un servidor para 10 personas por unos 7 dólares, pero las suscripciones de Java y Bedrock están separadas y los planes están fragmentados en varios niveles
      Puede que no encaje según el objetivo del servidor familiar, pero para que los niños jueguen juntos rápido y fácil probablemente sea la opción más simple. También he visto niños que insistieron durante mucho tiempo en usar solo Bedrock, se pasaron a Java y luego lamentaron no haberse cambiado antes

  • Icculus publicó un excelente video sobre portar un juego de SDL2 a SDL3, y el video sobre portar Doom está aquí: https://www.youtube.com/watch?v=ixdeGhsoxy8

    • No sabía que Chocolate Doom se estaba portando a SDL3 y que Icculus estaba trabajando en ello directamente. De las versiones de Doom que conozco, Woof! ya hizo la transición: https://github.com/fabiangreffrath/woof

  • Sorprende ver que Minecraft se va pareciendo cada vez más a un motor de juego propio que a un simple juego

  • Me pregunto si está documentado por qué dejaron GLFW. Tengo un proyecto que usa GLFW, así que siempre termino pensando si SDL es una mejor opción

    • En esta actualización, el soporte para Wayland pasó a funcionar sin trabajo adicional. Antes hacían falta soluciones alternativas y, aun aplicándolas, seguían apareciendo problemas nuevos, pero como la mayoría se conformaba con ejecutarlo en XWayland, no le prestaron demasiada atención
      SDL3 tiene un soporte sólido para Wayland de base. En Minecraft, GLFW solo se usaba para creación de ventanas, ícono de la barra de tareas, pantalla completa e entrada, y el resto se manejaba con OpenGL puro, así que la transición también fue sencilla. Ahora incluso soporta Vulkan, así que en Linux de escritorio y Steam Deck ya puede usarse una pila completamente moderna
    • SDL soporta móviles, mientras que GLFW no, así que podría tratarse de un intento de unificar el código entre plataformas
      SDL3 funciona incluso en Android 4.2, y alguna vez hice una app con SDL3 e ImGui sin usar Java
    • Una de las razones es el soporte para IME
    • SDL es casi una capa de plataforma que puede usarse en casi cualquier parte. Ofrece ventanas, gráficos, audio, entrada, red e hilos, mientras que GLFW solo ofrece ventanas, contexto gráfico y entrada, así que el resto de bibliotecas hay que prepararlas por cuenta propia
      Puede que no haga una gran diferencia en todos los proyectos, pero SDL ofrece más funciones y también mayor portabilidad
    • Incluso sin OpenGL ni Vulkan, se puede hacer un juego 2D completo solo con la API de SDL

  • El juego de ritmo osu! también cambió recientemente de SDL2 a SDL3 y mejoró mucho en rendimiento y latencia. La adopción de SDL3 parece algo lenta, y también sorprende que Minecraft haya usado GLFW hasta ahora
    En particular, después del cambio a SDL3 desapareció la latencia que ocurría al dejar abierto el cliente de Discord mientras se ejecutaba osu!, según recuerdo de un video de desarrollo en YouTube

    • En algunas distribuciones de Linux, sdl2-compat y sdl12-compat son la implementación predeterminada de SDL2 y 1.2, así que ya es común usar SDL3 indirectamente. Gracias a eso, más aplicaciones funcionan de forma nativa en Wayland con menor latencia que en XWayland, y también mejora el soporte para controles
      Ubuntu 24.04 no incluía SDL3 desde el principio, y como SDL3 es más reciente de lo que parece, esa parece ser una de las razones por las que su adopción va más lenta de lo esperado
    • osu! soporta los 3 principales sistemas operativos de escritorio, además de iOS y Android, y como intentaban mantener de forma nativa funciones como Wayland, la transición a SDL3 tomó unos 2 años. Parece que esta vez por fin llegó a una etapa realmente final
    • En SDL3 cambiaron varias API, lo que hace más difícil adoptarlo, y la carga aumenta especialmente cuando se usan bibliotecas de bindings

  • SDL2 ya mostraba su antigüedad, sobre todo en la abstracción de API de GPU incluyendo Vulkan y Metal, así que tiene sentido pasar a SDL3. También me pregunto si en la edición Java para Linux se resolverán por fin los viejos problemas de latencia de entrada y de Alt+Tab al cambiar la capa de ventana y entrada

    • En realidad, el objetivo de la transición no era SDL2 sino GLFW, así que si hoy hubiera que elegir de nuevo, naturalmente se escogería SDL3

  • Si se quiere dar un soporte activo a mods, parece mejor usar lenguajes donde sea fácil descompilar y modificar en tiempo de ejecución, como Java o C#, o bien usar la JVM o .NET CLR
    Si además de hacer cambios internos también se piensa en los modders, en la práctica se obtiene una excelente API de modding casi sin costo adicional

    • Lo que de verdad necesita un juego con muchos mods es solo una base de usuarios lo bastante grande. Para modders dedicados, un poco de parcheo binario o inyección de DLL no es un obstáculo