Ultimate Smash Friends: un smash bros like en python

moths-art · Le 28/11/2011, à 15:48

tshirtman : http://linuxfr.org/users/elessar/journa … ges-ultime
ça parle de la gestion des images dans des jeux vidéos : assez instructifs aussi sur l'évolution possible des formats d'image.

tshirtman · Le 28/11/2011, à 17:00

Heu, je vois pas en quoi ça se rapporte aux jeux vidéos là :] cela dit, merci quand meme, j'avais vu passer ce nouveau format, mais pas encore pris le temps de me plonger dedans...

edit: ah, j'ai vu que ça en parlais vite fait à partir des deux tiers de la page, mais rien de spécialement nouveau, c'est une technique classique, ça ne veux pas dire qu'elle est (encore) pertinente.

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

moths-art · Le 28/11/2011, à 18:10

Bon, c'est vrai que j'ai fait de gros raccourci et que c'est loin d'être aussi simple.
Pour les sites web, la réduction des requêtes HTTP fait que c'est vraiment hors sujet en effet.

Tu soulèves des problématiques tel que la fragmentation dans la ram : est-ce qu'elle est sujet à soucis comme dans un disque dur traditionnel (non ssd) ou vraiment négligeable?

C'est très délicat de trancher et j'avoue mon ignorance à ce niveau.
Je pense que le mieux serait de faire des tests de mémoire en confrontant des points de vues.
Maintenant, je peux comprendre que le dev de UFS est pour l'instant plus dans l'ajout de features que dans l'amélioration de son empreinte mémoire ou autre.

tshirtman · Le 28/11/2011, à 18:21

Ben RAM il me semble qu'on ne peux tout simplement pas fragmenter une donnée (contrairement à un DD), la machine donne un espace d'adressage à l'OS (qui n'est pas un mappage direct vers la mémoire physique, pour ça, voir le MMU, mais c'est un autre problème), et quand tu as un pointeur vers le début de ton objet, tu peux avancer de bits en bits jusqu'a la fin d'icelui, donc au démarrage du PC tout va bien, c'est tout vide, mais quand on a lancé et arrété pleins de trucs, on a une mémoire en gruyère emmental (on parle ici du stack ou tous les programmes piochent et non du heap qui est la mémoire assignée a un contexte d'execution, qui est de taille statique) bref, c'est assez compliqué, si je me souvient bien, l'algo qui gère ça a tendance à remplir les plus gros trous en premier (ça fait moins de gaspillage), et donc, il peut etre difficile de trouver des espaces mémoires de tailles suffisante si on manipule trop d'objets trop volumineux (et une texture décompressée, ça pèse vite ses dizaines de Mo).

Après, mes connaissances sur le sujets sont éparses aussi, et je n'ai rien contre le fait qu'on me montre que j'ai tords, ça me m'engage de toutes façons pas à changer quoi que ce soit dans l'immédiat .

Le dev d'USF, de mon coté, est un peu au point mort, par manque de temps, mais ça devrait reprendre après noel, si tout va bien...

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

doudoulolita · Le 29/11/2011, à 07:54

mini pods

Pour multitude4, j'aurais aimé incliner légèrement les pods pendant le jeu comme ci-dessus (c'est en taille réduite) mais on n'a pas ce qu'il faut pour ça, il me semble.
On pourrait diviser ces pods en 4 mini-blocks pour les coordonnées (ou plus pour des plate-formes mouvantes plus longues), et on donnerait les 4 coordonnées différentes pour chaque temps de l'animation (en escalier pour les pods penchés).
mini blocks
L'idéal serait de pouvoir avoir des mini-blocks de taille différente si on veut plutôt que tous identiques, et que leur taille puisse évoluer dans le temps.
Un peu comme si on mélangeait moving-blocks et decorum...
On peut imaginer aussi des plate-formes qui grossissent et se réduisent dans le temps ou se déforment, avec ce système.
Que pensez-vous de l'idée, les programmeurs ?

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

doudoulolita · Le 29/11/2011, à 08:41

