Forum de Ti-Gen.org, le site francophone des TI

Bienvenue Invité ! Se connecter Mes sujets	Administrer
Utilisateurs actifs : Aucun membre + 1 visiteur

Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.

:: Index » Forum Ti68K » Programmation C » GrayClipSpriteX8_OR ? (39 réponse(s))

./POST DE DEPART (post n°0) Marquer comme non lu.

Invité

Ecrit le: Mercredi 30 mars 2005 à 16:38

Est-ce qu'il y a une fonction GrayClipSpriteX8_OR quelque part ou une fonction équivalente ?

./Post n°1 Marquer comme non lu.

Jfg

Ecrit le: Mercredi 30 mars 2005 à 19:12

Administrateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 1260

Membre n°60

Inscrit le 23 février 2004

Citation venant du header d'extgraph:

// MastaZog asked for GrayClipSpriteX8_X_R routines. They will be written, although
// their priority is rather low.

Kill Mario

./Post n°2 Marquer comme non lu.

geogeo

Ecrit le: Mercredi 30 mars 2005 à 19:21

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4256

Membre n°3

Inscrit le 29 janvier 2004

Y en a une dans GFA Basic, voir Put! Codé par moi et pas testée à fond! Mais tu dvera faire quelques modifications!

-Edité le Mercredi 30 mars 2005 à 19:22 par geogeo-

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°3 Marquer comme non lu.

Invité

Ecrit le: Mercredi 30 mars 2005 à 20:48

JfG > Ah merci. J'ai encore raté quelque chose... #roll#

geogeo > Ok je vais voir.

./Post n°4 Marquer comme non lu.

Sasume

Ecrit le: Mercredi 30 mars 2005 à 22:36

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Sinon, il y a BitmapPut...

./Post n°5 Marquer comme non lu.

Folco

Ecrit le: Mercredi 30 mars 2005 à 23:19

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

(et ses bugs)

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°6 Marquer comme non lu.

Sasume

Ecrit le: Jeudi 31 mars 2005 à 09:50

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Sinon, genlib propose des fonctions équivalentes.

./Post n°7 Marquer comme non lu.

Invité

Ecrit le: Lundi 4 avril 2005 à 19:29

J'attends qu'elles soient écrites dans ExtGraph.

C'est pas urgent.

./Post n°8 Marquer comme non lu.

Lionel Debroux

Ecrit le: Mardi 5 avril 2005 à 14:26

Envoyer un message privé à Lionel Debroux

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Il vaudrait mieux utiliser ce qui est dans GFA-Basic, et ne pas attendre qu'elle soit dans ExtGraph...
Dans sa dernière version, genlib n'existe plus en natif...

Lionel Debroux - membre de TICT.

./Post n°9 Marquer comme non lu.

Jfg

Ecrit le: Mardi 5 avril 2005 à 17:21

Administrateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 1260

Membre n°60

Inscrit le 23 février 2004

"Dans sa dernière version, genlib n'existe plus en natif... "
ça veut dire quoi ?

Kill Mario

./Post n°10 Marquer comme non lu.

Sasume

Ecrit le: Mardi 5 avril 2005 à 17:40

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Qu'il faut un kernel pour l'utiliser. Est-ce vraiment un problème ?

./Post n°11 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mardi 5 avril 2005 à 18:28

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Oui, mais de toute façon, genlib "nostub" n'était pas vraiment _nostub non plus.

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!

./Post n°12 Marquer comme non lu.

Lionel Debroux

Ecrit le: Mardi 5 avril 2005 à 18:38

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

#10: pour la majorité des utilisateurs (et une majorité bien plus large de programmeurs), oui.

Lionel Debroux - membre de TICT.

./Post n°13 Marquer comme non lu.

Folco

Ecrit le: Mercredi 6 avril 2005 à 11:33

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

nan mais ça va??? il est plus simple d'installer preos ou de passer tous ses progs à ghostbuster?? et Lionel, t'es à côté de tes pompes quand tu parles de programmeurs gênés par le kernel... et pour commencer, si déjà le nostub de tigcc était du vrai natif... mais c'est pas le cas hein :/

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°14 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mercredi 6 avril 2005 à 15:27

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Martial Demolins :
nan mais ça va??? il est plus simple d'installer preos ou de passer tous ses progs à ghostbuster??

Les programmes compilés avec un ancien TIGCC, il faut de toute façon les passer sous GhostBuster parce que l'autopatcheur de PreOs ne peut pas les patcher complètement (PpHd prétend que les programmes kernel utilisant TIGCCLIB n'existent pas). Les programmes compilés avec un TIGCC récent, ben ils marchent sur la Titanium tel quel.

et Lionel, t'es à côté de tes pompes quand tu parles de programmeurs gênés par le kernel...

Non, c'est toi qui ne sais pas de quoi tu parles.

et pour commencer, si déjà le nostub de tigcc était du vrai natif... mais c'est pas le cas hein :/

Si.

Martial, j'en ai marre de tes trolls stupides et infondés.

./Post n°15 Marquer comme non lu.

Folco

Ecrit le: Mercredi 6 avril 2005 à 21:24

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

>>Martial, j'en ai marre de tes trolls stupides et infondés.
donnes-moi une indication alors, comment se-fait-il qu'un prog vide (rts) en nostub fasse 85 octets?

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°16 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mercredi 6 avril 2005 à 22:38

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

En assembleur ou en C?

En assembleur, il n'y a strictement aucun code de démarrage qui est rajouté, tu es en train de compter le header TI-GraphLink!

En C, c'est que tu choisis les mauvaises options. Les options par défaut sont optimisées pour des programmes plus grand qu'un simple rts: sur ces programmes, elles économisent de la place, sur un rts, elles sont effectivement contreproductives.

#define NO_CALC_DETECT
#include <tigcclib.h>
void _main(void)
{
}

avec les règlages de l'IDE étant (comme les donne tprbuilder):
-DUSE_TI89 -DUSE_TI92PLUS -DUSE_V200 -DMIN_AMS=100 -DUNOFFICIAL_OS_SUPPORT -DKERNEL_FORMAT_BSS -DKERNEL_FORMAT_DATA_VAR
donne un exécutable de 7 octets (00 05 4e 75 00 00 f3, on ne peut pas faire plus petit!).

./Post n°17 Marquer comme non lu.

Folco

Ecrit le: Mercredi 6 avril 2005 à 22:42

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

et le NO_CALC_DETECT donnera quoi en asm 68k?

edit-> même pas capable de recopier une instruction xD
-Edité le Mercredi 6 avril 2005 à 22:48 par Martial Demolins-

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°18 Marquer comme non lu.

Sasume

Ecrit le: Jeudi 7 avril 2005 à 08:31

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

./16> C'est ce qu'on dit. Il y a un petit stub de démarrage qui permet d'alléger ensuite le programme. En gros tu refais une partie du boulot du kernel (détection de calcs, ...) dans chaque prog. Le but du Kernel est simplement d'avoir ce code une seule fois sur la calc plutôt que dans chaque programme.

./Post n°19 Marquer comme non lu.

Lionel Debroux

Ecrit le: Jeudi 7 avril 2005 à 08:44

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Sasume, on a déjà parlé de ça dans une autre section de ce même forum.
Pour rappel: le FAIT est que le kernel + stdlib est lui-même un stub de 30 KB, qui bouffe de plus plusieurs KB de RAM. Aucun paquet de stubs de démarrage, sur virtuellement aucune calculatrice (gros stub <-> gros programme <-> peu de tels programmes sur une même calculatrice, en général) n'arrive à prendre une place pareille.

La bonne solution pour la détection de calcs n'est même pas le mode kernel (en plus du stub susmentionné, les RAM_CALLs nécessitent des relocations qui prennent de la place, ET des références xxx.l; c'est à dire, environ huit octets par référence - ça va bien pour le gain de place...), c'est l'incompatibilité on-calc.
Elle donne toujours du code plus petit et plus rapide. Les résultats peuvent être dévastateurs (sans rien faire, encore ~3 KB supplémentaires, en plus des ~15 déjà gagnés sur Ice Hockey 68k).

Lionel Debroux - membre de TICT.