Re: GUERRE ST-AMIGA, FIGHT !!!

[stapha92]

ah tiens tu retournes encore ta veste... quand je dis que ça émule aussi mal le mac qu'un émulateur C64, ça vient faire sa froufou avec son hardware cycle exact que personne n'a ne fut-ce abordé le sujet, et maintenant tu oses répondre que si ça n'émulait aucun jeu, on s'en fout.  c'est plutôt toi qui s'accroche aux branches et avec en bonus de jolies pirouettes...  

Surement pas : c'est TON habitude de t'accrocher aux branches quand tu réalises avoir dit une énormité.
Tu as parlé de la difficulté à émuler correctement un C64. Cette difficulté vient de l'obligation à faire une émulation cycle-exact. ça prend énormement de ressource. A un point qui est incomparable avec une émulation HLE.
J'ai dit "les applications bureautiques du ST on s'en fout, on avait celle du Mac avec l'émulation". C'est la seule fois ou j'ai parlé d'émulation du Mac avant de venir dans ce débat quand je t'ai vu utiliser l'émulation C64 pour expliquer que celle du Mac était impossible.
Cite moi le post ou je dis qu'on emulait un Mac pour les jeux.

quant à babsinov est ses vidéos avec A1200+ carte accélératrice + HD + carte vidéo + émulateur mac dernière révision 1994 + drivers spécifiques et peut-être patches, oui cool ça fonctionne enfin... on est loin du A500 en 1987 non ?

Patchs ? Donc tu crois vraiment qu'il y avait des patchs pour faire tourner ces jeux sur ShapeShifter ou Fusion ? Tu es trop drole...

Oui, on est loin de l'A500 de 87 c'est sur. Une question : ils sont de 87 les jeux que Babsimov t'a montré ?
Ils tournent sur un Mac de 87 ? 
Soit pas ridicule voyons ! 

alors je cite :

Quantum Paint : Mode 4K uses a special technique called "interlacing" in order to display 4,096 colors.  on est d'accord ce n'est pas l'entrelacement tel qu'on le connait en vidéo, mais plus un swapping d'écran.  j'ai oublié en effet les guillements

Oui tu cites, tu cites... mais tu ne comprends pas : Ils se sont foutus de vous !!!!

C'est pas les guillement le problème. J'ai bien compris dans quel sens "interlacing" est utilisé. Le problème est le nombre de couleurs.

Oui c'était bien écrit 4096 couleurs sur la boite mais c'était 3375. Pas de ma faute si la plupart des Stistes ne s'en rendaient pas compte. A l'époque je trouvais ça curieux qu'aucun ne s'en rendait compte. Mais j'aurais cru que maintenant tout le monde ou presque savait. Quand je vois que ce topic a été cité par un forum Atari et qu'on m'a traité d'ignare quand j'ai expliqué ça (heureusement, il y a des Stistes connaisseurs qui m'ont donné raison) je me dis qu'on est loin du compte...

2 couleurs affichées de façon alternées à chaque frame permettent d'obtenir la couleur intermédiaire au prix d'un scintillement léger. Chaque composante RVB se règle sur 8 niveau dans un ST. Avec 8 valeurs, tu ne peux créer que 7 valeurs intermédiaires. ça fait 15 en tout. D'ailleurs dans les logiciels de ST qui utilisent ce système, l'echelle RVB va de 0 à 14  pour chaque composante (ou alors c'est de l'esbrouffe).
Or 15x15x15 = 3375 couleurs. CQFD

Le mig peut utiliser le même système pour obtenir 29791 couleurs (et non pas 32768) avec un scintillement 2 fois plus faible.

La routine son de Vroom ?  tu parles de l'exemple que tu as donné en en prétendant qu'il fallait encore ajouter la routine de bouclage, alors qu'elle était intégrée ?  pourtant, le code n'était pas bien long à lire

Tu crois franchement que tu peu me donner des leçons sur de la lecture d'assembleur 68000 alors que tu as du mal à lire des posts ?
C'est trop te demander de comprendre mes réponses ? je t'ai remis en place sur ce point. Tu ne l'as plus abordé et maintenant tu reviens ? Tu es vraiment gonflé...

JE N'AI JAMAIS DIT QUE LE BOUCLAGE N'ETAIT PAS DANS LA ROUTINE, J'AI DIT QUE JE N'EN AVAIS PAS TENU COMPTE DANS LE CALCUL !!!!  APPRENDS A LIRE !!!!

Tiens relis. Peut-être qu'à la 3eme fois tu vas comprendre...

rocky007 a écrit:

980 000 cycles pour jouer un sample : 
        - à 5 Khz 
        - sur une seule voie 
        - sans variation de tonalité 
        - sans tenir compte du bouclage 
        - En réservant 4 registres
On est pourtant au-delà des 850 000 cycles qu'il restait au ST... 

ah bon ?  ton sample ne boucle pas ??  

lea.l   sample,a6
move.l  sample_length(pc),position

ça sert à quoi selon toi ?  à faire joli ?

mais je te l'accorde, le bruit des voiture concurrentes n'est pas géré dans ce cas.
pour la tonalité, je dois réécouter le jeu, car si c'est simplement la freq du playback qui varie, cela donne encore plus de temps au ST.
5khz pour un bruit de moteur ça me parait correct.

ça sert à quoi ? A remettre le pointeur au début du sample et à recharger sa longueur. Ces 2 opérations assurent donc le bouclage. 
On est d'accord. 

Qu'est-ce que j'avais posté  déjà ? 

ça :

    movem.l d0-d1/a6,-(sp)         
    move.l  usp,a6                     (4) 
    moveq.l #0,d0                      (4) 
    move.b  (a6)+,d0                   (8) 
    lsl.w   #3,d0                      (12) 
    subq.l  #1,position                (8)
    bne.s   .play                      (10) 
    lea.l   sample,a6
    move.l  sample_length(pc),position         
.play
    move.l  a6,usp                    (4)
    lea.l   $ffff8800.w,a6            (8)
    movem.l .da_table(pc,d0.l),d0/d1  (34) 
    movep.l d0,(a6)                   (24) 
    move.l  d1,(a6)                   (8) 
    movem.l (sp)+,d0-d1/a6         
    rte         