@ moths-art : Pour le graphisme, ce que j'aime, c'est mélanger toutes les techniques.
Le vectoriel est très pratique pour animer rapidement les persos et faire des traits nets quand on en a besoin.
Un dégradé propre, ça peut aussi être utile, parfois.
La 3D, si on la texture et qu'on l'éclaire correctement, peut avoir un rendu sympa pas trop plastique.
Tout ça peut-être ensuite retravaillé avec Gimp pour ajouter des textures photo ou repeindre par dessus.
Sans oublier le scan de dessins sur papier (qu'il faut parfois encrer et nettoyer patiemment pour que ça rende bien sur écran), de textures ou de peintures !

Il manque d'ailleurs peut-être un équivalent de Painter dans les outils libres, avec le côté traditionnel de la peinture et les textures papier. Je ne crois pas que Mtpaint ait les mêmes performances, je ne l'utilise jamais, je dois dire.

Merci pour l'info sur les groupes de calques, je vais upgrader Gimp rapidement, dans ce cas !

Dernière modification par doudoulolita (Le 29/11/2011, à 08:47)

tshirtman · Le 29/11/2011, à 08:45

En fait, c'est probablement déjà réalisable avec un decorum et des moving blocs, a voir si c'est trop compliqué a synchroniser ou pas (tu peux donner une texture temporairement aux blocs pour voir comment ils évoluent) s'il faut on réfléchira a unifier les deux.

Dernière modification par tshirtman (Le 29/11/2011, à 08:45)

doudoulolita · Le 29/11/2011, à 09:07

Là, je crois que je te laisserai faire le xml, je ne vois pas trop comment faire pour l'instant.
La difficulté de multitude 4, c'est aussi que l'herbe passe devant les pods correctement. Il faut peut-être d'autres layers en plus du foreground et du middle. Ou alors ne faire incliner que les pods du milieu.
Tu trouveras tous les éléments ici (pods et éléments du tas d'herbe dans les sources): multitude4.zip

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

moths-art · Le 02/12/2011, à 17:36

Bonjour,

Tes réponses sur la mémoire m'ont pas mal travaillé 'tshirtman', du coup j'ai voulu en savoir un peu plus.
Après une pérégrination web des plus chaotique et quelques tests sur la mémoire (j'ai fait des gcore -o mem_name PID puis j'ai parcouru le fichier généré pour retrouver des motifs.) j'ai déduis ceci :

Certes, dans USF les fichiers images sont décompressés dans la RAM mais ce n'est pas forcément le cas de tous les softs.
Pourquoi : parce que c'est la lib SDL (j'ai parcouru les sources, une bonne prise de tête), directement appelé par Pygame, qui utilise des 'Surfaces' (un genre de canvas) pour afficher ses images.

Bref, la question reste entière sur l'utilisation de sprites sur des fichiers séparés ou non : là où j'ai du mal à comprendre c'est que les tutos SDL conseils l'utilisation d'une grosse image contenant des sprites. Pourquoi? Faudrait tester...

Parallèlement à ça, j'ai commencé un 'character editor' en gtk...
C'est loin encore d'être fonctionnel et mature mais ça donne déjà une idée :
https://github.com/mothsART/ultimate-smash-friends

Le but à terme est d'avoir une timeline, une fenêtre de rajouts d'images etc.

J'ai également modifié le 'cv.py' pour mes besoins : principalement comprendre l'existant.
Y'a un problème certainement de 'dirlist' qui fait planter son lancement quand les dossiers rohon et robot existent.
(certainement car le xml n'est pas finalisé)
Je n'ai pas clairement identifié le problème, j'ai juste supprimé ces 2 dossiers.
J'avoue que c'est bourrin et indélicat mais j'ai préféré me concentrer sur d'autres choses.

Merci de vos retour.

tshirtman · Le 02/12/2011, à 21:48

moths-art a écrit :

Bonjour,
Tes réponses sur la mémoire m'ont pas mal travaillé 'tshirtman', du coup j'ai voulu en savoir un peu plus.
Après une pérégrination web des plus chaotique et quelques tests sur la mémoire (j'ai fait des gcore -o mem_name PID puis j'ai parcouru le fichier généré pour retrouver des motifs.) j'ai déduis ceci :
Certes, dans USF les fichiers images sont décompressés dans la RAM mais ce n'est pas forcément le cas de tous les softs.
Pourquoi : parce que c'est la lib SDL (j'ai parcouru les sources, une bonne prise de tête), directement appelé par Pygame, qui utilise des 'Surfaces' (un genre de canvas) pour afficher ses images.

En effet, je ne l'ai pas précisé, ce n'est pas forcément le cas pour tous les programmes, mais quand on a besoin de manipuler l'image (ce que permet pygame), c'est la forme décompressé et en format de pixel bien précis que tout ça finit, et les headers ne servent plus vraiment, la surface stoque la taille, le format et la profondeur de pixels, c'est pas grand chose.

Bref, la question reste entière sur l'utilisation de sprites sur des fichiers séparés ou non : là où j'ai du mal à comprendre c'est que les tutos SDL conseils l'utilisation d'une grosse image contenant des sprites. Pourquoi? Faudrait tester...

J'en ai parlé avec un collegue plus calé que moi, pour lui, ça se justifie pour les optimisations en OpenGL, mais dans le cas qui nous occupe (SDL n'utilisant pas l'accéleration graphique), il est d'accord que je ne gagnerait rien, et perdrait les optimisations que je ferait actuellement, à retourner sur un format a une ce type. Je pense que pour le reste, il s'agit surtout de vielles habitudes, et la fierté qu'auront beaucoup de programmeurs a utiliser une telle technique, qu'elle soit justifiée ou pas.

Parallèlement à ça, j'ai commencé un 'character editor' en gtk...
C'est loin encore d'être fonctionnel et mature mais ça donne déjà une idée :
https://github.com/mothsART/ultimate-smash-friends

\o/

Le but à terme est d'avoir une timeline, une fenêtre de rajouts d'images etc.

cool , si t'as besoin d'explications sur le format xml des persos, ou tout autre chose, n'hésite pas à poser des questions.

J'ai également modifié le 'cv.py' pour mes besoins : principalement comprendre l'existant.
Y'a un problème certainement de 'dirlist' qui fait planter son lancement quand les dossiers rohon et robot existent.
(certainement car le xml n'est pas finalisé)

Ah oui, c'est probable, je ne l'ai pas relancé après l'"ajout" de robot, il faudrait que je prenne le temps de découper/nommer les pauses, et mettre un xml de base.

Je n'ai pas clairement identifié le problème, j'ai juste supprimé ces 2 dossiers.
J'avoue que c'est bourrin et indélicat mais j'ai préféré me concentrer sur d'autres choses.

No soucy, on verra au moment de la pull request, pour merger tout ça

Merci de vos retour.

Je vais tester ça

edit:
Je viens de tester, et c'est un bon début . ça fait un peu plus propre que mon cv.py, et du coup, ce sera possible de rendre les interactions un peu plus intuitives .

Dernière modification par tshirtman (Le 02/12/2011, à 21:58)

doudoulolita · Le 04/12/2011, à 22:00

Je viens de récupérer USF sur git.
Voilà ce que j'ai pour cv.py:

laurence@laurence-desktop:~/Bureau/laurence/ultimate-smash-friends/utils$ python cv.py
  File "cv.py", line 307
    * 2)) + (int(time.time() * CONFIG.general.WALKSPEED']) % 200 if
                                                                  ^
SyntaxError: EOL while scanning string literal

tshirtman · Le 04/12/2011, à 22:05

En effet, je n'ai pas mergé la correction de moths-art pour l'instant, la suppression des deux persos m'embète un peu pour ça, je vais regarder.

edit: bon, j'ai mergé sa branche, et j'ai ajouté à nouveau les deux persos non finit, par contre, j'ai mis que quand on appelle cv.py sans paramettre, il charge seulement les persos "finis". On peut toujours lui demander de charger un perso non finis en lui passant le nom du perso.

pour mettre à jours

git pull

dans ton dossier.

Dernière modification par tshirtman (Le 04/12/2011, à 22:14)

doudoulolita · Le 04/12/2011, à 23:53

lila kick.gif Après static, walk et hit, j'ai travaillé le kick de Lila.
Elle avance doucement mais surement, toujours en me basant sur les vidéos de ma nièce. J'ai revu légèrement la coiffure qui était un peu raide à mon goût, je ne sais pas si ça se voit. J'ai bien sûr repris sur tous les frames.

tshirtman · Le 04/12/2011, à 23:55

Ah, c'est bien fluide ça! j'aime

je l'ai ajouté dans le dépot dans characters_unfinished, du coup

Dernière modification par tshirtman (Le 04/12/2011, à 23:58)

moths-art · Le 05/12/2011, à 16:14

Week-end pluvieux : ça m'a permis d'avancer légèrement.
Je voulais intégrer des boutons de lecture : pour cela, pas d'autre choix que d'utiliser les threads sous gtk.
C'était un peu folklorique car j'ai dût sortir gdb un moment pour identifier une superbe erreur provenant de Python et de sa gestion des threads (en gros, le mélange avec gtk réserve quelques surprises : c'est peut-être dût aux version un peu obsolète de mes libs...)

Le résultat : la possibilité d'appuyer sur 'play' et 'stop' pour chaque personnage et chaque mouvement!
Pour l'instant, la lecture est automatiquement en boucle (c'est ce qui était le plus chaud donc j'ai commencé par là)
mais à terme, je devrais chercher la valeur 'repeat' dans le xml afin de déterminer le nombre de boucle.

Comme cv.py, je me concentre actuellement sur la lecture du xml.
Une fois celle-ci bien opérationnel, je me pencherais sur l'écriture...

Merci de vos tests.

tshirtman · Le 05/12/2011, à 16:26

Pour la valeur "repeat", en fait, ne t'en préoccupe pas trop pour l'instant, je crois bien qu'elle n'a jamais servis autrement que pour une répétition infinie, et je crois la marche est le seul cas ou ça arrive.

Effectivement, il me semble qu'avec gtk les threads peuvent révéler quelques surprises, mais je ne me souvient pas de m'en être servis dans le premier éditeur que j'avais codé (qui ne faisait presque rien, et donc le code n'était pas très sauvable) viewer.pyw.
https://github.com/tshirtman/ultimate-s … r.pyw#L290
apparement je faisais ça via la boucle d'évenements de gtk.

Mais tu fais bien comme tu veux , tant que ça marche.

edit: je viens de tester, ça pose problème quand on quitte, les threads :]

j'ai fais un peu de nettoyage et j'ai mergé, ça fait plaisir de s'en sortir avec git maintenant j'aurais mis le temps ^^, pense à puller depuis mon dépot pour avoir les (petits) changements.

Dernière modification par tshirtman (Le 05/12/2011, à 16:36)

doudoulolita · Le 07/12/2011, à 10:22

Pour le programme de moths-art, n'oubliez pas que c'est pour les characters unfinished qu'il sera le plus utile. Et que ce n'est pas le temps qui est le plus difficile à gérer pour un graphiste mais les hardshapes et les vecteurs (en tout cas pour moi).

Pour la marche, c'est mieux si ça ne défile pas trop sinon, on ne voit rien, mais si on peut stopper là où on veut, ce sera super. Du coup, la valeur repeat n'est pas trop utile à récupérer.

Je suppose que moths-art a prévu de pouvoir appeler les fichiers images depuis le programme avec un bouton "parcourir" par exemple ? Comme ça on peut intégrer une nouvelle image facilement et rapidement.
Il faudrait que quand on se place dans la timeline à une frame précise et qu'on appelle l'image, celle-ci se place automatiquement au bon moment.
Si on se remet au même endroit dans la timeline et qu'on fait "parcourir", la nouvelle image remplacerait automatiquement la précédente.

Pour les hardshapes, ce serait bien de pouvoir les corriger dans le programme plutôt que dans le xml, avec soit des chiffres à changer, soit, encore mieux, un cadre dont on peut cliquer-glisser les bords. Mais ça, ça doit être difficile à faire !
Et pouvoir comparer tous les persos (finis ou non) pour les vecteurs des agressiv points, afin d'harmoniser la force des coups. Si on pouvait agrandir et réduire les vecteurs ou les déplacer dans le programme par clique-glisser des 2 points de début et de fin, ce serait génial.

---------------------------------------------------------------------------------------------
Je suis contente que l'animation de Lila vous plaise. Avec 8 frames par mouvement, c'est super fluide, et le principe de la motion capture (manuelle) fonctionne bien.
J'aurai plus de mal pour les mouvements que ma nièce n'a pas faits (rouler) ou ceux impossibles à faire pour elle (genre salto)

Dernière modification par doudoulolita (Le 07/12/2011, à 10:37)

moths-art · Le 07/12/2011, à 12:09

Bon, Doudoulolita : des nouvelles du front!

J'ai créé une branche spécialement pour mon dev (c_editor) convenu avec tshirtman.
Une fois que ça deviendra vraiment utilisable sur certains points ça à dire modification du xml à partir du soft, alors je mettrais en place un système de Tag pour que les graphistes puissent l'utiliser sans corrompre un xml avec une version en dev.

Tu donnes l'exemple de la marche : en effet, j'ai mis en place un bouton lecture/stop, des déplacements de frame en frame (previous et next) et la possibilité d'aller au début ou à la fin de l'animation.
C'est déjà opérationnel, je t'invites même à tester et donner tes retours si besoin.
Pour la timeline, je viens juste de commencer à travailler dessus : j'ai une idée précise de ce que je veux obtenir mais le temps et quelques détails techniques me frustre à son avancé rapide!
(tu peux également te donner une idée sur le dernier commit)

Comme tu l'évoques si bien, le but sera effectivement d'insérer/modifier/supprimer les fichiers images facilement.
Tu remarqueras que ma timeline est en fait une succession de boutons cliquables :
Pour chacune, on pourra lancer une fenêtre avec la possibilité de paramétrer le temps, le hardshape et chercher l'image s'y référant.(avec un bouton parcourir effectivement)

Pour les frames que l'on veut rajouter, je mettrais un bouton '+' qui lance la même fenêtre et qui place la frame après la sélection courante.
Par la suite, il sera aisé de déplacer chaque frame avec un glissé->déposé.

Pour la valeur 'repeat', j'ai vu avec tshirtman, elle est soit à 0 soit à -1 donc soit pas de répétion soit répétion à l'infini.
Cette valeur n'a pas de vrai sens au niveau de l'animation en effet.
Cependant, à terme : le soft a pour vocation de créer/modifier graphiquement le xml intégralement.
Du coup, il sera possible de déterminer si tel ou tel animation d'un personnage doit être répété dans le jeu. (ça sera visible par un bouton à cocher)

Doudoulolita : j'avais bien compris votre besoin sur des 'character unfinished', seulement, je voulais déjà avoir un bon existant avant de gérer correctement le xml.
Le problème qui à déjà apparu avec 'cv.py', c'est qu'il est délicat de gérer un xml partiel ou mal formé car il risque de planter le soft. (les mélange entre xml fait à la main et gérer par un soft sont toujours à prendre avec des pincettes : en général on utilise une dtd ou un xml shéma pour valider ça...)
Pour les hardshapes, les vecteurs et les aggressiv-point, j'ai besoin d'explication pour avancer.
Je ne comprend pas vraiment leur utilité ou leur fonctionnement.

Bon, faut pas trop s'enflammer non plus... j'ai pas de pouvoir divin! ;)
Y'a pleins de trucs que j'aimerais dev mais faut déjà être réaliste et pas être trop ambitieux pour ne pas baisser les bras... et voir que ça avance.
La gestion d'un projet c'est tout un art surtout si c'est "bénévole".
Tout ce qui est gestion de vecteurs graphiquement, avant que ça soit vraiment opérationnel, ça va demander quelques cafés, quelques cheveux voir quelques ongles pour d'autres.
------------------------------------------------------------------------------------

Pour les saltos de Lila, j'ai une solution : tu lui paye un tour de trampoline (3 à 4 euros) à la fête foraine et tu l'as filme!
Plus sérieusement, tu dois avoir des persos en 3D qui font ça sous blender par exemple.

Dernière modification par moths-art (Le 07/12/2011, à 12:09)

doudoulolita · Le 09/12/2011, à 09:16

@moths-art: merci pour toutes ces explications. on projet semble correspondre aux besoins des graphistes, dont je fais partie.
Une hardshape est un rectangle correspondant à la partie dure, elle est plus petite que les images, elle contient la tête, le tronc et les jambes mais pas forcément les bras. On peut en préparer une de base pour chaque pose à modifier suivant le personnage, par exemple.
Les vecteurs et les agressiv-points montrent la direction et la force des coups. Graphiquement, c'est donc juste une ligne. Tshirtman te donnera des explications plus techniques.
pour moi, ce serait bien de pouvoir cliquer-glisser les bords de la hardshapes et les points de début et de fin des vecteurs.

moths-art · Le 14/12/2011, à 17:41

Doudoulolita : j'ai bossé pas mal ces derniers temps sur la timeline et le hardshape.

Pour la timeline, je pense être au bout de mes peines et il reste plus qu'à tester, remonter les bugs et éventuels améliorations.
J'ai créer une possibilité de zoom pour améliorer sa prise en main. (qui est volontairement désactivé en mode lecture car les appels de ré-affichage sont vraiment délicates à gérer dans ce cas là)

Pour le hardshape, ça commence à correspondre à tes attentes mais comme tu l'as précisé, c'est loin d'être l'élément le plus facile...
J'ai donc pour l'instant l'affichage du rectangle en question par dessus l'image.
La possibilité de le modifier par glissé/déposé est en cours : il faudrait je pense d'abord la possibilité de zoom de l'image pour que ça est du sens.
Je veux également permettre un contrôle plus fin avec des spins buttons, les 2 options seront "connectés" à terme.

Pour l'instant, j'ai créé ça dans une fenêtre à part mais je viens de me rendre compte que c'est ergonomiquement pompeux.
J'imagine que le mieux sera de pouvoir ouvrir un 'panneau latéral' pour chaque modification de frame et visualiser directement le hardshape, les vecteurs et les agressiv-points.
On verra ça par la suite, je vais déjà me concentrer sur du fonctionnel.

Merci de vos retours afin de ne pas m'embarquer dans du dev inutile.

tshirtman · Le 14/12/2011, à 18:18

super, je regarde ça ce soir

doudoulolita · Le 03/01/2012, à 20:39

Juste pour vous souhaiter une bonne année

moths-art · Le 07/01/2012, à 09:20

Bonne année également!!
Voici les news pour 2012 :

1. Correction de bugs assez pernicieux dans la timeline
2. Utilisation d'une sidebar plutôt qu'une fenêtre externe pour les modifications d'une frame :
J'ai préférer pallier à ce déconvenue ergonomique le plus rapidement plutôt que de m'arracher les cheveux par la suite et entrainer des éventuels régressions.
3. Image centré : y'a encore un peu de taf pour que ça soit exactement au top...
4. Contrôle grossier via la souris et fin via les "spinbuttons" du hardshape!
Ca c'est le gros du boulot... et j'en suis pas peu fier!
Je crois, Doudoulolita que le père noël, bien que très en retard, va exhausser tes voeux.
Petite anecdote caché : j'ai des amis qui sont allés à la messe de minuit à noël: le prêtre se prénommait "Noël"...
Il se désignait donc comme le père noël!!
Vous remarquerez que les modifs de la souris impactent automatiquement les spinbuttons.
De même, le choix d'une nouvelle frame met à jour le harshape et les spinbuttons.
Enfin, j'ai volontairement une accroche de la souris à +ou- 5 pixels afin de gagner en confort.
Le code est forcément un peu pompeux (désolé tshirtman ) mais j'ai préféré m'attacher au fonctionnel avant d'optimiser la chose.
En plus, vu que c'est une des partie un peu obscur, je ne suis pas certain qu'une optimisation risque d'être bien venu...

