Que pensez vous de ma réflection ? Ha, et ce qui semble confirmer ma réflection, c'est cela :
http://www.youtube.com/watch?v=kRWRskYLdno&eurl=http%3A%2F%2Fwww.pcgameshardware.com%2Faid%2C687527%2FCryengine-2-vs-Cryengine-3-or-PC-vs-consoles-Video-comparison%2FNews%2F&feature=player_embedded
Crysis is a very heavy game. A simple grass texture is 1024 x1024 and about 3Mb, so it easy to overload the Vram of a PS3 or 360 which are 256MbVram.
Traduction, Crysis est un jeu très lourd. La simple texture de l'herbe est de 1024x1024 et donc environs 3 Méga octets. Donc c'est facile de dépasser la capacité de la PS3 ou de la 360 qui n'ont que 256Méga Octets.



Résumé de ce qui nous interesse : 1024x1024 pixel = 3Mb=3Mo

Tentative d'explication ?
1024x1024=1 048 576 pixel

Mais "pixel" est en faite incorrect, puisque en réalité, un pixel est sensé être une composante de couleur (RVB = Rouge Vert Bleu = RGB = Red Green Blue) (un pixel est en réalité soit un pixel rouge, soit un pixel vert, soit un pixel bleu en sachant que les 3 peuvent donner une couleur 24bits=3pxl*8bit). Nous avons donc 3x1.048.576=3.145.728 valeur à stocké ayant chaqu'une d'elle 255 intensité possible (1 octet = 8 bit= 1 byte)

3.145.728 (un tier de R un tier de V un tier de B) à stocker coutant chaqu'une d'elle 1 octet = 1 bytes...

D'où une texture de 1024x1024 pixel (chaqu'un RVB) environs égal à 3Mb=3Mo




Je ne sais pas si c'est correct, mais d'après mes moyennes connaissances, ça m'a l'air sacrément correct.

Les PC que vous avez à l'heur actuelles ont probablement tous au moins entre 32mo et 512mo de Vidéoram (certaines carte graphique ont même 2Go, voir 2Go en copie par carte dans le cas de mise en parallèle de plusieurs cartes), bref, on pourrait stocker des textures énormes en mémoire sans avoir peur de saturer ???


Je me permets de vous prévenir que d'après des testes assez simple que j'avais réalisé il y a un peu plus d'un an, un background ou un sprite ne peut pas dépasser 1600 ni en horizontal ni en vertical, ce qui signifie que le max est 1600x1600 par ressource. (1601x50 ne marchera pas, cependant, vous pouvez enregistrer des textures de 1600x1600 beaucoup de fois).





J'attends vos commentaires avec impatience, ceci serait une éxcélente nouvelle, cela veut dire qu'en faite, les limites de textures stockable sont gigantesques et cela me serait vraiment pratique pour mon optimisation de lumière de M@d_Doc et pour mon optimisation de lumière de Bast (qui s'optimisent en enregistrant les résultats des lumières statiques dans une surfaces (les surfaces de GM étant officiellement stockées dans la Vidéoram)).

Moi je me suis toujours demandé si on dépasse la vram il y a t-il un système qui met nos textures dans la ram à la place sinon c'est compliqué personne a la même carte graphique

Le PC "swapp" la ram dans le disque dur quand la ram est saturée.
En ce qui concerne la Vram, je sais que sur PC, avant, il y avait le "turbo cache" qui permettait de piocher dans la Ram pour s'en servir comme Vram (perte de gain, mais moindre que ce que ça devrait).

En ce qui concerne GameMaker, j'ai l'impression que si ta pas assez de Vram et que tu déclares un nouvelle espace qu'il ne peut pas te donner, il se contente de ne pas te l'accepter et quand tu veux t'en servir après, il te dit "surface inéxistante", normal puisqu'il a refusé de la crée puisqu'il y en avait pas de libre... Enfin, il me semble, je ne suis pas du tout sûr. Il faudrait vérifier (ça remonte à loin que j'avais vérifier cela) ...
M'enfin, dans les jeux vidéo, je pense que la carte graphique sait pompée et envoyer en Ram si manque de Vram. Juste que tes performances (nombre d'image par secondes) ont tendance à chuter dramatiquement, genre divisée par deux d'un coup, donc si tu sais que tu en as pas assez, vos mieux ne pas dépasser parce que ça tue les perfs.