J'ai mis le nombre de cycles entre parenthèses. J'ai ignoré les sauvegarde et les restaurations des registres utilisés, et le repositionnement au début du sample.

Tu n'as pas remarqué que je n'ai pas mis le nombre de cycles pour ces 2 lignes ? Tout comme pour les movem. 
C'est exactement ce que j'explique juste après. Je ne dis pas que le sample ne boucle pas. je dis que je n'ai pas tenu compte de ce bouclage dans mon calcul... 

Tu es tellement persuadé que je triche dans mes affirmations que tu perds toute objectivité dans ta lecture...

Même sans la variation de tonalité, sans la gestion multivoie, sans sauvegarde de registres et en se limitant à des samples de 5 Khz ON DEPASSE DEJA LES 10 % de CPU !!! Rajoute tout ce qui manque et les 10 % sont carrément EXPLOSES !!!

changer les couleurs en interruption sur un ST le fait aussi bien que le copper en effet.  ok, le copper c'est gratuit , le ST non, mais visuellement le résultat est là.  il faut reprendre le contexte dans laquelle la phrase était, ce qui tu as bien évidement omis.  on parlait à ce moment du fameux ambermoon et ses 64? couleurs que certains prétendaient que le résultat serait moche sur ST, alors que les zone menu / fenêtre de jeux et inventaires étaient horizontalement clairement définie.

Euh non pas du tout. "En effet" n'est pas un terme magique qui change la réalité. Tu peux l'utiliser, tu n'auras pas plus raison pour autant...
Par interruption, le ST fera 16 changement de couleur par ligne. Obligation d'utiliser du code synchronisé sans interruption pour atteindre 48 changements (sans interruption, ça ne marche pas si on met un processeurs plus rapide...). Et ces 48 coueurs, en fait c'est une palette pour chaque 1/3 de ligne : obligation de redéfinir même les couleurs qui ne changent pas.

Le copper c'est 57 changement par ligne. Ces changements se font slot par slot et à chaque fois sur celui que l'on veut. On n'est pas obligé de redéfinir une couleur qui ne change pas. Visuellement, ça n'a rien à voir.

Non je ne parlais pas d'Abermoon, je parlais de ça :

sur Atari, c'est du full overscan 416x228 30k colors...

sans mode HAM, avec copper, l'amiga ne peut dépasser 16 couleurs lignes, et en HAM, ce mode est tellement lourds que l'amiga ne sait plus rien faire. ( oui à part bouger un sprite hardware )

Ou ça

de mémoire, la copper est limité à 16 couleurs/ ligne.

Ou encore ça :

désolé de te contredire, mais le mode 512 / 4096 couleurs des ST et largement supérieur, car plus de couleur par ligne

Ridicule... Tu étais tellement enthousiaste que tu expliquais, sur de toi, que le ST était mieux adapté à la photographie que le mig... Mon pauvre...

pour l'affichage vidéo, tu n'as pas prouvé le contraire.  moi par contre, je t'ai cité les débits théoriques des meilleurs HD SCSI et du SCSI TT et prouvé que techniquement c'était probablement faisable.  du reste l'auteur de player n'a jamais fait le moindre test sur un HD SCSI.  j'ai cité le TT car SCSI d'origine.

Ah bon ? tu as prouvé quelque chose toi ? Quand ? Quand tu as posté un avi en 768x576 sans te rendre compte du format qui était celui de la tnt ?
Refais les calcul pour la bande passante. En tenant compte du fait que la RAM n'est pas disponible pendant l'affichage (les changements de palette) soit presque 3/4 du temps. Tu arriveras à un débit que la RAM elle même ne peut pas atteindre !
Si tu ne peux pas comprendre ça, faut que tu ailles travailler un peu sur les concepts que tu n'arretes pas d'aborder.

Et puis pour un ST/F, afficher une IMAGE FIXE EN 416x228 x 48 coul/ligne EST IMPOSSIBLE !!!!

Alors en vidéo... Tu connais mal la machine que tu idolatres...

pour le C2P blitter, peux-tu citer une démo qui utiliser cette technique sur un A500 ?

Pourquoi ? Tu n'as pas dit que ce n'était pas utilisé, tu as dit que c'était impossible. J'ai prouvé le contraire non ? T'essaies pas de te raccrocher aux branches ?

Pas de bol, les branches se cassent : il y a pleins de démos qui le font. Comme celle que je t'ai citée pour le HAM en voxel (Planet Rocklobster). Lis son readme.txt :

https://github.com/AxisOxy/Planet-Rocklobster

mais t'as raison, je me suis planté sur le HAM, tout comme le nombre de changement couleur COPPER / ligne.  néanmoins, je reste assez satisfait de mes connaissances malgré mon manque total d'expérience en coding sur amiga face aux "spécialistes" de l'amiga ici.

Heureux de voir que tu ne m'accuses pas d'avoir déformé tes propos cette fois. Mais y a pas que ces 2 points, regarde au dessus. Cependant on progresse.

Je dois avouer que je suis d'accord avec ta conclusion. Et tu peux y ajouter d'autres points généraux :
 - Tu as raison : il est possible de faire un OS multitache préemptif et performant sur le ST. Si ça s'est avéré compliqué, c'est à cause de la compatibilité. Pas à cause de l'architecture de la machine.
 - 512 ko de RAM au moment de la sortie du ST, à ce prix, c'était ENORME !

le principe de l'effet reste le même, si pour toi modifier une partie de la routine, par oubli, c'est se ridiculiser, te dois souvent avoir le moral à zero mon pauvre.

J'ai pas dit ça. Relis le passage ou tu dis que ta méthode (qui ne marche pas) est meilleure que celle que j'ai proposé (que tu vas finir par adopter) et tu comprendras ce que je veux dire

Et tout ça SANS les plate-formes : dois-je te rappeler que tu as prétendu pouvoir reproduire l'effet AU COMPLET en GFA avec 600 Ko ?...

dois-je te rappeler que j'ai avouer ce troll pour ensuite corriger mes propos il y a belle lurette ?  y'a vraiment que toi pour prendre au pied de la lettre le troll de prétendre refaire un effet assembleur A500 rotozoom et compagnie jamais vu même dans les meilleures mégademo Atari ST, et cela en GFA  . évidement, si tu prends mes premiers écrit sans en tenir compte de mes corrections... mais écoutes, plutôt que de parler, je vais prendre un peu de temps pour coder ça et on en rediscutera.  

Si tu te relis ce n'étais pas vraiment du troll... Mais bon, oublions ça.

Je te répète ce que j'ai déjà dit : Si tu codes ça en utilisant une méthode à laquelle je n'avais pas pensé et bien ça ira vite d'en rediscuter : je te féliciterai et te remercierai de m'avoir montré une méthode qui m'était inconnue.

Mon propos était de dire que l'émulation pouvait dépanner (et ça a été le cas pour moi avec PC-TASK et des compilos BORLAND sous DOS). Rien de plus.

"dépanner"..pour un carte à ce prix, je trouve cela inadmissible.    "dépanner", ça ressemble à un aveu de "en fait ça marchait vraiment pas bien mais dire que tu as raison me trouerais le c**"

Mais la carte ne sert pas qu'à ça ! Tu sais très bien tout ce dont un A1200 accéléré est capable.

Et un PC à 7500 Francs en 92 qui sera complètement obsolète moins de 2 ans après (286 à 12 Mhz...), c'est tout aussi inadmissible.

Dépanner signifie "si tu as besoin d'un PC de façon occasionnelle, l'émulation suffit". Et ça marchait très bien l'émulation PC.

Je te rappelle que, dès le début de cet échange, j'ai expliqué que je comprenais ton choix de prendre un PC pour pouvoir le maitriser dans une optique professionnelle.

Sur Amiga on n'utilise pas cette méthode. Du coup UAE et fellow n'ont pas besoin d'être cycle-exact.
Et vient pas me parler de l'option timing cycle-exact dans UAE. ça n'a rien à voir avec ce dont je parle.

ah non ?  et à quoi cela sert puisque selon toi ??  donc tu prétends que même sans émulation cycle exact , tout les jeux et démos Amiga  peuvent fonctionner ?  t'es de plus en plus fort... je suspecte que t'es bourré la gueule hier avec dlfrsilver.

C'est ça oui... Tu confond la vitesse du processeur émulé avec un type d'émulation bien précis.
T'es pas au courant que même le minimig n'est pas cycle-exact ? Pourtant bien compatible non ?
T'es pas au courant qu'on trouve des mig avec des tas de processeurs/vitesses différents ? Et qu'il n'y a jamais eu de système pour les faire tourner comme un mig d'origine (contrairement à un megaste) ?

Mais bon, si tu veux, on va dire que c'est la même chose (le jour ou tu étudieras le fonctionnement des émulateurs, tu comprendras...). Il n'empeche que ça change rien au point de départ : un Mac n'a pas besoin de ce genre de chose pour être émulé...

Non, ces cartes contiennent des processeurs X86 et, dans le cas du mig, sont reliées à des ports ISA. T'as déjà mis une carte réseau ou son dans un émulateur ? Moi pas..

adapter un lecteur 5/1/4 d'un PC sur un Atari, c'est pas de l'émulation.  donc quand on parle qu'une carte émulateur PC pour Atari fait de l'émulation, oui ça fait reste de l'émulation d'un ordinateur type PC.    tu as beau essayer de retourner la situation, c'est juste ridicule

Oui si ça te fait plaisir : une carte X86 relié à des cartes ISA issues du monde PC, ce n'est pas une machine, c'est de l'émulation...

1) Le 800 XL était vendu en pologne. Je n'ai rien contre nos amis polonais mais ils n'avaient pas le même niveau de vie que l'europe occidentale et les USA.

Trouve moi un ordinateur qui se vendait moins de 3-4000 Francs dans les pays occidentaux en 92 et qui a réussi à se vendre au même prix en 95 et on reparlera de pérennité...

on peut dire la même des USA et de la France.  nos amis français n'avaient pas le même niveau de vie que les américains, raison pour laquelle aux USA, dès 90-91, l'amiga a complétement disparu du marché américain au profit des PC / MAC.

combien de amiga se sont vendus à 4000FF en 95 ?  pourquoi Escom a coulé ?  jolie argumentation bancale, comme d'habitude.

Et alors ? Tu m'as trouvé un exemple d'ordinateur qui se vendait dans le même pays au même prix en 92 et en 95 ?

Tu m'as sorti le 800XL qui ne se vendait pas en pologne quand il se vendait dans les pays occidentaux et c'est moi qui a une argumentation bancale ? Tu es trop drole...

Combien de PC vendus 4000 Francs en 92 se vendaient 4000 Francs en 95 en France ?

change de PC alors.. preuve encore que le ST est toujours au top, l'original boot toujours plus vite que l'émulation sur un I7.  je sais pas d'où tu sors qu'un desktop prend 10 secondes à charger, demande à dlfrsilver, peut-être ton DMA est buggé  .  tu supposes quoi ? que c'est booté d'un HD et que j'ai édité la vidéo pour faire disparaître le boot HD ?  tu me fais trop d'honneur.

boot le GFA ?  ben oui je l'ai fait avec le HD, c'était très simple et rapide.  comme tu le dis, top de la convivialité, juste glisser à la souris, pas de truc horrible à taper comme à l'époque du DOS.
encore une fois, convivialité !

Oui bien sur...
Le problème, c'est qu'il n'y a pas que mon émulateur qui met plus de temps que ta vidéo. Il y a ton émulateur en mode fast drive aussi.
Et la vidéo que j'ai posté d'UN VRAI ST ? Tu vas me dire que le 68000 a été remplacé par un I7 ?

Très simple et très rapide ? Pourquoi tu ne l'as pas fait sur une disquette alors ?
Ton TOS/GEM si génial ne savait pas déplacer des fichiers pendant 5 ans. C'est pas ça le problème ?
Avec un HD tu as la place pour copier et supprimer le fichier source. Avec une disquette c'est plus compliqué : y a pas forcément la place.
Et il y a le patch à mettre pour pouvoir lancer un programme en Haute résolution.
Tu as une drole de vision de la convivialité...

