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

[The_Real_Zarchos]

C'est quoi le rapport de l'Archimedes dans ce thread ST-Amiga?

De plus, à sa sortie il coutait environ le double du prix de l'Amiga, qui lui même était mega cher comparé au ST (en 87). C'est quoi l'intérêt de comparer des ordis avec de telles différences de prix?

Ajusté à l'inflation, ca fait plus de 3000 Euros de nos jours, personne ne pouvait se le payer.

Ah tiens un comparse à la rescousse, bien à propos après que j'aie rétamé, pour la Nième fois, en long, en large, et en travers le Toukon-Mermoz 
Parles-en à ton Toukon-Mermoz, c'est son système pour me faire bannir : amener l'Archie ici, comme ça je réponds, au final ça énerve le Boss, et hop, 15 jours de ban.
C'est bien organisé votre histoire, et vous insultez ma très grande intelligence en pensant que je ne l'ai pas déjà remarqué.
**** top drôle ! ****

Parle nous du prix du 1000 et du 2000, tous 2 bien plus chers qu'un Archie ... mais je vais aller à la conclusion du débat sur le meilleur rapport qualité prix, puisqu'on va comparer des pommes et des oranges ( l'ordibouse de commocrotte face à la station de travail d'Acorn ) : ça restera toujours le ZX Spectrum +2 

[Invité]

 t'as rien rétamé du tout, après tes propos nuls encore resté sans réponse, comme d'hab, tes bêtises sur les couleurs bref, la merde habituelle avec toi, j'attends encore ta capture .

Mais bon vu que tu aimes faire de la provoc, même en racontant de la merde, ça ne m'étonne pas en fait .
Heureusement que les gens qui prennent le temps de lire ,peuvent voir que je t'ai encore humilé et démontré que tu ne connaissais pas grand choses, ni même les propriétés de ta machine . 
Tu me feras toujours autant rire, le beauf .

Franchement t'as vraiment pas de figure malgré que tu sois une brèle, tu continues à te venter 
T'es lamentable, et tout ça pour pas avoir à démontrer que tu pipeautes comme un charlot avec tes 480 couleurs WTF . 

Sur ce j'arrête la perte de temps, mets ta capture, ou ferme là .
Quand je pense que t'as même pas les connaissances pour savoir ce qu'est une palette, putain, la looze 

[The_Real_Zarchos]

Encore une fois, que des assertions, et aucune démonstration.

[Seb]

Je ne viens à la rescousse de personne, je viens sur Gamopat depuis des années et je trouve cette discussion complètement hors sujet dans ce thread, en plus de l'avoir rendu encore plus désagréable qu'il ne l'était avant que tu viennes.

J'ai eu un ST et un Amiga à l'époque et je me souviens que l'Archimedes était absolument hors de prix et qu'on s'en foutait tous de cette machine.

D'ailleurs j'ai regardé sur Mobygames par curiosité (qui ne liste pas tous les jeux mais ca donne un bon ordre de grandeur), et j'y vois que tous les ordis de l'époque ont des milliers de jeux, pendant que l'archimedes en a 148, soit une différence d'un facteur 10 et même 20.

Ouvre toi un thread pour l'Archimedes, cette machine qui n'intéressait pas grand monde à l'époque et qui coutait une fortune n'a rien à faire dans celui-là. Ce thread est dédié à ST Vs Amiga

[Invité]

Encore une fois, que des assertions, et aucune démonstration.

Pour le moment, hormis montrer que t'es un guignol, je vois rien d'autre dsl .

Déjà mets la capture, ça commence à faire longuet là .

[The_Real_Zarchos]

Je ne viens à la rescousse de personne, je viens sur Gamopat depuis des années et je trouve cette discussion complètement hors sujet dans ce thread, en plus de l'avoir rendu encore plus désabréable qu'il ne l'était avant que tu viennes.

J'ai eu un ST et un Amiga à l'époque et je me souviens que l'Archimedes était absolument hors de prix et qu'on s'en foutait tous de cette machine.

D'ailleurs j'ai regardé sur Mobygames par curiosité (qui ne liste pas tous les jeux mais ca donne un bon ordre de grandeur), et j'y vois que tous les ordis de l'époque ont des milliers de jeux, pendant que l'archimedes en a 148, soit une différence d'un facteur 10 et même 20.

Ouvre toi un thread pour l'Archimedes, cette machine qui n'intéressait pas grand monde à l'époque et qui coutait une fortune n'a rien à faire dans celui-là. Ce thread est dédié à ST Vs Amiga

On y parle aussi PC, X68000, Apple Mac, Apple IIGS, Falcon, TT, et même Next, alors ton avis à effarouchement sélectif et orienté ...

[stapha92]

Dixit le mec qui comme son double spirituel Mr zarchouille, ne poste que pour cracher sur les membres, j'adore ton sens aigu de l'équité et ton attitude humble 

On a droit à l'hôpital qui se fout de la charité...
Ton 'shoot' sur PCE, en version 'alpha', c'est le summum du comique ...
Y a rien à l'écran, pas d'ennemis ...
T'as toujours pas compris comment coder une routine de collisions ?
On te l'a expliqué ici, pourtant ...
Tu devrais monter une équipe de bras cassés avec le Stapha, lui ne sait pas coder une routine de rebonds ...

Ben si : contrairement à ce que tu affirmes, mon code peut reproduire exactement tes "rebonds" (entre guillemets puisque ce sont juste des inversions de sens moches et sans intérêt...).
Je t'expliquerai comment il marche quand tu auras produit le tien qui doit prendre moins de place d'après toi.
Bien sur, tu es libre de produire le code que tu veux, et d'utiliser ce que tu veux (même une table de 1Go si tu en as besoin) mais tu auras beau te triturer le cerveau, il te sera impossible de faire plus court...
Et tu as de la chance : j'aurai pu produire un code qui utilise des pattern prédéfinis (tu sais : c'est ce qu'on utilise dans les VRAIS jeux...) et la différence aurait été plus grande...

Et j'attend toujours un comparatif avec un code vraiment utile : comme celui que j'ai proposé et qui, en 10 octets (5 intructions), calcule les coordonnées X et Y d'un texel en virgule fixe et l'applique sur la texture. Tu dis maitriser les virgules fixes, ça devrait pas être compliqué  (je te le dis tout de suite : même en 20 octets tu n'y arriveras pas. loin de là). Le seul élément dans ton truc qui a besoin de ça c'est la routine de rééchantillonnage du son à jouer. Et tu n'as jamais été capable de le produire tout seul...
Pour info : elle est plus simple (il n'y a pas 2 variables à calculer mais une seule). Pourtant, elle sera bien plus longue que celle que j'ai donnée en exemple (et qui est connue de tous sur le mig depuis bien longtemps...)

C'est comme le Stapha, qui devait avoir une super idée pour faire un truc d'enfer sur Archie ( avec Babsimov qui était tout admiratif ) ah et puis hop, prout ! Ca ne peut pas marcher puisque l'Archie n'a que 16 slots pour obtenir 256 couleurs ...
Du coucou, patatra ! encore une connerie de plus de Stapha qui se la joue 'professeur' alors qu'il n'a que le niveau 'balayeur'.

Quel rapport ? Qui t'a dit que mon idée s'appuie sur une vrai palette ? Tu fabules encore ?
Ou tu comprends de travers et tu parles de la foi ou je disais qu'on pouvait transformer un chunky 256 couleurs en 2 plans de 16 couleurs. J'avais bien précisé que ça ne marchait pas sur archi parce qu'on peut pas les définir. Je me moquai de ton mode 256 couleurs avec 16 slots. Reprends mon post...

Mon idée ne s'appuie pas sur la palette. Pas du tout. Elle fonctionne donc aussi bien avec une vrai palette qu'avec celle de ton archimerde...

D'ailleurs je peux toujours l'envoyer à iktos s'il le souhaite : il me semble qu'il connait l'ARM...

Et rappel : je sais qu'il n'y a que 16 slots puisque j'ai du t'expliquer plusieurs fois comment étaient calculées les 240 couleurs que tu ne choisis pas...
Au bout de 30 ans, tu n'avais pas compris. Il m'a fallu 1 minute (comme à n'importe quel VRAI codeur). C'est qui le bras cassé ?

Et tu crois toujours qu'il y a des instructions à 0 cycles ? Je t'avais pourtant expliqué cette histoire ce cycles il y a bien longtemps et tu t'es moqué de mes propos dans un autre topic ou je n'étais même pas. La petite explication que tu as publiée prouve que j'avais raison mais tu ne t'en rends même pas compte. C'est qui le bras cassé ?

Tu promets partout un vrai jeu (tu avais même publié une page... lol !) depuis longtemps et il n'y a toujours rien. C'est qui le bras cassé ?

Tu compiles tes sprites à la main et tu obtiens un source de 600 Ko. Tu es le seul à faire ça, je peux te l'assurer. C'est qui le bras cassé ?

Tu as mis des années à poindre tes routines et je les ai déduites en 3 posts. Tu m'as alors accusé d'avoir décompilé du code que tu n'as pas publié (j'en serai de toute façon incapable). C'est qui le bras cassé ?


Parlons de ton WIP un peu :
- 480 couleurs grace à ton dégradé. Mais avec ta palette merdique, c'est 16 couleurs qui sont perdues et non une seule. Il te reste donc 15 couleurs choisies et 225 imposées pour le reste. Super les 480 couleurs...
- 2 Mo pour l'écran d'accueil incomplet. Y a rien qui te choque ?
- Tu utilises des sprites compilés à la main. Il te faut donc, pour avoir un mouvement horizontal 4 version de chaque sprite avec les 4 alignement possibles. C'est pour ça qu'il n'y a pas grand chose qui bouge horizontalement dans ton WIP. Sinon les 2 Mo n'aurait même pas suffits. Tu as même été obligé de mettre un effet d'apparition tout moche pour que ça ne soit pas trop statique...
- Avec les arbres, ton "optim" ne fonctionne pas car elle n'est efficace qu'avec des lignes pleines et les plus longues possibles (histoire de basculer en 32 bits dès le premier octets à écrire qui est aligné sur 32 bits). Or les arbres ont pleins de trous...
- Avec les ennemis, ton optim est moins efficace aussi car ils ont aussi des trous. Moins que les arbres mais il y en a...
- Le seul objet animé, c'est le perso principal. Ben oui : qui dit sprite à plusieurs frames, dit encore de la mémoire à consommer : entre les 4 versions de chaque frame et le code compiléà refaire pour chacune, 2 Mo ne suffisent plus.
- Tu as du passer tellement de temps sur le perso principal que tu nous l'as mis 11 fois ! Tu cherches à cacher la misère ?
- Ton perso principal est de la même couleur de la barrière du premier plan, ce qui fait bizarre : c'est pas le cas sur Amiga. Avec 480 couleurs tu n'as pas été capable de lui réserver sa propre palette ?
- 80% de Beast se passe dans les souterrains et le chateau : là tu as tout un plan entier à dessiner par dessus l'écran et, pas de bol, il y a des trous ! Comment vas tu t'en sortir avec tes sprites compilés ? Ah ben merde, ça ne peut plus marcher. Ou alors tu vas avoir plusieurs Mo de code juste pour ça... Mais t'en es pas au point ou tu es capable de le comprendre...
- Pour tout ça, tu utilises un ARM à 12 Mhz. Si on met le 1200 dans l'histoire alors là... Déjà que sur A500, il y a beaucoup mieux que SOTB....

J'arrete là, je pense que c'est plus que suffisant pour donner raison à Mermoz et montrer aux autres pourquoi tu ne peux pas sortir un jeu de tout ça...

Et à propos : quand tu te moques de Touko en disant qu'il ne sait pas implémenter une gestion de collision, tu devrais juste te souvenir de 2 choses :
- C'est une PC Engine. Je pense pas qu'il y ait de soucis pour ça...
- A ce jour, on n'a jamais vu une détection de collision dans tes WIP. C'est toi qui a l'air d'avoir du mal avec ça...

Et avec 4 octets d'occupation mémoire l'ARM peut charger jusqu'à 52 octets ( ce qui n'est pas le cas du 68000 ).

ça te suffisait pas de dire des conneries sur l'ARM ? Faut que tu reviennes sur le 68000 ? Avec 4 octets d'occupation mémoire, le 68000 peut charger jusqu'à 60 octets  : ben oui, ses 16 registres sont librement utilisables. Par exemple, le Program Counter n'en fait pas partie, contrairement à l'ARM...

[stapha92]

et bien allons y, fais donc la liste des instructions que tu peux utiliser pour du codé généré sur ARM
je te fais un début de liste de mémoire en 68000:
moveq
move.w
move.b
move.l
and b/w/l
or b/w/l
movep
automodification d'offsets pour lea et tous les move ( complexité directe au carré avec ça )
addx 
lsr/lsl/roxr/roxl pour transformer le contenu des registres sans les recharger
y en a surement d'autres mais ça date de 25 ans.

Expliques lui aussi que ces instruction ont toutes pleins de mode d'adressages. Là ou l'ARM ne sait travailler que sur des registres, le 68000 peut le faire aussi sur la RAM et en y accédant de pleins de façon différentes.

[Copper]

et surtout le 68000 sait faire des divisions un truc de fou

[Zarnal]

et surtout le 68000 sait faire des divisions un truc de fou

Surtout des divisions par zéro...

[stapha92]

Tu comprends déjà avec ça qu'il faut maximiser le nombre de registres dans ton LDM, c'est à dire charger plusieurs contenus de segments horizontaux définissant ton sprite, pour que ta liste de registres soit maximale.

C'est d'ailleurs pour ça que ça pose un souci de densité à tes sprites compiler dès qu'il y a des trous, sans parler des cycles suplèmentaire que le fetch va te prendre pour chaque instructions sup .

Ca c'est la connerie classique lue et relue partout.
En code généré tu n'as pas de masque, tu économises donc déjà de la place mémoire, et tu ne stockes pas les mots 32 bits de vide dans le rectangle englobant ton sprite ...
Et avec 4 octets d'occupation mémoire l'ARM peut charger jusqu'à 52 octets ( ce qui n'est pas le cas du 68000 ).
LDMIA R0!,{R1-R13}
laisse R14 dispo pour la destination de l'écriture dans la mémoire vidéo
l'adresse de retour de ton code tu l'as sauvée en mémoire et à la fin tu reviens à ton appelant avec LDR R15,AdresseRetour ( au départ t'as fait STR R14,AdresseRetour )
je simplifie pour expliquer

Parlons du dualplayfield sur le mig.
Il faut bien avoir tout le 'plan' en mémoire non ?
Donc perdre une place de dingue avec le vide ? ( ce qui n'est pas du sprite )
Moi je m'en fous sur Archie du vide, puisque tout est du sprite compilé ( donc sans les mots 32 bits de vide ).
Aaaahhh, vous n'y aviez pas pensé à celle-là, hein ?

Si si on y pense. Mais pas toi apparemment : avec toute cette place perdue SOTB tourne avec 512 Ko. Toi t'en es à 2 Mo avec pleins de contraintes pour économiser de la RAM...
Oser parler d'économie de place mémoire avec ton WIP...

Oui : parle du dual-playfield et montre nous ça sur Archie. En attendant, puisqu'on est pas prêt de voir quelque chose, et juste pour info : en dual playfield, le layer de devant (avec les vides) prend max 30 Ko (en 352x288 et en prévoyant 16 pixels de plus sur les 4 cotés pour le scrolling). Donc tu nous expliques qu'on perd une place de dingue alors que ça sera une portion de ces 30 Ko ? Même en double buffer, c'est ridicule à coté de la place que prennent tes sprites compilés...
Ou bien tu penses qu'on stocke tout le niveau en RAM ? Ben non, dans un vrai jeu on utilise des tiles (que l'amiga ou l'archimedes doivent gérer "manuellement"). Ton WIP n'en gère pas alors que le vrai SOTB si (ça pourrait être dans la liste des arguments qui démontent ton WIP, un de plus). Tu passeras sur ARM à 25 Mhz quand il faudra ajouter ça à ton WIP ?

[The_Real_Zarchos]

Et avec 4 octets d'occupation mémoire l'ARM peut charger jusqu'à 52 octets ( ce qui n'est pas le cas du 68000 ).

ça te suffisait pas de dire des conneries sur l'ARM ? Faut que tu reviennes sur le 68000 ? Avec 4 octets d'occupation mémoire, le 68000 peut charger jusqu'à 60 octets  : ben oui, ses 16 registres sont librement utilisables. Par exemple, le Program Counter n'en fait pas partie, contrairement à l'ARM...

-
Ah j'aurais dû préciser pour les psycho rigides autistes dans ton genre alors : je parlais dans le cas de l'usage pour les sprites compilés, puisque c'était le thème.
Toi qui es SI   intelligent, tu pourrais suivre, tout de même 

[The_Real_Zarchos]

Tu comprends déjà avec ça qu'il faut maximiser le nombre de registres dans ton LDM, c'est à dire charger plusieurs contenus de segments horizontaux définissant ton sprite, pour que ta liste de registres soit maximale.

C'est d'ailleurs pour ça que ça pose un souci de densité à tes sprites compiler dès qu'il y a des trous, sans parler des cycles suplèmentaire que le fetch va te prendre pour chaque instructions sup .

Ca c'est la connerie classique lue et relue partout.
En code généré tu n'as pas de masque, tu économises donc déjà de la place mémoire, et tu ne stockes pas les mots 32 bits de vide dans le rectangle englobant ton sprite ...
Et avec 4 octets d'occupation mémoire l'ARM peut charger jusqu'à 52 octets ( ce qui n'est pas le cas du 68000 ).
LDMIA R0!,{R1-R13}
laisse R14 dispo pour la destination de l'écriture dans la mémoire vidéo
l'adresse de retour de ton code tu l'as sauvée en mémoire et à la fin tu reviens à ton appelant avec LDR R15,AdresseRetour ( au départ t'as fait STR R14,AdresseRetour )
je simplifie pour expliquer

Parlons du dualplayfield sur le mig.
Il faut bien avoir tout le 'plan' en mémoire non ?
Donc perdre une place de dingue avec le vide ? ( ce qui n'est pas du sprite )
Moi je m'en fous sur Archie du vide, puisque tout est du sprite compilé ( donc sans les mots 32 bits de vide ).
Aaaahhh, vous n'y aviez pas pensé à celle-là, hein ?

Si si on y pense. Mais pas toi apparemment : avec toute cette place perdue SOTB tourne avec 512 Ko. Toi t'en es à 2 Mo avec pleins de contraintes pour économiser de la RAM...
Oser parler d'économie de place mémoire avec ton WIP...

Oui : parle du dual-playfield et montre nous ça sur Archie. En attendant, puisqu'on est pas prêt de voir quelque chose, et juste pour info : en dual playfield, le layer de devant (avec les vides) prend max 30 Ko (en 352x288 et en prévoyant 16 pixels de plus sur les 4 cotés pour le scrolling). Donc tu nous expliques qu'on perd une place de dingue alors que ça sera une portion de ces 30 Ko ? Même en double buffer, c'est ridicule à coté de la place que prennent tes sprites compilés...
Ou bien tu penses qu'on stocke tout le niveau en RAM ? Ben non, dans un vrai jeu on utilise des tiles (que l'amiga ou l'archimedes doivent gérer "manuellement"). Ton WIP n'en gère pas alors que le vrai SOTB si (ça pourrait être dans la liste des arguments qui démontent ton WIP, un de plus). Tu passeras sur ARM à 25 Mhz quand il faudra ajouter ça à ton WIP ?

Oui, on sait : un SOTB avec moults accès disques et en display timbre-poste 288x192 avec l'animation d'un personnage principal style 'écloppé' ...   et qui passe en 25 fps quand il se retourne, putain comme je me marre 
J'en baille : je ne suis pas sur ce niveau de merditude amigagaesque 

[stapha92]

et surtout le 68000 sait faire des divisions un truc de fou

Un jour, pour répondre à ça, il a sorti un code qui travaillait en additionnant le diviseur à chaque itération. Du coup, si le résultat est de 1 milliard, il faut 1 milliard d'itération. Rien que le branchement prend 5 cycles : 1 cycle pour l'instruction, 1 cycle pour la perte d'accès séquentiel et 3 parce que le pipeline est vidé dès qu'il y a un branchement sur son ARM). A vu de nez, entre 30 et 60 minutes avant d'avoir le résultat...

[The_Real_Zarchos]

et surtout le 68000 sait faire des divisions un truc de fou

Un jour, pour répondre à ça, il a sorti un code qui travaillait en additionnant le diviseur à chaque itération. Du coup, si le résultat est de 1 milliard, il faut 1 milliard d'itération. Rien que le branchement prend 5 cycles : 1 cycle pour l'instruction, 1 cycle pour la perte d'accès séquentiel et 3 parce que le pipeline est vidé dès qu'il y a un branchement sur son ARM). A vu de nez, entre 30 et 60 minutes avant d'avoir le résultat...

Faux : prouve tes dires.
C'est trop facile de balancer des conneries à chaque fois.

[stapha92]

Oui, on sait : un SOTB avec moults accès disques et en display timbre-poste 288x192 avec l'animation d'un personnage principal style 'écloppé' ... 
J'en baille : je ne suis pas sur ce niveau de merditude amigagaesque 

Oui plus petit : mais plus beau, avec un meilleur son et... qui fonctionne ! Toujours pas de tiles ? Parce que c'est plus facile d'être en 320 quand on en gère pas...

[The_Real_Zarchos]

C'est la totale éclat' ce soir ! Youpi !
Ils sont tous de sortie les tarés du mig !
C'est whack a mole ! Je vais m'amuser !

[stapha92]

et surtout le 68000 sait faire des divisions un truc de fou

Un jour, pour répondre à ça, il a sorti un code qui travaillait en additionnant le diviseur à chaque itération. Du coup, si le résultat est de 1 milliard, il faut 1 milliard d'itération. Rien que le branchement prend 5 cycles : 1 cycle pour l'instruction, 1 cycle pour la perte d'accès séquentiel et 3 parce que le pipeline est vidé dès qu'il y a un branchement sur son ARM). A vu de nez, entre 30 et 60 minutes avant d'avoir le résultat...

Faux : prouve tes dires.
C'est trop facile de balancer des conneries à chaque fois.

Rien à foutre de te prouver quoi que ce soit. Les lecteurs décideront qui croire. Après tous les mensonges et les insultes que tu as proférés sur moi, sur des topics ou je n'étais même pas, tu crois que je vais faire une recherche pour prouver que tu as dit un truc débile ? Vraiment pas besoin...

[Invité]

Et gérer un mode tiles en code généré , en fait il va perdre le bénéf des tiles qui est d'économiser de la RAM,si tant est que ce soit pertinent et simple à faire .
Il a de la chance, le niveau de départ, n'est pas spécialement varié, donc il a une chance, avec 2Mo de plus 

[The_Real_Zarchos]

Oui : parle du dual-playfield et montre nous ça sur Archie. En attendant, puisqu'on est pas prêt de voir quelque chose, et juste pour info : en dual playfield, le layer de devant (avec les vides) prend max 30 Ko (en 352x288 et en prévoyant 16 pixels de plus sur les 4 cotés pour le scrolling). Donc tu nous expliques qu'on perd une place de dingue alors que ça sera une portion de ces 30 Ko ? Même en double buffer, c'est ridicule à coté de la place que prennent tes sprites compilés...

Le dual playfield ce ne sera pas un avant plan en 7 couleurs comme sur ton sous hardware bousique de console de jeux râtée : ce sera sur Archie en 256 couleurs, hé ouais mon pote 

