ANIMATIONS [SCANLINE + ALGÈBRE]
John Dogget
Messages postés
384
Date d'inscription
vendredi 18 juin 2004
Statut
Membre
Dernière intervention
7 mai 2009
-
25 janv. 2009 à 00:03
Caribensila Messages postés 2527 Date d'inscription jeudi 15 janvier 2004 Statut Membre Dernière intervention 16 octobre 2019 - 26 janv. 2009 à 20:16
Caribensila Messages postés 2527 Date d'inscription jeudi 15 janvier 2004 Statut Membre Dernière intervention 16 octobre 2019 - 26 janv. 2009 à 20:16
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/49073-animations-scanline-algebre
https://codes-sources.commentcamarche.net/source/49073-animations-scanline-algebre
26 janv. 2009 à 20:16
26 janv. 2009 à 20:15
dans ce cas la gain est minime(si gain il y a) par contre la probabilité d'une erreur de saisie est importante.
26 janv. 2009 à 20:09
*Bouhouhouhouh*
Probablement un cube en 3D home-made avec des faces dégradées la prochaine fois ?
Cordialement, Bacterius !
26 janv. 2009 à 20:06
Si tu veux réutiliser ton code, passes par des ScanLines...Tu pourras ajouter des effets plus tard...et pourquoi pas la 3D ?
26 janv. 2009 à 20:03
x(
Cordialement, Bacterius !
26 janv. 2009 à 19:56
Moi, j'aurais laissé les tables trigonométriques en constante. J'ai pas testé, mais je crois que c'est plus rapide.
26 janv. 2009 à 19:22
y'en a encore plus par heure !!!
26 janv. 2009 à 19:21
BLUEPERFECT a raison pour la palette, en tout cas! La palette est le secret de ce genre d'animation je pense. Les perfs s'envolent !
Contrairement à ce que croient les novices, la palette ne limite pas la profondeur des couleurs affichées, mais seulement le nombre de couleurs affichées simultanément. Ce qui n'est pas gênant ici.
Autre avantage: tu peux obtenir des effets très intéressants et très rapides en ne travaillant que sur la palette ("palette-animation", in english).
Mais bon! Palette + threads, c'est pour les "pro", je crois. Mais c'est tj bon de savoir que ça existe.
26 janv. 2009 à 19:16
26 janv. 2009 à 19:15
Cordialement, Bacterius !
26 janv. 2009 à 19:14
26 janv. 2009 à 19:13
26 janv. 2009 à 19:08
Juste une question : quelle est le plus rapide (renvoient tous les deux 0 avec un GetTickCount, trop rapide) :
-- Version ASM --
function TMainForm.ScaleTo(X: Integer; Scale: Integer): Integer; // Replacement de X dans Scale (opérandes entiers)
begin
while X >= Scale do
asm
MOV EAX, X;
SUB EAX, SCALE; // ASM pour aller + vite
MOV X, EAX;
end; // On diminue X jusqu'à ce qu'il soit dans 0..Scale
Result := X; // On donne ça au résultat
end;
-- Version Pascal --
function TMainForm.ScaleTo(X: Integer; Scale: Integer): Integer; // Replacement de X dans Scale (opérandes entiers)
begin
while X >= Scale do X := X - Scale;
// On diminue X jusqu'à ce qu'il soit dans 0..Scale
Result := X; // On donne ça au résultat
end;
______________________
Et pareil pour le type Single à la place d'Integer ?
Je précise que j'ai souffert pour convertir une soustraction pascal en ASM, alors pitié ne m'achevez pas :'/
D'ailleurs il faut que je m'y mette, à l'ASM, c'est essentiel.
Cordialement, Bacterius !
26 janv. 2009 à 19:05
* Parce que chaque objet, maintenant que leur modalité est précisée, devrait posséder son propre espace mémoire et d'éxécution pour ses propres traitements
* Parce que Synchronize existe pour quelquechose
* Parce que jouer sur 32 bits parce que c'est plus rapide ne devrait pas être la justification d'une lenteur de traitement global
* Parce que DirectX fais mieux que ça en version 0.9beta...
26 janv. 2009 à 19:00
Précise ta pensée !
Cordialement, Bacterius !
26 janv. 2009 à 18:34
26 janv. 2009 à 18:33
Cordialement, Bacterius !
26 janv. 2009 à 18:32
Je travaille en 32 bits, c'est plus rapide qu'en 24 bits pour le CPU.
Cordialement, Bacterius !
26 janv. 2009 à 18:29
faut absolument jouer avec les threads...
Actuellement tu utilises 1 thread...
Dans l'absolu, il en faut un par objet animé !
26 janv. 2009 à 18:28
Fini les 128Ko de mémoire....
Et puis tu utilises combien de couleurs ?
Tu peux jouer avec la palette...
26 janv. 2009 à 18:27
Cordialement, Bacterius !
26 janv. 2009 à 18:25
"Sinon, dans le genre optimisation, si tes rotations sont cycliques, tu peux mettre tout ça en cache, même les TBitmap..."
Mais je viens de comprendre.
C'est une bonne idée, mais côté mémoire ça va pomper ! 360 TBitmaps en mémoire, argh.
Cordialement, Bacterius !
26 janv. 2009 à 18:17
26 janv. 2009 à 17:51
@Blueperfect : tes commentaires sont toujours plein de mystère ...
@Débiars : interessants résultats ... il faut que j'en finisse avec ces violations d'accès (l'opération de pointeur incorrecte, je croyais l'avoir virée !).
Et où puis-je télécharger un profiler ?
Ou bien dois-je me commander un Do-It-Yourself ?
Je demande à mon ami Google :)
Cordialement, Bacterius !
26 janv. 2009 à 13:29
un test avec un profiler te permettrait d'y voir plus clair..
avec cet outil, tu aurais la liste de toutes tes méthodes avec le nombre de cycles et aussi le temps consommé.
26 janv. 2009 à 10:54
26 janv. 2009 à 09:58
26 janv. 2009 à 09:53
128x128 : se plante au lancement dans SetPixel, violation d'adresse...
256x256 : fonctionne bien, mais fait une sinusite à l'arrêt : pointeur invalide...
512x512 : OK, un peu lent, mais est-ce vraiment un problème ??
Qui va piano, va sano !
(Cari, serait-ce le retour du cocombre masqué ? Bretzel liquide !!!)
25 janv. 2009 à 22:30
D'ailleurs, tu devrais lire tous les commentaires de ce tuto. C'est le plus intéressant! :)
(Et t'es bien sûr que c'est pas un concombre déguisé, ton PC?)
25 janv. 2009 à 21:44
Cordialement, Bacterius !
25 janv. 2009 à 21:42
Sinon pour l'optimisation je fais ce que je peux ...
Je me rappelle de son texte dancant à Manchester - dès que je posais son composant sur la fiche, il plantait comme c'est pas possible (100% CPU, plantage total => redémarrage du concombre). Mais je vais voir pour les sinus-cosinus.
Cordialement, Bacterius !
25 janv. 2009 à 21:40
Il faut rectifier le commentaire, c'est * 1000 arrondi ^^'
Désolé.
Cordialement, Bacterius !
25 janv. 2009 à 21:36
DegSinus[I] := Round(Deg(S) * 1000); // On récupère son sinus degré * 100 arrondi
il faut mettre :
DegSinus[I] := Round(Deg(S) * 100); // On récupère son
sinus degré * 100 arrondi
A+
25 janv. 2009 à 21:32
25 janv. 2009 à 20:54
Et ... je me suis inspiré de tes techniques d'optimisation du code avec les tables trigonométriques : j'ai créé 4 tableaux d'entiers (Sinus, Cosinus, DegSinus et DegCosinus), que je remplis dans une boucle au début de l'application.
Sinus et Cosinus contiennent les sinus des angles exprimés en radians. DegSinus et DegCosinus contiennent les sinus et les cosinus [en degrés] des [angles exprimés en radians] (utilisé dans le calcul des points des lignes).
Et evidemment, j'ai tout passé en entiers avec une multiplication puis une division par 1000. (mais je crois que si on le fait avec 1000000, la précision des sinus et des cosinus sera plus importante non ?).
Bon ben voilà, c'est déjà ça de gagné ! (300% de gain de performances, d'après ton tutorial).
Cordialement, Bacterius !
25 janv. 2009 à 16:12
C'est sur ces méthodes que tu dois t'arrêter en priorité pour améliorer les perfs. Elles constituent ce qu'on appelle des goulets d'étranglement...
25 janv. 2009 à 16:05
25 janv. 2009 à 16:00
tu aurais du songer au père Noël..
25 janv. 2009 à 15:59
pour le PC, tu aurais du songé au père Noël..
25 janv. 2009 à 15:26
Juste une question : c'est quoi un "goulet d'étranglement" ? Je ne comprends pas très bien.
Cordialement, Bacterius !
25 janv. 2009 à 15:23
(décidément je me fais doubler par tout le monde aujourdhui !).
Cordialement, Bacterius !
25 janv. 2009 à 15:22
Or, moi j'ai un escargot comparé au tien.
Donc, il faudrait que ... que tu me files ton PC pour quelques temps ... juste le temps de faire marcher le tien (car sur le mien ça marche bien car il est lent).
En fait ton problème vient que tes instructions sont executées tellement vite qu'elles tombent à coup sûr sur une synchronisation du thread - alors à la fermeture, conflit : Synchronisation + Libération du bitmap => Violation d'accès.
Donc, comme je ne peux pas tester dans les conditions de ton PC, je ne peux pas faire grand-chose.
Tu veux pas aller à Carrefour chercher un PC pourri en soldes à 50 euros, vite fait pour tester ? ^^
Cordialement, Bacterius !
25 janv. 2009 à 15:19
Pour pouvoir comparer les perfs efficacement, évite les threads ou les ProcessMessages quand tu es en phase d'optimisation. Une simple boucle avec un nombre d'itérations fixe est bien plus pratique pour déceler les goulets d'étranglement.
Et ce ne sera que lorsque tu penseras avoir optimisé au mieux que tu threaderas ton appli...
25 janv. 2009 à 15:15
Lines[Y][X].rgbBlue := B; // On définit la composante B
Pourquoi, je ne sais pas ...
25 janv. 2009 à 15:12
Mais c'est pas grave, ça marche avec l'autre boîte.
Affaire à suivre quand-même.
Je viens de mettre à jour :)
Au fait Cirec, tu as une idée de pourquoi, quelques fois, mes FPS sur 128x128 atteignent les 350 FPS, et que d'autres fois (sans rien changer au code), on passe à 63 FPS ?
Bizarre non ?
Cordialement, Bacterius !
25 janv. 2009 à 15:10
25 janv. 2009 à 15:05
Oui, je vais bien vérifier sinon je vais encore mettre à jour 20 fois ...
Cordialement, Bacterius !
25 janv. 2009 à 14:59
quelle énergie !
ya pas le feu au lac..
prends ton temps Bacterius.
25 janv. 2009 à 14:55
Mais c'est arrangé, j'ai mis plutôt l'autre option (MsgDlgBox), avec les paramètres tout regroupés, et ça marche bien maintenant.
Je vais pas tarder à mettre à jour sur le site.
Cordialement, Bacterius !
25 janv. 2009 à 14:41
Oublies pas que t'es dans un thread et qu'il aime pas la manipulation des pointeurs en simultanée !
25 janv. 2009 à 14:37
Alors, avec le MessageDlg classique :
case MessageDlg('Quelle résolution ?' + chr(13) + chr(13)
+ 'Cliquez sur OK pour une résolution de 512x512.' + chr(13)
+ 'Cliquez sur Oui pour une résolution de 256x256.' + chr(13)
+ 'Cliquez sur Non pour une résolution de 128x128.' + chr(13)
+ 'Ne quittez pas la boîte de dialogue.' + chr(13)
, Dialogs.mtConfirmation, [Dialogs.mbOK, Dialogs.mbYes, Dialogs.mbNo], 0) of
mrOK: Res := Point(512, 512);
mrYes: Res := Point(256, 256);
mrNo: Res := Point(128, 128);
end; // On demande pour la résolution d'affichage
C'est moche mais il n'y a pas de problème.
Avec une boîte de dialogue à toi :
New(Btns);
Btns[mbCust1] := '128x128';
Btns[mbCust2] := '256x256';
Btns[mbCust3] := '512x512';
case MessageDlgEx('Choisissez votre résolution', mtInformation, [mbCust1, mbCust2, mbCust3], 0, mbCust1, nil, Btns) of
mrCust1: Res := Point(128, 128);
mrCust2: Res := Point(256, 256);
mrCust3: Res := Point(512, 512);
end;
Dispose(Btns);
C'est beau, mais ça plante dès qu'on quitte cette boîte, sur une affectation de composante dans SetPixel. Bizarre, car ça marche avec une boîte normale et pas avec la tienne ??
Cordialement, Bacterius !
25 janv. 2009 à 14:17
En fait l'opération de pointeur incorrecte était générée par la tentative de dessin dans le composant TImage (libéré avant la fiche).
Je dessine sur la fiche et ça marche nikel (ça m'évite même le bidouillage avec le TBitmap temporaire dans le Create).
Maintenant que j'ai éradiqué cette erreur, je vais voir le messagebox personnalisé (j'en ai besoin :x), et j'arrange tous les autres petits trucs.
Cordialement, Bacterius !
25 janv. 2009 à 14:04
En revanche ... opération de pointeur incorrecte sur toutes les res. ^^' à la fermeture.
Cordialement, Bacterius !
25 janv. 2009 à 14:03
et je n'ai eu aucun plantage !!!
25 janv. 2009 à 14:02
Je prends note pour le timer.
Cordialement, Bacterius !
25 janv. 2009 à 14:01
Je regarde ton post, j'arrange tout ça et c'est parti.
Donc les tables dynamiques trigonométriques sont plus rapides que les constantes ?
Cordialement, Bacterius !
25 janv. 2009 à 14:01
D'ailleurs, dans ton code, je ne vois pas ce qui prends autant de temps...
Peut être devrais-tu changer la phase de dessin en suppriment l'appel à draw dans ton thread, et en la plaçant dans un TTimer de ta TForm à 25ms (40 affichages par secondes)...
Cordialement...
25 janv. 2009 à 14:00
En fait, ton ordi va tellement vite qu'il passe à tous les coups sur un appel à une variable détruite avec le thread ! héhé >-)
Sinon, dites-moi vos FPS ;)
128x128 = 63 FPS (bon hier je faisais du 219 FPS, je ne comprends pas ...).
256x256 = 43 FPS
512x512 = 12 FPS -_-'
Cordialement, Bacterius !
25 janv. 2009 à 13:53
Ça te fait : Surprise mais je plante :)
25 janv. 2009 à 13:49
case MyQuestion of
False: DynArray;
True: Nothing;
end;
^^
Cordialement, Bacterius !
25 janv. 2009 à 13:27
25 janv. 2009 à 13:24
Cordialement, Bacterius !
25 janv. 2009 à 13:10
25 janv. 2009 à 13:05
Donc, merci Cirec maintenant ^^, et puis le lien peut servir, je mets en favoris.
Cordialement, Bacterius !
25 janv. 2009 à 12:52
@Blueperfect : oui mais là j'utilise un tableau de pixels, donc pour dessiner sur le canevas c'est niet. Sinon merci pour le conseil du OnQueryClose, je vais voir ça.
@Nicolas : ouais je vais arranger ça, ca arrive de temps à autres :/
Cordialement, Bacterius !
25 janv. 2009 à 12:14
Animation
---------------------------
Violation d'accès à l'adresse 00401E78 dans le module 'AnimTest.exe'. Ecriture de l'adresse 00E40004.
---------------------------
OK
---------------------------
J'ai ce gentil petit message en quittant ton appli en 512x512 ...
Pas encore regardé le code ...
25 janv. 2009 à 03:02
Quand tu utilises un TThread, il faut le libérer sur OnQueryClose...sinon, il tourne sur des TCanvas qui sont libérés...
25 janv. 2009 à 02:58
Sinon le mieux est de les programmer soi-même :
Ce sont des variations du spectre lumineux basées sur 1 ou plusieurs couleurs...
A votre disposition pour étudier, et/ou améliorer un TPersistent de mon crû,que j'ai nommé TSpectre.... C'est une TStringList de TColor (ColorToString) et un éditeur de propriétés...et une collection de procédures de tracé de lignes/Cercles où l'on trace ces figures en ajoutant en paramètre un tableau de TColor, et une collection de fonctions de gestion des couleurs incluant :
* pour 1 couleur, on demande n valeurs TColor, deš% sombre à % clair, et on renvoie le tableau de TColors correspondant...
* pour plusieurs couleurs, on demande n valeurs TColors comprises entre l'étalonnage de TColors passé en paramètre...
Concrêtement :
DrawGradientLine( MyBitmap.Canvas,
Point(10,10), Point(100,10),
[ clRed, clGreen, clYellow ]
);
permets de tracer une ligne horizontale dont les couleurs varient du rouge au jaune, en passant par le vert...
25 janv. 2009 à 02:07
25 janv. 2009 à 00:51
DirectX c'est pas de la programmation, c'est de l'utilisation excessive de termes ésothériques malencontreusement non alignables, réservé aux élève de MathSpé...
>>Bactérius
Bonne idéee...je vais lire ça...Pour le tracé des lignes, j'ai idée que faire des gradients t'inspirerait...
25 janv. 2009 à 00:03
En tout cas, le code est archi-commenté, bravo => 7/10