Librairie dynamique - Page 5

Et trois en après, le bugfix est backporté dans upstream, et on peut enfin avoir des macros correctes ?

Bon, ya un truc que je capte vraiment pas :

Quand je fais ça :
truc = (peek_bit (Ptr[offset] , 7));
Ca me renvoie toujours truc == 0
Quand je fais ça :
truc = Ptr[offset];
Ca me renvoie 0 ou 0x80, suivant cas.

Sachant que Ptr est un char*, qui pointe dans un tableau fait de 0x80 et de 0x00.

Kékya qui va pas ?

peek_bit prend une adresse, pas une valeur. Essaie:
truc = (peek_bit (&Ptr[offset] , 7));
ou (ce qui revient au même):
truc = (peek_bit (Ptr + offset , 7));

han J'arrête tout, je repasse au TI-Basic

Merci ^^

De toutes façons pourquoi utiliser peekbit quand tu peux faire le joli masque & toi-même ?

Lire un bit est plus rapide que copier un char ? Faut que je vérifie ce que ça donne.
Je me demande pourquoi ce genre de macro n'est pas faite en asm

Le compilateur optimise ça en un btst normalement.

Très bien.

Etant donné qu'on m'a toujours aps rendu mon bouquin de C, je me pose une question sur ce qu'on pourrait appeler les priorités :
Avec un tel code :

			if (CharX % 16 <= 8)
			{
				if (peek_bit (TilesDataPtr + Block , CAN_CROSS))
					SpeedY = -140;
			}
			else if (peek_bit (TilesDataPtr + Block , CAN_CROSS) || peek_bit (TilesDataPtr + Block + 2 , CAN_CROSS))
				SpeedY = -140;

La paire d'accolade est-elle indidpensable ? ie est-ce que le else serait appliqué au premier ou au second if sans ça ? Est-ce défini ?

(et me parlez pas de l'optimisation du code, je viens de me rendre compte que c'est très simplifiable, mais là n'est pas la question )

Oui les accolades sont nécessaires

Il vaut beaucoup mieux un excès de parenthèses qu'un défaut de parenthèses. De plus, même si ça ne s'applique pas ici, il me semble qu'il y a de légères différences de priorités entre certains dialectes de C.
=> c'est très mal d'avoir un code dépendant de la priorité des opérateurs

On parlait d'accolades et pas de parenthèses
En plus le if n'est pas un opérateur mais une structure de contrôle, pas pareil
(Enfin c'est surtout que du coup y'a pas d'histoires de priorité ou autres)

Folco (./129) :
La paire d'accolade est-elle indidpensable ? ie est-ce que le else serait appliqué au premier ou au second if sans ça ? Est-ce défini ?

Oui, le comportement est défini (et heureusement, sinon la grammaire serait ambigüe) : un else se rapporte toujours au dernier if déclaré pour lequel il n’y a pas encore de else. Donc les accolades sont bien nécessaires

Ok, merci.

Autre truc, pour pouvoir optimiser : Est-ce que les évaluations des &&/|| sont paresseuses, et effectuées dans l'ordre du source ? Si c'est le cas, il y a pas mal à optimiser en organisant correctement les booléens.

En C, les évaluations sont paresseuses

Yep ! Merci.

Ya un moyen pour compiler un fichier de données en C ? Je vois pas comment m'y prendre... Je n'ai rien trouvé dans la doc à ce sujet, bien que je croyais qu'il en était question qqpart

C'est quoi un fichier de données pour toi ?

Oui, tu veux compiler quoi au juste ?

Un .incbin ?

Un fichier qui aura une extension OTH et qui contiendra que des données, pas le moindre code.

ttbin2oth.exe ou un truc du genre ? (tu veux un fichier externe ou l'inclure dans le programme ?)

Je ne sais pas si à partir d’un fichier .o obtenu à partir d’un .c on peut utiliser ces trucs là.

Pkoi tu parles d'un fichier .o ? J'avoue que j'ai du mal à comprendre ce qu'il veut vraiment

Je crois qu’il veut définir des données en C et pouvoir en faire un fichier TI.
Quand on compile du C, on obtient un fichier objet (.o). Donc il faudrait pouvoir transformer ce fichier .o en un fichier TI.

Si c'est ça, à mon avis¹, il a plus vite fait de coder un programme PC qui écrit le binaire sur lequel il ferait tourner ttbin2oth (oui non mais je sais qu'on obtient un fichier objet, quand même )

¹ mais mon avis ne vaut à peu près rien, ça fait un moment que j'ai arrêté de regarder ce qui se fait du côté des TI

Oui je pense pareil, un programme PC qui dumpe les données dans un fichier PC, et ensuite une conversion en fichier TI avec les outils ttmachin...
edit : en fait j'ai eu à faire un truc similaire, le plus simple pour le faire en une étape est plutôt de récupérer bin2oth.c dans les tt tools et d'utiliser la fonction y définie DataBuffer2OTHBuffer ^^

(mon avis vaut peut être quelque chose alors ? )

Autrement dit, si tes données sont dans data.h, tu te fais un petit datadump.c qui contient ceci :

#include "data.h"
extern unsigned char* DataBuffer2OTHBuffer(int            calctype,
					   char*          folder,
					   char*          varname,
					   char*          extension,
					   unsigned int   inlength,
					   unsigned char* indata,
					   unsigned int*  outlength);

plus un main (attention, pas un _main) qui passe ton tableau de données en argument à cette fonction et dumpe le résultat dans un fichier, et hop. Ensuite tu n'as plus qu'à compiler séparément bin2oth.c et linker ton datadump.o avec le bin2oth.o ainsi obtenu, tu lances le programme et il te générera le fichier.
(N.B. compiler avec gcc, pas avec tigcc )

Sinon, il y a aussi le hack qui se nomme ttextract. Mais un compilateur C est vraiment le mauvais outil pour générer un pur fichier de données, la méthode du programme qui écrit les données est bien plus propre.