Optimisation vitesse - Page 5

ton gain de place serait de ne pas écrire le lea.l 30(a0),a0 ?
OK, mais ça impliquerait une fonction de recopie de plans spéciale -> perte de place...

and.l (a1)+,(a0) or.l (a1)+,(a0)+ ; J'utilise ton magnifique format de GPlan ! dbf d2,Loop

En mode masqué : on suppose que le sprite est entrelacé (une ligne masque, une ligne sprite) :Loop:
 

En fait, si ton GPlan est un buffer pour les niveaux de gris, ce que j'ai dit au-dessus le concernant est faux. J'en conviens

Je me pose une question, si vous créer votre propre gestion de niveaux de gris avec votre propre format, vous pourrais gagner énormément en vitesse? Pour l'occupation en mémoire je sais pas mais en vitesse ça doit être assez énorme?

Bah faudrait y réfléchir...

FZ reviens

trust doit sûrement être en train d'écrire ses fonctions plus rapides et plus petites que celles d'ExtGraph sans préshifting. Il doit vraiment être à fond dedans parce qu'il ne pourrit plus le topic

non je suis en train de me lancé dans une fonction de gray qui prend bcp moins d'archive que celle de tigcc
et il serait plu facile de poster si je netait pas kick et que je devais me deco toutes les 30 secondes

Bah moi j'attends tes fonctions.
T'es toujours à dire que tu peux faire mieux, mais tu ne le fais jamais !
La preuve, ta fonction de nvg, ça fait plusieurs mois que tu en parles. Et toujours rien...
Et puis c'est assez difficile de faire plus petit que TIGCC sans perdre en vitesse, et en ayant des beaux niveaux.

T'es toujours à dire que tu peux faire mieux, mais tu ne le fais jamais !

et Xlib elle est pas sortie

1 je te rappelle que j'ai eut 2 ans de prepa tout comme pollux etc.. donc ca rallentit le dev et que Xlib a ete dev en urgence..
2 la je suis encore en stage, et je programme plus de 8h par jour alors le soir j'ai pas que ca a foutre (surtout que je me suis mis a linux et que je doit configurer fluxbox), et quand je post sur le frm c'est que je suis en train de faire une extraction de données sur le serv!

Tu les feras quand alors les fonctions ? (Histoire de montrer que ce que tu dis est bien fondé)

bein quand j'aurais le temps.. je verais

Question stupide... Y'a quoi comme jeux au graphismes assez poussés utilisant X?

en développement, il y a KII
(la v1 affichait pas mal de graphismes... la v2 en affiche autant, les améliorations etant portées ailleurs dans le moteur)

trust
: au fait la taille de votre lib archive montre bien que niveau place c'est tres gourmand!

Pas du tout. Déjà, la taille d'un fichier .a dépasse de loin la taille de toutes ses fonctions réunies. Et puis, un jeu utilisera peut-être un vingtième de cette archive. Probablement encore moins. Et seul ce qu'il utilise se retrouvera dans l'exécutable.

trust :
je vois pas en quoi c'est un bon algo sachant qu'un bon algo est bon dans tout les cas. or comme je l'ai deja expliquer, on fait un scroll bidirectionnel (ne parlons pas de tri avec etgraphlib) on se positionne dans la condition des deux plan au shift le moins rapiet et c'est sur cette position ue l'on fixe le fps du jeu.;

Solution simple: On ne fixe pas le fps.

sinon le jeu SACADE

Non, le jeu qui saccade, c'est le jeu où tu fixes un fps arbitraire et insuffisant alors que les routines peuvent aller plus vite.

godzil
:

Je ne vois pas de quoi tu parles, précise ! (encore des paroles en l'air ?)

il faisait reférence a un cas ou kevin refusait d'implémenter un truc pasqu'il le trouvait sale alors que sa lui aurait fait gagner pas mal de place

Pas parce que je le trouvais sale, mais parce que c'était sale.
Si c'est bien des routines de fichiers de Thibaut que tu parles, ces routines écrivaient volontairement en dehors d'un buffer. D'accord, ils le restauraient après, mais quand-même! Si la chaîne est en ROM, ça ne va pas marcher du tout... Bref, c'était une routine qui ne fonctionnait pas. Évidemment que je la rejette. Et comme Thibaut a refusé de corriger ce problème, ben, je n'ai pas pris ses routines. J'ai autre chose à faire que de corriger les routines boguées qu'on essaye de nous soumettre, quand il y a des routines existantes qui fonctionnent très bien.

trust
: ca s'adresse a KK il critique un choix de Xlib et cette critique je la juge infondée.

Je critique un "choix" parce que ce n'est pas un choix, c'est un refus de réaliser une routine utile.

Le mode XOR et AND servent strictement a rien dans un jeu donc pour une lib graphique pour les apps comme extgraphlib ya pa de probleme. Quand je parle de jeux, je parle de jeux graphiques assez poussé.

Déjà, ExtGraph n'est pas "une lib graphique pour les apps"! C'est une librairie graphique pour tout: applications, jeux, ...
Et il y a des jeux qui ont besoin de XOR ou AND. Ça permet d'aller plus vite qu'avec des sprites masqués. Regarde Phoenix par exemple, il affiche tout en XOR.

nEUrOO :
jackiechan: EXTgraph n'a été jusqu'à présent une librairie graphique pour faire de vrais jeux (à graphismes poussés) c'est ce que dit TiMad et que donc, il ne la considère pas comme une librairie graphique nécessitant autre chose que les modes XOR et AND.

ExtGraph a toujours été une librairie graphique pour tout, y compris ce que tu appelles les "vrais jeux"!

trust :
je vois pas en quoi c'est un bon algo sachant qu'un bon algo est bon dans tout les cas.
or comme je l'ai deja expliquer, on fait un scroll bidirectionnel (ne parlons pas de tri avec etgraphlib) on se positionne dans la condition des deux plan au shift le moins rapiet et c'est sur cette position ue l'on fixe le fps du jeu.;

Solution simple: On ne fixe pas le fps.

bein oui bien sur.. et ca sacade un mort.. mais reflechi avant de poster!

Non, le jeu qui saccade, c'est le jeu où tu fixes un fps arbitraire et insuffisant alors que les routines peuvent aller plus vite.

encore une fois reflchis, si le fps est fixé la fonction meme si elle tourne plus vite ca change rien c'est que quand elle tourne plus lentemant que ca change.. piuoff

Je critique un "choix" parce que ce n'est pas un choix, c'est un refus de réaliser une routine utile.

un refus a l'origine c'est un choix..

ExtGraph a toujours été une librairie graphique pour tout, y compris ce que tu appelles les "vrais jeux"!

le bouquet final, merci de ce poste plein d'ironie KK

pt1 mais vous etes tous aussi bornes les uns que les autres... kevin, jackiechan, TiMad...

et heu kevin, aucune "attaque personnelle", mais vu les nombreux et divers exemples que tu as pu nous donner de ton extraordinaire expertise dans le domaine du jeu et de la prog graphique performante, a mon avis t'es pas le mieux place pour en parler...
j'adore ta derniere phrase au fait

On l'aime tous sBibi

faut !smash tout ceux qui l'aime pas

Tiens, je viens d'essayer et je ne trouve pas que ça saccade, le fait que nos routines n'aient pas 2 boucles différentes selon le sfifting.
Et pourtant dans mon prog il n'y a que ça. Il n'y a aucun calcul autour qui ralentirait le tout et qui diminuerait ces effets.
À la limite, on peut distinguer des petits ralentissements éventuellement, mais il faut vraiment faire très attention, je me demande si ce n'est pas simplement psychologique.

jackiechan
: Tiens, je viens d'essayer et je ne trouve pas que ça saccade, le fait que nos routines n'aient pas 2 boucles différentes selon le sfifting.

Et tu utilises une boucle sans timer (donc fps variable)?
Si c'est bien ça, alors on voit enfin que ce que dit JackosKing=trust est totalement absurde...

1 si tu n'as pas repondu a mon message precedent c'est que tu ne pouvais pas contredire ce qui est dit donc je doute que tu puisses juger n'importe quoi.
2 si tu ne voit pas de difference, c'est peut etre parce que c'est ta routine de gray qui doit je pense imposer le fps, (c'ad que la routine d'affichage a une frequence plus rapide que celle des grays ?? c'est possible a verifier..
3 si tu vois pas de difference bein c'est comme tu veras pas de difference entre mul #30,d0 etc.. faut pas deconner.
4 je veux bien essayer le programme on calc.
5 ya combien de plans?

6 est ce que vous voyez la diff entre la version C et asm?

ha j'oublié, fetes un srcoll vertical (de haut en bas) avec possibilité de modifier X, et la vous verez une dif

Oui, ma boucle ne comporte pas de timer sinon le test ne serait pas valable.

mon dernier poste est le plus important ^^

Entre le cas le plus défavorable et le cas le plus favorable, il y a quand même (approximativement) entre 15% et 20% d'écart.
Mais l'essentiel est que ça ne fasse pas de saccades, ce qui est le cas, je trouve.

passe moi ta lib 1 sprite gray je te prouve le contraire en 10 minutes

trust
:1 si tu n'as pas repondu a mon message precedent c'est que tu ne pouvais pas contredire ce qui est dit donc je doute que tu puisses juger n'importe quoi.

Si je n'ai pas répondu à ton message précédent, c'est parce qu'il était tellement n'importe quoi qu'il ne méritait pas de réponse.
Mais puisque tu en veux absolument une, la voilà:

trust
:

trust :
je vois pas en quoi c'est un bon algo sachant qu'un bon algo est bon dans tout les cas. or comme je l'ai deja expliquer, on fait un scroll bidirectionnel (ne parlons pas de tri avec etgraphlib) on se positionne dans la condition des deux plan au shift le moins rapiet et c'est sur cette position ue l'on fixe le fps du jeu.;

Solution simple: On ne fixe pas le fps.

bein oui bien sur.. et ca sacade un mort.. mais reflechi avant de poster!

C'est toi qui n'as pas réfléchi, au point de ne pas lire ou ne pas comprendre le paragraphe qui suit. Et cf. aussi le message ./138.

Non, le jeu qui saccade, c'est le jeu où tu fixes un fps arbitraire et insuffisant alors que les routines peuvent aller plus vite.

encore une fois reflchis, si le fps est fixé la fonction meme si elle tourne plus vite ca change rien c'est que quand elle tourne plus lentemant que ca change..

Cette réponse est absolument n'importe quoi! "si le fps est fixé"... Justement, je te parle du cas où le fps n'est pas fixé, donc si les routines peuvent aller plus vite que ce que tu veux fixer comme fps, le fps est plus élevé qu'avec ton fps fixé.
Je réexplique:
* fps fixé => fps limité par le pire des cas => fps plus faible => saccade
* fpr variable => fps qui tourne autour du cas moyen => fps plus élevé => pas de saccade

Je critique un "choix" parce que ce n'est pas un choix, c'est un refus de réaliser une routine utile.

un refus a l'origine c'est un choix..

Mais un choix idiot.

ExtGraph a toujours été une librairie graphique pour tout, y compris ce que tu appelles les "vrais jeux"!

le bouquet final, merci de ce poste plein d'ironie KK

Ce n'est pas parce que des râleurs comme toi ne veulent pas utiliser ExtGraph pour des jeux que ce n'est pas prévu pour.

2 si tu ne voit pas de difference, c'est peut etre parce que c'est ta routine de gray qui doit je pense imposer le fps, (c'ad que la routine d'affichage a une frequence plus rapide que celle des grays ?? c'est possible a verifier..

Non, c'est parce que la différence de fps ne se fait pas remarquer.
Avoue d'avoir tort au lieu d'aller chercher des explications fantaisistes.

3 si tu vois pas de difference bein c'est comme tu veras pas de difference entre mul #30,d0 etc.. faut pas deconner.

1. Comparaison absurde.
2. C'est ce que GCC 3.3.1-tigcc-pre18 donne en mode -Os si on multiplie par 30 et ça ne dérange pas du tout pour Backgammon et TI-Chess.

4 je veux bien essayer le programme on calc.

Et tu crois qu'on fait confiance à tes "résultats"?

jackiechan
: Oui, ma boucle ne comporte pas de timer sinon le test ne serait pas valable.

Et voilà. Donc trust, la ferme!

heu si je raisone comme toi, un fps non fixé <=> a un fps moyen..
encore une fois mort de rire, non mais relit toi et reflechis..

heu pour trust la ferme, j'ai demandé a ce que je vous prouve moi meme la lenteur de votre lib dans certaines conditions! Une fois que j'aurai eut cette oportunité, et bien tu poura juger..

au fait backgamin n'est pas pour moi un jeu graphiquement evolué..

trust> j'ai effectivement constaté des différences de fps entre le cas le plus défavorable et le cas le plus favorable, comme je l'ai indiqué plus haut. Mais le fps moyen ne se compte pas à partir du cas le plus défavorable.