Heu Dwarf Fortress, le mec s'est fait chier a coder une interface ncurses, mais c'est totalement merdique et ce n'est pas l'affichage par défaut. Sous Linux il fait comme sous Windows, via la SDL.
Heu Dwarf Fortress, le mec s'est fait chier a coder une interface ncurses, mais c'est totalement merdique et ce n'est pas l'affichage par défaut. Sous Linux il fait comme sous Windows, via la SDL.
"Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."
Ouais te fait pas chier, utilise SDL, c'est un million de fois plus simple, et c'est cross plateforme...
Ben là ça marche bien pour l'instant
Ca rame pas, c'est simple à utiliser, et je consomme en tout et pour tout que 3.5 Mo de RAM.
En fait il y a deux inconvénients :
- pas de choix des caractères, et les trucs genre ☺▼■ ne marchent pas sous windows
- pas de choix des couleurs, je voudrais mettre du rouge à la place du blanc mais le #ff0000 est vraiment trop flashy
Je compte garder cette vue tant que j'aurai pas fini les mécaniques de jeu.
Rust fanboy
Mouais, et ça ne rame pas non plus si tu commences à afficher 150 objets qui bougent et / ou si tu scrolles l'écran ? Je veux dire si tu dois mettre à jour de grandes parties de l'écran.
"Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."
En fait je mets à jour l'écran 60 fois par seconde, vu que c'est le plus simple à faire.
Je redessine à chaque fois tout le sol, toutes les unités et tous les objets.
Je ne consomme que 2/3% du CPU.
Evidemment ce serait beaucoup plus efficient de ne mettre à jour que lorsqu'une unité ou un objet se déplace. Pas que ce soit difficile à faire, mais un peu chiant.
Cela dit je crois que pdcurses a un cache de l'état de la console et ne fait rien si l'appel de fonction ne fait pas changer la case.
Mais quand je scroll ça ne pose pas de problème non plus.
Si tu ne me crois pas : http://www.mediafire.com/?k0bk8onzpp1ue84
Rust fanboy
Je pense que le fait que ça rame vient de la logique du jeu : pathfinding, déplacements, etc.
Avec la SDL ce serait surprenant que dessiner 200 images fasse ramer le jeu, même si la SDL a pas forcément bonne réputation niveau performances.
Là j'ai essayé avec 1000 unités, et ça rame toujours pas (7 % de CPU) vu qu'elles sont toutes inactives.
Rust fanboy
C'est basé sur OpenGL ? Quelques centaines de milliers de polygones texturés en 8x8 ne devraient pas faire trop de mal à un GPU intégré d'il y a 10 ans…
Avec des vertex buffers et texture résidentes et un vertex shader qui décode le texte en calculant les coordonnées de texture et la couleur pour chaque rectangle… Ou alors sans vertex buffer mais avec seulement de la tessalation.
Pour les caractères exotiques, il faut déjà avoir une police bitmap 8x8 à largeur fixe, non ? (de l'OpenType scalé à cette échelle ça doit être affreux)
Rust fanboy
Bah, même le GPU de Carma gère la tessalation.
J'avais aussi pensé au Dynamic Parallelism en CUDA pour faire tourner tout le code sur GPU, mais c'est géré que sur Tesla K20 pour l'instant, et il n'a pas de sortie vidéo.
N'empêche, un jeu complet GPU-only, ça existe ? (en utilisant le CPU juste pour booter et pour les I/O qui ne sont pas accessibles par DMA depuis le GPU)
"Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."
Je veux ce logiciel de création de shader !
Rust fanboy
Quel monde de merde ou on a besoin d'un GPU pour afficher des caracteres.
Dans une precedente vie (enfin precedent job), on avait un outil porte de MS-DOS vers UNIX. Sous MS-DOS le debugger etait en mode texte donc hyper rapide. Le port avait ete fait sous X11 avec gestion des caracteres a la bite et au couteau (bitmaps et tout). Le resultat etait d'une rapidite hallucinante meme sur des machines depassees.
Me dites pas que maintenant en-dehors de l'acceleration 3D point de salut ?
Bah ton framebuffer il est (encore pour quelque temps) plus près du GPU que du CPU. Donc tu as intérêt à offloader le plus possible du rendu sur le GPU plutôt que de memcopier des bitmaps dans tous les sens.
Tu as toujours eu besoin d'un "GPU" pour afficher des caractères. La différence c'est que c'est maintenant fait dans des unités de calcul parallèle dédiées plutôt qu'en soft par le bios VGA ou toi-même.
Au final, c'est pas si différent, juste un tour de roue de Myer-Sutherland plus loin.
S'il y a des gens pas trop à jour niveau C++ et qui veulent s'y mettre :
http://channel9.msdn.com/Shows/Going...-Handling-in-C
J'ai pas regardé la vidéo, mais comme c'est Alexandrescu, c'est forcément bien expliqué et un peu drôle.
Rust fanboy
Truc de merde aujourd'hui sur VS2010 :
Je crée un projet, j'ajoute un EDM, je commence à faire bdd.totos.Add(toto) et là non, la méthode .Add n'existe pas
Alors bien sûr y'a la méthode bdd.totos.Addobject(toto) ou encore bdd.AddTototos(toto), mais les deux sont pas terribles.
Je cherche sur le net, et il semblerait que ce soit lié à ma version de l'EDM, sauf que je ne me suis pas amusé à la downgrader pour le plaisir
Edit : Je suis trop con, la bonne méthode c'est bien AddObject
Dernière modification par deathdigger ; 14/12/2012 à 16h35.
C'est quoi un EDM?
"Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."
Ca a l'air d'être un Espèce De Merdier.
Rust fanboy
Entity Data Model, la conversion de ta bdd (ou une partie) en objets en gros.
Par exemple, si t'as une table totos, et que tu instancies ta base de données en tant que Bdd ça te permet de le manipuler comme un objet :
L'avantage, c'est que tu te fais pas chier à créer ton SqlHelper et tout le bordel, tu crées ton objet simplement, tu l'ajoutes à ta collection avec bdd.Totos.Add(toto) et tu enregistres quand tu veux.Code:foreach(Toto t in Bdd.Totos) { MessageBox.Show(Toto.Nom); } //tu peux aussi faire des expressions lambdas comme ça : foreach(Toto t in Bdd.Totos.Where(x=>x.Nom.StartWith("coucou"))) //Et si t'es un oufzor, tu peux faire du linq var p = from Toto t in Totos where t.Nom.StartWith("coucou") select t.Id //Et si t'as des tables liées, tu peux directement aller les chercher (c'est une méthode de ton objet crée).
Bref, un vrai truc de feignasse, mais quand t'as gouté, c'est très difficile de revenir en arrière.
une balle, un imp (Newstuff #491, Edge, Duke it out in Doom, John Romero, DoomeD again)
Canard zizique : q 4, c, d, c, g, n , t-s, l, d, s, r, t, d, s, c, jv, c, g, b, p, b, m, c, 8 b, a, a-g, b, BOF, BOJV, c, c, c, c, e, e 80, e b, é, e, f, f, f, h r, i, J, j, m-u, m, m s, n, o, p, p-r, p, r, r r, r, r p, s, s d, t, t
Canard lecture
Ok c'est ce que je me disais aussi.
Sinon, quelqu'un connait un algorithme pour antialiaser une forme quelconque ? Je me bats avec pango/cairo sous windows qui a décidé qu'au delà d'une certaine taille c'était plus la peine de faire de l'antialiasing sur les polices...
"Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."
Ben t'as le MSAA qui consiste à dessiner sur une grande surface puis à réduire sa taille en faisant un filtrage bilinéaire.
Sinon t'as des algos de ce genre, mais ça se fait sur des images et ce sont des traitements assez complexes.
Rust fanboy
Oui, parce que mon appli est portable. Et sous Linux c'est beau automatiquement. C'est juste sous Windows que c'est moche.
C'est ce que j'ai fait finalement, échelle x3 pour cairo, puis rendu 5 fois en décalant légèrement à chaque fois, et un flou gaussien par dessus pour lisser encore peu. Ensuite le mipmap OpenGL réduit la taille de la texture et ça fait joli au final. Par contre je crois que ça rame un peu... mais tant pis je le fais qu'une fois normalement.
"Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."
Purée, du coup ça ne marchait plus sous Linux... il me faisait une vieille erreur "Out Of Memory" pour afficher UNE lettre dans un carré de 400x400 pixels. Je suis obligé d'ajouter des #ifdef pour faire d'une manière sous Windows et d'une autre sous Linux, c'est horrible.
---------- Post added at 01h01 ---------- Previous post was at 00h57 ----------
Tout ça pour ça :
"Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."
Coucou les canards.
Je galère un peu avec C++ et les templates. De fait, j'ai des questions
J'ai une template class pour gérer les volumes.
Ca fonctionne bien pour tous les types définis avant la compilation.Code:Volume<int> myvol_int(512, 512, 512); myvol_int.traitement(); myvol.set_file("/tmp/myvol_int"); myvol.write(); Volume<double> myvol_double(512, 512, 512); ...
Le volume créé possède la tronche suivante sur disque:
Ca permet notamment l'instanciation suivante:Code:myvol_int.hdr : fichier descriptif indiquant la dimension et le type de données, entre autres myvol_int.img : fichier RAW, tout simplement.
J'aimerais faire des petits programmes-outil qui soient capables de gérer un volume dont le type n'est connu qu'à l'exécution, type compris dans une liste limitative (uchar/int/float/double). Par exemple, faire des programmes qui binarisent ou seuillent, et des trucs un peu plus évolués aussi.Code:Volume<int> myvolrelu_int("/tmp/myvol_int"); myvolrelu_int.traitement(); //etc
Ce n'est pas de la préciosité: avec les float, je gère déjà des volumes d'un giga, et j'ai donc tout intérêt à adapter la précision selon l'usage.
On ne peut donc plus écrire dans le main:
puisque, dans ce contexte, on peut recevoir des volumes de float, double, etc.Code:Volume<int> myvolrelu_int("/tmp/myvol_int");
Dans l'état actuel, j'en ai été réduit à créer une classe wrapper: le fichier .hdr est lu et, selon le type de données qu'il indique, le wrapper va instancier le Volume du type correspondant. Ce n'est pas seulement inélégant, c'est carrément très fastidieux. Notamment parce que la classe wrapper ne sait rien faire, elle, et qu'il faut se débrouiller pour y porter les méthodes de Volume une par une.
Dites-moi que j'ai raté un épisode et qu'il est raisonnablement facile de faire cela proprement