Petits problèmes avec - Page 1

Salut !


J' ai un petit problème avec l' utilisation de structure, que je declare ainsi:

typedef struct
{
  unsigned short pX;
  unsigned short py;
  unsigned short pH;
  unsigned short pW;
}V; 

Mais alors, le compilo me mets 3 fois:

main.h:26: error: conflicting types for 'V'
main.h:26: error: previous declaration of 'V' was here.

Et bien sur, le compilo ne reconnait pas les structures lorsque j' essaye d'en créer.


Merci d'avance.

Edit: Hum desolé pour le titre, apparement l'utilisation des guillemts dans ce dernier serait à proscrire

tu n'utilises qu'une seule fois la variable V ?

En effet, ma structure n'est declaré qu'une seul fois !

ben, V il a l'air de connaitre (déjà déclaré..).... mais d'où?

ton main.h est peut-être inclu plusieurs fois

genre tu as :

// main.h
typedef struct 
{ 
  unsigned short pX; 
  unsigned short py; 
  unsigned short pH; 
  unsigned short pW; 
}V;  

et

// aaa.h

#include "main.h"
/* quelque chose */

puis

// main.c
#include "main.h"
#include "aaa.h"

void _main(void)
{
    // ...
}

Dans main.c, tu inclue tout d'abord main.h => main.h est inclu
puis tu inclus aaa.h, qui lui même inclu main.h => main.h est ré-inclu

donc, tu as deux fois le contenu de main.h => ta structure est définie deux fois => problème

pour ça, il faut empécher les inclusions multiples, avec quelque chose de ce genre dans chacun (par prudence) de tes .h :

// main.h
#ifndef _MAIN_H_
#define _MAIN_H_
typedef struct 
{ 
  unsigned short pX; 
  unsigned short py; 
  unsigned short pH; 
  unsigned short pW; 
}V;
#endif

comme ça, à la première inclusion, _MAIN_H_ n'exwiste pas => code inclu, et _MAIN_H_ créé
et à la seconde inclusion, _MAIN_H_ existe => code non ré-inclu

Hum, Merci.

de rien

(par contre, je vois rien de drole dans ce que j'ai dit )

bah, c'est juste que c'est à la mode ces tps-ci de mettre des #rotfl# partout

ah, ok

(dsl)

oué, enfin, pas une raison pour flooder non plus, hein

juste une petite remarque :

typedef struct
{
  unsigned short pX;
  unsigned short py;
  unsigned short pH;
  unsigned short pW;
}V; 

ca definit un type et non une variable ? (à cause du typedef)
et ensuite on declare la variable comme ca :
V var;

ou je suis complètement à la masse ce soir ?

oui oui, même si le message d'erreur laisse planer le doute ^^

oui et comme tout le monde (enfin au moins flanker) parlait de variable...

en fait, je pensais qu'il avait déclarer V comme variable et comme type

Ops, j' ai parlé trop vite: en fait, ma structure est censé enregistré les positions et la taille d' une sprite (les valeurs de la structure sont modifié lors de l' appuie d' une touche, ce qui permet de deplacer la sprite). Lorsque j' execute le programme, tout a l' air de se derouler normalement mais au bout de quelques mouvement de la sprite, le programme RAME anormalement. Lorsque je fais un printf de la valeur de la structure, j' obtiens la bonne valeur (76). Puis, dès que cette valeur passe à 31, mon programme se bloque carrement, et va de pire en pire, affichant des symbole au hasard dès que la position de la sprite est de 21, pour que finalement la sprite disparaisse....

poste ton code s'il n'est pas trop gros

ok,je vais quand meme le resumé :
//MAIN.H typedef struct {   int pX;   int pY;   int pH;   int pW; }VAISSEAU; extern unsigned char Svaisseau[];  //Sprite def extern VAISSEAU Hero;   //Sprite pos //MAIN.C #include "main.h" #include "sprite.h" #include "app.h" #include "game.h" VAISSEAU Hero; void _main( void ) {   Initialize();   while ( quit == 0 )   {     ClrScr();     KeyTest();     Maj();     Draw();     LCD_restore( fScreen );   }   Exit();   return; } //APP.H #include "main.h" void Initialize(void) {   Hero.pX = 76;   Hero.pY = 92-1;   Hero.pW = 84;   Hero.pH = 100-1;   return; } //(AUTO_INT 1 et 5 desactivé puis reactivé à la fin) void KeyTest(void) {   if((_keytest(RR_RIGHT)) && (Hero.pX < WIDTH - HEROWIDTH))     Hero.pX++;   if((_keytest(RR_LEFT)) && (Hero.pX > 0))     Hero.pX--;   return; } void Draw(void) {   //Sprite8(Hero.pX, Hero.pY, Hero.pH, SvaisseauM, fScreen, SPRT_AND); //mask   Sprite8(Hero.pX, Hero.pY, Hero.pH, Svaisseau, fScreen, SPRT_XOR);   return; }

une petite remarque comme ca : c'est Mal de mettre du code dans des .h, il ne sont sencés contyenir que des définitions (prototypes de fonctions ou déclarations de variables )
Mets plutot ton code dans d'autres fichiers .c et tu les compiles ensemble. Ca se fait dans tigcc tres facilement avec "add new c source" (ou ubn truc dans ce genre)
la fonction Maj fait quoi ?

le bug vient de la mauvaise utilisation des ecrans virtuels. là tu fais n'importe quoi.
tu dois :
- allouer un ecran virtuel
- utiliser PortSet pour dire à ams de dessiner dans cet ecran (si tu utilises des fontions d'ams)
à chaque frame :
- effacer l'ecran
- faire tout plein de calculs
- dessiner dans l'ecran virtuel (en passant l'adresse de ton ecran virtuel à sprite8 comme tu le fais)
- copier ton ecran virtuel vers l'ecran de la ti en utilisant memcpy
boucler
- dire à ams de desisner à nouveau dans l'ecran de la ti avec PortRestore
- liberer ton ecran virtuel

mais si tu n'utilises pas de fonctions d'ams pour l'affichage tu n'as pas besoin d'utilise PortSet et PortRestore
(si tu utilises printf il le faut)

Heuh en fait alors ne sachant pas que l' erreur venant du double buffer, j' ai zappé quelques déclarations et autres donc:

allouer un écran virtuel: extern char fScreen[LCD_SIZE]; (fait dans main.h)
utiliser PortSet: memset(fScreen, 0, LCD_SIZE); PortSet(fScreen, 239, 127); (fait dans la fonction Initialize(); )

effacer l'écran: ClrScreen(); a chaque debut de boucle
faire tout plein de calculs: ma fonction Maj() sert a cela
dessiner dans l' écran virtuel: ca donc ok
copier ton ecran virtuel vers l'ecran de la ti en utilisant memcpy: je crois que c'est à cela que sert LCD_restore: http://www.tiwiki.org/LCD_restore

PortRestore: PortRestore();


Voila.

tu n'alloues pas d'ecran virtuel en faisant un extern char fScreen[LCD_SIZE]; tu le déclares juste, et de toutes facons il ne faut jamais faire de définition de variables dans un .h sinon elle va se retrouver dupliquée dans chacun des .c dans lesquel l'entete a été inclu

ça veut dire que tu dis au compilo qu'il devra chercher la variable dans un autre fichier C
il faut que tu ajoutes char fScreen[LCD_SIZE]; dans ton fichier C (soit dans le corps de main mais attention aux problèmes de visibilité de ton tableau, soit en dehors : attention car ca peut faire grossir ton programe) ou que tu fasses une allocation dynamique avec malloc
je peux expliquer plus en détails si tu veux

pour LCD_Restoe : ouais j'ai mal lu j'ai confondu avec PortRestore désolé

une remarque : pourquoi tu utilises la macro HEROWIDTH et pas Hero.pW ?

bon en fait je sais pas trop d'ou vient ton bug, il faudrait que tu postes un code plus complet

Heu oui en fait fScreen est defini aussi dans main.c

J'ai uploadé le tout a l' addresse suivante: http://membres.lycos.fr/nanarduff/fly2.tar.gz

le fichier app.h a l'air corrompu

et place d'abord le code dans des .c au lieu des .h c'est beaucoup plus propre

voila j' ai re-uploadé les fichiers: http://membres.lycos.fr/nanarduff/fly.tar.gz Mais: pour les .c et .h, il faut donc que je mette "#include "myfile.c" dans main.c ?!

nan

une petite remarque comme ca : c'est Mal de mettre du code dans des .h, il ne sont sencés contyenir que des définitions (prototypes de fonctions ou déclarations de variables ) Mets plutot ton code dans d'autres fichiers .c et tu les compiles ensemble. Ca se fait dans tigcc tres facilement avec "add new c source" (ou un truc dans ce genre)

les fichiers .h ne sont là que pour dire aux autres fichiers .c quelles fonctions seront définies dans d'autres fichiers .c et quel est leur prototype, pareil pour les variables
c'est à ca que sert le mot clef extern
exemple :

---

Mal : du code dans les .h

//main.c
#include "funcs.h"
main() {
int i;
fonction(i);
}

//funcs.h

void fonction(int i) {
...
}

---

Bien : le code dans des fichoers C séparés

//main.c
#include "funcs.h"
main() {
int i;
fonction(i)
}

//funcs.c
#include "funcs.h"
void fonction(int i) {
...
}

//funcs.h

extern void fonction(int i);

le fichier h donne le prototype des fonctions du fichier h associé (en général le .h et le .c ont le même nom)
funcs.h est inclu dans funcs.c comme ca tu peux utiliser les fonctions avant qu'elles soient définies

OK

ca se passe pareil pour les variables que tu veux utiliser en dehors de ton fichier c :

//funcs.h
extern int i;

//funcs.c
#include "funcs.h"
int i,j;

i sera connu en dehors de ton fichier, mais j ne le sera pas.

et si tu définis des variables globales dans ton main.c, tu n'as qu'à creer un main.h que tu incluras dans tes autres fichiers c

Heuh encore un ok trop vite: le linker n' arrive pas à trouver les fonctions definies dans funcs.c dont le prototype se trouve dans funcs.h, ce qui me semble logique ( )puisque que comment funcs.h trouve funcs.c (car funcs.h est inclus dans funcs.c, mais funcs.c n' est pas inclus dans dans main.h, que funcs.h est inclu dans main.h !) ?!

Plutot que de m' egosiller à decrire mes include: http://membres.lycos.fr/nanarduff/fly2.tar.gz

Mais, hum, "revenons a nos moutons": pourquoi ce ***** programme bug svp ?


Merci d'avance

il faut que tu passes les deux fichiers au compilateur :
si tu fais ca en ligne de commande ca sera "tigcc main.c funcs.c" par exemple
avec l'ide tu fais "new c source" et mets ton code dedans ou alors project/add files

et faire des sous dossier pour mettre les entete et un autre pour les fichiers c ne sert à rien

si tu dois faire des sous dossiers c'est plutot pour regrouper des modules, mais c'est utile pour les plus gros projets

et- deplaces tes sprites dans un .c : ce ne sont pas des déclarations mais des données

Ok !
Après avoir passé quelques temps sur ce problème, j'ai enfin reussi a le resoudre. La solution (on sait jamais ); quand j' essayais d' utiliser un caractère à la place d 'une sprite tout allez bien. Et comme la sprite n' utilise que la variable Hero.pW en plus que le caractère et bin ca voulait que j' avais mis l 'emplacement de la sprite à la place de sa hauteur (99)

Merci beaucoup