Sprite16 en gray optimisé ? - Page 3

J'ai pas compris, tu préfères attendre les fonctions masquées ou tu peux t'arranger pour faire avec un OR ou un AND, mais pas les deux ?

cela dépend du temps d'attente pour les fonctions maskées
Pour le moment, je peux me contenter de celles de Extgraph... mais, qd tu auras écrit les tiennes, je serai happy de troquer celles de Extgraph contre des fonctions plus performantes

Je serais curieux de voir ta routine de spr32 maitre

PpHd> le début de la guerre de l'optimisation, entre les DIEUX et MAITRES ?

'tention : je n'ai jamais vu les sources de ExtGraph, p-ê ses PutSprite sont-ils plus rapides !
Mais quand je vois ses routines (pourtant optimisées un peu par PpHd) de recopie de buffers qui sont présentées sur le forum, j'imagine que mon petit bébé GRAPHX surpasse le gros ExtGraph

Thibaut> déjà, les fonctions de sprite de Extgraph sont écrites en C...
(au contraire des deux fohnctions que PpHd a arrangé)

La routine de Extgraph en sprite16 est 70% plus lente que celle de Genlib, je crois (ou 80, je sais plus le chiffre exactr que PpHd me disait
Pour le reste... Et bien... celle de sprite16 est la plus rapide => les autres st plus lentes

Arf; ma reponse est pas passe.
Bon je resume : y'a pas de mal a depasser extgraph.

oué, qd on s'y connais ne serait-ce qu'un peu
Mon truc, c'est plus de mettre des foncitons les unes à la suite des autres que de les concevoir

Oui, oui. Mais tu vois qu'avec Extgraph on peut quand meme booster, si on l'utilise bien
(Critique sauvage, desole

merci pour la critique
En fait, j'avais pensé à une telle solution... mais vu que les routines que j'avais de base dans Extgraph ne fonctionnaient qu'avaec un écran entier, je ne pouvais pas les utiliser => j'ai fait autrement...

Pour PpHd et squale92. C'est la dernière version qui date de <ben c'est écrit dans l'en-tête>, y'a pas encore le clipping ni toutes les fonctions que j'envisage. Notez la fonction de grays qui est vide

oué... c beau tout ce code ASM
j'y piges pas gd chose... elles sont pas en niveux de gris ?

GSSpr16And est pas buguee ? (lsr.W #4, d1 / add.w d1,d1 ?)
Pkoi tu decoupes en decalage de 2 word ? Ok c bien pour 32, mais pour 16 c inutile, non ?
L'utilisation d'a7 peut etre perilleuse si une int intervient est qu'elle modifie usp (... ca peut arriver).

Je ne vois nulle part lsr.w #4, d1 / add.w d1,d1

Je fais avec des mots parceque c'est aussi rapide, mais moins chiant !

Pour a7, tu as raison. Tu as une solution ?

Justement ! Il manque le add.w d1,d1 pour aligner l'adresse a l'ecran, non ?
Es-tu sur que c'est aussi rapide ?

J'allais te poser cette question. Par rapport à ExtGraph, ça te semble mieux ou pas ?

Pour le add, tu peux montrer les quelques lignes où il manque, je ne vois pas où c'est !

Et le pb du a7, je suppose que GenLib a un truc efficace pour l'éviter ?

On peut désactiver toutes les interruptions tout simplement. (genlib tourne toujours avec les interruptions désactivées.) Et quelles interruptions modifient USP? (Je ne vois pas ce que les interruptions viendraient chercher à USP, mais il y a des trucs bizarres dans AMS.)

Dans Krypton, j'ai supprimé toutes les interruptions :
AUTO_INT_1 et 5 pour l'utilisation de _rowread
AUTO_INT_6 parce qu'il posait pb qd un Kernel était installé
les autres parce qu'ils ne me servaient pas (le link, par exemple)

>Thib: Pour le 16, je ne sais pas. Pour le 32, oui
Et le pb d'usp n'intervient essentiellement pour des surcouches d'ams.

Et par curiosité, par rapport à Genlib ?

Je sais pas.

OK.

En fait il sait : mes routines sont potentiellement meilleures, elles le deviennent effectivement en déroulant les boucles et remplaçant les calculs d'offsets par la lecture d'une table précalculée ?

Blagues mises à part, je suis content de voir que j'ai dépassé un plus "grand" que moi pour les sprites 32 bits


J'ai découvert un petit bug dans les PutSprite 8 et 16 : je sauvegarde sur la pile le LSW de d5 alors que j'y écris avec moveq. C'est corrigé.

squale92 : bientôt je posterai le support des masques. C'est pas long à faire

[edit]Edité par Thibaut le 22-11-2001 à 16:57:59[/edit]

OK...

Tu es bloqué sur ce mot depuis hier soir

Au fait, pour répondre à ta question plus haut : oui c'est en NDG ! Tu vois que le premier argument doit être l'adresse du plane où afficher le sprite.

c'est en gray ?
Vu qu'il y a un seul plane, je supose qu'il faut afficher une fois sur le plan LIGHT et un autre sur le DARK, non ?

ben oui !

Ca marche comment avec ExtGraph ?

Bon quelques petites remarques:
tu ne sauvgarde pas les registres? (putpxl)
putpxl et toutes tes routines peuvent etre optimisée par un table.. mais c'est comprehensible que l'on ne veuille pas perde 128 octets

Sinon t'es routine sont peut etre rapide, mais je les considere comme quasiment inefficace; en effet tout tes sprites devront etre enregistre au format recommendée par les fonctions, la solution: refaire une fonction qui redimentionne les sprites en ram... et qui retourne une adresse du sprite... mais il me semble bien azur est un language haut niveau? donc je trouve cela un peu ridicule
pour resoudre ton probleme, il suffit de faire un demi deroulement de la boucle...
genre en gros:
if(taille_sprite&1) { affiche une ligne de ton sprite... }
taille_sprite>>=1;
while (taille_sprite) { affiche deux lignes de ton sprite a chaque fois }

bon perso sur un sprite de taille 16 ca vaut le coup... a toi de voir..

>> tu ne sauvgarde pas les registres? (putpxl)
Tu ne connais pas les conventions du C...

>> toutes tes routines peuvent etre optimisée par un table
Je le sais... lit le post 83 un peu plus haut.

>> pour resoudre ton probleme
Quel pb ??

>tout tes sprites devront etre enregistre au format recommendée par les fonctions,
A bon ?
Et sinon tu files une description du format des sprites a l'afficheur de sprites ?
Y'a toujours un format !