Choix d'une lib graphique pour coder en C - Page 3

Merci Jyaif. Je ne suis pas chez moi, donc pas réactif et sans outils ^^

J'avais vu pour la transparence, mais n'y a-t-il pas moyen de coller des images dont le format gère nativement la transparence (png dans mon cas) ? La surface n'a-t-elle pas directement cet attribut si l'on ouvre un tel fichier, en utilisant SDL image ? Je crois que si. Mais bon, je ne peux faire aucun teste jusqu'à demain ^^

PpHd -> Ok. ^^

Folco (./61) :
n'y a-t-il pas moyen de coller des images dont le format gère nativement la transparence (png dans mon cas) ? La surface n'a-t-elle pas directement cet attribut si l'on ouvre un tel fichier, en utilisant SDL image ?

Je ne sais plus. Avec SDL, tu ne peux ouvrir que des bmp, donc ce n'est pas possible. Avec SDL_Image, peut être.

Ah Jyaif, tu faisais référence à ça en me parlant d'une grande image qui en contient plusieurs ?
int SDL_BlitSurface(SDL_Surface *src, SDL_Rect *srcrect, SDL_Surface *dst, SDL_Rect *dstrect);
Suffit après de sélectionner le rectangle qui va bien dans l'image source pour l'afficher, et ça permet de grouper plein d'images en effet.

Et sinon, si j'utilise des BMP, il me faut une couleur transparente. Ca se choisit comment ? On prend au pif $ABCDEF et on serre les fesses pour que ce ne soit pas utilisé dans les sprites ?

Tu peux prendre une couleur peu fréquente. Pour les planches de sprites, le magenta pur ($FF00FF) est souvent utilisé.

Ok, bonne idée, ça ne devrait pas être utilisé en effet. Merci bien.

Folco (./63) :
Ah Jyaif, tu faisais référence à ça en me parlant d'une grande image qui en contient plusieurs ?
int SDL_BlitSurface(SDL_Surface *src, SDL_Rect *srcrect, SDL_Surface *dst, SDL_Rect *dstrect);
Suffit après de sélectionner le rectangle qui va bien dans l'image source pour l'afficher, et ça permet de grouper plein d'images en effet.

Han mais c'est plus qu'énorme, pour un sprite animé par exemple, c'est juste un décalage de coordonnées, rien à charger/checker en mémoire !
Et pour un curseur qui varie, juste un décalage d'abcisses/ordonnées dans un sprite, encore une fois aucun accès disque/mémoire. Enorme !

Tiens, question sur la portabilité des chemins.
Je suis habitués à mettre images dans src/spr.
Mais si je fais un SDL_LoadBMP("src/spr/truc.bmp"), ça va faire quoi sous Windows, lui qui attend des \ et non des / ?

Windows comprend parfaitement les / contrairement à Linux qui va merder sévère si tu mets des \. Mais rien ne t'interdit de tester quand même, pour être sûr.
En revanche, tu devrais faire un truc pour t'assurer que ton application est bien positionnée sur le bon répertoire de travail au démarrage, sinon elle trouvera pas les images.

Folco (./66) :
Han mais c'est plus qu'énorme, pour un sprite animé par exemple, c'est juste un décalage de coordonnées, rien à charger/checker en mémoire !
Et pour un curseur qui varie, juste un décalage d'abcisses/ordonnées dans un sprite, encore une fois aucun accès disque/mémoire. Enorme !

Ce n'est pas si simple, mais c'est dans l'idée

GoldenCrystal (./68) :
Windows comprend parfaitement les / contrairement à Linux qui va merder sévère si tu mets des \. Mais rien ne t'interdit de tester quand même, pour être sûr.

Ok. Je n'ai pas encore installé SDL sous Win, et je dev sous Linux. Je voulais savoir si je devais prévoir des directives conditionnelles. Tant mieux si c'est pas le cas.

GoldenCrystal (./68) :
En revanche, tu devrais faire un truc pour t'assurer que ton application est bien positionnée sur le bon répertoire de travail au démarrage, sinon elle trouvera pas les images.

Ah ben figure-toi que j'en ai parlé cet aprèm' sur IRC à Flanker et Zerosquare, et ils ont pas trop sur quoi me répondre. Comment faire ? J'ai essayé SetCurFold(GetCurFold()), mais il trouve pas tios.h
Et de manière portable qui plus est, je ne sais pas du tout m'y prendre, je n'ai pas touché à grand chose sur PC, et surtout pas au filesystem. Mais effectivement, j'aurais besoin de savoir faire ça !

Godzil (./69) :
Ce n'est pas si simple, mais c'est dans l'idée

J'imagine qu'avec la mémoire vidéo toussa c'est pas aussi simple en effet ? Pas grave, niveau code et vérifications à (ne pas) faire, c'est déjà le pied !

Folco (./70) :

GoldenCrystal (./68) :
En revanche, tu devrais faire un truc pour t'assurer que ton application est bien positionnée sur le bon répertoire de travail au démarrage, sinon elle trouvera pas les images.

Ah ben figure-toi que j'en ai parlé cet aprèm' sur IRC à Flanker et Zerosquare, et ils ont pas trop sur quoi me répondre. Comment faire ? J'ai essayé SetCurFold(GetCurFold()), mais il trouve pas tios.h Et de manière portable qui plus est, je ne sais pas du tout m'y prendre, je n'ai pas touché à grand chose sur PC, et surtout pas au filesystem. Mais effectivement, j'aurais besoin de savoir faire ça !

Il faut que tu trouves un API qui te donne le chemin d'accès à ton éxécutable (en cours d'éxécution), mais malheureusement il n'y a rien de portable pour ça. Ensuite, changer le répertoire de travail n'est pas très compliqué
(Par contre, il faire gaffe aux / et \ là )

Godzil (./69) :
Ce n'est pas si simple, mais c'est dans l'idée

J'imagine qu'avec la mémoire vidéo toussa c'est pas aussi simple en effet ? Pas grave, niveau code et vérifications à (ne pas) faire, c'est déjà le pied !

Hmm je ne suis pas certain que ce soit à ça que Godzil fasse référence, mais en gros, le curseur (matériel), n'est pas géré vraiment pareil qu'un sprite.

GoldenCrystal (./71) :
Il faut que tu trouves un API qui te donne le chemin d'accès à ton éxécutable (en cours d'éxécution)

C'est ce que je disais à Folco, on peut simplement utiliser argv[0] et virer le nom de l'exécutable à la fin, mais le parsing n'est pas portable à cause des / et des \ (et ça pourrait être potentiellement n'importe quoi d'autre).

1. Oki. Donc pas le choix, faut double code. Dans tous les cas, récupérer le répertoire de l'exécutable (il est dans argv ?) et trouver les commandes pour changer le chemin. Faire un system("cd <machin>") au pire.


2. (Han je l'avais pris pour squalyl une fois de plus )
Ok. Mais en fait, je n'affiche pas le curseur, mais un sprite à sa place. Je n'ai pas trouvé comment afficher un curseur en couleur + transparence avec SDL.

Non, argv[ 0 ] n'est pas fiable, sinon je l'aurais proposé.
D'une part, si tu éxécutes "toto", argv[ 0 ] est "toto", pas "/usr/bin/toto", d'autre part les applications peuvent faire joujou avec et mettre ce qu'elles veulent dedans (c'est complètement con comme concept ce argv[ 0 ] je trouve, mais bon…).
Par exemple dans un appel à exec, tu dois obligatoirement fournir argv[ 0 ] mais tu peux éxécuter popeye en lui faisant croire qu'il s'apelle olive…

Folco (./73) :
Faire un system("cd ") au pire.

Beurk

Sous Windows tu peux utiliser la fonction SetCurrentDirectory(chemin).
Sous Linux je sais plus, je te laisse chercher

GC : ah ben je savais pas, je pensais que le chemin dans argv[0] était complet :/

Enfin en fait le fait que argv[ 0 ] ne te donne pas le chemin complet n'est pas nécéssairement un problème, mais faut gérer ça de manière adéquate.
(À priori si argv[ 0 ] est "ls", tu peux supposer que le répertoire courant est celui dans lequel "ls" est éxécuté, etc.)
Sinon je crois que la fonction sous linux s'apelle bêtement chdir

Il me semblait aussi que c'était chdir (vieux souvenirs du cours de système d'exploitation), mais j'osais pas le proposer.
Mais de toute façon normalement c'est à l'utilisateur de s'assurer qu'il est dans le bon répertoire avant de démarrer l'application. Je ne connais pas beaucoup de programmes évolués qui fonctionnent correctement si tu les démarres de n'importe où.

Bah pour un jeu, qui plus est un jeu susceptible d'être lancé en ligne de commande sous linux, c'est indispensable.
Il me semble que Frozen Bubble le fait par exemple (oui c'est ma seule référence de jeu *crédible* sous linux, même si c'est codé en perl et sdl et tout. C'est d'ailleurs le seul jeu potable en sdl que j'aie jamais connu )

Y'a bien une autre solution : tu utilises un programme pour convertir tes fichiers binaires en .h, et comme ça tu as un programme compilé avec tout dedans ^^

Si c'est du perl il doit pouvoir voir facilement la source alors, et faire pareil
Frozen Bubble je ne dirais pas ce que j'en pense au risque de passer pour carrément odieux.
Bref perso je ne vois pas comment faire à part pour le coup du argv[0 ]. D'ailleurs question pour experts, est-ce qu'on a le droit de faire ça en C?

char *sep;
if ((sep = strrchr(argv[0], '/')) || (sep = strrchr(argv[0], '\')))
    *sep = 0;
printf("Path is %s\n", argv[0]);

Ça devrait fonctionner, même si niveau lisibilité on a déjà vu mieux ^^
(faudrait voir si argv est toujours accessible en écriture, par contre)

chdir, c'est changedir, l'equivalent de cd

Zerosquare (./81) :
Ça devrait fonctionner, même si niveau lisibilité on a déjà vu mieux ^^
(faudrait voir si argv est toujours accessible en écriture, par contre)

Perso je pensais plutôt à la double affectation dans l'expression (qui n'est peut être pas légale); en plus pour que ça marche bien il faut la garantie que la deuxième expression n'est pas évaluée lorsque la première est vraie. En Java je suis sûr que c'est le cas mais pas en C...

Si, ça c'est également valable en C (c'est un des rares trucs qui ne sont pas implementation-defined).

La pratique courante sous *nix, c'est que le chemin d'installation (le "préfixe") est fixé à la compilation, en général, c'est /usr/local par défaut pour les applications compilées par l'utilisateur et /usr pour les paquetages, ensuite, on met les binaires dans bin, les données dans share/nomdelappli etc. Les systèmes de paquetages sont basés sur ça, quand on essaie de faire autrement, ça ne fait que créer des problèmes (et je parle de mon expérience personnelle là, j'ai bien vu ce que ça donne avec TIGCC et le fameux $TIGCC, il est fort probable qu'une version future de TIGCC/*nix va passer aux chemins codés en dur à la compilation comme c'est fait d'habitude).

J'aime bien que les programmes puissent tourner à partir de leur répertoire courant, sans installation, comme ça ça ne fait pas chier ceux qui veulent essayer (pas de pourrissage), ça peut se ballader sur une clé usb etc...

YEAH !!!!!

J'arrive à avoir ma fenêtre, le background, mon curseur perso (un sprite, pas les fonctions de curseur prévues) avec le fond qui se redessine et tout et tout... sans bug et du premier coup \o/

Par contre, ma femme s'est même pas extasiée, je pensais pas que le mariage pût produire de si cruelles déceptions

bon par contre, j'ai voulu vérifier avec valgrind que je ne perdais pas ce que j'allouais :
valgrind --leak-check=full --show-reachable=yes ./src/bin/Debug/FPG2 2> /home/folco/Desktop/log.txt
Ben il est pas beau le log... http://www.mirari.fr/jYPm

Visiblement, rien ne viendrait de moi (?), tout de la SDL (des trucs alloué par SDL_Init et jamais effacés). C'est comme ça tous les softs, ils sont releasés avec des leaks dans tous les sens mais c'est pas grave, on verra rien ?

Welcome to the real world !

Folco (./86) :
J'aime bien que les programmes puissent tourner à partir de leur répertoire courant, sans installation, comme ça ça ne fait pas chier ceux qui veulent essayer (pas de pourrissage), ça peut se ballader sur une clé usb etc...

Et bah crois-moi, ce fonctionnement n'est pas du tout adapté sous *nix. Vouloir gérer ça avec TIGCC n'a créé que des ennuis. Ce n'est pas pour rien qu'on a une hierarchie des fichiers standardisée (FHS).

Folco (./88) :
C'est comme ça tous les softs, ils sont releasés avec des leaks dans tous les sens mais c'est pas grave, on verra rien ?

Comme tout OS moderne (non, AMS n'est pas moderne ) libère toute la mémoire d'un processus quand il termine, les libs PC ne se cassent souvent pas la tête à tout libérer explicitement, ce n'est qu'une perte de temps. Cela dit, ça rend la lib moins flexible parce qu'on ne peut pas l'initialiser et la quitter plusieurs fois dans le même programme sans leaker de la mémoire. (Par exemple, dans ld-tigcc, nous avons fait très attention à tout libérer parce qu'il peut être compilé en DLL et chargé et déchargé beaucoup de fois dans le même processus TIGCC IDE.)