Annonces Google
Serveur IRC
Serveur : irc.portlane.se
Canal : #AmigaNG
Activité du Site

Pages vues depuis 25/07/2007 : 24 887 379

  • Nb. de membres 186
  • Nb. d'articles 1 269
  • Nb. de forums 19
  • Nb. de sujets 20
  • Nb. de critiques 24

Top 10  Statistiques

Index du forum »»  Création-Développement »» Vitesse d'affichage

Vitesse d'affichage#2183

6Contributeur(s)
artblinkzzd10hsinisrusYesCopAmiDARKthellier
3 Modérateur(s)
K-LElwoodcorto
artblink artblinkicon_post
Salut,

Il y a un résultat en programmation que je ne comprend pas.

J'ai repris le code depuis peu et j'ai refait des routines Gfx (scroll/zoom/rotation/etc..) et voici le fonctionnement "normal" d'un code pour afficher des modifications d'écrans:

Partons sur un scroll horizontale classique pas dur a faire

A la base, pour faire un scroll on utilise un écran plus grand que l'écran d'affichage afin d'éviter lors de la mise à jour de l'écran que les parties ajouter pour le scroll se voient (affichage du scroll avec des morceaux de tiles)

Les tiles sont des carrés ou rectangle par exemple de 64x64 pixels qui contient un bout d'image d'une banque d'images qui feront office de fond d'écran

Si on part sur un écran de 640*480, il faudra ouvrir ajouter des tiles avant 0 et après 640, on part du principe que l'on peut faire aller le scroll de droite à gauche et inversement.

Si j'affiche directement les tiles avec un double buffer en hard par exemple, c'est rapide, donc j'affiche le résultat du traitement directement, MAIS, si par contre, je créé une image de -64 à 640+64 vierge, que je mets le résultats des déplacements des tiles dans cette image et qu'ensuite j'affiche cette image avec un double buffer en hard, j'ai un gain de vitesse d'environ 30%!!!!!

Quelqu'un peu m'expliquer comment cela ce fait? c'est juste pour comprendre.

Normalement, afficher directement le résultat devrait être plus rapide que d'utiliser une bidouille surtout qu'a la base, le double buffer permet de switcher entre l'écran créé et l'écran afficher, j'ajoute un "écran" intermédiaire en plus, donc je switch 2 écrans mais entre 2 je créé une image qui sera afficher.... Bizarre

Merci les gens
zzd10h zzd10hicon_post
C'est le GTB qui doit faire un overflow mais comme c'est asymptomatique tu ne le perçois pas. C'est d'autant plus vicieux qu'il peut s'agir d'un processus stochastique.

Bref, c'est chaud !
...
...
...
...
Bon à part ça, je n'ai rien compris à la question 
artblink artblinkicon_post
BLAIREAU lol


J'recominche pour l'caillin

Double buffer = 2 écrans qui switch 
Les icones, ou tiles avec sprites etc... sont afficher au fur et a mesure sur un écran cacher, une fois l'écran caché terminé, on flip avec un autre écran si celui-ci est terminé. Si ça rame c'est parceque l'écran derrière ou caché n'est pas encore terminé


Ma technique = Double buffer,voir au dessus mais voila au lieu d'afficher mes icones/tiles/sprite/etc sur l'écran caché, je construit mon image dans une image (mémoire) et une fois que l'image est terminé, je l'affiche dans l'écran caché et je le flip et la, c'est LARGEMENT plus rapide

Ma technique est plus rapide... porker? 

Pigé trou d'balle? 

                      
           
                   
           
                   
                       
                              
zzd10h zzd10hicon_post
Ah, bien ton MDR en smileys. 
Allez, je laisse les pros t'embêter !
artblink artblinkicon_post
En écrivant je crois que j'ai compris...

Le double Buffer est celui d'hollywood (d'origine)

Est-ce que ce ne serait pas du fait, que le double buffer d'hollywood est en fait 2 vrais écran qui flip ?

Alors que moi, je construit une image SANS l'afficher.

La vitesse plus élevé serait donc le fait que je n'affiche pas des morceaux pour créer directement une image mais une image complète...

C'est important de savoir pourquoi quand on trouve sur un coup de bol ;-)
sinisrus sinisrusicon_post
c'est cool si tu as compris mais ça me semble aussi la raison si tu passe directement par la mêmoire puis affichage.

plutôt que écran caché (avec utilisation de la mémoire quand même)

Aller maintenant que tu as ta réponse va bossé ;-)
--
Coin coin... amitheme.amiga-ng.org
Sam460 1,15Ghz - OS4.1FE - Radeon Saphir HD7750 R7 250E - 2Go de ram
YesCop YesCopicon_post
Si j'ai bien compris le problème car je suis encore plus bête que zz,
tu as trouvé la solution.

Si tu utilises le blitter ou la composition (hard) , la différence de temps entre copier un tile ou une image entière est minime.

Ainsi, si tu veux afficher trois tiles séparément, tu feras trois appels au blitter alors que copier trois tiles dans une mémoire et afficher ensuite, cela fait un seul appel au blitter.

Evidemment, si tu as que quelques tiles, je ne pense que le gain soit important mais si tu as 10000 objets...

Moralité:
1 écran, 1 mémoire, on travaille sur la mémoire et on la copie à l'écran.

Sans oublier que tu économiseras de la mémoire car utiliser deux écrans coûte cher.

Sam Flex 800 Mhz Amiga OS4.1 FE
artblink artblinkicon_post
Ok, mais je pense qu'a la base c'est la fonction BeginDoubleBuffer() du langage Hollywood qui est mal écrite.
Je pense aussi que l'option hardware=True ce qui fait BeginDoubleBuffer(hardware=True) n'est juste qu'une optimisation sur l'utilisation de la mémoire mais 2 écrans physique sont toujours ouvert.

Donc, la création de l'écran se fait en directe même si celui-ci est caché.

A mon avis la commande Createbrush() d'hollywood travail directement avec la mémoire et n'ouvre pas un écran physique caché pour créer une tiles ou brush.

Donc, en créant une brush ou tile de la taille de l'écran depuis la mémoire et non d'un écran caché, le programme mouline plus vite du fait qu'il ne demande pas à la carte gfx de travailler, par contre, le microprocesseur doit morfler, a mon avis, avec cette technique, je détourne la lenteur du moteur 2D d'hollywood mais aucune carte GFX n'est exploiter, ça doit dépendre de la vitesse du microprocesseur.

Tant qu'andreas n'exploitera pas les drivers AOS ou que les drivers AOS pour les cartes GFX ne seront pas optimiser, je pense que je serais limiter sur la 2D (pas encore tester à fond la 3D)

Bon, on peut pas tout avoir, la simplicité du code et la vitesse... ;-)

Merci Yescop, je pige mieux ;-)

 
AmiDARK AmiDARKicon_post
Citation: artblink  .... A mon avis la commande Createbrush() d'hollywood travail directement avec la mémoire et n'ouvre pas un écran physique caché pour créer une tiles ou brush....
Peut-être surtout que la commande Createbrush() n'utilise pas les mêmes types de mémoire qu'un écran qui lui possède des restrictions spécifiques.. Car ta brush n'est pas prévue pour être "displayable" ...
Cela change beaucoup de choses ... J'avais ce même genre de trucs *bizarres* avec DarkBASIC v1 à l'époque où :
Utiliser un 2nd écran "non displayable", y tracer tout dessus, et copier le tout sur l'écran visible.
Etait environ 100x plus rapide que :
Tout tracer sur le double buffer de l'écran visible et switcher les buffers.

artblink artblinkicon_post
Ah!

Avoue que c'est tout de même étrange cette histoire car on fait un écran, ou plutôt on affiche, trace, déplace des objets sur un écran caché, on peut partir du principe que quelque chose de non affiché est rapide, est en fait il en ai rien. C'est pas parceque on ne voit pas que c'est plus rapide.

En fait tout est une question de déplacement de donnée avec les mémoire les plus rapides

La puce gfx de nos miga (Ng et autres) étant juste là pour afficher un résultat

Très intéressant tous ça, ça aide a l'optimisation

Mais les programmes optimiser aujourd'hui en fonction de nos drivers actuel ne sont et seront jamais optimisé ;-)
Petites Annonces

0 annonce(s) publiée(s)

Consulter

AmigaOS 4.1

Laissez-vous tenter par
AmigaOS 4.1
AmiTheme

AmiTheme