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

ZLib c'est un bon choix pour du C pur. Ce n'est pas ce qu'il y a de plus simple à mettre en oeuvre, mais ça va, et puis c'est un investissement (c'est toujours utile).

http://ymettier.free.fr/articles_lmag/lmag22/lmag22.html

Ca a l'air bien foutu en effet. Mais plutôt que de la compression, c'est de l'archivage qu'il me faut. j'ai pas réussi à savoir si tar est porté sous Win (sous Mac OS ça m'étonnerais pas ?).

Zerosquare (./138) :
Ah, si seulement il existait la directive INCBIN en C...

#define import_binary(filename,symname) asm(".globl "#symname"\n"#symname":\n\t.incbin \""filename"\"")
(cf. TIGCCLIB) marche très bien si ton GNU as est suffisamment récent.

Sous Windows tu peux utiliser les ressources pour inclure tes fichiers proprement et y accéder par nom ou par index, mais ce n'est pas portable, donc ça ne t'aidera pas.

Qt fournit un système de ressources portable.

Zerosquare (./145) :
(et ça doit être pour la même raison qu'on ne peut généralement pas effacer un programme tant qu'il tourne).

Seulement sous un OS pourri… Sous GNU/Linux, tu peux effacer un fichier quand tu veux, il sera rendu immédiatement indisponible pour les nouvelles ouvertures, et il sera automatiquement dégagé (c'est-à-dire, les blocs réservés pour lui seront automatiquement libérés) quand le dernier logiciel qui avait ouvert le fichier le ferme.

Folco (./148) :
Pour retrouver mes données dedans ("à quel offset ai-je foutu le sprite machin ?"), si j'étais sur TI, j'aurais fait une dll, avec un export à chaque début de fichier :
fichier@0000 -> pointe sur le fichier 1fichier@0001 -> pointe sur le fichier 2

Ce n'est pas du tout l'utilisation prévue pour une DLL!

Là, je vais devoir me démerder à faire un fichier binaire, avec les sprites écrits en brut, précédés par une table (typiquement : (int) Id sprite, (int) size, [...], [sprite 1], [sprite 2]

C'est bien, au moins comme ça tu apprends à faire les choses comme il faut.

Folco (./152) :
http://ymettier.free.fr/articles_lmag/lmag22/lmag22.html
Ca a l'air bien foutu en effet. Mais plutôt que de la compression, c'est de l'archivage qu'il me faut. j'ai pas réussi à savoir si tar est porté sous Win (sous Mac OS ça m'étonnerais pas ?).

On avait déjà discuté de ça. C'est la lib minizip livrée avec les sources de zlib qu'il te faut (sous Fedora, yum install minizip-devel ). Et oui, elle est disponible partout. Quant à tar, je t'avais proposé la libarchive qui est aussi portable.

Sinon, tu pourrais aussi carrément livrer un fichier par image comme le font les thèmes d'icônes freedesktop.org.

Kevin Kofler (./153) :
#define import_binary(filename,symname) asm(".globl "#symname"\n"#symname":\n\t.incbin \""filename"\"") (cf. TIGCCLIB) marche très bien si ton GNU as est suffisamment récent.

Merci, je ne connaissais pas.

Kevin Kofler (./153) :
Qt fournit un système de ressources portable.

Mais Folco n'utilise pas Qt dans son programme, et je doute qu'il s'y mette juste pour ça.

Kevin Kofler (./153) :
Seulement sous un OS pourri... Sous GNU/Linux, tu peux effacer un fichier quand tu veux, il sera rendu immédiatement indisponible pour les nouvelles ouvertures, et il sera automatiquement dégagé (c'est-à-dire, les blocs réservés pour lui seront automatiquement libérés) quand le dernier logiciel qui avait ouvert le fichier le ferme.

Je ne parlais que de Windows. Et "pourri", c'est ton point de vue : c'est un choix de conception différent. La solution dont tu parles produit des situations ambigües (tu effaces des fichiers, mais l'espace disque disponible n'augmente pas, etc.). Moi je considère que quand on essaye d'effacer un fichier alors qu'il est en cours d'utilisation, c'est déjà qu'il y a un problème.

Zerosquare (./154) :
Moi je considère que quand on essaye d'effacer un fichier alors qu'il est en cours d'utilisation, c'est déjà qu'il y a un problème.

Moi pas. C'est très courant quand j'installe les mises à jour de mon GNU/Linux. (Enfin, certains fichiers sont carrément effacés, la plupart sont remplacés, mais dans les 2 cas ça marche alors qu'un certain autre OS te gueule dessus dans les 2 cas.)

Folco (./152) :
http://ymettier.free.fr/articles_lmag/lmag22/lmag22.html

Ca a l'air bien foutu en effet. Mais plutôt que de la compression, c'est de l'archivage qu'il me faut. j'ai pas réussi à savoir si tar est porté sous Win (sous Mac OS ça m'étonnerais pas ?).

A ce moment si c'est pour "détarer" au moment de l'exécution autant fournir directement des fichiers alors... tu perds l'intérêt qui est de protéger tes données, et de toute façon tu vas archiver le programme avant de le distribuer, et le fait d'avoir plein de fichiers sur le disque dur une fois dézippé ne cause pas beaucoup de souci (surtout sous Linux).
Sinon tu peux sûrement écrire un "détareur" facilement, voire trouver une "libuntar" portable, mais l'idéal c'est de trouver un .c qui contient tout, parce que c'est de toute façon portable, il te suffit de le transporter avec ton projet ^^

Folco > Ben le format zip fait l'archivage, la compression est "facultative". (Mais recommandé...)
Et normalement ce n'est pas un problème. C'est de la compression/décompression à la volée, donc tu peux faire tout sans aucune extraction sur le disque (si les API SDL sont bien fichus...). C'est même l'intérêt principal, et ça a été fait pour.

Cf. http://www.winimage.com/zLibDll/minizip.html

Merci à tous. Je suis un peu noyé sur tout ce que j'ai à apprendre en ce moment mais on fera

Ben il faut y aller petit à petit, ou alors faire un système à la main (tout con pour commencer), tu auras peut être plus vite fait vu que c'est pas compliqué sur le principe, et tu apprendras bcp

Genre ce que j'ai proposé en ./148 ?

Par exemple ouais.
Ou même plus simple encore, une liste du genre:

{
    nom_fichier: char[],
    taille_fichier: uint32,
    données_fichier...
}

Une sorte de liste chainée, mais ça oblige à lire toutes les données de (n-1) images pour accéder à la n.
AMHA l'avantage d'une table est qu'on peut lire directement au bon offset.

Sinon, commence par faire ta fonction pourrie load_image (respectivement load_music, load_sound, etc.) qui ne fait que charger un fichier du disque. (En se basant éventuellement sur une fonction plus générique load_resource)
Quand tu seras plus avancé par la suite, tu pourras revenir sur le fonctionnement de ces fonctions pour mettre tout dans une archive ou autre...
En fait j'ai un peu l'impression que tu veux tout faire à la fois, sans savoir le faire, mais ce qui est important je pense, c'est de te focaliser sur un seul point important à la fois. (Si pour toi c'est le stockage des fichiers, soit, mais pourquoi avoir choisi un jeu dans ce cas ? )

Je m'en fosu du stockage des fichiers, je pourrais très bien garder des dizaines de sprites à part, mais j'ai envie de le faire pour savoir le faire
Mais t'as raison, je vais utiliser une fonction générique.
Et puis ça va me faire bosser les fonctions f* que j'ai jamais trop utilisées C'est con ça hein ? ^^

PpHd (./158) :
Cf. http://www.winimage.com/zLibDll/minizip.html

 arc = unzOpen ("MyArchive.zip");
 strcpy (FileName, "");
 do{
 unzGetCurrentFileInfo (arc, NULL, &FileName, sizeof (FileName), NULL, 0, NULL, 0);
 if (strcmp (FileName, WhatIWant) == 0) {
    // Found
    unzOpenCurrentFile(arc);
    unzReadCurrentFile (arc, &Buffer, BufferLen);
    unzCloseCurrentFile (arc);
    break;
 }
 } while (unzGoToNextFile (arc) != UNZ_END_OF_LIST_OF_FILE);
unzClose (arc);

Fait à l'arrach juste en lisant leur interface.

Merci beaucoup ! Mais je vais refaire par moi-même, j'aime comprendre tout (ok, même si ton code, je le comprends quand même ^^)

./163> Si tu veux permettre le nommage de tes fichiers (c'est quand même plus pratique que des numéros), une solution bornée à n opérations c'est tout à fait correct. En C, tu peux difficilement faire mieux.
./166> Il aurait pu/dû faire cette démarche par lui même

Brunni (./168) :
./163> Si tu veux permettre le nommage de tes fichiers (c'est quand même plus pratique que des numéros), une solution bornée à n opérations c'est tout à fait correct. En C, tu peux difficilement faire mieux.

tu veux pas plutôt dire qu'on peut difficilement faire pire? Faut y aller à coup de realloc mon gars, utiliser des listes chainées ici c'est un scandale.

const char* filelist = "sprite1\0" "sprite2\0" ...
générer un header genre
#define sprite1 1
[...]
en même temps que le fichier de données, et voilà tous les sprites dans un fichier et le header correspondant à utilser pour le jeu.
C'est une bonne méthode ?

|

Bon, avec mon edit j'ai peut-être pas été clair :
Le but est de maintenir un seul fichier "filelist.txt", contenant le nom d'un sprite par ligne.
On crée une archive avec chaque sprite, et en même temps un fichier .h contenant
#define sprite_truc X

Et dans le jeu, je fais des spriteOpen(sprite_truc)

Et la synchronisation entre le fichier de données et le header est assurée.

(j'ai peut-ête toujours pas été clair )

Je vois toujours pas pourquoi tu te casses autant le cul pour faire un truc si peu pratique à utiliser...
C'est pas souble, pas flexible, et facilement cassable. :/

Oué bon. J'ai bookmarké vos liens, j'y reviendrai après, je vais faire autre chose pour le moment.
J'implémente tout de suite l'idée de passer par une fonction tierce pour charger les fichiers, ce qui me permettra de modifier simplement la manière dont les données sont retournées au programme. Merci beaucoup.

ps ->>> Je vois toujours pas pourquoi tu te casses autant le cul
Quand on sait pas bien faire, tout parait dur

Folco (./175) :
Oué bon. J'ai bookmarké vos liens, j'y reviendrai après, je vais faire autre chose pour le moment.

\o/
Enfin une bonne décision! Te casse pas les couilles avec les trucs chiants au début, surtout que d'après ton historique tu as 0% de chance de release ton projet.

Jyaif (./176) :
surtout que d'après ton historique tu as 0% de chance de release ton projet.

C'est très clair, mais j'avance ! Et ma manière de faire du C me fait comprendre le C++. D'ailleurs, si je reprenais le projet en C++, je saurais comment passer ce qui m'a bloqué la fois précédente.

Folco (./175) :
ps ->>> Je vois toujours pas pourquoi tu te casses autant le cul
Quand on sait pas bien faire, tout parait dur

En fait c'est surtout que tu ne te contentes pas des solutions simples comme celle que je t'ai proposé, tu veux faire un truc optimisé avant même de faire tout court
Te fatigue pas, ma solution est loin d'être la meilleure, même si tu l'optimises avec toutes les idées du monde elle sera au mieux bonne, jamais la meilleure. Par contre elle est simple à implémenter

Je veux faire trop bien, c'est récurrent, et nombre de fois ça m'a arrêté, c'est sûr :/ Ne serait-ce que parce que j'avais pas le niveau pour faire aussi bien que je voulais...

Mais tu l'auras un jour, avec l'expérience. Et l'expérience c'est aussi de faire des trucs pourris (ok vaut mieux pas le savoir à l'avance sinon ça démotive )