Aller au contenu

[C]Effacement de la console...


Don_Angelo

Messages recommandés

Bonjour à tous,

Dans le cadre du projet de fin de semestre à la fac, je dois coder un petit jeu d'échec en console. L'usage d'une interface graphique n'est pas demandé et n'est pas autorisé vu que tous les étudiants n'ont pas suivi le cours de développement graphique qui est optionnel.

Pour que l'affichage du programme soit plus propre j'efface l'écran après chaque coup. Alors le problème étant que je me sers de system() pour le faire. Sauf que le code devant à la fois être utilisable sous windows et linux, et bien ça pose un petit soucis. Parce que pour unix on doit faire un system("clear") et pour windows un petit system("cls"). Je n'ai pas trouvé de solution satisfaisante sur le net, ou alors j'ai mal cherché. Donc l'idée m'est venue de recoder un genre de mini fonction qui regarde sur quel système le programme est exécuté et envoie la commande ad hoc, car si je comprends bien system() envoie une commande à un terminal. Ne sachant pas si c'est possible j'ai cherché un petit palliatif.

La solution que j'ai adopté temporairement et qui n'est pas très élégante à mon goût:

Faire un getenv("SHELL") qui n'est pas défini sur Win, donc renvoie null, et qui est valable sur Unix ce qui me permet de distinguer le système. C'est barbare, mais testé sous XP ça a l'air de convenir.

Donc je me demande si il y a plus élégant pour faire cela proprement, sans les ifdef que mon prof juge comme étant une méthode de sauvage.

Avez-vous des idées sur la question?

D'avance Merci.

Lien à poster

J'avais pensé en premier lieu à du #ifdef...

Ben tu pourrais avec une boucle remplir l'écran de caractère ' ' (espace) avant de rebalancer ton affichage... mais c'est nul, et paye ta vitesse de rafraîchissement...

Ou alors (idée saugrenue), tu pourrais demander directement au matériel un vidage de l'écran sans passer par les routines de l'OS. Exemple, l'interruption 10h du BIOS permet de positionner le mode vidéo (http://heim.ifi.uio.no/~stanisls/helppc/int_10-0.html), et par la même occasion cela réinitialise l'affichage...

Alors avec un bloc assembleur tu pourrais réaliser cet appel... en plus c'est rapide et c'est pas OS-dependant, par contre ça ne tourne peut-être que sous x86.

asm {

mov AH, 07h

int 10h ; récup mode vidéo courant dans AL

mov AH, 00h

int 10h ; positionne le mode vidéo spécifié en AL

}

Bon c'est peut-être n'imp, en plus je ne sais comment ce genre d'appel est plus ou moins intercepté par l'OS en fait (s'il y a interception...), mais j'essaierais bien par curiosité...

@+

Lien à poster

thev>Ouais c'est une idée interessante, mais je ne sais pas si le prof apprécierai que je balance du code en asm, dans le programme en C en fait. Celà dit je la garde dans un coin.

momo> Le problème c'est que dans les deux liens que tu présentes à ce que j'ai compris, la solution proposée revient à une compilation conditionnelle avec des ifdef, ce que le professeur ne veut surtout pas voir.

Quant aux codes ANSI, le problème étant, si j'ai bien compris, qu'il faut soit que la machine possède des pilotes installés, soit que la machine soit spécifiquement configurée pour. Or sur les machines où nous allons présenter notre code ce n'est pas le cas, et je pense que ça ne doit pas être le cas pour bon nombre de pc sous windows.

Juste pour que je me fasse une idée, à quel point ma "solution" est crade au niveau des normes et de la sémantique?

Lien à poster

Question bete : tu ne peux pas en début de programme faire un test pour savoir sur quel systeme tu le lance et positionner une variable en fonction, et faire des tests sur cette variable ensuite ? (dans l'idée, le test initial serait plus compliqué que le test de la variable, donc il serait interessant de ne le faire qu'une fois et de tester la variable plusieurs fois).

Autre idée, passer par un fichier paramêtre dans lequel tu dis si tu es sous un windows ou sous un linux (et donc ton programme compilé marche sur les deux).

...

Lien à poster

sinon, tu peux tout simplement ne pas effacer la console ...

genre une option permettant de dessiner l'intégralité de l'ecran mais un comportement par défault en "aveugle" avec seulement les coordonnées des coups ...

gnuchess marche comme ça, non ?

Lien à poster

Mince j'avais oublié ce thread.

Le code a été virtuellement rendu, mais j'ai une soutenance vendredi, il était trop tard pour intégrer ou la solution de storm ou celle de loone qui m'avaient toutes deux beaucoup plus.

La solution adoptée en fait ben comment dire, déclarer une fonction cls()

dont voici le code:

    
if(getenv("SHELL")) system("clear");
else system("cls");

Je sais c'est affreux, parce que je voulais éviter ça, mais en même temps je n'avais plus le temps de faire de trop grosses modifs d'autant qu'avec mon binôme nous étions en retard par rapport au projet, le code n'était pas encore terminé au matin la veille de la date limite de dépôt. Tout a été fini dans la journée. :oups

thev>Le prof ben il nous dira ce qu'il en pense le jour de la soutenance où il va falloir rendre des comptes, mais franchement, je pense qu'il ne s'attardera pas trop sur ce "détail" et préfèrera nous engueuler sur les fonctions plus importantes, où nous avions annoncé qu'on ne suiverait pas le sujet vu que c'était vraiment trop 'con' par moment.

Cela dit, j'utiliserais bien les solutions trouvées dans ce thread dans les codes que je ponderais à partir de maintenant.

momo> Oui nous avions pensé à quelques choses de ce genre, mais ce n'était pas trop permis par le sujet vu qu'on nous demandait clairement un affichage de l'échiquier ainsi que des diverses info telles que le joueur courant. Vu que tout ceci devait se passer dans la console, ça deviendrait bien vite illisible si on ne l'efface pas, à moins d'aérer de quelques lignes entre chaque nouvel affichage, mais en même temps c'est typiquement ce que font les fonctions d'effacement de console, donc on s'est dit qu'au fond ça revenait plus ou moins au même.

En plus je me rends compte qu'on s'est pris la tête pour rien en essayant de coder convenablement vu qu'en fait les profs ne jugent quasiment pas la qualité du code, mais regarde en priorité si il fonctionne. Les groupes qui ont déjà passé la soutenance m'ont dit que même si on code comme un sagouin mais que le code fonctionne et que je peux répondre aux questions des profs je m'assure déjà d'office entre 12 et 15/20.

Lien à poster
×
×
  • Créer...