Ce que je sais, c'est que si t'avais pu rendre facilement bootable ta disquette GFA facilement. Non seulement tu l'aurais fait, mais tu aurais une vidéo nous montrant la "simplicité" de la procédure...

oui c'est très lent en effet.  tiens au fait, est-ce bien sur un A500 d'origine en WB 1.3 ?  tiens ta vidéo, c'est sur un Amiga original ?

Oui très lent : quelques secondes de plus que ta vidéo suspecte qui arrive sur le bureau en 1/10 de seconde...
En tout cas ça boote tout seul sur une disquette et ça se prépare en 30 s.

Je n'ai pas d'A500. De toute façon je ne cherche pas à te convaincre, c'est peine perdue. Je cherche juste à montrer aux lecteurs que tes histoires de 45 secondes vs 5 minutes, c'est du n'importe quoi

Ensuite tu pars d'un bureau déjà ouvert et d'un accessoire déjà chargé...
Pourquoi avoir supprimé le chargement de l'accessoire ?
Pourquoi être repassé sur l'émulateur ? ça marche pas avec ton ST ?
Ça serait pas si simple que sur mig alors ? C'est sur que c'est convivial...
Pourquoi est-ce que la position de la souris change comme ça ?

ben on parle de l'horrible ST qui n'est pas multitâche..je constate que c'est tout aussi efficace d'une machine multitâche et tout aussi pratique, rapide.

j'ai repassé sur l'émulateur par facilité, ma souris ST étant crasseuse, mais imagines évidement un complot 
du reste pourquoi ça marcherait sur emulateur et pas sur ST ?  vraiment stupide encore.
la position souris ? c'est simple, tu switches entre deux états, je trouve cela au contraire très pratique qu'il sauvegarde ainsi la position de la souris.  imagines tu es en train de dessiner sur deluxe paint au pixel en zoom, mais tu as besoin de formatter une disquette : tu bascules, tu formates, et tu reviens exactement à la position à laquelle tu travaillais sans devoir te repositionner.  encore un avantage atari !  tu vas me dire que surement, en tapant 50 lignes dans le cli, il y aussi moyen de le faire. tu peux aussi te créer une page supplémentaire avec le bureau si cela te chante.  je vois pas trop l'intérêt de revenir sur le bureau, mais bon...oui on peut aussi le faire.

Oui bien sur, on te croit...
Un avantage la position de la souris ? Comme sa la position de ta souris sur ton tapis se retrouve régulièrement incohérente avec celle du pointeur ? Génial !!! Je commence à comprendre que tu ne trouves pas le mig convivial...

Tout aussi rapide ? On progresse : au début c'était plus rapide que le mig.
Tu devrais éditer ton commentaire sur youtube...

Et ton switcher, il prend combien de mémoire ?
Et il coutait combien à l'époque ? Sur le mig, c'est d'origine. Rien  ajouter.

le prg fait 14ko.

oui d'origine sur l'amiga, par contre il fallait acheter une action replay pour avoir un directory d'un disquette..la belle affaire

Non pas besoin d'une action replay : le mig a toujours pu afficher le contenu d'une disquette ou d'un répertoire sans programme supplémentaire.
Par contre le ST, lui ne savait pas déplacer un fichier ou renommer un répertoire. Et, dans ce cas, ce n'est pas que cette fonction n'était pas disponible dans le GEM, mais qu'elle n'existait pas du tout dans l'OS !!! C'est top !

Cela dit, je reconnais volontiers que ce switch est vraiment bien, surtout avec ses fonctions pour formater, etc... (bon il fallait surement attendre la fin du formatage pour revenir sur une appli, mais c'est un moindre mal).
A 14 Ko, Atari aurait pu intégrer ça dans la ROM.

Une appli GEM, lorsqu'elle est lancée, se voit attribuer TOUTE la mémoire disponible (oui oui, ça parait iréel mais c'est ça le GEM). Du coup, un switcher (comme K-Switch) s'en sort en la divisant par 2 : avec un ST 1 Mo, il créé 2 zones de 512 Ko (enfin moins puisque lui aussi prend de la place en RAM...). 

encore un méconnaissance totale du sujet. tout les swticher ne fonctionnent pas comme kswitch. tu peux attribuer toi-même la mémoire dans le switcher.  essaies par exemple Twist.

Je sais bien je n'ai pas dis le contraire. Je disais qu'ils avaient des problèmes différents. J'ai même dit qu'il y en avait plein qui ne marchait pas avec les applis GEM, donc forcément ils ne peuvent pas fonctionner comme K-Switch.

Et une seconde c'est plus rapide que le mig pour basculer ?

oui car tu ne comptes pas le temps pour arriver au coin de la fenêtre pour cliquer.  sur un switch , c'est un raccourci clavier.  de plus, tu peux le faire instantanément en désactivant la fenêtre d'information.

Euh... Sur le mig tu as aussi un raccourci clavier : Touche Amiga+M. J'ai pas voulu utiliser le clavier pour montrer que c'est plus convivial sur le mig puisqu'on a le choix. Et pour montrer la possibilité de déplacer un écran.

Donc j'aurai pu gagner du temps alors que le mig va déjà plus vite que ton ST ? Interessant...

Le mig possède des raccourci clavier pour tout. Même ceux des applications étaient standardisés.

Ah mais je remarque : le GFA boot tout seul ! Genial ! Sauf qu'avec un HD, c'est justement le cas ou on préfère arriver sur le bureau ! Pas de bol !

oui et c'est quoi la différence, si je le fais sur un HD, je peux le faire sur une disquette non ?
et pourquoi ne pas mettre le GFA en boot direct sur une partition et le boot bureau sur une autre et choisir la partition au démarrage ?  c'est pas pratique ça peut-être ?

Génial : créer une partition pour pouvoir booter sur un programme.
Sur le mig, il te suffit de connaitre 3 ou 4 commandes pour afficher un menu et choisir le programme à lancer au démarrage. Pas besoin de multiplier les partitions.



