Minecraft: Java Edition passe le backend de fenêtre et d’entrée à SDL3

 (minecraft.net)
1 points par GN⁺ 23 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Le Snapshot 4 de Minecraft 26.3 remplace GLFW par SDL3 pour le backend de gestion des fenêtres, d’entrée et d’intégration de plateforme, et introduit les SDL scancodes et keycodes pour l’entrée clavier
  • Les raccourcis clavier utilisent la position physique des touches plutôt que des codes liés à la disposition du clavier, Linux privilégie Wayland quand c’est possible, et macOS prend en charge la fenêtre native de composition de saisie
  • Un composant de données pour les combustibles personnalisés de four et d’alambic a été ajouté, permettant de définir le temps de combustion, le nombre d’utilisations et la vitesse de cuisson ou de brassage via un number provider
  • Le data pack 111.0 et le resource pack 92.0 modifient en profondeur les événements de clic sur les panneaux, les références de tables de loot, les triggers d’avancement, les propriétés d’environnement de génération des mobs, les paramètres de génération du terrain et les shaders
  • Des plantages du mode plein écran exclusif sont connus sous Windows en configuration multi-écran et sous Wayland, et cette version de test peut corrompre les mondes : il faut donc faire une sauvegarde ou l’exécuter dans un dossier séparé

Système de fenêtre et d’entrée basé sur SDL3

  • La bibliothèque de gestion des fenêtres, d’entrée et d’intégration de plateforme passe de GLFW à SDL3
    • L’entrée clavier utilise les SDL scancodes pour la position physique des touches
    • Les raccourcis d’édition de texte qui varient selon la disposition du clavier utilisent les SDL keycodes
  • Les raccourcis clavier fonctionnent désormais selon les touches physiques plutôt que selon les codes de touches propres à chaque disposition
  • Le réglage de souris Raw Input est supprimé, et le jeu utilise désormais toujours le mode souris relative en cours de partie
  • Le plein écran sans bordure devient le mode plein écran par défaut, et il est possible de basculer entre le mode sans bordure et le mode exclusif sans redémarrer
    • Sur macOS, le plein écran exclusif n’est plus pris en charge
    • La taille minimale de la fenêtre est de 320×240 pixels
  • Sous Linux, Wayland est privilégié nativement lorsqu’il est disponible
  • Sur macOS, maintenir une touche pendant une saisie de texte affiche la fenêtre native d’accents et de candidats

Problèmes connus en plein écran

  • Le plein écran exclusif sous Windows peut faire planter le jeu dans certaines situations, en particulier en environnement multi-écran
  • Sous Wayland, le jeu plante lors de l’entrée en plein écran exclusif

Changements de gameplay et d’interface

  • Les joueurs en mode spectateur peuvent interagir avec les portails pour se téléporter
  • Les tatous n’essaient plus de se rouler en boule lorsqu’ils sont immergés dans un liquide
  • Une échelle GUI distincte peut être appliquée à l’overlay de débogage
    • Elle se règle dans les Debug Options avec F3 + F6
    • La valeur par défaut Auto conserve une résolution plus élevée que le GUI normal, tandis que Unchanged correspond à l’échelle GUI normale
    • player_speed, qui affiche la vitesse de déplacement du joueur en blocs par tick, ainsi qu’un affichage du taux de rafraîchissement ont aussi été ajoutés
  • L’ordre des minerais dans l’inventaire créatif a été réorganisé en matériaux sans palier, matériaux de palier non raffinés, puis matériaux de palier raffinés
    • Les blocs de construction suivent l’ordre minerais sans palier, minerais de palier raffinés, puis famille Copper, avec les blocs Copper les plus nombreux placés plus loin
    • L’onglet Natural Blocks est organisé dans l’ordre Overworld → Nether → End

Combustibles personnalisés et composants d’objet

  • minecraft:cooking_fuel définit le carburant pour Furnace, Smoker et Blast Furnace
    • burn_time indique le nombre de ticks de combustion, et speed_multiplier définit la vitesse de cuisson ou de fusion via minecraft:number_provider
  • minecraft:brewing_fuel définit le nombre d’utilisations et la vitesse de brassage du carburant de Brewing Stand
    • L’ancien item tag #brewing_fuel est supprimé et ne peut plus servir à enregistrer de nouveaux carburants de brassage
  • Les recettes de Smoker et Blast Furnace utilisent désormais le même temps de cuisson que Furnace, et l’accélération provient du minecraft:cooking/speed_default du composant de carburant
  • Les champs de temps de cuisson et de carburant de Furnace, Smoker et Blast Furnace passent de short à integer et speed_multiplier est ajouté
  • BrewTime et Fuel du Brewing Stand passent aussi à integer, avec l’ajout de total_brew_time, total_fuel et speed_multiplier
  • Les composants de données ajoutés sont les suivants
    • minecraft:sign_text_front, minecraft:sign_text_back : stockent le texte avant et arrière d’un panneau et l’affichent dans l’infobulle de l’objet
    • minecraft:waxed : marqueur sans champ indiquant que le contenu a été ciré
    • minecraft:cushion/color : applique l’une des 16 couleurs de teinture à un Cushion placé
    • minecraft:villager_food : définit les objets que les villageois peuvent manger et leur valeur nutritive
    • minecraft:mob_visibility : définit de 0.0 à 10.0 l’effet d’un équipement sur la distance de détection par les mobs ; même cumulée, la valeur maximale de vision ne dépasse pas 10.0

Compatibilité des panneaux et des data packs

  • La version du data pack passe à 111.0
  • Les commandes et événements de clic des textes personnalisés sur panneau ne s’exécutent plus par défaut lors d’un clic sur le bloc, et les composants de texte des nouveaux panneaux ne sont plus interprétés automatiquement
    • Le nouveau champ allow_op_features vaut false par défaut ; pour restaurer l’ancien comportement, il faut le définir explicitement à true
    • Les panneaux enregistrés dans les anciennes versions ainsi que les minecraft:block_entity_data contenant des données de panneau reçoivent allow_op_features=true
  • L’écran d’édition des panneaux après placement n’apparaît que lorsqu’un clic normal peut ouvrir l’écran d’édition, par exemple si le panneau n’est pas ciré et que le texte avant peut être modifié
  • Les panneaux échangent les composants minecraft:sign_text_front, minecraft:sign_text_back et minecraft:waxed
  • Les blocs sûrs sur lesquels /spreadplayers peut placer les joueurs sont contrôlés par le block tag #entities_can_teleport_to

Références de registre et changements sur le loot et les avancées

  • Les types de tables de loot disposant d’un registre dédié prennent en charge les références à des éléments de registre et à des tags
    • Les champs d’élément unique peuvent recevoir un ID namespaced ou une valeur inline
    • Les champs de liste peuvent recevoir une valeur inline, un ou plusieurs ID namespaced, une liste de valeurs inline ou un ID de tag avec #
    • Cela concerne advancement, item modifier, loot table, number provider, predicate, recipe et slot source
  • Les anciens types reference de predicate, item modifier et slot source sont supprimés car devenus inutiles
  • Plusieurs champs des triggers d’avancement peuvent désormais recevoir non seulement des predicates inline, mais aussi des ID de predicate namespaced
    • Le comportement implicite minecraft:all_of de l’ancienne liste de conditions est supprimé, il faut donc désormais toujours préciser type
    • Plusieurs champs block, recipe_id et loot_table passent respectivement au pluriel et prennent en charge un ID unique, une liste ou un tag
  • Dans Loot Pool Entry, conditions devient condition et functions devient modifier
  • Dans Loot Function, conditions devient condition, et function, qui indiquait le type de fonction, devient type
    • Les listes de conditions inline ne sont plus acceptées ; pour le même comportement, il faut expliciter minecraft:all_of
  • Dans Predicate, le champ de type condition devient type, et minecraft:reference ainsi que minecraft:block_state_property sont supprimés
    • Le nouveau minecraft:match_block vérifie ensemble l’ID ou le tag du bloc, les états, le NBT, les composants et les predicates de composant
  • Les number providers inline doivent désormais toujours préciser type et n’utilisent plus minecraft:uniform comme valeur par défaut
  • Plusieurs number providers Vanilla ont été ajoutés pour fournir le temps de combustion par combustible de cuisson, la vitesse de cuisson ou de brassage par défaut, et le nombre d’utilisations pour le brassage

Apparition des mobs et génération du monde

  • La nouvelle propriété d’environnement minecraft:gameplay/natural_mob_spawns définit les apparitions de mobs basées sur un poids par catégorie ainsi que le spawn cost par entité
    • Pendant le placement lors de la génération du monde, seules Dimension et Biome appliquent cette propriété
    • Le modificateur overlay applique en priorité les paramètres de catégorie de la couche supérieure ainsi que le spawn cost de la même entité
  • minecraft:gameplay/creature_world_gen_spawn_probability définit, pendant la génération du monde, la probabilité de répétition des apparitions de mobs de catégorie creature entre 0 inclus et 1 exclu, avec une valeur par défaut de 0.1
  • spawners, spawn_costs et creature_spawn_probability des biomes sont supprimés et déplacés vers la nouvelle propriété d’environnement
  • La propriété d’environnement des particules ambiantes interpole la probabilité entre les images-clés de la timeline et prend en charge le modificateur append, qui ajoute des éléments à la liste de particules de la couche inférieure
  • Dans Noise Settings, les paramètres d’aquifère et de veines de minerai sont réorganisés en un objet optionnel aquifers et une liste ore_veins
    • En l’absence de configuration, aucun aquifère ou aucune veine de minerai n’est généré
    • Les champs de density function associés quittent noise_router pour rejoindre cette nouvelle structure
  • Les Density Functions ajoutent sub, div, negate, lerp, floor, round, ceil, truncate, beardifier
    • Plusieurs noms d’arguments existants deviennent value, left, right, input, noise
    • invert est renommé en reciprocal
    • beardifier n’est plus implicitement ajouté à final_density

Graphismes et principales corrections de bugs

  • La version du resource pack passe à 92.0
  • Des shaders compatibles avec la transparence indépendante de l’ordre (order-independent transparency) ainsi que la définition OIT_ALWAYS_WRITE_DEPTH sont ajoutés
  • core/integrate_depth.fsh intègre le depth buffer du HUD 3D et des gizmos toujours affichés au-dessus dans le depth buffer principal
  • Les principaux problèmes corrigés sont les suivants
    • Problèmes de raccourcis clavier et de saisie liés aux claviers non QWERTY ainsi qu’à macOS et aux saisies CJK
    • Plantages du rendu des cartes avec Improved Transparency, ainsi que problèmes d’affichage du verre, des objets semi-transparents, des particules et des limites du monde
    • Plantages causés par des projectiles hors de la hauteur du monde et par le placement de ruches à la hauteur minimale
    • Problèmes d’enregistrement et de chargement des heightmaps lors de la génération du monde, ainsi que désynchronisation de la position des mobs après tick sprint
    • Problèmes de placement, de couleur, de nom personnalisé, de durée de carburant et de détection de collision des Cushion
    • Problèmes liés aux dégâts et au vol de l’Ender Dragon, à l’usage des portails par les spectateurs et à la détection des blocs sûrs par /spreadplayers

Installation et précautions de test

  • Ce Snapshot est destiné à Minecraft: Java Edition et s’installe en activant Snapshot dans l’onglet Installations du Minecraft Launcher
  • Les versions de test peuvent corrompre les mondes, il faut donc les sauvegarder ou les exécuter dans un dossier distinct de vos mondes principaux
  • Un Minecraft server jar multiplateforme est également fourni
  • Les bugs peuvent être signalés sur le Minecraft issue tracker, et les retours sur le site Feedback

À lire aussi

1 commentaires

 
GN⁺ 23 시간 전
Avis sur Hacker News

  • L’implémentation LWJGL de ce binding a été écrite par un membre de l’équipe du modpack GTNH, bouclant à nouveau la boucle vanilla→moddé→vanilla https://github.com/LWJGL/lwjgl3/pull/1033

    • En exagérant un peu, on pourrait dire que GTNH a davantage contribué à Minecraft que Microsoft. Je ne dis pas seulement ça parce que j’y ai moi-même un peu contribué : le soin et la quantité de travail investis sont impressionnants
    • Je me demande combien de développeurs Minecraft actuels ont été moddeurs par le passé, et combien le sont encore aujourd’hui

  • J’ai récemment porté le jeu Tribal Trouble (https://github.com/bondolo/tribaltrouble) de GLFW vers SDL3, et dans l’ensemble le refactoring s’est fait assez facilement. Il y a eu quelques problèmes avec le plein écran exclusif et le plein écran bureau, mais ils ont fini par être résolus
    J’ai aussi écrit une démo pour tester et documenter la gestion délicate des modes d’affichage. Le jeu est en Java, comme Minecraft, mais la démo est en C pour la garder aussi simple que possible

    • Tribal Trouble, ça faisait vraiment longtemps que je n’avais pas entendu ce nom. Je me souviens que les développeurs disaient avoir choisi Java parce qu’ils voulaient utiliser un langage étrange ou peu courant pour développer un jeu
    • Je me demande s’il y avait un problème avec GLFW, ou pour quelle raison le passage à SDL3 a été choisi

  • Le plein écran exclusif sous Windows peut faire planter le jeu, surtout en multi-écran, et sous Wayland il existe un problème connu où le simple fait d’y entrer provoque un plantage. Dans les deux cas, ça ressemble typiquement à des bugs bloquants justifiant de reporter un snapshot ; j’espère qu’ils seront corrigés avant la sortie stable

    • Un snapshot consiste à publier tel quel l’état actuel de la branche principale, y compris les bugs bloquants
      À mon sens, le niveau d’attente en matière de stabilité va dans l’ordre suivant : version à support long terme, version stable, release candidate, bêta, alpha, snapshot, commit tout juste mergé, PR non mergée, PR brouillon, etc. Un gros bug devrait repousser une release candidate ou une bêta, et un bug critique devrait empêcher le merge lui-même, mais il n’y a aucune raison de retarder un snapshot à cause d’un bug qui a passé la CI et a été mergé
      Un snapshot, c’est plutôt une coupe régulière de l’état actuel pour permettre aux utilisateurs de l’exécuter et de faire des retours sans devoir compiler eux-mêmes main
    • Pour une sortie stable, on pourrait reporter, mais il n’y a aucune raison de retarder un snapshot. Il faut le publier en l’état pour mesurer par télémétrie la fréquence des problèmes connus, et découvrir avant la sortie stable ceux qui ne sont pas encore connus
      Les snapshots n’ont jamais promis d’être exempts de bugs ; c’est même l’inverse qui est supposé
    • Sauf configuration particulière, Minecraft utilise probablement depuis longtemps le plein écran sans bordure. Ces dix dernières années, de nombreuses plateformes, services et applis ont abandonné le plein écran exclusif
    • Aujourd’hui, le rendu dans une fenêtre plein écran est plus courant que le plein écran exclusif. Les gestionnaires de fenêtres appliquent généralement à la fenêtre plein écran au premier plan les mêmes optimisations qu’ils réservaient autrefois au mode exclusif
    • C’est le genre de problème qui peut arriver avec un snapshot, et il y a de fortes chances que ce soit corrigé dans le snapshot suivant

  • Je me demande comment un papa technicien qui ne connaît absolument pas Minecraft devrait s’y prendre pour monter un serveur familial en 2026. Les enfants jouent actuellement sur iPad et parfois sur un vieux MacBook ou un PC Windows

    • Minecraft existe en deux éditions, Java et Bedrock. Les versions mobile, console et Windows Store reposent sur Bedrock, tandis que celle téléchargée directement depuis le site est l’édition Java
      On peut faire tourner un serveur Java standard et utiliser Geyser pour convertir en temps réel le protocole Bedrock. Les clients Bedrock, plus fortement limités, peuvent nécessiter des contournements, mais cela permet de gérer le tout autour d’un serveur Java, qui offre plus d’options
    • Les guides de tuning JVM pour Minecraft qu’on trouve en ligne sont souvent obsolètes ou erronés, mieux vaut donc les ignorer
      Il suffit d’utiliser une JVM récente, d’augmenter la mémoire maximale autant que raisonnablement possible, puis d’utiliser ZGC. Certains guides recommandent de modifier quantité de flags sans justification, voire de combiner des réglages contradictoires comme la taille de la région Eden et une pause cible
      ZGC a une latence très faible et ses performances se dégradent moins avec de grands heaps, mais il vaut mieux rester sous 32 Go pour conserver la compression des en-têtes d’objets. Les JVM récentes améliorent aussi l’utilisation mémoire et les performances globales
    • Il suffit de suivre le guide de configuration d’un serveur vanilla en édition Java. L’édition Java ne fonctionne que sous Windows, macOS et Linux, mais je la trouve meilleure et moins boguée que Bedrock
      Si davantage de performances sont nécessaires, on peut installer fabric et lithium. Mieux vaut éviter les mods comme Paper, Spigot ou Purpur, qui peuvent casser des systèmes automatisés
    • Minecraft sur téléphone et tablette est plus fermé et plus limité que l’édition Java, ce qui réduit les options
      J’ai utilisé itzg/docker-minecraft-server de façon fiable pendant des années, et j’aimais le fait que l’image prenne tout en charge sans avoir à installer les dépendances une par une. Il existe aussi une image de serveur Bedrock, mais je n’ai pas réussi à la faire fonctionner correctement
      Pour l’exploitation la plus simple, tout le monde devrait utiliser l’édition Java sous Windows, Mac ou Linux ; sinon, il reste la solution de payer un serveur hébergé, Realms
    • Vu la préférence des enfants pour jouer sur iPad, Realms peut aussi valoir le détour. Il me semble qu’environ 7 dollars donnent droit à un serveur pour 10 personnes, mais les abonnements Java et Bedrock sont séparés et les offres sont fragmentées en plusieurs niveaux
      Selon l’objectif du serveur familial, ce ne sera peut-être pas adapté, mais pour que les enfants jouent ensemble rapidement et simplement, c’est la solution la plus facile. J’ai aussi vu des enfants qui se sont longtemps obstinés sur Bedrock, puis sont passés à Java et ont regretté de ne pas l’avoir fait plus tôt

  • Icculus a publié une excellente vidéo sur le portage d’un jeu de SDL2 vers SDL3, et la vidéo du portage de Doom est ici : https://www.youtube.com/watch?v=ixdeGhsoxy8

    • Je ne savais pas que Chocolate Doom était porté vers SDL3, ni qu’Icculus travaillait dessus lui-même. Parmi les ports de Doom que je connais, Woof! a déjà fait la transition : https://github.com/fabiangreffrath/woof

  • C’est surprenant de voir Minecraft se rapprocher de plus en plus d’un moteur de jeu à part entière plutôt que d’un simple jeu.

  • Je me demande si la raison de l’abandon de GLFW est documentée. Comme j’ai un projet qui utilise GLFW, je me demande toujours si SDL serait un meilleur choix.

    • Avec cette mise à jour, la prise en charge de Wayland fonctionne sans travail particulier. Avant, il fallait des contournements, et même après les avoir appliqués de nouveaux problèmes apparaissaient sans cesse, mais comme la plupart des gens se satisfaisaient d’une exécution via XWayland, on n’y prêtait pas trop attention.
      SDL3 dispose par défaut d’une prise en charge solide de Wayland. Dans Minecraft, GLFW ne servait qu’à la création de fenêtres, à l’icône de barre des tâches, au plein écran et aux entrées, le reste étant géré en OpenGL brut, donc la transition était aussi facile. Désormais, avec la prise en charge de Vulkan en plus, on peut utiliser une pile entièrement moderne sur les bureaux Linux et le Steam Deck.
    • SDL prend en charge le mobile, contrairement à GLFW, donc il peut s’agir de vouloir unifier les bases de code propres à chaque plateforme.
      SDL3 fonctionne même sur Android 4.2, et j’ai déjà créé une appli avec SDL3 et ImGui sans Java.
    • L’une des raisons est la prise en charge des méthodes de saisie (IME).
    • SDL ressemble davantage à une couche de plateforme utilisable presque partout. Il fournit fenêtres, graphisme, audio, entrées, réseau et threads, alors que GLFW ne fournit que les fenêtres, le contexte graphique et les entrées ; il faut donc préparer soi-même les autres bibliothèques.
      Ce n’est peut-être pas une grande différence pour tous les projets, mais SDL offre plus de fonctionnalités et une meilleure portabilité.
    • Même sans OpenGL ni Vulkan, on peut créer un jeu 2D complet uniquement avec l’API SDL.

  • Le jeu de rythme osu! est lui aussi récemment passé de SDL2 à SDL3, avec de nettes améliorations de performances et de latence. L’adoption de SDL3 semble un peu lente, et il est aussi surprenant que Minecraft ait utilisé GLFW jusqu’ici.
    En particulier, après le passage à SDL3, la latence qui apparaissait quand le client Discord était ouvert pendant l’exécution d’osu! a disparu ; je crois l’avoir vu dans une vidéo de développement sur YouTube.

    • Dans certaines distributions Linux, sdl2-compat et sdl12-compat sont les implémentations par défaut de SDL2 et 1.2, si bien que beaucoup utilisent déjà SDL3 indirectement. Grâce à cela, davantage d’applications fonctionnent nativement sous Wayland avec une latence plus faible que sous XWayland, et la prise en charge des manettes s’améliore aussi.
      Ubuntu 24.04 n’incluait pas SDL3 dès le départ ; SDL3 étant plus récent qu’on ne le pense, cela semble être l’une des raisons pour lesquelles son adoption est plus lente que prévu.
    • osu! prend en charge les trois principaux systèmes d’exploitation de bureau ainsi qu’iOS et Android, et comme il voulait aussi conserver nativement des fonctionnalités comme Wayland, le passage à SDL3 a pris environ deux ans. Cette transition semble être la première à réellement atteindre la phase finale.
    • Plusieurs API ont changé dans SDL3, ce qui rend son adoption plus difficile, surtout quand on passe par des bibliothèques de bindings.

  • SDL2 montrait son âge, notamment dans l’abstraction des API GPU incluant Vulkan et Metal, donc le passage à SDL3 est logique. Je me demande aussi si les problèmes anciens de latence d’entrée et d’Alt+Tab sous Linux dans l’édition Java seront résolus par le changement de couche fenêtre/entrée.

    • En réalité, la cible de la migration n’était pas SDL2 mais GLFW ; donc si l’on devait faire un nouveau choix, il serait naturel de choisir SDL3.

  • Pour prendre activement en charge les mods, il semble préférable d’utiliser un langage où la décompilation et les modifications à l’exécution sont faciles, comme Java ou C#, ou bien la JVM et le CLR .NET.
    En tenant compte des moddeurs lors des changements internes, on peut obtenir une excellente API de modding pratiquement sans coût supplémentaire.

    • Tout ce dont un jeu avec énormément de mods a réellement besoin, c’est d’une base d’utilisateurs suffisamment grande. Pour des moddeurs dévoués, un peu de patch binaire ou d’injection de DLL ne constitue pas un obstacle.