bon, imagines que le lendemain du release de doom 3 sur TI, tu sois le seul à l'avoir sur ta 92, alors que tout le monde a des 89. Et bien pendant un temps donné, tu pourras pas faire de multiplayer. Et tu pourras avec la compatibilité on-calc.

Lionel Debroux> T'es un extremiste en fait au niveau des programmes sur calculatrices. Ils doivent être forcément petits, rapides, moches (inutile de perdre de la place pour une interface), avoir le moins possible de code de démarrage, être extrêmement chiant à installer et à utiliser et pour finir être obligatoirement programmés en assembleur (langage donnant le code le plus compacte et le plus rapide possible, bien sûr ça dépend de la façon dont on code ).
Bref faire un code identifiant le modèle ne prend pas des kos et des kos et si on fait ça une bonne fois pour toute au démarrage on perd aucune ressource. J'vais encore extrapolé mais c'est comme si tu affirmais qu'il faut un max de ressources même pour un truc qui demande l'attente d'une touche. Ou encore faire obligatoirement des jeux en 8 bits noirs & blanc pour éviter de perdre inutilement des kos pour les sprites... Je me repète mais perso avoir un seul binaire c'est vraiment plus simple pour tout le monde, déjà c'est chiant de mettre à jour un pack lorsqu'on effectue une compilation mais si il faut encore x compilations pour chaques modèles avec x sources... Sérieux on est vite perdu. Certes on est pas sur PC ou là le pb de compatibilité se pose aussi mais on a pas x Go de mémoire. Bref moi se qui me fait marrer c'est genre les mises à jour où le programme a diminué de 40 octets par exemple. Mais bon le débat peut être posé différement, comment est faite la compatibilité entre chaque machine? C'est clair que si c'est codé à l'arrache et qu'on perd des kos et des ressources pour pas grand chose alors là la faute vient du programmeur, maintenant si le programme fait que forcément il est plus judiceux de faire des binaires à part alors oui je suis d'accord avec toi Lionel Debroux mais dans la majorité des cas la compatibilité entre machines peut être assurée on-calc si on y pense au début du programme autrement le résultat est assez désastreux.

#119: le fait soit que ça embête un peu moins les utilisateurs de faire du compatible on-calc, est un des rares, sinon le seul, argument en faveur de la compatibilité on-calc. A part ça, c'est plus gros, plus lent, et il y a un exemple éclatant du fait que l'incompatibilité on-calc n'est absolument pas un problème en termes d'utilisation, voir plus bas.


#120:
> moches (inutile de perdre de la place pour une interface)
Idem: c'est tout Kevin, mais pas moi. Va donc voir TI-Chess et TI-MineSweeper !

> et pour finir être obligatoirement programmés en assembleur
Ben voyons... J'ai réécrit tous les programmes de TICT en assembleur pur, c'est bien connu... Toi-même as fait des programmes bien plus largement écrits en assembleur que ceux dont je m'occuper (et je t'ai aidé à les optimiser).

> Bref faire un code identifiant le modèle ne prend pas des kos et des kos et si on fait ça une bonne fois pour toute au démarrage on perd aucune ressource.
Oh que si. Il faut quand même tester à chaque fois le résultat de ce test et agir en conséquence. C'est d'autant plus inefficace que les actions sont compliquées.
> J'vais encore extrapolé mais c'est comme si tu affirmais qu'il faut un max de ressources même pour un truc qui demande l'attente d'une touche.
En compatibilité on-calc, c'est un fait: "il faut un max de ressources même pour un truc qui demande l'attente d'une touche". Ce sont en effet les tests de touches qui sont les plus inefficaces en compatible on-calc. C'est de là que vient la plus grande partie des au moins 2 KB gagnés par le décochage brutal de tous les modèles sauf 1 dans Ice Hockey 68k, sans aucune autre optimisation sur le code !

> mais si il faut encore x compilations pour chaques modèles avec x sources
Dans l'absolu, c'est plutôt vrai. Cependant, les compilations ne prennent pourtant pas un temps monstre, et on n'est pas obligé de tout recompiler à chaque fois (j'utilise un makefile pour ce sur quoi je suis en train de bosser).
Dans mon cas: j'ai un problème que vous n'avez pas, à savoir que TI-Chess existe en quatre langues, et TICT-Explorer existe en six langues. Comme il est évidemment absolument hors de question de mettre toutes les langues dans le même exécutable, il me faut donc de toute façon faire au minimum quatre/six compilations complètes de l'arbre de fichiers...
Au passage, j'en profite pour rappeler qu'il est stupide de faire deux arbres complets de fichiers différents, l'un pour 89/89T, l'autre pour 92+/V200: c'est surtout une source de bugs... Les différences hors touches (kbd.h, transparent pour le programmeur) se règlent très bien par des #defines dans un fichier inclus par tous: #define ... C89_92(...,...)

> Bref moi se qui me fait marrer c'est genre les mises à jour où le programme a diminué de 40 octets par exemple.
Dans l'absolu, ça peut être risible. En proportion, pas forcément.
Quelle est la taille de la routine de grays de TIGCCLIB ? Moins d'1 KB. 40 octets sont donc plus de 4% en proportion.
FYI, on a eu un exemple de programme sur lequel le passage à GCC 4.0 gagne plus de 2 KB. Il est donc forcément compilé en -Os. L'optimisation à la main, couplée à un passage à des options de compilation optimisées, peut être dévastateur (Ice Hockey 68k, Civ89: plus de 10 KB).

