1

yop,

Excusez-moi d'oser poster dans cette rubrique, mais loin d'OpenGL ou de DirectX comme le propose le sous-titre de cette catégorie, je vais tout simplement parler de SDL2.

Pour référence, l'ensemble de la doc est disponible ici : https://wiki.libsdl.org/APIByCategory

Pour ceux qui connaitraient SDL première version, on n'utilise plus de Surfaces dans SDL2, mais directement des Textures, ce qui semble bien plus approprié aux hardwares modernes, et permet quelques trucs sympas comme le stretching ou la rotation quand on copie une Texture sur une autre.

Mon problème (on y vient !) : je ne comprends pas pourquoi il faut, dans certaines fonctions, passer un Renderer en argument, alors qu'on en est pas encore à écrire la Texture quelque part, et qu'on pourra l'écrire où l'on voudra, quelque soit le Renderer pass à l'origine.

Voici comment sont structurées les données SDL d'un programme :
SDL_Window -> une fenêtre dans le WM
SDL_Renderer -> le renderer de la fenêtre en question

On copie dans ce renderer tout ce qu'on veut de textures via RenderCopy
Mais alors, si on donne le renderer à utiliser lors de la copie, pourquoi par exemple, à la création de la texture, doit-on spécifier un renderer ?

Et il y a ainsi quelques fonctions comme ça, où il faut passer un resnderer, sans que je comprenne à quoi il serve. A l'époque de SDL1, tant qu'on copiait pas une Surface sur un renderer, on avait pas de pseudo-destination à spécifier,..

Merci d'avance pour vos éclaircissations. smile

2

Je suppose que ce qu'ils appellent renderer est l'équivalent du "Device" en Direct3D, ou du contexte en OpenGL…
Si tu lis la doc, y'a marqué:
SDL_CreateTexture:Returns a pointer to the created texture or 0 if no rendering context was active, the format was unsupported, or the width or height were out of range; call SDL_GetError() for more information.

De fait, je pense aussi que leur API est mal fichu (ce qui m'étonne pas le moins du monde…), ou alors que leur doc est très merdique (les deux pouvant être vrais simultanément), mais ça, je vais te dire, c'est pas mon problème grin

(Et flemme d'aller lire leur code pour voir ce qu'il y a marqué. tongue)

En toute logique, ils ont voulu plus caler sur la terminologie que tu vas trouver, sur les API modernes, et essayer de s'harmoniser sur la gestion des ressources (à la façon d'un wrapper): Une texture est composée de une ou plusieurs surfaces (pour les mip maps), et forcément liée à la création avec un contexte. En conséquence, quand tu crées ta texture, tu as la possibilité qu'elle soit directement placée en mémoire vidéo plutôt que créée en mémoire physique et transférée par la suite. Logiquement, les appels de SDL devraient déléguer le boulot à OpenGL ou Direct3D, donc ça devrait marcher.

Après, ils disent pas ce qui se passent si tu essayes d'utiliser une texture avec un "Renderer" autre que celui que tu as utilisé pour la créer. En toute logique, ça devrait planter, mais ils ont peut-être écrit du code spécialement pour gérer ce cas… ^^
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes