PureBasic

Pour ce qui est de l'utilisation mémoire, n'oublie pas que si tu dépasses la capacité mémoire de la carte vidéo, le reste est chargé en mémoire centrale, voire en utilisant le disque dur, d'où une chute des FPS (directx faisant les transferts autostupidement)

djes a écrit :Pour ce qui est de l'utilisation mémoire, n'oublie pas que si tu dépasses la capacité
mémoire de la carte vidéo, le reste est chargé en mémoire centrale, voire en utilisant le disque dur,
d'où une chute des FPS (directx faisant les transferts autostupidement)

Djes a raison sur ce point. Par contre, DX ne gère pas si stupidement la mémoire video que
cela. Quand la RAM de la carte est pleine, il faut bien mettre le reste quelque part, donc
en RAM system en général. Il existe un certains nombres de commutateurs sous DX qui permettent
de gérer au petits ognons justement ton espace mémoire destiné à la video. Par contre, dans
beaucoups de langages ils ne sont pas directement accessible, à voir si sous Blitz3D (puisqu'il
s'agit de ce langage) qui passe par DirectX7 (donc DirectDraw à l'époque pour les rendu 2D)
tu as des instructions de bas niveau pour le management de la VRAM. Il faut aussi savoir que
le fait d'avoir tes images en RAM system et non en VRAM ne ralentit pas forcement le traitement,
surtout quand tu fait des appli 2D.
Par exemple il m'arrive de travailler sur des textures procedurales, que je place en RAM
system pour des raison de rapidité d'accès, sans vraiment trop plomber pour autant le frame rate.

Après tu peux passer par des format compressé de tes images en VRAM, comme le DXT5, qui peut te faire
gagner parfois 75% d'espace en VRAM (je ne pense pas que cela soit géré par DX7 et donc par
Blitz3D), vérifie aussi que Blitz3D n'applique pas par defaut de mipmapping à tes images, ce
qui augmente pas mal leur volumes en mémoire. (mais la il faut que tu change de forum )

Sinon, une meilleurs opti de tes images pourrait etre une des solutions. Il me semble avoir lu plus
haut que tu montais jusqu'a 4096X4096 en resolution pour certaines de tes images. Une simple texture
de ce format représente à elle seule 64Mo en VRAM. A ce rytme la tu arrive en effet vite aux limites
de ton systeme. De plus si c'est pour un jeux, je suppose que tu souhaiteras qu'il puisse tourner
sur un large éventaille de machine, donc la aussi avec plus de 450Mo de media à charger, tout le
monde ne pourra pas digéré la chose comme cela. 150Mo à 200Mo parrait déjà une bonne valeur (comme
le disait Polux).

case a écrit :mon conseil ne charge que les images qui sont nécessaires pour un niveau. a mon avis tu n'utilise pas toute tes images dans le même tableau

Après avoir dormis et après reflexion, il est vrai que j'ai pas mal d'images pour l'intro, avec même mon personnage en SD( grosse tête avec petit corps) se baladant sur une carte + quelques images bien lourde que je compte remplacer par un petit dessin animé plus économe( du style game boy).
De plus j'ai une gestion d'inventaire un peu lourde aussi, que je peux charger uniquement si le joueur y fait un tour.
Bref faut que je fasse "le ménage" dans mes images, et que je sois plus prudent à l'avenir...

Polux a écrit :Pour le chargement des médias via pure, aucun souci. Lethal 4 utilise parfois jusqu'à 150Mo de Vram ( cg ) et aucun souci de ralentissement.

Jusqu'à maintenant je n'ai pas utilisé de sprite3D, donc cette mémoire n'est pas utilisé, non ? Même pour la transparence, j'utilise la vieille technique d'affichage( 1 pixel sur 2). Mais la version Pure aura la transparence, principalement pour l'eau( et petit nuage de poussière aussi).

Merci pour ta généreuse proposition, dès que mon jeu commencera à tourner avec pure, je vous ferai un état des lieux.

question: j'ai besoin que vous me rafraichissiez la mémoire: le mode fenêtré ne pose pas de problème avec pure pour l'utilisation de sprite2D et 3D par rapport au mode graphique? J'ai testé avec une anim d'un vilain de bonne taille en mode fenêtre, j'ai rajouté un gadget... et c'est finalement amusant à faire.
Et un grand merci à Dobro pour ses exemples bien commentés.

tmyke a écrit :

djes a écrit :mémoire de la carte vidéo, le reste est chargé en mémoire centrale.

Je te remercie de m'avoir donné toutes ces explications, bien précieuses.

Donc pour un jeu 2D, et avec Pure, les sprite2D sont logés dans la Ram et les sprites 3D dans la Vram, ai-je bien compris ?

Ou alors tout est logé dans la Vram, et si ça déborde, hop, le cpu, avec ses petits bras musclés, met ce qui dépasse dans la Ram ?

tmyke a écrit :Sinon, une meilleurs opti de tes images pourrait etre une des solutions. Il me semble avoir lu plus
haut que tu montais jusqu'a 4096X4096 en resolution pour certaines de tes images.

oui, j'en ai même 5 de cette taille... dont 2 concernant le monde marin, je pense que dans le même niveau, je peut libérer 2 grandes images des vilains de Terre, pour ensuite charger celles des vilains des mer... oui heu c'est possible, faut que je médite. faudra alors que je fasse gaffe pour le level design...

Bon... en étant économe et plus prudent à l'avenir, la solution de facilité serait de gonfler ma Ram, en passant de 1Go à 1Go et demi. Avec 512 Mo de plus, je suis certains de pouvoir m'exprimer pleinement. Et vu que la norme actuelle est au 2Go, 1,5 Go sous XP ou 2Go pour ce glouton de Vista, y a pas de soucis, qu'en pensez vous ?

