GAMOPAT
Vous souhaitez réagir à ce message ? Créez un compte en quelques clics ou connectez-vous pour continuer.

GUERRE ST-AMIGA, FIGHT !!!

+31
crapahute
A1WSX
ace76
Ninja_SCX
BDCIron
delpiero013
Nextome
Julien Amandine
dlfrsilver
Violent Ken
meuhmeuh
oliver27
upsilandre
babsimov
pcengineman
Atlantis
dam's
stapha92
Strider
cryodav76
barbarian_bros
Brume
Seb
vicomte
Doctoritchy
ryosaeba
Urbinou
Vortex
rocky007
drfloyd
lulrik
35 participants

Page 33 sur 34 Précédent  1 ... 18 ... 32, 33, 34  Suivant

Aller en bas

amiga - GUERRE ST-AMIGA, FIGHT !!! - Page 34 Empty Re: GUERRE ST-AMIGA, FIGHT !!!

Message par dlfrsilver Lun 7 Sep 2015 - 0:49

L'O/S 9 de microware a été utilisé sur X68000 pour programmer les jeux de machine d'arcade de Toaplan nommés Outzone (pour ne citer que lui).

J'ai trouvé l'info dans un PDF scanné de 686 pages de doc de design de chez TOAPLAN. L'X68000 fut leur seconde machine de développement. Avant lui, ils utilisaient l'ordinateur Sony BMC-777.

Juste en apparté :)

dlfrsilver
Interne
Interne

Nombre de messages : 7647
Date d'inscription : 29/05/2009

Revenir en haut Aller en bas

amiga - GUERRE ST-AMIGA, FIGHT !!! - Page 34 Empty Re: GUERRE ST-AMIGA, FIGHT !!!

Message par stapha92 Lun 7 Sep 2015 - 8:24

rocky007
Un TT maintenant ? Quand bien même, tu pourrais pas.
oui un TT, et les débits que permettait le TT en SCSI ainsi que les HD SCSI permettent ce type d'animation
On parle du ST je te rapelle : regarde le titre du TOPIC. Le STE ne devrait même pas y etre (la grande majorité des ST vendus ne sont pas des STE) 

Rapellons un peu le début du débat. Tu t'es emporté avec ces vidéos. Tu étais en joie et tu n'as pas hésité à te moquer des amigaistes. 
Tu as même traité cryodav76 de rigolo alors que ses interrogations étaient fondés. Interrogations auxquelles tu as repondu des choses du genre :
rocky007
il ne faut rien modifier à la machine, faut juste un lecteur CF
rocky007
mon dieu, mais..pfff..c'est qd même pas compliqué à comprendre :
le STe sait afficher sans problème une image overscann 4096 couleurs... 
alors techniquement, c'est super simple : il lit l'image sur la CF et l'affiche, et ce 25 par seconde. 
il n'y a pas de buffering ( hormis peut-être un simple swap) , pas de décompression, rien, lit un bloc d'octets et l'affiche, pourquoi il lui faudrait 5 giga de RAM ? 300 ko maximum suffisent largement pour effectuer l'opération. donc le seul point crucial est le débit, il n'y a rien de magique la dedans. 
c'est de la simple logique que même un amigaiste pourrait comprendre ( quoique, apparemment non, puisque tu butes une vidéo d'un autre player qui n'a rien à voir )
rocky007
Il lit l'image et il l'affiche""... Tu es vraiment à coté de la plaque...
Pour ces vidéos, j'ai parlé de débits et des explications de l'auteur pour t'expliquer que c'était impossible sur un ST non modifié. ça n'a pas suffit à te convaincre et tu te réfugies maintenant derrière le TT pour éviter de reconnaitre que tu t'étais moqué de cryodav76 à tort.

Alors je vais t'expliquer pourquoi c'est impossible meme avec un débit SCSI de 2,5 Mo/s (donc le double de l'interface la plus rapide AUJOURD'HUI !) :

Une image de 416x228 en 16 couleurs prend 47424 octets. ça donne 47 924 x 50 = 2,3 Mo à "lire et à écrire" à chaque seconde. Un 68000 en est totalement incapable ! Donc si : c'est magique...
N'importe quel codeur ST ou mig sait cela... 

Et il faut rajouter les changements de palette : 

Spectrum 512 a montré que le maximum que le ST pouvait faire c'est 3 changements de palette / ligne. Si tu passes en overscan, c'est moins parce que ça bouffe aussi du cpu à chaque ligne. Donc 416 pixels/ligne avec 3 changements de couleurs, c'est impossible sur un ST, même avec une image fixe !
Rien que ça aurait du te mettre la puce à l'oreille... 

Ok, faisons comme si un ST pouvait afficher ce genre d'image... 

Le changement de palette occupe tout le cpu pendant toute la zone d'affichage qui représente 73% de la frame. Il reste donc 27% des ressources cpu à chaque frame pour "lire l'image et l'écrire". 
ça fait du 2,3 Mo/0,27 = 8,5 Mo/s. C'est plus du double de ce que peut faire le blitter du mig qui lui-même explose un 68000 !!!! 
En fait, c'est plus que la RAM du ST (ou la chip ram du mig) peut faire... C'est dire le ridicule de tes affirmations ! C'est encore plus "magique" !

Alors quand tu te moques des amigaistes comme cryodav76 (à qui tu proposais un mouchoir après avoir posté ces vidéos), c'est toi même que tu décridibilise... 

Au fait pour les 8,5 Mo/s : ce nombre s'applique aussi au TT. Donc tes affirmations sur les débits du TT en SCSI, tu peux les garder

Au final tu avais raison sur un point : cryodav76 avait besoin d'un mouchoir car il a du pleurer de rire...

rocky007
Je ne comprends pas ton explication.  si j'ai bien compris, fait bien scroller ton écran HAM d'un pixel ?  donc tu auras des problème de couleurs.
C'est pourtant pas compliqué. 

Je ne fais pas scroller l'écran, je le déplace ! Je détaille : 

Sur le mig, la taille et la position de l'écran peuvent être librement défini. Y a pas juste un mode fenêtre et un mode overscan. 
Donc quand je dis que je déplace l'écran, c'est vraiment ça. mais comme j'ai mis deux sprites (de couleur noire, qui font toute la hauteur de l'écran et qui sont au dessus du playfield) à gauche et à droite de l'écran, ça donne l'impression que ça scrolle. Il n'empeche que Denise va traiter les pixels cachés, donc il n'y aura aucun problème de couleur. 

Quand le déplacement atteint 16 pixels, on déplace le contenu en changeant le registre d'adresse. On aura donc largement eu le temps de préparer la copperlist suivante. 

C'est clair cette fois ?

rocky007tu 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, et mirrorant et doublant certaines lignes pour le partie haute et basse, ce qui fait facilement 80 étapes d'animations avec 1 mo
Ah bon ? Alors c'est quoi çà :
rocky007
euh, encore une fois tu as l'air bien sûr de toi... moi tout ce que je vous, c'est un fond précalculé, ainsi qu'une plateforme précalculée également. Et rien du tout infaisable sur ST. Le shoot ? qu'y a-t-il de spéciale ? Le parallax précalculé comme on en faisait sur St depuis la Union Demo ?
Vraiment là, tu as pris le mauvais exemple.
Ou alors ça :
rocky007
pour moi, un effet qui est strictement identique comme rotation de plateformes identiques au degré prés , effet rotatif avec motif répétitif, tout ça, ça m'a l'air pas catholique. Pourquoi, si c'était du temps réel, ne pas exploiter ce dernier, en faisant des plateformes de différents tailles, qui bougent différemment ou en fonction du personnage
Bon pour celle là, je peux te trouver une excuse : les plates-formes bougent justement en fonction du personnage : son poids les fait pencher. Mais j'admet volontiers que ça ne se voit pas vraiment dans la vidéo.

Plus loin dans ce post tu expliques avoir planifié de ripper les données et adapter en GFA et prouver que c'était possible en pre-calc avec 640 Ko.

Bon allez, comme tu n'as jamais été capable de reconnaitre une erreur. On va oublier et se concentrer sur le tube. 

Tu arrives comment à 80 étapes d'animations ? Tu sors ce chiffre de quel chapeau ? Et combien pèse chacune d'entre elles ? 

Tactique classique : tu assènes des affirmations assorties de concepts que tu ne maitrises pas et de nombre sortis de ton chapeaux. ça fait illusion auprès de certains peut-être, mais surement pas auprès de ceux qui connaissent un tant soit peu les machines dont on parle.

Allons-y :

1) Le motif du tube se répète si on considère que les changement de couleurs peuvent être obtenu avec un changement de palette. Inutile donc d'avoir une image qui fait tout l'écran. 
L'image necessaire semble faire 50 lignes de haut. 
2) Chaque ligne de l'écran a une largeur différente. Mais comme la courbure est centrée, chaque largeur est utilisée 2 fois. On a donc 100 largeurs différentes. 

ça nous fait 50 lignes à stocker dans 100 largeurs. 5 000 lignes donc. 
Une ligne fait 160 Octets : 50x100x160 = 800 Ko. ça fait beaucoup pour du précalc. 
Mais ce n'est pas le seul problème : copier les différentes lignes en optimisant correctement le code 68000 va prendre quasiment tout le temps cpu disponible dans une frame. 
Donc en GFA, tu peux oublier cette méthode. 

Tu as codé sur ST et tu ne sais pas que la simple copie d'une image prend presqu'une frame entière en assembleur ? 

Pour le faire en GFA, il te faudrait stocker les images entières et modifier l'adresse écran à chaque fois. Mais comme il y a 50 lignes à traiter avant de boucler, il te faudrait 50 images pour que ça reste fluide meme quand la vitesse ralentie. 50 x 32 Ko = 1,6 Mo. Donc en GFA, tu peux oublier... 

Récapitulons :
Tu nous as expliqué qu'un ST pouvait afficher certaines vidéos sans modifs, alors qu'il ne peut même pas afficher ne serait-ce que l'une des frames de ces vidéos en tant qu'image fixe.
Tu as affirmer pourvoir reproduire 2 effets en précalc en gfa alors que tu ne pourrais en faire un seul à la fois (pour les plates-formes : ce serait pire...).

ça fait 2 fois que tu es à coté de la plaque quand tu parles du ST. En fait bien plus mais je me restreint au sujet abordés dans le débat qui nous oppose.

Je laisse aux lecteurs le soin de juger de ta crédibilité quand tu prétend expliquer des choses sur le mig quand on voit à quel point tu peux te planter quand tu parles de ta machine de prédilection...

Allez, je suis gentil et je vais t'expliquer comment cet effet peut être obtenu sur ST dans une démo. 

Tu commences par stocker tes lignes sur 3 plans : le précalc prendra 600 Ko. Le problème va être de l'appliquer sur 4 plans sans perdre de temps. 
Sur un mig, les bitplans étants séparés, il n'y aurait aucune difficulté : on ne traiterait que 3/4 des données. 

Sur ST on ne peut pas faire pareil mais, en etant malin, on peut s'arranger pour gagner du temps. 
J'explique : 

Sur ST la mémoire écran est disposé comme suit : 

11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44... 

Chaque chiffre représentent un octet et désigne le bitplan auquel il est destiné. On voit qu'ils sont regroupés 2 par 2 car le shifter lit les données 16 bits à la fois. 

On va stocker les lignes du tunnel en disposant les plans 1,2 et 4 de cette façon : 

11 22 11 22 11 22 11 22 11 22 11 22 11 22 44 44 44 44 44 44 44 

On chargera en 2 temps : 

movem.l (a6)+,d0/d2/d4/d6/a0/a2/a4 
movem.w (a6)+,d1/d3/d5/d7/a1/a3/a5 

Le premier movem travaille avec des longword, ce qui permet permet de charger le plan 1 dans la partie haute et le plan 2 dans la partie basse de chaque registre. 
le deuxième travaille avec des word. Seuls les partie basses de chaque registre seront chargées avec les données du plan 4. la partie haute, qui correspond au plan 3 restera à 0 (on aura pris soin d'effacer les registres avant le traitement bien sur)

Puis on ecrit tous les registres d'un coup : 

movem.l d0-d7/a0-a5,-(a7) 

On a fait notre conversion 3 plans->4 plans sans perdre de temps. On en a meme gagné grace au deuxieme movem qui traite des word et non des longword. 
(les 2 movem réunis prennent 108 cycles. un seul movem.l qui lit les 14 registres en aurait pris 124) 

Donc pour une ligne entière il faudra faire : 

movem.l (a6)+,d0/d2/d4/d6/a0/a2/a4 
movem.w (a6)+,d1/d3/d5/d7/a1/a3/a5 
movem.l d0-d7/a0-a5,-(a7) 
movem.l (a6)+,d0/d2/d4/d6/a0/a2/a4 
movem.w (a6)+,d1/d3/d5/d7/a1/a3/a5 
movem.l d0-d7/a0-a5,-(a7) 
movem.l (a6)+,d0/d2/d4/d6/a0/a2 
movem.w (a6)+,d1/d3/d5/d7/a1/a3 
movem.l d0-d7/a0-a3,-(a7) 

Pour traiter une ligne avec 3 séries, il faut que les deux premières utilisent 14 registres, il faudra donc se mettre en mode superviseur pour en avoir un de plus. 
On pourra aussi faire 4 série avec 10 registres et en garder 4 disponibles. ça pourrait être plus interessant au final, a cause de ce qu'il reste à faire. A tester. 

ça prendra 656 cycles par lignes. Il faudra ajouter le calcul de l'adresse de la ligne à copier (qui pourra être stockée dans une table de précalc) et le bouclage (et il ne reste plus de registres pour ça...). On va arrondir le tout à 700 cycles. Donc ça fait 700 * 200 lignes * 50 i/s = 7 000 000 cycles : il en reste 1 millions. On va donc pouvoir mettre quelques interruptions horizontales pour faire les changements de palettes. 

Par contre, après, il ne restera plus assez pour ajouter une plate-forme. même sans faire de rotation...

Donc OUI : on peut faire l'effet de tube sur un ST en utilisant 600 Ko de précalc et plus de 90% des ressources cpu avec un code correctement optimisé. 

Au final tu auras reproduis partiellement un effet du mig en bouffant tellement de RAM et de CPU que ça sera inutilisable. Exactement comme la phaleon demo et son screen qui reproduit très partiellement SOTB...

C'est pas la premiere fois qu'un AMIGA-FANBOY poste un code qui présente des optimisations spécifiques au ST. 
Par contre j'ai toujours pas vu le moindre code posté par l'un de nos experte STiste... 

Pour info, si on veut faire pareil sur le mig. C'est à dire en precalc, et sans utiliser le blitter, le copper ou les sprites il suffirait d'utiliser une interruption horizontale et de redefinir à chaque ligne l'adresse à afficher pour chacun des 3 plans. en comptant les changements de palette (qui seraient dans la même interruption). ça prendrait 10 % de cpu...

Et oui : meme sans utiliser ses atouts, le mig explose le ST juste grace à la souplesse de son chipset...


rocky007
Entrelacé, c'est le truc qui était une obligation en vidéo. Et ou as-tu vu qu'il faut un moniteur à plus 10 000 FF pour l'afficher ? Faudrait que tu te décides à ne parler que des domaines que tu maitrises, ça t'éviterait pas mal d'inepties : Le mode entrelacé a toujours fonctionné avec tous les moniteurs et TV.

oui avec des scintillements à flinguer les yeux en 10 minutes.

Tu as attendu l'époque des LCD pour regarder la TV ? Parce que je le répète à l'intention de tous ceux qui, comme toi, nous rabachent cet argument bidon : 

 - TOUT CE QUE TU POUVAIS VOIR À LA TÉLÉ ÉTAIT ENTRELACÉ à l'époque du mig (TV, K7 video, Laserdisc, DVD) !!! Autant qu'avec le mig, la seule différence est le niveau de contraste maximum : il est bien plus élevé avec un mig ou un ST en RGB qu'avec tous les autres systèmes (sauf le matériel pro). Il y avait des TV 100 Hz à l'époque des CRT justement pour réduire ce phénomène. ça marchait d'ailleurs très bien pour le mig... 
 - TOUS LES MODES D'AFFICHAGE DU MIG EXISTENT EN ENTRELACE ET EN PROGRESSIF !! 
 - MEME AUJOURD'HUI, TOUS LES PROGRAMMES TV SONT ENTRELACES !! (Quand une télé affiche 576i, le i signifie interlaced) Mais ça se voit moins (malgré l'utilisation du numérique qui permet d'atteindre des niveaux de contraste maximum) à cause du temps de latence des LCD 
 
Et on parlait de l'utilisation PRO. L'absence de mode entrelacé était rédhibitoire pour eux. Ils doivent être aveugles puisqu'ils nous balancent de l'entrelacé depuis les débuts de la TV...

rocky007

un simple exemple, déjà cité :


Agrandir cette image
amiga - GUERRE ST-AMIGA, FIGHT !!! - Page 34 13_017
Tu es sérieux là ? Tu me sors une carte à 16 000 Fr qui ne se branche que sur un mega ST 2/4 ? ça fait la config à 30 000 si on comptes le deuxième moniteur !!! 
Parce que ta super carte sort une image qui est à part de celle du ST... C'est ridicule... Et ce n'est utilisable qu'avec des programmes spécifiques... 
Ce n'est pas la faute de la carte (par ailleurs très bien faite), c'est la faute de la super architecture du mega ST qui en fait une machine pas vraiment évolutive 
Pour 30 000 Fr tu avais un A2000 avec une carte graphique 24 bits utilisables par pleins de logiciels (car connectée dans le port vidéo que LUI possédait...) et une carte accélératrive qui faisait que ton mega ST pouvait se rabiller. 
En fait, vu l'année ou est sortie ta carte chili, c'est un A3000 + carte graphique que tu pouvait avoir... 

C'est bien de nous parler du TT, puis du Mega ST, puis d'une carte à 16 000 Fr. Mais on est dans un topic Amiga VS ST... 

Tu pouvais faire du titrage avec un A500+genlock. En haute définition, overscan (704x576x16)... Un ST peut même pas en rever... 

Tant qu'on y est, on va prendre un 800XL avec VBXE et expliquer que c'est mieux qu'un C64... 

rocky007
Pourquoi sur parole ? 
J'ai livré des codes. Tu peux les prendre pour les faire vérifier sur des forums ST ou Amiga. Pas besoin de me faire confiance. 
Et ne t'inquiètes pas : si j'ai menti dans les codes, on tardera pas à voir quelqu'un venir rectifier. 

Si je résume : 
 - Tu ne sais pas comment fonctionne le blitter du mig. 
 - Tu ne comprends pas le code d'une C2P 
Et tu te permets d'affirmer que le blitter du mig ne peut pas en faire. Et tu insistes en plus ! Je t'avais donné des arguments faciles à vérifier 
Surtout pour quelqu'un qui codait sur ST... 

Y a pas quelque chose qui cloche ?

en quoi j'insiste ?  tu as donné ta démonstration de l'utilisation partielle du blitter dans une routine C2P, ok, je l'ai acceptée non ? 
je n'ai jamais prétendu connaître l'amiga et encore moins le fonctionnement de son blitter, ni même être un expert Atari.  Où vois-tu que j'ai prétendu être cela ?  et je te rassure, je sais comment fonctionne une routine C2P, peut-être pas de la façon la plus optimisée, mais dans son principe.
Tu insiste en disant "même si je dois te croire sur parole". Tu pourrais juste dire "ok tu as raison" mais non : ça a l'air d'être trop dur. 

Je me permet de te raffaichir la mémoire : 
rocky007
Je suis pas spécialiste,  mais il me semble que blitter de l'amiga est assez rigide.  Il très pratique pour déplacer des gros blocs de mémoire, mais certainement pas pour aider à faire du polyfill sur des scènes complexes et encore moins pour du C2P.
tu commences pas "Je suis pas spécialiste,  mais il me semble" puis tu dis que le blitter du mig est rigide. Ah bon ? Tu sors ça d'ou ? Du même chapeau que toutes tes autres élucubrations ?
Ensuite tu continues avec du "certainement pas" et du "encore moins" : tu ne joues pas les expert qui sait de quoi il parle ? Alors que tu fais 3 fausses affirmations dans la meme phrase.

Quand je t'ai répondu tu as pris un ton moqueur en me mettant au défi de te montrer une routine c2p plus rapide que sur ST grace au blitter.

Pas de bol : ça ne m'a posé aucun problème. Je t'ai posté deux routines C2P optimisées : une pour ST et une pour le mig.

Parce qu'il n'y a pas qu'avec le mig que tu parles sans savoir : c'est tout aussi vrai avec le ST...

ps :

C'est parce que tu disais devoir me croire sur parole que j'en ai conclu que tu ne savais pas comment fonctionne une C2P et j'ai estimé que ce n'était pas logique d'affirmer des choses dessus. Ce n'était pas une critique de tes connaissances en coding. Si tu l'as pris comme ça, je te présente mes plus plates excuses. 

Le niveau en tant que codeur de quelqu'un n'est jamais criticable. Pour moi, le type qui est content de parvenir à afficher les nombres premiers en GFA mérite autant de respect que celui qui découvre l'interpolation à base de addx. 
Je serai tout autant ravi d'aider le premier que le second. Aucune différence pour moi. tout comme cela ne ferait aucune différence que ce soit un codeur sur ST ou sur mig. 

Dans le cas présent, je critique ton attitude (que tu n'es pas le seul a adopter, loin de là) surtout pas tes connaissances.

rocky007
Donc très proche, c'est pas gagné. Peut-être avec des techniques modernes et 3 Mo minimum. Mais, dans le même cas, le mig aurait pu avoir un Ambermoon bien plus fluide.

C'est pourquoi je trouve que les "aurait pu" n'apportent rien au débat et font tourner en rond. 

exactement comme ton scrolling HAM... qd qq'un dit qu'un ST aurait été incapable de faire ambermoon dans son état actuel, et tu le confirme, cela est faux : le ST aurait pu approcher fortement et cela n'aurait pas été un jeu irréalisable comme certains le prétendent ici... ( contrairement à d'autres jeux comme Lion Heart )
Non, mon scrolling HAM ne rentrait pas dans le cadre du "aurait pu", il entre dans celui du "c'est possible". je te rappelle qu'à la base de cette discussion tu disais (et tu n'étais pas le premier, loin de là...) que le HAM ne pouvait afficher que des images statiques et qu'il ne restait que 1% de CPU. J'ai déjà prouvé que c'était faux. 
Quand au scrolling, c'est juste de la faisabilité dont il était question : je n'ai même pas dit que cela pourrait être utilisable dans un jeu. 

Oui je confirme ce que j'ai dit. Je ne reviens pas dessus. Je peux même ajouter qu'avec un peu moins de couleurs et de fluidité (il aurait fallu se limiter à 1 Mo et on ne disposait pas des techniques actuelles), il n'aurait pas du tout perdu de son interet. 
Pour moi Thalion a fait une erreur, ils auraient du le sortir en utilisant le moteur d'Amberstar : ça n'aurait pas couté grand chose en dev (ils auraient même pu faire évoluer un peu le moteur) et ça aurait donné un super jeu au ST. Il n'aurait donc pas été necessaire d'en vendre des tonnes pour être bénéficiaire... 

rocky007
Donc ça nous fait (44 + 20 + 32 + 36) * 5 000 = 660 000 cycles/secondes. Le ST disposant de 850 000 cycles de plus que le mig, on voit que l'avantage est déjà en grande partie consommé alors qu'on a pas joué de sample encore ! La routine qui doit s'en occuper va encore prendre quelques dizaines de cycles... 5 000 fois par secondes.

c'est bizarre, lorsque je fais le calcul :

64 ( interruption ) * 5000 = 320000 cycles ce qui te laisse 530000 cycles libre pour une simple routine monovoie de playback, ce qui est parfaitement réalisable.  de plus, c'est pas le seul élément à prendre en compte : personne ici ne peut dire comment est le code amiga et s'il a été correctement porté et optimisé. 
C'est bizarre mais lorsque tu fais le calcul :
 - Tu te limites à 5000 Hz mais penses-tu que cela soit suffisant pour obtenir un son acceptable avec une variation de tonalité (y en a dans vroom) ? Surement pas... 
 - Tu parles de routine monovoie mais tu as du remarquer qu'il y avait plusieurs voies dans Vroom non ?
 - Tu choisis d'écarter la sauvegarde/restauration des registres. Tu te rends compte que cela limitera l'efficacité des movem qui seront utilisé pour effacer l'écran par exemple ?

Le pire : même en faisant ça, tu as tort... 

Je ne me suis jamais interessé à l'exploitation du YM, il faudrait donc que je me documente avant de pouvoir écrire une "simple routine monovoie de playback" corectement optimisée. 
Aussi, je vais me contenter d'en reprendre une. Elle est posté par l'auteur de Wolfenstein 3D. Je pense que l'on peut estimer que c'est quelqu'un qui sait de quoi il parle... 

La voici : 

    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. Le total est de 124 cycles. 
En fait 126 puisque le bne.s prendra 2 cycles de plus sur un vrai ST. 
        
Donc au final, on obtient 126 * 5000 = 630 000 cycles + 320 000 cycles pour l'interruption 

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

