Ah non j'insiste! J'ai "deux écrans". Du moins, j'ai mon écran coupé en deux horizontalement parlant. Sans parler du clavier qui a du mal, mais bon, ça c'est pour le test! + les ressources CPU englouties à 100%!! ça c'est quand même un peu trop!
Mais, ayant testé sur une autre bécane, j'ai pu voir par moi-même que ça fonctionnait très bien. J'ai mis ma configuration précise sur le forum officiel pour d'autres soucis mais je ne pense pas que vous puissiez faire quelque chose. Maintenant, faire un bon scrolling nécessite de gérer les deux méthodes avec et sans Ogre. Et si Ogre semble lourd, éventuellement avec un substitutif de Ogre. Mais, pour ma part, c'est quand même une librairie dite "native", ce qui a son avantage d'être assez simple à diffuser ici.
@beauregard
Pour l'utilisation des sprites, tu as raison de dire qu'il faut les utiliser : si Ogre ne fonctionne pas sur toutes les bécanes et que les sprites fonctionnent à merveille, ce serait bête!
Aussi, j'ai posté quelques soucis de diagnostics pour Ogre sur le forum officiel. Parce que si on n'arrive pas à détecter que Ogre ne fonctionne pas correctement, comment (dans un jeu qui utilise le défilement) savoir s'il faut plutôt utiliser les sprites?
Dans ce cas précis, Ogre est un peu lourdos en effet!!!
Benchmark avec synchronisation sur l'affichage
Ce code n'est pas destiné à être respectueux du système. Bien sûr qu'il prend 100% du CPU; il en prend le maximum pour être sûr d'être sous la synchro. Au lieu d'utiliser l'accélération matérielle (qui n'est pas utilisable sous Windows, l'interruption VBL n'existe pas!), il fait du polling : interroger le hardware en permanence, de façon à connaitre la position du spot, et faire le swap des buffers au moment où il n'y a (en théorie), pas d'affichage, c'est à dire lors de la VBL.
-Il attend la VBL-
Il swappe les buffers
Il laisse un peu de temps au système
Il attend la fin de la VBL
Il se met en très haute priorité
Il efface le back buffer
Il affiche une ligne à la position actuelle du spot
Il affiche un effet quelconque
Il affiche une ligne à la position actuelle du spot
->On sait en regardant la hauteur entre les deux lignes le temps qu'a pris notre effet. En l'optimisant, il en prendrait moins...
Si l'écran est coupé chez Ollivier, c'est qu'il y a un retard entre la véritable VBL et le swap. C'est évidemment anormal, et il serait intéressant de comprendre pourquoi. Quelque chose se déclenche lors de la VBL qui pique tout le CPU et ne le rend qu'une demi-frame après?
En fait, je me fiche complètement du système, j'essaye de l'exploiter à fond. Je lui rentre dedans, je pertube le task switching, de façon à être prioritaire et à répondre le plus vite possible. Mais je lui rends quand même la main de temps en temps de façon à ne pas avoir de plantage. Mais si je pouvais, je le couperais complètement. Quelle idée idiote d'avoir le système qui bosse tout le temps derrière! Comme dirait un vieux pote, pendant que je joue je ne grave pas!!!! Et l'antivirus qui se réveille en plein milieu d'une partie, ça sert à quoi, à part faire ch***? Enfin, c'est un autre sujet.
Pour résumer, l'objet de ce code est de coller au plus près à l'affichage. Avec mes deux lignes qui ressemblent pour les béotiens à des bugs, je peux mesurer de façon assez précise le temps que prend mon code. C'est visuel : je peux comparer deux routines, sans avoir besoin d'un ellapsedmilliseconds (à la précision... hem!). S'il y a des fluctuations, c'est qu'il y a des choses sur le système, qui volent du CPU, à un haut niveau de priorité! C'est très intéressant pour s'en rendre compte!
Ah, au passage... J'ai aussi incorporé une gestion correcte du ALT-TAB en plein écran (jamais publiée par quiconque sur aucun des forums...)
Cher Bourrin (!)
Gros bourrin même. Je comprends ta démarche, d'ailleurs s'il faut l'optimiser, je peux comprendre. Maintenant, mon petit système est stable. Le moindre pet est contrôlé ce qui aboutit à d'étranges surprises.
A titre technique, les lignes sont très stables. Elles "grésillent" un petit peu de deux ou trois pixels. Elles sont à environ 128 et 192 pixels l'une et l'autre.
Le "coup de sabre" horizontal est lui aussi stable à une centaine de pixels de hauteur (non la moitié, je ne l'avais pas précisé).
En tout cas, le fait d'avoir testé sur une autre bécane, et d'avoir des effets tout à fait différents me rend beaucoup moins sceptique (comme la fosse) quand à l'utilité de préparer un petit jeu (quand ma conscience me le permettra) utilisant Ogre ET les sprites de manière idem à ScreenRequester.PBI où il y a le choix des modes, etc...
Bref, sans ton intervention orgueilleuse, vaniteuse, outrancière (et j'en passe!) avec ce code, je ne pense pas qu'il me serait venu à l'idée de maintenir l'utilisation des sprites.
Pour faire un peu moins con et rancunier, bravo pour la pioche de ce petit code intéressant. Maintenant, comme disent Huitbit et Beauregard (que j'ai tenté de convaincre), avoir un CPU évacué de toute charge lourde c'est... Mieux! Quand j'utilise 4% de mon CPU, c'est qu'il y a Ben Hur, un 40MHz acceptait volontier ce scrolling. Et j'ai pu montrer que sur certaines bécanes (XP: forum anglais Coding question), un scrolling était très fluide avec très peu de ressources. Maintenant, il serait de mauvaise foi de ne pas t'avouer toute mon incapacité à optimiser ton code page 1 pour arriver à des résultats similaires. ça doit forcément être possible. Si l'écran est régulier, que Ogre (ou autre : DreamMotion?) arrive à concilier les deux, il doit nous manquer quelques fonctions très intéressantes à ce sujet!
Maintenant, je tâcherai, si le code évolue de vérifier sur ma pitite daube s'il y a toujours cet effet indésirable. Pour la portabilité, ce serait stupide de ne pas apporter sa pierre au niveau test. A l'heure actuelle, apeuré par la forme du code, je n'émmets qu'une légère hypothèse : la priorité n'est pas toujours manipulable à 100%. Peut-être que mon système bien réglé refuse périodiquement d'offrir la priorité puis accepte toujours périodiquement. Les configurations sont ici. Les diagnostics sont pour Ogre donc il faut inverser les diagnostics (1ère config fonctionne mal, 2nde config fonctionne très bien).
Woilà Djes! On n'a pas fini de "faire couler de l'encre" !!
Gros bourrin même. Je comprends ta démarche, d'ailleurs s'il faut l'optimiser, je peux comprendre. Maintenant, mon petit système est stable. Le moindre pet est contrôlé ce qui aboutit à d'étranges surprises.
A titre technique, les lignes sont très stables. Elles "grésillent" un petit peu de deux ou trois pixels. Elles sont à environ 128 et 192 pixels l'une et l'autre.
Le "coup de sabre" horizontal est lui aussi stable à une centaine de pixels de hauteur (non la moitié, je ne l'avais pas précisé).
En tout cas, le fait d'avoir testé sur une autre bécane, et d'avoir des effets tout à fait différents me rend beaucoup moins sceptique (comme la fosse) quand à l'utilité de préparer un petit jeu (quand ma conscience me le permettra) utilisant Ogre ET les sprites de manière idem à ScreenRequester.PBI où il y a le choix des modes, etc...
Bref, sans ton intervention orgueilleuse, vaniteuse, outrancière (et j'en passe!) avec ce code, je ne pense pas qu'il me serait venu à l'idée de maintenir l'utilisation des sprites.
Pour faire un peu moins con et rancunier, bravo pour la pioche de ce petit code intéressant. Maintenant, comme disent Huitbit et Beauregard (que j'ai tenté de convaincre), avoir un CPU évacué de toute charge lourde c'est... Mieux! Quand j'utilise 4% de mon CPU, c'est qu'il y a Ben Hur, un 40MHz acceptait volontier ce scrolling. Et j'ai pu montrer que sur certaines bécanes (XP: forum anglais Coding question), un scrolling était très fluide avec très peu de ressources. Maintenant, il serait de mauvaise foi de ne pas t'avouer toute mon incapacité à optimiser ton code page 1 pour arriver à des résultats similaires. ça doit forcément être possible. Si l'écran est régulier, que Ogre (ou autre : DreamMotion?) arrive à concilier les deux, il doit nous manquer quelques fonctions très intéressantes à ce sujet!
Maintenant, je tâcherai, si le code évolue de vérifier sur ma pitite daube s'il y a toujours cet effet indésirable. Pour la portabilité, ce serait stupide de ne pas apporter sa pierre au niveau test. A l'heure actuelle, apeuré par la forme du code, je n'émmets qu'une légère hypothèse : la priorité n'est pas toujours manipulable à 100%. Peut-être que mon système bien réglé refuse périodiquement d'offrir la priorité puis accepte toujours périodiquement. Les configurations sont ici. Les diagnostics sont pour Ogre donc il faut inverser les diagnostics (1ère config fonctionne mal, 2nde config fonctionne très bien).
Woilà Djes! On n'a pas fini de "faire couler de l'encre" !!
Et tu t'y connais...Ollivier a écrit :Bref, sans ton intervention orgueilleuse, vaniteuse, outrancière (et j'en passe!) avec ce code, je ne pense pas qu'il me serait venu à l'idée de maintenir l'utilisation des sprites.
En fait oui, il est très facile de faire un scrolling très fluide avec PB, que ce soit en utilisant les sprites 2d, 3d ou Ogre. Il n'y a qu'à regarder les jeux de Polux pour s'en convaincre, ils contiennent des tonnes de parallaxes, des scrollings différentiels et un tas d'autres trucs et sont d'une constante fluidité. Et ils sont tous en 2D.Ollivier a écrit :Et j'ai pu montrer que sur certaines bécanes (XP: forum anglais Coding question), un scrolling était très fluide avec très peu de ressources.
Je n'ai pas compris ce que tu voulais optimiser... L'effet? C'est un code quelconque; on pourrait aussi bien mettre le calcul d'une fractale; l'intérêt est plus dans la synchro et les rasterlines.Ollivier a écrit :Maintenant, il serait de mauvaise foi de ne pas t'avouer toute mon incapacité à optimiser ton code page 1 pour arriver à des résultats similaires.
J'ai légèrement modifié le code pour le rendre un peu moins gourmand et pour que le clavier soit plus réactif (jusqu'ici il était presque bloqué!). Sur ta machine, il doit y avoir quelque chose qui se passe au niveau de la VBL qui décale la position du swap. Une tâche (avec un fort niveau de priorité) doit se réveiller à ce moment là. En outre j'ai suggéré à Fred de permettre l'usage du triple buffer qui éviterait la "coupure".Ollivier a écrit :Maintenant, je tâcherai, si le code évolue de vérifier sur ma pitite daube s'il y a toujours cet effet indésirable.
C'est un petit travail de recherche/confrontation de points de vue qui n'est pas désagréable.Ollivier a écrit :Woilà Djes! On n'a pas fini de "faire couler de l'encre" !!
Même si je sais d'avance que tu gagneras 
Voici un autre exemple utilisant des "plots". Clic gauche pour voir le framerate.
http://djes.free.fr/purebasic/eye.exe
http://djes.free.fr/purebasic/eye.exe
-
beauregard
- Messages : 1307
- Inscription : dim. 08/juil./2007 18:32
- Localisation : Toulouse
testé sur mon vieux PC, ligne verte au 3 quart de l'écran donc encore fluide... un bel oeil !djes a écrit :Voici un autre exemple utilisant des "plots". Clic gauche pour voir le framerate.
http://djes.free.fr/purebasic/eye.exe
config de mon ordi: seven, directx11, Pentium(R) DualCore E5700, RadeonHD 4550 512MB, PureBasic 4.61 x86
Merci! Pas beaucoup de retours, alors le tien me rassurebeauregard a écrit :testé sur mon vieux PC, ligne verte au 3 quart de l'écran donc encore fluide... un bel oeil !djes a écrit :Voici un autre exemple utilisant des "plots". Clic gauche pour voir le framerate.
http://djes.free.fr/purebasic/eye.exe
-
beauregard
- Messages : 1307
- Inscription : dim. 08/juil./2007 18:32
- Localisation : Toulouse
à propos de plot, chez moi, plot et directx9 ne font pas bon ménage:djes a écrit :Merci! Je ferai peut-être un tuto sur comment se servir de ce truc pour optimiser un code. C'est vraiment une technique très efficace. Ceci fait, on peut utiliser une synchro normale avec flipbuffers en sachant qu'on a été au bout de l'optim
http://www.purebasic.fr/french/viewtopi ... 68&start=0
config de mon ordi: seven, directx11, Pentium(R) DualCore E5700, RadeonHD 4550 512MB, PureBasic 4.61 x86