Le topic de la programmation, string, chaînes, cuir et compagnie

[rOut]

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.

[war-p]

Ouais te fait pas chier, utilise SDL, c'est un million de fois plus simple, et c'est cross plateforme...

[Tomaka17]

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.

[rOut]

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.

[war-p]

Ben là ça marche bien pour l'instant

http://tof.canardpc.com/view/1f58854...a6f19dac0d.jpg

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.

Faut pas oublier qu'avec df, les caractères spéciaux, ce sont des images...

[Tomaka17]

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

[war-p]

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

Va falloir voir avec plein d'unité... Je me souviens de df où dès que t'atteignait un certain nombre de nain, ça devenait compliqué pour le pc...

[Tomaka17]

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.

[war-p]

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.

Ouais, je pensais aux traitement du genre du pathfinding, SDL, je me fais pas de bile, c'est solide!

[Møgluglu]

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)

[Tomaka17]

Ou alors sans vertex buffer mais avec seulement de la tessalation.

Ou comment demander une carte graphique de dernière génération dans la config minimum pour un jeu en mode texte

[Møgluglu]

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)

[rOut]

[Tomaka17]

Je veux ce logiciel de création de shader !

[newbie06]

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)

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 ?

[Møgluglu]

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.

[newbie06]

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.

Beuh ? Ma reflexion portait plutot sur l'aspect acceleration materielle 2d vs 3d. Pour le reste je suis evidemment d'accord avec toi

[war-p]

Je veux ce logiciel de création de shader !

Vas-y, tu peux commencer à le coder... Tu peux toujours t'inspirer de l'outil de l'udk pour créer ses shader.

[Tomaka17]

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.

[deathdigger]

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

[rOut]

C'est quoi un EDM?

[Tomaka17]

Ca a l'air d'être un Espèce De Merdier.

[deathdigger]

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 :

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

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.
Bref, un vrai truc de feignasse, mais quand t'as gouté, c'est très difficile de revenir en arrière.

[ducon]

Ca a l'air d'être un Espèce De Merdier.

Ou en……… de m…….

[rOut]

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

[Tomaka17]

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.

[Robix66]

Si je propose DirectWrite je me fait taper dessus je suppose ?

[rOut]

Si je propose DirectWrite je me fait taper dessus je suppose ?

Oui, parce que mon appli est portable. Et sous Linux c'est beau automatiquement. C'est juste sous Windows que c'est moche.

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.

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.

[rOut]

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 :

[vectra]

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.

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

Ca fonctionne bien pour tous les types définis avant la compilation.

Le volume créé possède la tronche suivante sur disque:

myvol_int.hdr  : fichier descriptif indiquant la dimension et le type de données, entre autres
myvol_int.img : fichier RAW, tout simplement.

Ca permet notamment l'instanciation suivante:

Volume<int> myvolrelu_int("/tmp/myvol_int");
myvolrelu_int.traitement();
//etc

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.

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:

Volume<int> myvolrelu_int("/tmp/myvol_int");

puisque, dans ce contexte, on peut recevoir des volumes de float, double, etc.


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