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

Donc en soi ce n'est pas grave ? Faut pas que je me fasse suer avec Valgrind alors. Mais un programme (pas une dll), faut quand même qu'il libère sa mémoire proprement, non... A moins que la notion de propreté à ce niveau devienne inexistante avec les OS modernes, et donc autant faire léger et ne pas libérer ?
C'est quoi la bonne politique ?

Si tu n'as plus besoin de quelque chose au milieu du programme, tu es censé la libérer tout de suite. Sinon, tu appelles les fonctions pour quitter les libs quand tu codes proprement, mais pour libérer, c'est un peu comme tu veux. J'ai tendance à toujours libérer explicitement ce que je peux, mais normalement ça ne sert à rien.

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...

C'est tout de même bien pratique

Oué pareil, je libère toujours vu que je m'y crois obligé.

Bon les gars en aéronautique, on vous dis de faire quoi ? Vous êtes censés être astreints à des normes très rigoureuses, je pourrais prendre exemple peut-être ?

Bah c'est simple, y'a des cas où les allocations de mémoire dynamiques sont tout simplement interdites

J'ai pas trouvé comment on affiche simplement un texte avec SDL, il faut s'y prendre comment ? Je ne vois pas de fonction qui s'y rapporte...

Dans SDL il n'y a rien. Tu as 2 solutions:
1/ Tu peux garder ta font dans une bitmap, et découper ta bitmap. Faisable à la main si la font est monochasse, l'horreur sinon...
2/ Tu peux utiliser SDL_ttf.

Oki, merci.

J'ai un souci (un while qui ne termine jamais), je débogue donc. La condition d'arrêt dépend d'une variable locale, mais GDB semble me dire que la variable n'existe pas...
Fichier joint : (screen12.png)

Pour info, c'est la première fois que j'utilise un débogueur C, je n'ai pas encore les bons réflexes pour pousser mes investigations...

Voici les différentes parties du code :
La déclaration :

typedef struct IconsData
{
    SDL_Rect IconPos;
    Uint16 IconSprRank;
} ICONS_DATA;

Les données :

ICONS_DATA IconsData[] =
{
    {{800, 600, 32, 32}, 0},            // Scenario
    {{850, 600, 32, 32}, 1},            // Campaign
    {{900, 600, 32, 32}, 2},            // Exit
    {{0, 0, 0, 0}, 0}                   // End of table
};

L'appel de fonction :

int DrawIcons(SDL_Surface *Surface, SDL_Surface *IconsSprites, ICONS_DATA *IconsData);
[...]
DrawIcons(Background, Icons, IconsData)

Et la fonction est dans le screen.

Si l'on peut me donner le pourquoi du comment 'Iter' semble ne pas exister, et comment faire pour avancer dans la résolution du problème, ça serait cool.

Réponse donnée sur IRC ^^

Mici

Rapport aux allocations mémoire, n'écoutes pas ce que dit Kevin.
Les OS récents libèrent de manière automatique, et autant que faire se peut, les ressources allouées par les programmes parce que le nombre de développeurs incompétents qui sont pas fichus de libérer la mémoire est incroyable (puis il faut y ajouter les simples erreurs de développeurs qui eux, sont compétents) donc on évite dans une certaine mesure les inconvénients à l'utilisateur. Mais il y a éventuellement des ressources qui seront pas libérées et pourront causer des fuites de mémoires globales.
Bref, libérer la mémoire n'est pas facultatif, et certainement pas une perte de temps, c'est une histoire de code propre ! D'autant plus que (encore une fois) la libération des ressources n'est pas un service offert à ton application (i.e. ce n'est pas garanti quel que soit l'OS), mais un service rendu à l'utilisateur et au système lui-même. (Ça augmente l'efficacité et la fiabilité du système vis à vis des programmes mal codés).

(Et non, je te rassure, y'a des tas de trucs bien codés qui libèrent la mémoire comme il faut, moyennant les éventuels bugs… Y'en a peut-être juste moins qui sont open-source… (Mais j'en sais rien à vrai dire))

Oki merci. De toute façon, j'aime bien (essayer de...) coder proprement.

Disons que c'est généralement pas bien dans la conception mais parfois c'est tout à fait ok de laisser le système le faire. Genre si tu charges une librairie et que tu sais que tu en auras besoin jusqu'à la fin du programme, alors tu ne vas pas la décharger juste avant le return du main. Pareil pour ta classe "Application" principale, tu fais un new dans le main mais pas de delete.
'Fin faut pas penser que c'est forcément des porcs qui ne libèrent pas leurs ressources, sinon tu vas trouver tout ce qui se fait sur PC nul

Déjà j'ai pas les classes en C Mais je comprends bien. Mais je préfère rester très propre, question de principe.
Sinon, on peut charger une lib pendant l'exécution, mais comment faire ? Moi ça doit être linké par le linker dynamique, donc je ne peux pas décharger la sdl à la main. On fait comment pour le faire à la mano (just4fun )

Sous Windows, comme ça.
Sous Linux, chépas

./105 > Le faire à la main ça se fait avec LoadLibrary() et GetProcAddress() sous Windows, et dlopen() et dlsym() à d'autres endroits.
Mais ce n'est intéressant que pour des scénarios spécifiques (le plus commun étant: un système de plug-ins), et c'est pareil, il *faut* _toujours_ libérer les références à ces librairies quand tu ne t'en sers plus. Tu ne sais absolument pas ce que la librairie peut avoir à gérer (donc allouer) comme ressources derrière ton dos, donc tu te dois de la libérer proprement !
Pareil pour la classe Application non libérée. Désolé Brunni, mais il n'y a rien de pire que faire ça. Dans un langage avec GC, ta classe sera automatiquement libérée donc c'est hors-propos, mais pour un langage comme le C++, bien conçue, le detructeur de ton "Application" va certainement faire bien plus que de simplement libérer la mémoire. C'est juste un gros bug de passer outre… un « delete myApplication; » ça te coute quand même pas grand chose…

Globalement quand tu codes, il faut considérer tout ce que tu utilises comme une boîte noire (même si c'est toi qui l'a codé…). Tu sais ce que ça prend en entrée et ce que ça fait en sortie. Le reste tu n'as pas à t'en préoccuper (ou en dernier recours si le truc est buggué et impossible à réparer ni à contourner). De cette manière, si tu change un composant (par une version avec un API compatible hein ) sans toucher aux autres, le code continue de compiler et de fonctionner à la perfection. Allouer et désallouer la mémoire fait partie des protocoles à respecter, c'est tout…

Merci pour les tips sur les dll. Mais en effet, ce n'est pas pour moi.

Pour le reste, je plussoie des deux mains.

GoldenCrystal (./102) :
Mais il y a éventuellement des ressources qui seront pas libérées et pourront causer des fuites de mémoires globales.

Mais ce n'est pas le cas pour une simple allocation de mémoire.

Et sous *nix, on est plutôt bien fichus en cas de terminaison brutale (genre SIGKILL). Mais évidemment il y a des trucs comme les fichiers temporaires et les lockfiles qui peuvent traîner, et certaines APIs de communication entre processus mal conçues laissent aussi traîner les trucs (en revanche, D-Bus est robuste envers des apps terminées sans libérer les ressources pour une raison ou pour une autre, ce cas est détecté automatiquement).

Folco (./105) :
Moi ça doit être linké par le linker dynamique, donc je ne peux pas décharger la sdl à la main.

Décharger la lib ne va rien libérer à part l'espace utilisé par la lib elle-même.

As-tu bien pensé à appeler SDL_Quit();?

Oui, j'utilise SQL_Quit(), et systématiquement (pas dans une condition ou autre quoi, passage obligé).

Tiens, je découvre à l'instant SDL_gfx, qui propose des fonctions géniales qui me manquaient :
- lignes, cercles, triangles, bref plein de trucs
- framerate constant super simple, genre SetFPS(30);
- affichage de caractères et de string genre draw (char *x, x, y, color RGB).
bref, du simplissime sur toute la ligne.

Bon, j'ai besoin d'en savoir plus au niveau du fonctionnement de la SDL, et je n'ai pas réussi à me faire une idée avec la doc...

J'ai des doutes quant au rafraichissement du buffer initialisé avec SetVideoMode(...). Ca dessine une fenêtre "graphique" à l'écran et ça renvoie un pointeur SDL_Surface permettant de dessiner dessus. Mais le rafraichissement est-il automatique ? Ai-je besoin de construire mes plans dans une autre SDL_Surface que je viens coller après dans cette fenêtre ?

Voici ce que dit la doc de SDL_Flip :

SDL_Flip

Name
SDL_Flip -- Swaps screen buffers

Synopsis
#include "SDL.h"
int SDL_Flip(SDL_Surface *screen);

Description
On hardware that supports double-buffering, this function sets up a flip and returns. The hardware will wait for vertical retrace, and then swap video buffers before the next video surface blit or lock will return. On hardware that doesn't support double-buffering, this is equivalent to calling SDL_UpdateRect(screen, 0, 0, 0, 0).
The SDL_DOUBLEBUF flag must have been passed to SDL_SetVideoMode, when setting the video mode for this function to perform hardware flipping.

Return ValueThis function returns 0 if successful, or -1 if there was an error.

Est-ce que ça veut dire que je peux dessiner directement sur cette surface, et que le rafraichissement réel de l'écran se fera à l'appel de SDL_Flip() ? Ou dois-je dessiner dans un buffer, l'écraire puis swapper ?
Je ne sais pas trop, et mes dessins ne sont pas assez chargés pour que je puisse me rendre compte d'un quelconque clignotement pour le moment...

edit-> j'ai le double-buffering activé par défaut, mais je crée une fenêtre sans si la création échoue, donc je veux quelque chose de fluide dans les deux cas.

Info supplémentaire : la doc de SDL_DOUBLEBUF qu'on passe en argument de SetVideoMode() :

Enable hardware double buffering; only valid with SDL_HWSURFACE. Calling SDL_Flip will flip the buffers and update the screen. All drawing will take place on the surface that is not displayed at the moment. If double buffering could not be enabled then SDL_Flip will just perform a SDL_UpdateRect on the entire screen.

Ca voudrait bien dire qu'on dessine toujours sur une surface cachée, et que seul un appel explicite à SDL_Flip() provoque le swapping des surfaces ?

En conséquence de quoi, on eput toujours dessiner sur la surface renvoyée par SetVideoMode(), elle ne sera affichée qu'après SDL_Flip() et on n'aura pas d'artefacts ?

Normalement tu devrais pas avoir à t'en occuper, mais je connais pas SDL donc je vais pas trop m'avancer…
Commençons par la base: les deux techniques pour la présentation à l'écran sont
1 - Le page-flip (utilisé en plein écran en général): Tu as un buffer affiché directement par la cg (frontbuffer), et un autre dans lequel tu dessines (backbuffer); les rôles alternent.
2 - La copie: Tu as un buffer affiché directement par la cg (frontbuffer), et un autre dans lequel tu dessines (backbuffer); Le contenu du backbuffer est copié dans le frontbuffer quand tu le demandes.
Quand la méthode 1 n'est pas supportée, on utilise la méthode 2 (typiquement, en mode fenêtré), mais normalement c'est quand même gérée de manière matérielle. Si jamais tu avais une carte graphique ne supportant pas le double buffering, tu devrais implémenter la méthode 2 à la main, or une telle carte graphique est une antiquité, par conséquent, la copie serait malgré tout lente.
Après, je ne sais pas vraiment ce que fait SDL_Flip. D'après la doc que tu as cité, ça laisse entendre que SDL_Flip est la méthode 1, et SDL_UpdateRect la méthode 2, donc un bête choix entre les deux devrait faire l'affaire, mais ça reste pas clair. (Est-ce que tu as un endroit où ils te précisent qu'il y a toujours un backbuffer, ou non ?)

[EDIT] cross… Ok donc SDL_Flip utilise bien le comportement standard, méthode 1 ou méhode 2, ne te préoccupe pas de ça donc ^^

Ok, merci. Et j'ai dit une connerie, c'est la doc de SDL_DOUBLEBUF que j'ai citée dans mon post précédent (à n'utiliser qu'avec SDL_HWSURFACE qui stocke la surface à afficher dans la mémoire de la CG, pas en RAM).

Donc au final, j'affiche directement dans la surface créée par SetVideoMode(), et je fais un SDL_Flip() à la synchro.

Merci bien.

J'aimerais savoir comment faire pour intégrer des images (png) au binaire, histoire de ne pas se trimballer avec 50 fichiers à côté.
L'idéal serait d'arriver à stocker les fichiers dont j'ai besoin dans le format utilisé par SDL (SDL_Surface), peut-être SDL propose-t-elle un outil pour faire ce genre de trucs ? Parce que intégrer un png et devoir aller le lire à la main après, ou utiliser libpng pour ça, non merci. ^^

Si tu arrives à lire ton png une première fois pour le transformer en SDL_SURFACE, tu peux le faire n'importe quand, non ?
Pour le reste, pourquoi ne pas convertir tes sprites en tableaux de chars ?

Ben tu peux les stocker en RAW mais ça prend pas mal de place... Le mieux reste les fichiers externe (dans une archive).

Les tableaux de chars peuvent être les pngs, c'est comme ça que je l'entendais d'ailleurs. Le raw me semble une mauvaise idée à moi aussi.