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

yop,


J'aimerais faire du graphisme, c'est à dire sortir des programmes en console, mais :

- faire purement du graphisme, dans un buffer, comme on le fait sur TI : pas de gestion des fenêtres du Window Manager, pas de boites de dialogue etc..., vraiment afficher des sprites/maps/textes à l'écran.

- avoir une abstraction matérielle complète : je veux juste savoir où dessiner, sans me soucier de la résolution ou du bpp actuel (juste passer des paramètres à une fonction qui me règlera tout ça). Abstraction hw au niveau du layout clavier, de la souris etc, ie en récupérant les évènements (KEY_DOWN, BUTTON_LEFT etc...) sans descendre plus bas. Pareil pour le son (même si je verrai dans un second temps).
Abstraction complète par rapport à la carte graphique également, je ne veux pas mettre les doigts dedans.

- avoir une portabilité par recompilation pour au moins Win et Linux, MacOS souhaité.

- une librarie accessible simplement en C (pas de wrappers à la noix pour un truc prévu pour le C++).

- ne surtout pas me plonger dans les algos de dessins à l'écran à partir de fichiers de sprites ou de sprite en mémoire, un PutSprite(x, y, sprite, mode) suffit amplement.

- je ne vais faire que de la 2D bête et méchante, et ça ne sera certainement pas gourmand en ressources


J'ai pensé à la SDL, je ne sais pas s'il y a autre chose dans ces specs. J'ai lu ça : http://www.libsdl.org/intro.fr/ , ça m'a bien plu.

Qu'en pensez-vous ? C'est pas trop bordélique à utiliser cette lib ?


ps -> Quand on code en C, quels sont les pièges à éviter pour marcher sur du 32 et 64 bits sans changer son code ?
ps2 -> je suis en train de lire les tutos sur la sdl sur lesiteduzero

SDL ça pue, ça fait des applications qui marchent mal sous Windows, mal sous Linux, et mal sous OSX tout pareil, ou alors très bien sur un (avec éventuellement des gros hack) et très mal sur tous les autres… C'est tout le bien que j'en pense.
Les trucs portables c'est mal. Choisis une plateforme. Choisis un API. et reste avec.
T'as aussi allegro sinon (mais je ne l'ai jamais utilisé (SDL non plus, faut pas pousser) ni utilisé de trucs fait avec. De toutes façons je fuis déjà SDL comme la peste…)

Sinon pour ton « ps » c'est simple: Il faut utiliser les vrais types des fonctions. time_t, clock_t, size_t, etc. Ne jamais convertir de pointeur en entier, ni d'entier en pointeur (JAMAIS !). Ne jamais supposer une quelconque représentation mémoire pour un type, donc ne pas utiliser de hack. Faire bien attention à utiliser des sizeof partout où il faut.
Bref, il suffit de coder proprement. Très proprement. Et ça passera comme une lettre à la poste. (Indice: si ton code compile sans warning en -pedantic -Wall tu es peut-être sur la bonne voie)

