fonction Sprite32 version clipée ? - Page 2

#trihum#

deux images, superposees l'une sur l'autre, de 32 de large, qui tilent et qui scrollent en largeur? (eventuellement pas a la meme vitesse?)

jme souviens plus si le 68k a une instruction pour faire des rotations de bits, mais si oui, pour chaque ligne de 32 pixels de ton sprite, en supposant 1 bit par pixel, tu le loade dans un registre, tu le rotate left ou right de (backgroundPositionInPixels & 0x1F), suivant le sens de scrolling, et tu blitte cette valeur 32 bits betement sur toute la largeur de l'ecran, avant de passer a la ligne d'apres ?
(inserer ici une combinaison bitwise custom des deux uint32 correspondant aux deux backgrounds respectifs, avant de le blitter 5 fois a la suite pour remplir la ligne de l'ecran)

mais bon ca doit pas etre ca que tu cherche a faire, et j'ai pas du comprendre ta question, pke c'est un peu bidon, comme reponse

edit: ah ouais, y a bien des instructions ROR et ROL

Un 'tit dessin vaut mieux qu'un long discours



Voila, en gros je souhaite tapisser le fond d'un backgound composé de 2 sprites ( 1 et 2 sur l'image).
Seulement voila, l'idée que, par exemple, lorsque je scrolle vers la droite, le sprite de gauche qui disparaît de l’écran se retrouve du coté droit (A, par exemple, viendrait se coller a H)
et vis versa lorsque je scrolle du coté gauche


j’espère m’être bien expliqué, c'est pas forcement facile a comprendre


merci

ah. ok.
bon ben pas de rotations de bits alors..
pourquoi tu fais pas juste qqch comme:

    u32    *sprite0 = ...;
    u32    *sprite1 = ...;
    u32    scrollInPixels = ...;
    u32    lshift = scrollInPixels & 0x1F;
    u32    rshift = 32 - lshift;

    assert(spriteHeight <= screenHeight);
    while (y < spriteHeight)
    {
        u32    lineSprite0 = sprite0[y];
        u32    lineSprite1 = sprite1[y];

        u32    line0 = (lineSprite0 << lshift) | (lineSprite1 >> rshift);
        u32    line1 = (lineSprite1 << lshift) | (lineSprite0 >> rshift);

        // en supposant un ecran de 160 pixels de large
        static_assert(screenWidth / 32 == 5);
        screen[0] = line0;
        screen[1] = line1;
        screen[2] = line0;
        screen[3] = line1;
        screen[4] = line0;
        screen += 5;

        y++;
    }

?