beauregard a écrit : Donc pour un jeu 2D, et avec Pure, les sprite2D sont logés dans la Ram et les sprites 3D dans la Vram, ai-je bien compris ?

Je ne peux pas te répondre de manière cathegorique, tout dépends comment PB en interne gère les images
qui sont chargées. Mais je dirais qu'a vue de nez cela doit etre cela.

beauregard a écrit :oui, j'en ai même 5 de cette taille...

ouaa, en effet, à elles seules elles pèsent 320Mo, cela commence à faire.
Si mon calcul est juste, cela représente plus de 20.000 tiles en 64x64 pixels.
Meme si on considère qu'il y a des animations, ton environement doit etre
fichtrement riche
N'y a-t-il pas moyen de passer par une gestion de tes media (ne charger en RAM que
ceux qui sont indispensables). Je sais que ce genre de management des ressources
n'est pas toujours faciles, mais il t'épargnerais bien des soucis de mémoire, et
t'assurerais un meilleurs portage sur des machine qui ne sont pas forcement des
bêtes de concours ( du moins en RAM ou en VRAM).
Un de mes petits poratbles (très sympa au demerant) qui tourne qu'avec 512Mo de
RAM et une 9700pro de 128Mo se verais vite débordé par ton bébé

Sinon, il existe une technique, que je n'ai jamais testeé, donc je ne pourrais pas trop
t'aider, mais elle consiste à créer au lancement du jeux un disque virtuel en RAM,
d'y loader tout tes media (donc encore compressés), et ensuite tu charge à chaque
fois a partir de ce disque virtuel les elements dont tu as besoin à un instant T, puis
tu les libère tes ressource dès qui'l ne sont plus utiles, et ainsi de suite.

tmyke a écrit : [Sinon, il existe une technique, que je n'ai jamais testeé, donc je ne pourrais pas trop
t'aider, mais elle consiste à créer au lancement du jeux un disque virtuel en RAM,
d'y loader tout tes media (donc encore compressés), et ensuite tu charge à chaque
fois a partir de ce disque virtuel les elements dont tu as besoin à un instant T, puis
tu les libère tes ressource dès qui'l ne sont plus utiles, et ainsi de suite.

Exactement ce que j'utilise

ne charge l'intro que lorsque tu en a besoin, puis vide la mémoire utilisée quand tu entres dans le jeu.

de même lorsque la partie prend fin et que le joueur retourne a l'écran titre, efface les données graphiques du jeu et charge les données graphiques de l'écran titre.

pour ce qui est de la creation de tes niveaux je suppose que tu utilise un système de tuiles(tiles) que tu prend dans une image puis que tu pose a l'endroit nécessaire , tu peux liberer la memoire utilisée par l'image une fois que tu as pris tout les morceaux dont tu as besoin par exemple

je me souviens du temps ou je programmais en gfa sur atari st j'avais reflechis a une maniere d'avoir un tres grand niveau de plusieur ecrans que je pouvais faire scroller dans tout les sens. avec une ram de 512ko tu imagine qu'a l'epoque c'etait impensable de faire une tres grande image et d'afficher uniquement la partie qui nous interessait

l'astuce consistait a avoir une image plus grande que l'ecran de la taille d'une tuile de chaque cotes

disons qu'on utilise des tuiles de 32 pixel de large ton ecran etant en 1024*768 on utiliserais donc une image de 1088*832 comme buffer on dessine toute les tuiles de la zone du buffer

au depart la zone affichée réelement serais (x,y,l,h) 31,31,1024,768
si je deplace mon personnage vers la gauche de 1 pixel a chaques fois

j'affiche la zone 30,31,1024,768 - 29,31,1024,768 etc... etc... donc je ne redessine pas tout l'écran a chaque fois avec une boucle for/next sur toute la surface visible je me contente juste d'afficher la partie réellement visible lorsque j'arrive a 0,31,1024,768 je décale mon image de 32 pixel vers la droite et je dessine la ligne de tuile manquante a gauche , et j'affiche mon image a 31,31,1024,768 donc avec un tel système tu peux virtuellement avoir des niveaux énormes sans consommer trop de memoire graphique.

petit dessin explicatif


la partie foncée est en dehors de l'ecran

1 position de depart
2 je deplace vers la gauche
3 je deplace vers la gauche
4 je me suis deplacé de 32 pixel vers la gauche
5 je decal mon image de 32 pixel vers la droite ainsi que la position affichée
6 j'affiche les tiles de gauche

7 je me deplace vers la gauche

etc...

bon, j'ai fait du ménage ce soir... pour 3 images seulement, résultat en .bmp :
de 49.153 -> 28.225
de 39.937 -> 13.231
de 14.977 -> 11.701
Total= je passe de 104 Mo à 53 Mo, belle économie.
j'avais complément oublier qu'une image de 4096*4096 .bmp vide, rempli de la couleur noire par exemple, pèse 49.153 ko !!! Donc chaque espace vide laissé entre 2 images bouffe inutilement de la mémoire...
Je dois revoir mes dernières images( au moins 12, y a du boulot) et après çà ira mieux.

case a écrit :ne charge l'intro que lorsque tu en a besoin, puis vide la mémoire utilisée quand tu entres dans le jeu.

je viens de le faire et cela soulage un peu ce vieux blitz. J'ai aussi pensé au fait que lorsque mon personnage nage dans l'eau, il est inutile de tester tout les trucs concernant les, heu, les truc qui se trouve sur la terre ferme( vilain de terre et des airs, piège, plate-forme, objet à récolter...)
A+