Re: GUERRE ST-AMIGA, FIGHT !!!

[Invité]

@rocky007: Bravo, dommage qu'il soit à l'envers, mais l'effet rend bien   ..

par contre, fait chier, je n'arrive pas à capturer/encoder correctement pour youtube... sur l'originale, il y a pas ces petits glitchs verticaux / saccades qui apparaissent après compression. ( quelqu'un connait comment faire une capture 100% fidèle ? 

J'utilise fraps, avec un encodage 25/30 fps et non 50/60 par défaut .

[rocky007]

j'ai trouvé le problème pour l'encodage, je capturais en 320x200, et évidement les artefacts de compression bousillait tout...

vous êtes difficile , voilà mon tube en mode tunnel...( n'oublions pas que c'est juste un essai, pas un demo que je vais sortir )

[Invité]

hoho.bien ouej

tu as du %cpu en rab a ce stade la?

[Invité]

C'est vraiment pas mal là .

[rocky007]

hoho.bien ouej

tu as du %cpu en rab a ce stade la?

plus rien :)   mais faut pas oublier que c'est en GFA.

[Invité]

plus rien :)   mais faut pas oublier que c'est en GFA.

Et si tu passes en 2bp, ça t'accélérerait pas la copie ??

[stapha92]

plus rien :)   mais faut pas oublier que c'est en GFA.

Et si tu passes en 2bp, ça t'accélérerait pas la copie ??

Il ne peut pas : les bitplans du ST sont entrelacés : on ne peut pas traiter 2 bp avec des bmoves.

Sinon... Superbe Rocky !

ça rend vraiment bien.

Une petite remarque : 

ATTENTION !!! CE N'EST PAS UNE CRITIQUE !!!!

ça devrait rendre beaucoup mieux avec un double-buffer et une attente de vbl.

Tu disais atteindre 23 i/s, ce qui te ferait passer de justesse à 3 vbl (16,6 i/s effectif) : pourquoi ne pas le compiler ? Tu serais à 25 i/s sans problème avec la gestion de la vbl.

Je dois dire que la vitesse du gfa est très bonne, mais il doit aller plus vite en compilé.

vous êtes difficile , voilà mon tube en mode tunnel...( n'oublions pas que c'est juste un essai, pas un demo que je vais sortir  )

Ben... et pourquoi pas ? Le plus dur est fait ! il suffit de remplacer quelques lignes de code GFA en assembleur et hop : c'est du 50 i/s ! Pour un effet pas souvent rencontré.

Et l'assembleur te permettrait plusieurs choses :
 - plus besoin de textures symétriques.
 - un stockage sur 3bp, donc de la place gagnée. En fait tu pourrais avoir la même taille de texture que BTL...
 - Tu pourrais faire une déformation du genre : au début ça scrollerait en étant plat. Puis le tunnel apparaitrait petit à petit en se creusant. Aucun cout supplémentaire, puisque tu as toutes les lignes à toutes les tailles, y a que le choix des lignes à copier.
 - En redescendant à 25 i/s, tu disposerais d'une frame entière pour ajouter quelque chose par dessus ! Une balle qui rebondirait sur le tunnel en étant préscalée par exemple.

Mais je le répète : l'effet est très réussi. Encore bravo.

Sinon, tu as utilisé un logiciel pour faire la courbure ? Trop long en GFA ? ça t'oblige à stocker 16 demi-images sur la disquette ?

[Invité]

Il ne peut pas : les bitplans du ST sont entrelacés : on ne peut pas traiter 2 bp avec des bmoves.

Dommage 

[Seb]

Dans un effet comme celui-là tu as potentiellement 2 fois la même ligne de la même taille à l'écran (une fois dans la partie supérieure de l'écran, une fois dans la partie inférieure, mais pas de facon exactement symétrique).

En assembleur tu pourrais afficher ca en movem, en initialisant les registres une fois pour 2 affichages, ca sauverait du temps.

Sinon la facon demomaker serait de "sacrifier" 8 couleurs, alors inutilisables pour autre chose, pour faire cet effet uniquement via des timers dans des motifs verticaux courbés. Ca prendrait un temps machine assez modeste, celui de changer la palette à chaque ligne. L'inconvenient est que tu aurais droit a un motif qui se repete tous les 8 (gros) pixels.

Il faudrait par contre restaurer ce fond (localement) quand il est modifié par des sprites.

[rocky007]

merci à tous

la démo est déjà compilée malheureusement, donc ajouter un double buffering ralentirait encore plus la demo, qui est déjà à la limite du tolérable

transformer ceci en démo n'était pas le but, c'était surtout tester une idée mais si je trouve un peu de temps, peut-être que j'en ferais une version plus aboutie en assembleur.  en tous cas, c'était marrant de se replonger dans l'atari

j'avais pensé aussi à déformer l'image autrement :  une oscillation qui augmenterait de plus en plus sur l'image, créant des dizaines de "vagues" dans l'image, c'est peut-être cet effet qui me motivera

dans la première version la déformation est calculée en GFA ( le premier essai avec mes carrés ) mais je n'étais pas satisfait de mes courbes et cela nécessitait des ajustements.   plutôt que perdre du temps à ça, et profitant d'avoir un rendu 3d sur le pattern , j'ai utilisé photoshop en mode 3D. j'ai calculé 17 images ( 0->16° par pas de 1° ), ensuite converti le tout en PI1.  on voit clairement la différence de rendu entre la version tube et la version tunnel où je n'avais pas ajouté les ombrages pour tenter de les faire en raster.  mais le pattern comportant trop de différents gris, je n'ai pas eu le temps de coder la table des dégradés.

[rocky007]

En assembleur tu pourrais afficher ca en movem, en initialisant les registres une fois pour 2 affichages, ca sauverait du temps.

Sinon la facon demomaker serait de "sacrifier" 8 couleurs, alors inutilisables pour autre chose, pour faire cet effet uniquement via des timers dans des motifs verticaux courbés. Ca prendrait un temps machine assez modeste, celui de changer la palette à chaque ligne. L'inconvenient est que tu aurais droit a un motif qui se repete tous les 8 (gros) pixels.

Il faudrait par contre restaurer ce fond (localement) quand il est modifié par des sprites.

oui bonne idée, ce serait d'autant plus utile si je fait un effet de vague où il y aura plus que 2 répétitions...

[A1WSX]

L'effet est vraiment réussi, bravo rocky007 !

[ryosaeba]

j'ai trouvé le problème pour l'encodage, je capturais en 320x200, et évidement les artefacts de compression bousillait tout...

vous êtes difficile , voilà mon tube en mode tunnel...( n'oublions pas que c'est juste un essai, pas un demo que je vais sortir )

La conversion est superbe et en GFA !!!! Serait-il possible de l'inclure dans une demo ou un jeu si codé en ASM ?

[stapha92]

merci à tous

la démo est déjà compilée malheureusement, donc ajouter un double buffering ralentirait encore plus la demo, qui est déjà à la limite du tolérable

transformer ceci en démo n'était pas le but, c'était surtout tester une idée mais si je trouve un peu de temps, peut-être que j'en ferais une version plus aboutie en assembleur.  en tous cas, c'était marrant de se replonger dans l'atari

j'avais pensé aussi à déformer l'image autrement :  une oscillation qui augmenterait de plus en plus sur l'image, créant des dizaines de "vagues" dans l'image, c'est peut-être cet effet qui me motivera

dans la première version la déformation est calculée en GFA ( le premier essai avec mes carrés ) mais je n'étais pas satisfait de mes courbes et cela nécessitait des ajustements.   plutôt que perdre du temps à ça, et profitant d'avoir un rendu 3d sur le pattern , j'ai utilisé photoshop en mode 3D. j'ai calculé 17 images ( 0->16° par pas de 1° ), ensuite converti le tout en PI1.  on voit clairement la différence de rendu entre la version tube et la version tunnel où je n'avais pas ajouté les ombrages pour tenter de les faire en raster.  mais le pattern comportant trop de différents gris, je n'ai pas eu le temps de coder la table des dégradés.

Je me disais que le GFA était vraiment rapide...Bon, même pour du compilé, le gfa a l'air performant.

Ok je comprend. En même temps l'utilisation de photoshop permet d'avoir un filtrage sur le zoom, ce qui rend bien mieux qu'un zooming brut.

C'est le double buffering qui ralentirait ? C'est pas l'attente vbl plutôt ? Je connais pas le GFA, c'est pourquoi je demande.

Sinon, je ne suis pas du tout d'accord ! La vitesse de ta démo n'est pas à la limite du tolérable, pas du tout !   

La conversion est superbe et en GFA !!!! Serait-il possible de l'inclure dans une demo ou un jeu si codé en ASM ?

Je me permet de te répondre Ryosaeba : Rocky me corrigera si besoin.

En assembleur, ça tournerait à 50 images/secondes. ça laisse plus d'une frame si c'était intégré dans un effet/jeu à 25 images/secondes. Y a de la marge...
En plus en assembleur, ça aurait d'autres avantages :
 - Moins de place mémoire car la possibilité de stocker ça sur 3 plans. Il n'y aurait je pense pas de perte de qualité en 8 couleurs.
 - Pleins de variations possibles, comme celle dont rocky à parlé. Je ne crois pas trop au système 1 lecture -> plusieurs écritures car il faudrait multiplier ou complexifier les routines. ça compliquerait le truc alors qu'il faut se caler sur la version la plus lente. Et comme dans le pire des cas, on a 1 lecture pour 1 écriture...
De toute façon, même sans ça l'effet seul serait à 50 i/s.
 - Pas besoin que la texture soit symétrique : la symétrie pourrait être créée en choisissant les bonne lignes.

Et il faut garder à l'esprit que Rocky a choisi une petite texture pour aller vite mais que son système permet d'en prendre une qui fasse toute la largeur de l'écran... 

Dernier point : Rocky redessine tout l'écran. Ce qui apporte des avantages car il n'y a pas de restauration à faire.

[Nextome]

j'ai trouvé le problème pour l'encodage, je capturais en 320x200, et évidement les artefacts de compression bousillait tout...

vous êtes difficile , voilà mon tube en mode tunnel...( n'oublions pas que c'est juste un essai, pas un demo que je vais sortir )

ha oui quand même... bravo.

[Invité]

Le nom de YouTUBE n'a jamais eu autant de sens.

[Invité]

Le nom de YouTUBE n'a jamais eu autant de sens.

[stapha92]

Le nom de YouTUBE n'a jamais eu autant de sens.

Trop fort !!! 

