On est une petite équipe et on va réaliser un jeu et moi je vais m'occuper de la programmation du moteur 3d en dx8.
 
Mais avant tout, j'aimerai savoir quel est le meilleur format de texture, .bmp, .jpg, .tga ?
 
Je ne compte pas utiliser la compression DXT et de plus j'ai remarqué qu'en ressource mémoire, les .jpg étaient beaucoup moins lourdes que les .bmp (donc + avantageuses)
Mais j'aimerai savoir comment sont gérées les différentes compressions d'images au niveau du cpu/gpu.
J'aimerai savoir si selon les compressions (.bmp ou .jpg), une de celle-ci est plus avantageuse à gérer en terme ressources cpu/gpu.
 
Je sais que pour les transformations, le cpu ou gpu (selon les machines) travaillera sur les données de l'image (donc + celle-ci est petite en poids, mieux cela sera pour les calculs de matrices, donc avantage au .jpg) mais pour le rendu, selon les differentes compressions, y en a t-il une + économique en temps machine que l'autre ou est-ce que cela n'a aucune influence ?
 
Merci de me renseigner, cela m'aiderai bien à faire un choix.

que ton image soit une jpeg, une bmp, une tga, une png n'a absolument aucune influence sur d3d. au final, elle prendra toujours la même place sur le gpu : largeur x hauteur x 2 ou 4 bytes (16 ou 32b). le format n'a aucune influence sur le temps de rendu ou le 'calcul de matrices' qui n'est d'ailleurs effectué que sur les vertices. ce qui influence la vitesse du rendu, c'est la taille de la texture, la profondeur de couleur (16/32b), et le rendu d'alpha par pixel.
 
d'où l'intérêt d'utiliser les textures compressées, qui cette fois ci prennent ET moins de place sur la carte ET sont plus rapides au rendu.

oui mais une jpeg par exemple a un format de compression propre, et pour la rendre sur un objet, d3d va utiliser une routine différente de celle utilisée par une bmp.
Ainsi, je ne suis pas sûr que le format n'est aucune influence pour d3d.
 
J'aimerai savoir lequel des formats est traité le + efficacement par d3d, indépendemment du poids de la texture.
Sachant que les format de compressions sont différents, les routines de gestion par d3d de ces formats vont bien être différentes, non ?
Si c'est le cas, certaines doivent être + efficaces que d'autres mais cela est invisible pour tout utilisateur de d3d.

tu crois que d3d, enfin plutôt la carte graphique, a en rom tous les algos de décompression d'image ? et que toutes les cartes du monde entier ont toutes les algos pour décompresser du jpeg, du png, ... en RUNTIME ?
 
bon, va lire la doc ...

pas la carte graphique, mais d3d doit bien le gérer quoi qu'il en soit.
 
Elle ne s'affiche pas toute seule par magie l'image, il faut bien la décoder selon son format.

T'as l'air faché youdont    ??? Pourtant c pas si idiot ce qui dit le monsieur?
 
Moi je dis ça j'y connait 0+ 0 = tete a toto mais le topic m'interessait

Je m'y connais pas trop en direct3D (et en directX tout court dailleurs), mais je pense que si tu mets tes textures en jpg, ça risque de ralentir le tout, car le CPU devra décompresser l'image avant de pouvoir l'envoyer au gpu alors qu'avec une image bmp, il n'y a pas besoin de décompression.

ouai mais si tu fait un jeu avec que des images bmp sa va prendre de la place

choisi le format en fonction de la taile / qualite que tu veux avior.
le chargement serait peut etre un peu + len (et encore...) avec une image compresser.

...
 
sans la compression de textures (dxtc) : pour qu'une carte 3d puisse afficher une texture, il faut qu'elle soit dans sa mémoire à elle, totalement décompressée (un gros bloc linéaire). ie une image 256x256x32b, qui prend 47k en jpeg, prendra 256x256x4 = 256k de mémoire sur la carte.
 
en utilisant dxtc, ça prendra (sur la mem de la carte) ... moins.
 
quant au chargement : non ce n'est pas de la magie, c'est ton code à toi qui charge l'image et la décompresse. ensuite, création d'une surface directx de la même taille que la texture (en puissance de deux la taille de la texture d'ailleurs), lock de la surface, blit de la zone mémoire de l'image décompressée vers la zone mémoire de la texture. puis unlock de la surface. et hop.
 
et y'a des fonctions d3dx qui s'occupent de faire le bloc précédent.

Je le sais, j'utilse par exemple la fonction
 
HRESULT D3DXCreateTextureFromFileA(
  LPDIRECT3DDEVICE8 pDevice,
  LPCSTR pSrcFile,
  LPDIRECT3DTEXTURE8* ppTexture
)
 
qui prend en charge automatiquement le chargement de tout type de texture.
On peut aussi coder la facon de décompresser nos textures mais c'est simplement pour les textures compresser par le dxtc.
En fait, j'aimerai savoir le fonctionnement interne de cette fonction.

c'est ce que je dis dans mon message précédent ...