Affichage de point ST basse

[hylst]

Vivement que je finisse de debugger les écrans de la japemo voulue 100% GFA (sauf rout chip), que je fasse un peu plus de technique, voire à quel point je peux optimiser certains effets.
Tu as en tous cas l'air de te débrouiller déjà en asm.

[tomchi]

haha !!! A cause de toi (ou grace plutot hein ?!) je suis sur une routine de rotozoomer 1 plan.
100% gfa temps reel pour le moment, j'en suis à 3 vbls pour un affichage de 160*100 avec des quadruples pixels.
pas terrible, il va etre temps de passer aux precalcs pour booster tout ça

HAHAA !!! 9 vbls en plein ecran pffffffffffffff .....

[leglod]

haha !!! A cause de toi (ou grace plutot hein ?!) je suis sur une routine de rotozoomer 1 plan.
100% gfa temps reel pour le moment, j'en suis à 3 vbls pour un affichage de 160*100 avec des quadruples pixels.
pas terrible, il va etre temps de passer aux precalcs pour booster tout ça

HAHAA !!! 9 vbls en plein ecran pffffffffffffff .....

avant ou apres compilation ?

devine ^^'

[hylst]

En 3 vbls seulement ?! Le rotozoom... je m'y suis cassé les dents, comme l'effet blob, lenteur inimaginable, en grande partie à cause de la lenteur de l'affichage.
En 1 plan... du code généré en card avec adresse relative et masque pour le or precalculé pour chaque point et chaque étape ?
Dommage que l'on ne puisse gérer des rasters horizontaux ... en gfa... sans quoi ce serait un carnage... =D
rrraaa... le copper amiga.... =D


En tous cas, j'ai hâte de voir ça !

[leglod]

Il est capable de quoi ce cooper amiga et le blitter de l'amiga il est vraiment beaucoup plus puissant que celui d'Atari ?

[hylst]

si ça t'intéresse, tu trouveras pas mal d'infos ici http://fr.wikipedia.org/wiki/Original_Amiga_chipset

[leglod]

J'avais deja lu un peut tout ca, je sais tres bien que l'Amiga n'a rien a prouver de ces capacite sur le ST, ce que je voulais savoir c'est surtout les performance du Blitter de l'Amiga par rapport a celui du STe , a l'epoque boucoup disaient que celui du STe ne valait rien, pas plus rapide qu'une bonne routine en assembleur ect.. Mais qu'en est il reelement ?

[tomchi]

pff, derouler le code n'accelere pas grand chose, et le peu d'idees d'optimisation que j'avais ne font rien gagner ^^'
toujours 3vbls pour un pauvre 1/2 ecran en 1 plan.
ça me botte pas bien de faire 360 kos de precalcs juste pour voir si ça va plus vite

:'(

[hylst]

360ko ? ça passe encore j'aurais tendance à dire. Si ta mémoire n'est pas trop mangée par de gros inline, ou autres precalcs. Après... tout dépend de ton code...

[tomchi]

\o/ Apres 360 kos de precalcs et une chtite optimisation sur l'incrementation des pointeurs ça tourne en 1 vbl !!
Bon, sauf que yaurait pas de temps pour autre chose même pas un petit soundchip :'(
Pis .. ben euh ... en fait 160*100 ça fait pas un demi ecran, ça fait le quart d'un ecran, alors c'est tout petit ... re :'(
derouler tout le code ne ferait pas gagner beaucoup en temps machine mais resulterait en un source de plus de 7000 lignes ...
Hmmmm chais pas quoi faire avec ça, soit je m'en sert si j'arrive a gagner un peu de cpu pour remplir un peu plus l'ecran, soit j'essaye une routine assembleur, mais du coup ça serait plus du GfA et rotozoomer 1 plan en asm c'est la loose.
Enfin, maintenant je sais à quoi m'en tenir