Surface QRhi du jeu, composée avec le reste de l'interface QML.
Le jumeau Qt Quick de QRhiWidget
L'éditeur dessine sa scène dans un QRhiWidget ; le jeu la dessine ici. Les deux rendent dans une texture d'appui que leur hôte compose : la cible technique ne change pas — Direct3D 11 par défaut sous Windows, au travers de QRhi (EX-ARCH-050, EX-REN-002) — seul l'hôte change.
Ce qui change vraiment, et qu'il ne faut pas se cacher
QRhiWidget peint sur le fil graphique. QQuickRhiItem peint sur le fil de rendu, et c'est la seule différence qui compte. Toute donnée que la simulation produit doit donc traverser synchronize(), appelée pendant que le fil graphique est bloqué — le seul instant où les deux fils peuvent se parler sans verrou.
C'est pour cela que la composition de scène (hmi::ComposedScene, structure pure et sans GPU, EX-NFR-004/005) est exactement le bon objet de transfert : le fil graphique la remplit, synchronize() la remet, le fil de rendu la soumet. La frontière que le projet s'était donnée pour tester le rendu sans GPU sert ici une seconde fois.
Ce qu'il ne fait pas encore
Il n'affiche aucune scène : Source/Elements/Levels/ est vide par construction depuis le LOT-01, et le contenu du RPG arrive avec un lot ultérieur. Il établit la plomberie — création du QRhi, passe de rendu, couleur d'effacement — qui était le vrai risque du portage, et laisse la scène à brancher quand elle existera. Bâtir une session de jeu autour d'un niveau qui n'existe pas produirait du code que rien ne peut vérifier.
