GPArt, c'est pour quand? :) - Page 2

J'comprends toujours pas le coup du jpeg carre.
Tu dis que t'arrivais qu'a decompresser des images de dimension type 100x100 ou 200x200 ou 1234x1234 et pas des images 640x480 par exemple ?
C'est sacrement etrange, la libjpeg c'est un truc bien standard (bien qu'implemente de facon un peu space), ca fonctionnait tres bien pour moi (les images sur lesquelles je bossais etaient de taille 384x256).
J'ai encore le source sous la main, c'etait la jpeglib Version 6b. Toute tassée, la fonction typImage readjpeg(char * nomDeFichier) que j'ai faite et qui utilise a fond la libjpeg doit tenir en 25 lignes.
Par contre, j'ai pas de code source pour la sauvegarde, j'avais juste eu besoin de faire de la lecture.

bah je te jure que quand je read un Jpeg pas carre, ca me donne genre un fichier encrypter avec un decalage de 1 pixel par couleurs, bref un truc imonde impossible a expliquer!
Un truc de fou! Ca arrive souvent en code! ^^

Tu veux qu'on essaye de voir ce qui passe pas dans ton code et qui a l'air de fonctionner chez moi ?
Ou alors c'est pas super important, ou c'est pas grave, ou t'as laisse tomber, ou c'est a la poubelle, ou t'as plus envie de parler de ca et on laisse tomber.
Comme tu veux, moi ca me gene pas de jeter un coup d'oeil (mais vu l'etat actuel de mon pc, j'crois qu'il faudra que j'attende mardi pour tester si tu m'envoies des lignes de code a compiler)

Bah j espere que ta le bide bien accrocher, c est du porc de chez porc(bon y a pas que mon code dedans, le reste c est le autres, moi j ai quelques outils et les enregistrements sous divers format!) mais je sais que la libJpeg est toute conne a utilise(tout est fait!) mais pour une raison X(ou peut etre Y) ca veut pas avec autres chose que des JPEG Carre!
Mais il est vrai que je m en fou, c est un projet de fin d annee, et c est moi qui organise la soutenance(grosso modo les bugs on les montre pas! ^^). Mais c est gentil a l occassion peut etre, la deja faut que je fasse le pot de peinture et la baguette magic(truc qui me casse un peu les Coui??es).

Serieux ???????? Tu vas rire, qu'est-ce qu'il y avait dans un projet fait dans un cours a bac+4: la baguette magique ! (et le pot de peinture, c'est pareil a programmer, voir plus facile)
EDIT du post: en parlant de pot de peinture..... et si on rajoutait ca dans gpArt ?

signé: la loutre qui risque d'avoir besoin de se programmer vite fait une sorte de baguette magique sur le zBuffer la semaine prochaine (le monde est rempli de coincidences)

P.S: bon, je suppose qu'en plus de bosser sur des trucs sur lesquels je bosse aussi, t'es pas une jolie fille qui aurait envie qu'on aille ensemble au resto pour parler d'algo de pot de peinture un soir (On sait jamais...)

le pot de peinture c'est facile à faire avec une fonction récursive qui analyse les pixels aux alentpurs et verifie sil peut le remplir. Le pb c'est qu'on arrive vite a surcharger la pile et Crash. J'ai fais qq essais mais ce n'est pas ma priorité actuellment.

je serais très intéressé si vous portiez la lib jpeg sur GP32....Ca serait cool pour toute sorte d'appli, jeux......Qu'est-ce que vous en dites ?

Sinon GPART ne disposera pas de fonction pot de peinture. Je veux que ce petit utilitaire reste basique. Une sorte de petit soft de graffiti rien de +.

Pour moi il s'agit + d'un exercice pour pouvoir coder un autre soft + consistant.
(avec menus etc....) Mais là, je vous livre une info ultra confidentielle

pot de peinture c'est juste un algo classique de recherche operationnelle... comme celui de mon lk go pour manger les pierres, sauf qu'il peut y avoir une certaine tolerance.

encore plus faciile: le pot de peinture qui s'applique aux pixels eloignés. meme pas besoin d'algo de parcours de graphe, un simple parcours de tableau suffit...

Lapkill - >Nan mais la c est plus un pot de peinture!(et c est meme pas drole a code! ^^)

Moi je veux un vrai pot, et en recursif il marche y a pas de doute, mais le prof a fait "Heu c est long" et j ai fais "oui desole!"
Donc la j ai fait la meme version iterative, elle doit marcher! En theorie, ^^

Yaouank - > Nan desole, je suis bien un homme et j aime les filles! ^^
Le monde est injuste!

Conseil du jour:
Le pot de peinture ou la baguette magique en recursif ? C'est sur que c'est la meilleure methode pour exploser la pile.
Le mieux c'est de creer sa propre pile (un machin a taille variable, qui grandit quand il est plein) et de faire un truc du genre:
(version pot de peinture)
- mettre le pixel de depart dans la pile
- tant qu'il reste des points dans la pile
- prendre le premier/dernier point de la pile (pour premier/dernier, les deux marchent mais un est sacrement plus lent, ca depend comment on a concu la pile)
- si sa couleur est noir
- colorier le point dans la couleur demandee
- rajouter les 4/8 points autour de ce point dans la pile
- fin si
- fin tant que

Voila. J'ai essaye de faire court. Ca marche mais ca doit etre ameliorable (comme en regardant la couleur des points avant de les mettre dans la pile pour essayer de garder une taille raisonnable a la pile. Mais faire ca, ca rajoute quelques autres modifs a l'algo)

