Salut à tous,
Je suis nouveau, je viens d'apprendre que Purebasic est mon langage, qui me permettera de developper rapidement et efficacement des applications comme des jeux, pourtant je cherche une possibilité qui va me permettre d'eviter de coder une partie compliqué de mon projet de jeu:
- Est ce possible de charger une image, un effet sonnore, ou meme un objet 3d directement à partir de la RAM, en supposant que ces objets sont préalablement chargés sur une zone Memory? Et merci d'avance.
Charger des fichiers à partir de la RAM
pour les sprites, les images, les sons , regarde les commandes CatchSprite() CatchImage() etc, pour la 3D ce n'est pas possible à ma connaissance ?
Ceci dit , je ne vois pas en quoi ça va te simplifier la vie ?
Un LoadSprite() , LoadImage() etc , auront le même effet, tu auras autant de code à créer pour ton jeu.
La différence c'est qu'avec IncludeBinary tu inclues les médias dans l'exe.
[EDIT]
Oups CatchSprite() ne charge pas à partir de la RAM .... mais du binaire !
Donc utilise LoadSprite() , ça fera l'affaire
Code : Tout sélectionner
CatchImage(0, ?Logo)
End
DataSection
Logo: IncludeBinary "Logo.bmp"
EndDataSectionUn LoadSprite() , LoadImage() etc , auront le même effet, tu auras autant de code à créer pour ton jeu.
La différence c'est qu'avec IncludeBinary tu inclues les médias dans l'exe.
[EDIT]
Oups CatchSprite() ne charge pas à partir de la RAM .... mais du binaire !
Donc utilise LoadSprite() , ça fera l'affaire
http://purebasic.developpez.com/
Je ne réponds à aucune question technique en PV, utilisez le forum, il est fait pour ça, et la réponse peut profiter à tous.
Je ne réponds à aucune question technique en PV, utilisez le forum, il est fait pour ça, et la réponse peut profiter à tous.
Merci comtois pour ta solution, elle peut servire, mais je crois qu'il manque du detail à mes besions:
- Ce que je sais c'est que les images (dans le cas de loadimage) occupent plus de memoire dans la RAM ou VRAM une fois chargé, mon projet de jeu gère un ensemle d'image qui depasse les 1400 par personnage ( taille 256x256px), et j'ai remanqué qu'on chargeant ces images à partir d'un seul fichier, qui englobe le tout, occupe moins de place et ne prend que 5sec, alors que ça prend une minute si je charge chaque image séparée et imagine la taille qui vont occuper.
- j'ai déja utilisé loadimage et freeimage, mais imagine le fps du jeu qui doit attendre qu'a chaque fois le disque dure charge ses images.
- un autre detail qui me manque à propos de catchimage, tu as dit que ça se charge à partir du binary, le binary se trouve où, HDD ou RAM? je suppose qu'il doit etre chargé avec l'exe dans la RAM non?
- Ce que je sais c'est que les images (dans le cas de loadimage) occupent plus de memoire dans la RAM ou VRAM une fois chargé, mon projet de jeu gère un ensemle d'image qui depasse les 1400 par personnage ( taille 256x256px), et j'ai remanqué qu'on chargeant ces images à partir d'un seul fichier, qui englobe le tout, occupe moins de place et ne prend que 5sec, alors que ça prend une minute si je charge chaque image séparée et imagine la taille qui vont occuper.
- j'ai déja utilisé loadimage et freeimage, mais imagine le fps du jeu qui doit attendre qu'a chaque fois le disque dure charge ses images.
- un autre detail qui me manque à propos de catchimage, tu as dit que ça se charge à partir du binary, le binary se trouve où, HDD ou RAM? je suppose qu'il doit etre chargé avec l'exe dans la RAM non?
-
Anonyme
Bonjour et bienvenu(e) , je ne pense pas que le fait d'inclure les images dans l'executable joue sur le fps , ou le temps de chargement.
il y a plusieurs désaventage pour un gros projet de faire de cette manière (d'inclure les médias)
- Exe sont très gros en taille , dans ton cas, prennons exemple des 1400 images en 256x256 , cela te fait en Mo = (((256x256x4) * 1400) / 1024) / 1024 = 350 Mo
- tu sortiras donc des corréctifs à 350 mo minimum pour le moindre bug
@++
il y a plusieurs désaventage pour un gros projet de faire de cette manière (d'inclure les médias)
- Exe sont très gros en taille , dans ton cas, prennons exemple des 1400 images en 256x256 , cela te fait en Mo = (((256x256x4) * 1400) / 1024) / 1024 = 350 Mo
- tu sortiras donc des corréctifs à 350 mo minimum pour le moindre bug
@++
une image en mémoire suivant la résolution le nombre de bit par pixel occupe généralement plus ou autant de place que sur le disque la raison est simple, sur disque ton image est compressée pour tenir moins de place.
mais pour ton jeu, ton image tu vas obligatoirement la décompressée pour l'utiliser et donc elle reprendra sa place non compressée donc si tu charge toute tes ressources en un seul bloc en mémoire tu vas te retrouver avec ta mémoire occupée par
ton gros fichier qui contiens tout
+
tes images décompressée que tu utilise
en chargeant depuis le disque tu n'aura que les images décompressées qui prendrons de la place en mémoire.
donc a mon avis c'est mieux de charger depuis le disque.
après tout dépend aussi du type de jeu dans lequel tu te lances.
mais pour ton jeu, ton image tu vas obligatoirement la décompressée pour l'utiliser et donc elle reprendra sa place non compressée donc si tu charge toute tes ressources en un seul bloc en mémoire tu vas te retrouver avec ta mémoire occupée par
ton gros fichier qui contiens tout
+
tes images décompressée que tu utilise
en chargeant depuis le disque tu n'aura que les images décompressées qui prendrons de la place en mémoire.
donc a mon avis c'est mieux de charger depuis le disque.
après tout dépend aussi du type de jeu dans lequel tu te lances.
Tu es sûr que tu as besoin de tout ça en même temps ? tu peux peut-être charger tes images au fur et à mesure du besoin ?mon projet de jeu gère un ensemble d'image qui dépasse les 1400 par personnage ( taille 256x256px)
Tu peux en dire plus sur ton projet ?
Sinon tu peux charger un sprite en mémoire RAM , il suffit d'utiliser le mode #PB_Sprite_Memory avec la fonction LoadSprite().
http://purebasic.developpez.com/
Je ne réponds à aucune question technique en PV, utilisez le forum, il est fait pour ça, et la réponse peut profiter à tous.
Je ne réponds à aucune question technique en PV, utilisez le forum, il est fait pour ça, et la réponse peut profiter à tous.
Merci à tous pour vos explication, et pour mieux s'entendre je vais vous donner une idée de mon projet, c'est un jeux de combat, les sprites sont des rendu 3d, la qualité d'animation des mouvement exige que chaque mouvement possède un grand nombre de frames, de plus je prévois un slowmotion pour certains coups spéciaux.
J'ai déja entamé une procedure compliqué pour packer les images ou sprites dans la ram, les sprites sont indexés sur 8bits et sont liés à des palettes, alors la lecture se fera par code et s'ecrit directement via le pointeur sur l'image, mais cette procedure est limitée pour un simple usage, alors que j'envisage l'utiliser dans tout mon projet, raison pour laquelle je cherche une alternative.
Pour ceux passionné par les jeux de baston, mon projet vise à creer un Fighting maker ( Mugen like), et j'essai de reproduire un format comme le .sff ( qui engloble palettes et sprites .pcx avec leurs coordonnées x,y)
statistiques: un pack de 1400x256x256x8bits occupe 3,5Mo, aulieu de 350, de plus le temps de chargement est estimé à 5sec au lieu de quelques minutes
J'ai déja entamé une procedure compliqué pour packer les images ou sprites dans la ram, les sprites sont indexés sur 8bits et sont liés à des palettes, alors la lecture se fera par code et s'ecrit directement via le pointeur sur l'image, mais cette procedure est limitée pour un simple usage, alors que j'envisage l'utiliser dans tout mon projet, raison pour laquelle je cherche une alternative.
Pour ceux passionné par les jeux de baston, mon projet vise à creer un Fighting maker ( Mugen like), et j'essai de reproduire un format comme le .sff ( qui engloble palettes et sprites .pcx avec leurs coordonnées x,y)
statistiques: un pack de 1400x256x256x8bits occupe 3,5Mo, aulieu de 350, de plus le temps de chargement est estimé à 5sec au lieu de quelques minutes
quel que soit le type de jeu, ne charger que ce dont on a besoin en ram reste toujours la méthode la plus efficace. Et même pour un pong, bien coder ne fait jamais de mal. (remarquons que je ne suis pas forcement le mieux placé pour dire ca)
Après, en 8 bits, on a: 1400*256² / 1024² = 87,5 mo. C'est vrai que c'est ridicule dans la ram face aux machines de nos jours, mais ca rend l'executable énorme. Dans mon cas, à la vision d'un executable de plusieurs mega octets, je prend la fuite.
Qui plus est, si c'est un clône de mugen, a quoi bon avoir des datas dans l'executable?
Bref, je reste perplexe.
Par contre, si tu partage ton code pour les palettes, ca m'interresse.
Après, en 8 bits, on a: 1400*256² / 1024² = 87,5 mo. C'est vrai que c'est ridicule dans la ram face aux machines de nos jours, mais ca rend l'executable énorme. Dans mon cas, à la vision d'un executable de plusieurs mega octets, je prend la fuite.
Qui plus est, si c'est un clône de mugen, a quoi bon avoir des datas dans l'executable?
Bref, je reste perplexe.
Par contre, si tu partage ton code pour les palettes, ca m'interresse.
poshu, je sais ce que tu viens de dire, mais dans ma methode le chargement est le dechargement joue un role important, tout d'abord je charge toutes les images au format COMPRESSE, qui occupe 3,5Mo, ensuite je cree une image ou un sprite dans lequel je change les couleurs des pixel à partir du pack compréssé.
Pour mieux s'approcher de la réalité, imagine qu'on joue avec 3 persos chacun, ce qui fait un total de 6, alors dans le cas normal, le chargement va marquer une pause importante pendant le passage entre l'ecran de selection de perso, et le jeu, de plus, la decompression à partir de la ram est negligeable par rapport au temps de lecture a partir du Hdd.
J'espère etre clair cette fois ci.
Mon code sera partagé avec plaisir, mais là je suis en transition Blitz3d=>Purebasic
Pour mieux s'approcher de la réalité, imagine qu'on joue avec 3 persos chacun, ce qui fait un total de 6, alors dans le cas normal, le chargement va marquer une pause importante pendant le passage entre l'ecran de selection de perso, et le jeu, de plus, la decompression à partir de la ram est negligeable par rapport au temps de lecture a partir du Hdd.
J'espère etre clair cette fois ci.
Mon code sera partagé avec plaisir, mais là je suis en transition Blitz3d=>Purebasic
Pour compresser tes fichiers tu peux t'inspirer de cette méthodebadrs a écrit :J'ai déja entamé une procedure compliqué pour packer les images ou sprites dans la ram, les sprites sont indexés sur 8bits et sont liés à des palettes, alors la lecture se fera par code et s'ecrit directement via le pointeur sur l'image, mais cette procedure est limitée pour un simple usage, alors que j'envisage l'utiliser dans tout mon projet, raison pour laquelle je cherche une alternative.
Code pour compresser un fichier
Code : Tout sélectionner
If ReadFile(0, "twinbee.mxm")
FileLength = Lof(0)
*Buffer = AllocateMemory(FileLength)
*Packed = AllocateMemory(FileLength+8)
ReadData(0, *Buffer, FileLength)
CloseFile(0)
PackedSize = PackMemory(*Buffer, *Packed, FileLength, 9)
If PackedSize
If CreateFile(0, "TwinBee.pak")
WriteData(0, *Packed, PackedSize)
CloseFile(0)
MessageRequester("Info", "Packed !", 0)
EndIf
EndIf
EndIfCode : Tout sélectionner
If ReadFile(0, "TwinBee.pak")
FileLength = Lof(0)
*Buffer = AllocateMemory(FileLength)
UnpackedModule = AllocateMemory(20000)
ReadData(0, *Buffer, FileLength)
CloseFile(0)
Size = UnpackMemory(*Buffer, UnpackedModule)
If Size
If CatchMXMModule(UnpackedModule)
PlayMXMModule()
MessageRequester("Info", "Click to change the position", #MB_ICONINFORMATION)
SetMXMModulePosition(1)
MessageRequester("Info", "Click to change the volume", #MB_ICONINFORMATION)
MXMModuleVolume(50)
MessageRequester("Info", "Click to quit", #MB_ICONINFORMATION)
EndIf
EndIf
EndIfà la place de CatchModule() tu mets CatchSprite() et ça le fait aussi.
Pense aussi à utiliser ClipSprite().
Je n'ai pas compris mais tu as sûrement de bonnes raisons de procéder ainsi.Les sprites sont indexés sur 8bits et sont liés à des palettes, alors la lecture se fera par code et s'ecrit directement via le pointeur sur l'image
[EDIT]
J'ai pris en exemple le premier code qui me tombait sous la main, mais en fait, tu peux aussi regarder la commande CreatePack() pour compresser tes fichiers.
http://purebasic.developpez.com/
Je ne réponds à aucune question technique en PV, utilisez le forum, il est fait pour ça, et la réponse peut profiter à tous.
Je ne réponds à aucune question technique en PV, utilisez le forum, il est fait pour ça, et la réponse peut profiter à tous.
-
beauregard
- Messages : 1307
- Inscription : dim. 08/juil./2007 18:32
- Localisation : Toulouse
bienvenu(e), 
j'l'avais deviné que tu faisais un jeu de combat, rapport à la taille des sprites... ma pensée pour la taille de l'exe:
j'ai vu des PC vendu avec 3Go à moins de 800euros, et les pcportables vont commencer l'année 2008 en beauté( avec 4Go).... et d'ici que ton jeu soit terminé, même un exe de 300Mo, soyons fou, ne va pas effrayer les amoureux de street fighter( qui n'ont pas les même préocupations/connaissances des codeurs). Quelque soit la méthode utilisé, ce sera la bonne... à la condition que ton jeu soit amusant( et avec au moins un combatant charismatique, et une femme belle et cultivée comme heu, léa parker par exemple, hum).
A+
j'l'avais deviné que tu faisais un jeu de combat, rapport à la taille des sprites... ma pensée pour la taille de l'exe:
j'ai vu des PC vendu avec 3Go à moins de 800euros, et les pcportables vont commencer l'année 2008 en beauté( avec 4Go).... et d'ici que ton jeu soit terminé, même un exe de 300Mo, soyons fou, ne va pas effrayer les amoureux de street fighter( qui n'ont pas les même préocupations/connaissances des codeurs). Quelque soit la méthode utilisé, ce sera la bonne... à la condition que ton jeu soit amusant( et avec au moins un combatant charismatique, et une femme belle et cultivée comme heu, léa parker par exemple, hum).
A+
Merci à tous encore une fois, et merci comtois pour ta methode de compression et décompression, mais le format de compression dont je parle ne s'agit pas d'une methode comme winrar ou 7zip, d'ailleur cette mathode du MxMModule est bonne aussi et je vais l'inclure dans mon projet.
beauregard, rassure toi, mon projet vise un package de pas plus que 80Mo en total, 56Mo en Vram, et 120Mo en Ram, je vais essayer d'optimiser le jeu en essayant d'associer la rapidité et un bon gameplay, sans oublier l'animation ou les effet speciaux,..... bref t'as qu'attendre pour voir.
Comme je vous ai dit, je viens du monde de Blitz3d, et mon projet est bien avancé avec blitz, et je compte le traduire en Purebasic. Pour ceux qui se demandent toujours pourquoi packer et stocker en ram, je vais vous dire que l'exe sera biensur petit, mais les media aulieu de les cherger a chaque fois, je prefere les charger au début au format compréssé, et à chaque fois que j'en ai besoin, je décompresse et remplace mes sprites, (peek & poke)
Bientot je vais vous donner une Démo de l'evolution de mon projet, j'espère qu'elle vous rapprochera des contraintes que j'ai rencontrées, et qu'elle vous montre l'importance de mon projet ainsi que les avantages de le faire en Purebasic.
beauregard, rassure toi, mon projet vise un package de pas plus que 80Mo en total, 56Mo en Vram, et 120Mo en Ram, je vais essayer d'optimiser le jeu en essayant d'associer la rapidité et un bon gameplay, sans oublier l'animation ou les effet speciaux,..... bref t'as qu'attendre pour voir.
Comme je vous ai dit, je viens du monde de Blitz3d, et mon projet est bien avancé avec blitz, et je compte le traduire en Purebasic. Pour ceux qui se demandent toujours pourquoi packer et stocker en ram, je vais vous dire que l'exe sera biensur petit, mais les media aulieu de les cherger a chaque fois, je prefere les charger au début au format compréssé, et à chaque fois que j'en ai besoin, je décompresse et remplace mes sprites, (peek & poke)
Bientot je vais vous donner une Démo de l'evolution de mon projet, j'espère qu'elle vous rapprochera des contraintes que j'ai rencontrées, et qu'elle vous montre l'importance de mon projet ainsi que les avantages de le faire en Purebasic.
Dernière modification par badrs le lun. 31/déc./2007 0:32, modifié 1 fois.
Bonne idée, il n'y a rien de mieux pour comprendre ton projet.badrs a écrit :Bientot je vais vous donner une Démo de l'evolution de mon projet, j'espère qu'elle vous rapprochera des contraintes que j'ai rencontrées, et qu'elle vous montre l'importance de mon projet ainsi que les avantages de le faire en Purebasic.
http://purebasic.developpez.com/
Je ne réponds à aucune question technique en PV, utilisez le forum, il est fait pour ça, et la réponse peut profiter à tous.
Je ne réponds à aucune question technique en PV, utilisez le forum, il est fait pour ça, et la réponse peut profiter à tous.
Trouvé
Je viens de terminer mon code de chargement des images et sprites directement à partir de la ram, et pour ceux qui veulent avoir une idée du projet, je vous invite à essayer la démo ci joint
J'ai désactivé la totalité des actions et menus pour la simple raison que c'est pas optimisé encore, et pour proceder il suffit de clicker Menu:"QuickLoad", puis choisir "Dafaut 1"
(Vous pouver defiler les images ou changer la palette des couleurs)
J'ai désactivé la totalité des actions et menus pour la simple raison que c'est pas optimisé encore, et pour proceder il suffit de clicker Menu:"QuickLoad", puis choisir "Dafaut 1"
(Vous pouver defiler les images ou changer la palette des couleurs)