Re: GUERRE ST-AMIGA, FIGHT ! (Mauvaise foi assurée)

[Copper]

Ca m'étonnerait que le vendeur accepte mais tu peux toujours essayer on sait jamais...

[Copper]

Un document de guerre d'époque

[epc35]

"l'image très ludique de Atari ne sera plus un handicap dans le pro"

Non, mais, n'importe quoi, venez dans le futur discuter sur ce forum, on vous expliquera comment vous dominez ce marché.

[Jacques Atari]

Un document de guerre d'époque

Très intéressant, et ni l'un ni l'autre n'ont l'air de savoir de quoi ils parlent...
L'encadré sur le patron d'AMIE est aussi très intéressant. Le mec avait compris que le PC était le futur. Pourtant, il s'accrochera sur son A2000 grotesque. Les fanatiques du Commodore...

[Copper]

Oui tu as raison l'interlocuteur Atari ne sait pas de quoi il parle quand il dit que le STE est une machine phénoménale à tous les niveaux...

[stapha92]

oui je peux répéter autant de fois que tu t'es planté en pensant qu'en shared c'est 64  cycles CPU , 64 cycles blitter... suivie d'une longue démonstration mathématique prouvant te dires alors que tu étais 100% dans l'erreur.  Et ton contre argument "le shared c'est de la merde" est aussi mauvaise que ton "je le savais mais je l'ai pas dit", ça prouve simplement 1° tu t'es gouré, avec en bonus une démonstration de 10 ligne totalement fausse

100% dans l'erreur selon toi ? Ok...
Je savais pour le coup de l'instruction bonus mais ce n'est pas toujours utilisable. Mais ok : vraiment pas besoin de chercher la petite bete, alors considérons cette instruction supplémentaire (lancé juste après avoir démarré le blitter) comme toujours utilisée.

Puisque je suis dans l'erreur, dis moi en quoi pour la enième fois, ce qui suit est faux :
 - Si le cpu termine son instruction "bonus" avant le blitter, il reste totalement innocupé jusqu'à ce que le blitter termine.
 - Dans 90% des cas, quand cette instruction bonus est terminée, le blitter n'a même passé 10% de ses 64 cycles.
 - Le seul cas ou l'instruction sera plus longue que le blitter (et donc le cpu toujours occupé) est la division signé. Très intéressant : c'est celle que l'on évite absolument (et les codeurs ST sont très forts à ce jeu là). 
 - Quand ce cas se produit, le blitter rend betement la main et la mémoire n'est utilisée par aucun des 2 jusqu'à la fin de l'instruction.
 - La granularité prévue pour le shared mode ne permet de garantir un traitement correct des interruptions.
 - Si le shared mode avait été fait 1 cycle cpu / 1 cycle blitter. Le blitter irait aussi vite (1/2 = 64/128) mais le cpu ne serait quasiment pas ralenti.

Vas-y, expliques nous ce qui est faux là dedans au lieu d'écrire comme si tu avais prouvé quoi que soit : tu te contente de nier mes chiffres (qui sont expliqués et pas balancé comme ça...) et tu appelles ça une preuve... On croirait avoir à faire à un platiste...

Comparaison avec l'équivalent du shared coté mig : Quand le 68000 a besoin d'un accès mémoire, il attend 3 cycles et il accède à la mémoire pour 1 cycle et le blitter reprend la main immédiatement. Le 68000 ne peut pas faire 2 accès mémoires en moins de 4 cycles....
A aucun moment, les cycles mémoires resteront inutilisés. 

Vas-y : expliques nous donc comment tu fais l'équivalent avec ton share mode et tu pourras alors dire que ce n'est pas de la merde...

Et penses à l'expliquer sur AtariForum : Dans les topic sur Lotus STE, on voit que l'utilisation du shared mode a été envisagée à cause des interruptions mais rapidement abandonnée. Ils sont forcément 100% dans l'erreur eux aussi...