Mais bon, toutes ces demonstrations de la "puissance" et de la "convivialité" du TOS/GEM c'est bien beau mais alors une question : pourquoi y a-t-il eu autant d'alternatives sur ST ? Y en a pas eu sur le mig...

[stapha92]

Tu te souviens tu disais "ma méthode est meilleure que la tienne".
Quand on prend ce discours pour après dire que "le principe reste le même", en utilisant une méthode qui n'a rien à voir avec ce que l'on a annoncé au début, on se ridiculise tout seul...

Qu'est-ce que tu vas copier avec tes bmove ? Un écran entier ? Parce que le mirroring, je sais pas ou tu le vois...
Allez encore un effort de reflexion : tu vas finir par réaliser que le seul moyen de faire tenir tout ça en RAM, c'est de stocker et de copier ligne à ligne. Et c'est exactement la solution que j'ai proposé dès le début...
Problème : avec tes bmove, il est impossible de faire la conversion 3->4 plans que j'ai expliquée. Du coup, ça ne tiendra pas en RAM ton truc...
Et "un peu" moins que 50 i/s ? Tu es trop drole : tu finiras loin du compte. Tu n'atteindras pas 10 i/s avec tes bmove sur un ST avec 1 Mega...

bon, ce n'est qu'un proof of concept, puisque Mr. Stapha est le plus malin.  donc exactement comme j'avais expliqué :

je déplace 16ko sur l'écran total et j'en fait un mirror en temps réel , tu m'excuseras le motif ringard, l'effet tunnel pourri ... mais bon je vais pas passer la journée non plus.  taille mémoire utilisée : 256ko  23 FPS sans optimisation

Aie... ça me fait mal de te dire ça parce que tu as fait un effort mais tu as tout faux. Vraiment tout faux.

Je m'explique : ce qui est difficile à faire dans l'effet tunnel, c'est le zooming en X.

Faire une variation sur l'axe vertical n'a rien de difficile en temps réel.
Y a des tas de démos ST ou Amiga ou une image est étirée ou écrasée en hauteur. Mais uniquement en hauteur. Tu dois maintenant comprendre pourquoi.

Regarde mieux BTL : chaque ligne subit un niveau de zoom différent sur la largeur.

Ce que tu proposes n'a rien à voir. Ton motif devrait voir sa taille varier en largeur sur chaque ligne.
Du coup, les lignes verticales devraient se courber toutes seules avec l'effet. Et cette courbure serait plus prononcé sur les bords de l'écran et inexistantes au milieu.
Et comme tu as un motif qui fait une conquantaine de ligne qui scroll, le mirroring est impossible : dans BTL, le haut et le bas de l'ecran ne sont pas identiques (même inversés).

Je veux bien que le pattern soit moche et que le calcul de déformation ne soit pas optimal. Mais sans zoom horizontal, ce n'est pas un proof of concept.



Le lien Youtube pointe directement sur le tableau de bonus pour que tu n'ais pas besoin de chercher.

[Invité]

pas la peine de répéter 1000x la même chose.  c'est marrant je critiquais justement Stapha d'isoler ma phrase du contexte de la discussion d'ambermoon, pour que tu fasses exactement la même chose !