Même en optimisant à mort, quitte à stocker les samples sur 8 octets (ce qui n'est pas réaliste), une routine pour reproduire ce qu'il faut dans vroom consommerait bien plus... 

Tu as raison par contre : personne ne peut dire comment est le code amiga. Mais ce dont on est certain, c'est que la partie son a du être réécrite corretement puisqu'il n'y a pas le choix. C'est un classique dans les St-ports. Et jouer des samples sur 4 voix à 20 Khz avec une variation de tonalité sans bloquer de registres est gratuit sur le mig. 
Quand à l'affichage, comme tout se fait au cpu et que le mig s'est restreint à du 320x200x16, ça doit prendre le même temps.

rocky007
Mais c'est faux de dire que toutes les applis pro allaient plus vite sur ST

sur ST, une application tournaient pour elle seule, sur amiga, tu as tout les threads qui tournent en fonds.  donc pas convaincu
Plutot que de repartir sur un long discours qui ne pourrait pas te convaincre, je t'invite à essayer des applis qui existent sur les 2 machines. PageStream ou Pro24 existent sur les 2 plates-formes et sont du domaine de prédilection du ST. Tu verras que la gestion des threads est extrement performante. 
Ou essaie un jeu OS-Friendly dans lequel tu peux couper le multitache (Breathless, un doom-like par exemple doit le permettre) : tu ne verras aucune différence dans le frame-rate. 

Et je ne vois pas ou tu as vu qu'l y avait un tas de threads qui tournent en fond.

rocky007 a écrit:
Quand bien même : si on avait besoin d'un cpu rapide pour une utilisation sérieuse, on pouvait mettre une carte accélératrice, nous.

?? l'atari aussi... il y a avait une large gamme de cartes accélératrices
Sur ST ? Pas du tout !

Tout ce qu'il y avait c'est des cartes qui se mettaient à l'intérieur du ST. Sur que les pros étaient tous des geek bricoleurs qui se foutaient de la garantie...
Et tout ce qu'il y avait, c'était des 68000 boostés. La plupart du temps à 16 Mhz. Et celles qui étaient le plus efficage avait une mémoire cache. Ce qui permettait un gain de 50-60 % à cette fréquence. Celles qui n'en n'avaient pas atteignaient 10-20 % d'amélioration en réel.
Parce que tu peux mettre le micro-processeur que tu veux dans un ST, il sera toujours ralenti par la RAM..
Meme Atari, dans le MegaSTE a du mettre une mémoire cache pur réussir à accélérer sa machine et suivre un époustouflant 68000 à 16 Mhz... Ouaouhhh !

Un Amiga 500 pouvait être accéléré avec un 68000/010/020/030/040/060 sans aucun problème (pour les derniers, pas dès le début puisqu'ils n'existaient pas). Y avait rien à démonter et le gain de vitesse était totalement disponible.

rocky007 a écrit:il y a une différence entre qualité sonore, et qualité des phonèmes et le programme qui les gère.
Montre nous ça parce que je n'ai pas vu ces phonèmes géniaux. J'ai du mal chercher...

Et tu n'as pas répondu : à quoi ça sert dans un logiciel ? Sur mig tu pouvais en faire dans un programme en GFA ou dans un script...

rocky007 a écrit:
Donc, si le port série ne peut pas faire du midi avec la même qualité, je dois donc en déduire que Steinberg et C-Lab sont des arnaqueurs puisque ces 2 entreprises (les plus renommées dans le midi) proposaient des boitiers midi qui, je le répète, avaient plus de prises et de canaux que ce qu'il y a d'origine. Et ces boitiers se branchaient sur le port série. Je parle de boitiers midi pour le ST, pas pour le mig ! 
Ces boitiers sont la preuve que le port série du ST peut faire du midi plus efficacement que les ports midi du ST... Alors pourquoi pas le mig ? Ben justement : lui aussi avait des boitiers avec plus de prises que ce qu'il y a d'origine sur un ST.

oui et est-ce aussi bon qu'une seule prise midi ?  je possède encore le modèle steinberg et je me souviens avoir eu pas mal de problème de synchro, problème inexistant qd je passais en direct sur la prise midi.
Oui tout à fait. C'est aussi bon. ça marche EXACTEMENT de la même façon avec une bande passante plus élevée.
Ah bon ? Donc Steinberg, le nom plus respectée dans l'informatique musicale à l'époque vendait des boitiers qui marchaient mal (et c'était des boitiers pro pour certains en rack 19". Pas des mini boitiers à 100 Francs...). J'ai du mal à croire ça...
Tu es au courant que sur mig aussi on trouve des artistes qui ont fait du midi et sorti des albums ?
C'est bizarre parce que aucun mig n'a de prise midi en série : ils sont forcément passés par un boitier...
Comment ont-ils fait ?
Maintenant je ne dis pas que tu mens : peut-être que ton boitier avait un problème. Ou que tu utilises un pass-thru pour imprimante qui en pose.
avatar
stapha92
Patient contaminé

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

Revenir en haut Aller en bas

amiga - GUERRE ST-AMIGA, FIGHT !!! - Page 34 Empty Re: GUERRE ST-AMIGA, FIGHT !!!

Message par Invité Lun 7 Sep 2015 - 10:24

- L'archimedes : Tiens, mais j'en avais pas parlé de celui là ? A l'époque c'est cantoné au marché britannique, c'est plus cher qu'un 500 (je te rappel la gamme de prix) et... c'est multitache coopératif ! Je sais même pas s'il y a le plug and play (peut être). Et le sujet sur l'archimèdes ici a montré que c'était pas au niveau d'un Amiga 500 ! Mais le premier modèle c'est 1987 (même année que le 500)
https://en.wikipedia.org/wiki/Acorn_Archimedes
Le problème de l'archi est un peu le même que le ST, à part qu'il a un CPU de la mort, donc requiert bcp de RAM (et rapide surtout 120/140 ns) ce qui fait exploser son prix,donc pas de copros .
Les pros archis diront toujours que l'intérêt de copros quand tu as l'ARM est nul ,ce qui est débile mais bon, car je connais pas de bécanes performantes en tout avec juste le CPU .
avatar
Invité
Invité


Revenir en haut Aller en bas

amiga - GUERRE ST-AMIGA, FIGHT !!! - Page 34 Empty Re: GUERRE ST-AMIGA, FIGHT !!!

Message par dlfrsilver Lun 7 Sep 2015 - 14:51

stapha92 a écrit:
rocky007
Un TT maintenant ? Quand bien même, tu pourrais pas.
oui un TT, et les débits que permettait le TT en SCSI ainsi que les HD SCSI permettent ce type d'animation
On parle du ST je te rapelle : regarde le titre du TOPIC. Le STE ne devrait même pas y etre (la grande majorité des ST vendus ne sont pas des STE) 

Rapellons un peu le début du débat. Tu t'es emporté avec ces vidéos. Tu étais en joie et tu n'as pas hésité à te moquer des amigaistes. 
Tu as même traité cryodav76 de rigolo alors que ses interrogations étaient fondés. Interrogations auxquelles tu as repondu des choses du genre :
rocky007
il ne faut rien modifier à la machine, faut juste un lecteur CF
rocky007
mon dieu, mais..pfff..c'est qd même pas compliqué à comprendre :
le STe sait afficher sans problème une image overscann 4096 couleurs... 
alors techniquement, c'est super simple : il lit l'image sur la CF et l'affiche, et ce 25 par seconde. 
il n'y a pas de buffering ( hormis peut-être un simple swap) , pas de décompression, rien, lit un bloc d'octets et l'affiche, pourquoi il lui faudrait 5 giga de RAM ? 300 ko maximum suffisent largement pour effectuer l'opération. donc le seul point crucial est le débit, il n'y a rien de magique la dedans. 
c'est de la simple logique que même un amigaiste pourrait comprendre ( quoique, apparemment non, puisque tu butes une vidéo d'un autre player qui n'a rien à voir )
rocky007
Il lit l'image et il l'affiche""... Tu es vraiment à coté de la plaque...
Pour ces vidéos, j'ai parlé de débits et des explications de l'auteur pour t'expliquer que c'était impossible sur un ST non modifié. ça n'a pas suffit à te convaincre et tu te réfugies maintenant derrière le TT pour éviter de reconnaitre que tu t'étais moqué de cryodav76 à tort.

Alors je vais t'expliquer pourquoi c'est impossible meme avec un débit SCSI de 2,5 Mo/s (donc le double de l'interface la plus rapide AUJOURD'HUI !) :

Une image de 416x228 en 16 couleurs prend 47424 octets. ça donne 47 924 x 50 = 2,3 Mo à "lire et à écrire" à chaque seconde. Un 68000 en est totalement incapable ! Donc si : c'est magique...
N'importe quel codeur ST ou mig sait cela... 

Et il faut rajouter les changements de palette : 

Spectrum 512 a montré que le maximum que le ST pouvait faire c'est 3 changements de palette / ligne. Si tu passes en overscan, c'est moins parce que ça bouffe aussi du cpu à chaque ligne. Donc 416 pixels/ligne avec 3 changements de couleurs, c'est impossible sur un ST, même avec une image fixe !
Rien que ça aurait du te mettre la puce à l'oreille... 

Ok, faisons comme si un ST pouvait afficher ce genre d'image... 

Le changement de palette occupe tout le cpu pendant toute la zone d'affichage qui représente 73% de la frame. Il reste donc 27% des ressources cpu à chaque frame pour "lire l'image et l'écrire". 
ça fait du 2,3 Mo/0,27 = 8,5 Mo/s. C'est plus du double de ce que peut faire le blitter du mig qui lui-même explose un 68000 !!!! 
En fait, c'est plus que la RAM du ST (ou la chip ram du mig) peut faire... C'est dire le ridicule de tes affirmations ! C'est encore plus "magique" !

Alors quand tu te moques des amigaistes comme cryodav76 (à qui tu proposais un mouchoir après avoir posté ces vidéos), c'est toi même que tu décridibilise... 

Au fait pour les 8,5 Mo/s : ce nombre s'applique aussi au TT. Donc tes affirmations sur les débits du TT en SCSI, tu peux les garder

Au final tu avais raison sur un point : cryodav76 avait besoin d'un mouchoir car il a du pleurer de rire...

rocky007
Je ne comprends pas ton explication.  si j'ai bien compris, fait bien scroller ton écran HAM d'un pixel ?  donc tu auras des problème de couleurs.
C'est pourtant pas compliqué. 

Je ne fais pas scroller l'écran, je le déplace ! Je détaille : 

Sur le mig, la taille et la position de l'écran peuvent être librement défini. Y a pas juste un mode fenêtre et un mode overscan. 
Donc quand je dis que je déplace l'écran, c'est vraiment ça. mais comme j'ai mis deux sprites (de couleur noire, qui font toute la hauteur de l'écran et qui sont au dessus du playfield) à gauche et à droite de l'écran, ça donne l'impression que ça scrolle. Il n'empeche que Denise va traiter les pixels cachés, donc il n'y aura aucun problème de couleur. 

Quand le déplacement atteint 16 pixels, on déplace le contenu en changeant le registre d'adresse. On aura donc largement eu le temps de préparer la copperlist suivante. 

C'est clair cette fois ?

rocky007tu 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, et mirrorant et doublant certaines lignes pour le partie haute et basse, ce qui fait facilement 80 étapes d'animations avec 1 mo
Ah bon ? Alors c'est quoi çà :
rocky007
euh, encore une fois tu as l'air bien sûr de toi... moi tout ce que je vous, c'est un fond précalculé, ainsi qu'une plateforme précalculée également. Et rien du tout infaisable sur ST. Le shoot ? qu'y a-t-il de spéciale ? Le parallax précalculé comme on en faisait sur St depuis la Union Demo ?
Vraiment là, tu as pris le mauvais exemple.
Ou alors ça :
rocky007
pour moi, un effet qui est strictement identique comme rotation de plateformes identiques au degré prés , effet rotatif avec motif répétitif, tout ça, ça m'a l'air pas catholique. Pourquoi, si c'était du temps réel, ne pas exploiter ce dernier, en faisant des plateformes de différents tailles, qui bougent différemment ou en fonction du personnage
Bon pour celle là, je peux te trouver une excuse : les plates-formes bougent justement en fonction du personnage : son poids les fait pencher. Mais j'admet volontiers que ça ne se voit pas vraiment dans la vidéo.

Plus loin dans ce post tu expliques avoir planifié de ripper les données et adapter en GFA et prouver que c'était possible en pre-calc avec 640 Ko.

Bon allez, comme tu n'as jamais été capable de reconnaitre une erreur. On va oublier et se concentrer sur le tube. 

Tu arrives comment à 80 étapes d'animations ? Tu sors ce chiffre de quel chapeau ? Et combien pèse chacune d'entre elles ? 

Tactique classique : tu assènes des affirmations assorties de concepts que tu ne maitrises pas et de nombre sortis de ton chapeaux. ça fait illusion auprès de certains peut-être, mais surement pas auprès de ceux qui connaissent un tant soit peu les machines dont on parle.

Allons-y :

1) Le motif du tube se répète si on considère que les changement de couleurs peuvent être obtenu avec un changement de palette. Inutile donc d'avoir une image qui fait tout l'écran. 
L'image necessaire semble faire 50 lignes de haut. 
2) Chaque ligne de l'écran a une largeur différente. Mais comme la courbure est centrée, chaque largeur est utilisée 2 fois. On a donc 100 largeurs différentes. 

ça nous fait 50 lignes à stocker dans 100 largeurs. 5 000 lignes donc. 
Une ligne fait 160 Octets : 50x100x160 = 800 Ko. ça fait beaucoup pour du précalc. 
Mais ce n'est pas le seul problème : copier les différentes lignes en optimisant correctement le code 68000 va prendre quasiment tout le temps cpu disponible dans une frame. 
Donc en GFA, tu peux oublier cette méthode. 

Tu as codé sur ST et tu ne sais pas que la simple copie d'une image prend presqu'une frame entière en assembleur ? 

Pour le faire en GFA, il te faudrait stocker les images entières et modifier l'adresse écran à chaque fois. Mais comme il y a 50 lignes à traiter avant de boucler, il te faudrait 50 images pour que ça reste fluide meme quand la vitesse ralentie. 50 x 32 Ko = 1,6 Mo. Donc en GFA, tu peux oublier... 

Récapitulons :
Tu nous as expliqué qu'un ST pouvait afficher certaines vidéos sans modifs, alors qu'il ne peut même pas afficher ne serait-ce que l'une des frames de ces vidéos en tant qu'image fixe.
Tu as affirmer pourvoir reproduire 2 effets en précalc en gfa alors que tu ne pourrais en faire un seul à la fois (pour les plates-formes : ce serait pire...).

ça fait 2 fois que tu es à coté de la plaque quand tu parles du ST. En fait bien plus mais je me restreint au sujet abordés dans le débat qui nous oppose.

Je laisse aux lecteurs le soin de juger de ta crédibilité quand tu prétend expliquer des choses sur le mig quand on voit à quel point tu peux te planter quand tu parles de ta machine de prédilection...

Allez, je suis gentil et je vais t'expliquer comment cet effet peut être obtenu sur ST dans une démo. 

Tu commences par stocker tes lignes sur 3 plans : le précalc prendra 600 Ko. Le problème va être de l'appliquer sur 4 plans sans perdre de temps. 
Sur un mig, les bitplans étants séparés, il n'y aurait aucune difficulté : on ne traiterait que 3/4 des données. 

Sur ST on ne peut pas faire pareil mais, en etant malin, on peut s'arranger pour gagner du temps. 
J'explique : 

Sur ST la mémoire écran est disposé comme suit : 

11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44... 

Chaque chiffre représentent un octet et désigne le bitplan auquel il est destiné. On voit qu'ils sont regroupés 2 par 2 car le shifter lit les données 16 bits à la fois. 

On va stocker les lignes du tunnel en disposant les plans 1,2 et 4 de cette façon : 

11 22 11 22 11 22 11 22 11 22 11 22 11 22 44 44 44 44 44 44 44 

On chargera en 2 temps : 

movem.l (a6)+,d0/d2/d4/d6/a0/a2/a4 
movem.w (a6)+,d1/d3/d5/d7/a1/a3/a5 

Le premier movem travaille avec des longword, ce qui permet permet de charger le plan 1 dans la partie haute et le plan 2 dans la partie basse de chaque registre. 
le deuxième travaille avec des word. Seuls les partie basses de chaque registre seront chargées avec les données du plan 4. la partie haute, qui correspond au plan 3 restera à 0 (on aura pris soin d'effacer les registres avant le traitement bien sur)

Puis on ecrit tous les registres d'un coup : 

movem.l d0-d7/a0-a5,-(a7) 

On a fait notre conversion 3 plans->4 plans sans perdre de temps. On en a meme gagné grace au deuxieme movem qui traite des word et non des longword. 
(les 2 movem réunis prennent 108 cycles. un seul movem.l qui lit les 14 registres en aurait pris 124) 

Donc pour une ligne entière il faudra faire : 

movem.l (a6)+,d0/d2/d4/d6/a0/a2/a4 
movem.w (a6)+,d1/d3/d5/d7/a1/a3/a5 
movem.l d0-d7/a0-a5,-(a7) 
movem.l (a6)+,d0/d2/d4/d6/a0/a2/a4 
movem.w (a6)+,d1/d3/d5/d7/a1/a3/a5 
movem.l d0-d7/a0-a5,-(a7) 
movem.l (a6)+,d0/d2/d4/d6/a0/a2 
movem.w (a6)+,d1/d3/d5/d7/a1/a3 
movem.l d0-d7/a0-a3,-(a7) 

Pour traiter une ligne avec 3 séries, il faut que les deux premières utilisent 14 registres, il faudra donc se mettre en mode superviseur pour en avoir un de plus. 
On pourra aussi faire 4 série avec 10 registres et en garder 4 disponibles. ça pourrait être plus interessant au final, a cause de ce qu'il reste à faire. A tester. 

ça prendra 656 cycles par lignes. Il faudra ajouter le calcul de l'adresse de la ligne à copier (qui pourra être stockée dans une table de précalc) et le bouclage (et il ne reste plus de registres pour ça...). On va arrondir le tout à 700 cycles. Donc ça fait 700 * 200 lignes * 50 i/s = 7 000 000 cycles : il en reste 1 millions. On va donc pouvoir mettre quelques interruptions horizontales pour faire les changements de palettes. 

Par contre, après, il ne restera plus assez pour ajouter une plate-forme. même sans faire de rotation...

Donc OUI : on peut faire l'effet de tube sur un ST en utilisant 600 Ko de précalc et plus de 90% des ressources cpu avec un code correctement optimisé. 

Au final tu auras reproduis partiellement un effet du mig en bouffant tellement de RAM et de CPU que ça sera inutilisable. Exactement comme la phaleon demo et son screen qui reproduit très partiellement SOTB...

C'est pas la premiere fois qu'un AMIGA-FANBOY poste un code qui présente des optimisations spécifiques au ST. 
Par contre j'ai toujours pas vu le moindre code posté par l'un de nos experte STiste... 

Pour info, si on veut faire pareil sur le mig. C'est à dire en precalc, et sans utiliser le blitter, le copper ou les sprites il suffirait d'utiliser une interruption horizontale et de redefinir à chaque ligne l'adresse à afficher pour chacun des 3 plans. en comptant les changements de palette (qui seraient dans la même interruption). ça prendrait 10 % de cpu...

Et oui : meme sans utiliser ses atouts, le mig explose le ST juste grace à la souplesse de son chipset...


rocky007
Entrelacé, c'est le truc qui était une obligation en vidéo. Et ou as-tu vu qu'il faut un moniteur à plus 10 000 FF pour l'afficher ? Faudrait que tu te décides à ne parler que des domaines que tu maitrises, ça t'éviterait pas mal d'inepties : Le mode entrelacé a toujours fonctionné avec tous les moniteurs et TV.

oui avec des scintillements à flinguer les yeux en 10 minutes.

Tu as attendu l'époque des LCD pour regarder la TV ? Parce que je le répète à l'intention de tous ceux qui, comme toi, nous rabachent cet argument bidon : 

 - TOUT CE QUE TU POUVAIS VOIR À LA TÉLÉ ÉTAIT ENTRELACÉ à l'époque du mig (TV, K7 video, Laserdisc, DVD) !!! Autant qu'avec le mig, la seule différence est le niveau de contraste maximum : il est bien plus élevé avec un mig ou un ST en RGB qu'avec tous les autres systèmes (sauf le matériel pro). Il y avait des TV 100 Hz à l'époque des CRT justement pour réduire ce phénomène. ça marchait d'ailleurs très bien pour le mig... 
 - TOUS LES MODES D'AFFICHAGE DU MIG EXISTENT EN ENTRELACE ET EN PROGRESSIF !! 
 - MEME AUJOURD'HUI, TOUS LES PROGRAMMES TV SONT ENTRELACES !! (Quand une télé affiche 576i, le i signifie interlaced) Mais ça se voit moins (malgré l'utilisation du numérique qui permet d'atteindre des niveaux de contraste maximum) à cause du temps de latence des LCD 
 
Et on parlait de l'utilisation PRO. L'absence de mode entrelacé était rédhibitoire pour eux. Ils doivent être aveugles puisqu'ils nous balancent de l'entrelacé depuis les débuts de la TV...

rocky007

un simple exemple, déjà cité :


Agrandir cette image
amiga - GUERRE ST-AMIGA, FIGHT !!! - Page 34 13_017
Tu es sérieux là ? Tu me sors une carte à 16 000 Fr qui ne se branche que sur un mega ST 2/4 ? ça fait la config à 30 000 si on comptes le deuxième moniteur !!! 
Parce que ta super carte sort une image qui est à part de celle du ST... C'est ridicule... Et ce n'est utilisable qu'avec des programmes spécifiques... 
Ce n'est pas la faute de la carte (par ailleurs très bien faite), c'est la faute de la super architecture du mega ST qui en fait une machine pas vraiment évolutive 
Pour 30 000 Fr tu avais un A2000 avec une carte graphique 24 bits utilisables par pleins de logiciels (car connectée dans le port vidéo que LUI possédait...) et une carte accélératrive qui faisait que ton mega ST pouvait se rabiller. 
En fait, vu l'année ou est sortie ta carte chili, c'est un A3000 + carte graphique que tu pouvait avoir... 

C'est bien de nous parler du TT, puis du Mega ST, puis d'une carte à 16 000 Fr. Mais on est dans un topic Amiga VS ST... 

Tu pouvais faire du titrage avec un A500+genlock. En haute définition, overscan (704x576x16)... Un ST peut même pas en rever... 

Tant qu'on y est, on va prendre un 800XL avec VBXE et expliquer que c'est mieux qu'un C64... 

rocky007
Pourquoi sur parole ? 
J'ai livré des codes. Tu peux les prendre pour les faire vérifier sur des forums ST ou Amiga. Pas besoin de me faire confiance. 
Et ne t'inquiètes pas : si j'ai menti dans les codes, on tardera pas à voir quelqu'un venir rectifier. 

Si je résume : 
 - Tu ne sais pas comment fonctionne le blitter du mig. 
 - Tu ne comprends pas le code d'une C2P 
Et tu te permets d'affirmer que le blitter du mig ne peut pas en faire. Et tu insistes en plus ! Je t'avais donné des arguments faciles à vérifier 
Surtout pour quelqu'un qui codait sur ST... 

Y a pas quelque chose qui cloche ?

en quoi j'insiste ?  tu as donné ta démonstration de l'utilisation partielle du blitter dans une routine C2P, ok, je l'ai acceptée non ? 
je n'ai jamais prétendu connaître l'amiga et encore moins le fonctionnement de son blitter, ni même être un expert Atari.  Où vois-tu que j'ai prétendu être cela ?  et je te rassure, je sais comment fonctionne une routine C2P, peut-être pas de la façon la plus optimisée, mais dans son principe.
Tu insiste en disant "même si je dois te croire sur parole". Tu pourrais juste dire "ok tu as raison" mais non : ça a l'air d'être trop dur. 

Je me permet de te raffaichir la mémoire : 
rocky007
Je suis pas spécialiste,  mais il me semble que blitter de l'amiga est assez rigide.  Il très pratique pour déplacer des gros blocs de mémoire, mais certainement pas pour aider à faire du polyfill sur des scènes complexes et encore moins pour du C2P.
tu commences pas "Je suis pas spécialiste,  mais il me semble" puis tu dis que le blitter du mig est rigide. Ah bon ? Tu sors ça d'ou ? Du même chapeau que toutes tes autres élucubrations ?
Ensuite tu continues avec du "certainement pas" et du "encore moins" : tu ne joues pas les expert qui sait de quoi il parle ? Alors que tu fais 3 fausses affirmations dans la meme phrase.

Quand je t'ai répondu tu as pris un ton moqueur en me mettant au défi de te montrer une routine c2p plus rapide que sur ST grace au blitter.

Pas de bol : ça ne m'a posé aucun problème. Je t'ai posté deux routines C2P optimisées : une pour ST et une pour le mig.

Parce qu'il n'y a pas qu'avec le mig que tu parles sans savoir : c'est tout aussi vrai avec le ST...

ps :

C'est parce que tu disais devoir me croire sur parole que j'en ai conclu que tu ne savais pas comment fonctionne une C2P et j'ai estimé que ce n'était pas logique d'affirmer des choses dessus. Ce n'était pas une critique de tes connaissances en coding. Si tu l'as pris comme ça, je te présente mes plus plates excuses. 

Le niveau en tant que codeur de quelqu'un n'est jamais criticable. Pour moi, le type qui est content de parvenir à afficher les nombres premiers en GFA mérite autant de respect que celui qui découvre l'interpolation à base de addx. 
Je serai tout autant ravi d'aider le premier que le second. Aucune différence pour moi. tout comme cela ne ferait aucune différence que ce soit un codeur sur ST ou sur mig. 

Dans le cas présent, je critique ton attitude (que tu n'es pas le seul a adopter, loin de là) surtout pas tes connaissances.

rocky007
Donc très proche, c'est pas gagné. Peut-être avec des techniques modernes et 3 Mo minimum. Mais, dans le même cas, le mig aurait pu avoir un Ambermoon bien plus fluide.

C'est pourquoi je trouve que les "aurait pu" n'apportent rien au débat et font tourner en rond. 

exactement comme ton scrolling HAM... qd qq'un dit qu'un ST aurait été incapable de faire ambermoon dans son état actuel, et tu le confirme, cela est faux : le ST aurait pu approcher fortement et cela n'aurait pas été un jeu irréalisable comme certains le prétendent ici... ( contrairement à d'autres jeux comme Lion Heart )
Non, mon scrolling HAM ne rentrait pas dans le cadre du "aurait pu", il entre dans celui du "c'est possible". je te rappelle qu'à la base de cette discussion tu disais (et tu n'étais pas le premier, loin de là...) que le HAM ne pouvait afficher que des images statiques et qu'il ne restait que 1% de CPU. J'ai déjà prouvé que c'était faux. 
Quand au scrolling, c'est juste de la faisabilité dont il était question : je n'ai même pas dit que cela pourrait être utilisable dans un jeu. 

Oui je confirme ce que j'ai dit. Je ne reviens pas dessus. Je peux même ajouter qu'avec un peu moins de couleurs et de fluidité (il aurait fallu se limiter à 1 Mo et on ne disposait pas des techniques actuelles), il n'aurait pas du tout perdu de son interet. 
Pour moi Thalion a fait une erreur, ils auraient du le sortir en utilisant le moteur d'Amberstar : ça n'aurait pas couté grand chose en dev (ils auraient même pu faire évoluer un peu le moteur) et ça aurait donné un super jeu au ST. Il n'aurait donc pas été necessaire d'en vendre des tonnes pour être bénéficiaire... 

rocky007
Donc ça nous fait (44 + 20 + 32 + 36) * 5 000 = 660 000 cycles/secondes. Le ST disposant de 850 000 cycles de plus que le mig, on voit que l'avantage est déjà en grande partie consommé alors qu'on a pas joué de sample encore ! La routine qui doit s'en occuper va encore prendre quelques dizaines de cycles... 5 000 fois par secondes.

c'est bizarre, lorsque je fais le calcul :

64 ( interruption ) * 5000 = 320000 cycles ce qui te laisse 530000 cycles libre pour une simple routine monovoie de playback, ce qui est parfaitement réalisable.  de plus, c'est pas le seul élément à prendre en compte : personne ici ne peut dire comment est le code amiga et s'il a été correctement porté et optimisé. 
C'est bizarre mais lorsque tu fais le calcul :
 - Tu te limites à 5000 Hz mais penses-tu que cela soit suffisant pour obtenir un son acceptable avec une variation de tonalité (y en a dans vroom) ? Surement pas... 
 - Tu parles de routine monovoie mais tu as du remarquer qu'il y avait plusieurs voies dans Vroom non ?
 - Tu choisis d'écarter la sauvegarde/restauration des registres. Tu te rends compte que cela limitera l'efficacité des movem qui seront utilisé pour effacer l'écran par exemple ?

Le pire : même en faisant ça, tu as tort... 

Je ne me suis jamais interessé à l'exploitation du YM, il faudrait donc que je me documente avant de pouvoir écrire une "simple routine monovoie de playback" corectement optimisée. 
Aussi, je vais me contenter d'en reprendre une. Elle est posté par l'auteur de Wolfenstein 3D. Je pense que l'on peut estimer que c'est quelqu'un qui sait de quoi il parle... 

La voici : 

    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. Le total est de 124 cycles. 
En fait 126 puisque le bne.s prendra 2 cycles de plus sur un vrai ST. 
        
Donc au final, on obtient 126 * 5000 = 630 000 cycles + 320 000 cycles pour l'interruption 

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

Même en optimisant à mort, quitte à stocker les samples sur 8 octets (ce qui n'est pas réaliste), une routine pour reproduire ce qu'il faut dans vroom consommerait bien plus... 

Tu as raison par contre : personne ne peut dire comment est le code amiga. Mais ce dont on est certain, c'est que la partie son a du être réécrite corretement puisqu'il n'y a pas le choix. C'est un classique dans les St-ports. Et jouer des samples sur 4 voix à 20 Khz avec une variation de tonalité sans bloquer de registres est gratuit sur le mig. 
Quand à l'affichage, comme tout se fait au cpu et que le mig s'est restreint à du 320x200x16, ça doit prendre le même temps.

rocky007
Mais c'est faux de dire que toutes les applis pro allaient plus vite sur ST

sur ST, une application tournaient pour elle seule, sur amiga, tu as tout les threads qui tournent en fonds.  donc pas convaincu
Plutot que de repartir sur un long discours qui ne pourrait pas te convaincre, je t'invite à essayer des applis qui existent sur les 2 machines. PageStream ou Pro24 existent sur les 2 plates-formes et sont du domaine de prédilection du ST. Tu verras que la gestion des threads est extrement performante. 
Ou essaie un jeu OS-Friendly dans lequel tu peux couper le multitache (Breathless, un doom-like par exemple doit le permettre) : tu ne verras aucune différence dans le frame-rate. 

Et je ne vois pas ou tu as vu qu'l y avait un tas de threads qui tournent en fond.

rocky007 a écrit:
Quand bien même : si on avait besoin d'un cpu rapide pour une utilisation sérieuse, on pouvait mettre une carte accélératrice, nous.

?? l'atari aussi... il y a avait une large gamme de cartes accélératrices
Sur ST ? Pas du tout !

Tout ce qu'il y avait c'est des cartes qui se mettaient à l'intérieur du ST. Sur que les pros étaient tous des geek bricoleurs qui se foutaient de la garantie...
Et tout ce qu'il y avait, c'était des 68000 boostés. La plupart du temps à 16 Mhz. Et celles qui étaient le plus efficage avait une mémoire cache. Ce qui permettait un gain de 50-60 % à cette fréquence. Celles qui n'en n'avaient pas atteignaient 10-20 % d'amélioration en réel.
Parce que tu peux mettre le micro-processeur que tu veux dans un ST, il sera toujours ralenti par la RAM..
Meme Atari, dans le MegaSTE a du mettre une mémoire cache pur réussir à accélérer sa machine et suivre un époustouflant 68000 à 16 Mhz... Ouaouhhh !

Un Amiga 500 pouvait être accéléré avec un 68000/010/020/030/040/060 sans aucun problème (pour les derniers, pas dès le début puisqu'ils n'existaient pas). Y avait rien à démonter et le gain de vitesse était totalement disponible.

rocky007 a écrit:il y a une différence entre qualité sonore, et qualité des phonèmes et le programme qui les gère.
Montre nous ça parce que je n'ai pas vu ces phonèmes géniaux. J'ai du mal chercher...

Et tu n'as pas répondu : à quoi ça sert dans un logiciel ? Sur mig tu pouvais en faire dans un programme en GFA ou dans un script...

rocky007 a écrit:
Donc, si le port série ne peut pas faire du midi avec la même qualité, je dois donc en déduire que Steinberg et C-Lab sont des arnaqueurs puisque ces 2 entreprises (les plus renommées dans le midi) proposaient des boitiers midi qui, je le répète, avaient plus de prises et de canaux que ce qu'il y a d'origine. Et ces boitiers se branchaient sur le port série. Je parle de boitiers midi pour le ST, pas pour le mig ! 
Ces boitiers sont la preuve que le port série du ST peut faire du midi plus efficacement que les ports midi du ST... Alors pourquoi pas le mig ? Ben justement : lui aussi avait des boitiers avec plus de prises que ce qu'il y a d'origine sur un ST.

oui et est-ce aussi bon qu'une seule prise midi ?  je possède encore le modèle steinberg et je me souviens avoir eu pas mal de problème de synchro, problème inexistant qd je passais en direct sur la prise midi.
Oui tout à fait. C'est aussi bon. ça marche EXACTEMENT de la même façon avec une bande passante plus élevée.
Ah bon ? Donc Steinberg, le nom plus respectée dans l'informatique musicale à l'époque vendait des boitiers qui marchaient mal (et c'était des boitiers pro pour certains en rack 19". Pas des mini boitiers à 100 Francs...). J'ai du mal à croire ça...
Tu es au courant que sur mig aussi on trouve des artistes qui ont fait du midi et sorti des albums ?
C'est bizarre parce que aucun mig n'a de prise midi en série : ils sont forcément passés par un boitier...
Comment ont-ils fait ?
Maintenant je ne dis pas que tu mens : peut-être que ton boitier avait un problème. Ou que tu utilises un pass-thru pour imprimante qui en pose.

Merci encore pour ces explications, j'en connais un qui s'est mangé son "coup de bon fonctionnement" du lundi matin MDR

quand je lis ce que Stapha écrit, j'en viens à me dire mais pourquoi les Ataristes viennent nous faire la guerre alors que qu'elle fut pire que perdue, et que plus il en écrit, et plus les choses deviennent claires. Je regrette de ne pas avoir d'aptitude en programmation, ça m'aurait permis de pouvoir expliquer certaines choses voir d'en affirmer d'autres de manière empirique.

C'est surement ça mon problème. Je comprends et je constate, le souci dans certains cas c'est de prouver les choses.

L'exemple de Vroom est parlant, de même que mon histoire de temps pour formater une disquette. Les Ataristes rabachent que le ST est plus rapide alors que c'est simplement pas vrai du tout. Ils ont répandu des mythe(o)s au sujet de l'amiga qui ne tiennent pas la route : Le WB de l'amiga plante souvent (connerie), les accès disques sont plus rapide (connerie), le CPU est plus rapide sur ST (vrai et une connerie en même temps).

Le CPU du ST est plus rapide oui, car je pense que les ingés d'atari ont du se rendre compte que la machine de base n'étant pas un cheval de course, ils ont préféré mettre un 68000 avec un quartz doté d'une cadence de 8 mhz pour booster le tout.

L'amiga lui a été volontairement "ralenti" pour qu'il puisse se synchroniser avec le chipset.

Donc en bref, c'est une comparaison qui semble avoir un sens, mais qui en fait n'en a pas dans la réalité.

Stapha a même prouvé et expliqué dans ses arguments que l'architecture même de l'amiga, sans parler de CPU est beaucoup plus rapide que celle du ST. C'est pour ça qu'on dit que l'Amiga est doté d'une architecture matériellement accélérée, la ou le ST a une architecture totalement standard avec un 68k couplé à un framebuffer.

Les explications de Stapha confirment également ce que je disais plus haut : à chose égale, le CPU du ST est totalement étranglé, la ou le CPU de l'amiga garde un maximum de marge. Et cela malgré le fait que le CPU du ST tourne plus vite que celui de l'Amiga !
avatar
dlfrsilver
Interne
Interne

Masculin Nombre de messages : 7647
Age : 46
Date d'inscription : 29/05/2009

Revenir en haut Aller en bas

amiga - GUERRE ST-AMIGA, FIGHT !!! - Page 34 Empty Re: GUERRE ST-AMIGA, FIGHT !!!

Message par Invité Lun 7 Sep 2015 - 15:24

si l'AMIGA est une console à disquettes, 
Le ST est un boulier avec une sortie péritel.


les ataristes trouveront toujours les plus viles excuses pour prouver la superiorité de leur machine.

ON ESSAYE DE NOUS FAIRE CROIRE QUE MON PETIT PONEY EST PLUS FORT QUE GODZILLA dans ce topic. même sans aucune connaissance approfondie de l'affaire (d'autres en parleront mieux que moi, mais les faits sont la), il suffit d'ouvrir les yeux 10 secondes. A ce niveau là c'est plus de la mauvaise foi, c'est du déni de réalité.

amiga - GUERRE ST-AMIGA, FIGHT !!! - Page 34 Boulier-a-10-rangees
figure 1: le 1er prototype d'Atari ST
avatar
Invité
Invité


Revenir en haut Aller en bas

amiga - GUERRE ST-AMIGA, FIGHT !!! - Page 34 Empty Re: GUERRE ST-AMIGA, FIGHT !!!

Message par Urbinou Lun 7 Sep 2015 - 15:29

MDR MDR Y en a qui craquent ici !!
Urbinou
Urbinou
Docteur agrégé **
Docteur agrégé **

Masculin Nombre de messages : 12632
Age : 55
Localisation : Liège, Belgique
Date d'inscription : 12/02/2013

http://cambouisdelatari.wordpress.com

Revenir en haut Aller en bas

amiga - GUERRE ST-AMIGA, FIGHT !!! - Page 34 Empty Re: GUERRE ST-AMIGA, FIGHT !!!

Message par dlfrsilver Lun 7 Sep 2015 - 15:42

kaot a écrit:si l'AMIGA est une console à disquettes, 
Le ST est un boulier avec une sortie péritel.


les ataristes trouveront toujours les plus viles excuses pour prouver la superiorité de leur machine.

ON ESSAYE DE NOUS FAIRE CROIRE QUE MON PETIT PONEY EST PLUS FORT QUE GODZILLA dans ce topic. même sans aucune connaissance approfondie de l'affaire (d'autres en parleront mieux que moi, mais les faits sont la), il suffit d'ouvrir les yeux 10 secondes. A ce niveau là c'est plus de la mauvaise foi, c'est du déni de réalité.

amiga - GUERRE ST-AMIGA, FIGHT !!! - Page 34 Boulier-a-10-rangees
figure 1: le 1er prototype d'Atari ST

Oui c'est exactement ça, du déni de réalité. on peut avoir de bons souvenirs de jeux sur l'Atari, mais rester les pieds sur terre au sujet de la machine.
avatar
dlfrsilver
Interne
Interne

Masculin Nombre de messages : 7647
Age : 46
Date d'inscription : 29/05/2009

Revenir en haut Aller en bas

amiga - GUERRE ST-AMIGA, FIGHT !!! - Page 34 Empty Re: GUERRE ST-AMIGA, FIGHT !!!

Message par oliver27 Lun 7 Sep 2015 - 16:10

kaot a écrit:si l'AMIGA est une console à disquettes, 
Le ST est un boulier avec une sortie péritel.

Pas très sympa la comparaison.... enfin, si j'étais un beau boulier en bois, bien fini et tout et tout, j'aimerais pas être comparé à cette quincaillerie qu'est le ST  amiga - GUERRE ST-AMIGA, FIGHT !!! - Page 34 418468
avatar
oliver27
Patient en incubation

Masculin Nombre de messages : 88
Age : 51
Localisation : Fribourg, Suisse
Date d'inscription : 23/01/2014

Revenir en haut Aller en bas

amiga - GUERRE ST-AMIGA, FIGHT !!! - Page 34 Empty Re: GUERRE ST-AMIGA, FIGHT !!!

Message par Invité Lun 7 Sep 2015 - 16:44

et encore le boulier affiche davantage de couleurs simultanément.
avatar
Invité
Invité


Revenir en haut Aller en bas

amiga - GUERRE ST-AMIGA, FIGHT !!! - Page 34 Empty Re: GUERRE ST-AMIGA, FIGHT !!!

Message par dlfrsilver Lun 7 Sep 2015 - 16:50

Han on a Brice de Nice à bord loool :) ahahaha

Excellente celle-là !
avatar
dlfrsilver
Interne
Interne

Masculin Nombre de messages : 7647
Age : 46
Date d'inscription : 29/05/2009

Revenir en haut Aller en bas

amiga - GUERRE ST-AMIGA, FIGHT !!! - Page 34 Empty Re: GUERRE ST-AMIGA, FIGHT !!!

Message par stapha92 Lun 7 Sep 2015 - 18:24

ryosaeba a écrit:La question a déjà été posée mais je ne pense pas avoir eu une réponse claire.... Comment peut-on faire sur Amiga pour avoir un directory d'une D7 et ce de la manière la plus simple.... soit sans HD ? Et quid si pas de WB et de programme spécifique comme Opus ?
Ben tu fais fais un double-clic sur la disquette. On t'a déjà répondu... 
Ah je vois : tu veux dire dans le cas ou tu veux voir les fichiers cachés (sans icone) avec une des premières version du WB ? 
Pourquoi faire ça ? L'utilisateur lambda n'en a pas besoin ! Pour lui c'était plus pratique de ne voir que les fichiers qui lui étaient utiles... 

L'utilisateur expérimenté pouvait utiliser le CLI. Pas besoin du WB ou de DOpus 
ryosaeba a écrit:Autre question, pour faire démarrer en boot un programme, il faut une startup sequence ....faut-il obligatoirement passer par un éditeur de texte ?
pour le faire démarrer en boot, la seul chose à mettre dans la startup sequence est le nom du programme. 
Tu peux passer par un éditeur de texte quelconque ou taper ed dans le cli. 
Tu peux aussi créer ta startup sequence sans éditeur avec une seule ligne sous le cli : il suffit d'utiliser la redirection. 
Oui je sais, c'est encore un concept inconnu sur ST. J'expliquerai une autre fois... 

S'il s'agit d'un programme que tu souhaites lancer depuis le worbench, il te suffit de le mettre dans le dossier WBStartup 

ryosaeba a écrit:Autre question, si je mets un programme sur D7 qui a besoin de la librairie du WB, je dois jouer à l'alchimiste pour créer une D7 avec tous ce qui faut dedans ?
La librairie du WB n'est utile qu'avec le WB. Tu penses qu'elle sert à l'affichage des fenêtres ? Pas du tout, ça c'est pris en charge par Intuition. 
C'est une librairie qui se trouve en rom et qui offre bien plus de fonctions que le GEM... 
La librairie workbench sert surtout aux AppIcon, AppMenu, AppWindow. Ils s'agit de systèmes qui pemettent au workbench d'envoyer un message à une application en fonction d'actions de l'utilisateur. On est encore dans des concepts inconnu sur ST... Alors tu peux te moquer avec ton arrière pensée mais le fait est que même en faisant l'alchimiste, tu ne pourras jamais faire avec le GEM ce que te permet la librairie du WB... 

Au fait : la librairie du workbench consiste en un seul petit fichier. Pour l'alchimiste, tu repasseras... 

ryosaeba a écrit:Autre question... sur le ST les programmes se reconnaissent facilement car il y a une icone standard. Sur l'Amiga ce n'est pas le cas sauf si on en créer une spécifique ?
Euh... Jamais personne n'a eu du mal a reconnaitre un programme sur le mig. Pour la plupart des logiciel, quand tu cliquais sur la disquette, tu voyais 2 icones : un pour lancer le logiciel et un pour l'installer. Tu n'étais pas obligé de naviguer avec tous les fichiers présents sur la disquette pour les retrouver. 
Sinon, le WB peut afficher une icone spécifique aux exécutables qui n'en ont pas. Tu peux donc retrouver le système du ST. Et j'ai jamais vu un programme livré comme ça... 

Tu as voulu prouver quoi là ? Que le St était plus convivial ? Désolé mais ce n'est pas le cas pour moi. Le fait d'avoir des icones personnalisables (et de n'importe quel taille), des noms de fichiers en clair, et des fichiers que l'on peut cacher est plus convivial pour moi. D'ailleurs, les OS d'aujourd'hui ne fonctionnent-ils pas comme ça ? 

Ou alors j'ai mal compris. Tu voulais dire que le ST est un meilleur gestionnaire de fichier que le mig grace à son GEM en rom ? 
Tu as raison : j'admet que quelqu'un qui voulait un ordinateur et s'en servir juste pour regarder le contenu de disquettes ou de répertoires devait prendre un ST. 

Maintenant à mon tour de poser des questions. 

Tu as posé une question sur le démarrage au boot d'un programme. Ton arrière pensée était "avec un ST tu le fais en mettant ton programme dans le dossier "AUTO". 
J'ai 2 questions sur les autoboot : 
Avec un ST tu faisais comment pour faire démarrer au boot un logiciel qui tournait en haute résolution (sans patch ni outil supplémentaire)? 
Tu pouvais pas ? Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 

Avec un ST tu faisais comment pour faire démarrer au boot un logiciel GEM (c'est à dire qui utilisait la souris, les fenêtre, les icones, du classique quoi ) ? 
Tu pouvais pas ? Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 

Avec un ST, tu faisais comment pour renommer un répertoire ? 
Ah tu pouvais pas ? Obligé de passer par un programme... Ah mais non ! je suis bête ! C'est pas seulement le GEM qui n'offrait pas cette fonction, c'est carrément le TOS ! Donc tu ne pouvais même pas le faire par programmation ! LOL ! 
Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 

Avec un ST, tu faisais comment pour avoir plus de 40 répertoires ? 
Ah tu pouvais pas... Bon c'est pas si grave : plus de 40 répertoires sur une disquette, c'était pas courant... 
Ah mais ça concerne aussi les HD ? Aie ! 40 repertoires max (en comptant tous les sous-répertoire et toutes les partitions) sur un HD, là par contre ça craint... 
Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 

Avec un ST tu faisais comment pour que la position, la taille, les paramètres d'une fenêtre (d'une disquette ou d'un répertoire) soient mémorisés ? 
Tu pouvais pas ? Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 

Avec un ST tu faisais comment pour ouvrir plus de 4 fenêtres ? 
Tu pouvais pas ? Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 

Avec un ST tu faisais comment pour déplacer (et non copier) un fichier plus grand que la taille disponible sur ta disquette (donc pas moyen de copier et supprimer la source) ? 
Tu pouvais pas ? Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 

Avec un ST tu faisais comment pour faire une sauvegarde incrémentale avec ton HD vu que l'attribut d'archivage était buggé et ne se posait pas ? 
Tu pouvais pas ? Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 

Avec un ST tu faisais comment pour copier tous les fichiers qui correspondaient à des critère particuliers et qui se trouvaient dans différents endroits ? 
Par exemple, copier sur une disquette 30 fichier IFF disséminés dans 5 répertoires et mélangés avec d'autres fichiers. 
Et tout ça en une seule manip, pas 30... 
Tu pouvais pas ? Mais je croyais que le couple GEM/TOS était parfait dès le départ ? 


Je pourrai continuer longtemps comme ça : au jeu des manques ou de la convivialité, le ST n'est absolument pas devant le mig, contrairement à ce qu'affirment beaucoup de Stistes ici. 
Et vu que tu prétends que le WB n'était pas terminé, je peux en conclure la même chose. Certaines des choses que je viens de citer ont été réglés après l'arrivée du 2.0. Et y en a qui posaient des problèmes autres que la convivialité...

Note que je me suis restreint au domaine que tu abordais : la manipulation de fichiers...

Ah non, tu as parlé des librairies aussi. Alors j'explique l'interet :

Dans l'amigaos tu as accès à tout un tas de librairies qui sont en rom ou pas.
Par exemple, il y a une librairie mathématique qui te donne accès à des fonctions trigonometriques. 
Si tu utilises un logiciel pour de rendering 3D, le programme utilisera abondamment cette libriarie (s'il a été correctement écrit). Maintenant imaginons que tu achete une carte avec un 68020+copro arithmétique, tu aimerais bien que ce programme (et d'autres) utilisent le copro de ta carte, non ?
Et bien il suffira de dire à l'OS que tu souhaite utiliser une autre librairie et de lui fournir. Et là c'est très compliqué : il faut copier un fichier dans le répertoire libs. Et même plusieurs puisqu'il y a surement plusieurs librairie que tu pourrais rendre plus performantes. Bien sur, les cartes accélératrices étaient livrés avec des logiciels d'install qui faisaient tout ça. ça permettait, si tu faisais ça sur ta disquette WB ou ton HD de rendre immédiatement pleins de programmes beaucoup plus rapides que s'ils s'étaient contenté de ne profiter que de l'accélération apportée par le 68020 (on est dans des facteurs de vitesse qui se mesurent en dizaines/centaines).
Ce système est tellement souple qu'il permettrait à des logiciels écrits pour le 68000 de profiter de la puissance du powerpc quand les cartes qui en étaient équipées sortiront...

Et pourtant, l'utilisateur lambda ne savait pas qu'il y avait un répertoire libs...
ça vaut pas le coup, en échange de ce que ça apporte, de jouer les "alchimistes" ?

Moi, la convivialité, je dirai que c'est très subjectif. Et je noterai que tous les OS moderne utilisent une ergonomie plus proche de celle du mig que du ST : noms long, icones personnalisés, sauvegarde des paramètres d'affichage des dossiers, jauge indiquant l'espace restant (ah tiens ! encore un truc bien pratique qui n'existait pas sur ST), etc... 

J'explique pour ceux qui ont du mal à comprendre et que ça interesse sincèrement. 

L'OS du mig est en ROM (tu as raison Ryosaeba : ça pose les même problèmes de mise à jour qu'avec le TOS du ST). 
Mais l'OS ne contient pas le bureau. C'est la différence avec celui du ST. Mais tout le reste y est (y compris l'interface graphique). 
Et l'amigaos propose une API bien plus complète que celle du TOS/GEM. Elle est non seulement plus optimisé (les fonctions de l'OS n'ont pas besoin de manipuler la pile autant que sur ST...) mais elle prend plus de place. 
Un ST c'est 192 Ko pour l'OS et le bureau. 
Un mig c'est 256 Ko pour l'OS seul. 

Un bureau, pour être le plus convivial, doit être personnalisable. Et je ne parle pas que de cosmétique, je parle de personnalisation qui permet d'améliorer la productivité. 
Un exemple simple : sur le WB, tu peux personnaliser la surface d'affichage pour qu'elle occupe le maximum visible sur un moniteur. Faire ce réglage à chaque allumage de l'ordinateur n'aurait pas de sens. Il faut donc que ce soit mémorisé, sinon personne ne l'utiliserait. Attention ! je ne parle pas d'étirer la zone comme on pouvait le faire sur certains moniteurs (ceux qui le faisaient étaient rares). je parle d'augementer le nombre de pixels : plus on en a mieux c'est. Grace à ça, en moyenne résolution, le mig avait un bureau de 680-700 pixels par 260/280 lignes. (et une application qui ouvrait ses propres écrans pouvait reprendre les réglages du WB...) Le ST restait cantonné à du 640 x 200. Et tout ça dans une fenêtre ridiculement petite. 
Grace à ce système, sur un Amiga, pour avoir un bureau de 14 pouces, il fallait un écran de 15 pouces. Sur un ST, il fallait un écran de 18/19 pouces ! Et tout ça avec moins de pixels, moins de couleurs, et un pointeur qui ne pouvait pas avoir sa palette spécifique. Ce qui n'est pas très convivial quand on dispose de 4 couleurs en tout... 
Donc quand tu as un bureau hautement configurable et personnalisable, il est logique de le mettre sur disquette puisqu'il faudra de toute façon charger pleins de choses avant de l'ouvrir. 


Maintenant tous les outils que tu avais sur le WB tu pouvais les avoir aussi sur le GEM ? Tu es loin du compte...
Une chose est sure : tu ne connais pas le mig... Ou plutot les outils que tu peux avoir sur le WB. Rien que celui dont je parle juste au-dessus qui te permet d'optimiser la suface d'affichage : ça n'existe pas sur le ST et c'est impossible à faire... 

A propose d'outil, il y en avait un sur ST qui permettait de lancer un programme en moyenne résolution au boot (bon c'est plus un correctif qu'un outil...). 
Il se mettait lui aussi dans le dossier AUTO. 
Voici un extrait de sa doc : 

Although the ST's internal clock keeps time with an accuracy of two seconds, the time-stamping of files is accurate only to within one minute. To be absolutely certain that the AUTO folder will work correctly, you should allow at least two minutes to elapse between the time that you place each file in AUTO. This ensures that the ST will have no difficulty deciding the correct order in which to run the programs. 

Il faut attendre au moins 2 minutes entre chaque copie de fichier ! ça c'est convivial ! LOL !

L'ordre des programmes dépend de la date des fichiers ! Super si tu veux changer cet ordre...
Je préfère 1000 fois une statupsequence.

Et je pourrais te citer des tas de choses que tu faisais facilement avec une startupsequence (et un cli intégré en ROM...) et qui auraient demandé de solides connaissances en programmation pour les faire avec un ST...
avatar
stapha92
Patient contaminé

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

Revenir en haut Aller en bas

amiga - GUERRE ST-AMIGA, FIGHT !!! - Page 34 Empty Re: GUERRE ST-AMIGA, FIGHT !!!

Message par dlfrsilver Lun 7 Sep 2015 - 19:11

Stapha92 vs les fessés du ST : 2 à 0 !
avatar
dlfrsilver
Interne
Interne

Masculin Nombre de messages : 7647
Age : 46
Date d'inscription : 29/05/2009

Revenir en haut Aller en bas

amiga - GUERRE ST-AMIGA, FIGHT !!! - Page 34 Empty Re: GUERRE ST-AMIGA, FIGHT !!!

Message par ryosaeba Lun 7 Sep 2015 - 19:41

dlfrsilver a écrit:Stapha92 vs les fessés du ST : 2 à 0 !
non Ryosaeba 3 - Amigaiste :0 

Sans Stapha vous n'auriez même pas su répondre...... Et je peux continuer comme cela aussi bien en mettant en valeur l'Amiga ou le St ou l'inverse.
ryosaeba
ryosaeba
Infirmier

Masculin Nombre de messages : 4269
Age : 49
Date d'inscription : 02/07/2009

Revenir en haut Aller en bas

amiga - GUERRE ST-AMIGA, FIGHT !!! - Page 34 Empty Re: GUERRE ST-AMIGA, FIGHT !!!

Message par dlfrsilver Lun 7 Sep 2015 - 19:49

ryosaeba a écrit:
dlfrsilver a écrit:Stapha92 vs les fessés du ST : 2 à 0 !
non Ryosaeba 3 - Amigaiste :0 

Sans Stapha vous n'auriez même pas su répondre...... Et je peux continuer comme cela aussi bien en mettant en valeur l'Amiga ou le St ou l'inverse.

Il a démonté tout ce que tu as dis clairement. Même moi tu as biaisé à mort sur mes propres affirmations.

Et pire, j'ai démontré que rien que côté lecteur de disquette l'amiga défonce encore le ST MDR

Donc oui Ryosaeba 0 - dlfrsilver 1 et Ryosaeba 0 - Stapha92 2

MDRRR !!!!
avatar
dlfrsilver
Interne
Interne

Masculin Nombre de messages : 7647
Age : 46
Date d'inscription : 29/05/2009

Revenir en haut Aller en bas

amiga - GUERRE ST-AMIGA, FIGHT !!! - Page 34 Empty Re: GUERRE ST-AMIGA, FIGHT !!!

Message par Invité Lun 7 Sep 2015 - 19:51

si l'AMIGA est une console à disquettes, 
Le ST est un boulier avec une sortie péritel.
MDR
avatar
Invité
Invité


Revenir en haut Aller en bas

amiga - GUERRE ST-AMIGA, FIGHT !!! - Page 34 Empty Re: GUERRE ST-AMIGA, FIGHT !!!

Message par ryosaeba Lun 7 Sep 2015 - 19:52

dlfrsilver a écrit:
ryosaeba a écrit:
dlfrsilver a écrit:Stapha92 vs les fessés du ST : 2 à 0 !
non Ryosaeba 3 - Amigaiste :0 

Sans Stapha vous n'auriez même pas su répondre...... Et je peux continuer comme cela aussi bien en mettant en valeur l'Amiga ou le St ou l'inverse.

Il a démonté tout ce que tu as dis clairement. Même moi tu as biaisé à mort sur mes propres affirmations.

Et pire, j'ai démontré que rien que côté lecteur de disquette l'amiga défonce encore le ST MDR

Donc oui Ryosaeba 0 - dlfrsilver 1 et Ryosaeba 0 - Stapha92 2

MDRRR !!!!
Tu n'as rien compris........ RyoSaeba 5 - dlfrsilver :0 MDR MDR MDR MDR MDR MDR MDR MDR
ryosaeba
ryosaeba
Infirmier

Masculin Nombre de messages : 4269
Age : 49
Date d'inscription : 02/07/2009

Revenir en haut Aller en bas

amiga - GUERRE ST-AMIGA, FIGHT !!! - Page 34 Empty Re: GUERRE ST-AMIGA, FIGHT !!!

Message par dlfrsilver Lun 7 Sep 2015 - 20:02

si si j'ai tout compris Ryosaeba 0 - dlfrsilver 10 MDR MDR MDR MDR

-------

https://www.gamopat-forum.com/viewtopic.forum?t=82337
avatar
dlfrsilver
Interne
Interne

Masculin Nombre de messages : 7647
Age : 46
Date d'inscription : 29/05/2009

Revenir en haut Aller en bas

Page 33 sur 34 Précédent  1 ... 18 ... 32, 33, 34  Suivant

Revenir en haut

- Sujets similaires

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