Petite question : un hardshape est obligatoire pour une image?
Si oui, je pense que lors du rajout d'une frame, le hardshape prendra automatiquement la taille de l'image.
Ça m'évitera de retoucher à du code sensible juste pour sa création...

Bon, l'idée est de vous soumettre déjà ça afin de bien correspondre à vos attentes.
Si oui, j'attaquerais sans doute dans l'ordre :

* widget de zoom sur les images.
* système de vecteur pour les aggressiv points.
* Maintient des modifs en ram.
* Enregistrement des modifs cad maj des fichiers xml.
* Mise en place de boutons "undo/redo" (je vais réutiliser le procédé de mypaint que j'ai déjà éprouvé en fournissant des patchs)
* Possibilité de création/suppression de frame voir des glissé/déposé...
* Possibilité de création de personnage
* peaufinage de l'interface
* système de préférence

tshirtman · Le 07/01/2012, à 11:31

moths-art a écrit :

Bonne année également!!
Voici les news pour 2012 :
1. Correction de bugs assez pernicieux dans la timeline
2. Utilisation d'une sidebar plutôt qu'une fenêtre externe pour les modifications d'une frame :
J'ai préférer pallier à ce déconvenue ergonomique le plus rapidement plutôt que de m'arracher les cheveux par la suite et entrainer des éventuels régressions.
3. Image centré : y'a encore un peu de taf pour que ça soit exactement au top...
4. Contrôle grossier via la souris et fin via les "spinbuttons" du hardshape!
Ca c'est le gros du boulot... et j'en suis pas peu fier!

En effet, c'est super cool

Je crois, Doudoulolita que le père noël, bien que très en retard, va exhausser tes voeux.
Petite anecdote caché : j'ai des amis qui sont allés à la messe de minuit à noël: le prêtre se prénommait "Noël"...
Il se désignait donc comme le père noël!!
Vous remarquerez que les modifs de la souris impactent automatiquement les spinbuttons.
De même, le choix d'une nouvelle frame met à jour le harshape et les spinbuttons.
Enfin, j'ai volontairement une accroche de la souris à +ou- 5 pixels afin de gagner en confort.
Le code est forcément un peu pompeux (désolé tshirtman ) mais j'ai préféré m'attacher au fonctionnel avant d'optimiser la chose.

C'est pas grave, ça peu s'améliorer par la suite, si on essaye de tout faire parfait directement, on fait rien.

En plus, vu que c'est une des partie un peu obscur, je ne suis pas certain qu'une optimisation risque d'être bien venu...
Petite question : un hardshape est obligatoire pour une image?
Si oui, je pense que lors du rajout d'une frame, le hardshape prendra automatiquement la taille de l'image.
Ça m'évitera de retoucher à du code sensible juste pour sa création...

Tu peux en créer une automatiquement à la taille de l'image oui, normalement si tu n'en crèe pas il doit utiliser la hardshape de base du perso, mais je ne suis pas sur que ce soit une bonne idée, je crois que toutes ont des hardshapes actuellement, je n'ai pas vérifié récemment si ça marchait bien comme prévus (le fallback).

Bon, l'idée est de vous soumettre déjà ça afin de bien correspondre à vos attentes.
Si oui, j'attaquerais sans doute dans l'ordre :
* widget de zoom sur les images.
* système de vecteur pour les aggressiv points.
* Maintient des modifs en ram.
* Enregistrement des modifs cad maj des fichiers xml.
* Mise en place de boutons "undo/redo" (je vais réutiliser le procédé de mypaint que j'ai déjà éprouvé en fournissant des patchs)
* Possibilité de création/suppression de frame voir des glissé/déposé...
* Possibilité de création de personnage
* peaufinage de l'interface
* système de préférence

Bon programme tout ça

je viens de tester, c'est super! (le controle du hardshape à la souris c'est génial!) J'ai juste l'impression qu'il y a un manque de fluidité dans la mise à jours entre deux frames en mode "play". en tout cas, je vais regarder pour merger ça déjà

Dernière modification par tshirtman (Le 07/01/2012, à 11:33)

moths-art · Le 07/01/2012, à 12:02

Bon, je viens de créer une première version des boutons de zoom... c'est pas encore top mais ça permet de se donner une idée!
Pour les problèmes de fluidité, c'est pas toujours simple : j'ai eu quelques déboires sur le hardshape à la souris.
En fait, le problème est identifié depuis quelques temps et il est sans doute multiple :
1. les accès au disque pour chaque image.
Il faudrait que je crée des pixbufs (image en mémoire) pour toutes les frames d'une timeline.
2. les mises à jour de la sidebar ne devrait pas être actif pendant une animation : ça veut dire retoucher au code de la timeline pour gérer ça correctement : je me suis donné un petit temps d'accalmie pour me concentrer sur des choses plus excitantes.
Je ne l'avait pas évoqué mais c'est vrai que c'est pénible...

stay tuned, ça arrive...

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1626 Le 28/11/2011, à 15:48

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

#1627 Le 28/11/2011, à 17:00

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

#1628 Le 28/11/2011, à 18:10

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

#1629 Le 28/11/2011, à 18:21

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

#1630 Le 29/11/2011, à 07:54

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

#1631 Le 29/11/2011, à 08:41

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

#1632 Le 29/11/2011, à 08:45

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

#1633 Le 29/11/2011, à 09:07

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

#1634 Le 02/12/2011, à 17:36

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

#1635 Le 02/12/2011, à 21:48

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

#1636 Le 04/12/2011, à 22:00

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

#1637 Le 04/12/2011, à 22:05

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

#1638 Le 04/12/2011, à 23:53

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

#1639 Le 04/12/2011, à 23:55

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

#1640 Le 05/12/2011, à 16:14

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

#1641 Le 05/12/2011, à 16:26

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

#1642 Le 07/12/2011, à 10:22

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

#1643 Le 07/12/2011, à 12:09

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

#1644 Le 09/12/2011, à 09:16

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

#1645 Le 14/12/2011, à 17:41

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

#1646 Le 14/12/2011, à 18:18

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

#1647 Le 03/01/2012, à 20:39

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

#1648 Le 07/01/2012, à 09:20

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

#1649 Le 07/01/2012, à 11:31

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

#1650 Le 07/01/2012, à 12:02

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

Pied de page des forums