[mOved] BomberMan World - Page 7

-

nah oui mais ya kand meme une difference entre donner des screen et donner le prog kon pe pas utiliser, moi je trouve ke c pas bien.

c'ets clair que les bombes c'ets le plsu dur dans le jeu en 4h tu m'epate ^_^
j'espere que ta bien optimisé ca qd même
Hate de voir le tiens et hate de m'y remmetre sur le mien( des quej ia un peud e news du graphiste )

non moi je trouve sa lol gg orion puis au moin tout le monde sait ki as koi cé un peu plus sur fo eviter une deuxiemme affaire neogeopockeet-thunderz

pour ça faudrait que j'ai 2 gp32 et 2 gp link (en plus un mode link, c'est sacrement cho a faire pour les synchronisation de transmition et tout, c'est pas aussi simple que vous le pensez peut etre)

En general les SDK sont tres bien fait pour ca!(bon euh GP, c est pas sur, mais... tout n est peut etre pas bugger!) Je pensais pareil sous DirectX et il s avere que c est assez simple(quand ca marche!) ^^

-

-

oui 2 serait plus adapter mais comme dans tous bombeman tu as des items qui te permettent te faire
augmenter la distance des explosion (je sé pas si tu veut le faire mais il serait plus logique de commencer par des petites explosion^^)

Orion_
:

Mr Pomme :
j'espere que ta bien optimisé ca qd même

ben le code de detection pour ne pas exploser apres un block dur par exemple
ou s'arreter apres un block explosable etc ...
me semble un peu gros et pas trop optimisé, mais je vois franchement pas comment faire autrement.
c'est pas pour autant qu'il n'est pas optimisable (j'ai juste pas trouvé comment pour l'instant)
le system d'explosion est enregistré dans un tableau avec plein d'info (frame actuelle de l'explosion, type etc ...) qui me permettra de rajouter les bonus sans trop de mal
par la suite.

bon sinon, j'ai eu pas mal de remarque quand au gresillement du son qui est malheuresement independant de ma volonté, la faudrait demander a gamepark de revoir son code au niveau du SDK.

pour le gresillement j'ai le même probleme c'est des que tu a un sond qui staure en freauence il me semble, huhu un tableau j'avais aussi commencer comme ca mais j'ai changé car j'espere poru toi que tu librer bien ta mémoire apres uen explosioncar sinon il y a potienteielment un problème ( c'est le pourquoi je me suis penché pas mal dessus )
hu j'ai pas souvennance que les explosions s'additionnent quand elles sont bloqué fauderai que je refasse une partie ^_^

du très bon boulot orion, bonne chance pour la suite

-

ya des structureq bcq plus adaptive et moins gourmande en mémoire que les tableaux songes y

-

les listes chainees?
si c de ca que tu parle, ca peut etre totalement l'inverse "songes y "

bha oui entre autre, l'avantge ets le gain flagrant de place et aussi le fait que la mémoire est libéré des que j'ai plsu beoin d'un bombe par exemple, j'ai fait des test et ca consome bien moins de place en mémoire lors d'un partie mais il faut tout réécrire evidement ^-^
Ce que j'ai fait car sinon je connais de spetit marrant qui vont placer un millard de bombe juste pour voir si ca deconne pas ;-)

Mr Pomme :
ya des structureq bcq plus adaptive et moins gourmande en mémoire que les tableaux songes y

Hum. Pour des élements tous identiques comme des bombes dans un jeu comme Bomberman, j'ai du mal à voir comment une liste chainée pourrait prendre moins de place qu'un simple tableau, ou bien tu dois pas t'y prendre comme il faut
(et au passage, en plus de prendre plus de mémoire ça serait sensiblement plus lent)

un bombe est un élément assez complexe a geré l'aire de rien et nan je suis certaind en e pas prendre psud eplace car je librere mes structures des qu'elle sont finie

En plein pendant le jeu, tu libere la mémoire ? lol
1 - Une bombe n'est *pas* une structure complexe à gérer, ou alors tu n'as jamais rencontré de structure réellement complexe
2 - Utiliser une liste chainée dans ce cas est une perte de vitesse et de place

Bha t'es pas obliger de me croire , bien sur je libère la mémoire allouer une fois qu elle explose , elle n'a plus de raison d'exister en mémoire!
T'es pas obliger de me croire si tu veu pas m'en fout en fait lol ^_^, je sais ce que j'ai tester et ca me suffit amplement
je le metterai surment en GPL plus tard tu pourra zieuter le code si tu veu

Mr Pomme
: Bha t'es pas obliger de me croire , bien sur je libère la mémoire allouer une fois qu elle explose , elle n'a plus de raison d'exister en mémoire!

