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 » Programmes et tests... » Beta-tests de programmes de TICT... (117 réponse(s))

./REPRISE DU POST PRECEDENT (post n°38) Marquer comme non lu.

geogeo

Ecrit le: Jeudi 23 juin 2005 à 20:54

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4256

Membre n°3

Inscrit le 29 janvier 2004

Dommage que la qualité des niveaux de gris n'ait pas été améliorée. Mais bon à part ça si elle est plus petit alors autant la prendre!

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°39 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 23 juin 2005 à 21:04

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Sasume :
Au fait, Kevin, tu n'as pas répondu à mes mini-messages concernant Grib : est-ce que le modèle que j'utilise pour gérer le double-buffering te plaît ?

Non.

Est-ce que tu es toujours contre remplacer gray.s par grib ?

Tu veux carrément que je remplace gray.s??? Dis-donc, t'es gonflé... La compatibilité antérieure, ça ne te dit rien? (grib est totalement incompatible avec les routines de gris actuelles.) C'est hors de question!
-Edité le Jeudi 23 juin 2005 à 21:04 par Kevin Kofler-

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°40 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 23 juin 2005 à 21:09

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

LionelA :
donc il y a une API differente, ca n'aurait pas été mieux de garder exactement la même (comme ca la conversion de programmes existant serait instantanée) ?

Et surtout, si tu veux remplacer la routine de TIGCCLIB, il n'y a pas de choix, faut une API 100% compatible.

geogeo :
Dommage que la qualité des niveaux de gris n'ait pas été améliorée. Mais bon à part ça si elle est plus petit alors autant la prendre!

Mais pas dans TIGCC, parce que l'API n'est pas compatible avec les versions existantes.

./Post n°41 Marquer comme non lu.

Folco