> Mais bon le débat peut être posé différement, comment est faite la compatibilité entre chaque machine?
Mal.
> C'est clair que si c'est codé à l'arrache et qu'on perd des kos et des ressources pour pas grand chose alors là la faute vient du programmeur.
Hmm. En y pensant, je me dis qu'il y aurait peut-être quelque chose à faire - tabuler les valeurs et masques des touches - sur Ice Hockey 68k. C'est une modification très lourde, mais elle permettrait peut-être de gagner encore des centaines d'octets.
>, maintenant si le programme fait que forcément il est plus judiceux de faire des binaires à part
C'est le cas de TI-Chess et TICT-Explorer, pour les raisons sus-mentionnées. J'estime à 8 KB au moins le coût de la compatibilité on-calc pour TI-Chess (fond d'écran: LCD_SIZE; tests de touches de partout). Pourtant, TI-Chess est le programme pour TI-68k le plus téléchargé de tous les temps sur ticalc...

Eh les gars, vous avez lu le titre de ce topic
ça m'étonnerai. ça par en couille là

Si tu en as vraiment marre, en tant qu'auteur du topic, tu peux toujours
de l'off-topic

Il existe aussi des solutions moins violentes.

Ecoute ma remarque est plutôt constructive , tu trouve pas je suppose et pourtant c'est pas sensé être méchant .

comme dit Sasume, il suffit que les gens off-topic arrêtent le off-topic ^^

et l'auteur ne peut plus kicker lui-même
(suite à des abus)
Seul les admins/modérateurs peuvent

Ce que j'ai écrit ne se voulait pas méchant non plus...

> et l'auteur ne peut plus kicker lui-même
> (suite à des abus)
> Seul les admins/modérateurs peuvent
OK.

On le continue où, le off-topic ? J'ai horreur qu'une partie n'ait pas de droit de réponse pour ce type de raisons.

Je prend compte de tes remarques.

Finesse !!

Ma question s'adresse à mes interlocuteurs aussi bien qu'aux modérateurs: si on continue (à voir en privé ?) quelle section est la plus appropriée ?

Algorithmie et optimisation ?

Dans jrad, ça me paraît bien
Si tes interlocuteurs veulent te répondre ils créeront un topic, ok.

Algo et optimisations ne sert pas que pour les Ti, la rubrique "C" peut-être ? (il n'y a pas de "programmation génerale", ça manque peut-être).

Pollux > même comme ça tu peux éviter, thx...

bravoooo tip top ton log bravo bravo bravissimo!!

ronylicha -> dsl mais ca fait un bout de temps que je ne viens plus ici

Tu peux telecharger Ti Graph Link pour essayer d'envoyer le contenu du ZIP.
Si tu as une Ti89

 
tu ne verras directement  pas les fichiers .9XG dans ton explorateur. 
tu devras selection expressement  le Type .9XG pour pouvoir les envoyer a la Ti89 
 
Une autre solution est de renommer les .9XG en .89G ( je ne me rapelle plus exactement l'extension des Groupes de fichier pour Ti89) 

Si ca ne marche recontacte moi ici.


Je vais surement faire une Release de ce programme en Utilisant ma Libraire 'ExtLiB'.
En Effet, j'ai code une nouvelle Version de mon Viewer de Matrix avec ExtLiB

Il faut dire que ce viewer existe deja en version :
- Ti-Basic + Vertel (Version 1)
- C (TIGCC) (Version 2)

...
Comme tu peux le constater sur la capture d'ecran en piece jointe, c'est un peu comme si toutes les colonnes se retrouvaient ecrasées les unes sur les autres sur le coté gauche de l'ecran.

Ma calculatrice est une TI89 (pas la titanium mais celle de couleur plutot bleue avec le contour de l'ecran gris clair. donc ce n'est pas non plus le plus ancien modèle de ti89 qui etait noir)

J'ai pourtant tout fait normalement (ainsi que d'essayer d'autres combinaisons possibles puisque dans ton zip le fichier Vertel.89z est present une fois dans le repertoire gestion mais une autre fois aussi dans le repertoire viewer)

...

 
-> tual.alban 
il faudrait voir quel est la version de Hardware et de ton AMS. 
un screenshot de ton menu About  [HOME]+[F1]+[A]  serait bienvenu 

2 solutions a ton probleme :
- soit mon programme Basic 'Viewer' est buggue
- soit Vertel contient un Bug

Si c'est mon programme Basic 'Viewer', c'est peut-etre au niveau de la Liste retourne par la fonction 'getConfg()' , car je m'en sert pour definir le type de calculatrice.

Je vais essayer de voir si je ne peux pas sortir la release avec mon viewer C.

Tres bien ce programme bravo ! Il est beaucoup plus pratique que TI-finance et possede beaucoup plus de possibilités (notamment les tableaux d'amortissement tout fait). Je ferais juste une petite critique concernant les criteres de choix d'investissment, il manque le cout annuel equivalent ou annuité équivalente je rappel la formule :
AE=VAN*t/(1-(1+t)^-n)

Voili voilou

ok merci ! je vais voir si y a la place pour rajouter ca dans la boite de Dialogue.

Si y a des truc qui cloche vous gener pas pour les reporter. je vais sortir une version la semaine prochaine
n'utilisant plus vertel. Ce sera avec mon viewer C.

je n arrive PaS A trouves des programmes de comptabilite gestion pour la ti 92 est ce que kelkun peut m aider ????

1°) C'est pas le bon topic.
2°) A priori, le programme proposé par l'auteur du topic que tu squattes devrait être compatible pour la Ti-92.

avec ma V200 quand jutilise un programme il est ecrit variable indefinie que dois je faire merci

Interessant. Andoh_wilfried apprécie ta contribution dans son topic.

attention les tableau d'amortissement d'immob en dégressif semblent erronés (je pense a un probleme dans les coeff :
Duree|Coeff
3-4an|1.25
5-6an|1.75
> 6an|2.25
ex : si je met dans ton prog un amort. de 400000 sur 5ans, il me trouve un tx dégressif de 40%
or il est de 35% (1/5 * 1.75)

edit : c'est bon jai modifier les coeff dans ton prog et tout marche

Tiens, moi qui croyais avoir fait une mise a jour pour regler ce petit probleme.
Faut croire que j'ai pas remplacer le Zip.

J'ai fait une fonction global pour determiner le coef degressif, comme cela tout le monde pourra modifier cela a sa guise.

J'ai aussi prevu de sortir mon autre petit programme qui presente la modelisation des flux de tresorerie d'un projet d'investissement. C'est sense calculer permettre de calculer la le RCAI, RN VAN, et d'autres truc.

Le probleme c'est que y a un crash de Vertel quelque part entre les fonctions "list" et "delt".
Je vais essayer de contacter Vertyos pour voir.

Je vais aussi voir si je peux sortir une Version Stable de mon Editeur de Matrix.

slt les gars,

je prepare le decf avec l'intec et j ai 1 ti 89 depuis peu et je suis dans la merde car je ne sais pas comment faire pr utiliser ce prog gestion
qq un peu m'aider svp

taco

il y a un read-me dans le zip qui explique quelle programme utilser.
Je vais surement rajouter un menu pour choisir l'un des programme a lancer vu que
la frequence de ce genre de question.

j ai besoin du logiciel qui permet d envoyer les programmes du PC vers la TI j ai pa trouve

ok

j'ai remis en ligne la version C de MatView.