[dam's]

Oui, bravo Rocky! 
Et puis c'est cool, le topic respire le calme depuis 2 pages!

[dlfrsilver]

Bien vu et bien joué Rocky, bel effort !!!

Bon maintenant la séance fendage de gueule de ce soir (pas voulu ni cherché de ma part).

Ma compagne m'appelle pour venir manger, et ce faisant je laisse tourner mon Atari 520 STE (4mo de ram!) avec de la musique en fond sonore.

On mange, et après avoir fini le repas, pendant qu'elle regarde sa série préférée à la télé, elle me balance dans les dents :

Elle : "C'est quoi ce son de merde ? D'ou ça vient ?"
Moi : "tu viens de faire connaissance avec le son de l'atari ST, qu'est-ce que tu en dis"
(je précise, elle est musicienne dans un orchestre)
Elle : "Mais c'est merdique, quelle horreur pour les oreilles ce truc !"
Moi : "Ben quoi ? Tu préfères le son de l'Amiga ?"
Elle : "ah bah largement, y a pas de mal ! L'amiga c'est du son digital au moins, c'est bien plus agréable à l'oreille. Moi ça vrille les nerfs !"
Moi : "Hé oh ! t'as quelque chose contre le son 8 bits ?"
Elle : "Coupe-moi ça, ou je le fais moi-même !"

Je m'en suis retourné tout penaud et tout péteux..... J'imagine les mecs ayant un Atari ST/E avec madame derrière qui les pourrit en leur disant arrête de faire suffoquer des moutons en mettant leur tête dans ton cul, ça les fait couiner, et c'est insupportable !!"

[rocky007]

C'est le double buffering qui ralentirait ? C'est pas l'attente vbl plutôt ? Je connais pas le GFA, c'est pourquoi je demande.

Sinon, je ne suis pas du tout d'accord ! La vitesse de ta démo n'est pas à la limite du tolérable, pas du tout !   

La conversion est superbe et en GFA !!!! Serait-il possible de l'inclure dans une demo ou un jeu si codé en ASM ?

Je me permet de te répondre Ryosaeba : Rocky me corrigera si besoin.

En assembleur, ça tournerait à 50 images/secondes. ça laisse plus d'une frame si c'était intégré dans un effet/jeu à 25 images/secondes. Y a de la marge...
En plus en assembleur, ça aurait d'autres avantages :
 - Moins de place mémoire car la possibilité de stocker ça sur 3 plans. Il n'y aurait je pense pas de perte de qualité en 8 couleurs.
 - Pleins de variations possibles, comme celle dont rocky à parlé. Je ne crois pas trop au système 1 lecture -> plusieurs écritures car il faudrait multiplier ou complexifier les routines. ça compliquerait le truc alors qu'il faut se caler sur la version la plus lente. Et comme dans le pire des cas, on a 1 lecture pour 1 écriture...
De toute façon, même sans ça l'effet seul serait à 50 i/s.
 - Pas besoin que la texture soit symétrique : la symétrie pourrait être créée en choisissant les bonne lignes.

Et il faut garder à l'esprit que Rocky a choisi une petite texture pour aller vite mais que son système permet d'en prendre une qui fasse toute la largeur de l'écran... 

Dernier point : Rocky redessine tout l'écran. Ce qui apporte des avantages car il n'y a pas de restauration à faire.

tu m'as induit en erreur en fait  !!  tu te souviens lorsque j'avais expliqué ma première méthode, tu m'avais répondu : Tu expliques pouvoir le faire en "modifiant l'adresse écran et en faisant du mirroring" : c'est  juste completement débile...

je viens de tester et cela fonctionne parfaitement, je suis à 50 FPS en GFA !  ( sans vsync )

c'est ta question sur le double buffering qui m'a fait douter... après ta réponse sur ma théorie, j'ai douté et pensé qu'on ne pouvait modifier l'adresse physique de l'écran, ce qui obligerait en cas de double buffering de recopier l'écran logique sur le physique et donc un bmove 32ko, raison pour laquelle je disais que ce serait plus lent...   mais ce n'est pas du tout vrai, et donc ma théorie de départ était bien correcte :

en double buffering :  je fais le mirror sur la futur image à afficher et ensuite pointe l'écran physique dessus ( mais aucun intérêt, autant même calculé toute l'image à l'avance et être au max de la vitesse )
sans buffering : je pointe l'écran physique sur l'image à afficher et j'en fait le mirror ( économie de 17*16ko )( mais problème de synchro )

j'économise un déplacement de 16ko, en assembleur il devrait me rester plus de 50% de la frame pour un effet.

pour l'optimisation "1 lecture" , elle est efficace pour un effet tunnel : on économise 100 chargements, il n'y a même pas d'algo puisqu'il suffit de précalculer leurs positions dans une table.   exemple :

adresse de la ligne #87 = 320000 et doit être affichée à la ligne 15 et 157
le tableau serait : 320000,15,157, etc...  il ne charge donc qu'une seule fois l'adresse source et le tableau ne prendrait presque pas de mémoire.

sinon pour répondre à Ryosaeba, si on utilise cette nouvelle méthode, je pense qu'il est facilement possible de faire un effet supplémentaire  ( un scrolltest, ou des sprites ) en 50 FPS, mais on se limite à un texture symétrique pour le tunnel.

pour la méthode Stapha, c'est à dire précalc chaque lignes sans mirror, c'est également possible :  j'avais déjà réfléchis avec la limitation de l'ancienne routine et avais imaginé un effet possible en 50 FPS :  des cylindres en raster qui rebondiraient sur un décors scrollant verticalement.  le raster dezoomerait pour simuler la chute et lorsqu'ils toucheraient le décors , celui-ci déformerait comme l'effet tunnel, en fonction de la taille du cylindre.

[stapha92]

Désolé de t'avoir induit en erreur Rocky. Ce que je voulais dire, c'est que l'idée de mirroring en changeant l'adresse de l'ecran n'avait aucun interet puisque tu pointes forcément sur un écran entier. C'est l'association des deux qui n'a aucun interet. Maintenant tu vois parfaitement ce que je voulais dire, on aura fini par se comprendre... 

Si tu pouvais changer l'adresse de l'écran PENDANT l'affichage, ça serait différent : tu la modifierais au début de l'affichage et juste avant la 101eme ligne (si tu pouvais utiliser un modulo négatif, sinon il faudrait le faire au debut des 100 dernières lignes).

C'est pourquoi quand tu m'as répondu qu'on ne pouvait pas changer l'adresse de l'écran "actif", je me suis dit que tu t'étais souvenu qu'un ST ne permet pas le changement de l'adresse de l'écran pendant l'affichage et que donc le "mirroring par adresse" n'était pas possible.

Su mig par exemple, tu peux la changer à n'importe quel moment et indiquer un modulo negatif : Là l'idée d'associer le changement d'adresse et le mirroring aurait un sens. C'est pourquoi j'avais dit que ça n'en avait pas sur le ST.

Et donc bien sur qu'un ST peut changer l'adresse de l'ecran. Le problème est que la modif n'intervient qu'au début de l'affichage et que l'octet de poids faible n'est pas pris en compte (obligeant à utiliser des adresses multiples de 256, ce qui empeche de s'en servir pour des scrollings verticaux).

Tu viens d'essayer cette méthode qui marche parfaitement mais tu as du mal regarder : En GFA, sans vsync, ça doit aller BIEN PLUS VITE que 50 i/s !!! 


Cela dit ta méthode via bmove a plusieurs avantages :
 - Elle prend 2 fois moins de RAM. Donc elle permet des textures 2 fois plus grandes.
 - Si tu veux dessiner des sprites par dessus l'effet, il n'y a pas besoin de restaurer le fond.


J'avais bien compris pour l'optim "1 lecture" mais le problème est que tu n'affiches pas toujours 2 fois la même ligne sur ton écran. Et vu que tu pars d'une autre texture que celle du haut de l'écran pour mirrorer
je dirai même qu'il n'y a jamais 2 fois la même ligne affichée dans ton effet.

[rocky007]

ok, on est enfin tombé d'accord, c'est un grand jour

ouip, on peut modifier que l'octet poid fort et moyen de l'adresse écran... mais contournable avec un "hardscroll".

pour revenir à cette 2ème méthode, j'ai qd même un doute : on n'utilisant pas de double buffering, on devrait pouvoir pointer sur les 16ko à afficher et en faire le mirroring directement sur l'écran physique tout en étant avant le balayage vertical, pour simplement se synchro à la fin de l'affichage pour la frame suivante.  on a quand même 1/2 frame d'avance pour afficher la seconde partie de l'écran.  et l'écrasement de la seconde partie de l'image ( qui est en fait la frame suivante de la 1ere moitié ) par le mirror  ne sera pas visible puisqu'elle se fera avant l'arrviée du balayage.

pour l'optim "1 lecture", c'est vrai je n'avais pas plus pensé à ça, les deux 1/2 d'écran ne sont pas parfaitement opposées

[stapha92]

ok, on est enfin tombé d'accord, c'est un grand jour

ouip, on peut modifier que l'octet poid fort et moyen de l'adresse écran... mais contournable avec un "hardscroll".

pour revenir à cette 2ème méthode, j'ai qd même un doute : on n'utilisant pas de double buffering, on devrait pouvoir pointer sur les 16ko à afficher et en faire le mirroring directement sur l'écran physique tout en étant avant le balayage vertical, pour simplement se synchro à la fin de l'affichage pour la frame suivante.  on a quand même 1/2 frame d'avance pour afficher la seconde partie de l'écran.   toute la question est de savoir si l'écrasement de la seconde partie de l'image ( qui est en fait la frame suivante de la 1ere moitié ) par le mirror sera visible ou pas ( cela se fait quand même en moins d'1/120eme de seconde ).

A marquer d'une pierre blanche 

Si toutes tes frames sont stockées sur 16 Ko et que tu pointes dessus, lorsque tu feras ton mirroring tu ecraseras la frame suivante...
Seul moyen d'éviter ça : espacer tes frames de 16 Ko afin de laisser libre la partie qui sera utilisée pour le mirroring. Mais ça revient à stocker des frames de 32 ko : on retombe sur la méthode de stockage par écran entier...

[rocky007]

ah ben  oui juste, t'as raison c'était débile    comment ne pas avoir pensé à ce détail aussi gros qu'une maison...

[stapha92]

Ben c'est arrivé à tous ceux qui ont cherché des optims, moi le premier... 

En même temps, ça veut dire que ton système est le meilleur en GFA. En tout cas moi je vois pas comment faire mieux.

Tu peux peut-être gagner sur l'implémentation (dérouler tes bmoves par exemple). Mais tu as déjà du le faire.

En tout cas au niveau algo, je pense que tu as trouvé le meilleur moyen. Ton idée de faire un seul bmove pour la première moitié et se servir d'une autre frame pour le mirroring est très bonne. A mon avis, elle offre le meilleur compromis entre espace mémoire et rapidité en GFA.

[Invité]

ca y est c'est la paix sur le topic


mais a la fin c'est le ST ou l'amiga qui gagne?

[rocky007]

le ST bien sûr ! 

petite question pour les experts, c'est quoi le bidule avec les 2 floppys au dessus de l'atari ?
un "desktop" spécial pour accueillir les drives du 520 ?

[Invité]

ST, Super Trashcan en anglais,j'invente rien 

[barbarian_bros]

le ST bien sûr ! 

petite question pour les experts, c'est quoi le bidule avec les 2 floppys au dessus de l'atari ?
un "desktop" spécial pour accueillir les drives du 520 ?

Trouvé (à priori sur le site d'où vient l'image) :
Il s'agit d'une 'Micro Mate 520 STation'.
Le ST première version n'avait pas de lecteur intégré (on voit bien sur la photo le cable de la souris qui part de l'emplacement occupé par le lecteur sur les modèles suivants), il fallait donc un lecteur externe, ou 2 pour pour faire facilement des copies.
La STation permettait de ranger efficacement ces lecteurs de façon accessible (juste au dessus de l'ordi), tout en économisant de la place puisqu'on peut poser le moniteur dessus, et une boite de rangement pour disquettes ou des manuels à côté du moniteur.
On mettait les 2 lecteurs sur la gauche, la partie de droite n'est qu'un cache qui permet de ranger/cacher les blocs d'alimentation des lecteurs et celui du ST (le premier modèle n'avait pas non plus d'alim intégrée) ainsi que l'excédent de longueur des câbles de connexion des lecteurs.
Je suppose qu'à l'origine c'était livré aussi avec un cache à gauche si on ne possédait qu'un seul lecteur.

C'est en métal (ça supporte donc sans problème le poids des alims et du moniteur, et c'est surélevé, on peut donc glisser le ST dessous le ranger, ou  pour ne laisser dépasser que le clavier quand on s'en sert, du coup on a besoin d'un bureau/plan de travail bien moins profond. (un STf/e est plus profond à cause du lecteur et de l'alim intégrés et donc dépassera toujours un peu).
D'après la pub on peut aussi tout connecter pour avoir un seul interrupteur pour allumer tous les éléments.

Une autre photo de l'engin non monté :


C'est quand même la classe comme configuration, il ne manque qu'un disque dur SH204 (le modèle 'boite à chaussure' ) posé à côté de l'écran :


Source :
1 article sur bytecellar.com
L'auteur a aussi un compte Flickr où il a posté plein de photos du montage de l'engin :
My Atari 520 Setup

[rocky007]

merci pour l'info.  en effet, ça donne pas mal, ça permet de ranger tout ce bazar de façon élégante.

même madame est contente de plus voir tous ces câbles par terre..