EDIT: par curiosite, avec des rotations de bits, ca donnerait:

    u32    lmask = 0xFFFFFFFF << shift;
    u32    rmask = ~maskl;

    assert(spriteHeight <= screenHeight);
    while (y < spriteHeight)
    {
        u32    lineSprite0 = sprite0[y] <<< shift;
        u32    lineSprite1 = sprite1[y] <<< shift;

        u32    line0 = (lineSprite0 & lmask) | (lineSprite1 & rmask);
        u32    line1 = (lineSprite1 & lmask) | (lineSprite0 & rmask);

bon, pas sur que ca soit fondamentalement mieux par contre... c'est meme probablement moins efficace.

Certainement moins, en fait ça dépend du pas de son scroll, un scroll d'au moins 8 pixels serait idéal pour ne pas plomber les perfs.

Cool

Je m'en n'allons tester tout ca alors

merci bien


Sinon l’écran est vraiment pas top ( ou alors c'est l’affichage des NVG ???) lorsque mon perso de balade , on le distincte vraiment moins bien
J'me tâte sur trois solutions:

-faire en sorte que le perso soit en permanence centré a l’écran, mais de toute façon les ennemis bougeront eux, et le problème sera toujours la ....
-retirer le background ou bien ne l'afficher qu' avec du blanc ou gris clair.... histoire d’améliorer la visibilité
-tester carrement la coversion en noir et blanc du jeu (seulement si le probleme vient des NVG ....)





Le sujet du topic a plus rien a voir, la mais m'en fout, c'est l'mien

edit: manquait un S

Commence par synchroniser ton affichage avec l'écran. Je ne sais pas si Extgraph fournit ce genre de fonctions. GCC4TI en fournit.
Sinon, c'st automatique avec Genlib (dont tout le monde a pu voir qu'une nouvelle version est sortie tout récemment) : t3/?id=20

Extrait de la documentation :

4.2 C

A C example is even shorter:

#include <genlib.h>
// The entry point is gl_main.
void gl_main()
{
...
}
That's all! It is far easier in C since you have the ability to use gl_main, instead of doing the job yourself! You can define USE_KERNEL to compile in kernel format (shorter and more compatible with newer calculator since all the hacks are concentrated in the kernel). If you don't define the target, genlib will compile for all the calculators. You mustn't define SAVE_SCREEN of NO_EXIT_SUPPORT! And you don't need to include tigcclib since genlib.h do it for you.

Voilà, tu écris gl_main() dans ton programme à la place de main(), et tout roule, cette libraire génial et over surpuissante te fait tout.


(!kbkk)

Sympa c'te lib

vais tester tout ca


J'ai regardé la doc, un peu, je voudrais juste une precision :

gl_put_big_sprite() affiche bien un sprite avec la transparence (le blanc?) avec en plus un halo blanc , c'est ca ?
et niveau performance, c'est plus speed qu'un sprite32+mask ?



merci bien en tout cas

Je ne sais pas si tu lis l'assembleur, mais Genlib est une bête de performance, un vrai monstre. C'est PpHd qui l'a écrite, c'est aussi l'auteur de SMA, Chrono Fantasy, PreOS, PedroM et bien d'autres encore. Donc niveau perf tu feras pas mieux. A noter que ExtGraph est aussi extrêmement performante. Ce sont les deux meilleures libs sur TI68k.

sawamura (./37) :
gl_put_big_sprite() affiche bien un sprite avec la transparence (le blanc?) avec en plus un halo blanc , c'est ca ?

C'est tout à fait ça.

Le problème, c'est que genlib t'oblige à utiliser un kernel.

ouais mais les perfs blastent

Ce sont [ExtGraph et Genlib] les deux meilleures libs sur TI68k.

J'ajouterai que ce sont aussi les deux seules librairies vraiment utilisables en 2010, car elles sont toujours maintenues (en particulier, ce sont les deux seuls libs vraiment compatibles avec la 89T)

Kevin Kofler (./39) :
Le problème, c'est que genlib t'oblige à utiliser un kernel.

Fichtre !

Lionel Debroux (./41) :

Ce sont [ExtGraph et Genlib] les deux meilleures libs sur TI68k.

J'ajouterai que ce sont aussi les deux seules librairies vraiment utilisables en 2010, car elles sont toujours maintenues (en particulier, ce sont les deux seuls libs vraiment compatibles avec la 89T)

Il y a aussi TIGCCLIB, hein. (Mais effectivement, les routines de sprites ne sont pas clippées.)

Serait-il possible de limiter le HS dans ce topic (./39, ./40, ./42, ./43) ? Merci.

coucou

Bon, quelqu'un aurait-il sous le coude un convertiseur "bmp to BGS" ???

Apres quelques recherches, j'ai vu qu'il existait un "pgm2bgs", mais mon pote google est pas motivé pour me trouver un lien ok....



merci bien

Sur le site de Ximoon (un des modérateurs adorés de cette section), site sis ici (hihihi) : http://membres.multimania.fr/ximoon/ , tu prends le programme DoAnyBgs, il fais ce que tu veux.

Merci bien ca marche nickel


Cependant je viens de m'apercevoir d'un truc bizarre ??
Je commence a avoir beaucoup de sprites, et je les ai donc stocké dans un .h , seulement en incluant le fichier au projet ( et a main) ,
GCC4TI a ete incapable de le touver ("no such file or directory")
J'ai lancé GCC4TI en mode compatibilité WinXP et la aucun probleme, aussi bien a la compil' qu'au test sur calc....

un probleme de compatibilité avec W7?


edit: la "compatibibilité" ca existe pas, ou alors on m'aurait menti...

Un problème de droit a priori. T'es en administrateur sous ta machine ? Ce problème est connu sour Vista et Seven, il faut désactiver l'UAC et a priori, ça passe.

Un problème avec l'UAC qui ne se manifeste que sur certaines machines, ce qui veut dire que l'UAC n'est probablement pas le seul responsable du problème. Peut-être y a-t-il la suite de ""sécurité"", peut-être encore autre chose.

C'est pas lié au fait que l'IDE essaie de copier temporairement les fichiers "quelque part" au moment de la compilation, de façon à reproduire l'arborescence de ses dossiers virtuels ? Ça fait longtemps que je n'ai pas utilisé TIGCC/GCC4Ti mais il me semblait avoir retenu quelque chose dans le genre, je confonds peut-être.

(si c'est ça et que le fameux dossier "temporaire" est codé en dur sans passer par les variables d'environnement de Windows, il y a effectivement de grandes chances pour que l'UAC fasse la tête)

C'est pas lié au fait que l'IDE essaie de copier temporairement les fichiers "quelque part" au moment de la compilation, de façon à reproduire l'arborescence de ses dossiers virtuels ?

Oui, c'est lié, si ma mémoire est bonne.

si c'est ça et que le fameux dossier "temporaire" est codé en dur sans passer par les variables d'environnement de Windows

Non, ou du moins, pas partout: dans mainunit.pas, accessible à partir de http://trac.godzil.net/gcc4ti/browser/trunk/tigcc/ide , on trouve

                GetTempPath (SizeOf (TempDir), TempDir);
                Temp := AnsiString (TempDir);
                if (Length (Temp) <= 0) or (not DirExists (Temp)) then begin
                        GetEnvironmentVariable ('TMP', TempDir, SizeOf (TempDir));
                        Temp := AnsiString (TempDir);
                end;
                if (Length (Temp) <= 0) or (not DirExists (Temp)) then begin
                        GetEnvironmentVariable ('TEMP', TempDir, SizeOf (TempDir));
                        Temp := AnsiString (TempDir);
                end;
                if (Length (Temp) <= 0) or (Length (Temp) > 30) or (Pos (' ', Temp) > 0) or (Pos ('TEMP', UpperCase (Temp)) <= 0) then begin
                        GetWindowsDirectory (TempDir, SizeOf (TempDir));
                        Temp := WithBackslash (AnsiString (TempDir)) + 'TEMP\';
                        if not DirExists (Temp) then try
                                MkDir (Temp);
                        except end;
                end;
                if (Length (Temp) <= 0) or (Length (Temp) > 30) or (Pos (' ', Temp) > 0) then begin
                        Temp := 'C:\TEMP\';
                        if not DirExists (Temp) then try
                                MkDir (Temp);
                        except end;
                end;
                Temp := WithBackslash (Temp) + IntToHex (GetCurrentProcessID, 8) + '\';
                if not DirExists (Temp) then try
                        MkDir (Temp);
                except end;

( http://trac.godzil.net/gcc4ti/browser/trunk/tigcc/ide )

C'est étrange en effet, il y a plutôt trop de précautions que pas assez dans ce bout de code, ça pourrait être intéressant de regarder le log de l'UAC pour voir précisément quelle est opération qui demande une levée des restrictions.

Le problème ne peut pas venir de cette curieuse limite à 30 caractères ?
Je ne sais pas si le dossier temporaire du système va se cacher dans le dossier de l'utilisateur, mais si c'est le cas, le chemin est facilement plus long...

                if (Length (Temp) <= 0) or (Length (Temp) > 30) or (Pos (' ', Temp) > 0) then begin 
                        Temp := 'C:\TEMP\'; 
                        if not DirExists (Temp) then try 
                                MkDir (Temp); 
                        except end; 
                end; 

et puis la création du répertoire temp en dur, c'est pas très élégant (ni très fiable je pense)

C'est sûr, mais ayant loupé le test sur la longueur, je pensais que ce cas ne serait jamais testé. C'est curieux d'avoir ajouté cette condition en effet, d'autant plus que sur des Windows récents, ça a toutes les chances de se produire :/ (C:\Documents and Settings\<login>\Local Settings\Temp)

Ça doit effectivement être ça, le problème, chapeau à RHJPP!

Je pense que la raison de ce test, c'est d'éviter que les lignes de commande pour le compilateur dépassent la longueur maximale. Mais 30 doit être insuffisant comme longueur à utiliser.

Un chemin …\Temp aussi long, c'est vraiment mal conçu! Vive "/tmp"!

Et ça doit déjà être ce bloc:

                if (Length (Temp) <= 0) or (Length (Temp) > 30) or (Pos (' ', Temp) > 0) or (Pos ('TEMP', UpperCase (Temp)) <= 0) then begin 
                        GetWindowsDirectory (TempDir, SizeOf (TempDir)); 
                        Temp := WithBackslash (AnsiString (TempDir)) + 'TEMP\'; 
                        if not DirExists (Temp) then try 
                                MkDir (Temp); 
                        except end; 
                end;

qui est activé et cause probablement le problème avec l'UAC (%WINDIR%\Temp\ doit être protégé).

Kevin Kofler (./56) :
Je pense que la raison de ce test, c'est d'éviter que les lignes de commande pour le compilateur dépassent la longueur maximale. Mais 30 doit être insuffisant comme longueur à utiliser.

En effet, MAX_PATH est défini à 260 caractères donc tu risques de heurter cette limite assez facilement si un projet contient une arborescence profonde…
Mais c'est quand même assez improbable, et on peut passer outre cette limitation d'un autre temps (conservée pour des raisons de compatibilité ) en utilisant les chemins UNC… (Ce qui à priori ne poserait pas le moindre problème ici)

Le problème n'est pas MAX_PATH, mais la longueur totale de la ligne de commande passée à gcc.exe etc.

Tu sais que tu as le droit de définir le répertoire en cours comme sous Linux ? Et il me semble que gcc arrive à fonctionner avec les chemins relatifs
Mais bon, c'est vrai qu'il y a peut-être probablement des bugs liés à la constante MAX_PATH à l'intérieur de gcc… :]