(PS: Puisse ta carte graphique t'exploser entre les doigts pour avoir osé toucher à SDL )

Arrête un peu, pour ce que veut faire Folco, SDL convient parfaitement

Ce n'est pas aussi mauvais qu'on le dit, c'est juste que ça attire les fainéants qui codent comme des porcs.

GC -> toujours aucun parti-pris toi, comme d'habitude
Pour afficher des images et lire des touches ça va bugguer tant que ça ? Où c'est pas au point du tout du tout, ou alors t'exagères un peu (mais comme je te connais un peu marseillais sur les bords, ben... )

0² -> le porc fainéant te remercie

ps -> j'ai filé une bière à ma carte graphique, elle m'a avoué qu'elle supporterait la SDL sans souci

Euh non mais c'est pas du tout ce que je voulais dire, je parlais de certains utilisateurs de SDL

Et pour ce que tu veux en faire ça marchera parfaitement

Ok merci

Alors déjà, tu ne peux en général pas afficher directement sur l'écran dans un OS multitâches moderne, le plus que tu pourras faire, c'est d'avoir une fenêtre plein écran, ou au plus un framebuffer en mode console (mais normalement, c'est plutôt la fenêtre plein écran qui est retenue, parce que ça casse les pieds de devoir quitter X11 pour jouer). Et tu as intérêt à permettre aussi le mode fenêtré, il y a des gens comme moi qui ont horreur des jeux qui forcent le plein écran. (J'ai toujours IRC qui tourne en tâche de fond et, si on me demande quelque chose, je veux pouvoir répondre.)

Ensuite, SDL ne fonctionne normalement pas en mode console, ça passe par X11. Il y a une version DirectFB, mais comme dit plus haut, normalement on reste sous X11 pour jouer!

Mais sinon, SDL est très bien pour ce que tu veux faire, et n'écoûte surtout pas GoldenCrystal, il adore les APIs propriétaires et le lock-in…

Je te conseille Allegro ( http://www.allegro.cc ) plutot que SDL. Allegro devrait te plaire, c'est DOS compatible
Allegro peux manger a peut pret tout type d'affichage, VGA, SVGA, FB, DirectFB, X11, Win32, MacOS, MacOSX et j'en passe. Par contre la 5.x (ou 4.9) sont à éviter pour l'instant, une bonne "vielle" 4.2 ou la derniere 4.4 suffit largement ^^

(mon premier prog "graphique" a été fait a l'époque sur DJGPP+Allegro #souvenirs#, c'était en 1999...

Je vais lire sa doc, merci.

Je vais finir ce que je trouve sur la SDL déjà. ^^

Kevin m'a dit sur IRC que dans les concepts, ExtGraph ~= SDL et Genlib ~= Allegro. Le truc, c'est que je n'ai pas besoin de tilemap ou assimilé, mais je lirai la doc tout de même.

edit -> ah oué 473 pages la doc d'Allegro

Enfin, c'est ce que j'ai lu dans des discussions précédentes ici. Il faut dire que je n'ai pas codé quoi que ce soit avec Allegro et que mon expérience avec SDL se limite à la partie son (pour l'émulation du son dans TiEmu/Emu-TIGCC que j'ai codée avec Peter Fernandes (hypersonic)).

Je ne reconnais pas du tout SDL dans ce que dit GoldenCrystal.

Pour l'avoir énormément utilisé (depuis que je code plus pour TI je n'utilise que ça), elle fonctionne super bien, et de manière identique sur tous les OS. La seule différence qui me vient à l'esprit, c'est la gestion des icones dans les fenêtres, c'est dire.

Pour tout ce qui est gestion des fenêtres et de l'affichage, du clavier, et des timers, ça marche parfaitement.


Pour finir, c'est totalement stupide de dire de ne pas faire de programmes multiplateformes (on dirait entendre Steve Jobs), en particulier pour les jeux où tu t'en BLC de l'OS, tout ce que tu veux c'est que le jeu fonctionne...

Folco (./9) :
dans les concepts, ExtGraph ~= SDL et Genlib ~= Allegro

Ah, ça doit être pour ça que j'aime SDL ^^

Bon ben je vais faire un post plus sérieux.
Ce qui se fait de mieux en multi-plateformes:
Audio: FMOD.
Graphique: OpenGL.
Et c'est tout. (J'avoue que pour la gestion des périphériques d'entrées… je sèche)
(Bien évidemment Direct3D > OpenGL, mais malheureusement il n'existe que sous Windows :'( )

Après encore heureux que le rendu soit identique sous tous les OS. Mais une librairie graphique pour faire du graphisme c'est un peu réducteur. On ne vit plus à l'époque de MS-DOS avec un programme éxécuté tout seul en plein écran. Y'a des trucs autour. C'est là que ça pêche. C'est pas du tout adapté au monde réel.
Comme du dis, ça fonctionne de manière identique sur tous les OS ? Tu vois pas un problème là dedans ? Moi oui, un énorme problème.

Et je n'ai pas dit de pas faire de programme multiplateforme, mais il faut le faire bien. Un API multiplateforme n'est pas une solution viable dès que tu touches au graphisme. Stout.

Pfffff.... t'aurais lu mes specs, t'aurais vu que je cherche juste à afficher des sprites, pas à faire de la 3D etc..., et surtout à avoir une abstraction totale par rapport au HW, aussi bien en entrée qu'en sortie. Encore une fois tu casses (tout est nul sauf moi qui ait la solution a tout), mais... tu donnes aucune solution.


Merci à tous pour ce feedback sur la SDL, je vais l'utiliser.

J'ai commencé à regarder Allegro, ça m'a l'air de l'overkill pour ce que je veux faire. Déjà, les 50 premières fonctions servent à décortiquer le type de CPU/OS/CG/etc... dont j'ai rien à battre ^^

GoldenCrystal (./12) :
Audio: FMOD.

Non-libre => poubelle!

GoldenCrystal (./12) :
Bon ben je vais faire un post plus sérieux.
Ce qui se fait de mieux en multi-plateformes:
Graphique: OpenGL.

Je suis bien d'accord, mais ta gestion des fenêtres et du clavier, tu va l'a faire avec SDL.

On ne vit plus à l'époque de MS-DOS avec un programme éxécuté tout seul en plein écran. Y'a des trucs autour. C'est là que ça pêche. C'est pas du tout adapté au monde réel.Comme du dis, ça fonctionne de manière identique sur tous les OS ? Tu vois pas un problème là dedans ? Moi oui, un énorme problème.

Ce n'est pas parce que tu utilise une librairie multiplateforme qui ne supporte que les features commun à toutes les plateforme, que subitement ton programme n'a plus le droit d'utiliser de fonctionnalités spécifiques à chacune des plateformes. Voir Chrome.

Un API multiplateforme n'est pas une solution viable dès que tu touches au graphisme. Stout.

Pourquoi? Tu pense que DirectX ne pourrait pas fonctionner sous OS X ou Linux?

Il y a plein de technologies non-portables là-dedans, à commencer par les objets COM. Ce n'est pas sans raison que la seule implémentation de Direct X sous GNU/Linux ou OS X fait partie de WINE.

Bon, soit. Je voulais juste savoir pourquoi "Un API multiplateforme n'est pas une solution viable dès que tu touches au graphisme.". J'ai pris DirectX comme exemple parce que pour lui, c'est ce qu'il y a de mieux dans ce domaine.

Jyaif (./15) :

On ne vit plus à l'époque de MS-DOS avec un programme éxécuté tout seul en plein écran. Y'a des trucs autour. C'est là que ça pêche. C'est pas du tout adapté au monde réel.Comme du dis, ça fonctionne de manière identique sur tous les OS ? Tu vois pas un problème là dedans ? Moi oui, un énorme problème.

Ce n'est pas parce que tu utilise une librairie multiplateforme qui ne supporte que les features commun à toutes les plateforme, que subitement ton programme n'a plus le droit d'utiliser de fonctionnalités spécifiques à chacune des plateformes. Voir Chrome.

Rapport à ton argumentation, Chrome n'est justement pas un exemple, mais un contre-exemple.
C'est ce que je dis: multi-plate-forme, mais bien fait. Tu gardes le cœur et tu fais une version différente de l'UI pour chaque système. Oui c'est comme ça que ça fonctionne monsieur. (Je ne voulais pas aborder ce sujet dans ce topic, mais difficile de ne pas le faire là)

./13 > J'ai parlé de OpenGL parce que:
1 - Qui peut le plus peut le moins. Si OpenGL peut faire de la 3D il peut évidemment faire de la 2D. (Tu devrais pouvoir demander conseil à Orion_ je pense)
2 - OpenGL est un API C. En dehors des extensions (dont tu n'auras pas besoin), OpenGL est d'une simplicité extrême.
3 - Y'a pas plus abstrait du matériel que OpenGL, justement. (ça se complique avec les extensions mais passons) C'est d'ailleurs mon principal reproche à son égard. Tu appelles des fonctions et tu espères que ça marche. Ça s'arrête là.
Pour clarifier: ça marche, en général, mais tu sais pas comment. Tu sais même pas si le rendu sera fait de manière logicielle ou matérielle. A-b-s-t-r-a-c-t-i-o-n ! (PS: Sous Windows avec des drivers décent tu as peu de chances de tomber dans le premier cas)

Bref, c'est pas vraiment overkill, et contrairement à tous les autres API que tu trouveras qui sont des surcouches autour des API truc, machin et bidule. OpenGL est juste OpenGL. Partout.
Mais il y a quelques extensions spécifiques à chaque système pour initialiser la machinerie. C'est un vrai API multiplateforme

Mais va avec SDL si c'est ce qui te convient hein. Ma critique est basée du point de vue de l'utilisateur final, pas du programmeur. Leur API n'est probablement pas dégueu (enfin j'en sais rien), j'émet juste de très fortes réserves sur leur implémentation

GoldenCrystal (./18) :

Jyaif (./15) :

On ne vit plus à l'époque de MS-DOS avec un programme éxécuté tout seul en plein écran. Y'a des trucs autour. C'est là que ça pêche. C'est pas du tout adapté au monde réel.Comme du dis, ça fonctionne de manière identique sur tous les OS ? Tu vois pas un problème là dedans ? Moi oui, un énorme problème.

Ce n'est pas parce que tu utilise une librairie multiplateforme qui ne supporte que les features commun à toutes les plateforme, que subitement ton programme n'a plus le droit d'utiliser de fonctionnalités spécifiques à chacune des plateformes. Voir Chrome.

Rapport à ton argumentation, Chrome n'est justement pas un exemple, mais un contre-exemple.

Chrome est un programme qui utilise des librairies multiplateforme, mais qui utilise aussi des fonctionnalités spécifiques à chacune des plateformes. C'est un parfait exemple :s

C'est ce que je dis: multi-plate-forme, mais bien fait.

Bon, au moins on est d'accord sur ça...

Tu gardes le cœur et tu fais une version différente de l'UI pour chaque système. Oui c'est comme ça que ça fonctionne monsieur. (Je ne voulais pas aborder ce sujet dans ce topic, mais difficile de ne pas le faire là)

On garde le coeur et on fait une version adaptée pour chaque système en effet, mais on peut très bien garder la même UI, et c'est ce que font tous les jeux multi plateformes.

Et oui, désolé de pourrir le sujet avec le off-topic ça devrait être la signature de pas mal de monde sur yNquoique pour certains, -"le off-topic" +"de la merde" ...

L'API SDL n'est pas dégueu du tout (c'est quand même un développeur de jeu qui l'a créée, à la base), la partie 2D ressemble même plus ou moins à DirectDraw. Faudrait tester les perfs, mais ça ne m'étonnerait pas qu'on arrive pas loin du natif si on s'en sert bien, vu qu'un des back-end sous Windows c'est DirectX.

Ce qui donne mauvaise presse à SDL, ce sont les gens qui recompilent des trucs multiplateformes tels quels, sans les optimiser du tout et/ou qui ne maîtrisent pas les bases de la prog graphique (savoir s'il vaut mieux mettre les buffers en RAM principale ou en RAM vidéo, ne pas faire de conversions de format à la volée, privilégier les traitements par blocs au lieu de faire du pixel par pixel, etc.)

Allegro n'est pas du tout un tilemap engine, mais bien une librairie graphique complete, son, musique, 2D, 3D, etc...

Ah mais j'ai pas dit ça, juste qu'il y avait, d'après ce que j'ai compris, un tilemap que SDL n'a pas du tout. Bref, pour faire des PutSprite ici et là, c'est de l'overkill chez moi, même si c'est sûrement très bien pour celui qui en a l'usage.

Bon, let's go sur la SDL quoi qu'en pensent certains ()

Je vois souvent ce style de boucle dans les exemples/tutos, et même dans le template de CodeBlocks :

    // program main loop
    bool done = false;
    while (!done)
    {
        // message processing loop
        SDL_Event event;
        while (SDL_PollEvent(&event))
        {
            // check for messages
            switch (event.type)
            {
                // exit if the window is closed
            case SDL_QUIT:
                done = true;
                break;

                // check for keypresses
            case SDL_KEYDOWN:
                {
                    // exit if ESCAPE is pressed
                    if (event.key.keysym.sym == SDLK_ESCAPE)
                        done = true;
                    break;
                }
            } // end switch
        } // end of message processing
    [affichage]
    }

Mais... ça va tourner en permanence ça (PollEvent dépile un évènement, il n'est pas bloquant) ? C'est pas mieux de baser cette boucle sur un timer, où l'on détecté les évènements, je ne sais pas, tous les 30 ou 60ème de seconde par exemple ? Sinon, on va boucler en permanence (et à une vitesse différente sur chaque machine kipluzè...).
Ca devrait consommer tout le CPU ça, non ? En tout cas, je ne vois pas pourquoi ça ne le ferait pas...

(C'était la première question du noob qui n'a jamais rien affiché sur un PC à part dans stdout )

edit -> oué, un truc aussi con prend un CPU à 100%, en l'utilisant réellement à 3% max je suis sûr ^^

Faut mettre un truc comme sleep quelque part, évidemment… ^^
À priori tu devrais utiliser usleep(1)… (La fonction sleep de Linux est compté en secondes, elle servirait a rien du tout, mais usleep est en millisecondes)
Enfin bon, c'est une boucle principale standard hein. Mettre un sleep à chaque itération va peut-être démolir les performances de ton jeu, c'est peut-être pas l'idéal.
Mais d'abord teste avec usleep(1) à chaque itération et tant qu'il y a pas de problèmes de performances, ne cherche pas à mettre autre chose.
(Ensuite, tu pourras essayer de ne l'appeler que toutes les 10 itérations, par exemple… ^^)

Wouaw, mais c'est Unix ce truc, non, ou du moins Linux ? http://www.linux-kheops.com/doc/man/manfr/man-html-0.9/man3/usleep.3.html

Je vais me démerdouiller avec les timers de la SDL. Décrémenter un compteur, via un timer, avec un callback pour rafraichir l'écran. Je ne sais pas ce que ça bouffe en CPU, mais ça permet d'avoir un fps constant déjà. Et de ne gérer les évènements qu'une fois par frame, ça me semble correct comme méthode ?

poru un jeu est-ce grave de consommer 100% ?

Sinon si tu veux limiter, un simple "sleep" (en secondes) ou usleep (en micro secondes) suffit pour "limiter" le nombre de boucle par seconde

Si tu veux vraiment juste que ton soft rende le CPU a la fin de la boucle, un simple "yield" ou sleep(0)/usleep(0) rend la main a l'ordonnanceur, et si il a d'autres tache de meme niveau a qui donner la main il le ferra, sinon tu reprendra la main directement

Godzil (./26) :
poru un jeu est-ce grave de consommer 100% ?

En soi, je trouve ça dommage de bouffer 100% d'un CPU là où 5% suffisent, oui. C'est surtout désagréable pour l'utilisateur dans le principe, surtout pour un jeu pas temps-réel (donc où une telle consommation CPU n'est pas justifiée).

J'ai pas encore choisi la solutions, merci pour vos idées, mais en tout cas je ne boufferai pas tout un CPU quoi qu'il arrive. ^^

./25 > Le truc c'est qu'un timer n'aura jamais une précision suffisamment bonne pour te permettre d'obtenir un rendu fluide.
Pour avoir un truc fluide, il y a d'autres méthodes, plus simples qu'un timer.
En fait, il suffit de compter le temps dans ta boucle principale. Avec un API précis bien sûr… Il te faut au moins une précision de l'ordre de 10ms, mais si tu peux avoir 1ms c'est encore mieux ^^int lastTime = …; // Obtenir le temps de référence (je suppose qu'on compte en millisecondes dans cet exemple) int newTime; int desiredInterval = 1000 / 60; // Si tu vises 60 FPS while (loop) { do { usleep(1); // Sleep(1) sous Windows… Tu as peut-être même un équivalent portable SDL ? … // Gestion des évènements newTime = …; // Obtenir le temps actuel } while (newTime - lastTime < desiredInterval); // On répète la boucle d'évènements tant qu'on a pas attendu assez newTime += desiredInterval; // On incrémente le temps de référence de la durée d'une frame fixe. … // Rendu }Par contre cet algo ne gère pas le frameskip. C'est pas forcément dur à ajouter, mais tu n'en auras pas besoin au début.
./27 > Et tu as raison !
Un truc qui bloque toutes les autres opérations sur le système même quand il fout rien, c'est ultra chiant…

Il explique bien ici comment ne pas bouffer 100% du cpu meme en utilisant SDL_PollEvent

http://www.siteduzero.com/tutoriel-3-14136-maitrisez-le-temps.html#ss_part_1

Merci bien. Je l'ai lu hier en effet (j'oublie vite quand je lis des paquets de docs ). C'est un simple algo bête et méchant.

Mais je crois que j'ai besoin de très simple en fait. Dans le cas d'un jeu de strat tour par tour, il ne se passe rien tant qu'on a pas d'input de l'utilisateur (pas d'animations). Donc au pire on peut juste limiter le fps/nombre d'input avec une simple différence de timer, si l'on part du principe que l'on rafraichit l'écran (si besoin est) après chaque input. Je crois que je vois trop grand, c'est vraiment simple. ^^