Ce nouveau jeu, c'est grav ! - Page 6

[sondage=14643]

Merci pour vos réponses !

Arvi89 :
Perso, je trouvais que ça sonnait bien "grav" ...

grav' !

Je songe à améliorer la version Ti92+/V200 qui pour l'instant ne fait qu'afficher l'écran de la Ti89 en haut à gauche.
J'aimerais alors savoir ce que vous mettriez dans l'espace qui reste ? (je centrerai le jeu)
Titre, temps, les records du niveau ...?

Ah, aussi, préférez-vous une version compatible avec ti89 et ti92+/v200 ou deux versions différentes (une pour ti89 et une pour ti92+/v200) ?

Merci pour vos réponses !

Bah... ce serait mieux si tout l'écran était utilisé^^

Domage de n'utiliser qu'un bout de l'écran, dans le pire des cas occupe le reste de l'écran avec des conneries, c'est toujours bien mieu que de ne voir qu'une partie de l'écran utilisé..

bon, je me suis remis dessus mais le zoom que j'ai codé en C est trèèèèès lent (3 fps)
Alors j'aimerais savoir où je pourrais trouver une fonction plus rapide

Sinon, ca ne prendra pas tout l'écran

Merci pour vos reponses !

PS : desolé pour le remontage mais je vais bientot releaser une nouvelle version avec quelques nouvelles features et il me manque ce zoom !

Personnellement, je trouve que c'est un peu laid, un zoom. Je te conseille de ne pas utiliser tout l'écran, ou à la limite d'utiliser la partie vide de l'écran pour afficher des infos sur le jeu (nom du niveau, score, etc...)

Sinon, ExtendeD avait codé une routine de zoom très rapide (utilisant du précalcul), essaie de chercher ça sur le forum, ou demande lui directement par mini-msg.

Oui, mais ce n'est pas aussi rapide que la fonction d'ExtendeD.

Par chance, on a une ratio écran pas trop compliquée (3:2), et donc basé sur des tables, ça pourrait être très simple et vraiment très rapide (moyennant 528 octets de RAM pour les tables).
Voici un exemple très simple de comment on peut faire // C Source File // Created 11/12/2004; 11:26:12 #include <tigcclib.h> //Types de données plus rapides à écrire %) u8 signifie 8 bits non signé. typedef unsigned char u8; typedef short s16; typedef unsigned short u16; typedef unsigned long u32; //Excusez les pseudo-optimisations merdiques pour la TI, je suis plus habitué à la GBA maintenant ;) void CalcScaling (u8 *ecran, u16 *buffer)               {      u16 i, decal, *tmpBuf;      u16 valeur;      u8 temp;            memset(buffer,0,sizeof(buffer));      tmpBuf=buffer;      for (valeur=0;valeur<256;valeur++)                    {           temp=valeur;           decal=12-2;           //Première partie (position paire)           for (i=0;i<8;i+=2)                    {                //Paire                if (temp&128)                     *tmpBuf|=3<<decal;                decal--;                temp<<=1;                //Imaire                if (temp&128)                     *tmpBuf|=1<<decal;                decal-=2;                temp<<=1;           }           tmpBuf++;      }            //A la suite, le numéro de ligne à blitter      tmpBuf=buffer+256;      //0=saut de ligne, 1=ligne identique à la précédente      *tmpBuf++=0;      for (i=1;i<128;i++)                         {           if ((int)((i*100)/128)==(int)(((i-1)*100)/128))                *tmpBuf++=1;           else                *tmpBuf++=0;      } } void Scale (u8 *dst, u8 *src, u16 *buffer)                    {      u16 i, valeur, j, *ligne;            //Je crois que cette construction ne change rien avec celle-ci sur TI:      //for (i=28;i;i-=2)      //Car il n'y a pas de soustraction écrivant directement sur le statut (??) comme subs r0,r0,#1 sur ARM      //A tester en fait      ligne=buffer+256;      for (j=0;j<100;)                    {           //Refaire la même ligne?           if (*ligne++)                src-=30;           else                j++;           for (i=0;i<20;i+=2)                    {                //Je suis obligé de diviser en deux accès 8 bits, même si un accès impair 16 bits aurait été plus optimisé...                valeur=buffer[*src++];                *dst++|=valeur>>4;                //La perte d'informations est volontaire                *dst|=valeur<<4;                valeur=buffer[*src++];                *dst++|=valeur>>8;                *dst++|=valeur;           }           src+=10;      } } // Fonction principale void _main (void) {      u8 ecran[LCD_SIZE];      u16 buffer[256+128];      //Calcul des tables           CalcScaling(ecran,buffer);      //Sauvegarde de l'écran      LCD_save(ecran);      //Effacement (obligatoire, la routine dessine l'écran en OU logique)      ClrScr();      //Dessin à l'échelle      Scale(LCD_MEM,ecran,buffer);      //Attente d'une touche      ngetchx(); }
(Je viens de la coder comme ça, j'ai plus trop l'habitude de la TI, et j'ai pas testé au niveau vitesse, mais ça a déjà l'air plutôt rapide )

Ma routine est en asm devait être utilisée dans Sim pour la réduction d'écran de 89, pas pour du zoom (quoi qu'elle pourrait peut-être être adaptée).
Mais la version de Sim l'implémentant plantait pas mal et ne fonctionnait qu'avec les gray de graphlib. Peut-être que je retenterai, mais Sim ne semble pas intéresser assez de monde.

Merci bien quand même, je vais essayer la routine de Brunni.

Ma routine ne fonctionne pas parce que le memset n'est pas situé au bon endroit en fait... // C Source File // Created 11/12/2004; 11:26:12 #include <tigcclib.h> //Types de données plus rapides à écrire %) u8 signifie 8 bits non signé. typedef unsigned char u8; typedef short s16; typedef unsigned short u16; typedef unsigned long u32; //Excusez les pseudo-optimisations merdiques pour la TI, je suis plus habitué à la GBA maintenant ;) void CalcScaling (u8 *ecran, u16 *buffer)               {      u16 i, decal, *tmpBuf;      u16 valeur;      u8 temp;            tmpBuf=buffer;      for (valeur=0;valeur<256;valeur++)                    {           temp=valeur;           decal=12-2;           //Première partie (position paire)           for (i=0;i<8;i+=2)                    {                //Paire                if (temp&128)                     *tmpBuf|=3<<decal;                decal--;                temp<<=1;                //Imaire                if (temp&128)                     *tmpBuf|=1<<decal;                decal-=2;                temp<<=1;           }           tmpBuf++;      }            //A la suite, le numéro de ligne à blitter      tmpBuf=buffer+256;      //0=saut de ligne, 1=ligne identique à la précédente      *tmpBuf++=0;      for (i=1;i<128;i++)                         {           if ((int)((i*100)/128)==(int)(((i-1)*100)/128))                *tmpBuf++=1;           else                *tmpBuf++=0;      } } void Scale (u8 *dst, u8 *src, u16 *buffer)                    {      u16 i, valeur, j, *ligne;            //Je crois que cette construction ne change rien avec celle-ci sur TI:      //for (i=28;i;i-=2)      //Car il n'y a pas de soustraction écrivant directement sur le statut (??) comme subs r0,r0,#1 sur ARM      //A tester en fait      ligne=buffer+256;      for (j=0;j<100;)                    {           //Refaire la même ligne?           if (*ligne++)                src-=30;           else                j++;           for (i=0;i<20;i+=2)                    {                //Je suis obligé de diviser en deux accès 8 bits, même si un accès impair 16 bits aurait été plus optimisé...                valeur=buffer[*src++];                *dst++|=valeur>>4;                //La perte d'informations est volontaire                *dst|=valeur<<4;                valeur=buffer[*src++];                *dst++|=valeur>>8;                *dst++|=valeur;           }           src+=10;      } } // Fonction principale void _main (void) {      u8 ecran[LCD_SIZE];      u16 buffer[256+128];      memset(buffer,0,sizeof(buffer));      //Calcul des tables           CalcScaling(ecran,buffer);      //Sauvegarde de l'écran      LCD_save(ecran);      //Effacement (obligatoire, la routine dessine l'écran en OU logique)      ClrScr();      //Dessin à l'échelle      Scale(LCD_MEM,ecran,buffer);      //Attente d'une touche      ngetchx(); }
Là ça devrait aller Mais t'attends pas à des miracles (autour des 23 fps, pas plus je pense). Faudrait l'implémenter en ASM...

J'ai essayé et c'est pas assez rapide (mais mieux que moi ).
Merci quand même mais je crois que je ne vais pas faire de zoom.

et sinon tu peux faire des sprites/tiles plus gros pour la version 92+/v200, non ?

C'est possible mais ca demande beaucoup de boulot.
Et je sais pas si j'aurais le courage avant la fin de l'année !

Il me semble qu'Arkanoid: Revenge of DOH doit avoir une routine de zoom, mais je ne sais plus dans quel sens elle est (probablement l'autre).

Je pense qu'il faut toujours designer les programmes pour la 89(T), qu'il n'est pas toujours nécessaire de faire des versions spécifiques pour les écrans plus grands des 92+ et V200, et que la façon de faire consistant à zoomer / dézoomer bouffe énormément de puissance pour pas grand chose.

Parles pour toi...

"Je pense qu'"...

Tu penses trop

Il a bien le droit d'avoir un avis, non ?

bobti89 :
J'ai essayé et c'est pas assez rapide (mais mieux que moi ).
Merci quand même mais je crois que je ne vais pas faire de zoom.

Non, c'est juste que ma routine est merdique. C'était simplement une idée comme ça, mais en codant une routine de zoom en ASM et en l'optimisant assez, je pense qu'on peut espérer atteindre 100 FPS (ce qui devrait être suffisant pour ton jeu, non?).

J'ai mis dans ExtGraph (en fait le source y était déjà depuis un certain temps, mais complètement oublié - dans ExtGraph 2.00 Beta 4, il n'est carrément pas utilisable) une routine dans l'autre sens (240 -> 160).
Elle utilise deux tables de 256 valeurs (8 bits) précalculées. Le résultat est visuellement extrêmement moche (quand il y aura ExtGraph 2.00 Beta 5, amusez-vous à appliquer une telle routine sur une sauvegarde de l'écran HOME...). Si j'ajoute ça, c'est parce que certains programmeurs semblent aimer, bien que ce soit moche, que ça ralentisse et que ça prenne une quantité pas négligeable de place (~600 octets). Le prix de la compatibilité...
Dans ce sens (160 -> 240), pour être plus rapide, il faut utiliser une table de 256 valeurs (16 bits) précalculées. Pour répéter les lignes, il faut une copie ASM, déroulée car son coût est négligeable: moins de 10 instructions, c'est à dire deux ou trois ordres de grandeur de moins que ce que coûte la compatibilité on-calc dans un programme...
Le but est de transformer des doublets en triplets (par blocs de 4 doublets). De façon évidente, 00 -> 000 et 11 -> 111; mais que choisiriez-vous entre 01 -> 001 et 10 -> 110, ou 011 et 10 -> 100 (cela a peu d'importance) ?

Pour grav ca serait pas plus rentable de tout simplement faire des sprites plus gros? et de combler l'espace restant par des informations diverses?

./173 > Ben en fait ça dépend du point de l'écran. Peu importe quel modèle tu choisis, il ne sera réellement valide que pour un octet sur 3 ^^ Si tu a déjà fait des tests je serais curieux de voir ce que ça donne par rapport à un redimenionnement classique.
Si je me souviens bien de ce que j'avais trouvé il y a quelques temps, il fallait 3 tables pour un résultat optimal (en qualité, pas forcément en vitesse). Si on prend un redimensionnement de base 16 pixels -> 24 pixels on a ce shéma:

1 01 01 01 01 01 01 01 0
110110110110110110110110

Il y a dans le résultat 3 suites de 8 bits différentes, donc on doit en faire 3 tables (c'est évident que une table 16 bits -> 24 bits prendrait beaucoup trop de place) respectivement de 32, 64 et 64 valeurs. Au final ça en fait même moins que les 256 valeurs (que tu peux réduire à 128 en utilisant not) par contre c'est évidemment plus lent :/

Du 5, 6, 5 (pas 5, 6, 6 qui fait 17 pixels), c'est ce que fait dans l'autre sens la routine 240 -> 160 que j'utilise. As-tu benché ce que ça donne dans ce sens ? Les shifts / rotates sont lents...
Je n'ai pas fait de tests de ma routine, car elle n'est pas codée.
J'avais pensé à réduire la taille des tables de lookup en exploitant une répétition. Ca ralentit un peu, moins de 20% je pense (1 branch + 1 à 3 autres instructions). Si ça n'est pas trop lent d'origine, c'est parfaitement jouable.

Hmm oui je sais (hélas) que c'est lent :/ Je vais aller bencher ça pour voir ^^

J'ai codé en vitesse la routine, le package de test (il ne nécessite en principe pas ExtGraph 2.00 Beta 4) est disponible à http://tict.ticalc.org/downloads/testscale.zip
Des deux combinaisons que j'ai citées dans #172, il est manifeste que les deux conviennent, mais jamais en même temps...
GoldenCrystal, est-ce que tu pourrais mettre en téléchargement d'une façon ou d'une autre ce que tu avais fait ? TIA.

Tiens, je m'aperçois que j'ai oublié les prototypes dans le fichier C. Pas grave, ils y sont dans les fichiers ASM, il suffit de rajouter "extern".

Posts croisés.

Heu je vais la coder avant
Parce que la routine que j'ai sous la main là elle fonctionne par décalages de bits alors... :]