Je pense que tes calculs sont faux, parce que : la texture en 1024*1024 fait effectivement 3 Mo sur le disque dur, MAIS tu ne sais pas combien elle pèse une fois dans la Vram (c'est un peu comme si tu disais qu'un .exe qui pèse 2 Mo prendra forcément 2 Mo de RAM, ce qui n'est absolument pas le cas), et si elle est ou non compressée en Vram.

Ensuite, il me semble que les PCs peuvent swapper les textures dans la RAM, explication :

J'avais un PC qui avait 4 Mo de Vram, je pouvais pas mettre de textures en 1024*1024, seules les textures en 512*512 passaient (et en configurant l'écran en 16 bpp), mais je pouvais mettre bien plus de 4 textures en 512*512 (4 textures en 512*512 donnent théoriquement la même chose qu'une texture en 1024*1024).
Bien sûr ce n'est qu'une hypothèse, car peut-être qu'en fait une texture en 1024*1024 est plus lourde en Vram que 4 textures en 512*512.

la cg de la 360 c'es pas 512?
sinon je dirais que l'image est garder en tampon dnas la carte comme un image dnas l'oeuil
si certain truc sont plus gros que le capteur visuel(CG ou oeil) ils sont pas afficher
et comme une CG utilise pas le m^me principe qu'un oeuil il peux simplement pas l'afficher
moyen de défaire cette limite= plus grande CG
ou pas

mouai... je doute qu'il faille de l'alpha sur une texture d'herbe quand m^me

WarGamer :
D'après ceux qui parlent de Crysis, la PS3 et la 360 ont une 256Mo, mais tet qu'ils se gourent, je n'ai pas vérifier et ça ne m'interesse pas (cela voudrait juste dire que sur 360, Crysis pourrait avoir enfin des textures plus fines).

Nicoulas :
Sauf que dans le cas de Crysis, la texture de l'herbe plaquée sur le sol n'a pas intérêt à être transparent, donc pas de canal Alpha. Mais c'est vrais qu'avec un Canal Alpha, la logique aurait voulu que du 32bit en 1024x1024pxl fasse 4Mo.
Deplus, avant les textures étaient compressées, mais ça coutait dans les perfs, maintenant, généralement, je pense qu'elles ne le sont plus, et qu'elles vont grâce à DirectX11 et aux Méga textures réapparaître (compressé quasi sans perte de qualité ni de perfs...).
Bref, je pense que dans le cas de Crysis, les textures ne sont pas compressées. Et je ne parlais pas du poids sur le Disque Dur, mais dans la Vram. Car des textures non compressées dans la Vram sont me semble t'il sous une forme très proche du bitmap (3 paquets de 8 bits, chaque paquet pour une composante de couleur (R ou V ou B) et donc intensité entre 0 et 255 pour chaque paquet).



Et oui, les PC peuvent swapper dans certains cas (virtualisée une Mémoire dans une autre), sinon, dans certains jeux, on ne devrait pas pouvoir monter les graphismes à fond sans planter si on est en manque de Vram (alors qu'on peut, mais ça coute très très chèr sur les perfs). Et ton exemple me semble excélent pour l'illustrer, mais dans le cas de GameMaker, je ne suis pas convaincu que ça puisse swapper la Vram dans la Ram (il faudrait faire le teste avec un PC moins puissant que le miens... parce que mes 256mo de Vram risquent d'être dur à démonter XD).


Nicoulas, j'attends ta réponse ^^

Je ne sais pas... d'après moi, une texture a un canal alpha, qu'il soit utilisé ou non, mais bon, tout dépend du format des textures, une fois de plus.
Prenons par exemple le moteur source, qui stocke (dans les vtf et vmt) dans le fichier la texture elle même (R,G,B), un EVENTUEL canal alpha (donc c'est optionnel), des données sur le matériaux, les données du bump map, et j'en passe et des meilleures...
Et la plupart de ces données se retrouvent dans la vram : bah oui, un layer de rouge, un vert, un bleu, un alpha, un bump map, etc, etc...
Je ne sais pas comment marche le cry engine, mais il ne faut pas oublier toutes ces données des textures que la CG doit absolument prendre en compte... ce qui finit par monter le poids des textures au delà de tes estimations, d'après moi.
(et remplir la vram de textures, c'est là aussi théorique... il y a aussi les shaders, modèles divers, masks, etc. qui sont loadés en permanence dans la vram)

Bref, c'est mon point de vue, en pur n00b du hardware :p (enfin presque)

J'avais pensé au bumpmap ect...
Mais je pense que quand il dit qu'une texture d'herbe prend 3Mo, c'est juste la texture en RVB, sans le reste. Après, je me doutais que quelqu'un allait me coincer la dessus. ^^
Mais avec 3Mo en non compressé, je ne pense pas qu'il y ait autre chose de pris en compte (comme le bumpmap), avec Bumpmap, ça doit faire plus, à moins que la texture soit compressée et que du coup, le bumpmap tienne dedans, mais pour une question de performance, je ne pense pas que les textures soient compressées donc si mon calcul est juste, 3Mo, c'est juste la texture RVB.


J'attends d'autres remarques pertinentes encore, je ne sais pas lesquelles, l'alpha et le bumpmapping, c'étaient tout ce à quoi je m'attendais.

Si il y a un pro dans le domaine qui pouvait enfin nous affirmer la solution, ce serait sympa XD

L'exemple que je donnais avec la texture en 1024*1024 et les 4 textures en 512*512 était avec GM.

Sinon pour compléter la liste des trucs qui utilisent la Vram (hormis shaders, etc), tout simplement l'initialisation (et le maintient) de la 3D en utilise plusieurs mégas.

Je pense quand même que 3 Mo de Vram pour une texture 1024*1024 c'est assez peu, je me demande si c'est aussi simple qu'un canal RGB

EDIT : non c'est bien 3 Mo, mais sans les mipmaps, mais je connais pas bien Crysis, je sais pas si le filtrage des textures peut se faire en trilinéaire.

je crois que c'est comme ça qu'on affiche les sprite dans les vielles consoles non ? plusieurs carreaux de 8/16 pixels pour afficher un sprite

Les vielles consoles utilisaient juste des tiles set minuscules et chaque couleur prenait moins de bit donc au final, ça prenait bien moins de place. Et c'était suffisant pour tout le jeu.

SHM : ba 256de Vram, ce n'est pas faible non plus, le soucis, c'est juste que Crysis map avec de nouvelles textures un peu partout donc au final...
Mais je sais que par exemple, Crysis en very high en 1920x1200 avec antialiasingX8, ça pompe dans les 650Mo au moins. Donc il faut laisser un peu de marge pour ne pas risquer la chute fatigue de baisse de perfs et ça nous fait comprendre que dans ce genre de cas 1Go de ram, c'est ce qu'il faut et 2Go, c'est un peu de la foutaise à l'heur actuelle.

Moi j'ai lu quelque part que travailler en 24bits était moins performant que travailler en 32bits c'est pour ca que je pense que la texture d'herbe est sur du 32bits. M'enfin je dis ce que je pense sans trop le savoir vraiment. Mais dans ma tête mélanger du 24bits et du 32bits en temps réel ca coute cher en performance à cause des conversions de 24 à 32 bits ou de 32 à 24 bits récurrentes...

aucune idée, mais c'est possible, je demanderais à Bubu si la conversion se fait au niveau de la carte graphique ou de la puce VGA sur les écrans.
(Mon binhomme en GEII, je comprenais rien à la programmation des ship VGA, lui si, et était tet le seul XD), tet que maintenant, TheDarkTiger peut se douter lui aussi de la réponse (comme il a le même diplôme maintenant) ...



Au sujet du débat sur le swappage ou pas de la mémoire vidéo de GM dans la ram ou pas, je suis tombé sur ça (coup de peau, je regardais l'aide pour les bend mode et non pour ça)


La texture choisie peut ne pas être actuellement en mémoire vidéo. Le système la chargera alors pour vous en cas de besoin mais parfois, vous souhaiterez le faire par vous-même. Pour cela, il existe les fonctions suivantes :

texture_preload(texid) Charge immédiatement la texture en mémoire vidéo.
texture_set_priority(texid,prio) S'il y a trop peu de mémoire vidéo, certaines textures seront temporairement retirées de la mémoire afin de libérer de la place pour permettre le chargement des textures nécessaires. Les textures de priorité la plus basse seront supprimées en premier lieu. Par défaut, toutes les textures possédent la priorité 0 mais il vous est possible de changer cette priorité à l'aide de cette commande (n'utilisez que des valeurs positives !)

Donc oui, GM peut virtualiser la mémoire vidéo des surfaces dans la ram si elle sature.



Maintenant retournons au débat taille des surfaces dans GM = combien de Mo de la VideoRam ?
Réponse que j'ai essayé de démontrer dans le premier post : 1MégaPixel (1000x1000pxl) =3Mo et sans doute 4 avec le canal alpha de GM8.

Des réactions ?


EDIT : codave : si sur GM7, c'est en 24 bits, c'est que c'est probablement stoké en 24bits et converti ensuite, bien que pas sûr !?

Je peux faire du 2047*2047 maximum avec mes 64 mo de Vram.
Lorsque je tente du 2048*2048, ça doit rentrer dans la Vram (la surface est bien créée), mais l'affichage de la surface est impossible.
Au delà, la surface n'est pas créée.

Je te laisse faire tes calculs (pas le temps là). ^^

Je l'ai dis plus haut ^^
D'après mes testes réalisés il y a un bail, tu ne peux pas dépasser 1600pxl en longueur ou en largeur.

1600x1600 ça passe, mais 1000x1601 ne passera pas (tu peux le faire en plusieurs textures mais pas en une seule)