Bah oui je pense bien vu que c'est le but... Mais c'est lent. Vu la place que tu perd en utilisant une liste chainée, ça ne prendra pas plus de place (voir même "ça en prendra moins") d'utiliser un tableau simple, et ça y gagnera beaucoup en vitesse. D'une part parcequ'on évite les allocations, d'une autre parcequ'une liste chainée est par nature lente à manipuler.

P.S : Je pense qu'Orion_ a réflechi un minimum au problème avant de coder ça comme ça... Et il a eu parfaitement raison

bha apparment il emploie plusieurs tableau et je suis pas sûr du gain la dessus ^_^
j'ai pas dit qu 'orion avait mal fait , je dit juste que moi j'ai fait comme ca et apres test c'ets bien plus performant(pour mon cas en tout cas).
Et si il est vrai que je prends plus de place en mémoire au deux premiere bombe , j'en regagne aussitot ensuite ^_^ car je ne peu aps avoir 100 bombe en m^me temps sur l'ecran donc econome en mémoire , mais si on joue au realloc avec les tableau le gain peut surment etre moins probant j'en disconvient pas mais moi j'ai besoin de trouver facilment mes bombes ^_^

techniquement il s en fou d avoir plusieur tableau il a 8mo de memoire, si encore il etait vraiment limite mais c est pas ces 4 tableau qui vont le tuer! Je pense sincerement aussi que ca methode est pas mauvaise(je dis pas qu elle optimiser loin de la!) mais le coups des listes chaine c est vraiment se casser les bonbons pour rien!(surtout pour ce type de jeux tres carre!)

waip je sais bien qu'il y avais plsu simple mais j'avais envie de faire qq chsoe de bien pour mon premier jeu sur gp32

justement non c'est pas forcement quelquechose de bien...
les listes chainees c'est bien, mais pas partout, idem pour les tableaux, les arbres, les graphes, etc...
et la memoire que tu perd depend beaucoup de l'implementation de malloc...
sans compter que ces magnifiques listes chainees fragmentent ta memoire a fond

une des implementations assez courante (je sais pas si elle est utilisee sur gp), c'est d'arrondir la taille des blocs a une puissance de 2. (c'est celle que tu trouve sur certains os sur pc, les bsd entre autres il me semble)
donc tu fais le calcul, si t'as une structure qui fait 40 octets, que t'as 100 blocs de cette structure, ca te fera absolument pas 4000 octets, ca te fera 6400 octets. (plus la taille des blocs utilise par l'implementation, places juste avant ton bloc a toi)
maintenant tu fais un tableau de 100 de ces memes structures, ca te fait 4096 octets...

et un tableau n'a pas forcement une taille fixe non plus.
realloc est lent si tu realloue beaucoup de fois d'enormes blocs de mem et qu'il n'y a plus suffisemment de place dans le heap juste apres le bloc pour l'etendre, vu que realloc devra le recopier a coups de memcpy vers le nouvel emplacement. si ton bloc n'a rien devant, le cout du realloc est quasiment le meme que celui d'une allocation normale.
mais si tu realloue par blocs de 5 ou 10 structures a la fois, tu devra reallouer _beaucoup_ moins souvent ---> cout du realloc quasiment nul (la encore dans l'exemple des bombes... de tte facons plus de 10 bombes en meme temps c'est assez improbable, donc si t'alloue ton tableau initial a 10 ca sera tres rare si tu dois l'agrandir...)

sans compter la perte de temps que represente le parcours d'une liste chainee compare a l'indexation directe d'un tableau...
enfin bon comme a dit manoloben on s'en fout... si y a de la mem ou de la vitesse a gagner c'est sans doute pas a cet endroit
donc pour des trucs comme ca c'est d'abord surtout la clarte du code qui importe... et perso je trouve qu'un code de manipulation de tableaux est plus rapide et simple a lire qu'un code de manipulation de liste chainees...

et puis si tu veux faire un truc "bien", tu peux toujours jarter ta liste chainee, et faire un graphe, comme ca t'aura des cluster bombs, banana bombs... des... hem heu dsl.. trop joue a worms3d ce WE

... no comment
je suis pas un guru en prog C mais j'ai fait mais test et je m'en tiens a ceux là,
miantenant je toruve ca lourd d'être toujours reprit et je crois que je posterai plus dans cette section du forum , ya toujours des gens qui savent mieux que les autres..tant pis de totue façon j'apporte rien au gens ici donc pas de problèmes pour vous!!

lol... super intelligente et constructive ta reaction...

je te rassure je la considère pas comme intelligente mais ca commence à me prendre la tête vuq ue c'ets aps la première fois..^_^ et je vois pas pourquoi etre constructif car quand on essaye on se fait " taper ses doigts" par des pseudo guru ^_^

-

D'un côté, tant que le résultat y est, le reste, on s'en branle !

Vous les mettez sur quoi comme carte vos progs GP32?