Ultimate Smash Friends: un smash bros like en python

doudoulolita · Le 15/11/2011, à 15:37

thunder_all.zip contient 2 dossiers:
- thunder avec le nouveau xml (decorum) à placer dans levels
- thunder-light qu'il faut placer dans le dossier misc.
Je n'arrive pas à le faire marcher si les éclairs et l'image transparente sont dans le même dossier que les autres images.
Mais bon, l'éclair peut ainsi servir sur d'autres décors

Dernière modification par doudoulolita (Le 15/11/2011, à 15:38)

tshirtman · Le 15/11/2011, à 18:10

Je vais tester ça , en effet, ça peut servir dans d'autres niveaux.

edit: ça marche je l'ai poussé sur github, , bon, le code sur github est un peu cassé par contre, par ce que j'ai pas vérifié des changements d'aspidites (oui, il est revenu!) avant de les accepter, mais on va tacher de corriger ça sous peu.

Dernière modification par tshirtman (Le 15/11/2011, à 18:27)

doudoulolita · Le 18/11/2011, à 20:35

Si c'est bon pour les éclairs, j'essaierai de faire plusieurs sortes d'éclairs à différents endroits; avec le decorum, ça devrait être facile.
Je regarderai quelques vidéos pour voir comment la foudre fonctionne "en vrai".

Pour le niveau Thunder, j'avais aussi envie de retravailler les immmeubles. Mais bon, j'ai aussi mon perso Lila et le dragon Redlong à animer, ça fait pas mal de choses !

S'il y a des soucis sur github, je ne vais pas faire de pull et au pire, je testerai mes animations avec de bons vieux gifs animés.

doudoulolita · Le 22/11/2011, à 01:10

Minkie static Minkie kick2 Minkie hit2 Voici une nouvelle combattante pour USF-teddy : Minkie
De quoi faire peur aux hardcore gamers, non ?

Je n'ai gardé dans USF-teddy que Sorlo (l'ancien), Miks, Rizzie et Minkie. Il y a maintenant moins de mouvements pour les persos (une dizaine de frames seulement en tout). Tous ont le même xml sauf leur nom bien sûr et ça colle à peu près (et tant pis pour la qualité des hardshapes et des agressiv points)
J'ai simplifié 3 décors pour l'instant avec juste 3-4 plates formes et sans moving blocks ni decorum ni autre. Le tout avec des coordonnées en chiffres bien ronds.
J'aimerais finaliser une version USF-teddy de ce type (ultra simple) pour Noël et la proposer sur mon blog nounours.

Ca peut aussi servir de modèles pour des jeunes qui veulent créer des décors ou des persos. Il faudrait prévoir la même simplification pour Xeon, Possum et les autres pour une version "ado" facile à personnaliser.

Dernière modification par doudoulolita (Le 22/11/2011, à 01:14)

doudoulolita · Le 24/11/2011, à 21:42

A mon boulot, c'est le retour des maternelles qui réclament à grands cris Ultimate Smash Friends en fin de séance...

Les mini-hardcore gamers veulent la version avec Xeon et Possum, installée sur mon ordi, tandis que les autres se contentent des premiers BiX et Blob.

C'est surtout la bagarre pour utiliser le pavé directionnel, les 2 joueurs se préoccupant plus de l'accaparer que de jouer réellement...
Je sens que je vais devoir leur faire un cours de jeu vidéo si je veux qu'ils comprennent le fonctionnement avant Noël.

J'ai 6 joueurs sur une salle de 10 postes, les autres (ils sont 23 en tout) n'ayant pas encore découvert le jeu. La maîtresse est d'accord tant que ce n'est pas trop violent.

Pour eux, j'aurais besoin de pouvoir faire un lanceur sur le bureau pour la version bzr (et plus tard celle de git), et pouvoir le balancer via le serveur sur tous les postes (par ssh) mais jusqu'ici, je n'ai pas trop bien réussi.

C'est je pense le seul moyen pour qu'ils aient accès à la version Possum-Xeon, car sur Ubuntu 10.04, elle ne s'installe pas correctement par le ppa ou le .deb.

Dernière modification par doudoulolita (Le 24/11/2011, à 21:44)

tshirtman · Le 24/11/2011, à 23:08

doudoulolita a écrit :

A mon boulot, c'est le retour des maternelles qui réclament à grands cris Ultimate Smash Friends en fin de séance...

\o/

Les mini-hardcore gamers veulent la version avec Xeon et Possum, installée sur mon ordi, tandis que les autres se contentent des premiers BiX et Blob.

Ok, il en faut pour tous les gouts