2° tu ne sais pas te remettre en question et accepter ton erreur, ce qui est problématique puisque cela ne donne plus aucune envie de débattre avec toi puisque quoique je te prouve, cela ne sera jamais suffisant   ( on l'a bien vu avec le sample log, preuves audible  par tous, mais tu restes dans le déni ).

Ah oui ? Preuve audible par tous ? Tout comme les vidéos visibles par tous ? (parce que j'attends les fichier pour regarder ça sur un emul...)
Sauf que tu as triché en baissant le volume. Et justement, dans mon comparatif log/linéaire j'explique pourquoi avec un volume bas le log est avantagé.
Moi j'ai mis une vrai explication détaillé avec graphiques de courbes à l'appui (A la Zarnal quoi... ) et toi tu t'es contenté de reprendre les inepties que l'on trouve sur internet et qui confondent "12 bits de dynamique" avec "12 bits de résolution".

Je te l'ai indiqué en te demandant une version normalisée et, bizarrement, tu n'as rien posté... Cela n'a pas eu le résultat escompté ? 
Et pour info : fais le test avec mon sinus comme tu dis : avec lui aussi, le log s'en sortira mieux si tu baisses le volume  : preuve que la démonstration est valable.
 
ça suffit pas ? Ok quelque chose d'audible pas tous (une vrai musique, pas un sinus comme tu dis) :


Version 16 bits linéaire (forcément...) à 22 Khz :
https://www.dropbox.com/s/i4dxzl8mpyuzpfx/16%20bits.wav?dl=0

Version 8 bits linéaire à 22 Khz :
[url=https://www.dropbox.com/s/48jna60r1xas0a4/8 bits]https://www.dropbox.com/s/48jna60r1xas0a4/8%20bits%20lin%C3%A9aire.wav?dl=0[/url]

Version 8 bits log à 22 Khz :
[url=https://www.dropbox.com/s/p9e16gnzzxpgv3d/8 bits]https://www.dropbox.com/s/p9e16gnzzxpgv3d/8%20bits%20log.wav?dl=0[/url]

Pendant l'intro le log s'en sort mieux : peu d'artefacts et pas de souffle. Par contre pour tout le reste...

Ah ben mince alors ! Elle est ou la supériorité du log ? Pour te citer : "la qualité qui équivaut presque du 13 bits linéaire". Et tu penses m'avoir "mouché" sur le log...

N'importe qui peut vérifier les fichiers ou refaire l'opération :
 - télécharger audacity
 - charger le fichier 16 bits
 - exporter en wav en choisissant l'encodage "unsigned 8-bit PCM". C'est le 8 bits linéaire.
 - exporter en wav en choisissant l'encodage "U-Law"

Et il suffit de refaire le travail après avoir baissé le volume (CTRL + A puis menu effet/normaliser et mettre - 18 db dans le champ) pour faire la même triche que Rocky.
Et, comme par hasard, là, le log s'en sortira mieux.

tout comme ton erreur sur Dread, en comparant les +- 80000 cycles CPU perdus par frame affichée ( soit +-50% d'une scanline ) dû au doublement des lignes VS +-0 cycles perdu sur amiga grâce à son Copper.

Ah ça y est tu l'as fait ton calcul !
Moi j'arrive à 66 000. Mais peut être que ton nombre est le calcul pour 200 lignes...

Pas grave, on est pas loin.

Mais avant que tu nie mes chiffres :

Movem.l (A0)+,D0-D7/A1-A6 : lecture de 14 registres (56 octets)  durée : 12 + 8*14 = 124 cycles
Movem.l D0-D7/A1-A6,xxx(A0) :  écriture de 14 registres : 12 + 10*14 = 152 cycles

Donc 276 cycles pour copier 56 octets. Et il suffit de dérouler ensuite. Ce qui donne :
83 (lignes) x 160 (octets par ligne) x 276 (cycles par copie) / 56 (octets par copie) = 65 451 cycles. 

Combien de cycles le cpu du ST a-t-il en plus par frame ? réponse : 18 000 en pal.
Donc, si on prend une moyenne de 5 frames par rendu (et je suis gentil...) ça fait 90 000 cycles en plus pour le cpu du ST. Donc après avoir doublé les lignes, le cpu du ST a encore 24 000 cycles de plus. Donc tu as tort, le doublement n'explique pas tout : meme en l'incluant, le ST devrait être plus rapide...
Et je n'ai pas compté les cycles pris par le copper et les sprites sur les 5 frames (c'est pas gratuit d'être plus joli) et le surcout des lignes en plus (supérieur au cout du gun)....
Donc non : le copper n'explique pas la différence.

Alors ? Elle est ou mon erreur sur Dread ? Parce que même en enlevant "les +- 80000 cycles perdus" le ST conserve une avance coté cpu. 
Donc expliques ou est ma soi-disant erreur, c'est pas difficile : ça peut être que sur 18000 ou 5. Alors ?

Note que je n'ai pas sauté sur ton erreur ("scanline" au lieu de "frame") moi...

Autre petite précision sur le sprite : tu expliques qu'il suffit de changer son Y. Oui bien sur, et comme ça il recouvrira le panel de score quand il descendra. Tu as une bonne vision de tout ça Rocky...

Et, encore une fois, n'oublie pas que le ST dispose de 2 Mo et qu'il doit avoir plein de code déroulé la ou le mig n'a plus la place. Et il y a pleins d'autres optims possibles.

ça te fait 1 FPS de différence  juste pour la partie Amiga  "copper", à cela faut aussi ajouter le blitter utilisé sur amiga VS 100% CPU sur la version ST sans blitter.   bref, tu es toujours à coté de la plaque.

C'est pas 1 fps seulement mais on est d'accord : c'est grace à l'architecture de l'amiga qui lui permet de distribuer ses canaux DMA en fonction des besoin et non de façon statique comme le ST, qui en a pourtant beaucoup moins. C'est ce qui permet au blitter et au cpu de bosser en parralele. 
Parce que le blitter qui bosserait tout seul en bloquant le cpu (mode qui existe aussi sur le mig), ça ne serait pas du tout aussi rapide : le blitter doit faire plusieurs passes pour la C2P. Et lui et le cpu perdent du temps : y a beaucoup d'accès mémoire à faire pour le cpu (buffer chunky à remplir et textures à lire) et tout est en chip.

Le simple fait de stocker toutes les textures en fast permet au cpu et au blitter d'avoir 2 fois moins de cycles perdus. Et là ce n'est plus 20% de différence...
Il faut 1 Mo de fast, donc un amiga avec 1,5 ou 2 Mo de ram au total. Comme la version ST...
Et si Dread était pensé dès le départ pour 2 Mo (donc avec fast), il aurait des optims qui améliorerait la vitesse par rapport à la version actuelle sur 2 Mo...

Mais oublions et expliques nous comment tu pourrais faire pareil pour une c2p au blitter en parrallele du cpu puisque, selon toi, le share mode le permet.
Le gars de wolf3d qui est très bon, utilise aussi la méthode grosses table et movep (la preuve : il a besoin de 2 Mo aussi) et son jeu a été pensé exclusivement pour ST. 

Sans une solution blitter magique (et il n'y en a pas...), une version ST sur 1 Mo irait beaucoup moins vite. Pourtant ça serait la seule comparaison équitable : Dread serait comparé sur des configs standard de l'époque. 

En tout cas tu dis que la C2P au blitter sur le mig est plus performante que la C2P 100% cpu du ST.

C'est bien parce que tu m'as, encore une fois, traité de débile quand je l'ai affirmé...
Et quand j'ai expliqué la méthode (qui n'a rien de compliqué) , tu as continué.
Y avait pas Dread à ce moment là. Donc tu as basculé sur tes "gnagnagna j'ai dit 3 fois que t'étais à la ramasse donc j'ai prouvé que tu avais tort".

Oui, tu as prouvé à la façon Rocky que j'avais tort. Dread a prouvé que j'avais raison.

Aussi petite précision : le HUD dans Lotus, c'est 40x93 pixels soit 3720 pixels sur 64000 pixels, soit +-1/17ème de l'écran...j'avais dit 1/16 à vue de pif, tu vois j'étais gentil.   Tu peux chipoter pour les 11 lignes vides si ça te fait plaisir ou le nombre de plans blabla, tu es juste comme d'habitude hors sujet puisque je ne parlais que de la surface que prenait le HUD sur l'écran.  Mais tu sais pas t'empecher, faut que dtu sortes ta science pour tes fanboys.  Recomptes tes points Danone, tu avais un 3-1 gratuit qui n'est pas passé.

Oui continue à me charrier et à te raccrocher aux branches. Parce que bifurquer sur la surface est trop pathétique.

Tu parlait du HUD à cause du surcout pour l'afficher avec le blitter. Donc on s'en fout de la surface, c'est la quantité de données qui compte ! Et il y en a 2 fois moins en 4 couleurs qu'en 16. Point barre. Donc tu peux écarter ce que tu veux mais tout le monde peut relire l'échange et voir que ce que je dis est vrai.
Et il y a bien des lignes vides qui ne sont pas traitées. Et si tout n'est pas traité d'un coup, c'est tout simplement parce que le l'archi du ST l'empêche : il n'y aurait plus d'interruption au bon moment sinon...
Donc les lignes vides sont évitées sans surcout.
C'est bien 1/40eme de l'écran : 5 (octets par ligne) x 80 (lignes) x 2 (bitplans) = 800 octets. Et 800 x 40 = 32 000. La taille d'un écran ST dis donc !
Pas au point la vue de pif...

Au final, le blitter va bien déplacer 2,5 % du contenu d'un écran (800 malheureux octets !) toutes les 2 ou 3 frames et tu pense que ça explique la différence de vitesse ? Mon pauvre pas du tout : c'est le blitter qui ne peut pas travailler correctement en parralele du cpu, contrairement à celui du mig le problème. Et ce n'est pas sa faute mais c'est de l'ARCHITECTURE du ST...

Tu dois te battre avec la caissière en disant "vous être hors sujet comme d'habitude ! J'ai pris 1 Danone, j'ai droit à 3 gratuit !


D'ailleurs, reprend la vidéo :

L'auteur (qui est le codeur : il doit un peu savoir de quoi il parle) explique que l'affichage du HUD est performant. Bien plus que la version cpu. Et on voit bien que les lignes vides ne sont pas traitées.
Donc la version STE affiche la route et le hud plus rapidement mais le blitter se fait tellement battre par le 68000 pour tous les objets qu'elle perd cette avantage et finit par se retrouver derrière la version initiale. Alors que le blitter est fait pour ce genre de travail. Top l'architecture du ST...

Et rappel : la version mig tourne avec 512 Ko, pas la version STE. Et la version mig n'est pas optimisée au mieux, la version STE si.
Rien qu'en utilisant tous les sprites, la version amiga aurait plus de couleurs tout en consommant moins de cycles.

edit : en copie pure, le blitter du STE est plus rapide que celui de l'amiga (même écart que les cpu), qui dépose déjà le 68000. Pourtant, le codeur a du confier l'affichage du décor de fond au 68000 car, explique-t-il dans la vidéo, c'est plus rapide. Y a vraiment un problème... 

tu crois quand je poste un montage photoshop c'est pour me faire repérer pour un poste d'infographiste ?
ça me détend de faire une petite pause avec des conneries qui me font rire.... à voir la teneur de tes posts, je penses pas que le mot humour fasse partie de ton quotidien.  Ta plus grosse soirée délire a été quand tu as jeté ta grenadine sur ton trivial poursuit.

Même si c'était le cas je ne le jugerai pas.
Mais je me suis mal exprimé : je ne voulais pas parler de tes montages photo humoristiques. Je parlais des copies écrans de jeu qui devait démontrer qu'une version 16 couleurs est aussi belle que 32 couleurs. Et donc que le ST aurait pu... bla bla bla...

[Jacques Atari]

[rocky007]

Très intéressant, et ni l'un ni l'autre n'ont l'air de savoir de quoi ils parlent...

L'encadré sur le patron d'AMIE est aussi très intéressant. Le mec avait compris que le PC était le futur. Pourtant, il s'accrochera sur son A2000 grotesque. Les fanatiques du Commodore...

Surtout le mec d'Amiga qui ne savait pas ce qu'était un ordinateur 3 ans auparavant.  C'est dingue

[Copper]

Première expérience dans la micro ne veut pas forcément dire qu'il ne connaissait pas les gros systèmes avant

Surtout que visiblement il avait quand même passé 7 ans chez HP avant de rejoindre Commodore...

[Jacques Atari]

Surtout que visiblement il avait quand même passé 7 ans chez HP avant de rejoindre Commodore...

Quelle déchéance...

[rocky007]

Première expérience dans la micro ne veut pas forcément dire qu'il ne connaissait pas les gros systèmes avant

Surtout que visiblement il avait quand même passé 7 ans chez HP avant de rejoindre Commodore...

euh moi je lis : "première expérience dans la micro : 3 ans chez HP"...avant de rejoindre Commodore.

[Copper]

D'après les échos :

Franck Lanne, quarante-six ans, a passé sept ans chez Hewlett-Packard et fut notamment directeur des ventes et du marketing. Il rejoignit en 1987 Commodore France et en fut directeur général jusqu'en 1990.

[Jacques Atari]

Le genre de mec qui n'y connaît rien en informatique, il était juste là pour vendre un produit. Là c'était une gamme d'ordinateurs. Il pouvait aussi bien le faire pour des aspirateurs que pour des petits pois. Ayons du respect pour les ingénieurs et, à la limite, le boss de la boîte s'il a vraiment une vision de la chose façon Tramiel Mais les autres...

[rocky007]

oui encore un autre vendeur "d'eau sucrée" converti à l'univers de la micro

[Zarnal]

Le genre de mec qui n'y connaît rien en informatique, il était juste là pour vendre un produit. Là c'était une gamme d'ordinateurs. Il pouvait aussi bien le faire pour des aspirateurs que pour des petits pois. Ayons du respect pour les ingénieurs et, à la limite, le boss de la boîte s'il a vraiment une vision de la chose façon Tramiel Mais les autres...

Encore un ami de Silver ?

[Copper]

Qu'en est-t-il de l'interlocuteur Atari ???

[Copper]

Le genre de mec qui n'y connaît rien en informatique, il était juste là pour vendre un produit. Là c'était une gamme d'ordinateurs. Il pouvait aussi bien le faire pour des aspirateurs que pour des petits pois. Ayons du respect pour les ingénieurs et, à la limite, le boss de la boîte s'il a vraiment une vision de la chose façon Tramiel Mais les autres...

Ceux qui ont acheté un Atari ST ne s'y connaissaient rien en informatique non plus

[dav1974]

oui je peux répéter autant de fois que tu t'es planté en pensant qu'en shared c'est 64  cycles CPU , 64 cycles blitter... suivie d'une longue démonstration mathématique prouvant te dires alors que tu étais 100% dans l'erreur.  Et ton contre argument "le shared c'est de la merde" est aussi mauvaise que ton "je le savais mais je l'ai pas dit", ça prouve simplement 1° tu t'es gouré, avec en bonus une démonstration de 10 ligne totalement fausse

100% dans l'erreur selon toi ? Ok...
Je savais pour le coup de l'instruction bonus mais ce n'est pas toujours utilisable. Mais ok : vraiment pas besoin de chercher la petite bete, alors considérons cette instruction supplémentaire (lancé juste après avoir démarré le blitter) comme toujours utilisée.

Puisque je suis dans l'erreur, dis moi en quoi pour la enième fois, ce qui suit est faux :
 - Si le cpu termine son instruction "bonus" avant le blitter, il reste totalement innocupé jusqu'à ce que le blitter termine.
 - Dans 90% des cas, quand cette instruction bonus est terminée, le blitter n'a même passé 10% de ses 64 cycles.
 - Le seul cas ou l'instruction sera plus longue que le blitter (et donc le cpu toujours occupé) est la division signé. Très intéressant : c'est celle que l'on évite absolument (et les codeurs ST sont très forts à ce jeu là). 
 - Quand ce cas se produit, le blitter rend betement la main et la mémoire n'est utilisée par aucun des 2 jusqu'à la fin de l'instruction.
 - La granularité prévue pour le shared mode ne permet de garantir un traitement correct des interruptions.
 - Si le shared mode avait été fait 1 cycle cpu / 1 cycle blitter. Le blitter irait aussi vite (1/2 = 64/128) mais le cpu ne serait quasiment pas ralenti.

Vas-y, expliques nous ce qui est faux là dedans au lieu d'écrire comme si tu avais prouvé quoi que soit : tu te contente de nier mes chiffres (qui sont expliqués et pas balancé comme ça...) et tu appelles ça une preuve... On croirait avoir à faire à un platiste...

Comparaison avec l'équivalent du shared coté mig : Quand le 68000 a besoin d'un accès mémoire, il attend 3 cycles et il accède à la mémoire pour 1 cycle et le blitter reprend la main immédiatement. Le 68000 ne peut pas faire 2 accès mémoires en moins de 4 cycles....
A aucun moment, les cycles mémoires resteront inutilisés. 

Vas-y : expliques nous donc comment tu fais l'équivalent avec ton share mode et tu pourras alors dire que ce n'est pas de la merde...

Et penses à l'expliquer sur AtariForum : Dans les topic sur Lotus STE, on voit que l'utilisation du shared mode a été envisagée à cause des interruptions mais rapidement abandonnée. Ils sont forcément 100% dans l'erreur eux aussi...

2° tu ne sais pas te remettre en question et accepter ton erreur, ce qui est problématique puisque cela ne donne plus aucune envie de débattre avec toi puisque quoique je te prouve, cela ne sera jamais suffisant   ( on l'a bien vu avec le sample log, preuves audible  par tous, mais tu restes dans le déni ).

Ah oui ? Preuve audible par tous ? Tout comme les vidéos visibles par tous ? (parce que j'attends les fichier pour regarder ça sur un emul...)
Sauf que tu as triché en baissant le volume. Et justement, dans mon comparatif log/linéaire j'explique pourquoi avec un volume bas le log est avantagé.
Moi j'ai mis une vrai explication détaillé avec graphiques de courbes à l'appui (A la Zarnal quoi... ) et toi tu t'es contenté de reprendre les inepties que l'on trouve sur internet et qui confondent "12 bits de dynamique" avec "12 bits de résolution".

Je te l'ai indiqué en te demandant une version normalisée et, bizarrement, tu n'as rien posté... Cela n'a pas eu le résultat escompté ? 
Et pour info : fais le test avec mon sinus comme tu dis : avec lui aussi, le log s'en sortira mieux si tu baisses le volume  : preuve que la démonstration est valable.
 
ça suffit pas ? Ok quelque chose d'audible pas tous (une vrai musique, pas un sinus comme tu dis) :


Version 16 bits linéaire (forcément...) à 22 Khz :
https://www.dropbox.com/s/i4dxzl8mpyuzpfx/16%20bits.wav?dl=0

Version 8 bits linéaire à 22 Khz :
[url=https://www.dropbox.com/s/48jna60r1xas0a4/8 bits]https://www.dropbox.com/s/48jna60r1xas0a4/8%20bits%20lin%C3%A9aire.wav?dl=0[/url]

Version 8 bits log à 22 Khz :
[url=https://www.dropbox.com/s/p9e16gnzzxpgv3d/8 bits]https://www.dropbox.com/s/p9e16gnzzxpgv3d/8%20bits%20log.wav?dl=0[/url]

Pendant l'intro le log s'en sort mieux : peu d'artefacts et pas de souffle. Par contre pour tout le reste...

Ah ben mince alors ! Elle est ou la supériorité du log ? Pour te citer : "la qualité qui équivaut presque du 13 bits linéaire". Et tu penses m'avoir "mouché" sur le log...

N'importe qui peut vérifier les fichiers ou refaire l'opération :
 - télécharger audacity
 - charger le fichier 16 bits
 - exporter en wav en choisissant l'encodage "unsigned 8-bit PCM". C'est le 8 bits linéaire.
 - exporter en wav en choisissant l'encodage "U-Law"

Et il suffit de refaire le travail après avoir baissé le volume (CTRL + A puis menu effet/normaliser et mettre - 18 db dans le champ) pour faire la même triche que Rocky.
Et, comme par hasard, là, le log s'en sortira mieux.

tout comme ton erreur sur Dread, en comparant les +- 80000 cycles CPU perdus par frame affichée ( soit +-50% d'une scanline ) dû au doublement des lignes VS +-0 cycles perdu sur amiga grâce à son Copper.

Ah ça y est tu l'as fait ton calcul !
Moi j'arrive à 66 000. Mais peut être que ton nombre est le calcul pour 200 lignes...

Pas grave, on est pas loin.

Mais avant que tu nie mes chiffres :

Movem.l (A0)+,D0-D7/A1-A6 : lecture de 14 registres (56 octets)  durée : 12 + 8*14 = 124 cycles
Movem.l D0-D7/A1-A6,xxx(A0) :  écriture de 14 registres : 12 + 10*14 = 152 cycles

Donc 276 cycles pour copier 56 octets. Et il suffit de dérouler ensuite. Ce qui donne :
83 (lignes) x 160 (octets par ligne) x 276 (cycles par copie) / 56 (octets par copie) = 65 451 cycles. 

Combien de cycles le cpu du ST a-t-il en plus par frame ? réponse : 18 000 en pal.
Donc, si on prend une moyenne de 5 frames par rendu (et je suis gentil...) ça fait 90 000 cycles en plus pour le cpu du ST. Donc après avoir doublé les lignes, le cpu du ST a encore 24 000 cycles de plus. Donc tu as tort, le doublement n'explique pas tout : meme en l'incluant, le ST devrait être plus rapide...
Et je n'ai pas compté les cycles pris par le copper et les sprites sur les 5 frames (c'est pas gratuit d'être plus joli) et le surcout des lignes en plus (supérieur au cout du gun)....
Donc non : le copper n'explique pas la différence.

Alors ? Elle est ou mon erreur sur Dread ? Parce que même en enlevant "les +- 80000 cycles perdus" le ST conserve une avance coté cpu. 
Donc expliques ou est ma soi-disant erreur, c'est pas difficile : ça peut être que sur 18000 ou 5. Alors ?

Note que je n'ai pas sauté sur ton erreur ("scanline" au lieu de "frame") moi...

Autre petite précision sur le sprite : tu expliques qu'il suffit de changer son Y. Oui bien sur, et comme ça il recouvrira le panel de score quand il descendra. Tu as une bonne vision de tout ça Rocky...

Et, encore une fois, n'oublie pas que le ST dispose de 2 Mo et qu'il doit avoir plein de code déroulé la ou le mig n'a plus la place. Et il y a pleins d'autres optims possibles.

ça te fait 1 FPS de différence  juste pour la partie Amiga  "copper", à cela faut aussi ajouter le blitter utilisé sur amiga VS 100% CPU sur la version ST sans blitter.   bref, tu es toujours à coté de la plaque.

C'est pas 1 fps seulement mais on est d'accord : c'est grace à l'architecture de l'amiga qui lui permet de distribuer ses canaux DMA en fonction des besoin et non de façon statique comme le ST, qui en a pourtant beaucoup moins. C'est ce qui permet au blitter et au cpu de bosser en parralele. 
Parce que le blitter qui bosserait tout seul en bloquant le cpu (mode qui existe aussi sur le mig), ça ne serait pas du tout aussi rapide : le blitter doit faire plusieurs passes pour la C2P. Et lui et le cpu perdent du temps : y a beaucoup d'accès mémoire à faire pour le cpu (buffer chunky à remplir et textures à lire) et tout est en chip.

Le simple fait de stocker toutes les textures en fast permet au cpu et au blitter d'avoir 2 fois moins de cycles perdus. Et là ce n'est plus 20% de différence...
Il faut 1 Mo de fast, donc un amiga avec 1,5 ou 2 Mo de ram au total. Comme la version ST...
Et si Dread était pensé dès le départ pour 2 Mo (donc avec fast), il aurait des optims qui améliorerait la vitesse par rapport à la version actuelle sur 2 Mo...

Mais oublions et expliques nous comment tu pourrais faire pareil pour une c2p au blitter en parrallele du cpu puisque, selon toi, le share mode le permet.
Le gars de wolf3d qui est très bon, utilise aussi la méthode grosses table et movep (la preuve : il a besoin de 2 Mo aussi) et son jeu a été pensé exclusivement pour ST. 

Sans une solution blitter magique (et il n'y en a pas...), une version ST sur 1 Mo irait beaucoup moins vite. Pourtant ça serait la seule comparaison équitable : Dread serait comparé sur des configs standard de l'époque. 

En tout cas tu dis que la C2P au blitter sur le mig est plus performante que la C2P 100% cpu du ST.

C'est bien parce que tu m'as, encore une fois, traité de débile quand je l'ai affirmé...
Et quand j'ai expliqué la méthode (qui n'a rien de compliqué) , tu as continué.
Y avait pas Dread à ce moment là. Donc tu as basculé sur tes "gnagnagna j'ai dit 3 fois que t'étais à la ramasse donc j'ai prouvé que tu avais tort".

Oui, tu as prouvé à la façon Rocky que j'avais tort. Dread a prouvé que j'avais raison.

Aussi petite précision : le HUD dans Lotus, c'est 40x93 pixels soit 3720 pixels sur 64000 pixels, soit +-1/17ème de l'écran...j'avais dit 1/16 à vue de pif, tu vois j'étais gentil.   Tu peux chipoter pour les 11 lignes vides si ça te fait plaisir ou le nombre de plans blabla, tu es juste comme d'habitude hors sujet puisque je ne parlais que de la surface que prenait le HUD sur l'écran.  Mais tu sais pas t'empecher, faut que dtu sortes ta science pour tes fanboys.  Recomptes tes points Danone, tu avais un 3-1 gratuit qui n'est pas passé.

Oui continue à me charrier et à te raccrocher aux branches. Parce que bifurquer sur la surface est trop pathétique.

Tu parlait du HUD à cause du surcout pour l'afficher avec le blitter. Donc on s'en fout de la surface, c'est la quantité de données qui compte ! Et il y en a 2 fois moins en 4 couleurs qu'en 16. Point barre. Donc tu peux écarter ce que tu veux mais tout le monde peut relire l'échange et voir que ce que je dis est vrai.
Et il y a bien des lignes vides qui ne sont pas traitées. Et si tout n'est pas traité d'un coup, c'est tout simplement parce que le l'archi du ST l'empêche : il n'y aurait plus d'interruption au bon moment sinon...
Donc les lignes vides sont évitées sans surcout.
C'est bien 1/40eme de l'écran : 5 (octets par ligne) x 80 (lignes) x 2 (bitplans) = 800 octets. Et 800 x 40 = 32 000. La taille d'un écran ST dis donc !
Pas au point la vue de pif...

Au final, le blitter va bien déplacer 2,5 % du contenu d'un écran (800 malheureux octets !) toutes les 2 ou 3 frames et tu pense que ça explique la différence de vitesse ? Mon pauvre pas du tout : c'est le blitter qui ne peut pas travailler correctement en parralele du cpu, contrairement à celui du mig le problème. Et ce n'est pas sa faute mais c'est de l'ARCHITECTURE du ST...

Tu dois te battre avec la caissière en disant "vous être hors sujet comme d'habitude ! J'ai pris 1 Danone, j'ai droit à 3 gratuit !


D'ailleurs, reprend la vidéo :

L'auteur (qui est le codeur : il doit un peu savoir de quoi il parle) explique que l'affichage du HUD est performant. Bien plus que la version cpu. Et on voit bien que les lignes vides ne sont pas traitées.
Donc la version STE affiche la route et le hud plus rapidement mais le blitter se fait tellement battre par le 68000 pour tous les objets qu'elle perd cette avantage et finit par se retrouver derrière la version initiale. Alors que le blitter est fait pour ce genre de travail. Top l'architecture du ST...

Et rappel : la version mig tourne avec 512 Ko, pas la version STE. Et la version mig n'est pas optimisée au mieux, la version STE si.
Rien qu'en utilisant tous les sprites, la version amiga aurait plus de couleurs tout en consommant moins de cycles.

edit : en copie pure, le blitter du STE est plus rapide que celui de l'amiga (même écart que les cpu), qui dépose déjà le 68000. Pourtant, le codeur a du confier l'affichage du décor de fond au 68000 car, explique-t-il dans la vidéo, c'est plus rapide. Y a vraiment un problème... 

tu crois quand je poste un montage photoshop c'est pour me faire repérer pour un poste d'infographiste ?
ça me détend de faire une petite pause avec des conneries qui me font rire.... à voir la teneur de tes posts, je penses pas que le mot humour fasse partie de ton quotidien.  Ta plus grosse soirée délire a été quand tu as jeté ta grenadine sur ton trivial poursuit.

Même si c'était le cas je ne le jugerai pas.
Mais je me suis mal exprimé : je ne voulais pas parler de tes montages photo humoristiques. Je parlais des copies écrans de jeu qui devait démontrer qu'une version 16 couleurs est aussi belle que 32 couleurs. Et donc que le ST aurait pu... bla bla bla...

 Ce post (enfin les données techeuniques) me fait me demander un truc :
 Vous pensez que les programmeurs a l'époque savaient tout ça ? (ce dont vous parlez...) ou savaient t-ils repousser les limites techniques des machines comme ils arrivent a le faire aujourd’hui ?) ou avaient le temps de s'en servir pour adapter des jeux sous licence le plus vite possible ?

[drfloyd]

les dev d'aujourd'hui sur Amiga ne repoussent aucune limite, ils sont surtout pas bon en terme de game design (c'est mon avis)

On Attend BOING II, The ball revenge, pour prouver que les dev maitrisent en 2022   Mais depuis que BOING a été réalisé sur micro 8bit de 1981 en 5 lignes de pur basic, le mythe en a pris un sacré coup.

Les limites sont repoussées sur C64 par contre. Ces dernieres années, whaouu....

[Copper]

La scene Amiga n'est pas passionnante il faut bien le reconnaître... Le C64 a des trucs sympa mais malheureusement qu'est-ce que c'est moche avec cette palette

Par contre j'ai toujours pas vu Settlers sur 8 bits uniquement des fausses Boing demo

[stapha92]

Ce post (enfin les données techeuniques) me fait me demander un truc :
Vous pensez que les programmeurs a l'époque savaient tout ça ? (ce dont vous parlez...) ou savaient t-ils repousser les limites techniques des machines comme ils arrivent a le faire aujourd’hui ?) ou avaient le temps de s'en servir pour adapter des jeux sous licence le plus vite possible ?

Ce n'est que mon avis mais, pour moi, ils avaient les connaissances nécessaires mais pas les budgets.

Et les éditeurs n'avaient aucun interet à leur en accorder. Y qu'a voir, par exemple, SOTB sur ST ou Pacmania sur Amiga. Les 2 auraient pu être meilleurs mais ne se seraient pas vendus davantage : SOTB est un succès sur ST et Pacmania étaient assez bon pour le marché.

Après, forcément, les passionnés d'aujourd'hui vont plus loin : ils ont eu beaucoup plus de temps, et internet a favorisé le travail collaboratif et les échanges.

Il y a quand même eu des jeux techniquement impressionnants à l'époque (Brian the lion, Soccer kid, Behind the iron Gate, Lion Heart, Ambermoon, Mr Nutz,  ...)

[stapha92]

les dev d'aujourd'hui sur Amiga ne repoussent aucune limite, ils sont surtout pas bon en terme de game design (c'est mon avis)

On Attend BOING II, The ball revenge, pour prouver que les dev maitrisent en 2022   Mais depuis que BOING a été réalisé sur micro 8bit de 1981 en 5 lignes de pur basic, le mythe en a pris un sacré coup.

Les limites sont repoussées sur C64 par contre. Ces dernieres années, whaouu....

Ah bon ? Aucune limite ?

Et Dread ? Et Metro siege ? Et Boss machine ? Et Souverän Soccer ? Et Inviyya ? Et Quest ? Et il y en a encore pleins...

Même pour le game design, quand on sait que Dread est livré avec un editeur de map sur PC ou qu'on jette un oeil sur Quest...

Bon, ce n'est pas pire que quand tu parles de l'OS pas en ROM ou du GFA qui surclasse tout sur ST...

[Jacques Atari]

Il n'en est jamais revenu de son Amiga celui-là, et il n'en reviendra jamais...

[Copper]

La première fois que j'ai vu un ST je n'en suis pas revenu non plus... Tellement c'était naze

[Copper]

.Bon, ce n'est pas pire que quand tu parles de l'OS pas en ROM ou du GFA qui surclasse tout sur ST...

Oui c'est sur que c'est stupide de dire ça même si les apparences sont trompeuses...

Mais bon c'est normal quand on utilisé l'Amiga que comme une console de jeu et qu'on a pas fait de disquettes bootables optimisées (avec GoWB par exemple)

[Jacques Atari]

Arrête de te la péter Coppy. Vu ton âge, tu ne codais rien du tout au début des années 90, tu faisais mumuse avec SOTB et la Boing Ball. Tu as dû découvrir le code bien après, quand Commodore avait mis la clé sous la porte et que l'Amiga était déjà oublié et ringard.

[Copper]

Arrête de te la péter Coppy. Vu ton âge, tu ne codais rien du tout au début des années 90, tu faisais mumuse avec SOTB et la Boing Ball. Tu as dû découvrir le code bien après, quand Commodore avait mis la clé sous la porte et que l'Amiga était déjà oublié et ringard.

Biensur que si Monsieur Otarie j'ai même publié un shareware compensé chez FDS (Free Distribution Software) à l'époque...

SOTB j'ai pas joué beaucoup avec (j'ai plus joué au III) et j'ai jamais eu la Boing Ball (rappelons toutefois qu'il ne s'agit qu'un programme de test écrit bien avant la sortie de l'Amiga par Dale Luck et RJ Mical en 1984 )

Il est vrai que l'on ne connait pas les programmes de tests écrits par l'équipe de l'Atari ST il faut dire qu'il n'y avait pas grand chose à tester non plus

[Zarnal]

Arrête de te la péter Coppy. Vu ton âge, tu ne codais rien du tout au début des années 90, tu faisais mumuse avec SOTB et la Boing Ball. Tu as dû découvrir le code bien après, quand Commodore avait mis la clé sous la porte et que l'Amiga était déjà oublié et ringard.

Biensur que si Monsieur Otarie j'ai même publié un shareware compensé chez FDS (Free Distribution Software) à l'époque...

SOTB j'ai pas joué beaucoup avec (j'ai plus joué au III) et j'ai jamais eu la Boing Ball (rappelons toutefois qu'il ne s'agit qu'un programme de test écrit bien avant la sortie de l'Amiga par Dale Luck et RJ Mical en 1984 )

Il est vrai que l'on ne connait pas les programmes de tests écrits par l'équipe de l'Atari ST il faut dire qu'il n'y avait pas grand chose à tester non plus

Ben moi j'ai juste codé et publiè commercialement... ...ben rien du tout en fait.

[stapha92]

Il n'en est jamais revenu de son Amiga celui-là, et il n'en reviendra jamais...

Dit celui qui poste plus de 2 000 messages en un an avec, comme pseudo, le nom d'une marque dont l'heure de gloire est passée depuis 40 ans...

Par contre, Google avait fait un emulateur amiga en ligne pour ses 30 ans. Ils ont même payé pour les roms. Eux aussi n'en sont pas revenus ? Ou ils ont juste, comme moi, un regard nostalgique particulier sur une machine qui a marqué l'histoire bien plus que ton 8 bits déguisé dont aucun dev chez Google ne connait l'existence...

Et, pour info, pas besoin de coder pour faire une disquette bootable : l'os du mig dispose d'un vrai shell. Comme tous les os sérieux. Ce n'est pas le cas de celui du ST, fort logiquement...

Bizarre de se faire déposer par une soi-disant console à disquette pour des dizaines de choses qui ne concernent que des ordinateurs...

Le seul truc que le ST a et qu'un mig ne peut pas avoir, c'est le port cartouche...

[Jacques Atari]

Biensur que si Monsieur Otarie j'ai même publié un shareware compensé chez FDS (Free Distribution Software) à l'époque...

Amusant, j'aimais bien leur jeu Voyager 10.

SOTB j'ai pas joué beaucoup avec (j'ai plus joué au III)

Pffff... Quand Shinobi rencontre Indiana Jones... Quelle daube! SOTB, y'a vraiment le 1 qui vaut quelque chose. Dès le second, c'était un cran en dessous.

Il n'en est jamais revenu de son Amiga celui-là, et il n'en reviendra jamais...

Dit celui qui poste plus de 2 000 messages en un an avec, comme pseudo, le nom d'une marque dont l'heure de gloire est passée depuis 40 ans...

Au moins, elle existe toujours, même si ça n'a plus grand-chose à voir. Commodore, l'Amiga, le "mig", c'est mort. Bouffé par les vers.

[Copper]

Un simple fichier s/startup-sequence suffit avec un bootblock adéquat sur le mig...

Dommage que la collection Shareware compensé de FDS ne soit pas disponible sur le net (en tout cas j'ai pas trouvé)