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 » Betas et WIPs » Hawk (107 réponse(s))

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

Sasume

Ecrit le: Jeudi 1er septembre 2005 à 13:12

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Nul :
Les animations sont en fait les ennemis qu'il faut tuer.

OK, donc le tilemap engine ne te srvira à rien pour ça.

Les bords haut et bas sont les images fixes qui défilent sur le fond (avec une espèce de treillis).
Je n'utilise SpriteX8 que pour rafraîchir les bords donc tous les 9 pixels. Sinon j'utilise Sprite32 pour les animations.
Il y a seulement deux motis élémentaires qui constituent les bords: un motif pour le haut et un autre pour le bas. La "map" est une liste indiquant l'ordonnée à laquelle il faut afficher d'abord le bord haut puis le bord bas (dans le code, c'est situé dans le dossier 'gfx', fichier 'hawk_gfx', 'bord_ord'). Ca peut paraître un peu crade comme façon de faire mais ça gagne énormément de place. Au lieu d'afficher 3 sprites avec Sprite32, j'affiche une seule sprite avec SpriteX8.

Pourquoi 3 sprites avec Sprite32 si tes bords font 9 pixels de largeur ?
En fait, je n'avais pas vu que tes niveaux ressemblaient à un "tunnel", c'est vrai que dans ce cas, ta solution est plus économique en mémoire. Et puis niveau rapidité je pense que tu t'en sors bien parce que tu n'as pas besoin de tout réafficher (l'arrière plan) à chaque fois...

./Post n°77 Marquer comme non lu.

Nul

Ecrit le: Jeudi 1er septembre 2005 à 13:54

Membre: Maître

Messages: 141

Membre n°196

Inscrit le 16 avril 2004

Sasume :
Pourquoi 3 sprites avec Sprite32 si tes bords font 9 pixels de largeur ?

Car la hauteur des bords est de 80 pixels.

"De tous les animaux, l'homme a le plus de pente,
A se porter dedans l'excès."

Jean de la Fontaine

./Post n°78 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 1er septembre 2005 à 14:00

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

La hauteur n'a aucune importance, tu peux passer n'importe quelle hauteur en paramètre.

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

Sasume

Ecrit le: Jeudi 1er septembre 2005 à 14:02

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Tout à fait. Tu pourrais donc utiliser Sprite16. Ou sinon réduire ton sprite à 8 pixels et utiliser Sprite8.

./Post n°80 Marquer comme non lu.

Nul

Ecrit le: Jeudi 1er septembre 2005 à 14:15

Membre: Maître

Messages: 141

Membre n°196

Inscrit le 16 avril 2004

Ah tiens, je ne savais pas ! Ca marche aussi avec les fonctions Sprite32 de tigcc alors.
Merci beaucoup en tout cas (on en apprend tous les jours)

"De tous les animaux, l'homme a le plus de pente,
A se porter dedans l'excès."

Jean de la Fontaine

./Post n°81 Marquer comme non lu.

Sasume

Ecrit le: Jeudi 1er septembre 2005 à 15:15

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Personnellement, je te conseille d'utiliser les fonctions graphique d'une librairie puissante (pas TIGCCLIB), tu auras toutes les chances d'obtenir un code plus petit et moins gourmand en ressources.

./Post n°82 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 1er septembre 2005 à 16:48

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Plus petit, pas forcément. Les routines de TIGCCLIB gèrent tous les modes d'affichage avec la même routine.

./Post n°83 Marquer comme non lu.

Folco

Ecrit le: Jeudi 1er septembre 2005 à 16:56

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

C'est bien ça le problème

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

Sasume

Ecrit le: Jeudi 1er septembre 2005 à 16:58

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Oui puisqu'en général on n'utilise pas plus d'un ou deux modes d'affichage différents.

./Post n°85 Marquer comme non lu.

Lionel Debroux

Ecrit le: Vendredi 2 septembre 2005 à 10:11

Envoyer un message privé à Lionel Debroux

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Ce ne doit en effet pas être la majorité des programmes qui utilisent les trois à la fois. Si on utilise XOR, c'est souvent en double XOR. Sinon, AND+OR, mais on utilise facilement MASK / TRAN (qui n'existe pas en tant que telle dans TIGCCLIB) dans ce cas. C'est plus rapide.

Des routines dont les versions clippées seront peut-être aussi dans ExtGraph: voir ce topic.

Lionel Debroux - membre de TICT.

./Post n°86 Marquer comme non lu.

Nul

Ecrit le: Vendredi 2 septembre 2005 à 14:10

Membre: Maître

Messages: 141

Membre n°196

Inscrit le 16 avril 2004

J'ai fait la version incompatible on-calc pour la 89: 4294 bytes de gagnés sur le fichier non compressé mais gain de 1637 bytes pour le ppg, ce qui est ridicule. Je ne ferai donc pas de version incompatible on-calc à moins que certains aient de sérieux arguments

"De tous les animaux, l'homme a le plus de pente,
A se porter dedans l'excès."

Jean de la Fontaine

./Post n°87 Marquer comme non lu.

geogeo

Ecrit le: Vendredi 2 septembre 2005 à 14:17

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4256

Membre n°3

Inscrit le 29 janvier 2004

Encore une fois un bon exemple que de faire des fichiers on-calc imcompatibles n'apportent pas grand chose!

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

Folco

Ecrit le: Vendredi 2 septembre 2005 à 15:18

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

pour info, comment as-tu fait ton incompatibilité on-calc?
juste en décochant les options de 92+/V200 ou en optimisant le code et les données?

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

Nul

Ecrit le: Vendredi 2 septembre 2005 à 15:26

Membre: Maître

Messages: 141

Membre n°196

Inscrit le 16 avril 2004

Les deux. En enlevant toutes les conditions pour déterminer si c'était une 89 ou une 92+.

"De tous les animaux, l'homme a le plus de pente,
A se porter dedans l'excès."

Jean de la Fontaine

./Post n°90 Marquer comme non lu.

Folco

Ecrit le: Vendredi 2 septembre 2005 à 15:33

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

ok, merci.

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

Kevin Kofler

Ecrit le: Vendredi 2 septembre 2005 à 16:59

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Nul :
Les deux. En enlevant toutes les conditions pour déterminer si c'était une 89 ou une 92+.

Ce n'est même pas la peine de faire ça, GCC peut faire ça tout seul si tu compiles seulement pour un modèle (ou deux dans le cas de TI-92+ et V200).

./Post n°92 Marquer comme non lu.

Nul

Ecrit le: Vendredi 2 septembre 2005 à 17:09

Membre: Maître

Messages: 141

Membre n°196

Inscrit le 16 avril 2004

Ah, ok.

"De tous les animaux, l'homme a le plus de pente,
A se porter dedans l'excès."

Jean de la Fontaine

./Post n°93 Marquer comme non lu.

Lionel Debroux

Ecrit le: Vendredi 2 septembre 2005 à 17:36

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

> J'ai fait la version incompatible on-calc pour la 89: 4294 bytes de gagnés sur le fichier non compressé
C'est un chiffre pas étonnant, qui dépasse LCD_SIZE octets, et ce sur tous les modèles...
> mais gain de 1637 bytes pour le ppg, ce qui est ridicule
Ce qui est ridicule, en vérité, c'est de dire que c'est ridicule de diminuer la taille d'un fichier de 1637 octets, quel qu'il soit ! Pourquoi la taille compressée ne diminue-t-elle pas autant que la taille compressée ? Parce que tu as réduit la compressibilité due à la redondance du code de test des touches ou de taille de l'écran.
En proportion, ça doit être ~5% de la taille du PPG.
Par comparaison, le gain sur le PPG est par exemple de plus de 3/2 d'un lanceur spécifique (poubelle !), plus d'un ttstart générique avec routine rapide. C'est ce que j'ai gagné sur GFA-TEM.

La taille compressée n'est pas le bon marqueur de l'optimisation, c'est la taille décompressée (= consommation de RAM lors de l'exécution) qui compte le plus. Mais après tout, ça reste à toi de choisir si tu veux continuer à pénaliser tous les utilisateurs de façon permanente, pour une minorité d'utilisateurs (ceux des 92+/V200)...

