# langage C : coordonnées dans un jeu



## BiG ToM (11 Juin 2008)

Bonjour,
Pour la réalisation d'un jeu, nous cherchons à modifier les valeurs dans une matrice qui représente la grille du jeu.
En fait on entre les coordonnées de la matrice où on veut jouer et on met une croix dedans.
On sait comment faire mais, comment est il possible de modifier la valeur et réafficher les nouvelles grille avec la croix que l'on a placé ???
Merci


----------



## PA5CAL (11 Juin 2008)

Bonjour

Hum... 

Comme la seule indication dont on dispose c'est que programme est en langage C, on va avoir beaucoup de mal à deviner tout seul tout le reste...

Un petit mot sur l'environnement, l'interface utilisateur et les librairies employées, peut-être ?


----------



## BiG ToM (11 Juin 2008)

http://www.iuta-geii.univ-lille1.fr/projetstut1/data/Sujet_4_Noemix.pdf

voila le lien comme ca cela sera clair. En fait on a réalisé la grille de départ mais on ne sait pas comment modifier l'affichage de la grille lorsqu'on entre les coordonnées....


----------



## PA5CAL (11 Juin 2008)

Ça m'a tout l'air d'être un jeu en mode texte.

Le plus simple est d'effacer l'écran et de réafficher entièrement la grille avec son nouveau contenu.

Sinon, si c'est possible (mais cela dépend de l'interface utilisateur), on peut se passer d'effacer l'écran et se contenter de déplacer le curseur pour n'aller modifier que la croix rajoutée.

Il faudrait avoir plus de renseignements pour pouvoir en dire plus... Dans quoi va devoir tourner le jeu ? Une fenêtre Terminal ? Une fenêtre Aqua ? La console X ? Une fenêtre graphique X ?


----------



## BiG ToM (11 Juin 2008)

Oui on voudrait faire  ce que tu dis mais on ne siat pas comment sachant que l'on a déja une fonction Affichage qui affiche la grille je ne sais pas si c'est dans une fonction qui fallait la mettre mais bon...
L'affichage se fait sur le terminal


----------



## PA5CAL (11 Juin 2008)

Y aurait-il déjà une fonction d'effacement de prévue ?

Sinon, on peut lancer une commande système "_clear_" pour effacer la fenêtre du Terminal, ou bien encore "afficher" des caractères de contrôle pour provoquer la remontée du curseur jusqu'en haut de la grille avant de rappeler la fonction d'affichage.

Dans le réglage par défaut de la fenêtre Terminal, on doit pouvoir faire remonter le curseur au début de la ligne du dessus grâce aux caractères "\b\r".


----------



## Museforever (15 Juin 2008)

J'avais fait un Pacman qui fonctionnait un peu sur le même principe. Il te suffit de parcourir ton tableau case par case (2 for imbriqués) et pour chaque case de faire un gotoxy(x,y) où x et y sont les coordonnées du caractère à afficher. Et juste après tu fais un cout de ce caractère. Et tu mets tout ça dans un do while pour le faire tourner en boucle.

C'est pas la meilleur méthode, mais si tu la comprends tu pourras facilement l'améliorer. Et ce n'est pas facile à expliquer non plus car ton programme peut être fait de plein de façons, donc sans voir le code c'est pas super facile à trouver une solution.


----------



## p4bl0 (19 Juin 2008)

NCurses ?
Announcing ncurses 5.6 - GNU Project - Free Software Foundation (FSF)
ncurses - Wikipedia, the free encyclopedia

C++ : NCurses Development Kit for C++


C'est assez simple à prendre en main : j'ai réussi à écrire un Tetris en C avec ncurses juste en me servant des pages de man (elles sont très bien foutues !) quand j'avais pas encore internet à mon appart.

Ça te permettra de facilement faire ce que tu demandes


----------



## tatouille (20 Juin 2008)

p4bl0 a dit:


> NCurses ?
> Announcing ncurses 5.6 - GNU Project - Free Software Foundation (FSF)
> ncurses - Wikipedia, the free encyclopedia
> 
> ...



oui c'est ce que j'allais suggerer  car faire des clears c'est assez limite deplacer un curseur aussi on obtient jamais vraiment ce qu'on veut et ca varie d'un term emulator a un autre


----------



## PA5CAL (20 Juin 2008)

Il est vrai que "\r" risque d'être interprété différemment suivant les systèmes.

Mais utiliser NCurses pour répondre à un exercice scolaire risque d'être hors sujet.

On peut admettre à la limite que les librairies dynamiques nécessaires au fonctionnement de NCurses fassent partie du système lorsqu'on est sous Mac OS X ou Linux.

Mais il est probable que l'exercice doive tourner au final sur un PC sous Windows (bien que _*nous n'ayons pas encore eu de réponse à ce sujet*_), lequel nécessiterait alors forcément un composant logiciel supplémentaire (passage par Cygwin, ou portage de NCurses par GnuWin32 par exemple).

Et si les composants logiciels extérieurs spécifiques à l'OS sont autorisés, alors autant passer carrément à un véritable environnement graphique.

Et si tel n'est pas le cas, peut-être vaudrait-il mieux se tourner vers les *séquences escape ANSI*, qui ont toutes les chances d'être acceptées par tous les systèmes, moyennant (seulement) un paramétrage adéquat.


----------



## p4bl0 (21 Juin 2008)

Si son prof d'info est pas sur un UNIX c'est lui (le prof) qui mérite une mauvaise note 

Puis si il est sous windows et qu'il a pas cygwin d'installé ça doit pas être un informaticien de toutes façons :rateau:


----------



## PA5CAL (21 Juin 2008)

Le dernier prof d'info que j'ai eu à l'école était venu quelques temps avant les premiers cours pour se faire la main dans la salle informatique. À ce moment, nous ne savions pas qui il était. Il est bien resté dix minutes à tourner autour d'un IBM PC (un vrai de vrai, à l'époque, pas un "compatible"). Il a fini par nous demander comment on l'allumait (le gros interrupteur rouge était pourtant situé dans un logement noir bien visible sur le côté droit, si je me souviens bien). Quand on l'a reconnu à l'entrée du premier cours qu'il nous a prodigué, on a tous pensé qu'on était mal barrés ! La suite l'a prouvé, et le taux d'assiduité a vite chuté.

Bref, tout ça pour dire que les profs d'informatique ne sont pas forcément informaticiens (tout comme certains profs ne sont pas forcément compétents dans la matière qu'ils enseignent - ce n'est pas un reproche que je leur fait, c'est seulement un constat).


----------



## mtgred (23 Juin 2008)

Si tu as une matrice qui s'appelle "m" ayant "n" lignes et "m" colonnes, ce bout de code devrait affiche le contenu de ta matrice sur la console.


```
for(int i = 0; i < n; i++) {
  for(int j = 0; j < m; j++)
    if(m[i][j])
      printf(" x ");
    else
      printf(" 0 ");
  printf("\n");
}
```


----------



## p4bl0 (23 Juin 2008)

amha là gcc il gueule hein  

j < m;
m_[j]_


----------



## mtgred (23 Juin 2008)

p4bl0 a dit:


> amha là gcc il gueule hein
> 
> j < m;
> m_[j]_


_

Euh oui en effet 

for(int i = 0; i < n; i++) {
  for(int j = 0; j < m; j++)
    if(mat[j])
      printf(" x ");
    else
      printf(" 0 ");
  printf("\n");
}_


----------



## Didier Guillion (23 Juin 2008)

Amusant...
Juste une remarque anodine.
Je sais qu'a l'époque des cartes perforées, on réduisait les noms des variables à une lettre car on faisait tout à la main à l'époque.
Mais pourquoi ne pas utiliser "NombreDeColonnesDansLeTableau" au lieu de "m", "PositionEnColonneDansLeTableau" au lieu de "j", etc, etc.
A défaut de commenter, mais c'est une autre histoire, cela simplifierait la lecture non ?

Cordialement


----------



## PA5CAL (23 Juin 2008)

Didier Guillion a dit:


> pourquoi ne pas utiliser "NombreDeColonnesDansLeTableau" au lieu de "m", "PositionEnColonneDansLeTableau" au lieu de "j", etc, etc.
> A défaut de commenter, mais c'est une autre histoire, cela simplifierait la lecture non ?


"m" et "j" sont probablement moins parlants que  "NombreDeColonnesDansLeTableau" et "PositionEnColonneDansLeTableau".

En revanche, ces deux derniers sont longs à taper, ils risquent à la longue d'occasionner de la fatigue et des erreurs de frappe, et puis ils sont finalement assez peu lisibles.

On rallongerait inutilement le temps de développement sans beaucoup gagner au niveau de la lisibilité (... pas bon !).

Les noms longs et explicites sont à réserver pour les éléments dont on ne voit pas immédiatement la fonction parce qu'ils sont trop délayées dans le code source.

Quand la portée d'un variable est limitée à trois ou quatre lignes, la question ne se pose pas vraiment, à moins que l'opération codée ne soit pas triviale.

Dans les autres cas, il me semble que pour les éléments qui apparaissent souvent, il est préférable de choisir un nom assez court mais suffisamment explicite, et d'accompagner sa déclaration ou sa première utilisation d'un commentaire explicatif.


Dans le cas présent, je laisserais "i" et "j", et je rallongerais "m" et "n", et éventuellement "mat".


----------



## tatouille (23 Juin 2008)

oui ca depend, mais pour ce genre de chose, de simple lettre "mathematique" sont lisibles

m (matrix), r (row), c (column) 
par exemple c'est bien aussi

while(r)
-> --r
-->while(c)
-----> --c

#define MAX(a,b) (a>b ? a : b)

mais apres c'est une question de style, si tu utilises des frameworks avec beaucoup de deco
t'as tendence a Reproduire afin d'obtenir une homogénéité de lecture

```
typededef int32_t IndexType;
typededef void NoReturnType;
typededef const *void TypeRef;

// Matrix NumberOfRow NumberOfColumn

NoReturnType 
MatrixPaint(
  IndexType NumberOfRow, 
  IndexType NumberOfColumn, 
  ...);

typedef struct {
  int32_t r;
  int32_t c;
} matrix_t;

...

void   
matrix_paint(
  int32_t r, 
  int32_t c, 
  ...);

matrix_t   
matrix_create(
   int32_t r, 
   int32_t c);

void   
 matrix_paint( matrix_t , ...
```
si 1,  rien n'interdit de packer son code avant compilation, le tout c'est d'etre human bitable


----------



## p4bl0 (23 Juin 2008)

Les noms de variables explicites je trouve ça très bien mais en l'occurence pour i et j c'est tellement courant de s'en servir pour le parcours d'un tableau que les deux lettres sont assez explicites en elles mêmes.

Mais sinon appelé une matrice "m", "mat", "matrice" dans un vrai programme c'est pas coule par contre, la matrice c'est "quelque chose" : une grille de jeu par exemple. Donc faut lui donner un nom en rapport avec ça 

*EDIT:* connexion internet foireuse y a eu deux réponses depuis que j'ai pas pu poster :-/


----------



## PA5CAL (23 Juin 2008)

p4bl0 a dit:


> *EDIT:* connexion internet foireuse y a eu deux réponses depuis que j'ai pas pu poster :-/


Grillé !


----------



## tatouille (23 Juin 2008)

p4bl0 a dit:


> Les noms de variables explicites je trouve ça très bien mais en l'occurence pour i et j c'est tellement courant de s'en servir pour le parcours d'un tableau que les deux lettres sont assez explicites en elles mêmes.
> 
> Mais sinon appelé une matrice "m", "mat", "matrice" dans un vrai programme c'est pas coule par contre, la matrice c'est "quelque chose" : une grille de jeu par exemple. Donc faut lui donner un nom en rapport avec ça
> 
> *EDIT:* connexion internet foireuse y a eu deux réponses depuis que j'ai pas pu poster :-/



ou i,j,k est nomenclature utilisee pour les incrementales ou indexes, pas vraiment "la variable de reference"


----------



## Didier Guillion (23 Juin 2008)

PA5CAL a dit:


> "m" et "j" sont probablement moins parlants que  "NombreDeColonnesDansLeTableau" et "PositionEnColonneDansLeTableau".
> 
> En revanche, ces deux derniers sont longs à taper, ils risquent à la longue d'occasionner de la fatigue et des erreurs de frappe, et puis ils sont finalement assez peu lisibles.
> 
> ...




Bof... Le temps de dev... Le copier/coller c'est autorisé.
Mais je ne te critique pas vraiment c'est ce que l'on apprends dans les écoles. On s'imagine que si le source est plus court, le résultat est plus optimisé. Faribole, billevesée.
Reste a savoir si tu veut *coder* ou *écrire*.
 La prog, c'est un moyen pour toi ? (De passer à autre chose) Ou un but de t'exprimer ?
Soit verbeux, commente.
 Fais toi plaisir. 
N'oublie pas, petit scarabé,   "Un source, c'est du commentaire avec des lignes de code autour".

Pense a ceux qui vont te lire. Ou toi même... 
Dans 20 ans, tu te comprendra ?


Cordialement


----------



## PA5CAL (23 Juin 2008)

Didier Guillion a dit:


> Bof... Le temps de dev... Le copier/coller c'est autorisé.
> Mais je ne te critique pas vraiment c'est ce que l'on apprends dans les écoles. On s'imagine que si le source est plus court, le résultat est plus optimisé. Faribole, billevesée.
> Reste a savoir si tu veut *coder* ou *écrire*.
> La prog, c'est un moyen pour toi ? (De passer à autre chose) Ou un but de t'exprimer ?
> ...


Ce n'est pas en faisant des copier-coller qu'on arrive à produire 300 à 500 lignes de code inédites par jour. Le code le plus court ne donne pas le résultat le plus optimisé, mais il prend sûrement moins de temps à être fabriqué et à être relu.

Sur des projets de plusieurs centaines de milliers de lignes de code, des budgets de quelques millions d'euros et des plannings calibrés au jour près sur plusieurs années, si l'on s'était permis d'utiliser des noms d'une trentaine de caractères, les retards accumulés nous auraient empêchés d'honorer nos engagements vis-à-vis de nos clients, on aurait dû payer des pénalités de retard astronomiques, perdu des marchés, et peut-être fini par mettre la clé sous la porte.

Quant aux commentaires et à la documentation, ils doivent être comme le code : en corrélation avec le but recherché et les ressources du projets. Ils doivent pouvoir être compris et remis à jour à chaque fois que nécessaire, et parfois plusieurs années après et par des personnes différents.

Pour info, j'ai eu à retravailler récemment sur des sources qui datent de vingt ans. Heureusement que j'ai réussi à les relire pour pouvoir les modifier, parce que le client, lui, n'attend pas.


----------



## Didier Guillion (24 Juin 2008)

Le code le plus court est certainement le plus rapide à écrire mais assurément pas le plus rapide à relire ! Ni à débogger !

Et tu arrive à caller des projets de plusieurs années au jour près, 'tain, tappe à la porte de M Gate, ils ont besoin de toi...


Cordialement


----------



## PA5CAL (24 Juin 2008)

Didier Guillion a dit:


> Le code le plus court est certainement le plus rapide à écrire mais assurément pas le plus rapide à relire ! Ni à débogger !


Exact, mais il y a une juste limite à atteindre, dont j'ai indiqué quelques principes au post #17.


Didier Guillion a dit:


> Et tu arrive à caller des projets de plusieurs années au jour près, 'tain, tappe à la porte de M Gate, ils ont besoin de toi...


Oui, au jour près sur plusieurs années, parce qu'*on ne donne pas dans l'amateurisme*.

Les projets qu'on traite sont parfois longs, et ils entrent en interaction avec d'autres qui nécessitent un partage des mêmes ressources. De plus, ils  sont soumis à des contrats très stricts quant aux délais, avec des pénalités de retard, qui sont bien fixées au jour près des années à l'avance, elles.

Or, les éventuels ratages (et heureusement ils sont rares) ne peuvent pas se résoudre par un allongement des périodes d'allocation des ressources (programmeur, expert métier, client, ordinateurs, matériels, site d'étude, site d'industrialisation, site d'exploitation, hôtel, moyen de transport...). Un dépassement des délais, même minime, demande souvent un report et une réorganisation de l'ensemble du projet chez les différents acteurs (dont beaucoup sont extérieurs à l'entreprise). Et *le report peut parfois atteindre plusieurs mois* !

C'est pour cette raison qu'en cas de difficulté, on assiste à un allongement de la durée du travail, et à un gonflement des équipes. On passe la semaine de 40 heures à 70 heures (adieu les weekends et les congés), et même les directeurs reviennent parfois participer aux brainstormings ou "pisser de la ligne".

Alors pour éviter d'en arriver là, chacun doit faire son métier correctement, à commencer par le codage du programme qui ne doit faire ni plus ni moins que ce qui est nécessaire et suffisant.


Je ne pense pas que cette situation soit exceptionnelle, car certains parmi mes amis et les membres de ma famille la vivent aussi. Compte tenu de tes remarques, je me permets de m'interroger sur le sérieux avec lequel on pratique le développement logiciel dans ton milieu. Mais peut-être ne s'agit-il que d'un hobby.

Cordialement


----------



## Didier Guillion (24 Juin 2008)

PA5CAL a dit:


> Compte tenu de tes remarques, je me permets de m'interroger sur le sérieux avec lequel on pratique le développement logiciel dans ton milieu.
> 
> Cordialement



Touché ! En effet, je ne cherche pas a me prendre au sérieux. Je m'amuse a faire ce que je fait.
Ce que tu me décrit est une vision réaliste de ce qu'est le développement pour certains : "pisser du code" pour tenir le délai.

"It compile, ship it!"

Heureusement, il en reste pour prendre leur pied a coder et dans ce cas, un code propre et élégant, bien commenté et clair, avec des noms de fonctions et de variables adéqua est une satisfaction.

Cordialement


----------