P.S: j'pense que c'est pas la peine de vous ecrire la structure et les fonctions de gestion de la pile, si ?

C est vrai qu il marche pas sur de grosse image mon truc(the pile fait pouffff!) Mais bon c etait du depannage a la veille de soutenance! ^^
Donc comme je le disais on montre pas les bugs! ^^

sur GP32 cegenre de fn récursive peut remplir des surfaces de 30*30 pixels. Au delà il y a explosion de pile. Bien sûr, c'est une valeur empirique.

30 30 ca fais quand meme minimun 900 appel, c est toujours sympa! ^^

oui c'est déjà pas mal
faudrais pouvoir libérer la pile et continuer le processus.
C'est vrai que l'idée de créer une pile est intéressante.

petite pensee du jour: Le C, c'est pas du prolog, evitez au maximum les fonctions recursives, preferez une boucle.
Moi je vous conseille d'effacer vite fait de votre memoire l'idee de faire du remplissage par une fonction recursive, vous allez avoir que des merdes.

P.S: sinon pour le coup des 900 appels, je pense plutot que quand pékélé a ecrit son truc c'etait plus sous la forme d'un "parcours d'arbre en profondeur d'abord" (desole des termes compliques) et qu'il y avait maxi 30 appels reccursifs consecutifs. Je me trompe peut etre mais je crois que c'est plutot dans cet ordre de grandeur le nombre d'appels recursifs que le C peut gerer avec les reglages par defaut.

59 appels recursifs max, en fait, pour le cas particulier oule parcours fait la diagonale complete

humm, ouiap, mais ta pile(de recursion! Je sais pas si ca se dit!) en C elle fait bien 4000 et des patates nan?

Qui c'est qui va tester ?
Et pour lui donner un peu de poids dans la pile, faites une fonctions avec quelques arguments du style:
void recursif (int niveau, int x, int y, unsigned char couleurR, unsigned char couleurG, unsigned char couleurB, unsigned char *imageR,unsigned char * imageG, unsigned char *imageB, int largeur, int hauteur)

Perso, j'peux pas encore le faire, dans ma liste de projet j'en ai 2 qui passent en priorite avant l'installation d'un sdk gp32: 1- reinstaller windows pour qu'il soit plus tout moisi et qu'il reconnaisse l'usb 2- essayer de reparer ma carte memoire smc qui a eu un leger probleme pendant une copie et qui est desormais inutilisable.

YaouanK, a la recherche d'un lecteur de carte smc en usb compatible avec "cardwiper" le formateur de carte memoire, ma derniere chance.

Oula ça devient trop techniquepour moi
je posterai ma source de fn de remplissage récursive à mon retour de vacances.
j'ai bien essayer de la repasser en boucle mais sans succès. j'y arrive mieux dans l'autre sens

pour la SMC, il m'est arrivé la même chose en transferrant + que la capacité.
Le seul moyen que tout rentre dans l'ordre a été de la formater.

je vais faire court parce que c'est pas trop l'endroit pour poster ca. windows a crashé pendant un transfert avec mon lecteur de carte smc sur port parallele.
Resultat:carte hs qui fait crasher la gp32 au demarrage (l'intercepteur de bug du multifirmware m'affiche la memoire et les registres).
-Je boot avec une autre carte sur pacrom, j'echange les cartes, je demande format a pacrom "done. 1 bad block".
-le "recover smc" du bios standard me dit "0 pb".
-le lecteur de carte memoire sur port parallele: "carte illisible, formater ? - capacite 3Mo - formatage impossible" (note: c'est une 64Mo)
-carte formatee avec un app photo numerique, la carte passe dans la gp32 mais n'est toujours pas reconnue par le lecteur de carte du pc. C'est mieux que rien mais je voudrais qu'elle fonctionne partout
-j'ai trouve un soft sur internet qui est cense me formater la carte mais il lui faut un lecteur smc usb. avec un peu de chance, je devrais reussir a mettre la main sur un demain (ca fait 10j que je l'attends, le gars qui a les cles de l'armoire etait en vacances)

P.S: le lecteur smc fonctionne avec la 16Mo qui n'est pas a moi et que j'utilise comme smc non crashee pour booter sous pacrom. A priori, le pb vient vraiment de la carte smc 64Mo et non du lecteur comme on me l'a suggere.

Je vois pas pour ton pb.

Sinon, la bonne nouvelle, c'est que je suis de retour de vacances et que je vais pouvoir me remettre sérieusement à GPART.

J'ai commande un nouveau lecteur de carte sur cdiscount hier. 20 euros. Meme si la carte n'est pas formatee parfaite (si elle l'etait elle passerait sur mon lecteur actuel), je devrais reussir a la lire sur le pc. Les nouveaux lecteurs sont plus stables que les anciens sur port parallele avec drivers a installer (jamais mis a jours par le vendeur)

Private: Manoloben, mail envoye. C'est pas encore au niveau de la version que j'avais mais ca devrait fonctionner. C'est le principal.

Une question sur GPArt:
Pourra t'on sauvegarder en GPG

ben ça pourrait éventuellement se faire, mais faut pas attendre de multiformat dès la 1ère release

Bon ben voilà les dernières news.
j'ai donc créer mon propre format ".art"
les sauvegardes fonctionnent.
Pour l'instant je n'ai pas implanté de compression.
La capture de l'écran en 16 bit crée un fichier de 150 k ce qui est raisonable.

Je vais maintenant attaquer le chargement des images enregistrées et je ferai une release public. le logiciel ne sera pas fini mais permettra à tout t'un chacun de s'amuser.

Je tient à annoncer officellment que mon soft ne sera pas un freeware !!!

et oui ce sera un drawinware.
Si vous l'utilisez vous vous engagerez à m'envoyer au moins une de vos création lol

T'as pas peur de faire des cauchemars avec nos creations ?
Et tu feras une page web avec tous les drawing qu'on t'enverra (ou au moins certains histoire de montrer ce que les gens arrivent a faire, en beau comme en moche).
YaouanK, la loutre qui dessine comme ses pieds (et vous imaginez meme pas comment c'est dur d'utiliser la gp32 avec ses pieds)

Et bien j'espère que Fx me fera une petite page pour GPART sur GP32news

Bon voilà ! j'ai réussi.
Maintenant on peut sauvegarder son oeuvre et la charger au format .art . Ce dernier n'est pas encore compressé.
Pour l'instant le fichier est écrasé à chaque sauvegarde. J'implanterai plus tard le chargement de plusieurs fichiers.

Mais celà est déjà suffisant pour une 1ère release publique de la bêta.
Donc juste le temps de faire un écran d'intro et de fin et ce sera dispo.
surveiller bien les news sur [url]www.gp32news.com [/url]

Chouette, chouette, chouette, on vas pouvoir dessiner avec la gp!!!!
En plus, c est une super idee le drawinart!!!
Bonne contiunuation, et ate de tester Gpart!!!

Cool Pékélé, j'ai hâte de voir ça

(même pas 1 petit RLE dans ton format ART?)

heu....ça dépend..Mais ça risque de prendre un certain temps...alors que là on peut commencer à s'amuser même si ce n'est pas complétement finit.