C'est surtout la bagarre pour utiliser le pavé directionnel, les 2 joueurs se préoccupant plus de l'accaparer que de jouer réellement...

arf, donc je suppose qu'ils ont besoin d'une configuration plus simple à gauche, c'est pas simple, ces claviers non alignés sont vraiment une plaie, faudrait donner des typematrix à tous le monde...

Je sens que je vais devoir leur faire un cours de jeu vidéo si je veux qu'ils comprennent le fonctionnement avant Noël.

Hum, bon, en meme temps, à leur age, c'est un jeu un peu complexe pour la plupart...

J'ai 6 joueurs sur une salle de 10 postes, les autres (ils sont 23 en tout) n'ayant pas encore découvert le jeu. La maîtresse est d'accord tant que ce n'est pas trop violent.

Plus de testeurs! cool , bon, faudrait que je trouve le temps pour faire avancer le gameplay alors ^^'.

Pour eux, j'aurais besoin de pouvoir faire un lanceur sur le bureau pour la version bzr (et plus tard celle de git), et pouvoir le balancer via le serveur sur tous les postes (par ssh) mais jusqu'ici, je n'ai pas trop bien réussi.

Hum, Tu as réussis à faire un lanceur, déjà, ou pas? Pour le lancement par ssh, c'est pas forcément simple, mais ça doit etre possible, à condition de se connecter avec le bon utilisateurs et en indiquant le bon display:

DISPLAY=:0 ultimate-smash-friends

(si 0 ne marche pas, essayer 1, le ":" est important).

C'est je pense le seul moyen pour qu'ils aient accès à la version Possum-Xeon, car sur Ubuntu 10.04, elle ne s'installe pas correctement par le ppa ou le .deb.

Hum, il faudrait vraiment que je teste ça... >_>

doudoulolita · Le 25/11/2011, à 00:05

J'ai retravaillé USF-teddy avec des niveaux assez faciles pour les enfants (pour sauter facilement sur les plate-formes et le pod d'un des niveaux). J'ai supprimé Night (inspiré de Thunder) pour reprendre Bix_level en plus grand et encore plus simple. J'ai juste changé son nom en bixland.

bixland, version simplifiée de Bix_level

Tous les niveaux sont basés sur une taille identique: 1280 x 1024px et ont des chiffres ronds pour les coordonnées des plate-formes et des pods. Je pense que ça facilitera les choses pour ceux qui veulent personnaliser le jeu.

Il faudra peut-être revoir un peu les persos pour que les hardshapes identiques fonctionnent sans trop de souci et revoir les agressiv-points qui semblent faiblards pour le hit.
J'aimerais aussi ajouter un panda... C'est pour mon blog nounours, faut faire fort !

Dernière modification par doudoulolita (Le 25/11/2011, à 00:10)

tshirtman · Le 25/11/2011, à 00:08

Tiens, leur palette de mouvement est limité, mais ça peut t'intéresser, et c'est du svg donc tu peux le retravailler facilement. Ils pourraient tous utiliser le même xml, vu que seul la tête change vraiment.
http://opengameart.org/users/creek23

doudoulolita · Le 25/11/2011, à 00:59

Merci pour le lien, les persos sont dans le genre mignon qui conviendrait pour mon site nounours. Mais, y a pas de mascotte nounours ou panda dans le monde du libre ?

Un truc que je ferais bien pour USF-teddy -> joueur 1 : pavé directionnel + lettres P pour Pied (kick), et M pour Main (hit).
Les enfants arrivent à retenir le début des mots et ce sont des lettres proches sur le clavier AZERTY. C'est un chouïa didactique comme ça... C'est moins facile pour le bouclier car le B est un peu loin, mais Espace ou le point d'exclamation serait bien aussi.

Pour le joueur 2, c'est moins facile de trouver des idées faciles à retenir pour des petits, à part les chiffres du pavé numérique. Ils n'aiment vraiment pas se prendre la tête avec des lettres, à cet age, alors que sur le pavé numérique, il y a des petites flèches.

Ou alors, faudrait des autocollants (ou des bouts de post-its) à coller sur le clavier pour jouer à USF !

tshirtman · Le 25/11/2011, à 10:28

Hum, pour un panda, y'a bien Panda3D comme projet libre je sais pas s'ils ont d'autres artworks de leur mascotte.

Pour le clavier, je pense qu'en effet, à par les autocollants, y'a pas trop de solutions simples, mais je pense que c'est dur d'en trouver des assez résistants pour se barrer tout le temps, à par des autocollants spécial clavier, mais tu risque de commander un jeu complet et juste pouvoir utiliser les quatre flèches normales plus celles du pavé numérique, si tu sacrifie un clavier pour ça, ça peut le faire.