Ecrit le: Jeudi 23 juin 2005 à 21:40

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Deux choses:
-> j'ai mis 20 minutes à adapter GFA-Editor à grib, au lieu de TIGCCLIB (en gagnant 800 octets, merci aux optimisations possibles en assembleur.
-> une bonne partie des fonctions très accessibles avec grib sont galère à aller chercher avec TIGCCLIB (hormis GrayOn et GrayOff, il n'y a que des macros en C dans gray.h :/ )

<<< 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°42 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 23 juin 2005 à 22:21

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Martial Demolins :
-> j'ai mis 20 minutes à adapter GFA-Editor à grib, au lieu de TIGCCLIB (en gagnant 800 octets, merci aux optimisations possibles en assembleur.

Que tu mettes 20 minutes, 20 heures ou 20 secondes pour ton adaptation n'a aucune importance, une API de TIGCCLIB ne sera jamais remplacée par une API incompatible.

./Post n°43 Marquer comme non lu.

Folco

Ecrit le: Jeudi 23 juin 2005 à 22:33

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

erf... on se veut programmeurs... c'est à dire qu'on ne rechigne pas au temps (s'il reste raisonnable) ou à la difficulté (si elle reste dans nos cordes) d'améliorer nos programmes (surtout des améliriorations en taille).

<<< 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°44 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 23 juin 2005 à 23:08

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

TIGCCLIB est compatible source depuis TIGCCLIB 1.0 (les programmes exemple de TIGCC 0.6 de 1999 compilent tous sans modifications avec TIGCC 0.96, sauf un qui a besoin d'une seule ligne #undef à cause d'un conflit de nom avec un nom réservé par le standard C ISO, donc inévitable), et ça ne va pas changer.

[EDIT: Correction d'un lapsus qui m'avait échappé (sauf->sans).]
-Edité le Dimanche 23 octobre 2005 à 00:26 par Kevin Kofler-

./Post n°45 Marquer comme non lu.

Sasume

Ecrit le: Vendredi 24 juin 2005 à 08:26

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Non.

Pourquoi ? (je parle du double-buffering, pas du fait que les plans peuvent être alloués consécutivement).

Tu veux carrément que je remplace gray.s??? Dis-donc, t'es gonflé... La compatibilité antérieure, ça ne te dit rien? (grib est totalement incompatible avec les routines de gris actuelles.) C'est hors de question!

On peut facilement obtenir la même API que TIGCCLIB. Mais ça prendra un peu plus de place que la version actuelle. Pour ce qui est du double-buffering de TIGCCLIB, par contre je ne sais pas si ce sera faisable.

./Post n°46 Marquer comme non lu.

Sasume

Ecrit le: Vendredi 24 juin 2005 à 08:38

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Dommage que la qualité des niveaux de gris n'ait pas été améliorée.

Qu'est-ce qui ne va pas avec les gris ?

./Post n°47 Marquer comme non lu.

Sasume

Ecrit le: Vendredi 24 juin 2005 à 08:43

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Est-elle plus rapide et consomme-t-elle moins les piles?

Je pense que mon handler d'interruption est plus court que celui de TIGCCLIB, donc à priori, elle bouffe moins de CPU (mais je pense que c'est complètement négligeable).
Par contre, mes fonctions d'attente se font en basse consommation, contrairement à TIGCCLIB.

./Post n°48 Marquer comme non lu.

Kevin Kofler

Ecrit le: Vendredi 24 juin 2005 à 09:06

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Sasume :
On peut facilement obtenir la même API que TIGCCLIB. Mais ça prendra un peu plus de place que la version actuelle. Pour ce qui est du double-buffering de TIGCCLIB, par contre je ne sais pas si ce sera faisable.

Le double-buffering fait partie de l'API.

./Post n°49 Marquer comme non lu.

Sasume

Ecrit le: Vendredi 24 juin 2005 à 09:19

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

En fait, j'avais dit ça parce que je ne connaissais pas bien l'API du double-buffering, mais je viens de regarder et c'est bon. Mais en fait, ce serait une mauvaise idée de la conserver. Par exemple la fonction GrayDBufToggleSync n'est pas intéressante et devrait être supprimée.
En fait, l'API de TIGCCLIB aurait du être bien pensée dès le début pour pouvoir être remplacée par celle de Grib sans problèmes.
Je pense que c'est mieux que Grib reste une lib séparée.

./Post n°50 Marquer comme non lu.

Lionel Debroux

Ecrit le: Vendredi 24 juin 2005 à 09:24

Envoyer un message privé à Lionel Debroux

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Je pense que tu as lu mes intentions au sujet de Grib dans le topic sur yAronet, Kevin ?

Sinon, tu laisses passer un paquet de trucs:
"
(en gagnant 800 octets, merci aux optimisations possibles en assembleur.
"
et
"
erf... on se veut programmeurs... c'est à dire qu'on ne rechigne pas au temps (s'il reste raisonnable) ou à la difficulté (si elle reste dans nos cordes) d'améliorer nos programmes (surtout des améliriorations en taille).
"
Mot magique: "optimisation taille".
"
-> une bonne partie des fonctions très accessibles avec grib sont galère à aller chercher avec TIGCCLIB (hormis GrayOn et GrayOff, il n'y a que des macros en C dans gray.h :/ )
"
Peu de programmeurs l'utilisent en ASM, mais c'est un avantage.

"
Par contre, mes fonctions d'attente se font en basse consommation, contrairement à TIGCCLIB.
"
Cela aussi est un avantage de grib.

Lionel Debroux - membre de TICT.

./Post n°51 Marquer comme non lu.

Kevin Kofler

Ecrit le: Vendredi 24 juin 2005 à 09:36

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Sasume :
Par exemple la fonction GrayDBufToggleSync n'est pas intéressante et devrait être supprimée.

Je ne suis pas d'accord, je reste de l'avis que c'est la seule manière à la fois fiable et simple d'utilisation de gérer le toggle. (Ça répond aussi à ta question pourquoi je n'aime pas ton design pour le double-buffering.)

./Post n°52 Marquer comme non lu.

Kevin Kofler

Ecrit le: Vendredi 24 juin 2005 à 09:38

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Lionel Debroux :
"
(en gagnant 800 octets, merci aux optimisations possibles en assembleur.
"
et
"
erf... on se veut programmeurs... c'est à dire qu'on ne rechigne pas au temps (s'il reste raisonnable) ou à la difficulté (si elle reste dans nos cordes) d'améliorer nos programmes (surtout des améliriorations en taille).
"
Mot magique: "optimisation taille".

Optimiser TIGCCLIB, je veux bien, mais pas en sacrifiant la compatibilité source!
Et il n'y a pas de raison que les gains d'octets de grib, s'ils existent vraiment (je n'ai pas fait mes tests à moi) ne puissent pas être obtenus avec une API compatible.

"
Par contre, mes fonctions d'attente se font en basse consommation, contrairement à TIGCCLIB.
"
Cela aussi est un avantage de grib.

Je peux implémenter ça aussi, mais ce n'est pas ça qui va réduire la taille...

./Post n°53 Marquer comme non lu.

Kevin Kofler

Ecrit le: Vendredi 24 juin 2005 à 09:41

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Et au fait:

Lionel Debroux :
Je pense que tu as lu mes intentions au sujet de Grib dans le topic sur yAronet, Kevin ?

Ça va en tout cas monter la priorité de mon plan de rajouter des routines de sprites clippées à TIGCCLIB pour réduire l'influence de ExtGraph.

./Post n°54 Marquer comme non lu.

Lionel Debroux

Ecrit le: Vendredi 24 juin 2005 à 09:55

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Tu ferais mieux de fournir un compilo et un émulateur qui fonctionnent, et même la routine 7 grays (même si c'est peu utile, car le flicker est important, ça bouffe plus de puissance, et qu'il existe environ une - horrible - fonction de sprite, celle de Backgammon), avant de faire cela...

Là, tu ne fais rien d'autre ton caprice parce que je ne veux pas utiliser ton patch qui donne une calling convention moins efficace au tilemap engine, et que je me tourne vers une librairie concurrente plus petite car elle me permet de ne pas le faire.
C'est pitoyable, une fois de plus, d'autant plus que ton effort sera vain. En effet, ce ne serait pas vraiment dans ton style (quoique... le "faites ce que je dis mais pas ce que je fais" est habituel chez toi, c'est un fait) de garder plusieurs boucles pour optimiser les shifts. Or, tu ne peux pas ne pas savoir que les utilisateurs se foutent assez de gagner quelques octets sur une routine de sprite si elle est 10 à 20% plus lente...
Rappelle-toi que même si tu es l'unique mainteneur de TIGCC (et tu t'occupes à le rester !), tu ne peux pas toujours décider de ce qui est bon pour la communauté.

Lionel Debroux - membre de TICT.

./Post n°55 Marquer comme non lu.

Sasume

Ecrit le: Vendredi 24 juin 2005 à 10:08

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Je ne suis pas d'accord, je reste de l'avis que c'est la seule manière à la fois fiable et simple d'utilisation de gérer le toggle.

Vous réalisez l'attente avant de swapper. C'est curieux, moi je la fais après plutôt. Ça évite que sur les HW1 on dessine sur le plan encore à l'écran...

./Post n°56 Marquer comme non lu.

geogeo

Ecrit le: Vendredi 24 juin 2005 à 12:24

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4256

Membre n°3

Inscrit le 29 janvier 2004

Toute une histoire pour pas grand chose. Sérieux mettez vos efforts en commun pour améliorer gray.s. On dirait un combat entre Boeing et Airbus.

Y a pas de concurrence sur les TIs.

Sinon moi ce qui me chagrine et qui fait que programmer un jeu ça ne m'interesse plus c'est que l'écran bave énormément avec les niveaux de gris ce qui rend les jeux très bof bof. Mais j'ai constaté par contre une amélioration des niveaux de gis pour les jeux en Kernel utilisant Genlib par exemple.

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°57 Marquer comme non lu.

Folco

Ecrit le: Vendredi 24 juin 2005 à 12:46

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Tout parti pris mis à part, j'ai constaté la même chose (c'est genlib que j'utilise quand je programme pour moi).

<<< 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."