rewind a écrit 3413 commentaires

Même pour de la 2D simple, c'est difficile de faire un jeu qui tourne vraiment bien sur un netbook.

On verra bien. J'espère ne pas trop avoir à souffrir de ces ralentissements. Est-ce que tu les observes aussi bien sur Windows que sur Linux ?

Il y a les ViewPort qui semble plus ou moins identique, peut être que c'est moins puissant en terme de fonctionalité ?

Ce n'est qu'une partie de la fonctionnalité.

Justement avec SDL2, c'est aussi en hardware (utilisation de SDL_Texture au lieu de SDL_Surface)
Et on y trouve les fameuses rotations (https://bugzilla.libsdl.org/show_bug.cgi?id=1308) qui étaient en soft en version 1.2

Oui, on peut utiliser SDL2 pour implémenter une fonctionnalité similaire, je ne dis pas le contraire. Mais ce n'est pas immédiat.

J'avoue ne pas avoir trop compris de quoi il s'agissait (rapport avec les tile map?), mais il est question de "Position, rotation, scale" qui est justement integré dans RenderCopyEx de SDL2 (ainsi que le flip)

Rien à voir. Là, tu définis tout un tas de figure associé à la même texture (par exemple des tuiles) et tu envoies tout d'un coup et tout est dessiné en une seule fois. Avec SDL, tu dessines chaque tuile indépendamment, même si tu utilises la même texture.

Nous sommes d'accord. Et l'architecture que j'utilise offre de bonnes opportunités si jamais il y a besoin.

Vu que l'on ne sait pas le type de jeu dont il est question ici,

Je garde le suspense ;)

Merci, tu confirme l'impression que j'avais par rapport à ces deux bibliothèques. Notamment sur l'aspect un peu plus «bas niveau» de SDL2.

Concernant la portabilité, SFML2 est disponible sur Linux, MacOSX et Windows. Ça fait déjà pas mal et ça me suffit.

En plus de ce que dit devnewton, j'ajouterai que ce n'est pas le seul moyen de mettre dans des threads séparés, il y a d'autres architectures qui permettent également de faire du multi-thread assez facilement. Et que tenter d'optimiser au départ, ça n'est jamais une bonne idée, je ferai du multi-thread quand j'en aurai besoin.

Mais sachant qu'un ordi est capable de calculer et d'afficher des millions de triangles et que j'en suis très très loin, je pense que je n'en aurai pas besoin dans l'immédiat. À l'heure actuelle, j'en suis plutôt à mettre un sleep dans la boucle principale pour que ça n'aille pas trop vite.

Tu pourrais concevoir une architecture qui sépare parfaitement la gestion de l'affichage et des entrées utilisateurs de tout le reste du jeu.

Ça pourrait se faire mais ça serait assez difficile je pense. Disons que d'un point de vue conceptuel, c'est assez intéressant, mais dans la pratique, c'est quand même plus simple quand on mélange un peu tout. Et qui dit plus simple dit plus rapide à développer (le temps est l'ennemi du développeur seul).

En tout cas, vu que t'as déjà touché à la SDL2 et que tu sembles être tenté par SFML (je n'ai jamais touché à l'un des deux), je te conseillerais de partir sur SFML avec une bonne architecture. Si tu te rends compte que finalement c'est moins bien que la SDL pour ton utilisation, tu peux repartir sur de la SDL sans impact sur la totalité du code.

Ça, c'est un argument qui me plaît :)

Je pense qu'aujourd'hui la communication doit faire partie d'un projet dès le début.

J'ai déjà pensé à ça. J'envisage de faire une démo dès que j'aurai quelque chose de montrable (jouable avec quelques fonctionnalités de base).

gagner une visibilité dont on récoltera très vite les fruits lors d'une campagne de crowdfunding (à lancer aussi très tôt).

Pour l'instant, je n'image pas passer par du crowdfunding.

Tu as quelques exemples de trucs qui te semble necessaire et absent de SDL2 (en incluant sdl_image, sdl_mixer et sdl_ttf biensur)

Oui, j'ai quelques exemples:

