PureBasic

Bonjour,
Je voudrai savoir s’il y’a une méthode pour faire un loadsprite sans consommer trop de Ram !

Je pose le problème pour mieux diagnostiquer la chose :
Alors j’ai 10 Images de 7000x7000 pixel , format Bmp ça donne 140 Mo , et au format PNG 642 Ko.

Charger l’image en bmp ou png ça ne change rien, car elle est automatiquement convertie lors du chargement en mémoire, et ça taille atteint les 190 Mo !

Je dois charger 10 Images du genre dans le jeu, ce qui consomme presque 2 Go de Ram !
Ce qui est trop pour 10 Images.
Comment procéder pour que l’image chargée au format PNG reste dans les 642 Ko ?!

Merci pour vos solutions…

S il y a une solution elle est surement du coté de DirectX mais j'en doute. si les images sont compressé il faut les décompresser pour les afficher. J'ose pas imaginer la perte de perf a l'affichage.

décomposer l'image en tiles serait plus logique apres il faut que cela soit possible...

Donc il faut convertir les images en un format personnel, et charger que la partie visible à chaque fois !


(j’ai réussi à diviser la taille par deux en passant en mode 16 bits au lieu de 32 )

Mytic a écrit :Donc il faut convertir les images en un format personnel, et charger que la partie visible à chaque fois !


(j’ai réussi à diviser la taille par deux en passant en mode 16 bits au lieu de 32 )

ou peut etre charger ton image , puis virer ce qui n'est pas dans l'ecran ..

ça a l'air con dis comme ça , mais le principe est different..
de ce que tu ecris

Les images représentent l’animation d’une map gigantesque, qui va bouger pendant le mouvement du personnage, et donc elle doit obligatoirement être chargée en entier
Merci pour la suggestion

je part du principe que dans tes images en 7000x7000 tu as plusieurs sprites sinon tu as beau faire ca changera rien.

donc premierement tu decoupe tes images en plein d'images de petite taille que tu sauve dans un repertoire

fichier1.png
fichier2.png
fichier3.png

etc..

donc au lieu d'avoir une grosse image en 7000x7000 tu vas avoir une multitude d'images toute petites

tu ecrit dans une liste chainée tout les noms des fichiers ainsi généres et leur (taille additionée-la taille du fichier actuel) ce qui donne la position dans le fichier en octet (a l'aide d'une structure) ainsi que leur taille

exemple

fichier1.png 1000 octets
fichier2.png 1000 octets

la liste chainée contiendra

file : fichier1.png
offset : 0
taille : 1000
file : fichier2.png
offset : 1000
taille : 1000

ensuite tu cree un fichier qui vas contenir toute tes petites images en png

par exemple 'mesprites.dat'
au debut de ce fichier tu sauve le nombre de fichier, la taille totale en octets puis le contenu de ta liste chainée

puis tu charge en memoire (pas comme une image) chaque fichier et tu sauve le contenu de la memoire a la suite du fichier 'mesprites.dat'

tu vas te retrouver a nouveau avec un gros fichier qui contiens tout tes sprites toujours au format png.

ensuite pour utiliser le fichier ainsi crée tu ouvre le fichier 'mesprite.dat'

tu lis le nombre d'entrées
tu lis la taille totale des images

tu charge la liste chainée

tu cree un buffer de la taille totale des images

tu charge en memoire le reste du fichier avec un
readdata(#file,buffer,size)

ensuite tu peux utiliser tes images en faisant un catchimage ou un catchsprite (#image,buffer+offset ,taille)

rien ne t'empeche de faire une procedure loadmemsprite(sprite,"fichier")
qui recherche le nom de fichier dans la liste chainée
puis effectue le catchprite / catchimage

juste une idée


bien sur le fait que les header png des images sont repetes pour chaque image ca risque de faire un poil plus gros que l'image originale mais a mon avis rien de comparable a l'image decompressee

Merci case , c’est vraiment une bonne idée , charger les images compressées en plusieurs morceaux , puis décompresser et afficher que les morceaux visibles.

Mytic a écrit :Merci case , c’est vraiment une bonne idée , charger les images compressées en plusieurs morceaux , puis décompresser et afficher que les morceaux visibles.

A mes début, en testant clipsprite, cela fonctionnait jusqu'à 4096 colonnes. Si tu utilise cette commande, peux tu me dire si les mises à jour récentes de PB ont réglé ce problème

Il est quand même étonnant que tu n'utilise pas les classiques techniques de tiles, ou encore que tu n'a pas testé ou, heu, anticipé la chose( j'imagine que tu ne veux pas sacrifier tes décors , ce que je comprend( chuis pas doué dans ce domaine, et j'en bave pour en concevoir: soit c'est pas raccord, soit c'est trop répétitif, dur, dur)).
Tous mes voeux de réussite, allez, courage !

Beauregard : Le defis du tilling =]
Il y a une solution simple, qui de plus supprime la problematique des heu.. bordures :

Les tiles carrés sont une plaie. Je veux dire, les tiles carrés pleins.
Fait se chevaucher des tuiles aux bords irreguliers, ça marche impec !

Evidement l'abus de transparentSprite est mauvais pour la santée du flipbuffers. Ce que je fais alors, c'est que suivant le scrooling, j'imprime mes tiles transparent sur une tuile pleine, normale elle, qui donc s'affiche à coup de displaySprite classique. =]

Ainsi le temps pour imprimer sur le buffer ecran (sscomme ça qu'on dit?) une ligne ou une colonne, d'un pavage de tuiles transparentes n'est consomé qu'à la creation du sprite. =]


Je compte toujours partager mes codes, mais j'attends qu'ils soient plus souples et propres ! ^^
(Par exemple que le processus s'adapte automatiquement à la resolution d'ecran et à la taille des tuiles tout seul comme un grand =] )



Pour en revenir au sujet, effectivement il faut contraindre son dessin aux possibilitées de l'ordi au prealable.
Tu remarqueras, que sur de petits elements tu peux te permettre d'enregistrer en 256 couleurs sans qu'on'y remarque rien =]
ça inclut eventuellement d'autres contraintes, que je galererais à expliquer "scripturalement".

Quoi qu'il en soit, tu decouvriras surement en te penchant sur le sujet, que c'est un des aspects passionnants de la mise en place d'un jeu ^^ :
les astuces liées à la rapidité de calcule :p

Bonnes recherches ^^ !

j'ai rien compris mais cela à l'air bien fortiche. Pour la transparence, j'ai opté pour le "réalisé tout en sprite3D, et avec le clipsprite3D de eddy, et pis c'est tout".

Pour la conception des tiles, j'y arrive, mais en y passant de longues heures, et pixel par pixel s'il le faut. En suant à grosses gouttes...

Les tiles n’ont un réel effet que si dans la map les objets, terrains, décors se repentent !
Mais hélas ce n’est pas le cas pour ma map , ou chaque pixel ne ressemble pas à l’autre.

Mytic a écrit :Les tiles n’ont un réel effet que si dans la map les objets, terrains, décors se repentent !
Mais hélas ce n’est pas le cas pour ma map , ou chaque pixel ne ressemble pas à l’autre.

dans le cas d'un jeu d'aventure comme monkey island, je comprend. Mais si c'est un jeu à la diablo ou zelda ou encore starcraft, faut ruser un minimum quand même( comme le tyrannosaurus*, le joueur se focalise surtout sur ce qui bouge, à savoir personnages ou vaisseaux... donc une légère répétition de ton décor est peut être envisageable( je ne connais même pas dans quelle catégorie tu classe ton oeuvre donc je suppute hein) )
*
http://www.gameblog.fr/blog_392_les-joi ... nimatronic