lolo> j'ai maté ta src et tu as rajouté 3lignes dans ce que je t'avais filé .. pkoi t'as pas tout simplement étendu les boucles precedentes plutot que perdre du tps avec les fastdrawline ?
Spipu Le 09/02/2002 à 11:16 ben en fait, c'est ce que j'avais fait, et ca marchait tres bien si dX < dY, mais par contre si dX > dY, alors la ligne n'etait pas complete... voila pkoa...
bah dans ce cas là .. change quand mm et si et seulement si dX > dY alors tu fais ca .. tu devrais ganger un peu
Spipu Le 09/02/2002 à 17:42 je ferais le test lundi, la je suis pas chez moi
Spipu Le 14/02/2002 à 00:01 j'ai pas mal accélérer mon prgm : j'ai réussi a passé de 199 fps a 213 fps (test effectué sur un cube en ne desactivant que l'affichage des polygones) et je pense avoir fini l'optimisation des calculs...
maintenant je me penche sur l'opimisation de l'affichage... (je me base tjrs sur le cube)
premier constatation :
en désacivant absolument tout ce qui affichage : 460 fps
en rajout
Spipu Le 14/02/2002 à 10:36 non, il ne l'affiche que quand tu quitte, c un fps moyen depuis le lancement du prgm
a propos pour ton cube, tu dis que tu est a 700 fps, mais c quand tu le fait bouger ou quand il est immobile? car moi, si il est immobile bien enface, il n'y a alors plus que 2 faces a afficher, et je monte au dessus des 700 fps, don precise moi cela...
Spipu Le 14/02/2002 à 14:21 k
petite correction sur mes fps :
toujours pour le cube
sans aucun affichage : 506 fps
avec juste l'e.v. : 234 fps
(test effectué avec une animation de cube qui tourne)
donc si quelqu'un a une solution... merci...
et a propos, c pa possible de carrément changer l'adresse de l'ecran reel pour indiqué celui de l'ecran virtuel et donc d'viter carrement les copies d'ecran en jonglant entre 2 ecrans ?
Je ne sais absolument pas si c'est possible, mais ça revient exactement au même que de ne pas en utiliser, donc ça ne sert à rien.
est-ce que tu as des clignotements, sans l'écran virtuel ?
TiMad Le 14/02/2002 à 16:16 Erf ...utilisez Xlib.... plus de 90000pxl seconde en mode gray...
XLib v1.00 Powerrrrrrrrrrrrrrrrrrrr!
>lolo: et a propos, c pa possible de carrément changer l'adresse de l'ecran reel pour indiqué celui de l'ecran virtuel et donc d'viter carrement les copies d'ecran en jonglant entre 2 ecrans ?
Non, du moins pas sur HW2. (C'est la méthode qui ne marche que sur HW1 dont a parlé sBibi.)
Spipu Le 14/02/2002 à 17:40 heu... pourquoi ca ne marcheplus sous hw2?
en a propos, en fait , c koa HW1 et HW2 , g pas encore compris...?
Spipu Le 15/02/2002 à 15:11 vue la rapidité de xlib par rapport a extgraph, je sens que je vais m'y mettre ....
il marche ou pas, en NoStub ?
Miles Le 15/02/2002 à 15:31 sur HW1, le contrôleur est intégré au contrôleur et l'adresse de la mémoire est variable. Sur HW2, elle est variable car le GPU n'est plus fixe...
[edit]Edité par Miles le 15-02-2002 à 15:31:29[/edit]
Spipu Le 15/02/2002 à 16:07 mais cette adresse est bien stocké kelkepart , non ?
>lolo:
>vue la rapidité de xlib par rapport a extgraph, je sens que je vais m'y mettre ....
>il marche ou pas, en NoStub ?
Oui.
>en a propos, en fait , c koa HW1 et HW2 , g pas encore compris...?
HW1 = version matérielle 1
HW2 = version matérielle 2.00
>heu... pourquoi ca ne marcheplus sous hw2?
Sur HW1:
- On peut faire lire le LCD de n'importe quelle adresse divisible par 8.
- Quand on change cette adresse, l'écran est rafraîchi, parce que le LCD va chercher ses données en RAM.
Sur HW2:
- On peut faire lire le LCD de $4c00, $5c00, $6c00 et $7c00 seulement, et il y a des variables système importantes dans les zones à $5c00 , $6c00 et $7c00.
- Même si on règle le problème des variables système, on ne peut pas faire du plane swapping matériel parce que le LCD n'est pas rafraîchi si on change l'adresse. En effet, le LCD a une mémoire vidéo spéciale qui n'est rafraîchie que quand on écrit en la zone de RAM sélectionnée. Il faut donc obligatoirement écrire en la nouvelle zone si on change le plan. Donc autant recopier tout en $4c00, ce qui évite le problème des variables système. On ne peut pas faire plus rapide de toute façon.
[edit]Edité par Kevin Kofler le 15-02-2002 à 22:43:36[/edit]
Spipu Le 16/02/2002 à 17:42 donc, on abandonne le changement d'adresse....
mais pour revenir a Xlib, vu qu'il marche en nostub, je pense que je vais l'utiliser.
Il y a une fnc de remplissage de triangles dedant ?
Spipu Le 17/02/2002 à 14:09 x-lib, c'est surtout pour du gray ou du N&B ?
t bien patient Kevin...y'a la FAQ pr des questions du genre >en a propos, en fait , c koa HW1 et HW2 , g pas encore compris...?
Spipu Le 18/02/2002 à 19:04 ... il me rend un petit service , je voulais juste savoir la difference d'un point de vue gestion ecran...
c simpa de sa part de m'avoir repondu, et je suis sur que tu aimerais qu'on en fasse autant pour toi, donc ...
retournons a mon pb...
Spipu Le 22/02/2002 à 23:36 ben....voila les nouvelles...
kestion optimisation calcul : rien de 9, c deja a fond, jepense
kestion affichage : je cherche mais je trouve pas...
du coup, je me porte sur une autre partie (merci a Sbibi) :
mes objets avaient un gros defaut : tout etait stocké sur un octet : les coordonnées despoints allaient de -128 a 127, il ne pouvait pas y avoir plus de 256 point et 256 faces....pas tres glorieux tout ca...
du coup j'ai eu envie d'augmenter les capacités...
j'ai installé 3DS et j'ai vu que tous les objets avait un nombre de points <65535 et de meme pour lespoints.... donc j'ai eu envie des tout refaire la gestion des objets sur 2 octets a chaque fois, et programmer un convertiseur 3DSMAX -> TI92+/89... et la, Sbibi intervient ! il me parle du format ASE (j'ai undoute sur le nom) et je me rend compte qu'on peux souver sous ce format avec 3DS, et en plus, il a l'avantage de ressembler trs fortement a mon format...
d'ou les prochaines améliorations a apporté :
l'augmentation de la capacité des objets TI
un convertisseur ASE -> 9XZ ou 89Z
mais ça va remonter 
) et vu ke l'aff des fps est pas vraiment optimisé comme il faut... sans les fps ça doit faire un pe plus 
soit faire un tri plus efficace des facettes .. (a base de tri rapide c facilement trouvable)