• Les View qui permettent de simplifier la correspondance entre coordonnées du jeu et coordonnées de l'écran.
• les transformations simples d'entité (et ce n'est pas fait en software à la fin alors que si je devais le réimplémenter avec SDL, ça serait fait en software).
• Les vertex array qui permettent de dessiner rapidement plein de choses. Très pratique pour les tile map (l'exemple est donné sur la page).

Tout dépend bien entendu de ce que tu veux faire avec. Un jeu ? En 2d ? En 3d ? Avec OpenGL ou du rendu pur logiciel ?

Un jeu. En 2D. Je ne veux pas savoir comment est fait le rendu, la bibliothèque s'en occupe. Et je ne veux pas utiliser OpenGL directement.

la SDL n'excelle pas vraiment pour l'affichage : elle ne propose qu'un rendu matériel que depuis peu de temps.

Je pense que la version 2 de la SDL améliore vraiment les choses de ce point de vue. La différence entre ce qui est fait sur la carte graphique en accéléré et ce qui est fait en RAM en software est beaucoup plus explicite.

Ainsi, pour développer un jeu 2d, je conseillerais plutôt la SFML.

Ne me tente pas !

Si tu te lances dans un jeu, il y a une tâche très consommatrice de temps que l'on néglige souvent: les releases.

Je prend note.

il faut pouvoir sortir des binaires pour le maximum de plateformes

Dans un premier temps, si je release des démos, ça ne me dérange pas que ce ne soit pas disponible sur un maximum de plateformes. Mais je ne veux pas me bloquer par la suite, donc le choix est important dès le départ.

les API peuvent changer et ça prends du temps de migrer, surtout si ces API ne maintiennent pas la compatibilité entre deux versions.

Là dessus, c'est bien la raison pour laquelle je regarde des bibliothèques très jeunes et en version 2 : l'API est sans doute meilleure et plus aboutie que la version 1, et elle risque de durer un moment.

Sinon selon le type de jeu que tu veux faire, je te conseillerais des solutions plus facile à releaser: libgdx, playn, html5, pygame, haxe…

Je me sens très à l'aise avec C++, donc je vais laisser de côté Java et les autres langages ;)

Mais du coup, je ne me sens pas plus avancé. Parce que je comprends tout ce que tu dis et j'en étais là il y a peu. Mais quand même, une fois qu'on a regardé l'API de SFML2, on se dit qu'il manque des trucs à la SDL2. Et c'est ça qui m'embête bien.

Oui, c'est une différence, mais ça n'est pas si important. L'existence d'un binding C montre que la différence est essentiellement syntaxique, la SFML utilise assez peu les spécificités de l'orienté objet finalement.

Pas énormément de différence, c'est sur l'essentiel. Mais après, quand tu regardes de plus près, SFML a des trucs intégrés au niveau de la bibliothèque qui sont totalement absents de la SDL.

Si la Sécu avait été privatisée

Je vais t'apprendre un truc, la Sécu n'a jamais été publique, elle a toujours été privée et ses agents ne sont pas des fonctionnaires. Comme quoi, hein…

la sécurité sociale, invention française géniale du front populaire

Non, la sécurité sociale dans sa forme actuelle a été mise en place par le Conseil National de la Résistance dans son programme «Les jours heureux».

Le lien du JAR, je l'avais vu, mais ça m'aide pas… J'en fais quoi après ? Et puis est-ce que je vais avoir tout le SDK ? Est-ce que j'aurai accès à tous les scripts shell qui sont dans bin dans le dépôt ?

Par contre, c'est une grosse somme d'argent (on est à 1,2 millions à l'instant où j'écris) qui va aller largement soutenir des causes qui en ont besoin. Et ça, on a du mal à être totalement contre, non?

Si, parce qu'il y a certainement des raisons fiscales qui poussent à choisir des associations américaines (indice : 501c). Moi je vois ce Humble Bundle comme une façon pour les internautes de payer les impôts d'Electronic Arts.

Est-ce que tu pourrais faire un tarball à décompresser dans /opt pour permettre de tester plus facilement ? Les instructions dans build.txt et install.txt ne sont pas très claires pour moi…

En tout cas, le coup des define pour les boucles for, c'est vraiment pas mal pour ce genre de concours où il faut coder vite.

Oui d'ailleurs, je m'étonne que la qualité du résultat ne soit pas jugé, juste le temps mis pour coder. Typiquement, dans l'exemple que tu donnes, le premier exercice est un calcul de chemin critique et le second est un calcul de nombre de composantes connexes. Dans les deux cas, il existe des algorithmes qui vont bien et toute un série d'algorithmes sous-optimaux. Mais là, vu les tailles des instances, peu importe, même un truc naïf va marcher. Et gagnera s'il est codé en très peu de temps…

Justement, ce n'est pas ce qui est dit dans le lien mentionné plus haut ni dans l'article mentionné plus bas. Parce que quand on récupère une base de données comme dans le cas présent, le grain de sable se trouve en clair à côté donc ça ne change pas grand chose. Si tu attaques un seul mot de passe, ça ne change rien. Si tu attaques tous les mots de passe, le grain de sable ne protégera pas assez les plus faibles des mots de passe. Parce que de toute façon, tu vas péter 50% des mots de passe en quelques heures en testant les trucs les plus faciles.

Et puis le grain de sable, il vaut mieux le suffixer que le préfixer. Si tu le préfixe, tu peux calculer l'état du hash après avoir lu le grain de sable et ensuite tu repars de cet état pour tester la deuxième partie sans avoir à recalculer le début.

Considérer que l'utilisateur est un idiot est une excuse de plus en plus employée pour justifier de ne pas implémenter des fonctionnalités (voire pour en enlever), c'est très agaçant. La bonne solution serait justement de chercher comment rendre accessible et compréhensible ces fonctionnalités.

Tout ce que l'on écrit sur le net tombe dans le domaine public

Houla, non. Ce qui est publié, sur le web comme ailleurs, reste la propriété de son ou ses auteur(s).

Ni l'un, ni l'autre, quelque chose entre les deux ! L'auteur (puis ses descendants) a un monopole sur l'exploitation commerciale de son œuvre jusqu'à 70 ans après sa mort, ensuite ça va dans le domaine public.

Oui enfin, il y a suffisamment de gens qui travaillent sur la preuve de programme et/ou la vérification de programme pour savoir que c'est un problème extrêmement complexe dans le cas général et que si tu peux y arriver sur quelques exemples, là le commentaire demande clairement à ce que tous les programmes soient garantis.

si c'est vendu c'est que le fonctionnement est garanti par ceux qui programment.

Ce que tu demandes est tout simplement impossible : Problème de l'arrêt

Tu dis «Les objectifs sont les mêmes au niveau du support utilisé (la pub)» et j'ai déjà répondu : oui les techniques sont semblables (la forme) mais les objectifs (le fond) sont complètement différents. Tu confonds les deux pour mieux servir ton propos et assimiler l'un à l'autre. Alors que la nature (le fond) des deux n'a strictement rien à voir.