> Encore une fois un bon exemple que de faire des fichiers on-calc imcompatibles n'apportent pas grand chose!
Tu sais très bien qu'il y a d'excellents exemples du contraire, TI-Chess en tête. Rajoute deux fonds d'écran (2*LCD_SIZE) et plusieurs KB pour les routines spécifiques modèle (tests de touches, graphismes), et tu obtiens un fichier plus gros (décompressé) que ce qu'aucune version de TI-Chess ne l'a été depuis longtemps, voire jamais. Et encore une fois, les gains se cumulent...

Lionel Debroux - membre de TICT.

./Post n°94 Marquer comme non lu.

Nul

Ecrit le: Vendredi 2 septembre 2005 à 18:11

Membre: Maître

Messages: 141

Membre n°196

Inscrit le 16 avril 2004

Parce que tu as réduit la compressibilité due à la redondance du code de test des touches ou de taille de l'écran.

Pas compris (franchement). J'utilise des #define (sans test pour la version incompatible) pour les touches, et pour les écrans ? #confus#

J'ai dit plus haut que j'ai supprimé toutes les conditions qui déterminent le modèle (plus de "routines spécifiques modèle"). Les écrans doivent conserver leur taille (ce n'est pas une histoire de modèle) pour respecter la version GB.

Mais après tout, ça reste à toi de choisir si tu veux continuer à pénaliser tous les utilisateurs de façon permanente,

Une pénalisation de 1637 octets sur des calcs qui ont 2 Mb de mémoire (la majorité des machines sont appelées à avoir même plus), bon ... J'ai la conscience tranquille. Ok pour la RAM ...

pour une minorité d'utilisateurs (ceux des 92+/V200)...

Qu'est-ce-qui te permet de dire ça ? Personnellement, je connais pas mal de gens qui ont une 92+ ou V200 (et qui me remercient).

J'espère que tu ne prendras pas ma réponse mal et que ce topic ne dérapera pas car je ne suis pas là pour m'engueuler

"De tous les animaux, l'homme a le plus de pente,
A se porter dedans l'excès."

Jean de la Fontaine

./Post n°95 Marquer comme non lu.

Kevin Kofler

Ecrit le: Vendredi 2 septembre 2005 à 18:38

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Lionel Debroux :
> mais gain de 1637 bytes pour le ppg, ce qui est ridicule
Ce qui est ridicule, en vérité, c'est de dire que c'est ridicule de diminuer la taille d'un fichier de 1637 octets, quel qu'il soit !

Si c'était une vraie optimisation, tu aurais entièrement raison, mais là, c'est virer des fonctionnalités pour gagner 1 KO, et ça ne vaut vraiment pas le coup.

Pourquoi la taille compressée ne diminue-t-elle pas autant que la taille compressée ? Parce que tu as réduit la compressibilité due à la redondance du code de test des touches ou de taille de l'écran.

On s'en fout du pourquoi (qui est évident), c'est le résultat qui compte.

En proportion, ça doit être ~5% de la taille du PPG.

Oui, et justement ça ne vaut pas le coup de virer une fonctionnalité (la compatibilité on-calc).

La taille compressée n'est pas le bon marqueur de l'optimisation, c'est la taille décompressée (= consommation de RAM lors de l'exécution) qui compte le plus.

Non. La consommation d'archive est permanente, la consommation en RAM que temporaire. L'archive est bien plus importante. (Maintenant, si le choix est entre perdre ~50 octets d'archive ou presque 4 KO de RAM, c'est une autre histoire. #roll#

Tu sais de quoi je parle.)

Mais après tout, ça reste à toi de choisir si tu veux continuer à pénaliser tous les utilisateurs de façon permanente, pour une minorité d'utilisateurs (ceux des 92+/V200)...

Tu as quelque chose contre les minorités?

Tu sais très bien qu'il y a d'excellents exemples du contraire, TI-Chess en tête. Rajoute deux fonds d'écran (2*LCD_SIZE) et plusieurs KB pour les routines spécifiques modèle (tests de touches, graphismes), et tu obtiens un fichier plus gros (décompressé) que ce qu'aucune version de TI-Chess ne l'a été depuis longtemps, voire jamais. Et encore une fois, les gains se cumulent...

Le fond d'écran TI-92+, on pourrait s'en passer, les tests de touches, ils pourraient être factorisés en utilisant les _keytest(RR_*), et les graphismes, ben les pièces sont les mêmes sur TI-89 et TI-92+ à ma connaissance.