PureBasic

Hier soir, j'ai fini une nouvelle série d'images réalisé par mes soins, avec amour. Désormais, le poids total de mes images dépasse les 50 Mo. Oui, je me suis mis dans la tête de concevoir un jeu de plate-forme en 1024*768 avec beaucoup d'étapes d'animations, un gros projet donc.

Mais en voulant intégrer ces dernières images avec un autre basic( honte à moi), j'ai rencontré le problème suivant, résumé de mon code:

Et là surprise, le fps chute à 30 images/secondes !!!

Après plusieurs tests infructueux, je constate que ce basic ne supporte pas un dépassement de 50Mo + utilisation de double boucle... et ainsi mon plan de coder mon jeu avec 2 basics tombe à l'eau.

Je n'ai pas atteind le même niveau avec PureBasic, mais j'espère ne pas rencontré le même problème de limitation à 50Mo + utilisation de double boucle...

Si quelqu'un pouvez me rassurerez, là.

Je n'ai jamais eu autant de ressources pour un projet (et pourtant, le jeu que je développe en ce moment est conséquent) donc je ne peux pas répondre précisément...
Par contre il doit etre possible de ne charger qu'une partie des images, et à chaque affichage, faire un free sur l'image courante et de charger la suivante, et ainsi de suite... non ? (peut-être que je n'ai pas bien compris le problème)

Tu as chargé (décodé) toutes les images en mémoire????????????????????

pour savoir la place que prennent tes images en mémoire sauve les en bmp et regarde la taille totale, n'oublie pas que le format png est compressé mais que cela ne permet de gagner de la place que sur le disque dur... pour ce qui est de la chute de fps cela peut etre du au fait que la mémoire vive de l'ordinateur est pleine et qu'il utilise le disque dur en mémoire swap que ce soit en blitz en pure en gfa en C++ en assembleur etc... si la memoire est pleine c'est normal que les perf se dégradent.

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

bref optimise la chose sinon je suis curieux de voir l'animation d'un des personnages de ton jeu ^^

Merci pour vos interventions.

Alors, actuellement, j'ai 83 images de tailles diverses. Les plus grandes ne dépasse pas les 4096 colonnes( il y a bien une limite à 8192, mais je me suis autolimité à 4096 pour raison pratique: mon écran wide n'est qu'un 19pouce).

ATHOW a écrit :Par contre il doit etre possible de ne charger qu'une partie des images, et à chaque affichage, faire un free sur l'image courante et de charger la suivante, et ainsi de suite... non ? (peut-être que je n'ai pas bien compris le problème)

J'y ai pensé au début, mais je me suis dis que je ne devrai pas dépasser les 100Mo. Alors avec 1Go de Ram( très courant à l'heure actuelle), et 256Mo de vram( mais là c'est du hors sujet car juste pour les sprite3D), et bien il n'y a pas de soucis, je charge tout au démarrage, et comme çà je n'embête pas le joueur avec des temps d'attentes.
Bien sûr pour les boss, je peux éventuellement libérer la mémoire de certaines images, c'est facile à faire mais j'en suis pas encore là car j'en ai encore pour plusieurs mois.

djes a écrit :Tu as chargé (décodé) toutes les images en mémoire????????????????????

oui. 50Mo, ce n'est pas excessif, si ?
Il y a aussi la conversion des images sous forme de data, peut être est ce la solution ? Si c'est le cas, il s'agit de la dernière solution, je n'ose pas imaginer le nombre de ligne de data qu'il faut pour cela Mais pas sur que çà marche. ché pas.

Avec Purebasic j'ai testé, merci à Dobro, une méthode consistant à placer les images dans l'executable. Mais encore une fois, je n'ai pas beaucoup codé depuis septembre, car tout mon temps disponible est passé dans la conception d'image, donc je n'ai pas encore appliqué cette méthode( là, c'est plutôt mon côté "artiste" qui répond, le "codeur" lui est un peu rouillé ! )

Je connais pas grand-chose à la prog de jeux, mais je suis pas sur que le fait d'intégrer tes images dans l'executable change grand chose à la conso mémoire, ni à la vitesse de chargement des images.

A vérifier quand même, mais je suis pas convaincu que ça change grand-chose à ton problème.

case a écrit :pour savoir la place que prennent tes images en mémoire sauve les en bmp et regarde la taille totale, n'oublie pas que le format png est compressé mais que cela ne permet de gagner de la place que sur le disque dur...

merci pour le conseil, je vais convertir le tout en bmp et regarder la taille totale.

case a écrit :pour ce qui est de la chute de fps cela peut etre du au fait que la mémoire vive de l'ordinateur est pleine et qu'il utilise le disque dur en mémoire swap que ce soit en blitz en pure en gfa en C++ en assembleur etc... si la memoire est pleine c'est normal que les perf se dégradent.

Non, je n'ai pas l'impression que le disque prenne le relai de la mémoire.

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

bref optimise la chose sinon je suis curieux de voir l'animation d'un des personnages de ton jeu ^^

C'est vrai, mais la plupart des images concerne le jeu en lui-même et j'ai encore du boulot donc çà va pas le faire quand même.
Seul mon frère et mes parents ont vu le jeu, si çà leur plait je continu, sinon je recommence. Ce n'est pas du pixar, mais avec toute l'umilité qui me caractérise y a des trucs que j'ai bien réussi. Ah oui, il y a aussi mon cousin de 8ans qui l'a vu, mais il n'a pas voulu me croire, bon j'ai modifié le décor vite fait et là il n'en revenait pas, mais y a que les jeux de guerres qui l'intéresse...
Pour exemple, la taille du personnage dirigé par le joueur est dans des cases de 128*128( j'ai veillé à faire gaffe aux proportions par rapport à la résolution, en étudiant les jeux les plus connus)

Chris a écrit :Je connais pas grand-chose à la prog de jeux, mais je suis pas sur que le fait d'intégrer tes images dans l'executable change grand chose à la conso mémoire, ni à la vitesse de chargement des images.

A vérifier quand même, mais je suis pas convaincu que ça change grand-chose à ton problème.

oui, je suis bien d'accord. Le problème ne se pose pas avec PureBasic, pas encore.
Bon, de mon côté je vais lâcher "mes pinceaux" à regrêt, pour tester la chose, avec fébrilité...

pour info une image en 1024*768 en 32 bits elle pese 3 mo

(1024*768*4)/1024

L x H x octets / 1ko

reste a voir combien de pixels tu as dans toute tes images

j'ai pas tout saisi de ton problème,
enfin , de ce que j'ai compris , tu fait un jeu de plateforme , donc , un jeu a base de tile ? ( tuilles )

While steptileY<(NUM_Y_TILES)
While steptileX<(NUM_X_TILES)

Wend
Wend

se genre de boucle plus que simplet , bouffe énormément de temps cpu. car dans cette situation , tu affiches même se qui est en dehors de l'écran , donc forcement , tu obtiens une chute vertigineuse du frame rate...
si tu gère le scrooling est que tes tiles font 64x64 pixel et que tu as une résolution de 1024x768 tu sais donc que tu ne peut pas affiché plus de 16 tuiles en x et 12 en y (1024/64 , 768/64) a toi ensuite , via un calcul en fonction de la position du scrolling de savoir quel tuille affiché.

et si ton autre basic se nomme Darkbrouzook , tu peut stoppé ton projet , même avec le meilleur code qui soit , le code générer est beaucoup trop lourd.

++

Bon, après un peu de ménage, j'ai un total de 83 images, le tout convertis en .bmp pesant 471 Mo. Avec winXP qui bouffe je sais plus combien, je pense quand même que je n'ai pas remplis les 1Go de ram. Le basic en question commence par bli et se termine en basic3D, avec un tz au milieu.

Cpl.Bator a écrit :j'ai pas tout saisi de ton problème,
enfin , de ce que j'ai compris , tu fait un jeu de plateforme , donc , un jeu a base de tile ? ( tuilles )

oui, j'ai même laissé un code de de l'editeur que j'utilise, pas complet mais bon:
http://www.purebasic.fr/french/viewtopi ... 48&start=0

Cpl.Bator a écrit : se genre de boucle plus que simplet , bouffe énormément de temps cpu. car dans cette situation , tu affiches même se qui est en dehors de l'écran , donc forcement , tu obtiens une chute vertigineuse du frame rate...
si tu gère le scrooling est que tes tiles font 64x64 pixel et que tu as une résolution de 1024x768 tu sais donc que tu ne peut pas affiché plus de 16 tuiles en x et 12 en y (1024/64 , 768/64) a toi ensuite , via un calcul en fonction de la position du scrolling de savoir quel tuille affiché.

oui 16*12 c'est exact... pour ce qui est de l'editeur.

Car dans mon jeu, pour éviter que les vilains disparaissent brutalement, ou pour utiliser un seul tile ou lieu de deux pour l'affichage d'une plate-forme mouvante par exemple, ou encore un objet très grand de 384 pixels de haut par exemple, ben j'ai agrandis progressivement au cours du développement... et donc je suis passé de 16*12 à 48*36.

Pour le 2ème et 3ème plan, je reste à 16*12. Donc en fait il y a 3 doubles boucles de ce style, la 1ère étant problablement la plus gourmande, mais cela n'a pas, ou presque*, posé problème.... jusqu'au dépassement des 50Mo de ram( ~450Mo en .bmp, certaines images n'ayant pas encore était intégré, c'est un peu le bordel la dedans)

*je dis presque parce qu'il faut éviter d'utilier les signes < ou > à l'intérieur d'une double boucle du code source du jeu, je n'ai jamais compris pourquoi, mais on peut s'en passer, alors...

Cpl.Bator a écrit : se genre de boucle plus que simplet , bouffe énormément de temps cpu. car dans cette situation , tu affiches même se qui est en dehors de l'écran , donc forcement , tu obtiens une chute vertigineuse du frame rate...

heu..., attend mon 1er plan affiche l'équivalent de 9 écrans
16*3=48
12*3=36
48*36
donc si un vilain se déplace hors de ce 48*36
Si Xvilain> 1024+(1024-32 ou 64 je sais plus), alors la variable de contact sol du vilain est à 0, et ce vilain tombe dans le vide( pour éviter cela, il faut le mettre en sommeil dès qu'il arrive à proximité de la frontière de ce 48*36).

Donc non, ce qui est en dehors de l'écran d'une taille de 48*36 ne s'affiche pas. Si c'était le cas, la programmation serait moins complexe.

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

L'idéal etant d'affecter une place à tes sprites et de les charger dynamiquement suivant les niveaux en remplaçant ceux qui ne servent plus ( c'est ma technique pour mes différents jeux ). Cela évite de surcharger la mémoire ( faut penser à ceux qui ont des cg avec peu de mémoire ) et permet de gagner en efficacité. Il vaut mieux éviter de charger les médias avec l'exe, c'est pas très propre...ni fonctionnel.

Par contre, tu devrais revoir ta boucle pour l'affichage des tiles. L'optimisation doit se faire ici.
Le principe, c'est de ne calculer que ce qui est nécéssaire et également, si possible, de n'afficher que ce qui est nécessaire.
Two affiche l'équivalent d'une quinzaine d'écran de 1024x768, rempli d'effets en tout genres, d'enemis animés, tourrelles, ect... et il faut vraiment charger pour que ça rame ( et encore, depuis j'ai amélioré le code et je pense avoir pas mal gagné en rapidité ).
Je tacherais de poster une partie du code source pour t'aider si tu as besoin.

+1 pour Cpl: si c'est DBP que tu utilise, oublie tout de suite... ou revois tes ambitions à la baisse...