D'autres questions... - Page 1

Bon ya pas d'raisons que naPO ai son topic de questions d'noob en C et pas moi
Alors voilà, c'est chose faite j'en ouvre un ^^

Bon on va démarrer cool avec une egnime sur laquelle je planche depuis un petit moment #magic_feignantiz_toussa#

Mon probleme est simple, j'travaille avec des "fenetres" dans mon programme et en niveaux de gris. Donc quand j'ouvre une fenetre,
je sauve tout skia dessous, j'ecrit, puis a un moment j'efface cette fenetre en remettant le sprite d'origine et je fini par libérer le bloc.
Et ce qui me pose probleme c'est la sauvegarde du sprite.
Dans la doc d'extgraph j'ai trouvé ca :
void SpriteX8Get(short x,short y,short h,void* src,unsigned char* dest,short bytewidth) __attribute__((__stkparm__));
J'arrive a l'utiliser +/- bien mais a chaque fois j'ai un crash de la calc :/

Ca m'etonne pas trop puisque j'arrive pas vraiment a savoir a quoi correspondent h et bytewidth.
h = la hauteur du sprite en pixels ? octets ? multiple de 8 ?
bytewidth = ??? multiple de 8 ?

Bref si kkun l'a deja utilisée j'apprecierai son aide

Oui cette fonction permet de sauver une image dont la hauteur est h et la largeur bytewidth*8

Donc si tu veux sauvergarder l'écran tu fera :

void SpriteX8Get(0, 0 , 128, LCD_MEM, buffer ,240/8) ;

[cross ]
y a aucune raison de penser que h devrait être multiple de qqch, par contre en principe bytewidth = largeur en octets = largeur en pixels / 8 ^^

Ah Oki merci
Donc c'est bien ce que je faisait au début mais ca buggais encore +
J'regarderai ca avant ce soir et si j'ai encore un probleme je m'en remettrai a vous

Une petite précision qui me viens là :
pour un seul plan, il me faut bien faire une alloc de sizeof(((h/8+1)*bytewidth)*(char )) non ?

NAN pourquoi tu divise h par 8 ! L'alloc est de h*bytewidth tout simplement !

heu...
Si je multiplie des pixels avec des octets ya y avoir un probleme nan ? xD
[Apres réflexion ...]
Ptin chui une vraie quenelle
Merci Thor ^^

Oui tu as raison fais une analyse dimensionnelle

Mais le mieux c'est de te rapeller que 3840 = 128*240/8; Une ligne etant composée de 240 pixels elle utilise donc 240<<3 octets pour être codée or dans l'écran il y a 128 lignes donc ... tu connais la suite ... Bon courage pour ta fonction. A mon avis si ça foire c'est un problème de sortir d'écran car si je me rapelle bien cette fonction de sauvegarede de zone de l'écran n'est pas clippée.

Nan mais effectivement j'ai percuté ca tàl : "[Apres réflexion ...] "
Ce qui est sûr c'est que je ferai plus l'erreur ^^
J'vois toutes ces fonctions d'un autre angle maintenant Encore merci

Ajout> Et du coup le crash est dû à un dépassement de buffer dans la heap ^^

Je m'en doutais

De rien pour l'aide ...je suis passé par là également

^^

Bon j'viens de voir autre chose :

Alors, comme j'utilise les grays, j'ai pensé sauver mes deux plans avec 2 SpriteX8Get successifs, l'un pour DARK_PLANE et l'autre pour LIGHT_PLANE.
Ensuite pour les restaurer, j'efface l'emplacement du sprite et j'utilise 2 SpriteX8_OR successifs pour chacun des deux plans aussi.

Seulement j'ai un bug, et dans la doc d'extgraph je viens de voir qu'il y a une fonction :
void GraySpriteX8_OR(short x,short y,short h,unsigned char* sprite1,unsigned char* sprite2,short bytewidth,void* dest1,void* dest2);

Donc evidement j'ai cherché une fonction "GraySpriteX8Get" et j'ai pas trouvé.

Alors est-ce que mes bugs (graphiques) ne viendraient pas de là aussi ?
Mais j'ai comme un doute, puisque il serait logique que "la-dite" fonction fonctionne comme je procede.
Ou alors, est-il posible que lors des "Get", certaines parties des plans ne soient pas encore remplis et que du coup je copie n'importe quoi ?

Enfin bref je fait peut-etre fausse route alors merci de votre aide et de vos eclaircissements


------------------------------------------
Une autre question qui as rien avoir :

Admettons que j'ai un source en asm pur, je fait comment pour appeller une fonction en C sans passer par un appel asm ?

- a priori étant donné que les sprites sont stockés sur deux plans indépendants j'aurais tendance à penser que GraySpriteX8 c'est la même chose que SpriteX8 appliqué à chacun des plans (en un peu plus rapide)

- ça peut être intéressant si tu n'as pas bcp de sprites qui bougent d'effacer et de redessiner (encore que, dans la mesure où tu n'as pas bcp de sprites, ça ne changera rien au framerate de prendre une solution presque optimale ou une solution moins optimale), mais dès que tu commences à avoir un peu bcp de sprites, c'est plus efficace de tout effacer et tout redessiner (en faisant du double buffering pour que ça ne clignote pas)

- il suffit que tu fasses un prototype en C :

asm {
MaFonction:
  mulu d0,d0
  rts
};
int MaFonction(int x);

• Dude se gratte la tete et parait perplexe


Bon je crois que sur un point on est d'accord
1/ A savoir que 2 SpriteX8_OR successifs peuvent etre "optimisés" en un seul GraySpriteX8_OR ^^

Par contre je sais pas si on s'est bien compris pour le reste
[...]
Ah si!
1+2/ Apres rererelecture tu m'as répondu aussi pour les SpriteX8Get...alors j'ai rien dit

Bon par contre pour le troisieme point, je crois que ce que tu me dit c'est l'inverse de ce que je voudrai ^^
3/ En fait, j'ai 2 sources, l'une en C et l'autre en ASM. Et je voudrai appeler une fonction C de l'interieur de mon source ASM
Est-ce possible ? si oui comment ?


Ah encore un truc, pour ca ? : "Ou alors, est-il posible que lors des "Get", certaines parties des plans ne soient pas encore remplis et que du coup je copie n'importe quoi ?"
A priori devrai y avoir aucun probleme puisque je fait pas de double buffering mais je voudrai en etre certain

Est-ce possible ? si oui comment ?

Ah ben là y a encore moins à faire ^^ si par exemple tu utilises la convention regparm,

int square(int x) { return x*x; }

asm {
blabla:
  move.w param(pc),d0
  bsr square
  move.w d0,resultat
  rts
};

^^

mais LOL xD
C'est bien un truc pour moi ca ^^ #purtrucdefeignasse#
Moults merci's Pollux Ca va bien m'aider

Pollux :
- il suffit que tu fasses un prototype en C :

asm {
MaFonction:
  mulu d0,d0
  rts
};
int MaFonction(int x);

Il faut quand même préciser à TIGCC où sont les paramètres (ici, dans d0).

Bah non, pas si tu utilises la convention d'appel regparm...

et c'est fiable, regparam ? je me souviens d'avoir eu qq plantages suivant le nbr de registres que je précisais, pas moyen de passer tous les arguments par registres dans certains cas ^^

Jamais eu de problèmes avec perso.

Moi non plus.

Pollux> Ce que je voulais dire c'est qu'il faut le préciser qqpart, parce que par défaut tigcc utilise stkparm comme convention.

C'est quoi la différence de ces deux conventions ?
Parce que c'est pas la premiere fois que j'en entend parler ou meme que je les croise ^^

stkparm : les parametres sont empilé avant l'appel de la fonction
regparm : les parametres sont passés dans les registres

ahhhhhhhhhhhhhhhhhh encore un truc de feignasse

C'est surtout que les appels sont plus rapides et prennent moins de place.

J'imagine que tu parle de regparm là ?
Tiens ben tant qu'a faire une autre question en rapport :
Me suis toujours demandé si "la pile" etait une puce à part ou si c'etait tout betement de la ram ? (j'ai mon avis mais je veux en etre sûr ^^ En ram non ?)

Edit> Hum question bete ca n'as aucun sens si c'est une puce a part ^^

Ca aurait très bien pu être une puce de ram séparée, ou de la mémoire interne du microcontrôleur sur hw1, ou... etc.
Bref c'est en ram

C'est le micro controleur qui "décide" où est la mémoire, et c'est transparent vis à vis de l'adressage mémoire, donc la mémoire peut être un peu partout. C'est bien ça ?
(j' essaye de me rappeler mes cours d'archi ^^)

Ah Le fameux mappage