GUERRE ST-AMIGA, FIGHT !!!

Page 31 sur 34 Précédent  1 ... 17 ... 30, 31, 32, 33, 34  Suivant

Voir le sujet précédent Voir le sujet suivant Aller en bas

Qui a gagné la grande guerre ST-AMIGA ?

29% 29% 
[ 5 ]
71% 71% 
[ 12 ]
 
Total des votes : 17

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par TOUKO le Mar 13 Oct 2015 - 9:23

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

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 .

TOUKO
Interne
Interne

Nombre de messages : 10057
Date d'inscription : 08/07/2010

http://touko-dev.blog.fr/

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par rocky007 le Mar 13 Oct 2015 - 13:25

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

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



rocky007
Guéri miraculeux

Masculin Nombre de messages : 2563
Age : 42
Date d'inscription : 29/01/2011

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par kaot le Mar 13 Oct 2015 - 13:32

hoho.bien ouej thumleft

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

kaot
Patient incurable

Masculin Nombre de messages : 1590
Age : 38
Localisation : la bas
Date d'inscription : 12/02/2015

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par TOUKO le Mar 13 Oct 2015 - 13:50

C'est vraiment pas mal là .

TOUKO
Interne
Interne

Masculin Nombre de messages : 10057
Age : 43
Localisation : LE MANS/MARSEILLE
Date d'inscription : 08/07/2010

http://touko-dev.blog.fr/

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par rocky007 le Mar 13 Oct 2015 - 13:54

@kaot a écrit:hoho.bien ouej thumleft

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

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

rocky007
Guéri miraculeux

Masculin Nombre de messages : 2563
Age : 42
Date d'inscription : 29/01/2011

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par TOUKO le Mar 13 Oct 2015 - 14:10

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 ??

TOUKO
Interne
Interne

Masculin Nombre de messages : 10057
Age : 43
Localisation : LE MANS/MARSEILLE
Date d'inscription : 08/07/2010

http://touko-dev.blog.fr/

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par stapha92 le Mar 13 Oct 2015 - 18:01

@TOUKO a écrit:
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 ! Mr. Green

ç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é.

@rocky007 a écrit: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 ?

stapha92
Patient contaminé

Masculin Nombre de messages : 506
Age : 47
Localisation : Région parisienne
Date d'inscription : 16/08/2010

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par TOUKO le Mar 13 Oct 2015 - 18:36

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

TOUKO
Interne
Interne

Masculin Nombre de messages : 10057
Age : 43
Localisation : LE MANS/MARSEILLE
Date d'inscription : 08/07/2010

http://touko-dev.blog.fr/

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par Seb le Mar 13 Oct 2015 - 18:46

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.

Seb
Patient contaminé

Masculin Nombre de messages : 543
Age : 100
Localisation : Canada / France
Date d'inscription : 14/01/2015

http://www.gamopat-forum.com/t76752p25-collection-principalement

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par rocky007 le Mar 13 Oct 2015 - 21:10

merci à tous Wink

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 Wink

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 Wink

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 Wink

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
Guéri miraculeux

Masculin Nombre de messages : 2563
Age : 42
Date d'inscription : 29/01/2011

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par rocky007 le Mar 13 Oct 2015 - 21:18

@Seb a écrit:
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...

rocky007
Guéri miraculeux

Masculin Nombre de messages : 2563
Age : 42
Date d'inscription : 29/01/2011

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par A1WSX le Mar 13 Oct 2015 - 22:33

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

A1WSX
Patient en incubation

Masculin Nombre de messages : 76
Age : 44
Localisation : France
Date d'inscription : 08/05/2012

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par ryosaeba le Mer 14 Oct 2015 - 17:30

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

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


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

ryosaeba
Infirmier

Masculin Nombre de messages : 3549
Age : 42
Date d'inscription : 02/07/2009

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par stapha92 le Mer 14 Oct 2015 - 18:12

@rocky007 a écrit:merci à tous Wink

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 Wink

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 Wink

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 Wink

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 !  Wink 


@ryosaeba a écrit: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...  Wink

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

stapha92
Patient contaminé

Masculin Nombre de messages : 506
Age : 47
Localisation : Région parisienne
Date d'inscription : 16/08/2010

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par Nextome le Mer 14 Oct 2015 - 18:42

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

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


ha oui quand même... bravo.

Nextome
Patient contaminé

Masculin Nombre de messages : 316
Age : 42
Localisation : Beaune
Date d'inscription : 17/03/2015

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par onels4 le Mer 14 Oct 2015 - 18:43

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

onels4
Docteur Modérateur ****
Docteur Modérateur ****

Masculin Nombre de messages : 69678
Age : 35
Localisation :
Date d'inscription : 22/05/2011

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par TOUKO le Mer 14 Oct 2015 - 18:52