[iktos]

Et avec 4 octets d'occupation mémoire l'ARM peut charger jusqu'à 52 octets ( ce qui n'est pas le cas du 68000 ).

ça te suffisait pas de dire des conneries sur l'ARM ? Faut que tu reviennes sur le 68000 ? Avec 4 octets d'occupation mémoire, le 68000 peut charger jusqu'à 60 octets  : ben oui, ses 16 registres sont librement utilisables. Par exemple, le Program Counter n'en fait pas partie, contrairement à l'ARM...

-
Ah j'aurais dû préciser pour les psycho rigides autistes dans ton genre alors : je parlais dans le cas de l'usage pour les sprites compilés, puisque c'était le thème.
Toi qui es SI   intelligent, tu pourrais suivre, tout de même 

tu montres encore que tu n'y connais rien
tu les charges comment les registres pour les utiliser dans ton code généré ?
ben avec des movem qui peuvent charger 16 registres d'un coup, y compris A7/sp/usp qui sert de pile

et paf, encore un echec de zarcouille

[dlfrsilver]

Les adeptes de la technologie obsolète depuis plus de 35 ans sont en ville ce soir! Regardez-les fantasmer et se tripoter en choeur à 01h du matin sur des histoires de blitter à la con. On voit que la plupart des pharmacies sont fermées le dimanche, il faut donc trouver un exutoire en attendant qu'elles rouvrent lundi matin...

Parole d'homosexuel qui s'adore ! On te croit 

[dlfrsilver]

Au fait pourquoi GUNHED TV n'aime pas ATARI ? 

Parce qu'il n'y connait rien.

Réponse de gars qui n'a pas lu le bouquin (la réponse est dedans) mais crois savoir et se cramponne a ses convictions qui reposent...sur rien 

Pas besoin de lire son bouquin ,  si il n'aime pas l'ATARI , ca ne peut etre que parce qu'il n'y connait rien.  Faut aller chercher MIDI sur Amiga..  ou a 14h.

Ou alors c'est un Atariste refoulé... 

A mon avis, la réponse la plus probable, c'est que c'est peut etre un gas très intelligent, et qu'il a compris que pour faire un business avec des video et des bouquins retro il faut touché les pigeons de la secte Amiga.   

C'est comme l'autre a qui l'on demandait "est-ce que si on vous prouve que la terre est ronde, vous allez arreter de proclamer que la terre est plate?" ou il repond  "non,  parce que c'est mon Business".

Non mais toi aussi c'est quoi que tu comprends pas ? Tu crois que les anciens d'Atari auraient accepté de collaborer avec lui ?

En fait c'est simple, c'est pas une question d'aimer, ne pas aimer ou détester l'Atari, c'est de dire les choses comme elles ont été ! Et pas comme ça vous arrange !

Son bouquin à Gunhed, plein d'Ataristes l'ont acheté (ptet même plus que de possesseurs d'Amiga....), et tous sont d'accord voir étonnés avec les anecdotes fournies par les anciens de chez Atari.

Qui soit dit en passant contrairement à vous, n'en ont rien à foutre, bande de sectaires que vous êtes !

plus que sectaire, je dirais que c'est du fanatisme car quand clame tout content qu'il n'y a pas besoin de lire pour savoir ce qu'il y a dedans et par avance connaître les raisons qui animent son auteur on retrouve le même mécanisme chez ceux qui voulaient lapider Salman Rushdie

Mais sinon, le bouquin il vaut le coup ou sa vidéo sur la guerre ST vs Amiga suffit ?

Le bouquin comporte des infos inédites, fournies par les anciens de chez Atari et plus encore. Je dévoile pas, achetez le bouquin.

[rocky007]

Le bouquin comporte des infos inédites, fournies par les anciens de chez Atari et plus encore. Je dévoile pas, achetez le bouquin.

c'est bon, je l'ai trouvé en torrent, scanné 600 DPI.  étrangement aucun nom des "anciens d'Atari" ne sont cités... bizarre non ?  on ne cite pas ses sources en tant que bon journaliste ?

[dlfrsilver]

Le bouquin comporte des infos inédites, fournies par les anciens de chez Atari et plus encore. Je dévoile pas, achetez le bouquin.

c'est bon, je l'ai trouvé en torrent, scanné 600 DPI.  étrangement aucun nom des "anciens d'Atari" ne sont cités... bizarre non ?  on ne cite pas ses sources en tant que bon journaliste ?

ça m'étonnerait...... Encore tes contrefeux pourris, comme d'hab.....

[youki]

C est un roman de passé-fiction ce bouquin.

[Invité]

C est un roman de passé-fiction ce bouquin.

Y'a des babes au moins dedans ? 

Sinon c'est nul . 

[dlfrsilver]

C est un roman de passé-fiction ce bouquin.

Tout à fait, avec des infos des anciens d'Atari.

[youki]

C est un roman de passé-fiction ce bouquin.

Tout à fait, avec des infos des anciens d'Atari.

C est une sorte de fable...

[dlfrsilver]

C est un roman de passé-fiction ce bouquin.

Tout à fait, avec des infos des anciens d'Atari.

C est une sorte de fable...

Sauf qu'elle est réaliste et qu'elle fait mal au cul. Putain la barre de rire, le boss d'Atari France qui a du remplacer à sa pomme tout les megaST de Libération à cause des problèmes de bug DMA/CPU, ahahah j'en rigole encore !
Et pire, qu'il ait du les menacer chez Atari hihihihi 

La tronche du "pro" chez Atari, y a jamais eu ça sur Amiga en modèle professionnel. La machine était réputée pour sa fiabilité.

[youki]

C est un roman de passé-fiction ce bouquin.

Tout à fait, avec des infos des anciens d'Atari.

C est une sorte de fable...

Sauf qu'elle est réaliste et qu'elle fait mal au cul. Putain la barre de rire, le boss d'Atari France qui a du remplacer à sa pomme tout les megaST de Libération à cause des problèmes de bug DMA/CPU, ahahah j'en rigole encore !
Et pire, qu'il ait du les menacer chez Atari hihihihi 

La tronche du "pro" chez Atari, y a jamais eu ça sur Amiga en modèle professionnel. La machine était réputée pour sa fiabilité.

Il donne des preuves  de ça?   

On parle des gas de commodore qui ont du rappeller tout les amigas chez les distributeurs pour modifier la roms, pour enlever le message "we did it, they fucked it".?