Bin voilà, avec ce que tu ajoute, je pense qu'au départ, Andreas (créateur d'hollywood) travailler qu'avec la VRAM et c'est surement pour cela que l'on ne peut pas exécuter un prg Hollywood sans carte GFX comme la pixel64 (par exemple)

Mais lorsqu'il a vu que son double buffer était pourrie (peut être parceque je lui ai filer un script avec mon moteur 2 fois plus rapide qu'avec son doublebuffer pourrie), il s'est empressé de dirigé le bitmap sur la ram et non sur la vram et c'est peut être aussi pour cela que la fonction begindoublebuffer() avec l'option hardware=true n'est compatible qu'AVEC les amiga ;-)

La seule solution, d'après ce que je comprend serais de créer un doublebuffer qui tape directement sur le GPU sans passer par le CPU afin d'alléger les calcules de directions, IA, etc...

Mais quand cela sera fait sur nos AOS?

Je comprend que c'est pas évident pour andreas de créer un langage multiplateforme tout en optimisant pour AOS/Morphos, mais j'attend avec impatience un outil qui permettrai de coder du VB 

D'ailleurs, designer serait complet si on pourrait créer des fenêtres reaction/mui/vb et ensuite taper du code, faut pas croire, mais il y a un potentiel sur hollywood et designer qui n'est pas exploiter.

Si holly faisait partie intégrante d'AOS, imaginer? un langage multiplateforme intégré a un système!!!!!

Avec designer en plus, on l'a notre powerpoint ;-)

Et si toi et d'autre filer un coup de main a andreas, l'outil serait bien plus au top, oui, on n'a pas de suite bureautique, mais on peut avoir un langage simple, optimiser et multiplateforme avec en son coeur AOS ;-)

Bizarre que personne n'y ai pensé chez aeon et autres!!!!!!!!!!!!!!!

Citation: thellier  ... La seule opération RAM->VRAM qui est une peu rapide c'est de copier massivement avec un truc genre WritePixelArray();

Alain

Et encore, en OpenGL 1.x et 2.X ça rame grave du c**! (soit en locurrence, avec notre MiniGL actuel sous AmigaOS4.1FE).

Par contre il est vrai que si l'on pouvait contrôler le fait qu'un brush soit chargé directement en mémoire vidéo et que les copies soient faites par les GPU ... ça permettrait de bien booster la 2D :p
Mais je crois que ce n'est pas possible.

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é ;-)

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.

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 ;-)

 

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.

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 ;-)

Allez, je laisse les pros t'embêter !