@onels4 a écrit:Le nom de YouTUBE n'a jamais eu autant de sens.
MDR

TOUKO
Interne
Interne

Masculin Nombre de messages : 10057
Age : 43
Localisation : LE MANS/MARSEILLE
Date d'inscription : 08/07/2010

http://touko-dev.blog.fr/

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par stapha92 le Mer 14 Oct 2015 - 18:55

@onels4 a écrit:Le nom de YouTUBE n'a jamais eu autant de sens.
Trop fort !!!  MDR MDR MDR

stapha92
Patient contaminé

Masculin Nombre de messages : 506
Age : 47
Localisation : Région parisienne
Date d'inscription : 16/08/2010

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par dam's le Mer 14 Oct 2015 - 23:21

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

dam's
Patient contaminé

Masculin Nombre de messages : 448
Age : 40
Date d'inscription : 17/10/2009

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par dlfrsilver le Ven 16 Oct 2015 - 21:16

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 !!"

dlfrsilver
Patient incurable

Masculin Nombre de messages : 1182
Age : 39
Date d'inscription : 29/05/2009

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par rocky007 le Ven 16 Oct 2015 - 21:19

@stapha92 a écrit: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 !  Wink 


@ryosaeba a écrit: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...  Wink

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... Mr. Green

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.

rocky007
Guéri miraculeux

Masculin Nombre de messages : 2563
Age : 42
Date d'inscription : 29/01/2011

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par stapha92 le Sam 17 Oct 2015 - 9:59

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...  Wink

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 !!!  Wink


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.

stapha92
Patient contaminé

Masculin Nombre de messages : 506
Age : 47
Localisation : Région parisienne
Date d'inscription : 16/08/2010

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par rocky007 le Sam 17 Oct 2015 - 11:12

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

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


Dernière édition par rocky007 le Sam 17 Oct 2015 - 12:06, édité 1 fois

rocky007
Guéri miraculeux

Masculin Nombre de messages : 2563
Age : 42
Date d'inscription : 29/01/2011

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par stapha92 le Sam 17 Oct 2015 - 11:39

@rocky007 a écrit:ok, on est enfin tombé d'accord, c'est un grand jour Wink

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  Wink

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...

stapha92
Patient contaminé

Masculin Nombre de messages : 506
Age : 47
Localisation : Région parisienne
Date d'inscription : 16/08/2010

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par rocky007 le Sam 17 Oct 2015 - 12:07

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

rocky007
Guéri miraculeux

Masculin Nombre de messages : 2563
Age : 42
Date d'inscription : 29/01/2011

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par stapha92 le Sam 17 Oct 2015 - 13:09

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

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.

stapha92
Patient contaminé

Masculin Nombre de messages : 506
Age : 47
Localisation : Région parisienne
Date d'inscription : 16/08/2010

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par kaot le Sam 17 Oct 2015 - 18:14

ca y est c'est la paix sur le topic


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

kaot
Patient incurable

Masculin Nombre de messages : 1590
Age : 38
Localisation : la bas
Date d'inscription : 12/02/2015

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par rocky007 le Sam 17 Oct 2015 - 19:57

le ST bien sûr !  Mr. Green

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 ?



rocky007
Guéri miraculeux

Masculin Nombre de messages : 2563
Age : 42
Date d'inscription : 29/01/2011

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par TOUKO le Sam 17 Oct 2015 - 20:23

ST, Super Trashcan en anglais,j'invente rien  Mr. Green

TOUKO
Interne
Interne

Masculin Nombre de messages : 10057
Age : 43
Localisation : LE MANS/MARSEILLE
Date d'inscription : 08/07/2010

http://touko-dev.blog.fr/

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par barbarian_bros le Sam 17 Oct 2015 - 20:35

@rocky007 a écrit:le ST bien sûr !  Mr. Green

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

barbarian_bros
Docteur *
Docteur *

Masculin Nombre de messages : 4171
Age : 39
Localisation : 33
Date d'inscription : 29/11/2009

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par rocky007 le Sam 17 Oct 2015 - 22:36

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..


rocky007
Guéri miraculeux

Masculin Nombre de messages : 2563
Age : 42
Date d'inscription : 29/01/2011

Revenir en haut Aller en bas

Re: GUERRE ST-AMIGA, FIGHT !!!

Message par Contenu sponsorisé Aujourd'hui à 8:02


Contenu sponsorisé


Revenir en haut Aller en bas

Page 31 sur 34 Précédent  1 ... 17 ... 30, 31, 32, 33, 34  Suivant

Voir le sujet précédent Voir le sujet suivant Revenir en haut

- Sujets similaires

 
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum