Accueil Ti-Gen Foire Aux Questions Chat sur le chan #tigcc sur IRC
Liste des membres Rechercher Aide
Bienvenue Invité !   Se connecter             Mes sujets   
Administrer
0 membre(s) et 1 visiteur(s) actif(s) durant les 5 dernières minutes 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))
./REPRISE DU POST PRECEDENT (post n°19)   Marquer comme non lu.
Lionel Debroux Ecrit le: Jeudi 7 avril 2005 à 08:44 Déconnecté(e)    Voir le profil de Lionel Debroux Envoyer un email à Lionel Debroux Visiter le site WEB de Lionel Debroux Envoyer un message privé à Lionel Debroux  

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.
    
./Post n°20   Marquer comme non lu.
Jfg Ecrit le: Jeudi 7 avril 2005 à 12:57 Déconnecté(e)    Voir le profil de Jfg Envoyer un email à Jfg Visiter le site WEB de Jfg Envoyer un message privé à Jfg  


Lionel, on a déjà parlé de l'incompabilité oncalc dans une autre section de ce même forum; C'est le bordel pour l'utilisateur.

Kill Mario
    
./Post n°21   Marquer comme non lu.
Folco Ecrit le: Jeudi 7 avril 2005 à 13:41 Déconnecté(e)    Voir le profil de Folco Envoyer un email à Folco Envoyer un message privé à Folco  


>>le FAIT est que le kernel + stdlib est lui-même un stub de 30 KB
tu "oublies" de contrebalancer avec le poids des fonctions de TIGCCLIB et des libs statiques il me semble. :)
<<< 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°22   Marquer comme non lu.
Sasume Ecrit le: Jeudi 7 avril 2005 à 14:20 Déconnecté(e)    Voir le profil de Sasume Envoyer un email à Sasume Visiter le site WEB de Sasume Envoyer un message privé à Sasume  

Et puis quoi qu'il en soit, le stub des programmes générés à partir de TIGCCLIB en est un, un point c'est tout...

Donc si on dit que genlib _nostub n'était pas du vrai _nostub car elle incluait un stub, on ne peut pas se permettre de dire que les programmes _nostub générés par tigcc le sont également puisqu'ils intègrent un stub...

Bref, c'est idiot cette conversation.
    
./Post n°23   Marquer comme non lu.
Kevin Kofler Ecrit le: Jeudi 7 avril 2005 à 15:47 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Lionel Debroux :
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.

Faux. Un programme incompatible on-calc a toujours besoin d'une détection de modèle pour éviter qu'on fasse planter la calculatrice.

Un programme compatible on-calc, lui, peut dans certains cas s'en passer (mais pas s'il a une interface graphique ou une lecture de touches, en général; en revanche, un programme comme Gosper89 n'a pas besoin de détection du modèle), et dans ces cas l'incompatibilité on-calc ne sert à rien.
-Edité le Jeudi 7 avril 2005 à 15:47 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°24   Marquer comme non lu.
geogeo Ecrit le: Jeudi 7 avril 2005 à 18:32 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


Titre du topic? #roll#
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°25   Marquer comme non lu.
Invité Ecrit le: Jeudi 7 avril 2005 à 20:03 Déconnecté(e)    
 
Ouais mais c'est intéressant ! :) J'ai besoin de savoir des choses de ce "violent débat" aussi.

Et au passage, c'est plutôt une fonction GrayClipSpriteX8_OR_R dont j'ai besoin.
    
./Post n°26   Marquer comme non lu.
geogeo Ecrit le: Jeudi 7 avril 2005 à 22:02 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


Tout est dans GFA Basic, cette fonction existe. Et travail en OR et XOR.
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°27   Marquer comme non lu.
Invité Ecrit le: Vendredi 8 avril 2005 à 06:32 Déconnecté(e)    
 
Ah bon ben alors j'ai ma réponse ! Merci. :)
    
./Post n°28   Marquer comme non lu.
Lionel Debroux Ecrit le: Vendredi 8 avril 2005 à 12:09 Déconnecté(e)    Voir le profil de Lionel Debroux Envoyer un email à Lionel Debroux Visiter le site WEB de Lionel Debroux Envoyer un message privé à Lionel Debroux  

> > 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.
> Faux. Un programme incompatible on-calc a toujours besoin d'une détection de modèle pour éviter qu'on fasse planter la calculatrice.
Euh, évidemment. Je me suis mal exprimé. La détection de calc est nécessaire, mais quand on a trouvé que ce n'est pas la bonne calculette, on sort. Ca enlève tout le code qui regarde à chaque fois quel est le modèle, et quoi faire en fonction. Les détections touches sont parmi ce qui se fait de pire, voir Ice Hockey 68k (et si Travis n'a rien changé, puisque les blocs spécifiques ne sont pas tous entre #ifdef, on pourrait gagner plus que ~3 KB en passant en incompatible on-calc).