J'isole rien du tout, ta phrase est telle qu'elle 4 posts plus haut .
Bon tu parles de couleurs, et même en prenant juste ça, je dis non c'est pas pareil du tout .  
Timer ce genre de trucs au CPU(surtout avec le 68k dont l'intruction la plus rapide prend 4 cycles si je me trompe pas) n'est pas simple et pas aussi précis qu'avec le copper qui peut faire ça à la frame .

si le calcul du pattern serait mieux fait, oui l'effet tube serait correctement réalisé, et c'est bien 4 bt
le but ici n'était pas de refaire la demo, mais simplement prouver sa faisabilité.  pourtant, là aussi, c'est écrit dans le post.

Je pense pas que quelqu'un ici ai dit (stapha compris) que juste l'effet tunnel était infaisable(d'ailleurs je t'ai dit que c'était faisable pour moi), nous on parlait du niveau bonus de BTL dans son intégralité,même à 25 fps, c'est infaisable sur ST .
D'ailleurs tu arriveras surement au 25 fps pour ton ersatz de tunnel, mais jamais tu le ferras si tu dois gérer un jeu derrière .

tu as le même raisonnement qu'archiforever, qui prends les effets 1/1 pour dire que l'arm peut faire aussi bien que tout le chipset du mig .
Là forcement, par contre dés que tu montres des des jeux/demos ou tu as de multiples effets en même temps à la frame, c'est plus la même histoire .

[ryosaeba]

Oui. Bof c'est moche et cela fait mail à la tête le superbe effet de TBL. Avoir cela dans un jeu ce n'est pas l'idéal.

[stapha92]

pas la peine de répéter 1000x la même chose.  c'est marrant je critiquais justement Stapha d'isoler ma phrase du contexte de la discussion d'ambermoon, pour que tu fasses exactement la même chose !

J'isole rien du tout, ta phrase est telle qu'elle 4 posts plus haut .
Bon tu parles de couleurs, et même en prenant juste ça, je dis non c'est pas pareil du tout   

Je ne me référais pas à la discussion Ambermoon. J'ai mis trois extraits qui sont clairs... 
Sinon il a raison : le ST est capable de faire les 3 changements de palette dont il parle pour Ambermoon.

si le calcul du pattern serait mieux fait, oui l'effet tube serait correctement réalisé, et c'est bien 4 bt
le but ici n'était pas de refaire la demo, mais simplement prouver sa faisabilité.  pourtant, là aussi, c'est écrit dans le post.

Je pense pas que quelqu'un ici ai dit (stapha compris) que juste l'effet tunnel était infaisable, nous on parlait du niveau bonus de BTL dans son intégralité,même à 25 fps, c'est infaisable sur ST .
D'ailleurs tu arriveras surement au 25 fps pour ton ersatz de tunnel, mais jamais si tu dois gérer un jeu derrière 

En GFA et précalc ? Non surement pas 25 fps. Pas avec un vrai tunnel. Il faudrait faire des copies ligne par ligne. Même pas 10 i/s...
J'ai montré qu'en assembleur, ça prenait tout le cpu (et plus de 600 Ko) de refaire le tunnel seul en précalc. Et je n'ai pas triché, j'ai proposé une méthode optimisée pour faire une conversion 3->4 plans.

En temps réel, c'est impossible pour un ST, même le tunnel seul.

[stapha92]

Oui. Bof c'est moche et cela fait mail à la tête le superbe effet de TBL. Avoir cela dans un jeu ce n'est pas l'idéal.

De la part d'un amateur de démos, c'est de la mauvaise fois pure et dure. Et les plate-formes qui basculent quand brian est dessus ? ça sert à rien ?

[rocky007]

Et comme tu as un motif qui fait une conquantaine de ligne qui scroll, le mirroring est impossible : dans BTL, le haut et le bas de l'ecran ne sont pas identiques (même inversés).

Je veux bien que le pattern soit moche et que le calcul de déformation ne soit pas optimal. Mais sans zoom horizontal, ce n'est pas un proof of concept.

merci, mais mes yeux fonctionnent encore   bien évidement j'ai remarqué l'effet zoom , et bien évidement  mon truc torché en GFA vite fait est horrible et est très loin de BTL. 

le proof c'était la capacité du GFA à faire un déplacement de 16ko + mirroring de façon rapide avec peu de mémoire.  ok, c'est pas 50 FPS, surtout qu'il n'y pas de vsync, mais c'est pas non 10 fps comme affirmé ici.

j'ai toujours bien expliqué qu'il fallait un motif adapté au mirroring.  précalculer le zoom horizontal ne pose pas de problème. dans BTL, per exemple le crane poserait problème, mais avec un motif symétrique bien étudié, par exemple une texture de rocher cela donnerait je pense un effet assez similaire.  ( bien on qu'on se comprenne bien , bien entendu cela ne serait pas le même )

[ryosaeba]

Oui. Bof c'est moche et cela fait mail à la tête le superbe effet de TBL. Avoir cela dans un jeu ce n'est pas l'idéal.

De la part d'un amateur de démos, c'est de la mauvaise fois pure et dure. Et les plate-formes qui basculent quand brian est dessus ? ça sert à rien ?

L'effet est super. Mais rien qu'en regardant la video sur Youtube cela m'a donné la nausée. Désolé. Je vais essayé le jeux sur mon Amiga.

[rocky007]

J'isole rien du tout, ta phrase est telle qu'elle 4 posts plus haut .
Bon tu parles de couleurs, et même en prenant juste ça, je dis non c'est pas pareil du tout .  
Timer ce genre de trucs au CPU(surtout avec le 68k dont l'intruction la plus rapide prend 4 cycles si je me trompe pas) n'est pas simple et pas aussi précis qu'avec le copper qui peut faire ça à la frame .

ben si, relis bien : ce comparatif venait d'ambermoon.  il y a 3 changement de palettes à faire, un pour le menu du dessus, un pour la fenêtre de jeu et un pour l'inventaire. tu crois qu'il faut un précision d'enfer pour cela ? 

D'ailleurs tu arriveras surement au 25 fps pour ton ersatz de tunnel, mais jamais tu le ferras si tu dois gérer un jeu derrière .

pfff t'es épuisant, j'ai dit et redit mille fois que oui forcément le rotozoom et tout le reste sont bien entendu impossible sur un ST, d'autant plus en GFA !  vous me faites vraiment marrer... comme je le disais encore dans mon dernier post pour stapha, tu me crois vraiment assez con pour imaginer refaire BTL en GFA sur un ST ?  alors que même l'effet du tunnel seul n'a jamais été reproduit dans les meilleures mégademos assembleur sur ST ?

[ryosaeba]

Si, je pense te retrouver une demo St avec un rotozoom.... et je suis persuadé que j'ai déjà vu l'effet de TBL dans une demo St; Il faut que je cherche un peu....

[stapha92]

Et comme tu as un motif qui fait une conquantaine de ligne qui scroll, le mirroring est impossible : dans BTL, le haut et le bas de l'ecran ne sont pas identiques (même inversés).

Je veux bien que le pattern soit moche et que le calcul de déformation ne soit pas optimal. Mais sans zoom horizontal, ce n'est pas un proof of concept.

merci, mais mes yeux fonctionnent encore   bien évidement j'ai remarqué l'effet zoom , et bien évidement  mon truc torché en GFA vite fait est horrible et est très loin de BTL. 

le proof c'était la capacité du GFA à faire un déplacement de 16ko + mirroring de façon rapide avec peu de mémoire.  ok, c'est pas 50 FPS, surtout qu'il n'y pas de vsync, mais c'est pas non 10 fps comme affirmé ici.

j'ai toujours bien expliqué qu'il fallait un motif adapté au mirroring.  précalculer le zoom horizontal ne pose pas de problème. dans BTL, per exemple le crane poserait problème, mais avec un motif symétrique bien étudié, par exemple une texture de rocher cela donnerait je pense un effet assez similaire.  ( bien on qu'on se comprenne bien , bien entendu cela ne serait pas le même )

Oui mais si tu fais des déplacements de 16 Ko, il va te falloir plusieurs Mo de données précalculées.
Et tu ne pourras pas gagner de place avec du mirroring.

Je te répète : le seul moyen de faire tenir ça dans la RAM, c'est de stocker chaque ligne du motif (y en a une cinquantaine) dans chacune des tailles possibles (il y en a 100). Meme comme ça ça te prendra 50 x100x160 = 800 Ko. Mais tu seras obligé de copier ligne à ligne : 10 images/secondes en GFA...

[ryosaeba]

Dans la Posh demo, il y a un superbe rotozoom:

[ryosaeba]

et un autre ici:

[ryosaeba]

Les premiers ROTOZOOM sur St date de la Froggies over the fence

[Invité]

Je ne me référais pas à la discussion Ambermoon. J'ai mis trois extraits qui sont clairs...   
Sinon il a raison : le ST est capable de faire les 3 changements de palette dont il parle pour Ambermoon.

Je parlais pas de ça moi, mais de sa phrase "le changement de couleurs via interruption c'est pareil que le copper" .
Mais si ça parlait juste pour ambermoon, ok 

pfff t'es épuisant, j'ai dit et redit mille fois que oui forcément le rotozoom et tout le reste sont bien entendu impossible sur un ST, d'autant plus en GFA !  vous me faites vraiment marrer... comme je le disais encore dans mon dernier post pour stapha, tu me crois vraiment assez con pour imaginer refaire BTL en GFA sur un ST ?  alors que même l'effet du tunnel seul n'a jamais été reproduit dans les meilleures mégademos assembleur sur ST ?

faire le malin en gfa c'est ton idée, moi je te dis que même en ASM c'est infaisable .

[ryosaeba]

de mémoire, cette demo est codé en GFA sur ST: 

[rocky007]

Je te répète : le seul moyen de faire tenir ça dans la RAM, c'est de stocker chaque ligne du motif (y en a une cinquantaine) dans chacune des tailles possibles (il y en a 100). Meme comme ça ça te prendra 50 x100x160 = 800 Ko. Mais tu seras obligé de copier ligne à ligne : 10 images/secondes en GFA...

dans ce cas précis oui, mais il n'était jamais question de faire à l'identique mais toujours, je cite : "avec un motif adapté" qui me permet bien de précal la 1ere moitié du tunnel éviter 16ko de copie ligne/ligne.
j'avais pourtant clairement expliqué cela.

[Invité]

C'est fou quand même comme tu changes tes propos au fil du temps mon rocky
Au départ tu parlais juste de l'effet tunnel, maintenant tu rajoutes avec ds motifs simplifiés, forcement si petit à petit tu enlèves des choses, ça devient faisable .

[dlfrsilver]

Je vous en lâche une bonne (et qui n'a pas d'odeur ) :

Avec l'Atari ST/E on est tous "micro" !

ahahahahah

[rocky007]

C'est fou quand même comme tu changes tes propos au fil du temps mon rocky
Au départ tu parlais juste de l'effet tunnel, maintenant tu rajoutes avec ds motifs simplifiés, forcement si petit à petit tu enlèves des choses, ça devient faisable .

c'est fou comme il vous est difficile de lire correctement, pourtant, heureusement que j'ai une bonne mémoire, je me cite   :

06/09 : tu te trompes, je n'ai jamais parlé de la plateforme, mais bien de l'effet "tube" en fond.  avec un motif adéquat, tu peux faire le même effet en precalc

21/08 : ce tube n'est probablement pas mappée en temps réel. ça a l'air clairement précalculé sur sa moitié et mirroré.

PS : pas la peine d'embrayer sur "mais non, c'est du temps réel, t'as toujours rien compris"...c'est une citation, certes fausse, mais je n'avais pas imaginé en effet, à l'époque, que cet effet pouvait être fait en temps réel sur un amiga.  je n'avais pas non plus prêté aux détails des motifs originaux qui semblait à première vue répétitif et symétrique.  ( raison pour laquelle j'ai corrigé le 06/09 )

[stapha92]

Oui mais ça ne marchera pas Rocky : le fond scroll verticalement. Meme si tu utilises un motif symétrique, il ne sera presque jamais centré sur l'écran. Donc tu ne pourras pas mirrorer.

C'est pas simple à expliquer. Peut-être qu'un jour tu vas t'amuser à le faire en assembleur (le GFA permet d'inclure des routines en assembleur, non ?) et là avec les essais tu comprendras ce que je veux dire.

Quoi qu'il en soit, même si je ne suis pas d'accord avec ton POC, tu as fait l'effort de le coder. Et ça c'est une démarche que je salue.

[stapha92]

Ryosaeba,

En GFA la démo ? Avec des parties en assembleur alors, non ?

Pour les rotozooms : ils sont en 2x2 au mieux et en 16 images/ secondes max.
BTL, c'est du 1x1 en 50 images/secondes. Tu vas le voir puisque tu vas l'essayer.

Attention ! Je ne critique pas les rotozoom que tu as montré. Ils sont très chouettes ! Rien à redire.

Et eux passent par une C2P : impossible de faire du 1x1 en 1 vbl. Sur mig comme sur ST. BTL utilise d'autres techniques.

J'aime bien celui avec le visage de femme : l'image est modifié en plusieurs fois pour fluidifier le mouvement. Une sorte d'entrelacement. C'est très bien fait.

[Invité]

06/09 : tu te trompes, je n'ai jamais parlé de la plateforme, mais bien de l'effet "tube" en fond.  avec un motif adéquat, tu peux faire le même effet en precalc

Si tu reprends mes propos tenus à la même date, je t'ai dit que pour moi juste l'effet tunnel était faisable, forcement si tu utilises tout le CPU pour ce seul et unique effet .

21/08 : ce tube n'est probablement pas mappée en temps réel. ça a l'air clairement précalculé sur sa moitié et mirroré.

Il n'y a aucun mapping, c'est juste un effet hsync avec changement de palette, c'est la même chose que le jeu axelay ou castlevania 4 sur snes .
C'est juste un layer qui est déformé sur Y à chaque lignes via les registres de scrolling + des changements de palette,donc un effet purement 2D.

[rocky007]

Oui mais ça ne marchera pas Rocky : le fond scroll verticalement. Meme si tu utilises un motif symétrique, il ne sera presque jamais centré sur l'écran. Donc tu ne pourras pas mirrorer.

C'est pas simple à expliquer. Peut-être qu'un jour tu vas t'amuser à le faire en assembleur (le GFA permet d'inclure des routines en assembleur, non ?) et là avec les essais tu comprendras ce que je veux dire.

Quoi qu'il en soit, même si je ne suis pas d'accord avec ton POC, tu as fait l'effort de le coder. Et ça c'est une démarche que je salue.

je me trompe peut-être, je vais essayer par plaisir.   le frond scrolle bien verticalement, son déplacement est précalculé et pourtant j'ai pu ajuster les 2 parties pour que cela ne soit pas visible.  le motif est évidement plus simple qu'un pattern de rocher.

autre précision :  je ne mirror pas l'image de la 1ere moitié de l'écran, mais son "opposé" :  si j'ai 16 étapes de rotation, si j'affiche l'image 1 sur les 100 premières lignes, le mirror sera celle de l'image 16, reconstituant ainsi le motif intégral.

oui le GFA peut inclure des routines assembleur , c'est du reste ce que j'ai utilisé pour les rasters bleus en fond ( si si , il y en a, même si pas très visible )

[stapha92]

Oui mais ça ne marchera pas Rocky : le fond scroll verticalement. Meme si tu utilises un motif symétrique, il ne sera presque jamais centré sur l'écran. Donc tu ne pourras pas mirrorer.

C'est pas simple à expliquer. Peut-être qu'un jour tu vas t'amuser à le faire en assembleur (le GFA permet d'inclure des routines en assembleur, non ?) et là avec les essais tu comprendras ce que je veux dire.

Quoi qu'il en soit, même si je ne suis pas d'accord avec ton POC, tu as fait l'effort de le coder. Et ça c'est une démarche que je salue.

je me trompe peut-être, je vais essayer par plaisir.   le frond scrolle bien verticalement, son déplacement est précalculé et pourtant j'ai pu ajuster les 2 parties pour que cela ne soit pas visible.  le motif est évidement plus simple qu'un pattern de rocher.

autre précision :  je ne mirror pas l'image de la 1ere moitié de l'écran, mais son "opposé" :  si j'ai 16 étapes de rotation, si j'affiche l'image 1 sur les 100 premières lignes, le mirror sera celle de l'image 16, reconstituant ainsi le motif intégral.

oui le GFA peut inclure des routines assembleur , c'est du reste ce que j'ai utilisé pour les rasters bleus en fond ( si si , il y en a, même si pas très visible )

Ok je comprend. Mais ça veut dire que si tu as 16 étapes d'anims, ton motif fera 16 lignes  au niveau du zoom max. Et sera très petit au milieu de l'écran.
Je pense que c'est ce que tu veux dire quand tu parles de texture plus simple.

En le faisant ligne par ligne, je pense que tu peux économiser de la RAM et avoir exactement le meme rendu que dans BTL avec 600 Ko.
Ok faudrait le faire en assembleur, mais vu que ce sera de l'assembleur inline tu pourras dire en toute bonne fois que tu l'as fait en GFA... 
Et a tournera à 50 i/s
Après tout, même en précalc, c'est pas un effet courant dans les démos...

Sinon, pourquoi ne pas travailler sans mirroring ? La texture sera plus petite mais ça tournera à 50 I/s sans assembleur.

Quoi qu'il en soit, je suis pressé de voir ce que ça donne. Même avec 16 étapes, ça peut avoir un super rendu (et on peut avoir une belle texture, même avec cette taillle).

[ryosaeba]

cet effet a-t-il un nom ?

[rocky007]

Ok je comprend. Mais ça veut dire que si tu as 16 étapes d'anims, ton motif fera 16 lignes  au niveau du zoom max. Et sera très petit au milieu de l'écran.
Je pense que c'est ce que tu veux dire quand tu parles de texture plus simple.

En le faisant ligne par ligne, je pense que tu peux économiser de la RAM et avoir exactement le meme rendu que dans BTL avec 600 Ko.
Ok faudrait le faire en assembleur, mais vu que ce sera de l'assembleur inline tu pourras dire en toute bonne fois que tu l'as fait en GFA... 
Et a tournera à 50 i/s
Après tout, même en précalc, c'est pas un effet courant dans les démos...

Sinon, pourquoi ne pas travailler sans mirroring ? La texture sera plus petite mais ça tournera à 50 I/s sans assembleur.

Quoi qu'il en soit, je suis pressé de voir ce que ça donne. Même avec 16 étapes, ça peut avoir un super rendu (et on peut avoir une belle texture, même avec cette taillle).

oui c'est bien cela : la hauteur de la texture est égale au nombre d'étapes et devra être obligatoirement symétrique.   le mirroring c'était uniquement pour le rendre réalisable avec un framerate décent en GFA,cela n'a aucun intérêt en assembleur : il faudrait dépasser 100 étapes par ligne pour que le mirroring soit plus économique, sans oublier la contrainte de la texte symétrique qu'il n'y aura pas en assembleur.

j'ai enfin filière qui fonctionne bien pour faire mes essais, j'espère avoir un bon résultat rapidement.

[stapha92]

oui c'est bien cela : la hauteur de la texture est égale au nombre d'étapes et devra être obligatoirement symétrique.   le mirroring c'était uniquement pour le rendre réalisable avec un framerate décent en GFA,cela n'a aucun intérêt en assembleur : il faudrait dépasser 100 étapes par ligne pour que le mirroring soit plus économique, sans oublier la contrainte de la texte symétrique qu'il n'y aura pas en assembleur.

j'ai enfin filière qui fonctionne bien pour faire mes essais, j'espère avoir un bon résultat rapidement.

Ok.

"Fillière" ? C'est une coquille, une texture ?

J'ai une question : pour le mirroring, tu es obligé de faire des bmove ligne à ligne ?
Parce qu'il faut garder le meme sens au sein de chaque ligne tout en inversant l'ordre des lignes elles même.

Ou alors le bmove peut faire ça d'un coup ? C'est à dire copier 160 octets et faire reculer le pointeur de 320 octets, et ainsi de suite...

Si c'est le cas, c'est vraiment une instruction bien pensée.

[rocky007]

filière = les bons outils / méthodes... j'ai découvert entre autre un utilitaire fantastique : xnconvert

malheureusement, le bmove c'est juste source,destination,taille.

pour éviter un boucle, j'ai donc un bloc de 100 bmove avec adresses précalculées pour le mirroring

bon, voici le résultat,2 versions différentes, tous les deux en pure GFA, ça tiens dans 272ko de ram,le pattern en noir et blanc, c'est tout ce que j'ai trouvé sous la main, mais c'est bien 4 bitplans.

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 ?

[Seb]

La projection est dans le mauvais sens mais sympa sinon

(le centre du tube devrait être plus petit vu qu'on est dedans)

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