moths-art · Le 25/11/2011, à 14:06

eh, j'avais pensé également à Panda3D... en cartoon avec des lunettes, ça peut le faire.
Pour un nounours dans le libre, il y a effectivement 'Plee the bear'
http://doc.ubuntu-fr.org/plee_the_bear
qui est un bon jeu de plate-forme mêlant assez agréablement le "old scool" des sonic et mario des années 80-90 avec des techniques plus actuelles.

tshirtman · Le 25/11/2011, à 21:38

haha, il a ajouté la mascotte d'OGA, elle est marrante
http://opengameart.org/content/sara-the … art-mascot

ça commence à faire une belle collection

doudoulolita · Le 25/11/2011, à 21:54

Un nouvel article sur mon blog grâce à vous : Jeu vidéo et nounours
Vous m'aviez déjà parlé de Plee the bear, je crois, en tout cas, je l'avais dans mes marque-pages. Pour participer au développement ou à la personnalisation par contre, c'est plus compliqué que pour USF !
La mascotte de Panda 3D est mignonne, je vais voir pour faire une version pour USF-teddy.
Merci pour votre aide !

doudoulolita · Le 25/11/2011, à 22:43

tshirtman a écrit :

haha, il a ajouté la mascotte d'OGA, elle est marrante
http://opengameart.org/content/sara-the … art-mascot
ça commence à faire une belle collection

L'ensemble est sympa, avec du dynamisme dans la simplicité et des regards craquants.
Moi j'aime mieux Kit et Wilber, c'est pourquoi je les ai mis sur mon blog. J'aime bien aussi Gnu.

Dernière modification par doudoulolita (Le 25/11/2011, à 22:46)

moths-art · Le 26/11/2011, à 00:29

Doudoulolita : pour participer à "Plee the bear", j'ai trouvé ça plutôt facile et ouvert.
L'équipe (2 personnes en réalité) est française et reste assez active (le projet à déjà 2 ans derrière lui).
Pour ma part, j'ai fourni quelques graphismes et modifié quelques scripts et j'ai eu les droits de commit sur le SVN au bout de 3 semaines.
C'est plutôt rapide comparé à d'autres projet libre ou il faut des fois attendre plusieurs années et savoir baissé son froc.
Maintenant, le jeu commence à être assez mature est abouti ce qui demande une certaine exigence...
et puis le gros du code est en C++, ce qui est un peu moins à la porté de tous. (comparé à python bien évidement)
Ce qui est peu visible c'est que le SDK est autonome, fonctionnel et bien pensé.
Pour dire : les 2 devs ont créé un nouveau jeu à partir de celui-ci en 1 week-end :
http://www.developpez.net/forums/d11494 … n-j-jorge/

D'ailleurs, nous sommes en recherche de graphistes principalement...

Mon but n'est bien sur pas de faire basculer les contributeurs d'un projet à un autre, c'est à dire faire de la com pour Plee au détriment de USF.
Cependant, je pense que participer conjointement à plusieurs projets ne peux que être bénéfique (si le temps le permet bien sur): s'inspirer de bonnes idées, c'est aussi un des points fort du libre!

Finalement, je développe conjointement ce petit soft (plugin) mais ne connais pas assez la structure de USF pour savoir si ça peut aider : http://forum.ubuntu-fr.org/viewtopic.php?id=725191

tshirtman · Le 26/11/2011, à 00:43

Hum, dans USF, les sprites sont découpés dans des images individuelles, je fais ça avec gimp en général, sélection à la taille pile poil du sprite, maj-ctrl-x pour "découper l'image" (raccourcis perso), et maj-ctrl-s pour sauver dans un nouveau fichier, ctrl-z et je recommence avec le suivant, c'est vrai que c'est un peu fastidieux, mais c'est une fois par perso, et les tailles/emplacements dans l'image peuvent varier, donc je ne pense pas qu'un outils aiderait beaucoup.

Ce qui aiderait vraiment, ce serait un outil pour régler le fichier xml qui construit le perso à partir des sprites ^^, j'ai fais un visionneur qui aide pas mal, mais les GUI et moi ça fait une bonne douzaine, alors l'édition se fait toujours par editeur de texte.

Pour participer au dev d'USF, j'ai toujours donné rapidement les accès quand c'était sur launchpad, et maintenant que c'est sur github, ben j'ai mergé toutes les pull request que j'ai eu ^^ (mais c'est vrai que pour l'instant, c'est un seul contributeur, que je connaissais déjà ^^).

edit: je viens de voir la vidéo du jeu, pour deux jours, c'est pas mal surtout en C++ ^^, en python en réutilisant pas mal de trucs que j'ai fais pour USF, je pense que je m'en sortirais, mais on est pas dans un concours ^^.

Dernière modification par tshirtman (Le 26/11/2011, à 00:50)

moths-art · Le 26/11/2011, à 09:09

Tiens vous utilisez des images séparés pour chaque sprite...
C'est pas un peu gourmand en mémoire sans compter les nombreux accès au disque pour chaque image.
Vous auriez tout intérêt à utiliser tout les sprites d'un perso dans 1 ou 2 images je pense... les fps vont peut-être s'améliorer également.
Maintenant, je sais que des changements de cet ordre ne sont pas triviaux... faut mettre pas mal de tests unitaires pour éviter les régressions.

tshirtman a écrit :

les tailles/emplacements dans l'image peuvent varier

Pour les emplacements, ça ne pose pas de problème... mon plugin va directement les récupérer dans Gimp.
Ensuite, pour les tailles, je suis sur le point de mettre l'option "d'autocrop" des calques.
En gros, ça fait automatiquement l'opération que l'on peut obtenir en graphique comme ceci 'Calque->Découpage automatique de calque'

Je vais voir si ça peut s'appliquer dans votre projet en faisant un test sur un personnage.
Parallèlement à ça... je vais m'atteler à ton outil. J'imagine que tu préfères du gtk pour éviter les multiples dépendances?
Donne moi plus de précisions afin de mieux orienter mon dev.

tshirtman · Le 26/11/2011, à 11:18

Je suis gourmant en ram, notamment du fait de ce code:

@memoize
def image(name, *args, **kwargs):
    """
    A function to load an image, memoized, and with manipulation capabilities:
        scale, zoom
        reverse horizontaly,
        produce a lightened version of an image,
        change alpha of an image,
        crop
        and expand an image.
    """
    keywords = {
            'reversed': _reverse,
            'lighten': _lighten,
            'alpha': _alpha,
            'scale': _scale,
            'crop': _crop,
            'expand': _expand,
            'zoom': _zoom,
            'rotate': _rotate,
            }

    for kw in keywords:
        if kw in kwargs and kwargs[kw]:
            img = keywords[kw](name, kwargs)
            break
    else:
        img = _load(name)

    return img, img.get_rect()

sachant que @memoize fait que les résultats de l'opération sont sauvegardés en mémoire et renvoyé directement si la fonction est appelé dans le future avec les mêmes paramètres. j'utilise cette fonction pour charger toutes les images, avec tous les paramètres du jeu, et je t'assure que ça ne pose pas de soucis de FPS, par contre, c'est sur que ça mange de la RAM, cela dit, juste pour charger les images basiques, je pense que mettre chaque frame dans une image différent "gâche" moins de pixels (surtout quand les frames sont de tailles très différentes) que de tout mettre dans une image. Je sais que tout le monde fais ça, et découpe au cpu après, mais doute que ce soit pour des raisons de perfs, même si c'est très simple comme algo, c'est pas gratuit pour autant. C'est surtout que c'est plus facile de bosser sur un perso avec toutes les poses sur la même image.

Dernière modification par tshirtman (Le 26/11/2011, à 11:19)

moths-art · Le 26/11/2011, à 11:24

Bon, le week-end se prépare et je serais loin de tout ce qui caractérise le 21ème siècle...
Je reprendrais dimanche ou lundi soir à tête reposé.
Tout ce que je peux dire c'est que j'ai testé 'cv.py' (j'imagine que c'est le visionneur dont tu parles) dans le dépôt GIT et qu'ai dût régler quelques problèmes de dépendances et de syntaxe avant de pouvoir le lancer...

Je communiquerais le git diff à l'occasion.

tshirtman · Le 26/11/2011, à 11:38

ah, merci (oui, c'est de lui que je parle)

(c'est marrant les trucs qui marchent un jour, et plus quelques mois après >_>)

Dernière modification par tshirtman (Le 26/11/2011, à 11:38)

doudoulolita · Le 26/11/2011, à 13:45

moths-art a écrit :

Doudoulolita : pour participer à "Plee the bear", j'ai trouvé ça plutôt facile et ouvert.
L'équipe (2 personnes en réalité) est française et reste assez active (le projet à déjà 2 ans derrière lui).[...]
Maintenant, le jeu commence à être assez mature est abouti ce qui demande une certaine exigence...
et puis le gros du code est en C++, ce qui est un peu moins à la porté de tous. (comparé à python bien évidement)[...]
D'ailleurs, nous sommes en recherche de graphistes principalement...

Personnellement, je suis très débutante en programmation, je ne suis pas super logique et je n'ai pas une très bonne mémoire, donc le C++ est trop compliqué pour moi.

Pour les graphismes sur Plee Bear, je ne suis pas contre m'engager sur 2 projets si je trouve du temps. et si vous aimez mon style. Plee the Bear m'intéresse en effet pour mon blog sur les nounours. J'ai l'impression que les décors sont en 3D et j'ai envie de me coller un peu plus sur Blender, donc ça tomberait bien.

L'avantage d'USF, par contre, est que je peux facilement l'utiliser au boulot pour faire jouer les maternelles et pour faire des animations avec les ados.

moths-art a écrit :

Finalement, je développe conjointement ce petit soft (plugin) mais ne connais pas assez la structure de USF pour savoir si ça peut aider : http://forum.ubuntu-fr.org/viewtopic.php?id=725191

Je testerai ton plug in pour Gimp à l'occasion, c'est plutôt une bonne idée dans le principe. Moi, j'exporte mon image depuis Inkscape avec toutes les poses et c'est galère de les découper une par une dans Gimp à la bonne taille.

Est-ce qu'il repère la transparence pour faire son découpage ou ce sont les calques qui sont séparés ?
- Le premier est très utile pour séparer des persos en plusieurs images. Ce serait + précis et moins spécifique que les tranches (Filtres > web > slice, pour un site web).
Je trouve comme Tshirtman pratique d'avoir une image par pose, pour les animations avec les jeunes (et pour moi !), c'est moins impressionnant, et ça permet des tailles différentes si on veut.
- Le deuxième servirait pour les décors mais il faut d'abord fusionner les calques qui servent pour un élément précis, de toute façon (et alors, pour les transformer, bof ). Des groupes de calques et un découpage par groupes seraient géniaux dans Gimp.
Dans USF, nous n'avons pas beaucoup d'images différentes pour les décors, Pour l'instant 3 obligatoires (background, foreground + middle) + 1 ou 2 pods.

moths-art a écrit :

Tout ce que je peux dire c'est que j'ai testé 'cv.py' (j'imagine que c'est le visionneur dont tu parles) dans le dépôt GIT et qu'ai dût régler quelques problèmes de dépendances et de syntaxe avant de pouvoir le lancer...

Tshirtman a écrit :

(c'est marrant les trucs qui marchent un jour, et plus quelques mois après >_>)

Pour moi aussi, ça marche une fois sur deux, c'est étrange !

Dernière modification par doudoulolita (Le 26/11/2011, à 14:09)

doudoulolita · Le 27/11/2011, à 19:26

Minkie static sorlo static rizzie static ours miks static J'ai bossé sur mes persos d'USF-teddy. Minkie a un peu changé.

Je voulais qu'ils rentrent tous dans les mêmes hardshapes (en mettant des rectangles de tailles précises sur un calque, en dessous, tout bêtement). Il arrive qu'ils dépassent en largeur ou soient un peu moins large, mais la hauteur est toujours respectée.
J'ai différentes tailles de rectangles pour les différentes poses mais tous les persos doivent s'y conformer pour une même pose.

Mes hardshapes commencent par 0 0 puis la taille du rectangle.
Le souci est que pour une image de 60px de haut avec une hardshape de 60 de haut également, mes persos sont au-dessus des plate-formes de quelques mm.

Plus étonnant : si je passe la hardshape d'un des persos à 58 de haut, il a les pieds sur terre seulement de temps en temps mais pas toujours (en revenant sur la même plate-forme).

Dernière modification par doudoulolita (Le 27/11/2011, à 22:18)

tshirtman · Le 27/11/2011, à 20:51

Hum, il faut que je repasse sur le moteur physique je pense, je m'étais fais la réflexion y'a quelques mois, ça paraissait plus instable qu'avant...

(mais quand? c'est autre autre histoire >_>)

moths-art · Le 28/11/2011, à 14:19

Bon, de retour.:D (week-end dans un chalet avec sauna et piscine à 40° m'ont requinqué...)

doudoulolita : non, Plee the bear n'a jamais utilisé de 3D à ma connaissance...
Leur principe est d'avoir des images style cartoon (ce qui devrait te convenir) qui reste proche du dessin papier donc pas de vectoriel : courbes, aplats de couleurs et dégradés trop parfaits.
La 3D en sortie brute de blender risque de poser les mêmes problèmes.
Je trouve l'idée bonne d'utilisé des rendus 3D dans des jeux 2D car elles donnent de la profondeur.
Perso, quand je dessinais plus il y a quelques années, ça me permettait également de me créer une perspective complexe juste (sans m'arracher les cheveux) que je récupérais avec une table lumineuse.
En somme, tu peux utiliser un rendu 3D comme support mais le mieux est de texturé par la suite et de gommer en quelque sorte le côté trop pur de la 3D.

Pour P-CUTE :

doudoulolita a écrit :

Est-ce qu'il repère la transparence pour faire son découpage ou ce sont les calques qui sont séparés ?

En fait, ni l'un ni l'autre.
J'ai remarqué que les habitudes des graphistes pouvait être très différentes...
Ce qui m'a obligé à utiliser un fichier YAML (qui est dans ce cas précis plus minimaliste et compréhensible que du xml et moins minimaliste que du .conf) qui lui pilote la découpe des images.
Dans la majorité des cas, c'est les calques qui sont utilisés pour la découpe, mais plusieurs calques peuvent très bien servir pour un sprite.
Du coup, tu peux avoir des sprites qui réutilisent le même calque.(j'ai créé par exemple une animation d'un feu de cheminé pour Plee : le calque des bûches est réutilisé, seul les flammes changent)
A l'opposé, tu peux très bien avoir des calques dans ton espace de travail qui ne sera intentionnellement pas mentionné dans ton fichier YAML car tu n'en as pas besoin e production.
Exemple : un dessin scanné d'un personnage comme support en filigrane, une pose d'un personnage non abouti ec.
Tu peux aisément travailler avec plusieurs poses superposés afin de voir les différences.(en jouant sur l'opacité bien sur)
Le mieux est de regarder les tests fonctionnels du projet car elles permettent de voir l'ensemble des possibilités.

Tu mentionnes les groupes de calque : c'est opérationnel dans GIMP 2.7 : il y a même une vrai arborescence de groupes!
Je pense à terme intégrer cette possibilité dans P-CUTE : pour accéder à un groupe dans le fichier YAML, on fera ceci : groupe1.groupe2.calque pour une arborescence de ce genre :

groupe1:
            |
            `--> groupe2:
                             |
                             \-->calque

Seul limitation à mon sens, j'utilise pas mal mypaint et il n'y a pas de groupes de calques dans ce soft.
J'avais pensé à me penché sur la question mais vu le temps que j'ai passé à intégrer un pauvre bouton de duplication, ça m'a un peu refroidit : voir http://forum.ubuntu-fr.org/viewtopic.php?id=631391

En revanche, si vous avez des questions d'ordre spécifique à P-CUTE, le mieux est de les poser sur le fil correspondant : ça évitera de trop polluer celui-ci.

tshirtman :
Autant pour moi pour les fps : tu charges les images en ram avant de lancer le jeu ce qui une bonne idée.
Minimiser le nombres d'images réduirait le temps de lancement ce qui n'est pas forcément le plus contraignant.

tshirtman a écrit :

c'est sur que ça mange de la RAM, cela dit, juste pour charger les images basiques, je pense que mettre chaque frame dans une image différent "gâche" moins de pixels (surtout quand les frames sont de tailles très différentes) que de tout mettre dans une image.
Je sais que tout le monde fais ça, et découpe au cpu après, mais doute que ce soit pour des raisons de perfs, même si c'est très simple comme algo, c'est pas gratuit pour autant.
C'est surtout que c'est plus facile de bosser sur un perso avec toutes les poses sur la même image.

Je pense que tu te trompes sur ce point car cette technique date vraiment de la préhistoire du jeu vidéo (ou les softs de traitement d'image étaient vraiment rudimentaire) et bizarrement elle a la vie dur car elle est utilisé également dans les sites web et principalement par des gros bonnets : google, yahoo par exemple.

En fait, cette technique se comprend très facilement quand on s'amuse à découvrir la structure d'un fichier binaire : perso, j'utilise 'hachoir' : https://bitbucket.org/haypo/hachoir/wiki/Home (ou plus simplement apt-get install hachoir).
Tu remarqueras qu'une image png ou jpeg ne contiennent pas que des données mais :
un id, un entête, souvent un thumbnail (donc une image en plus petit pour un apperçu sur le bureau), une date de création, un text associé ('Create with gimp' par exemple) etc.(sans compter des éventuelles données exif)
Bref, des données redondantes que tu vas envoyer en ram qui n'auront aucun intérêt.
Leur pollution est proportionnelle à la taille de l'image : plus l'image est petite, plus ces données auront un impact non négligeable.

Il te suffit de comparer la taille des 125 personnages contenus dans 'data/characters/sorlo'
à 'data/characters/sorlo/source/sorlosheet.png' + 'data/characters/sorlo/source/supersorlosheet.png'.
Tu remarqueras que l'impact en ram est quasi double. (sans compter que les fichiers sorlotsheet.png et supersolosheet.png sont loin d'être optimisés.)

Pour les frames, de taille différentes : c'est ce qui à fait que l'algo de P-CUTE est passé de 100 lignes de code à 500... c'était loin d'être triviale et c'est pas encore totalement parfait.
Il est vrai qu'il faudrait (pour se rapprocher de la perfection) que je trouve le point de basculement entre la création de plusieurs images résultantes lorsque trop de pixels sont gâchés mais c'est assez lourd à envisager car chaque format d'image à son propre point d'équilibre et est interdépendant au programme à l'origine de sa création.(pour P-CUTE c'est GIMP)

Une solution également envisageable pour USF est de ne récupérer que les informations utiles de chaque image lors de l'appel à 'memorize' et de ne stocker qu'une grande image en RAM...
Les libs de hachoir (en python) pourrait peut-être t'aider.

tshirtman · Le 28/11/2011, à 15:40

moths-art a écrit :

Bon, de retour.:D (week-end dans un chalet avec sauna et piscine à 40° m'ont requinqué...)

Ah ben je te crois! Ça me ferais pas de mal non plus ^^, j'ai passé le week end a coder quasi non stop pour un projet.

tshirtman :
Autant pour moi pour les fps : tu charges les images en ram avant de lancer le jeu ce qui une bonne idée.
Minimiser le nombres d'images réduirait le temps de lancement ce qui n'est pas forcément le plus contraignant.

Pas tout à fait, chaque image est chargé au moment ou elle doit etre affiché pour la première fois, et les diverses transformations sont calculés la première fois ou on en a besoin pour l'image en particulier, et tout ça est mis en cache pour les fois suivantes. Donc le jeu est quand meme rapide a lancé, par contre, sur un pc un peu faiblare (je pense à mon eeepc 701) les quelques premières frames peuvent avoir de très faibles FPS, en effet, après ça va .

tshirtman a écrit :
c'est sur que ça mange de la RAM, cela dit, juste pour charger les images basiques, je pense que mettre chaque frame dans une image différent "gâche" moins de pixels (surtout quand les frames sont de tailles très différentes) que de tout mettre dans une image.
Je sais que tout le monde fais ça, et découpe au cpu après, mais doute que ce soit pour des raisons de perfs, même si c'est très simple comme algo, c'est pas gratuit pour autant.
C'est surtout que c'est plus facile de bosser sur un perso avec toutes les poses sur la même image.
Je pense que tu te trompes sur ce point car cette technique date vraiment de la préhistoire du jeu vidéo (ou les softs de traitement d'image étaient vraiment rudimentaire) et bizarrement elle a la vie dur car elle est utilisé également dans les sites web et principalement par des gros bonnets : google, yahoo par exemple.

En effet, par ce qu'une requete http constitue un overhead très important par rapport a un accès disque. Je pense que c'est plus pour cette raison que pour la taille des images, meme si a leur échelle, ces quelques centaines de ko sauvés par pages se traduisent par des miliiers ou millions de dollars par ans.

Je ne suis pas sur de quelle était la bonne raison à l'époque, mais je pense que ça a la vie dure pour de mauvaises raisons, en tout cas en local, je pense que c'est juste plus pratique de bosser sur une seule image, mais au niveau perfs en jeu, il vaut mieux avoir plusieurs textures qu'une grosse, à moins de très bien optimiser la place dans la texture en contenant plusieurs, si ça marche bien pour les modèles 3D, je pense que c'est pas terrible pour les sprites.

En fait, cette technique se comprend très facilement quand on s'amuse à découvrir la structure d'un fichier binaire : perso, j'utilise 'hachoir' : https://bitbucket.org/haypo/hachoir/wiki/Home (ou plus simplement apt-get install hachoir).
Tu remarqueras qu'une image png ou jpeg ne contiennent pas que des données mais :
un id, un entête, souvent un thumbnail (donc une image en plus petit pour un apperçu sur le bureau), une date de création, un text associé ('Create with gimp' par exemple) etc.(sans compter des éventuelles données exif)
Bref, des données redondantes que tu vas envoyer en ram qui n'auront aucun intérêt.

Oui il y a des données dans le fichier (et je connais hachoir ), mais non je ne vais pas les garder, tout ce que je vais avoir à la fin c'est une texture, sans tous le frata autour.

Leur pollution est proportionnelle à la taille de l'image : plus l'image est petite, plus ces données auront un impact non négligeable.
Il te suffit de comparer la taille des 125 personnages contenus dans 'data/characters/sorlo'
à 'data/characters/sorlo/source/sorlosheet.png' + 'data/characters/sorlo/source/supersorlosheet.png'.
Tu remarqueras que l'impact en ram est quasi double. (sans compter que les fichiers sorlotsheet.png et supersolosheet.png sont loin d'être optimisés.)

Hélas tu fais erreur en considérant que la différence de taille est seulement due aux en tetes, je pense que la compression PNG joue beaucoup plus (en effet, quand on compresse deux fichiers, on stock deux fois les tables de compressions, alors que si les deux images sont assez similaire, les memes codes risques de reservir beaucoup ), hors, une fois en RAM, on traite une vraie bitmap (un tableau de pixels), pas un truc compressé, donc la différence diminue d'autant .
Après, ça joue peut etre moins que je pense, mais en tout cas ce n'est aussi simple .

Pour les frames, de taille différentes : c'est ce qui à fait que l'algo de P-CUTE est passé de 100 lignes de code à 500... c'était loin d'être triviale et c'est pas encore totalement parfait.
Il est vrai qu'il faudrait (pour se rapprocher de la perfection) que je trouve le point de basculement entre la création de plusieurs images résultantes lorsque trop de pixels sont gâchés mais c'est assez lourd à envisager car chaque format d'image à son propre point d'équilibre et est interdépendant au programme à l'origine de sa création.(pour P-CUTE c'est GIMP)

Oui, sans doute assez complexe.

Une solution également envisageable pour USF est de ne récupérer que les informations utiles de chaque image lors de l'appel à 'memorize' et de ne stocker qu'une grande image en RAM...
Les libs de hachoir (en python) pourrait peut-être t'aider.

hum, en voyant les choses comme ça, il faudrait réserver une texture de taille arbitraire en RAM, et la compléter au fur et à mesure des appels à image(), sachant qu'un gros objet en RAM est bien plus encombrant que pleins de petits (il faut un gros espace continus, pas de fragmentation en RAM, alors que pleins de petits, c'est plus gérable. Franchement, je pense que c'est une mauvaise piste.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1601 Le 15/11/2011, à 15:37

Re : Ultimate Smash Friends: un smash bros like en python

#1602 Le 15/11/2011, à 18:10

Re : Ultimate Smash Friends: un smash bros like en python

#1603 Le 18/11/2011, à 20:35

Re : Ultimate Smash Friends: un smash bros like en python

#1604 Le 22/11/2011, à 01:10

Re : Ultimate Smash Friends: un smash bros like en python

#1605 Le 24/11/2011, à 21:42

Re : Ultimate Smash Friends: un smash bros like en python

#1606 Le 24/11/2011, à 23:08

Re : Ultimate Smash Friends: un smash bros like en python

#1607 Le 25/11/2011, à 00:05

Re : Ultimate Smash Friends: un smash bros like en python

#1608 Le 25/11/2011, à 00:08

Re : Ultimate Smash Friends: un smash bros like en python

#1609 Le 25/11/2011, à 00:59

Re : Ultimate Smash Friends: un smash bros like en python

#1610 Le 25/11/2011, à 10:28

Re : Ultimate Smash Friends: un smash bros like en python

#1611 Le 25/11/2011, à 14:06

Re : Ultimate Smash Friends: un smash bros like en python

#1612 Le 25/11/2011, à 21:38

Re : Ultimate Smash Friends: un smash bros like en python

#1613 Le 25/11/2011, à 21:54

Re : Ultimate Smash Friends: un smash bros like en python

#1614 Le 25/11/2011, à 22:43

Re : Ultimate Smash Friends: un smash bros like en python

#1615 Le 26/11/2011, à 00:29

Re : Ultimate Smash Friends: un smash bros like en python

#1616 Le 26/11/2011, à 00:43

Re : Ultimate Smash Friends: un smash bros like en python

#1617 Le 26/11/2011, à 09:09

Re : Ultimate Smash Friends: un smash bros like en python

#1618 Le 26/11/2011, à 11:18

Re : Ultimate Smash Friends: un smash bros like en python

#1619 Le 26/11/2011, à 11:24

Re : Ultimate Smash Friends: un smash bros like en python

#1620 Le 26/11/2011, à 11:38

Re : Ultimate Smash Friends: un smash bros like en python

#1621 Le 26/11/2011, à 13:45

Re : Ultimate Smash Friends: un smash bros like en python

#1622 Le 27/11/2011, à 19:26

Re : Ultimate Smash Friends: un smash bros like en python

#1623 Le 27/11/2011, à 20:51

Re : Ultimate Smash Friends: un smash bros like en python

#1624 Le 28/11/2011, à 14:19

Re : Ultimate Smash Friends: un smash bros like en python

#1625 Le 28/11/2011, à 15:40

Re : Ultimate Smash Friends: un smash bros like en python

Pied de page des forums