> Lionel, on a déjà parlé de l'incompabilité oncalc dans une autre section de ce même forum; C'est le bordel pour l'utilisateur.
Pas tant que ça. Ceux qui ont des scrupules peuvent toujours proposer les deux types (ce n'est même pas nécessairement une contrainte sur le code) pour faire plaisir à tout le monde...

> tu "oublies" de contrebalancer avec le poids des fonctions de TIGCCLIB et des libs statiques il me semble.
Une partie significative des fonctions de TIGCCLIB (en gros, stdio.h) n'est pas à utiliser pour des raisons d'efficacité. Cet aspect est aggravé par le fait qu'elles soient statiques, en effet.

Le format des libs statiques est très inefficace en taille. Si tu ne l'as jamais fait, expérimente ce que rien que le vieux ZIP fait aux libs statiques (en prenant des libs grosses et avec moins de redondance qu'ExtGraph, voir Cygwin sur Win32). Alors un 7-Zip "Ultra" qui fait des archives solides (attention, 512 MB de RAM nécessaires)...
Lionel Debroux - membre de TICT.
    
./Post n°29   Marquer comme non lu.
Kevin Kofler Ecrit le: Vendredi 8 avril 2005 à 13:37 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Lionel Debroux :
> Lionel, on a déjà parlé de l'incompabilité oncalc dans une autre section de ce même forum; C'est le bordel pour l'utilisateur.
Pas tant que ça. Ceux qui ont des scrupules peuvent toujours proposer les deux types (ce n'est même pas nécessairement une contrainte sur le code) pour faire plaisir à tout le monde...

La compatibilité on-calc reste quand-même ce qu'il y a de plus pratique.

Le format des libs statiques est très inefficace en taille. Si tu ne l'as jamais fait, expérimente ce que rien que le vieux ZIP fait aux libs statiques (en prenant des libs grosses et avec moins de redondance qu'ExtGraph, voir Cygwin sur Win32). Alors un 7-Zip "Ultra" qui fait des archives solides (attention, 512 MB de RAM nécessaires)...

On s'en fout de la taille des fichiers .a, ils ne sont jamais envoyés à la calculatrice.
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°30   Marquer comme non lu.
Folco Ecrit le: Vendredi 8 avril 2005 à 14:06 Déconnecté(e)    Voir le profil de Folco Envoyer un email à Folco Envoyer un message privé à Folco  


>>La compatibilité on-calc reste quand-même ce qu'il y a de plus pratique.
²

>>On s'en fout de la taille des fichiers .a, ils ne sont jamais envoyés à la calculatrice
ça ok. mais les 20 fonctions copiées dans 3 progs différents sur la même calc, c'est pas pareil. :)
<<< 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°31   Marquer comme non lu.
Lionel Debroux Ecrit le: Vendredi 8 avril 2005 à 17:24 Déconnecté(e)    Voir le profil de Lionel Debroux Envoyer un email à Lionel Debroux Visiter le site WEB de Lionel Debroux Envoyer un message privé à Lionel Debroux  

> La compatibilité on-calc reste quand-même ce qu'il y a de plus pratique.
Pour les end users, oui. Mais ça fait longtemps que je ne suis plus un end user, et toi aussi...

J'explique dans mon tutorial sur l'optimisation (car c'est un fait) que la compatibilité on-calc, c'est (en termes d'optimisation) pénaliser avec des programmes plus gros et plus lents (même si ce n'est pas forcément significatif) la majorité d'utilisateurs (89/89T, même si ce dernier modèle est encore rare) pour une minorité (92+/V200).
Quand j'étais au lycée, avant l'apparition de la V200 et de la 89T, il y avait plus de 80% de 89 par rapport aux 92+. Je me suis occupé d'une petite dizaine de 89, et d'une seule 92+. Jouant moins avec ma calculatrice que beaucoup de mes camarades, elle n'était pas pleine, et il m'était facile de prendre la version pour la 92+, puis de l'effacer.
Et on est en France, où les calculettes de dimensions physiques supérieures à celles de la 83(4)(+) ou 89 sont autorisées.

Un autre fait est que s'ils veulent un programme, les utilisateurs sont parfaitement capables de faire ce qu'il faut pour. Par exemple, sur 89, upgrader AMS à 2.07+ pour avoir la clock imprécise et le "beau" desktop lent (ce qui fait au passage perdre un secteur d'archive), quand ils se sont faits avoir par le marketing.

Désolé de le dire aussi brutalement, mais les programmes de TICT sont maintenant pour la plupart incompatibles on-calc, et ils sont et restent plus téléchargés que ceux de beaucoup d'autres...
Lionel Debroux - membre de TICT.
    
./Post n°32   Marquer comme non lu.
Jfg Ecrit le: Vendredi 8 avril 2005 à 19:56 Déconnecté(e)    Voir le profil de Jfg Envoyer un email à Jfg Visiter le site WEB de Jfg Envoyer un message privé à Jfg  


"mais les programmes de TICT sont maintenant pour la plupart incompatibles on-calc"
Distribue les 2 versions (compatibles et non-compatible) et puis on n'en parle plus :)
Kill Mario
    
./Post n°33   Marquer comme non lu.
Sasume Ecrit le: Vendredi 8 avril 2005 à 21:40 Déconnecté(e)    Voir le profil de Sasume Envoyer un email à Sasume Visiter le site WEB de Sasume Envoyer un message privé à Sasume  

Au fait, pour revenir au sujet, je suis en train de réécrire les fonction put_big_sprite de genlib (équivalent de GrayClipSpriteX8 en gros), je pourrai probablement adapter le code pour extgraph.
Le principal changement c'est que les big_sprites ont des largeurs multiples de 16 (et pas 8 comme extgraph), donc j'écris word par word, et ce serait très lent d'appliquer la même technique octet par octet avec extgraph, il faudrait donc modifier la boucle d'affichage, et ça pourrait utiliser un ou deux registres en plus, ça risque d'être tendu. Quoique, il n'y a pas de calcul de masque à faire...
Bref, de toute façon, pour l'instant je n'ai fait que la moitié, et je n'ai pas énormément de temps :(
    
./Post n°34   Marquer comme non lu.
Sasume Ecrit le: Vendredi 8 avril 2005 à 21:43 Déconnecté(e)    Voir le profil de Sasume Envoyer un email à Sasume Visiter le site WEB de Sasume Envoyer un message privé à Sasume  

Par contre, je n'ai pas envie de me taper les 50 versions d'extgraph (gray/nb, or/xor/and/mask/blit), donc je vous donnerai ce que j'aurai écrit et vous vous débrouillerez avec. Cela dit, j'ai cru comprendre, Lionel, que vous disposiez déjà de telles fonctions (écrites par un américain je crois), quel est le problème ?
    
./Post n°35   Marquer comme non lu.
Sasume Ecrit le: Vendredi 8 avril 2005 à 21:47 Déconnecté(e)    Voir le profil de Sasume Envoyer un email à Sasume Visiter le site WEB de Sasume Envoyer un message privé à Sasume  

Encore un détail : Je ne prétends pas que mes routines soient plus efficaces que d'autres.
Je suis simplement pour le partage de code.
    
./Post n°36   Marquer comme non lu.
geogeo Ecrit le: Vendredi 8 avril 2005 à 22:06 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


Tu peux pas éditer ton post au lieu d'en faire 3 à la suite? #roll#
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°37   Marquer comme non lu.
serioussam Ecrit le: Samedi 9 avril 2005 à 09:13 Déconnecté(e)    Voir le profil de serioussam Envoyer un email à serioussam Visiter le site WEB de serioussam Envoyer un message privé à serioussam  

J'allais poster exactement la même chose :D
la shasse é ouvèrte poure lay maychants
    
./Post n°38   Marquer comme non lu.
Sasume Ecrit le: Samedi 9 avril 2005 à 11:45 Déconnecté(e)    Voir le profil de Sasume Envoyer un email à Sasume Visiter le site WEB de Sasume Envoyer un message privé à Sasume  

Non parce que sur le PC à partir duquel j'ai posté, IE plante quand on demande d'ouvrir une nouvelle fenêtre.
    
  :: Index » Forum Ti68K » Programmation C » GrayClipSpriteX8_OR ? (39 réponse(s))
Pages : 2/3     « 1 [2] 3 » »|

.Répondre à ce sujet
Les boutons de code
[B]old[I]talic[U]nderline[S]trikethrough[L]ine Flip Hori[Z]ontallyFlip [V]erticallySha[D]ow[G]low[S]poilerCode [G][C]ite
Bullet [L]istList Item [K] Link [H][E]mail[P]icture SmileysHelp
Couleurs :
Saisissez votre message
Activer les smileys
     

Forum de Ti-Gen v3.0 Copyright ©2004 by Geoffrey ANNEHEIM
Webmaster: Kevin KOFLER, Content Admins: list, Server Admins: Tyler CASSIDY and Kevin KOFLER, DNS Admin: squalyl
Page générée en 84.18ms avec 20 requetes