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 28 sur 34
Page 28 sur 34 • 1 ... 15 ... 27, 28, 29 ... 34
Re: GUERRE ST-AMIGA, FIGHT !!!
alors oui j'ai eu une disquette qui as ete "abimée" en copiant vers le disque dur , mais seulement vers le disque dur , si c'est disquette vers disquette no soucis , et c'est le dma enfin le signal sortant du dma qui foire , mesure as l'oscillo les signaux ne sont pas propre je doit encore tester avec de simple condensateur de filtrage :)
pour amiga 0/10 pour disque dur , rien ne fonctionne sans parlé du ks 3.1 qui ne veut meme pas démmaré sur le 500 en rev 6a ! donc voila 0 partout pour les disque dur
pour amiga 0/10 pour disque dur , rien ne fonctionne sans parlé du ks 3.1 qui ne veut meme pas démmaré sur le 500 en rev 6a ! donc voila 0 partout pour les disque dur
Doctoritchy- Patient contaminé
- Nombre de messages : 308
Date d'inscription : 26/04/2015
Re: GUERRE ST-AMIGA, FIGHT !!!
En presque 10 ans à faire des demos sur ST, je ne me souviens pas avoir eu ce problème et pourtant j'en ai sauvé des fichiers, probablement des milliers de fois.
Pareil pour le son, jamais eu ce problème, et j'ai eu un 6128 et un A500, ce qui me donnait une référence fiable.
Pareil pour le son, jamais eu ce problème, et j'ai eu un 6128 et un A500, ce qui me donnait une référence fiable.
Re: GUERRE ST-AMIGA, FIGHT !!!
Est-ce que Exxos a dit que ça touchait tous les STs ? Il ne me semble pas. Si c'était le cas, il passerait son temps à répondre sur AF ou à réparer tous les ST de la planète, ce qui n'est pas vrai.
Tu fais de ton cas une généralité. Encore une fois, j'ai eu plus d'une 30aine de ST : je n'ai jamais constaté de pb de condo qui a coulé, contrairement à toi. Un gros coup de chance ? Possible, mais je ne crois pas... Et je n'ai jamais dit que mes ST m'avaient "mis une bombe" comme tu dis, relis mon message plus haut.
L'article que tu nous as sorti de ST Mag montre clairement qu'ils ont eu une version bêta entre les mains. Il y a beaucoup de choses à redire sur cet article, beaucoup de parti-pris injustifié. Au passage, je ne comprend vraiment pas ce qu'ils reprochent au modèle de RAM, qui était l'une des meilleurs avancées du STE par rapport au STE, mais ça c'est une autre histoire.
Enfin, contrairement à toi, Pasti ne m'a jamais joué de vilain tour, même avec le mauvais chipset DMA.
Est-ce que tu avais bien nettoyé les têtes de ton lecteur avant l'archivage ? Je m'explique : avec le KF et même le SPC, j'ai eu deux originaux flingués. Dans le deux cas, la tête de lecture était sale et ça a endommagé au moins un track complet. Ça se voit clairement à la lumière. c'était il y a deux ans, quand j'ai commencé à dumper. Depuis, je nettoie systématiquement la tête - et comme l'a conseillé Jim Drew il y a quelques mois, il faut le faire à chaque dump.
Ça serait peut-être une piste à explorer, non ? Sinon comment expliques-tu que je n'ai jamais eu le souci avec plusieurs centaines de STX créés sur un STE équipé d'un mauvais DMA, et ce, même avec un UltraSatan (je n'ai pas changé de STE tout de suite quand j'ai eu mon UltraSatan) ?
Tu fais de ton cas une généralité. Encore une fois, j'ai eu plus d'une 30aine de ST : je n'ai jamais constaté de pb de condo qui a coulé, contrairement à toi. Un gros coup de chance ? Possible, mais je ne crois pas... Et je n'ai jamais dit que mes ST m'avaient "mis une bombe" comme tu dis, relis mon message plus haut.
L'article que tu nous as sorti de ST Mag montre clairement qu'ils ont eu une version bêta entre les mains. Il y a beaucoup de choses à redire sur cet article, beaucoup de parti-pris injustifié. Au passage, je ne comprend vraiment pas ce qu'ils reprochent au modèle de RAM, qui était l'une des meilleurs avancées du STE par rapport au STE, mais ça c'est une autre histoire.
Enfin, contrairement à toi, Pasti ne m'a jamais joué de vilain tour, même avec le mauvais chipset DMA.
Est-ce que tu avais bien nettoyé les têtes de ton lecteur avant l'archivage ? Je m'explique : avec le KF et même le SPC, j'ai eu deux originaux flingués. Dans le deux cas, la tête de lecture était sale et ça a endommagé au moins un track complet. Ça se voit clairement à la lumière. c'était il y a deux ans, quand j'ai commencé à dumper. Depuis, je nettoie systématiquement la tête - et comme l'a conseillé Jim Drew il y a quelques mois, il faut le faire à chaque dump.
Ça serait peut-être une piste à explorer, non ? Sinon comment expliques-tu que je n'ai jamais eu le souci avec plusieurs centaines de STX créés sur un STE équipé d'un mauvais DMA, et ce, même avec un UltraSatan (je n'ai pas changé de STE tout de suite quand j'ai eu mon UltraSatan) ?
Brume- Patient contaminé
- Nombre de messages : 739
Age : 51
Localisation : Paris
Date d'inscription : 28/05/2013
Re: GUERRE ST-AMIGA, FIGHT !!!
Doctoritchy a écrit:alors oui j'ai eu une disquette qui as ete "abimée" en copiant vers le disque dur , mais seulement vers le disque dur , si c'est disquette vers disquette no soucis , et c'est le dma enfin le signal sortant du dma qui foire , mesure as l'oscillo les signaux ne sont pas propre je doit encore tester avec de simple condensateur de filtrage :)
pour amiga 0/10 pour disque dur , rien ne fonctionne sans parlé du ks 3.1 qui ne veut meme pas démmaré sur le 500 en rev 6a ! donc voila 0 partout pour les disque dur
Oui voilà, mes ST/E tant qu'on reste sur des opérations sur disquettes, aucun problème. Les soucis c'est uniquement de lecteur de disquette à disque dur.
Ouais tu vois, si les signaux sont pas propres, c'est entre autre lié au fait qu'Atari, au lieu de mettre ce qu'il fallait pour filtrer justement les signaux, et donc les parasites et le bruit, n'ont rien mis. Voilà pourquoi
Sur l'amiga, il peut y avoir plusieurs problèmes : 1) l'eprom que tu utilises n'est peut-être pas du bon type, soit trop lente, soit trop rapide. La révision n'a pas d'importance à ce sujet, et je n'ai rien lu au sujet d'une incompatibilité quelquonque avec une rev6A et le KS3.1 .
Quel est ta marque d'eprom, et son type et sa vitesse (ou alors est-ce que tu l'as achetée à un vendeur sur internet ?). Les disque durs sur Amiga, c'est un peu compliqué à paramétrer, mais comme y a des tutos bien clairs et bien expliqués, y a rien de sorcier à côté du ST. Et une fois les réglages fais, c'est du papa dans maman.
Je peux te tuyauter si tu as besoin :)
dlfrsilver- Interne
- Nombre de messages : 7782
Age : 47
Date d'inscription : 29/05/2009
Re: GUERRE ST-AMIGA, FIGHT !!!
En fait, d'après les posts d'Exxos, il s'avère qu'il n'y aurait pas qu'un problème de mauvaise puce DMA, mais bien un problème au niveau du hardware, qui comme je le disais un peu plus haut n'est pas documenté.Brume a écrit:Est-ce que Exxos a dit que ça touchait tous les STs ? Il ne me semble pas. Si c'était le cas, il passerait son temps à répondre sur AF ou à réparer tous les ST de la planète, ce qui n'est pas vrai.
Tu fais de ton cas une généralité. Encore une fois, j'ai eu plus d'une 30aine de ST : je n'ai jamais constaté de pb de condo qui a coulé, contrairement à toi. Un gros coup de chance ? Possible, mais je ne crois pas... Et je n'ai jamais dit que mes ST m'avaient "mis une bombe" comme tu dis, relis mon message plus haut.
L'article que tu nous as sorti de ST Mag montre clairement qu'ils ont eu une version bêta entre les mains. Il y a beaucoup de choses à redire sur cet article, beaucoup de parti-pris injustifié. Au passage, je ne comprend vraiment pas ce qu'ils reprochent au modèle de RAM, qui était l'une des meilleurs avancées du STE par rapport au STE, mais ça c'est une autre histoire.
Enfin, contrairement à toi, Pasti ne m'a jamais joué de vilain tour, même avec le mauvais chipset DMA.
Est-ce que tu avais bien nettoyé les têtes de ton lecteur avant l'archivage ? Je m'explique : avec le KF et même le SPC, j'ai eu deux originaux flingués. Dans le deux cas, la tête de lecture était sale et ça a endommagé au moins un track complet. Ça se voit clairement à la lumière. c'était il y a deux ans, quand j'ai commencé à dumper. Depuis, je nettoie systématiquement la tête - et comme l'a conseillé Jim Drew il y a quelques mois, il faut le faire à chaque dump.
Ça serait peut-être une piste à explorer, non ? Sinon comment expliques-tu que je n'ai jamais eu le souci avec plusieurs centaines de STX créés sur un STE équipé d'un mauvais DMA, et ce, même avec un UltraSatan (je n'ai pas changé de STE tout de suite quand j'ai eu mon UltraSatan) ?
On a les choses suivantes :
- des gens qui ont un ST (STFM, STF ou STE) qui ont procédé au remplacement de la puce dite mauvaise, et pour qui ça a fonctionné
- d'autres pour qui ça n'a pas marché, ou alors pour qui ça n'a fait qu'empirer les choses
exemple simple : Exxos a mis au point un patch hardware, qui s'applique sur la puce dite mauvaise. ça a corrigé le problème pour lui. Pour un autre gars, ça a été sans aucun effet, et pour moi pareil. J'ai testé le dit patch à base de condos.
tu vois, le truc c'est que comme Atari a pondu une tétrachiée de révision différentes sur tout les modèles de ST, (STFM, STF, ou encore STE), ça complique les choses, ce qui veut dire que ce qui marche pour Paul, ne marchera pas pour Jack (blague gratuite), ni pour Antoine.
J'ai remplacé la puce dite défectueuse sur mon 1040 STE par la bonne puce DMA, et l'ai mise sur socket. Et le résultat à l'arrivée c'est une catastrophe. Mon 1040 STE n'a carrément pas aimé le changement de la puce, à présent le lecteur de disquette déconne totalement, et Exxos m'a dit "tu n'aurais jamais du changer la puce dite mauvaise par la dite bonne. Ce faisant tu as changé la configuration matérielle de ton STE, et que je te l'ai dis, le remplacement de la puce n'est pas nécessairement la solution au problème."
Ce qui ramène à un problème matériel au niveau de la carte mère. Comme je le disais, je vais devoir lui envoyer ma carte mère pour qu'il checke le tout à l'oscilloscope, et bon courage pour lui, y a pas plus chiant que de débugger du hardware qui déconne..........
dlfrsilver- Interne
- Nombre de messages : 7782
Age : 47
Date d'inscription : 29/05/2009
Re: GUERRE ST-AMIGA, FIGHT !!!
bref, y'a que toi, qui a 100% de tes 10 ST ( dont j'attends toujours la photo ) qui ont des problèmes ! c'est quand même étrange non ? ( en fait, personne ici ne te croit, je sais pas si tu l'as remarqué ).
moi mon ST fonctionnait 24h/24h, avec des millions d'écritures sur le HD ( cartouche Syquest amovible, donc pas ce qui était de plus fiable ), et malgré tout cela, je n'ai jamais perdu une seule donnée...
moi mon ST fonctionnait 24h/24h, avec des millions d'écritures sur le HD ( cartouche Syquest amovible, donc pas ce qui était de plus fiable ), et malgré tout cela, je n'ai jamais perdu une seule donnée...
rocky007- Interne
- Nombre de messages : 9152
Age : 50
Date d'inscription : 29/01/2011
Re: GUERRE ST-AMIGA, FIGHT !!!
Que toi tout seul Rocky ne me croit pas, ça me dérange absolument pas une fois, tu n'es pas paroles d'évangile, mais juste une de Belgique !
C'est pas toi qui a tout mes emmerdes. Tout allait bien avec mes ST/E tant que j'utilisais des jeux sur disquettes. Du jour ou j'ai acheté un disque dur SH305, ça a commencé. J'ai acheté un ultrasatan, car je voulais installer mes jeux sur disque dur, et jouer à mes jeux préférés sur ST sans sortir les disquettes. Depuis c'est un cauchemar.
C'est pas toi qui a tout mes emmerdes. Tout allait bien avec mes ST/E tant que j'utilisais des jeux sur disquettes. Du jour ou j'ai acheté un disque dur SH305, ça a commencé. J'ai acheté un ultrasatan, car je voulais installer mes jeux sur disque dur, et jouer à mes jeux préférés sur ST sans sortir les disquettes. Depuis c'est un cauchemar.
dlfrsilver- Interne
- Nombre de messages : 7782
Age : 47
Date d'inscription : 29/05/2009
Re: GUERRE ST-AMIGA, FIGHT !!!
tu es déjà super lourd, mais en plus tu vas commencer avec des blagues sur les belges ? ça va vraiment pas arranger ton cas
déjà en 2012, tu te plaignais de tes ...2 atari... cela veut dire qu'en 3 ans tu as acheté 8 ST et qu'ils sont tous, comme par hasard défectueux ? la photo elle arrive ?
http://www.atari-forum.com/viewtopic.php?t=23228&start=25
déjà en 2012, tu te plaignais de tes ...2 atari... cela veut dire qu'en 3 ans tu as acheté 8 ST et qu'ils sont tous, comme par hasard défectueux ? la photo elle arrive ?
http://www.atari-forum.com/viewtopic.php?t=23228&start=25
rocky007- Interne
- Nombre de messages : 9152
Age : 50
Date d'inscription : 29/01/2011
Re: GUERRE ST-AMIGA, FIGHT !!!
C'est pas parce que j'ai des origines belges que ça t'autorise à me traiter de (super) lourd !rocky007 a écrit:tu es déjà super lourd, mais en plus tu vas commencer avec des blagues sur les belges ? ça va vraiment pas arranger ton cas
déjà en 2012, tu te plaignais de tes ...2 atari... cela veut dire qu'en 3 ans tu as acheté 8 ST et qu'ils sont tous, comme par hasard défectueux ? la photo elle arrive ?
http://www.atari-forum.com/viewtopic.php?t=23228&start=25
Aucun respect ces belges franchement !
Oui tu vois déjà en 2012 j'avais des problèmes avec mon 1040 STF et mon 1040 STE, et oui j'ai acheté d'autres atari en espérant tomber sur un modèle qui fonctionne enfin avec un disque dur, peine perdue !
Et la photo on verra si tu es mignon ! Si tu es sage et que tu arrêtes ton sketch, mmhh ouais ça pourrait se faire.
dlfrsilver- Interne
- Nombre de messages : 7782
Age : 47
Date d'inscription : 29/05/2009
Re: GUERRE ST-AMIGA, FIGHT !!!
ça va, te casses pas la tête avec ton photoshop et profites du soleil
rocky007- Interne
- Nombre de messages : 9152
Age : 50
Date d'inscription : 29/01/2011
Re: GUERRE ST-AMIGA, FIGHT !!!
Un TT maintenant ? Quand bien même, tu pourrais pas.rocky007c'est simple, offre moi un Atari TT, un HD SCSI et je te montre tout celastapha92 a écrit:C'est toi qui devrait être attentif à tes écritures : Je te rappelle qu'au départ, tu nous as expliqué que tes fameuses vidéos prouvaient que le ST aurait pu faire mieux que le mig à l'époque. Or, il faut 2,5 Mo/s et on en est loin, même avec un ultrasan... Il faut une interface spéciale (qui aurait coûté une fortune à l'époque...) et il faut trafiquer le ST et meme l'adressage du 68000. C'est dire le niveau des modifs...
On va faire plus simple : montre nous une de ces vidéos sur un vrai ST dans les conditions de l'époque...
Encore plus simple : bien que ça ne montrerait pas que le ST aurait pu concurrencer le mig en vidéo, montre nous une des ces vidéo sur un vrai ST.
Oui c'est sur : Je parlais de la compatibilité des applis et tu sors WHDLoad...rocky007La compatibilité était infiniment meilleure sur le mig sur sur le ST. Avec votre TOS non compatible 32 bits, c'est normal... Et en plus il n'était pas rétro-compatible. Sur le mig, tu peux mettre mettre un os 3.1 sur une machine équipée du 1.2 par exemple. Tu peux mettre un TOS 2.0 sur un STF ? ben non, tu ne peux même pas mettre un TOS 1.6 (tu sais celui qui a besoin de STE_FIX.PRG pour corriger des bug...).
l'utilisation même de whdloader démontre parfaitement le bordel nécessaire à faire fonctionner tous les jeux, ils faut jongler avec les différents kickstarter, wb, etc..appliquer des patchs à tout va, oui, magnifique compatibilité. je vois pas pourquoi Atari se serait casser la tête à faire un TOS 1.0 compatible 32 bits en 1985, à part dépenser plus en équipe de dev.
Et les jeux patchés, tu penses que c'est que pour la compatibilité ? Et le fonctionnement depuis un HD ? Et les protections ?
Et un os 32 bits permet d''améliorer la compatibilité ascendante justement.
Elle permet aussi de mettre des cartes 68020 ou plus. Pas inutile pour les pros...
Et elle permet aujourd'hui de mettre une carte à 100 € (vampire) dans un A500/A600 et d'avoir 64 Mo et un cpu plus rapide qu'un 68060...
C'est pas l'allocation qui pose problème, c'est la lecture ou l'ecriture à une adresse mémoire qui peut poser plus de problème s'il y a un bug et que l'adresse en question n'est pas réservée. Mais reprend mon explication sur les chances qu'a un ST de faire ce genre de choses : pas beaucoup moins qu'un amiga...rocky007
La ram qui empiétait ? Tu sors ça d'ou ? C'est plutôt le TOS qui a des problèmes de RAM : la gestion de la mémoire est beaucoup plus basique et c'est en accord avec l'architecture bidon du ST qui ne peut pas être accéléré de façon efficace sans utiliser de hack.
tu le sais très bien que dans un environement multitâche, l'allocation de la mémoire est essentiele et pose plus de problèmes que dans un environement monotâche. Evidement, si les programmes qui fonctionnent sont parfaitement écrit cela ne pose aucun problème, mais c'est rarement le cas.
D'autant que le ST a des adresses mémoires illicites en mode user.
Et de quelle façon peut-on détecter facilement les accès illégaux d'une appli pendant le debugging ? Avec une mmu. donc avec une carte accélératrice. Disponible sur le mig et pas sur le ST...
Et j'ai donné un exemple de ram qui empietait et faisait tout planter et ça se trouve dans le TOS...
Et tu sais très bien aussi que, dans un env multitache coopératif, lorsqu'une tache plante, tout est bloqué. Avec du préemptif, le plantage ne bloque pas tout. Donc quand un accessoire plante sur ST, ça avait plus d'impact qu'avec une commoditie sur le mig...
Connecter un sampler (qui valait plus cher qu'un ST...)sur le ST et le piloter par midi ? Ben c'est à la portée du premier 8 bits venu... Donc oui le ST "aurait pu" faire ça...rocky007Oui oui c'est ça : le St est multimédia... Avec un son 8 bits, une image qui ne peut remplir l'écran (sans trick hyper couteux en ressources et inutilisables dans une application) et des animations saccadés. Un ordinateur est multimedia si il possède des applications pour faire du multimédia. Y a quoi sur le ST ?
C'est vrai, le mig ne peut pas jouer une vidéo en 50 i/s en qualité vidéo. Mais il en est beaucoup plus proche que le ST. Les vidéos qui ont déjà été postées ici atteignent la qualité VHS, qui nous suffisaient bien à l'époque. Et elles tournent sur des vrais mig non "hackés". Pas sur un émulateur..
tout comme il faut être réaliste, 90% de l'utilisation "multimedia" de l'amiga était : faire les sous titres du club dorothée, et afficher des images précalculées. rien n'empéchait un studio TV de connecter un synthé ou sampler sur le ST midi mixer ainsi des sons qualité studio. alors oui, si tu veux, je veux bien dire que l'Amiga pouvait du multimédia "un peu plus joli" que l'Atari.
Sur le mig, tu pouvais connecter des cartes audio 16 bits multi-canaux et pilotées via AHI (rien de tel dans votre TOS ? Ah ben non...), ce qui les rendaient compatibles avec pleins d'applications : ça permettait de faire bien plus qu'un sampler/midi...
Et y a pas que le club dorothée : ça allait de motus à hugo en passant par pleins de pubs, les méteos (la première météo avec des icones animées était sur le mig, qui, avec toutes les extensions, coutait pourtant moins cher que les anciennes solutions). Et jamais entendu parler de Seaquest DSV ou Babylon 5 ? C'est pas vraiment le club Dorothée...
On trouve même une presentation faite sur le mig sur le CD de Win95. Si ça montre pas que le mig était le roi dans ce domaine...
Pas "un peu plus joli" mais beaucoup plus joli je dirais...
Et mieux animé.
Et mieux sonorisé.
Et sur tout l'écran.
Et sans scanline si besoin.
Comment ? Ok.rocky007. Tu attends quoi ? Je t'ai dit qu'il y avait des jeux avec un scrolling en HAM ? Tu n'arretes pas de dévier parce que tu ne peux pas continuer avec tes arguments. Au départ tu expliquais que le HAM ne pouvait servir qu'à des images statiques. Je t'ai montré un voxel en HAM et tu as rétorqué que les pixels etaient énormes. Superbe argument quand on sait qu'ils ont la meme taille sur les voxels en 16 couleurs des démos ST. Dans la discussion je t'ai dit qu'un scrolling en HAM était possible. Pas qu'il y avait des jeux en HAM avec un scrolling : dans un jeu c'est une autre paire de manches...
prenons alors un simple exemple, expliques-moi comment tu fais un scrolling horizontal HAM d'une jolie photo d'une demoiselle , en temps réel. tu vas encore me dire que c'est possible...mais tu oublieras de dire que ce sera moche... ne detournes donc pas le sens initial de mon affirmation.
Je met deux sprites noir sur les cotés de l'écran (par dessus le playfield). Pour faire scroller l'écran je le déplace d'un pixel à chaque fois. Si j'agrandi la zone affichée en meme temps que le déplacement, plus besoin du sprite de droite.
Quand je l'ai déplacé de 16 pixels, je change l'adresse de l'écran pour que son contenu se déplace de 16 pixel et je le repositionne à sa position de départ. Et ainsi de suite.
Il y aura des fringes seulement au déplacement de contenu. Donc tous les 16 pixels. Donc j'ai 16 frames pour préparer une copperlist qui redéfini la palette pour chaque ligne. Le 68000 doit donc préparer 12,5 lignes par frame (en 320x200) dans la copperlist. C'est largement jouable...,
Je change la copperlist quand je change de contenu.
Y a beaucoup de contraintes, je te l'accorde. Mais c'est possible. Et c'est tout ce que j'ai prétendu à la base.
Edit : Regarde cette vidéo :
Sur le haut, tu as un scrolling. Il y a des fringes au début. Si tu cachais ce début avec un sprite après avoir agrandi et déplacé l'ecran, l'affichage serait parfait.
Le scrolling ne se fait que sur une petite portion. Mais si on enlève tout ce que fait ce screen, il y a moyen de scroller une image fixe tu ne crois pas ?
Et tu es bien placé pour dire de ne pas détourner le sens initial : à la base tu as expliqué que le HAM, ce n'était que des images fixes et scintillantes...
Tu m'as mal compris. Je vais le dire autrement :rocky007Marrante la façon dont tu affirmes que le ST "aurait" pu utiliser ses tricks dans des jeux et pas le mig alors que c'est exactement le contraire...
ben tu viens juste d'affirmer le contraire : des jeux ST exploitant des tricks de megademo.
- Il est ou le jeu avec un scrolling horizontal au pixel à 50 i/s ? C'est courant dans les démo ST, n'est-ce pas ? Alors il est ou le jeu qui fait ça sur ST ? Pourtant, ça change tout : essaie sur le mig. Y en a pleins...
Et les parallaxes ? Et les multi-layer ? Y a des démos qui font ça à 50 i/s non ? Ils sont ou les jeux qui exploitent ces tricks ?
A l'inverse, je te le répète : BTL et M. Nutz exploitent des trick pour faire des effets JAMAIS vus dans une démo.
Tu avais affirmé que tu le ferais. Moi je ne t'ai jamais dit que je pouvais te montrer un scroll en HAM. J'ai juste dit que c'était possible.rocky007Puisque tu joues du "j'attend toujours", je te rappelle que tu avais affirmé pouvoir reproduire les rotations the BTL sur un ST avec 1 Mo pour prouver que c'était possible en précalc (alors que dans le cas de BTL, c'est le jeu qui tient en 1Mo). J'attends toujours...
je n'ai pas besoin de te prouver cela, tu sais qu'afficher des images precalcs sur un ST est possible non ? si, si, c'est possible. et si tu veux, je te le fais si me montre un scrolling horizontal d'une image HAM 4096 couleurs
Bien sur qu'afficher des images précalc est possible.
Et c'est vrai que tu n'en as pas besoin. Ce dont tu as besoin, c'est d'une calculette :
Le rotozoom de l'intro de BTL dure plus de 10 secondes sans jamais afficher 2 fois la meme image (Et je ne prend que la partie rotation plein écran). Il est en 50 i/s dans une résolution de 320x200x16 couleurs (et en 1x1 bien sur).
Un écran fait 32 Ko : 32 Ko x 10 secondes x 50 images = 16 Mo.
Bonne chance pour le précalc...
Et il y a pire : si tu relis mes explications sur le fonctionnement de cette rotation et que tu regardes bien les plate-formes de BTL qui pivotent, tu remarqueras quelque chose qui prouve que c'est pas du précalc. Tu ne vois pas ? Ben faut prendre la peine de mieux étudier les choses avant de faire des affirmations dessus.
Je ne demandais pas de l'aide mais un avis. Pourquoi tu parles d'assistanat ? (joli et adapté comme terme...)rocky007A noter : j'ai proposé une méthode pour faire un scrolling vertical au pixel sur ce forum et j'avais posé une question. Aucun STiste ne m'a répondu : Quand c'est pour affirmer des betises il y a du monde. Quand ça devient sérieux, il n'y a plus personne...
pourquoi ne mets tu pas ta théorie en pratique au lieu de demander de l'assitanat ? c'est trop difficile de passer 10 minute sur ton devpac ?
Et si je code quelque chose en 68000 ça sera sur le mig...
Choix personnel, c'est pas une critique : Certains préfèrent coder sur le ST, d'autres sur le mig.
Ok.rocky007Et le plus drole : SOTB sur ST était une vrai bouse. Il a pourtant été en tete des ventes pendant lontemps... LOL !
honnêtement je trouve qu'il s'en sont pas si mal sorti pour du ST.
Inutile d'etre moqueur avec ton "zoli dégradé"...rocky007Et pourquoi refaire la copperlist à chaque frame ? Tu crois qu'elle s'efface ? Il suffit de modifier ce qui doit l'être, c'est tout.
ah bon ? si tu as un jeu qui modifie dynamiquement l'image en copper, tu ne la recharge pas entierement peut-être ? mais la encore, on parlait des contrainte des vidéos avec changemement des couleurs en temps réel par le copper, pas d'un zoli dégradé dans le ciel de SOTB.
Je sais de quoi on parlait. Et c'est pourquoi j'ai dit :
la copperlist peut être modifiée avec le blitter. Très utile si on a une grosse copperlist pour faire des changement de couleurs partout par exemple.
Lis mieux la prochaine fois.
Mais arretons là : Tu penses qu'une interruption HBL (que le mig possède aussi...) c'est aussi bien qu'un copper. Ok...
Ah bon ? Ne t'ai-je pas donné raison sur Ambermoon ? En disant que le nom de l'exe était révélateur à lui seul ? N'ai-je pas également expliqué que tu avais raison en disant que le 1x1 au copper était impossible ?rocky007Je vais t'aider : tu es au courant que le copper peut faire des move dans n'importe quel registre du chipset. Tu ne t'es jamais demandé ce qui ce passerait s'il faisait un move dans le registre qui contient l'adresse de la prochaine instruction à exécuter (son PC) ? Ben ça fait un branchement ! Et grace à l'utilisation de SKIP, ce branchement peut être conditionné...
merci, mais là encore tu isoles du contexte qui était : faire une routine de 3D mappée avec le 3 instructions du copper. alors oui bien sûr tu peux faire un branchement de cette façon, mais c'est de la "bidouille", tu ne codes pas la copper comme un 68000 ( ce qui était mon propos )... mais bien sûr, c'est plus facile que de critiquer cette absurdité et l'expliquer comme si bien tu sais le faire.
Tu as raison dans ton propos : on ne fait pas de la 3D mappée avec le copper.
Tu as vu que cette fois encore que je TE DONNAIS RAISON ?
Tu as aussi dit que le copper ne pouvait pas faire de branchement : c'est faux et c'est pas une bidouille. Y a plusieurs 'PC' pour le copper dans les registres pour cette raison. Celui dont je te parle n'a aucune autre utilité. Et compare la vitesse de ce branchement avec celle du 68000, tu seras étonné...
Tu as aussi dit que le copper n'était pas utilisé pour les effets de BTL : c'est faux.
J'ai dit quand tu avais raison et quand tu avais tort. La différence, c'est que quand je t'ai donné raison, personne n'ait venu me contredire. Donc pas besoin d'insister...
- On parle du STrocky007Tu ne vois pas quel effet aurait été impossible à faire ? Je vais te donner quelques exemples :
- N'importe quel effet en haute résolution 16 couleurs.
- N'importe quel effet en oversan.
- N'importe quel effet en entrelacé.
- N'importe quel effet qui utilise le blitter (dommage : la plupart le font...)
- N'importe quel effet qui a besoin d'un scrolling (comme un simple générique)
- c'est possible sur un TT
- overscan existe, pourquoi en parles tu ?
- entrelacé ? le truc qui scintille et qui bousille les yeux et qu'aucun moniteur à moins de 10.000 FF ne peut afficher ?
- le ST n'avait pas de blitter, donc forcément
- la aussi les scrolling sont légion...mais peut-être parles tu en 60 FPS ?
- Je parle d'un overscan utilisable. Pas d'un trick qui n'est pas compatible avec tous les shifter, prend plein de ressources, rend impossible les interruptions, fait grésiller les moniteurs...
- 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.
Les pros de l'époque ne travaillaient qu'avec ça. Tout ce que tu regardais à la télé ou en vidéo (meme les DVD, pas juste les cassettes VHS) était comme ça. Aujourd'hui encore, c'est le cas avec les chaines TNT. Et les non HD sont en 576i comme le mig... (Et le "i" veut dire quoi à ton avis ?). Et quand tu était en progressif, ça générait des scanlines : ça a un coté rétro sympa aujourd'hui mais à l'époque, il fallait les éviter. Rien que ça suffit à éliminer le ST...
- On est d'accord. Donc y a pleins d'effet qu'il ne pouvait pas faire...
- ben oui : un générique qui saccade c'est pas terrible... (c'est l'exemple que je donnais pour le scrolling)
Difficile de faire plus bidon comme argument...rocky007Si je suis en train de coder quelque chose et que j'ai besoin d'une calculatrice sur ST, je fais comment si je n'ai pas chargé l'accessoire calculatrice ? Ben je fais pas...
fallait être prévoyant... idem, si sur amiga j'ai besoin d'une calculatrice une fois l'ordinateur démarré, mais que je ne retrouve plus ma disquette ? ben voilà, c'est aussi idiot. quand on bosse, on instaure un environement de travail ( qui ne se pose pas du tout avec un HD )
Moi j'avais tous mes outils sur 3 disquettes étiquetées Outils 1 à 3. Jamais eu de problème pour les retrouver.
Pour avoir la même chose en accessoires chargés dans "l'environnement instauré", il aurait fallu :
- Attendre une plombes que l'équivalent de 3 disquettes compressées soient chargées.
- Avoir 4 Mo de mémoire.
- Que tous ces outils existent sous forme d'accessoires
- Que votre cher TOS ne soit pas limité à 6 accéssoires.
Bonne chance...rocky007quel est l'interet d'un spooler d'impression dans un env monotache ?
tu fais ta capture / bufferisation série sous interruption.... tu vas me dire : oui mais alors ça plante avec les softs qui utilisent les interruptions. hormis spectrum 512 ( et encore, je sais pas si il imprimait ), les softs comme Calamus, etc.. fonctionnait parfaitement avec ce genre de spooler.
Ok : si tu veux croire qu'un spooler dans un env monotache ça a du sens, libre à toi.
J'ai toujours pas vu d'impression non bloquante sur un logiciel de dessin sur ST...
Quand à Spectrum 512, il utilise un kernel (technologie 8 bits...) : déclenche une interruption (si tu y arrives...) et admire ce qui arrive à l'image...
Traites moi de menteur directement pendant que tu y es. Tout le monde a bien vu qui, de nous deux, était régulièrement pris en défaut sur des affirmations fantaisistes. Je te fais une liste ?rocky007Oui c'est sur : super fiable le St et pas fiable le mig. C'est pour ça que le record de l'ordinateur resté allumé le plus longtemps est détenu par un Amiga (utilisé par une chaine hongroise, il est resté allumé 16 ans ! Et il a été éteint volontairement)
ah oui, ça c'est de l'argument béton ! et surement vrai, aucune panne de courant en 16 ans, elle habite dans une centrale nucléaire ta hongroise ?
Quand à la panne de courant : jamais entendu parler des onduleurs ?
Une caméra avec une synchro externe ? jamais vu. ça devait être exotique et ça llimite le choix : pas sur que les pros auraient apprécié de ne pas pouvoir utiliser les modèles les plus réputés...rocky007Je t'ai expliqué comment marche un Genlock mais tu ne comprends pas : il PREND LE CONTROLE DE L'HORLOGE VIDEO de l'ordinateur pour la synchroniser avec celle d'un autre signal vidéo (il ne se locke pas : il locke l'horloge de l'ordinateur)
En fait pas forcément mais, sinon, ça coutera bien plus cher et la qualité sera moins bonne puisqu'il faudra passer par un frame-buffer)
sauf erreur, il te faut seulement un des deux devices à locker, sauf si tu as par exemple une camera avec une connection genlock, la deuxième source n'en aura pas besoin. donc comme je disais, on pouvait très bien faire du montage vidéo avec un ST, même si cela coûte plus cher.
Et le montage, par définition, se faisait avec une bande et pas une caméra. Tu synchronisais en ralentissant la bande à la main ? LOL !
Et ta caméra qui, comme toutes les autres, travaillait en entrelacé devait avoir quelques difficulté pour se synchroniser sur un signal progressif...
Tu te raccroche aux branches (tu disais d'ailleurs que le ST pouvait faire AUSSI BIEN que le mig) mais tu aurais mieux fait d'abandonner.
Mais arretons de débattre et montres nous ça...
Et montre le nous en haute résolution overscan bien sur : du titrage dans une fenêtre (surtout que celle du ST est vraiment toute petite...) ou avec des gros pixels c'est pas sérieux...
Pourquoi sur parole ?rocky007Si je n'ai pas été clair dans l'explication (aussi bien pour le ST que le mig), n'hésites pas (toi ou d'autres) à demander.
belle démonstration, rien à redire pour une fois, même si je dois te croire 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 ?
Tu as raison : le 2x2 prend plus de temps que le 1x1 (surtout sur ST,moins sur STE. Mais c'est une vidéo STE que tu nous as montré). Mais ambermoon ne fait pas 1/4 d'écran. Et Wolfeinstein n'est pas en plein écran. La fenêtre d'Ambermoon fait pas loin de la moitié de celle de Wolfeinstein. Donc au final, de dernier affiche beaucoup moins de pixels. Et il lui faut 2 Mo pour tourner avec beaucoup moins de choses à gérer.rocky007Par contre, Ambermoon doit abondamment utiliser le blitter
oui en effet, changer les paramètres du blitter dans WinUAE change le jeu du tout au tout.
par contre je ne suis pas d'accord avec toi, afficher plein écran 2x2 n'est pas le même qu'un quart écran 1x1. de plus je n'ai jamais affirmé que le ST pouvait faire identique, mais il aurait pu faire, et tu dois l'admettre, un résultat très proche.
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.
Je peux te refaire une comparaison entre la meilleure C2P pour du raycasting sur mig et sur ST et tu verras lequel va le plus vite (tout en utilisant moins de RAM).
Tout ce que tu dis est logique. Mais tu te trompes (en partie seulement) car tu ne connais pas assez le fonctionnement d'un ST.rocky007Vroom n'est pas plus rapide sur le ST. Pourtant les routines d'affichages sont les même et n'exploitent absolument pas le chipset du mig.
tu le dis toi même : il n'utilise aucun chipset du mig, donc le jeu est 100% CPU. Le cpu du ST étant plus rapide, le jeu est plus rapide, et ce n'est pas la malheureuse routine son basse def qui va bouffer les 8% de cycle bonus du ST. j'ai poster les vidéos des 2 versions de Vroom ici même, on voit clairement une légère différence de vitesse à l'avantage du ST. mais cela est comme dis ridicule, puisque s'il avait été codé specifiquement pour l'amiga, ( ne fut-ce que les sprites ) , il aurait pris l'avantage.
Je vais donc d'expliquer :
Pour jouer un Sample sur un ST, il faut utiliser une interruption. Disons que l'on reproduise un sample à 5 Khz. Il faudra que cette interruption soit exécutée 5 000 fois par seconde. Calculons :
Pour déclencher une interruption sur le 68000, il faut 44 cycles.
Pour rendre la main, il faut 20 cycles.
Si le code utilise 3 registres (je pense que c'est un minimum), il faudra les sauvegarder au début du traitement de l'interruption: 32 cycles.
Il faudra les restaurer avant de rendre la main : 36 cycles.
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.
Et on se rend compte que "la malheureuse routine son basse def" prendra bien plus que les 850 000 cycles bonus du ST !
Tu peux améliorer un peu la situation en réservant les 3 registres à la routines. Ce qui évitera d'avoir à les sauvegarder/restaurer. Mais ça veut dire que tout le code du jeu disposera de 3 registres en moins. A voir, ça peut être plus ou moins pénalisant selon les cas.
Mais même comme ça, les 850 000 cycles seront dépensés...
Et j'ai pris des samples à 5 Khz : à cause de la variation de tonalité, il en faut bien plus pour avoir un résultat à peu près acceptable...
A noter : A cause de la reproduction du sample, Vroom ne pouvait plus faire de raster sur ce ciel et la route : les 2 interruptions se seraient téléscopés et cela aurait conduit à des problèmes dans le son ou avec les rasters (en fonction de l'interuption qui aurait du attendre). Dommage car cela aurait pu améliorer grandement l'effet de profondeur. Je me demande s'il n'aurait pas été mieux de se contenter d'un son non samplé et d'avoir ces rasters.
Sur le mig évidemment aucun problème : on aurait pu avoir les raster + le son samplé sans utiliser d'interruption...
Quand aux vidéos Youtube : tu parles de celle ou les 2 versions sont visibles sur le même écran ?
Désolé mais la version mig saccade bien plus que dans mon souvenir. Il faut se méfier des émulateurs...
Prend une vidéo faite sur un vrai A500, comme celles-ci :
Ou celle-ci (ce n'est pas vroom mais ça utilise le même moteur) :
Donc tu avais tort : les jeux sans scrolling ne sont pas forcément plus fluide sur ST.rocky007 a écrit:Lotus turbo esprit : plus fluide sur le mig. Et il n'y a pas que la fluidité : les objets sur les cotés et les voitures ne sont pas positionnés au pixel près. Ils se déplacent par a-coups. C'est déjà moche sur les objets mais sur les voitures c'est vraiment ignoble ! Facile à comparer
oui c'est vrai et c'est logique, l'atari n'ayant ni blitter, ni sprite hardware, y'a pas de mystère.
Y a pas que les fenêtres. ça concerne tous les affichages. Meme le pointeur de souris : des centaines de cycles de plus sur ST pour le raffraichir. Et ça 50 fois par seconde minimum.rocky007 a écrit:Le ST plus rapide pour les applis pro ? LOL !
un appli, ce n'est pas seulement déplacer une fenêtre plus vite au blitter, c'est aussi faire du computing, et là tu as beau sortir tes joker, la clock est là pour le ST
Et il y a les appels des fonctions de l'OS : bien plus lents sur le ST.
Et il y a l'architecture du ST : un cmp.l D0,D1 prend 8 cycles contre 6 sur le mig (comparer la valeur de 2 registres, c'est pas une instruction exotique qu'on utilise jamais).
Pour du calcul pur, tu as raison : le ST est plus rapide (surtout qu'on se fout qu'une multiplication prenne 72 cycles contre 70 ou, pire, qu'une division en prenne 160 au lieu de 158).
Mais c'est faux de dire que toutes les applis pro allaient plus vite sur ST (surtout pour les applis bureautiques)
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.
Tu as mal compris. Si l'icone n'a pas été défini, c'est l'icone standard des D7 (et lui aussi on peut le redéfinir) que le wb utilisera.rocky007 a écrit:Tu as tout à fait le droit de trouver le WB moins beau, c'est un critère subjectif. Il faut cependant noter que :
- Le WB est infiniment plus personnalisable que le GEM. Quand on voit les 2 options du GEM qui se battent en duel , ça donne envie de rire ! Les préférences du WB, c'est carrément autre chose.
Il affiche des icones personnalisés.
c'est à dire ? ne pas pouvoir voir le contenu d'un disquette si l'icone n'a pas été définie ? un coup de génie ça !
De plus c'est le nom de la disquette qui sera affichée. Et non pas LECTEUR A.
Quand au plus grand coup de génie, c'est quand même l'impossibilité de renommer un répertoire. Je ne parle pas du fait que cela ne soit pas possible dans le GEM, je parle du fait que le TOS ne pouvait pas le faire, même par programmation !
Oui démarrer le logiciel dont tu as besoin. Après avoir trouvé le bon exe : vu qu'ils ont tous des noms sur 8 caractères et le même icone, pas toujours simple.Rocky007 a écrit:Tout ça pour dire que, avec un peu de personnalisation, même toi tu aurais pu trouver le WB acceptable.
tout ce que tu as expliqué sur le WB n'effleure même pas ma sensibilité, car honnêtement je trouvais cela en 85 totalement superflu. ce qui était pour moi important, c'est d'allumer un ordi, ne pas attendre et jongler avec les 5 disquettes du WB pour avoir mon ordi operationnel, mettre une disquette, utiliser la confort de la souris et des fenetres ( et pas revenir à la préhistoire avec une ligne de commande ), ouvrir le contenu de ma disquette, voir tout ce qu'il s'y trouve et démarre le logiciel dont j'ai besoin.
que l'icone soit en 4096 HAM ou noir&blanc, c'est juste pour se la toucher ce genre de détail.
Et je souviens d'avoir voulu démarrer un logiciel sur ST et avoir eu un message me disant que je n'étais pas avec la bonne résolution ! C'est quoi ce truc ?!!!
Tous n'avaient pas ce défaut mais ça m'est arrivé pas mal de fois sur mon ST, jamais sur le mig...
Et, je te le répète : l'icone n'était pas là que pour faire joli ou pour pour repérer facilement un fichier.
Tu compares une simple commande du WB à des logiciels complet ? La commande pouvait être utilisée dans n'importe quel script (et la synthèse ne bloquait pas la suite du script puisqu'elle pouvait se faire en multitache...), ça pouvait avoir un interet. Quel est celui d'un logiciel ?rocky007 a écrit:Je me souviens de l'un de mes premiers contact avec le WB : j'ai utilisé la commande SAY pour le faire parler un peu. Quand j'ai réalisé que la synthèse vocale etait meilleure que le manoir de mortevielle (je venais du ST) je n'y croyais pas ! Mais bon : ça ne me servait à rien...
oui c'est argument classique du fanboy... mon petit voisin aussi frimait avec son SAM sur C64
c'est la grande époque du "hey , mon ordi parle".... ce que tu oublies de dire, c'est l'Atari avait lui aussi ses logiciels de synthèse vocale, dépassant ceux de l'amiga. ( oui mais on pouvait le porter squr amiga blablabla )... et à ce que je sache, ton SAY amiga ne possédait pas les phonèmes français, alors comment pouvait-il être meilleur ?
Et non, les logiciels du ST n'étaient pas meilleurs que cette simple commande. Tout simplement parce que le ST ne sait pas reproduire un sample avec la même qualité que le mig. Et je passe sur les options de la commande comme les variations de tonalité qui s'appuyaient sur un hardware inexistant sur un ST.
Fais dire "Cheese" à ton ST et écoute le souffle 10 fois plus fort qu'un cheveux sur la langue. Puis essaie sur un mig : tu verras que lui n'a pas besoin de consulter un orthophoniste... LOL !!
C'est vrai que dans ce cas, il te faut 1,5 Mo. C'est exactement ce que j'ai dit. Allez : disons que pour être tranquille, il faut 2 Mo. ça te convient ?rocky007 a écrit:Pas du tout : WHDLoad fonctionne avec 1 Mo. Avec 1,5 on est à l'aise pour les jeux ECS. C'est avec les jeux AGA qu'il en faut plus, parce que ceux-ci en prennent déjà 2. Mais les jeux AGA sur un A600...
oui en config de base... comment tu fais tourner un jeu qui nécessitait 1mo de RAM ?
De toute façon, avec un A600, c'est une carte vampire600 qu'il faut prendre : pour une centaine d'euro, ça ajoute 64 Mo et c'est plus rapide qu'un 68060. Et y a pleins de jeux sur le mig qui tire parti des cartes accélératrices.
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 !rocky007 a écrit:Ah bon ? Le midi est un port série, rien de plus. En quoi la gestion d'un port série est plus précise que la gestion d'un port série ? Et depuis quand le software en rom est un avantage ? La ROM de ton ST est plus rapide que la RAM ? C'est nouveau ça...
parce que sur amiga, la qualité du midi sera donc dépendant de la qualité du hardware ( car non, il suffit pas de brancher le TX sur la pin équivalente midi, et sera aussi dépendant du software. sur St, c'est standard et d'origine, clair et net.
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.
Mon utilisation m'a montré le contraire. Tout comme de nombreux utilisateur ici...rocky007 a écrit:rocky007 a écrit:l'Atari est bien conçu : il est plus stable que l'amiga
Bien sur, tu t'appuies sur quoi pour étayer ça ?
mon utilisation au quotidien des deux machines, tout comme de nombreux utilisateurs ici.
Aucun utilisateur du ST ne venait du mig. A l'inverse, un grand nombre d'utilisateurs du mig étaient passés par le ST. ça les rend plus crédibles pour comparer. Je parle d'utilisation réelle de l'époque. Pas de ceux qui font mumuse avec les 2 aujoud'hui.
C'est le genre d'argument que les STistes sortent quand ils n'ont rien d'autre à dire : ce n'est ni étayé ni vérifiable...
Mais si tu veux parler des erreurs de conception, je peux t'en mettre plusieurs pages. Y a des erreurs qu'on ne trouve pas dans le monde 8 bits...
Je precise alors : indépendamment du framerate, on peut effectivement avoir autant de frames d'animation sur le ST que sur le mig.rocky007 a écrit:Parce que sur le ST, il faut préshiter tous les sprites 16 fois, ça prend beaucoup de place. Sinon on le fait en temps réel : ça prend du temps (surtout pour des sprites qui font plus de 16 pixels de large). C'est possible sur un jeu avec un décor fixe et peu d'ennemis, genre POP mais impossible sinon.
Y a aussi le problème du masque : il faut le stocker également, 25% de place en plus, ou le calculer en faisant un OR entre tous les plans : ça prend du temps également.
Grace à l'utilisation d'un sprite pour le perso principal, le mig n'a besoin ni de préshifter, ni de stocker ou calculer un masque, ni d'appliquer une opération logique...
(Et pour le reste, le blitter peut faire tout ça tout seul)
merci de répeter Xeme fois l'explication que j'ai moi-même donné et précisée. Dflilver prétendait
qu'on ne pouvait animé plus de 15 frames sur ST , ce qui est complétement ridicule dire si on ne contexte pas cette affirmation, raison pour laquelle j'ai précisé, d'indépendament de la mémoire et du framerate, on peut avoir autant de frame d'animation sur un ST que sur amiga.
stapha92- Patient contaminé
- Nombre de messages : 831
Age : 25
Localisation : Région parisienne
Date d'inscription : 16/08/2010
Re: GUERRE ST-AMIGA, FIGHT !!!
Ahahah, encore le mot magique pour les STistes, interruptions lol ..
Je suis entièrement d'accord avec stapha, le 68000 est lent pour les interruptions, C'est un fait, c'est d'ailleurs pour ça que bcp de machines utilisent des procédés pour les éviter(copper(amiga),hscroll(megadrive),etc..) .
Le 68k est un CPU pour serveur et workstation, donc ses 64 cycles de prise/retour d'interruption sont dérisoires sur un OS, mais ça pique quand tu dois faire du 50/60 fps comme l'a montré stapha .
Forcement le ST n'ayant rien pour compenser va forcement dépenser bcp de cycles rien que pour ça .
Je suis entièrement d'accord avec stapha, le 68000 est lent pour les interruptions, C'est un fait, c'est d'ailleurs pour ça que bcp de machines utilisent des procédés pour les éviter(copper(amiga),hscroll(megadrive),etc..) .
Le 68k est un CPU pour serveur et workstation, donc ses 64 cycles de prise/retour d'interruption sont dérisoires sur un OS, mais ça pique quand tu dois faire du 50/60 fps comme l'a montré stapha .
Forcement le ST n'ayant rien pour compenser va forcement dépenser bcp de cycles rien que pour ça .
Dernière édition par TOUKO le Mar 1 Sep 2015 - 18:54, édité 2 fois
Invité- Invité
Re: GUERRE ST-AMIGA, FIGHT !!!
Est-ce que qq1 du forum va :
- Le dimanche 13 septembre 2015 à Beernem en Belgique an Retro Event du Club Amiga Belge ?
ryosaeba- Infirmier
- Nombre de messages : 4269
Age : 50
Date d'inscription : 02/07/2009
Re: GUERRE ST-AMIGA, FIGHT !!!
j'etait pas au courant npour le retro event , si j'ai pas de boulot se jour la je passerais faire un tour :)
bon drlfsilver , non j'ai pas besoin d'aide je me débrouillerais bien , pour le ste oui ça bug et oui c'est le chips réputé pour bugger sur certain ste ( qui as ete corrigé plus tard que as l'époque pouvais etre corrigé par le fournisseur , mais depuis il as fait faillite , non pas qu'il as plongé avec atari , non du tout le proprio est décéder et le fils as fait n'importe quoi et as coulé la boite ... )
pour l'amiga c'est un KS amigakit prévu pour le A500 rev6 , d'apres le vendeur il y as des pont manquant sur ma carte mere et ou résistance manquante ... un oubli surement pour activé la seconde partie de la rom ( de 512ko pour le 3.1 et 256 ko pour le 1.3 et la ron as deux "stack" de 256ko et il manque la pin pour switcher le stack !
soit j'ai pas trop le temps actuellement de planché la dessus je doit préparé un gros concert anniversaire et le patchage audio est assez gros +tout en hf +précalculer le line array + tout le reste as organiser , ect :)
donc semaine prochaine je plancherais la dessus , sur ce je retourne sur mes simulation :)
bon drlfsilver , non j'ai pas besoin d'aide je me débrouillerais bien , pour le ste oui ça bug et oui c'est le chips réputé pour bugger sur certain ste ( qui as ete corrigé plus tard que as l'époque pouvais etre corrigé par le fournisseur , mais depuis il as fait faillite , non pas qu'il as plongé avec atari , non du tout le proprio est décéder et le fils as fait n'importe quoi et as coulé la boite ... )
pour l'amiga c'est un KS amigakit prévu pour le A500 rev6 , d'apres le vendeur il y as des pont manquant sur ma carte mere et ou résistance manquante ... un oubli surement pour activé la seconde partie de la rom ( de 512ko pour le 3.1 et 256 ko pour le 1.3 et la ron as deux "stack" de 256ko et il manque la pin pour switcher le stack !
soit j'ai pas trop le temps actuellement de planché la dessus je doit préparé un gros concert anniversaire et le patchage audio est assez gros +tout en hf +précalculer le line array + tout le reste as organiser , ect :)
donc semaine prochaine je plancherais la dessus , sur ce je retourne sur mes simulation :)
Doctoritchy- Patient contaminé
- Nombre de messages : 308
Age : 45
Localisation : Belgique
Date d'inscription : 26/04/2015
Re: GUERRE ST-AMIGA, FIGHT !!!
- MIse en spoiler, le post était sans doute pas assez long:
- stapha92 a écrit:
Un TT maintenant ? Quand bien même, tu pourrais pas.rocky007
c'est simple, offre moi un Atari TT, un HD SCSI et je te montre tout celastapha92 a écrit:C'est toi qui devrait être attentif à tes écritures : Je te rappelle qu'au départ, tu nous as expliqué que tes fameuses vidéos prouvaient que le ST aurait pu faire mieux que le mig à l'époque. Or, il faut 2,5 Mo/s et on en est loin, même avec un ultrasan... Il faut une interface spéciale (qui aurait coûté une fortune à l'époque...) et il faut trafiquer le ST et meme l'adressage du 68000. C'est dire le niveau des modifs...
On va faire plus simple : montre nous une de ces vidéos sur un vrai ST dans les conditions de l'époque...
Encore plus simple : bien que ça ne montrerait pas que le ST aurait pu concurrencer le mig en vidéo, montre nous une des ces vidéo sur un vrai ST.
Oui c'est sur : Je parlais de la compatibilité des applis et tu sors WHDLoad...rocky007La compatibilité était infiniment meilleure sur le mig sur sur le ST. Avec votre TOS non compatible 32 bits, c'est normal... Et en plus il n'était pas rétro-compatible. Sur le mig, tu peux mettre mettre un os 3.1 sur une machine équipée du 1.2 par exemple. Tu peux mettre un TOS 2.0 sur un STF ? ben non, tu ne peux même pas mettre un TOS 1.6 (tu sais celui qui a besoin de STE_FIX.PRG pour corriger des bug...).
l'utilisation même de whdloader démontre parfaitement le bordel nécessaire à faire fonctionner tous les jeux, ils faut jongler avec les différents kickstarter, wb, etc..appliquer des patchs à tout va, oui, magnifique compatibilité. je vois pas pourquoi Atari se serait casser la tête à faire un TOS 1.0 compatible 32 bits en 1985, à part dépenser plus en équipe de dev.
Et les jeux patchés, tu penses que c'est que pour la compatibilité ? Et le fonctionnement depuis un HD ? Et les protections ?
Et un os 32 bits permet d''améliorer la compatibilité ascendante justement.
Elle permet aussi de mettre des cartes 68020 ou plus. Pas inutile pour les pros...
Et elle permet aujourd'hui de mettre une carte à 100 € (vampire) dans un A500/A600 et d'avoir 64 Mo et un cpu plus rapide qu'un 68060...
C'est pas l'allocation qui pose problème, c'est la lecture ou l'ecriture à une adresse mémoire qui peut poser plus de problème s'il y a un bug et que l'adresse en question n'est pas réservée. Mais reprend mon explication sur les chances qu'a un ST de faire ce genre de choses : pas beaucoup moins qu'un amiga...rocky007
La ram qui empiétait ? Tu sors ça d'ou ? C'est plutôt le TOS qui a des problèmes de RAM : la gestion de la mémoire est beaucoup plus basique et c'est en accord avec l'architecture bidon du ST qui ne peut pas être accéléré de façon efficace sans utiliser de hack.
tu le sais très bien que dans un environement multitâche, l'allocation de la mémoire est essentiele et pose plus de problèmes que dans un environement monotâche. Evidement, si les programmes qui fonctionnent sont parfaitement écrit cela ne pose aucun problème, mais c'est rarement le cas.
D'autant que le ST a des adresses mémoires illicites en mode user.
Et de quelle façon peut-on détecter facilement les accès illégaux d'une appli pendant le debugging ? Avec une mmu. donc avec une carte accélératrice. Disponible sur le mig et pas sur le ST...
Et j'ai donné un exemple de ram qui empietait et faisait tout planter et ça se trouve dans le TOS...
Et tu sais très bien aussi que, dans un env multitache coopératif, lorsqu'une tache plante, tout est bloqué. Avec du préemptif, le plantage ne bloque pas tout. Donc quand un accessoire plante sur ST, ça avait plus d'impact qu'avec une commoditie sur le mig...
Connecter un sampler (qui valait plus cher qu'un ST...)sur le ST et le piloter par midi ? Ben c'est à la portée du premier 8 bits venu... Donc oui le ST "aurait pu" faire ça...rocky007Oui oui c'est ça : le St est multimédia... Avec un son 8 bits, une image qui ne peut remplir l'écran (sans trick hyper couteux en ressources et inutilisables dans une application) et des animations saccadés. Un ordinateur est multimedia si il possède des applications pour faire du multimédia. Y a quoi sur le ST ?
C'est vrai, le mig ne peut pas jouer une vidéo en 50 i/s en qualité vidéo. Mais il en est beaucoup plus proche que le ST. Les vidéos qui ont déjà été postées ici atteignent la qualité VHS, qui nous suffisaient bien à l'époque. Et elles tournent sur des vrais mig non "hackés". Pas sur un émulateur..
tout comme il faut être réaliste, 90% de l'utilisation "multimedia" de l'amiga était : faire les sous titres du club dorothée, et afficher des images précalculées. rien n'empéchait un studio TV de connecter un synthé ou sampler sur le ST midi mixer ainsi des sons qualité studio. alors oui, si tu veux, je veux bien dire que l'Amiga pouvait du multimédia "un peu plus joli" que l'Atari.
Sur le mig, tu pouvais connecter des cartes audio 16 bits multi-canaux et pilotées via AHI (rien de tel dans votre TOS ? Ah ben non...), ce qui les rendaient compatibles avec pleins d'applications : ça permettait de faire bien plus qu'un sampler/midi...
Et y a pas que le club dorothée : ça allait de motus à hugo en passant par pleins de pubs, les méteos (la première météo avec des icones animées était sur le mig, qui, avec toutes les extensions, coutait pourtant moins cher que les anciennes solutions). Et jamais entendu parler de Seaquest DSV ou Babylon 5 ? C'est pas vraiment le club Dorothée...
On trouve même une presentation faite sur le mig sur le CD de Win95. Si ça montre pas que le mig était le roi dans ce domaine...
Pas "un peu plus joli" mais beaucoup plus joli je dirais...
Et mieux animé.
Et mieux sonorisé.
Et sur tout l'écran.
Et sans scanline si besoin.
Comment ? Ok.rocky007. Tu attends quoi ? Je t'ai dit qu'il y avait des jeux avec un scrolling en HAM ? Tu n'arretes pas de dévier parce que tu ne peux pas continuer avec tes arguments. Au départ tu expliquais que le HAM ne pouvait servir qu'à des images statiques. Je t'ai montré un voxel en HAM et tu as rétorqué que les pixels etaient énormes. Superbe argument quand on sait qu'ils ont la meme taille sur les voxels en 16 couleurs des démos ST. Dans la discussion je t'ai dit qu'un scrolling en HAM était possible. Pas qu'il y avait des jeux en HAM avec un scrolling : dans un jeu c'est une autre paire de manches...
prenons alors un simple exemple, expliques-moi comment tu fais un scrolling horizontal HAM d'une jolie photo d'une demoiselle , en temps réel. tu vas encore me dire que c'est possible...mais tu oublieras de dire que ce sera moche... ne detournes donc pas le sens initial de mon affirmation.
Je met deux sprites noir sur les cotés de l'écran (par dessus le playfield). Pour faire scroller l'écran je le déplace d'un pixel à chaque fois. Si j'agrandi la zone affichée en meme temps que le déplacement, plus besoin du sprite de droite.
Quand je l'ai déplacé de 16 pixels, je change l'adresse de l'écran pour que son contenu se déplace de 16 pixel et je le repositionne à sa position de départ. Et ainsi de suite.
Il y aura des fringes seulement au déplacement de contenu. Donc tous les 16 pixels. Donc j'ai 16 frames pour préparer une copperlist qui redéfini la palette pour chaque ligne. Le 68000 doit donc préparer 12,5 lignes par frame (en 320x200) dans la copperlist. C'est largement jouable...,
Je change la copperlist quand je change de contenu.
Y a beaucoup de contraintes, je te l'accorde. Mais c'est possible. Et c'est tout ce que j'ai prétendu à la base.
Edit : Regarde cette vidéo :
Sur le haut, tu as un scrolling. Il y a des fringes au début. Si tu cachais ce début avec un sprite après avoir agrandi et déplacé l'ecran, l'affichage serait parfait.
Le scrolling ne se fait que sur une petite portion. Mais si on enlève tout ce que fait ce screen, il y a moyen de scroller une image fixe tu ne crois pas ?
Et tu es bien placé pour dire de ne pas détourner le sens initial : à la base tu as expliqué que le HAM, ce n'était que des images fixes et scintillantes...
Tu m'as mal compris. Je vais le dire autrement :rocky007Marrante la façon dont tu affirmes que le ST "aurait" pu utiliser ses tricks dans des jeux et pas le mig alors que c'est exactement le contraire...
ben tu viens juste d'affirmer le contraire : des jeux ST exploitant des tricks de megademo.
- Il est ou le jeu avec un scrolling horizontal au pixel à 50 i/s ? C'est courant dans les démo ST, n'est-ce pas ? Alors il est ou le jeu qui fait ça sur ST ? Pourtant, ça change tout : essaie sur le mig. Y en a pleins...
Et les parallaxes ? Et les multi-layer ? Y a des démos qui font ça à 50 i/s non ? Ils sont ou les jeux qui exploitent ces tricks ?
A l'inverse, je te le répète : BTL et M. Nutz exploitent des trick pour faire des effets JAMAIS vus dans une démo.
Tu avais affirmé que tu le ferais. Moi je ne t'ai jamais dit que je pouvais te montrer un scroll en HAM. J'ai juste dit que c'était possible.rocky007Puisque tu joues du "j'attend toujours", je te rappelle que tu avais affirmé pouvoir reproduire les rotations the BTL sur un ST avec 1 Mo pour prouver que c'était possible en précalc (alors que dans le cas de BTL, c'est le jeu qui tient en 1Mo). J'attends toujours...
je n'ai pas besoin de te prouver cela, tu sais qu'afficher des images precalcs sur un ST est possible non ? si, si, c'est possible. et si tu veux, je te le fais si me montre un scrolling horizontal d'une image HAM 4096 couleurs
Bien sur qu'afficher des images précalc est possible.
Et c'est vrai que tu n'en as pas besoin. Ce dont tu as besoin, c'est d'une calculette :
Le rotozoom de l'intro de BTL dure plus de 10 secondes sans jamais afficher 2 fois la meme image (Et je ne prend que la partie rotation plein écran). Il est en 50 i/s dans une résolution de 320x200x16 couleurs (et en 1x1 bien sur).
Un écran fait 32 Ko : 32 Ko x 10 secondes x 50 images = 16 Mo.
Bonne chance pour le précalc...
Et il y a pire : si tu relis mes explications sur le fonctionnement de cette rotation et que tu regardes bien les plate-formes de BTL qui pivotent, tu remarqueras quelque chose qui prouve que c'est pas du précalc. Tu ne vois pas ? Ben faut prendre la peine de mieux étudier les choses avant de faire des affirmations dessus.
Je ne demandais pas de l'aide mais un avis. Pourquoi tu parles d'assistanat ? (joli et adapté comme terme...)rocky007A noter : j'ai proposé une méthode pour faire un scrolling vertical au pixel sur ce forum et j'avais posé une question. Aucun STiste ne m'a répondu : Quand c'est pour affirmer des betises il y a du monde. Quand ça devient sérieux, il n'y a plus personne...
pourquoi ne mets tu pas ta théorie en pratique au lieu de demander de l'assitanat ? c'est trop difficile de passer 10 minute sur ton devpac ?
Et si je code quelque chose en 68000 ça sera sur le mig...
Choix personnel, c'est pas une critique : Certains préfèrent coder sur le ST, d'autres sur le mig.
Ok.rocky007Et le plus drole : SOTB sur ST était une vrai bouse. Il a pourtant été en tete des ventes pendant lontemps... LOL !
honnêtement je trouve qu'il s'en sont pas si mal sorti pour du ST.
Inutile d'etre moqueur avec ton "zoli dégradé"...rocky007Et pourquoi refaire la copperlist à chaque frame ? Tu crois qu'elle s'efface ? Il suffit de modifier ce qui doit l'être, c'est tout.
ah bon ? si tu as un jeu qui modifie dynamiquement l'image en copper, tu ne la recharge pas entierement peut-être ? mais la encore, on parlait des contrainte des vidéos avec changemement des couleurs en temps réel par le copper, pas d'un zoli dégradé dans le ciel de SOTB.
Je sais de quoi on parlait. Et c'est pourquoi j'ai dit :
la copperlist peut être modifiée avec le blitter. Très utile si on a une grosse copperlist pour faire des changement de couleurs partout par exemple.
Lis mieux la prochaine fois.
Mais arretons là : Tu penses qu'une interruption HBL (que le mig possède aussi...) c'est aussi bien qu'un copper. Ok...
Ah bon ? Ne t'ai-je pas donné raison sur Ambermoon ? En disant que le nom de l'exe était révélateur à lui seul ? N'ai-je pas également expliqué que tu avais raison en disant que le 1x1 au copper était impossible ?rocky007Je vais t'aider : tu es au courant que le copper peut faire des move dans n'importe quel registre du chipset. Tu ne t'es jamais demandé ce qui ce passerait s'il faisait un move dans le registre qui contient l'adresse de la prochaine instruction à exécuter (son PC) ? Ben ça fait un branchement ! Et grace à l'utilisation de SKIP, ce branchement peut être conditionné...
merci, mais là encore tu isoles du contexte qui était : faire une routine de 3D mappée avec le 3 instructions du copper. alors oui bien sûr tu peux faire un branchement de cette façon, mais c'est de la "bidouille", tu ne codes pas la copper comme un 68000 ( ce qui était mon propos )... mais bien sûr, c'est plus facile que de critiquer cette absurdité et l'expliquer comme si bien tu sais le faire.
Tu as raison dans ton propos : on ne fait pas de la 3D mappée avec le copper.
Tu as vu que cette fois encore que je TE DONNAIS RAISON ?
Tu as aussi dit que le copper ne pouvait pas faire de branchement : c'est faux et c'est pas une bidouille. Y a plusieurs 'PC' pour le copper dans les registres pour cette raison. Celui dont je te parle n'a aucune autre utilité. Et compare la vitesse de ce branchement avec celle du 68000, tu seras étonné...
Tu as aussi dit que le copper n'était pas utilisé pour les effets de BTL : c'est faux.
J'ai dit quand tu avais raison et quand tu avais tort. La différence, c'est que quand je t'ai donné raison, personne n'ait venu me contredire. Donc pas besoin d'insister...
- On parle du STrocky007Tu ne vois pas quel effet aurait été impossible à faire ? Je vais te donner quelques exemples :
- N'importe quel effet en haute résolution 16 couleurs.
- N'importe quel effet en oversan.
- N'importe quel effet en entrelacé.
- N'importe quel effet qui utilise le blitter (dommage : la plupart le font...)
- N'importe quel effet qui a besoin d'un scrolling (comme un simple générique)
- c'est possible sur un TT
- overscan existe, pourquoi en parles tu ?
- entrelacé ? le truc qui scintille et qui bousille les yeux et qu'aucun moniteur à moins de 10.000 FF ne peut afficher ?
- le ST n'avait pas de blitter, donc forcément
- la aussi les scrolling sont légion...mais peut-être parles tu en 60 FPS ?
- Je parle d'un overscan utilisable. Pas d'un trick qui n'est pas compatible avec tous les shifter, prend plein de ressources, rend impossible les interruptions, fait grésiller les moniteurs...
- 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.
Les pros de l'époque ne travaillaient qu'avec ça. Tout ce que tu regardais à la télé ou en vidéo (meme les DVD, pas juste les cassettes VHS) était comme ça. Aujourd'hui encore, c'est le cas avec les chaines TNT. Et les non HD sont en 576i comme le mig... (Et le "i" veut dire quoi à ton avis ?). Et quand tu était en progressif, ça générait des scanlines : ça a un coté rétro sympa aujourd'hui mais à l'époque, il fallait les éviter. Rien que ça suffit à éliminer le ST...
- On est d'accord. Donc y a pleins d'effet qu'il ne pouvait pas faire...
- ben oui : un générique qui saccade c'est pas terrible... (c'est l'exemple que je donnais pour le scrolling)
Difficile de faire plus bidon comme argument...rocky007Si je suis en train de coder quelque chose et que j'ai besoin d'une calculatrice sur ST, je fais comment si je n'ai pas chargé l'accessoire calculatrice ? Ben je fais pas...
fallait être prévoyant... idem, si sur amiga j'ai besoin d'une calculatrice une fois l'ordinateur démarré, mais que je ne retrouve plus ma disquette ? ben voilà, c'est aussi idiot. quand on bosse, on instaure un environement de travail ( qui ne se pose pas du tout avec un HD )
Moi j'avais tous mes outils sur 3 disquettes étiquetées Outils 1 à 3. Jamais eu de problème pour les retrouver.
Pour avoir la même chose en accessoires chargés dans "l'environnement instauré", il aurait fallu :
- Attendre une plombes que l'équivalent de 3 disquettes compressées soient chargées.
- Avoir 4 Mo de mémoire.
- Que tous ces outils existent sous forme d'accessoires
- Que votre cher TOS ne soit pas limité à 6 accéssoires.
Bonne chance...rocky007quel est l'interet d'un spooler d'impression dans un env monotache ?
tu fais ta capture / bufferisation série sous interruption.... tu vas me dire : oui mais alors ça plante avec les softs qui utilisent les interruptions. hormis spectrum 512 ( et encore, je sais pas si il imprimait ), les softs comme Calamus, etc.. fonctionnait parfaitement avec ce genre de spooler.
Ok : si tu veux croire qu'un spooler dans un env monotache ça a du sens, libre à toi.
J'ai toujours pas vu d'impression non bloquante sur un logiciel de dessin sur ST...
Quand à Spectrum 512, il utilise un kernel (technologie 8 bits...) : déclenche une interruption (si tu y arrives...) et admire ce qui arrive à l'image...
Traites moi de menteur directement pendant que tu y es. Tout le monde a bien vu qui, de nous deux, était régulièrement pris en défaut sur des affirmations fantaisistes. Je te fais une liste ?rocky007Oui c'est sur : super fiable le St et pas fiable le mig. C'est pour ça que le record de l'ordinateur resté allumé le plus longtemps est détenu par un Amiga (utilisé par une chaine hongroise, il est resté allumé 16 ans ! Et il a été éteint volontairement)
ah oui, ça c'est de l'argument béton ! et surement vrai, aucune panne de courant en 16 ans, elle habite dans une centrale nucléaire ta hongroise ?
Quand à la panne de courant : jamais entendu parler des onduleurs ?
Une caméra avec une synchro externe ? jamais vu. ça devait être exotique et ça llimite le choix : pas sur que les pros auraient apprécié de ne pas pouvoir utiliser les modèles les plus réputés...rocky007Je t'ai expliqué comment marche un Genlock mais tu ne comprends pas : il PREND LE CONTROLE DE L'HORLOGE VIDEO de l'ordinateur pour la synchroniser avec celle d'un autre signal vidéo (il ne se locke pas : il locke l'horloge de l'ordinateur)
En fait pas forcément mais, sinon, ça coutera bien plus cher et la qualité sera moins bonne puisqu'il faudra passer par un frame-buffer)
sauf erreur, il te faut seulement un des deux devices à locker, sauf si tu as par exemple une camera avec une connection genlock, la deuxième source n'en aura pas besoin. donc comme je disais, on pouvait très bien faire du montage vidéo avec un ST, même si cela coûte plus cher.
Et le montage, par définition, se faisait avec une bande et pas une caméra. Tu synchronisais en ralentissant la bande à la main ? LOL !
Et ta caméra qui, comme toutes les autres, travaillait en entrelacé devait avoir quelques difficulté pour se synchroniser sur un signal progressif...
Tu te raccroche aux branches (tu disais d'ailleurs que le ST pouvait faire AUSSI BIEN que le mig) mais tu aurais mieux fait d'abandonner.
Mais arretons de débattre et montres nous ça...
Et montre le nous en haute résolution overscan bien sur : du titrage dans une fenêtre (surtout que celle du ST est vraiment toute petite...) ou avec des gros pixels c'est pas sérieux...
Pourquoi sur parole ?rocky007Si je n'ai pas été clair dans l'explication (aussi bien pour le ST que le mig), n'hésites pas (toi ou d'autres) à demander.
belle démonstration, rien à redire pour une fois, même si je dois te croire 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 ?
Tu as raison : le 2x2 prend plus de temps que le 1x1 (surtout sur ST,moins sur STE. Mais c'est une vidéo STE que tu nous as montré). Mais ambermoon ne fait pas 1/4 d'écran. Et Wolfeinstein n'est pas en plein écran. La fenêtre d'Ambermoon fait pas loin de la moitié de celle de Wolfeinstein. Donc au final, de dernier affiche beaucoup moins de pixels. Et il lui faut 2 Mo pour tourner avec beaucoup moins de choses à gérer.rocky007Par contre, Ambermoon doit abondamment utiliser le blitter
oui en effet, changer les paramètres du blitter dans WinUAE change le jeu du tout au tout.
par contre je ne suis pas d'accord avec toi, afficher plein écran 2x2 n'est pas le même qu'un quart écran 1x1. de plus je n'ai jamais affirmé que le ST pouvait faire identique, mais il aurait pu faire, et tu dois l'admettre, un résultat très proche.
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.
Je peux te refaire une comparaison entre la meilleure C2P pour du raycasting sur mig et sur ST et tu verras lequel va le plus vite (tout en utilisant moins de RAM).
Tout ce que tu dis est logique. Mais tu te trompes (en partie seulement) car tu ne connais pas assez le fonctionnement d'un ST.rocky007Vroom n'est pas plus rapide sur le ST. Pourtant les routines d'affichages sont les même et n'exploitent absolument pas le chipset du mig.
tu le dis toi même : il n'utilise aucun chipset du mig, donc le jeu est 100% CPU. Le cpu du ST étant plus rapide, le jeu est plus rapide, et ce n'est pas la malheureuse routine son basse def qui va bouffer les 8% de cycle bonus du ST. j'ai poster les vidéos des 2 versions de Vroom ici même, on voit clairement une légère différence de vitesse à l'avantage du ST. mais cela est comme dis ridicule, puisque s'il avait été codé specifiquement pour l'amiga, ( ne fut-ce que les sprites ) , il aurait pris l'avantage.
Je vais donc d'expliquer :
Pour jouer un Sample sur un ST, il faut utiliser une interruption. Disons que l'on reproduise un sample à 5 Khz. Il faudra que cette interruption soit exécutée 5 000 fois par seconde. Calculons :
Pour déclencher une interruption sur le 68000, il faut 44 cycles.
Pour rendre la main, il faut 20 cycles.
Si le code utilise 3 registres (je pense que c'est un minimum), il faudra les sauvegarder au début du traitement de l'interruption: 32 cycles.
Il faudra les restaurer avant de rendre la main : 36 cycles.
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.
Et on se rend compte que "la malheureuse routine son basse def" prendra bien plus que les 850 000 cycles bonus du ST !
Tu peux améliorer un peu la situation en réservant les 3 registres à la routines. Ce qui évitera d'avoir à les sauvegarder/restaurer. Mais ça veut dire que tout le code du jeu disposera de 3 registres en moins. A voir, ça peut être plus ou moins pénalisant selon les cas.
Mais même comme ça, les 850 000 cycles seront dépensés...
Et j'ai pris des samples à 5 Khz : à cause de la variation de tonalité, il en faut bien plus pour avoir un résultat à peu près acceptable...
A noter : A cause de la reproduction du sample, Vroom ne pouvait plus faire de raster sur ce ciel et la route : les 2 interruptions se seraient téléscopés et cela aurait conduit à des problèmes dans le son ou avec les rasters (en fonction de l'interuption qui aurait du attendre). Dommage car cela aurait pu améliorer grandement l'effet de profondeur. Je me demande s'il n'aurait pas été mieux de se contenter d'un son non samplé et d'avoir ces rasters.
Sur le mig évidemment aucun problème : on aurait pu avoir les raster + le son samplé sans utiliser d'interruption...
Quand aux vidéos Youtube : tu parles de celle ou les 2 versions sont visibles sur le même écran ?
Désolé mais la version mig saccade bien plus que dans mon souvenir. Il faut se méfier des émulateurs...
Prend une vidéo faite sur un vrai A500, comme celles-ci :
Ou celle-ci (ce n'est pas vroom mais ça utilise le même moteur) :
Donc tu avais tort : les jeux sans scrolling ne sont pas forcément plus fluide sur ST.rocky007 a écrit:Lotus turbo esprit : plus fluide sur le mig. Et il n'y a pas que la fluidité : les objets sur les cotés et les voitures ne sont pas positionnés au pixel près. Ils se déplacent par a-coups. C'est déjà moche sur les objets mais sur les voitures c'est vraiment ignoble ! Facile à comparer
oui c'est vrai et c'est logique, l'atari n'ayant ni blitter, ni sprite hardware, y'a pas de mystère.
Y a pas que les fenêtres. ça concerne tous les affichages. Meme le pointeur de souris : des centaines de cycles de plus sur ST pour le raffraichir. Et ça 50 fois par seconde minimum.rocky007 a écrit:Le ST plus rapide pour les applis pro ? LOL !
un appli, ce n'est pas seulement déplacer une fenêtre plus vite au blitter, c'est aussi faire du computing, et là tu as beau sortir tes joker, la clock est là pour le ST
Et il y a les appels des fonctions de l'OS : bien plus lents sur le ST.
Et il y a l'architecture du ST : un cmp.l D0,D1 prend 8 cycles contre 6 sur le mig (comparer la valeur de 2 registres, c'est pas une instruction exotique qu'on utilise jamais).
Pour du calcul pur, tu as raison : le ST est plus rapide (surtout qu'on se fout qu'une multiplication prenne 72 cycles contre 70 ou, pire, qu'une division en prenne 160 au lieu de 158).
Mais c'est faux de dire que toutes les applis pro allaient plus vite sur ST (surtout pour les applis bureautiques)
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.
Tu as mal compris. Si l'icone n'a pas été défini, c'est l'icone standard des D7 (et lui aussi on peut le redéfinir) que le wb utilisera.rocky007 a écrit:Tu as tout à fait le droit de trouver le WB moins beau, c'est un critère subjectif. Il faut cependant noter que :
- Le WB est infiniment plus personnalisable que le GEM. Quand on voit les 2 options du GEM qui se battent en duel , ça donne envie de rire ! Les préférences du WB, c'est carrément autre chose.
Il affiche des icones personnalisés.
c'est à dire ? ne pas pouvoir voir le contenu d'un disquette si l'icone n'a pas été définie ? un coup de génie ça !
De plus c'est le nom de la disquette qui sera affichée. Et non pas LECTEUR A.
Quand au plus grand coup de génie, c'est quand même l'impossibilité de renommer un répertoire. Je ne parle pas du fait que cela ne soit pas possible dans le GEM, je parle du fait que le TOS ne pouvait pas le faire, même par programmation !
Oui démarrer le logiciel dont tu as besoin. Après avoir trouvé le bon exe : vu qu'ils ont tous des noms sur 8 caractères et le même icone, pas toujours simple.Rocky007 a écrit:Tout ça pour dire que, avec un peu de personnalisation, même toi tu aurais pu trouver le WB acceptable.
tout ce que tu as expliqué sur le WB n'effleure même pas ma sensibilité, car honnêtement je trouvais cela en 85 totalement superflu. ce qui était pour moi important, c'est d'allumer un ordi, ne pas attendre et jongler avec les 5 disquettes du WB pour avoir mon ordi operationnel, mettre une disquette, utiliser la confort de la souris et des fenetres ( et pas revenir à la préhistoire avec une ligne de commande ), ouvrir le contenu de ma disquette, voir tout ce qu'il s'y trouve et démarre le logiciel dont j'ai besoin.
que l'icone soit en 4096 HAM ou noir&blanc, c'est juste pour se la toucher ce genre de détail.
Et je souviens d'avoir voulu démarrer un logiciel sur ST et avoir eu un message me disant que je n'étais pas avec la bonne résolution ! C'est quoi ce truc ?!!!
Tous n'avaient pas ce défaut mais ça m'est arrivé pas mal de fois sur mon ST, jamais sur le mig...
Et, je te le répète : l'icone n'était pas là que pour faire joli ou pour pour repérer facilement un fichier.
Tu compares une simple commande du WB à des logiciels complet ? La commande pouvait être utilisée dans n'importe quel script (et la synthèse ne bloquait pas la suite du script puisqu'elle pouvait se faire en multitache...), ça pouvait avoir un interet. Quel est celui d'un logiciel ?rocky007 a écrit:Je me souviens de l'un de mes premiers contact avec le WB : j'ai utilisé la commande SAY pour le faire parler un peu. Quand j'ai réalisé que la synthèse vocale etait meilleure que le manoir de mortevielle (je venais du ST) je n'y croyais pas ! Mais bon : ça ne me servait à rien...
oui c'est argument classique du fanboy... mon petit voisin aussi frimait avec son SAM sur C64
c'est la grande époque du "hey , mon ordi parle".... ce que tu oublies de dire, c'est l'Atari avait lui aussi ses logiciels de synthèse vocale, dépassant ceux de l'amiga. ( oui mais on pouvait le porter squr amiga blablabla )... et à ce que je sache, ton SAY amiga ne possédait pas les phonèmes français, alors comment pouvait-il être meilleur ?
Et non, les logiciels du ST n'étaient pas meilleurs que cette simple commande. Tout simplement parce que le ST ne sait pas reproduire un sample avec la même qualité que le mig. Et je passe sur les options de la commande comme les variations de tonalité qui s'appuyaient sur un hardware inexistant sur un ST.
Fais dire "Cheese" à ton ST et écoute le souffle 10 fois plus fort qu'un cheveux sur la langue. Puis essaie sur un mig : tu verras que lui n'a pas besoin de consulter un orthophoniste... LOL !!
C'est vrai que dans ce cas, il te faut 1,5 Mo. C'est exactement ce que j'ai dit. Allez : disons que pour être tranquille, il faut 2 Mo. ça te convient ?rocky007 a écrit:Pas du tout : WHDLoad fonctionne avec 1 Mo. Avec 1,5 on est à l'aise pour les jeux ECS. C'est avec les jeux AGA qu'il en faut plus, parce que ceux-ci en prennent déjà 2. Mais les jeux AGA sur un A600...
oui en config de base... comment tu fais tourner un jeu qui nécessitait 1mo de RAM ?
De toute façon, avec un A600, c'est une carte vampire600 qu'il faut prendre : pour une centaine d'euro, ça ajoute 64 Mo et c'est plus rapide qu'un 68060. Et y a pleins de jeux sur le mig qui tire parti des cartes accélératrices.
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 !rocky007 a écrit:Ah bon ? Le midi est un port série, rien de plus. En quoi la gestion d'un port série est plus précise que la gestion d'un port série ? Et depuis quand le software en rom est un avantage ? La ROM de ton ST est plus rapide que la RAM ? C'est nouveau ça...
parce que sur amiga, la qualité du midi sera donc dépendant de la qualité du hardware ( car non, il suffit pas de brancher le TX sur la pin équivalente midi, et sera aussi dépendant du software. sur St, c'est standard et d'origine, clair et net.
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.
Mon utilisation m'a montré le contraire. Tout comme de nombreux utilisateur ici...rocky007 a écrit:rocky007 a écrit:l'Atari est bien conçu : il est plus stable que l'amiga
Bien sur, tu t'appuies sur quoi pour étayer ça ?
mon utilisation au quotidien des deux machines, tout comme de nombreux utilisateurs ici.
Aucun utilisateur du ST ne venait du mig. A l'inverse, un grand nombre d'utilisateurs du mig étaient passés par le ST. ça les rend plus crédibles pour comparer. Je parle d'utilisation réelle de l'époque. Pas de ceux qui font mumuse avec les 2 aujoud'hui.
C'est le genre d'argument que les STistes sortent quand ils n'ont rien d'autre à dire : ce n'est ni étayé ni vérifiable...
Mais si tu veux parler des erreurs de conception, je peux t'en mettre plusieurs pages. Y a des erreurs qu'on ne trouve pas dans le monde 8 bits...
Je precise alors : indépendamment du framerate, on peut effectivement avoir autant de frames d'animation sur le ST que sur le mig.rocky007 a écrit:Parce que sur le ST, il faut préshiter tous les sprites 16 fois, ça prend beaucoup de place. Sinon on le fait en temps réel : ça prend du temps (surtout pour des sprites qui font plus de 16 pixels de large). C'est possible sur un jeu avec un décor fixe et peu d'ennemis, genre POP mais impossible sinon.
Y a aussi le problème du masque : il faut le stocker également, 25% de place en plus, ou le calculer en faisant un OR entre tous les plans : ça prend du temps également.
Grace à l'utilisation d'un sprite pour le perso principal, le mig n'a besoin ni de préshifter, ni de stocker ou calculer un masque, ni d'appliquer une opération logique...
(Et pour le reste, le blitter peut faire tout ça tout seul)
merci de répeter Xeme fois l'explication que j'ai moi-même donné et précisée. Dflilver prétendait
qu'on ne pouvait animé plus de 15 frames sur ST , ce qui est complétement ridicule dire si on ne contexte pas cette affirmation, raison pour laquelle j'ai précisé, d'indépendament de la mémoire et du framerate, on peut avoir autant de frame d'animation sur un ST que sur amiga.
Juste magnifique encore. La justification qui prouve par A + B que Vroom ne peut être que plus rapide sur l'Amiga par rapport à la version ST.
Comme quoi les ataristes sont de sacrés pipoteurs quand même !
Parce que vlà le mythe quoi "Vroom est plus rapide sur ST, br*nle-toi avec ça tiens ! ".
Magnifique aussi la démonstration calcul à l'appui au sujet de BTL, putain 16mo de RAM en précalc sur ST, je me marre, mais je me marre ! !
Sérieux Rocky, vas à la pharmaco la plus proche, et demande à la dame un produit hyper fort pour les douleurs anales, à force de te faire bitumer, c'est la mort (de honte) d'ici la fin de l'année qui t'attends !
ah ça tu peux parler, on sait maintenant que tu sais pas comment certaines parties de l'amiga fonctionnent.....
Ah tu peux viendre me chercher avec "ta copper", je ricane comme une baleine !
Si Stapha était en face de moi, c'est clair, quand on assure comme ça, c'est une bière offerte par la maison sans discussion. Putain que c'est beau !
dlfrsilver- Interne
- Nombre de messages : 7782
Age : 47
Date d'inscription : 29/05/2009
Re: GUERRE ST-AMIGA, FIGHT !!!
Juste magnifique encore. La justification qui prouve par A + B que Vroom ne peut être que plus rapide sur l'Amiga par rapport à la version ST.
pas du tout, cela ne prouve rien
Magnifique aussi la démonstration calcul à l'appui au sujet de BTL, putain 16mo de RAM en précalc sur ST, je me marre, mais je me marre ! !
marres-toi parce que tu ne comprends de toute façon rien
Sérieux Rocky, vas à la pharmaco la plus proche, et demande à la dame un produit hyper fort pour les douleurs anales, à force de te faire bitumer, c'est la mort (de honte) d'ici la fin de l'année qui t'attends !
ah ça tu peux parler, on sait maintenant que tu sais pas comment certaines parties de l'amiga fonctionnent.....
Ah tu peux viendre me chercher avec "ta copper", je ricane comme une baleine !
Si Stapha était en face de moi, c'est clair, quand on assure comme ça, c'est une bière offerte par la maison sans discussion. Putain que c'est beau !
tu touches décidément le fond, lires de telles choses devient incroyable, surtout pour une personne de ton âge.
tu devrais sérieusement te remettre en question, vraiment...
rocky007- Interne
- Nombre de messages : 9152
Age : 50
Date d'inscription : 29/01/2011
Re: GUERRE ST-AMIGA, FIGHT !!!
Le membre 'rocky007' a effectué l'action suivante : Lancer de dés !
'SUPPOS DE LA FORTUNE' :
Résultat :
'SUPPOS DE LA FORTUNE' :
Résultat :
Re: GUERRE ST-AMIGA, FIGHT !!!
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
C'est pas l'allocation qui pose problème, c'est la lecture ou l'ecriture à une adresse mémoire qui peut poser plus de problème s'il y a un bug et que l'adresse en question n'est pas réservée. Mais reprend mon explication sur les chances qu'a un ST de faire ce genre de choses : pas beaucoup moins qu'un amiga...
pas beaucoup moins , c'est toujours plus qu'un peu
des nombreux studios étaient équipés de Mega ST et de cartes Chili. oui l'amiga était roi dans ce domaine, mais il n'avait pas l'exclusivité du mot "multimedia"
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.
Tu avais affirmé que tu le ferais. Moi je ne t'ai jamais dit que je pouvais te montrer un scroll en HAM. J'ai juste dit que c'était possible.
Bien sur qu'afficher des images précalc est possible.
Et c'est vrai que tu n'en as pas besoin. Ce dont tu as besoin, c'est d'une calculette :
Le rotozoom de l'intro de BTL dure plus de 10 secondes sans jamais afficher 2 fois la meme image (Et je ne prend que la partie rotation plein écran). Il est en 50 i/s dans une résolution de 320x200x16 couleurs (et en 1x1 bien sur).
Un écran fait 32 Ko : 32 Ko x 10 secondes x 50 images = 16 Mo.
Bonne chance pour le précalc...
tu te trompes, je n'ai jamais parlé de la plateforme, mais bien de l'effet "tube" en fond. avec un motif adéquat, tu peux faire le même effet en precalc, et mirrorant et doublant certaines lignes pour le partie haute et basse, ce qui fait facilement 80 étapes d'animations avec 1 mo
J'ai dit quand tu avais raison et quand tu avais tort. La différence, c'est que quand je t'ai donné raison, personne n'ait venu me contredire. Donc pas besoin d'insister...
sauf que tu cibles uniquement que les ataristes... jamais tu n'iras critiquer des conneries dites par un amigaiste, ce qui prouve que tes propos sont clairement orienté. mais on s'en fout, je faisais juste remarquer.
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.
Difficile de faire plus bidon comme argument...
Moi j'avais tous mes outils sur 3 disquettes étiquetées Outils 1 à 3. Jamais eu de problème pour les retrouver.
Pour avoir la même chose en accessoires chargés dans "l'environnement instauré", il aurait fallu :
- Attendre une plombes que l'équivalent de 3 disquettes compressées soient chargées.
- Avoir 4 Mo de mémoire.
- Que tous ces outils existent sous forme d'accessoires
- Que votre cher TOS ne soit pas limité à 6 accéssoires.
alors dans ce cas, on utilises un simple switch. ok les programmes n'était pas multitache, mais quel importance ?
Bonne chance...
Ok : si tu veux croire qu'un spooler dans un env monotache ça a du sens, libre à toi.
J'ai toujours pas vu d'impression non bloquante sur un logiciel de dessin sur ST...
Quand à Spectrum 512, il utilise un kernel (technologie 8 bits...) : déclenche une interruption (si tu y arrives...) et admire ce qui arrive à l'image...
c'est pas de "bonne chance" c'est un réalité que tout utilsateur de PAO connaissait sur ST. Je peux t'en citer : Mdisk, Gem spooler, ramaby, etc..etc..
oui comme je te l'ai expliqué dans mon post, à part spectrum, je ne vois pas d'autres programmes qui poserait problème avec un spooler en interruption. en général, les ramdisk intégrait la fonction spooler :
Traites moi de menteur directement pendant que tu y es. Tout le monde a bien vu qui, de nous deux, était régulièrement pris en défaut sur des affirmations fantaisistes. Je te fais une liste ?
Quand à la panne de courant : jamais entendu parler des onduleurs ?
simplement qui était là 16 ans pour vérifier cela, il y avait un huissier ?
Mais arretons de débattre et montres nous ça...
Et montre le nous en haute résolution overscan bien sur : du titrage dans une fenêtre (surtout que celle du ST est vraiment toute petite...) ou avec des gros pixels c'est pas sérieux...
un simple exemple, déjà cité :
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.
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 )
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é.
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
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
Tu as mal compris. Si l'icone n'a pas été défini, c'est l'icone standard des D7 (et lui aussi on peut le redéfinir) que le wb utilisera.
je parles des l'icone des fichiers, pas du floppy.
Oui démarrer le logiciel dont tu as besoin. Après avoir trouvé le bon exe : vu qu'ils ont tous des noms sur 8 caractères et le même icone, pas toujours simple.
sur une disquette on avait rarement 50 programmes. donc 8 caractères me paraissent clairement suffisant pour nommer 1 ou 2 programmes sur la même disquette
Et non, les logiciels du ST n'étaient pas meilleurs que cette simple commande. Tout simplement parce que le ST ne sait pas reproduire un sample avec la même qualité que le mig.
il y a une différence entre qualité sonore, et qualité des phonèmes et le programme qui les gère.
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.
Mais si tu veux parler des erreurs de conception, je peux t'en mettre plusieurs pages. Y a des erreurs qu'on ne trouve pas dans le monde 8 bits...
oui et c'est là encore la preuve de tes propos biaisés, pas une fois tu ne citeras les erreurs de conceptions de l'amiga, tout ne seras systématiquement à charge de l'atari
rocky007- Interne
- Nombre de messages : 9152
Age : 50
Date d'inscription : 29/01/2011
Re: GUERRE ST-AMIGA, FIGHT !!!
Tu te rends compte que rien qu'avec ça ton ST il fait plus rien d'autre ??tu te trompes, je n'ai jamais parlé de la plateforme, mais bien de l'effet "tube" en fond. avec un motif adéquat, tu peux faire le même effet en precalc, et mirrorant et doublant certaines lignes pour le partie haute et basse, ce qui fait facilement 80 étapes d'animations avec 1 mo
Maintenant si tu parles juste de cet effet avec rien autour, oui c'est même faisable via interruptions, mais justement l'intérêt de la chose sur amiga, c'est d'avoir un jeu autour, avec en plus un autre effet inédit sur la plateforme et à 50 fps .
Ce que veux dire stapha,c'est que même avec bcp de RAM les besoins en CPU sont trop lourds pour que tout tourne de façon fluide .
C'est un peu la même chose qu'avait du mal à comprendre archiforever avec l'archimedes .
Le but des customs est de permettre des traitements très rapides sur des taches spécifiques tout en coûtant bien moins cher que d'avoir un CPU de la mort et la RAM qui va avec(en quantité autant qu'en rapidité) .
Bien sur au bout d'un moment le CPU(et le reste de l'architecture) étant assez rapide fait mieux que l'amiga de base.
j'ai l'impression que vous vous rendez pas compte de la merde que c'est de faire des routines timées dans un jeu !!,c'est d'ailleurs pour ça que 99% des effets dans les demos, restent dans les demos .
Invité- Invité
Re: GUERRE ST-AMIGA, FIGHT !!!
Tiens, une petite info que je viens de lire sur le site Obligement :
http://obligement.free.fr/articles/actuenbref07082015.php
Le créateur de DirectX était un amigaïste
Dans un billet du blog de Trevor Dickinson, on apprend qu'Alex St. John, créateur et développeur de DirectX (la couche 3D officielle de Windows), était un fan absolu de Commodore et un utilisateur Amiga. Il a débuté le développement de DirectX en 1994 pour le compte de Microsoft, année où Commodore a fait faillite... tout un symbole. Voici quelques autres révélations d'Alex St. John :
On s'étonne que Microsoft estampillé "pro" ait été chercher un Amigaiste pour créer la base de son avenir... (enfin, je voulais dire, seuls les ataristes s'étonnent).
Et je m'étonne de lire que les capacités multimédia de Windows 95 étaient inférieures à celles d'un Amiga 500 de 1987...
Mais, n'aurais je pas déjà dit, il y a un moment, que Scala Multimédia refusait de porter Scala sur PC (à moins d'y être obligé par la force des choses), justement parce qu'ils disaient qu'un PC ne leur permettait pas de faire ce que faisait un Amiga...
Pourtant, ici, certains ataristes m'ont un peu critiqué pour ces propros... alors qu'il semble bien que le créateur de DirectX lui même le reconnait ouvertement...
Ce qui tend à démonter que les propos de Byte "L'Amiga le premier ordinateur multimédia" était belle et bien tout à fait objectifs, contrairement à ce qu'on a voulu laisser entendre ici.
Je sens déjà que ça va partir sur des polémiques sur le zx81 qui pouvait faire du multimédia...
Ce message était pour donner l'info et faire quelques petites remarques taquines, pas pour repartir sur un débat déjà fait en long et en large... et bien entendu... largement gagné par l'Amiga...
Ben quoi... on me dit que je taquinerais encore... mais non, c'est bon enfant tout ça...
http://obligement.free.fr/articles/actuenbref07082015.php
Le créateur de DirectX était un amigaïste
Dans un billet du blog de Trevor Dickinson, on apprend qu'Alex St. John, créateur et développeur de DirectX (la couche 3D officielle de Windows), était un fan absolu de Commodore et un utilisateur Amiga. Il a débuté le développement de DirectX en 1994 pour le compte de Microsoft, année où Commodore a fait faillite... tout un symbole. Voici quelques autres révélations d'Alex St. John :
- Son expérience avec l'Amiga a influencé son travail sur la 3D.
- Avec les versions de Windows antérieures à Windows 95, jouer une vidéo de plus d'un minute faisait désynchroniser le son.
- Un de ses boulots chez Microsoft fut d'aider des centaines de développeurs à migrer leurs jeux MS-DOS sur Windows 95.
- Il s'était dit que Microsoft allait commercialiser en 1995 un système d'exploitation multimédia qui était inférieur à un Amiga 500 de 1987.
- Lui et deux autres personnes de l'équipe Windows 95 ont conspiré pour introduire des capacités médias genre Amiga sur la plate-forme PC.
- Il a conçu DirectDraw, un système graphique inspiré de l'Amiga avec des sprites gérés matériellement.
- DirectX est la raison sine qua non de l'apparition d'un émulateur Amiga sur Windows.
On s'étonne que Microsoft estampillé "pro" ait été chercher un Amigaiste pour créer la base de son avenir... (enfin, je voulais dire, seuls les ataristes s'étonnent).
Et je m'étonne de lire que les capacités multimédia de Windows 95 étaient inférieures à celles d'un Amiga 500 de 1987...
Mais, n'aurais je pas déjà dit, il y a un moment, que Scala Multimédia refusait de porter Scala sur PC (à moins d'y être obligé par la force des choses), justement parce qu'ils disaient qu'un PC ne leur permettait pas de faire ce que faisait un Amiga...
Pourtant, ici, certains ataristes m'ont un peu critiqué pour ces propros... alors qu'il semble bien que le créateur de DirectX lui même le reconnait ouvertement...
Ce qui tend à démonter que les propos de Byte "L'Amiga le premier ordinateur multimédia" était belle et bien tout à fait objectifs, contrairement à ce qu'on a voulu laisser entendre ici.
Je sens déjà que ça va partir sur des polémiques sur le zx81 qui pouvait faire du multimédia...
Ce message était pour donner l'info et faire quelques petites remarques taquines, pas pour repartir sur un débat déjà fait en long et en large... et bien entendu... largement gagné par l'Amiga...
Ben quoi... on me dit que je taquinerais encore... mais non, c'est bon enfant tout ça...
babsimov- Interne
- Nombre de messages : 5652
Age : 54
Date d'inscription : 20/02/2011
Re: GUERRE ST-AMIGA, FIGHT !!!
Tu te rends compte que rien qu'avec ça ton ST il fait plus rien d'autre ??
Maintenant si tu parles juste de cet effet avec rien autour, oui c'est même faisable via interruptions, mais justement l'intérêt de la chose sur amiga, c'est d'avoir un jeu autour, avec en plus un autre effet inédit sur la plateforme et à 50 fps .
Ce que veux dire stapha,c'est que même avec bcp de RAM les besoins en CPU sont trop lourds pour que tout tourne de façon fluide .
C'est un peu la même chose qu'avait du mal à comprendre archiforever avec l'archimedes .
Le but des customs est de permettre des traitements très rapides sur des taches spécifiques tout en coûtant bien moins cher que d'avoir un CPU de la mort et la RAM qui va avec(en quantité autant qu'en rapidité) .
Bien sur au bout d'un moment le CPU(et le reste de l'architecture) étant assez rapide fait mieux que l'amiga de base.
j'ai l'impression que vous vous rendez pas compte de la merde que c'est de faire des routines timées dans un jeu !!,c'est d'ailleurs pour ça que 99% des effets dans les demos, restent dans les demos .
ah mais si, clairement...je ne parlais que de cet effet isolé, pas du jeu en entier... toutes les 3 pages, c'est le même cinéma, il faut toujours vous le répéter et vous rassurer : oui l'amiga est supérieur techniquement à l'atari, pas un seul atariste ici ne dira que le ST peut faire un Lion Heart ou un Shadow of the Beast, tout le monde le sait très bien.
Le ST est sorti en 1985, il a marqué le début des l'ère 16 bit, que l'Amiga a terminé avec son A500.
Comme pionier, l'Atari St a marqué l'informatique familiale et professionnelle, c'est indiscutable. Et oui, pendant plusieurs années, il a dominé l'Amiga.
la plupart des jeux ST ont des routines timées...
j'ai l'impression que vous vous rendez pas compte de la merde que c'est de faire des routines timées dans un jeu !!,c'est d'ailleurs pour ça que 99% des effets dans les demos, restent dans les demos .
Dernière édition par rocky007 le Mar 1 Sep 2015 - 21:05, édité 1 fois
rocky007- Interne
- Nombre de messages : 9152
Age : 50
Date d'inscription : 29/01/2011
Re: GUERRE ST-AMIGA, FIGHT !!!
Et je m'étonne de lire que les capacités multimédia de Windows 95 étaient inférieures à celles d'un Amiga 500 de 1987...
moi aussi cela m'étonne fortement. J'utilisais déjà Adobe Premiere sur Win95 et cela tournait parfaitement.
alors dire qu'une vidéo de plus de 1 min était pas synchro faut pas déconner.
rocky007- Interne
- Nombre de messages : 9152
Age : 50
Date d'inscription : 29/01/2011
Re: GUERRE ST-AMIGA, FIGHT !!!
rocky007 a écrit:Le ST est sorti en 1985, il a marqué le début des l'ère 16 bit, que l'Amiga a terminé avec son A500.
Comme pionier, l'Atari St a marqué l'informatique familiale et professionnelle, c'est indiscutable. Et oui, pendant plusieurs années, il a dominé l'Amiga.
Dominé... en fait avec le recul, je pense que le terme "bridé" l'Amiga est plus approprié. Trop de portages baclé avec le ST comme dénominateur commun, résultat, il a fallu attendre un Shadow of the Beast et là, toi même reconnais que c'était l'Amiga qui dominait et a ensuite dominé le ST.
Et j'en reviens toujours à la même chose, tout ce qui a manqué à l'Amiga, ce n'est ni tel ou tel prise midi ou mode 31 khz en standard, ni même un soit disant OS en ROM, c'est principalement un soutien marketing SANS FAILLE de la part de Commodore.
Car, dès sa sortie, techniquement il était supérieur à tout ce qui existait (PC/MAC/ST) tant au niveau hardware que système d'exploitation.
Le ST s'est fait sa place en raison de son rapport qualité prix, c'était tout ce qu'il avait. Avec une meilleure politique chez Commodore, non seulement l'Amiga prenait la place du MAC, mais aussi celle du ST quand le 500 apparait.
Je regrette juste que ce n'ait pas été le cas. Je viens de lire l'article en anglais du créateur de DirectX. Il ne dit rien d'autre que ce que je viens de dire au sujet de l'Amiga à l'époque :
It was one of the most remarkable computers ever made.
A multitasking consumer OS running hardware accelerated audio, sprite graphics, and displaying thousands of colors in an era when PC screens were green and a state of the art Apple Macintosh looked like this;
This was what Amiga graphics looked like back then! And unlike the game consoles of that era, I could program the Amiga!
B&W single-tasking Macintosh
PC of the day
http://blog.a-eon.biz/blog/?p=7873
Dernière édition par babsimov le Mar 1 Sep 2015 - 21:28, édité 2 fois
babsimov- Interne
- Nombre de messages : 5652
Age : 54
Date d'inscription : 20/02/2011
Re: GUERRE ST-AMIGA, FIGHT !!!
rocky007 a écrit:
Et je m'étonne de lire que les capacités multimédia de Windows 95 étaient inférieures à celles d'un Amiga 500 de 1987...
moi aussi cela m'étonne fortement. J'utilisais déjà Adobe Premiere sur Win95 et cela tournait parfaitement.
alors dire qu'une vidéo de plus de 1 min était pas synchro faut pas déconner.
Lis mieux, il dit avant Windows 95, mais malgré tout il dit bien que Windows 95 avait des capacités multimédia inférieures à un Amiga 500, pour que tu ne te méprenne pas sur mes propos.
Comme c'est lui le créateur de DirectX, on peut tout de même supposer qu'il est assez objectif pour ne pas torpiller lui même sa création. On comprends bien qu'il cherchait à apporter à Windows des capacités similaires à ce qu'il avait connu, dès le début, sur Amiga et qu'il lui a fallu du temps pour ça (c'est d'ailleurs ce que je n'ai cessé de dire depuis le début aussi, les PC de nos jours ont mis longtemps à offrir une souplesse similaire à celle de l'Amiga de l'époque.)
Attention, avant que tu me demande en long et en large ce que j'entends par souplesse, il s'agit avant tout d'un ressentit personnel à l'utilisation, mais que je résumerais par réactivité (et ce n'est pas encore ça de nos jours).
Dernière édition par babsimov le Mar 1 Sep 2015 - 21:20, édité 1 fois
babsimov- Interne
- Nombre de messages : 5652
Age : 54
Date d'inscription : 20/02/2011
Re: GUERRE ST-AMIGA, FIGHT !!!
Forcement quand les jeux étaient des portages (foireux en plus) avec rien de plus que le ST c'est sur, mais cela n'avait rien à voir avec l'amiga, ni même que le ST rivalisait .Et oui, pendant plusieurs années, il a dominé l'Amiga.
Tu pouvais même avoir un I7 @ 3ghz, si les jeux étaient des copies carbones vites fait du ST, je vois pas comment on pouvait voir que le ST était largement en dessous .
Ce sont les devs qu'il faut blâmer,pas la machine .
Oui mais en faible quantité, et pas sur tout non plus .la plupart des jeux ST ont des routines timées...
Invité- Invité
Re: GUERRE ST-AMIGA, FIGHT !!!
TOUKO a écrit:forcement quand les jeux étaient des portages (foireux en plus) avec rien de plus que le ST c'est sur, mais cela n'avait rien à voir avec l'amiga, ni même que le ST rivalisait .
Tu pouvais même avoir un I7 @ 3ghz, si les jeux étaient des copies carbones vites fait du ST, je vois pas comment on pouvait voir que le ST était largement en dessous .
Ce sont les devs qu'il faut blâmer,pas la machine .
je ne dis pas le contraire, mais il faut ajouter à cela que le A500 n'est devenu accessible / populaire qu'en 87-88, soit près de trois après la sortie du ST.
on l'a déjà dit ici, dominer un marché ne se fait pas qu'avec du hardware.
rocky007- Interne
- Nombre de messages : 9152
Age : 50
Date d'inscription : 29/01/2011
Re: GUERRE ST-AMIGA, FIGHT !!!
DirectX à ses débuts c'était juste honteux, instable et gourmand au possible. Ce n'est pas un argument en faveur de l'amiga que de le comparer.
kawickboy- Interne
- Nombre de messages : 9884
Age : 46
Localisation : Paris / Eu - Le Tréport
Date d'inscription : 30/03/2008
Re: GUERRE ST-AMIGA, FIGHT !!!
rocky007 a écrit:TOUKO a écrit:forcement quand les jeux étaient des portages (foireux en plus) avec rien de plus que le ST c'est sur, mais cela n'avait rien à voir avec l'amiga, ni même que le ST rivalisait .
Tu pouvais même avoir un I7 @ 3ghz, si les jeux étaient des copies carbones vites fait du ST, je vois pas comment on pouvait voir que le ST était largement en dessous .
Ce sont les devs qu'il faut blâmer,pas la machine .
je ne dis pas le contraire, mais il faut ajouter à cela que le A500 n'est devenu accessible / populaire qu'en 87-88, soit près de trois après la sortie du ST.
on l'a déjà dit ici, dominer un marché ne se fait pas qu'avec du hardware.
Et oui, il faut un bon marketing... je suis content que tu le reconnaisse à demi mot.
Jack Tramiel chez Commodore (avec le C64) puis chez Atari (avec le ST) avait la formule "vendez aux masses/pas aux classes".
Ce qui se résume par ayez le meilleur rapport qualité prix face aux autres. Il n'était pas technicien et se moquait totalement de savoir si le hardware était bon. Le C64 était pas mal, parce que les deux ingénieurs qui l'ont conçu se sont fait plaisir, pas parce que Jack Tramiel leur avait dis de faire quelque chose de bien et en plus, comme à chaque fois, il leur a donné six mois pour le faire. Donc le ST, c'était la même chose, fait moi un truc du genre MAC pas cher, vous avez six mois. Tout ce qui compte c'est qu'on puisse le vendre pas cher, même si à l'intérieur techniquement c'est le minimum syndical.
S'il avait réussi à racheter l'Amiga (quand il a repris Atari), il n'aurait pas gardé les ingénieurs, juste les puces dans l'état dans lesquelles elles étaient (c'est à dire avec moins puissante que celles que Commodore a permis de finaliser) et aurait sortit un version bridé au maximum de l'Amiga, car l'OS à l'époque n'existait pratiquement pas et sans Carl Sassenrath, RJ Mical... bonne chance pour le finir. Donc hop un truc de type TOS/GEM (au mieux). Heureusement que Commodore a pu racheter l'Amiga et qu'on l'a connu ainsi.
Je me rend compte que je repars sur une trop longue tirade alors que je ne voulais ne dire que quelques mots. Avec l'Amiga je m'enflamme vite. Mea Culpa.
babsimov- Interne
- Nombre de messages : 5652
Age : 54
Date d'inscription : 20/02/2011
Re: GUERRE ST-AMIGA, FIGHT !!!
kawickboy a écrit:DirectX à ses débuts c'était juste honteux, instable et gourmand au possible. Ce n'est pas un argument en faveur de l'amiga que de le comparer.
Mon propos n'était pas de comparer DirectX avec l'Amiga.
D'ailleurs, si tu lis l'article en anglais, tu verras que le créateur de DirectX le dit lui même, Windows 95 ne supportait pas DirectX par défaut en réalité. Pour que les jeux DirectX tourne il devait dégager certaine couches de Windows95 pour que DirectX prenne la main comme il pouvait.
Ce qui est intéressant, c'est de lire à quel point il admirait l'Amiga comme ordinateur novateur et qu'il a cherché à introduire les concepts à la base de l'Amiga dans le PC, via DirectX.
Mon propos était, au départ, de dire que même l'auteur de DirectX reconnait que l'Amiga était supérieur pour le multmédia à Windows95 et bien entendu, par extension à tous les ordinateurs de l'époque (c'est ce qu'il dit dans ses propos, c'est très clair, y compris au sujet du MAC, il ne parle même pas du ST)
babsimov- Interne
- Nombre de messages : 5652
Age : 54
Date d'inscription : 20/02/2011
Re: GUERRE ST-AMIGA, FIGHT !!!
c'est un tout : une machine pas chère, fiable, puissante, révolutionnaire à sa sortie, avec un bon marketing.. et on ne peut pas dire que l'hardware était mauvais, il n'était pas exceptionnel mais il remplissait parfaitement son rôle de machine polyvalente.
rocky007- Interne
- Nombre de messages : 9152
Age : 50
Date d'inscription : 29/01/2011
Re: GUERRE ST-AMIGA, FIGHT !!!
Mon propos était, au départ, de dire que même l'auteur de DirectX reconnait que l'Amiga était supérieur pour le multmédia à Windows95 et bien entendu, par extension à tous les ordinateurs de l'époque (c'est ce qu'il dit dans ses propos, c'est très clair, y compris au sujet du MAC, il ne parle même pas du ST)
"tout ce qu'il dit n'est pas parole d'évangile"
plus que jamais cette phrase a du sens avec internet. je ne dis pas qu'il a tort, mais chacun à ses convictions profondes et son vécu. ce n'est pas parce que Bill Gate disait que Win 3.1 était le meilleur OS du monde qu'il avait raison. tout comme certains astronautes jurent avoir vu des extras terrestres... bref, son status ne donne pas une garantie de ses propos.
rocky007- Interne
- Nombre de messages : 9152
Age : 50
Date d'inscription : 29/01/2011
Page 28 sur 34 • 1 ... 15 ... 27, 28, 29 ... 34
Sujets similaires
» GUERRE ST-AMIGA, FIGHT !!!
» GUERRE ST-AMIGA, FIGHT !!!
» GUERRE ST-AMIGA, FIGHT !!!
» GUERRE ST-AMIGA, FIGHT !!!
» GUERRE ST-AMIGA, FIGHT !!!
» GUERRE ST-AMIGA, FIGHT !!!
» GUERRE ST-AMIGA, FIGHT !!!
» GUERRE ST-AMIGA, FIGHT !!!
» GUERRE ST-AMIGA, FIGHT !!!
Page 28 sur 34
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum