30

Je fais un essai en kernel, de toute façon, si cela ne me convient vraiment pas par la suite, je suis toujours a temps de le passer en statique et NoStub
http://membres.lycos.fr/pingooz/
Un cafe et deux sucres

31

Ba PiNGoO > ta lib regrouperait quoi exactement ?

Le mieux serait de faire un peu comme fer3C smile tu met tout se qui est important au moteur dans la lib et les jeux sont des "fichiers externe mais executable"
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

32

KK: c'est pas parce qeu t'aime pas que c'est n'importe quoi, t'as vraiment des problemeS...

33

Ben la lib regrouperait plein de fonctions utiles au moteur du jeu (mais pas tout le moteur) avec beaucoups de sprites de base et surtout toutes les fonctions qui vont êtres utilies pour les scriptes du jeu (qui rique d'êrte utilisés par un ou deux autres executables)
http://membres.lycos.fr/pingooz/
Un cafe et deux sucres

34

ecoute pas Kevin et fait ce que tu penses bon de faire..

35

GoldenCrystal
: Sois plus clair alors parce que "C'est un mauvais choix" ce n'est pas vraiment un avis...
Il a donné son explication juste après.
Et je trouve qu'il a raison.
Tout dépend de ce que veut faire PiNGoO...
avatar
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

36

J'ai pas dit qu'il avait tort, mais je dis juste qu'on ne donne pas un avis de cette façon.
EDIT: j'arrive pas bien à expliquer ce genre de choses alors si vous comprenez pas, oubliez ce que j'ai dit smile
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

37

Il a donné son explication juste après.
Et je trouve qu'il a raison. Tout dépend de ce que veut faire PiNGoO...

Et alors ce topic n'est pas un debat oui j'aime ca..
KK a la facheuse tendance d'obliger les autres a utiliser ses methodes, alors qu'il en existe bien d'autre, et a ce que je sache niveau prog on calc c'est pas la reference!

maintenant on s'en fou de ce que tout le monde pense.. soit c'est un conseil soit ca sert a rien d'en parler donc out!

38

Bah... si tu compte de toute façons utiliser la même lib pour tous tes programmes, autant le faire en dynamique. Au pire, sur la taille exclusive de ton programme, tu perd rien. Au mieux, tu y gagne puisque les fonctions de la lib ne sont pas recopier n fois dasn tes programmes.
avatar
Membre fondateur de la Ligue Anti-MacIntoc
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Un expert est quelqu'un qui en sait de plus en plus sur de moins en moins
de choses, jusqu'à ce qu'il connaisse absolument tout à propos de rien.

39

Le probleme est que Tigcc n'aime pas les libs dynamiques.
Donc pour faire ce que tu souhaites (sprite16(...., GetPlane(0)), deux solutions.
1. La plus simple: tu laisses tomber GrayOn, et tu utilises kernel.h et graphlib__Gray4On() (regarde dans kernel.h pour le nom exact).
Au lieu de GetPlane(0), GetPlane(1) tu utilises les equivalents graphlib__plane0 (j'ai encore oublie les noms).
C'est le plus simple,et ca fonctionnera parfaitement.
2. Plus complique: tu patches gray.s de tigcc pour qu'il exporte les addresses des plans.
(rajouter avant l'adresse du plan un projectname__0000 et projectname__0001 et faire les xdef correspondant, inclure gray.s dans le projet directement).
Puis ;odifier gray.h, et plus pariticulierement GetPlane pour qu'il utilise projectname__0000 et projectname__0001 au lieu des variables sus-cites.
En gros tu changes les noms des adresses des plans

Je conseille la solution 1.

40

Plus complique: tu patches gray.s de tigcc pour qu'il exporte les addresses des plans

ya pas besoin de patch il me semble.. au pire 2 externs

41

mais si la routine de gray est dans la lib, je vois pas le prob..

42

Ben si il pourra pas y acceder depuis le programme proncipal. Un extern est pas suffisant. Il faut renommer les noms.

43

je crois que je vais suivre ton conseil et utiliser les fonctions de graphlib ...etc
http://membres.lycos.fr/pingooz/
Un cafe et deux sucres

44

c'est vrai qu'en kernel il est plus logique d'utiliser graphlib tongue

45

kler ... surtout que ca marche bien, mm si ca fait des années que je l'ai pas utilisé grin (à l'époque, je programmais pas avec tigcc wink ct kitch )

46

y a d'autres lib kernel pour les 4nvg qui sont moins vielles ??? ça me derarnge pas d'utiliser graphlib, mais si il y a plus recent, je suis pour aussi smile
http://membres.lycos.fr/pingooz/
Un cafe et deux sucres

47

Non. On evite de sortir de nouvelles libraries lorsque c'est pas necessaire en general.

48

ben, comme il y a gray4, et graphlib qui font la même chose, je me suis dit ...
http://membres.lycos.fr/pingooz/
Un cafe et deux sucres

49

gray4lib est juste un wrapper appelant graphlib.

50

ah embarrassed, ok, je savais pas desolé
http://membres.lycos.fr/pingooz/
Un cafe et deux sucres

51

C'est pour des raisons historiques: gray4lib est la librairie de Fargo et de PlusShell, graphlib celle de DoorsOS. Les kernels récents évitent de dupliquer le travail et font de gray4lib un simple wrapper.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

52

Quant à:
PpHd
: Le probleme est que Tigcc n'aime pas les libs dynamiques.

ce n'est pas un problème spécifique à TIGCC. Le mélange de linkage statique et dynamique pose toujours ce genre de problèmes, quelle que soit la plateforme. La solution est de tout linker en statique (ou tout en dynamique, ce qui est la solution 1 de PpHd).
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

53

Attention, je ne sais pas si la TIGCC Team autorisera à utiliser graphlib, puisque c'est incompatible avec PlusShell... A mon avis tu vas être obligé d'utiliser gray4lib gni

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

54

Je déconseille l'utilisation de toute routine de niveaux de gris autre que GrayOn.

kernel.h est d'ailleurs un header non officiel, dont je déconseille l'utilisation pour les raisons suivantes:

1.
#undef	NO_AMS_CHECK				// Useless in Kernel mode (Kernel does the job for you).
#undef	NO_CALC_DETECT				// Useless in Kernel mode (Kernel does the job for you).
[...]
#define	NO_AMS_CHECK
#define	NO_CALC_DETECT

(i) Ce n'est pas le problème de kernel.h, mais du programmeur.
(ii) L'usage de NO_AMS_CHECK et NO_CALC_DETECT est fortement déconseillé sauf pour les cas bien particuliers (partie résidente d'un TSR, quand le programme d'installation a déjà effectué ces vérifications; si c'est la seule manière de rester en dessous d'une limite de taille; ...).
(iii) Le commentaire "Useless in Kernel mode (Kernel does the job for you)." est faux. PreOs n'est pas le seul kernel au monde. Ces tests sont nécessaires pour TeOS, par exemple.

2.
#undef USE_INTERNAL_FLINE_EMULATOR // Useless with Preos
Ça aussi, ce n'est pas le problème de kernel.h. Un header n'a pas à se mêler de ce genre de trucs.

3.
#undef	RETURN_VALUE				// Change the way of working
[...]
#define	RETURN_VALUE	((unsigned char *) *_RAM_CALL_F = (unsigned char *) *_ROM_CALL_109)

Et ça aussi, c'est carrément abusé. kernel.h n'a pas à modifier les #defines documentés de TIGCCLIB.

4.
// You can't no select Exit support 
#undef	_main
#define _main volatile __main__(); \
	asm(	".xdef	_main\n" \
		"	.xdef	__save__sp__\n" \
		"__save__sp__:\n" \
		"	.long 0\n" \
		"_main:	lea __save__sp__(%pc),%a0\n" \
		"	move.l %a7,(%a0)\n" \
		"	jbra	___main\n"); \
	 void ___main

Ceci est un hack totalement inutile qui n'a rien à faire dans kernel.h et qui est incompatible avec TIGCC 0.95.

Je précise que j'ai reporté tout ça à PpHd et qu'il a refusé de le changer.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

55

1. C'est un très mauvais prétexte, et c'est ce prétexte-là que critiquait ./53. On peut très bien vouloir faire un prog compatible seulement avec PreOS. (cela dit, si effectivement ça fait crasher TeOS, c pas cool => il faut un moyen de faire un prog kernel "nouvelle génération seulement")

2. Hum. C'est compréhensible, mais c'est discutable.

3. Tiens c'est incompatible avec GTC ça il me semble. Il vaudrait mieux faire *(unsigned char **)_RAM_CALL_F. Heu je ne vois pas pkoi c interdit si c propre? (je ne sais pas comment ça se passe pour RETURN_VALUE en kernel)

4. Euh oui, #undef NO_EXIT_SUPPORT serait plus utile...

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

56

Il a sûrement des raisons aussi valables que les tiennes roll
avatar
Un site complet sur lequel vous trouverez des programmes et des jeux pour votre calculatrice TI 89 / Titanium / 92+ / Voyage 200 : www.ti-fr.com.
Quelques idées personnelles ici.

57

Si vous etes pas content, vous l'utilisez pas, puis c'est tout.
Ensuite, TeOs est ultra buggue, donc c'est pas la peine de s'en faire pour lui.
Et vous pouvez toujours faire votre propre version a vous. D'ailleurs je le recommande.

58

Pollux :
1. C'est un très mauvais prétexte, et c'est ce prétexte-là que critiquait ./53. On peut très bien vouloir faire un prog compatible seulement avec PreOS. (cela dit, si effectivement ça fait crasher TeOS, c pas cool => il faut un moyen de faire un prog kernel "nouvelle génération seulement")

#define USE_PREOS_COMPRESSED_TABLES smile
Le nouveau stub teste automatiquement si le kernel est suffisamment récent, et puis la signature change aussi.
3. Tiens c'est incompatible avec GTC ça il me semble. Il vaudrait mieux faire *(unsigned char **)_RAM_CALL_F. Heu je ne vois pas pkoi c interdit si c propre? (je ne sais pas comment ça se passe pour RETURN_VALUE en kernel)

Ce n'est pas une bonne idée parce que le RETURN_VALUE de TIGCCLIB fonctionne très bien en mode kernel et qu'il n'y a donc pas de raison de le détruire. Il devrait appeler sa macro RETURN_VALUE_NOW et ne pas toucher à RETURN_VALUE.
4. Euh oui, #undef NO_EXIT_SUPPORT serait plus utile...

Ça aussi, ce n'est pas le problème du header, NO_EXIT_SUPPORT marche très bien en mode kernel. (D'ailleurs, TIGCC 0.95 détectera automatiquement si le support pour exit est nécessaire ou pas et ignorera totalement NO_EXIT_SUPPORT.)
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité