Instructions plus lente sur Hw2 ? - Page 1

Je viens de voir que l'instruction printf() ralentit bien plus la Ti 89 que l'émulateur VTI hw1 ! Comment est-ce possible ?
Il y en a d'autres comme ça ?
Et vous, vous utilisez quoi pour écrire du texte dans un jeu qui à besoin de bcp de rapidité ?

preimière possibilité :
tu réécris pas à tous les cycles du programme, mais juste de temps en temps (tous les 10 cycles, par exemple)

deuxième : tu fais ta fonction perso...
parce que les fonctions de TI... ça rame à mort pr le texte.

troisème> tu utilise Genlib

quatrième> tu attend la prochaine version de Xlib

[pub]
Ma propre fonction DrawStr : cf. http://alineasofts.free.fr/einstein/A_LIRE.htm#historique, dans l'avant dernière ligne de la liste des améliorations de la ßêta 2.5
[/pub]

Raphaël a écrit :
Je viens de voir que l'instruction printf() ralentit bien plus la Ti 89 que l'émulateur VTI hw1 ! Comment est-ce possible ?

Pour faire des benchs et des comparaisons, ne te fie pas trop à Vti

Comment faire une routine semblable à printf() ?? Je veux dire, comment ça fonctionne une fonction pareille

Regarde les sources de TIGCC pour voir comment marche la fonction printf...

Il ne faut surtout pas se fier à VTI pour les timings !
Le fait que printf soit plus lente sous HW2 que sous HW1 n'est pas étonnant (en fait, la distinction est due à AMS 1.xx ou AMS 2.xx et non pas à la version de hardware, a priori). Les fonctions de dessin de chaîne de caractère, ou de caractères, sous HW2, bénéficient d'un mécanisme qui permet d'overrider les polices système standard, ceci au détriment de la vitesse bien entendu...
Regarde la doc du SDK de TI (la doc et le SDK sont des vraies daubes, mais bon) pour plus d'informations.

Oui mais en fait j'utilise un compteur de frame que Vark m'a montré.
Et même sans restriction de vitesse avec VTI, la frame rate ne monte pas . Elle ne dépend donc pas de la vitessse de d'affichage de VTI.
Parce-que c vrai que VTI n'émule pas parfaitement et il y a des différence entre le 68k et celui ou l'on peut émuler toutes les calc.

C vrai que ça vient de la ROM, de toute façon il n'y a pas vraiment d'autres solutions.
Mais je savais pas que ça dépendait de la ROM.

Et dans vos jeux vous faites comment pour afficher les stats avec du texte: par exemple la vie, les munitions, les scores....
Vous un buffer en plus où vous enregistrez tout ça et l'affichez à chaque frame ?
Parce-qu'une petite lettre écrit avec printf fait descendre d'au moins 30 fps la vitesse sur HW2 ! (qd le jeu tourne à un frame rate très élevé déjà)

J'ai pensé à un truc, mais je ne pense pas que ce soit ce qu'il y ait de mieux :
tu as une variable vie qui contient les points de vie du joueur (0 à 9), tu peux faire :
viestr[10][2]={"0","1","2","3","4","5","6","7","8","9"};
et pour afficher tu fais :
DrawStr(0,0,viestr[vie],1);
à mon avis, ce sera plus rapide que printf_xy(0,0,"%d",vie);

Mais bon, si tu as l'intention d'afficher un nombre compris entre 0 et 1000, ça fait beaucoup de chaines...

y'aplus rapide encore
tu fait un tbl de sprites des chiffres et tu l'utilise pour afficher le nbres de vies
>police personalisée plus rapidité

Ou pour économiser de la place (toujours avec ma méthode, même si celle de Vark est mieux en fait), tu peux faire un tableau de 10 chars qui ont les valeurs de 48 à 57 ensuite, tu peux les afficher avec DrawChar...

franchement quelkes povres sprites de8*8 ça bouffe pas bcp de place ...
d'ailleurs si j'avaisd utilisé cette méthode pour v-rally il serait bcp plus rapide

Ouais vos méthode on l'air pas mal ! Je vais sans doute utiliser des sprites alors !
Ceux d'extrgraph évidement !
Et avec genlib on peux en faire des plus rapide ? Parce-que j'ai télécharger cette lib mais je sais pas comment m'en servir.

Dans ai.15 (vous conaissez ? ) je crois qu'il utilise un buffer pour enregistrer les stats et puis il sont modifié un par un au cours du jeu. Parce-quen fait il remet jamais son buffer à 0 et pour afficher les vaisseau et tout ça, il n'utilise aucun buffer (ou je sais pas comment il fait) mais ça clignote pas et c rapide !

Oui kla meilleur solution c'est de se programmer sa propre fonction d'affichage de texte. Je n'ai pas mesuré précisément combien de fois mon DrawStr et plus rapide que celui de l'AMS, mais il est beaucoup beaucoup beaucoup plus rapide.

Oui, soit tu passe par un tab de char contenant les num correspondant aux chiffres 0, 1, ... 10 et tu affiches avec DrawChar (moins gros que la méthode avec les chaines), ou bien, vu que le cas est simple ici, affiche avec des sprite, c'est très rapide et + joli !

C'est dur à programmer ? Ca se programme en C ? Et au fait on peut le télécharger où ton shell Thibaut ?

Et on fait on fait comment pour créer et lire une matrice en C ?
Parce-que pour le momenbt j'utilise que des listes mais comme c'est mon premier projet je vais laisser tomber ert essayer de passer à qqchose de plus sérieux.

J'ai mis une après-midi entière à dessiner les 256 caractères, puis 1 journée et demi pour coder mon DrawStr ultra optimisé.

Dessine-toi tes 10 fontes et affiche-les avec une fonction PutSprite quelconque, ce sera plus facile (mais plus lent qu'un vrai DrawStr optimisé... mais plus rapide que celui de l'AMS)

Et pour écrire ta fonction avec les 10 sprites par ex, fo faire comment ?
Sinon je peux tjrs faire une fonction comme ça:
if(nbre==1)
{
sprite(....sprite1...)
}
.........

aaaahhhhhhhhaaaah quelle horreur !!!!!!!!!!!!! Il y a une structure algorithmique dédiée aux tests multiples sur une même variable (les valeurs doivent être constantes) :

switch (nbre)
{
  case 1 : blablabla; break;
  case 2 : blablabla; break;
  ...
}

Elle produit un code considérablement plus rapide.

Mais pour afficher des chiffres il y a encore mieux :
- tu stockes l'adresse de chaque sprite dans un tableau (qui fera donc 10 éléments puisqu'il y a 10 sprites)
- pour obtenir l'adresse du bon sprite, il suffit alors de faire : adresse_du_sprite_correspondant_au_nombre= tableau_des_adresses_des_sprites[nbre];

la méthode du tableau c la meilleure

les swich j'aime pas trop

Elle produit un code considérablement plus rapide.

Mais pour afficher des chiffres il y a encore mieux :
- tu stockes l'adresse de chaque sprite dans un tableau (qui fera donc 10 éléments puisqu'il y a 10 sprites)
- pour obtenir l'adresse du bon sprite, il suffit alors de faire : adresse_du_sprite_correspondant_au_nombre= tableau_des_adresses_des_sprites[nbre];

Je savais pas que l'on pouvais mettre l'adresse dans un tableau !
Ah, oui là c'est sûr que c la meilleurs solution !
C'est un truc comme ça que je cherchait ! : lire le sprite à afficher dans une variable.
Enfin, un truc précalculé quoi !

Mais comment on fait pour :
-déclarer l'adresse du sprite ?
- et une fois l'adresse lu, afficher le sprite avec l'adresse ?

Raphaël a écrit :
Parce-que c vrai que VTI n'émule pas parfaitement et il y a des différence entre le 68k et celui ou l'on peut émuler toutes les calc.

C vrai que ça vient de la ROM, de toute façon il n'y a pas vraiment d'autres solutions.

Ben non, ça vient du fait que VTI n'est pas un vrai 68k, et ce que tu mesures, c'est la vitesse de ton x86 à émuler les instructions 68k, pas la vitesse d'un 68k.
N'utilise jamais VTI pour mesurer un temps d'exécution!!!

Raphaël :  // === définitions de sprites  char sprite_0[8]= {0b00010000                     0b01101100                     0b10000010                     0b10000010                     0b10000010                     0b10000010                     0b01101100                     0b00010000}; char sprite_1[8]= {0b00010000                    0b01110000                    0b10010000                    0b00010000                    0b00010000                    0b00010000                    0b00010000                    0b11111110}; ... // === déclarations inline void afficher_mon_chiffre(void *adresse_du_plan, short x, short y, short chiffre); char *sprites_chiffres[10]= {sprite_0, sprite_1, sprite_2, sprite_3, sprite_4, sprite_5, sprite_6, sprite_7, sprite_8, sprite_9}; // === implémentation inline void afficher_mon_chiffre(void *adresse_du_plan, short x, short y, short chiffre) {   Sprite8(x, y, 8, sprites_chiffres[chiffre], adresse_du_plan, SPRT_OR); }
J'ai essayé d'être très clair.
On peut même faire mieux puisque tous les sprites sont de mêmes dimensions et sont stockés linéairement...

Raphaël a écrit :
Mais comment on fait pour :
-déclarer l'adresse du sprite ? - et une fois l'adresse lu, afficher le sprite avec l'adresse ?

[i]unsigned char sprites[256][8]={{0,0,0,0,0,0,0,0},{1,1,1,1,1,1,1,1},/*etc. Il manque 254 sprites. */};
void _main(void) {
int i=(unsigned char)'A'; //(unsigned char) parce qu'on ne veut pas d'indices négatifs!!!
Sprite8(0,0,8,sprites,LCD_MEM,SPRT_OR); // On utilise des sprites 8×8. Ça devrait suffire.
}

Il demandait uniquement pour les chiffres

Thibaut, c'est quoi la source de ton drawstr tres rapide ? stp

pphd en avait donné une version

Thibaut: il faut que tu mesures ta routine de DrawStr super super optimisée... Si elle est plus de 4 fois plus rapide que celle d'AMS, bravo.
Raphaël: tu peux faire plus rapide que des routines de sprite. Regarde tthdex/tthedit/ebook de la TIGCC Tools Suite, disponible à http://tict.ticalc.org .

Les fonctions de chaîne de caractères de TICT seront bientôt intégrées à la librairie de TIGCC, je m'en occupe en ce moment.

Cool, on pourra les comparer à mon DrawStr
Il me semble qu'il est impossible de faire de DrawStr plus rapide que ce que j'ai fait, mais je peux me tromper. Attention c'est un DrawStr 4x6 (petite fonte).

faut jamais dire que t'as fait la routine la plus rapide. c pas moi qui le dit, c M Abrash