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

[rocky007]

La question était pour la PC Engine , pas pour l'Amiga

[Copper]

C'est hors sujet la PC Engine

[rocky007]

Touko l'a amenée dans la conversation pour expliquer comment l'effet de BTL était réalisé , donc curieux comme le je le suis j'attends ses explications complémentaires pour enrichir mes connaissances

[touko]

Déjà, tu connais une machine capable de faire ça ? et bien, aucune .

Touko l'a amenée dans la conversation pour expliquer comment l'effet de BTL était réalisé

J'ai rien ammené du tout, je t'ai juste montré que pas besoin de précalc pour faire l'effet .Cependant a ton habitude, tu déformes les propos, j'ai jamais dit que l'amiga ou la PCE changeaient le scrolling sur X au pixel, toi oui .
Par contre j'ai affirmé clairement que la courbure sur PCE était faite en modifiant le scroll X à la ligne, et c'est le cas.

[rocky007]

Déjà, tu connais une machine capable de faire ça ? et bien, aucune .

oh bien on dirait que la nuit t'a porté conseil..
donc on passe de " je te l'ai expliqué 4 pages avant " à "aucune machine n'est capable de le faire"    trop fort

J'ai rien ammené du tout, je t'ai juste montré que pas besoin de précalc pour faire l'effet .Cependant a ton habitude, tu déformes

ça fait 5 pages que je te demandes comment tu fais la déformation X comme dans BTL. et donc aujourd'hui tu me dis que ce n'est plus possible sur PC Engine alors que hier "tu m'avais expliqué et que j'étais trop con pour trouver la réponse dans les pages ?"

et pour preuve que je ne déforme pas, je te cite à nouveau :

Ca change rien du tout, puisque le but est de modifier les registres de scrolling à chaque ligne, que tu le fasses sur X, Y ou X/Y ne change rien

propos, j'ai jamais dit que l'amiga ou la PCE changeaient le scrolling sur X au pixel, toi oui .

ah bon ? où cela ?  tu peux citer ?  au contraire, je t"expliques qu'il faut 11 étapes de précalcul...ce que tu ne comprends toujours pas  


tu sais à qui tu me fais penser

[youki]

Déjà, tu connais une machine capable de faire ça ? et bien, aucune .

oh bien on dirait que la nuit t'a porté conseil..
donc on passe de " je te l'ai expliqué 4 pages avant " à "aucune machine n'est capable de le faire"    trop fort

bon je m'excuse si je suis a coté de la plaque , j'ai pas trop suivi votre "débat"...  mais si c'est ce à quoi je pense ,   je pense que sur une Lynx ou une NEO GEO , ca doit être possible.

[rocky007]

en fait ce serait possible sur n'importe quel machine avec scroll hardware
la différence avec l'Amiga, c'est que le Copper fait le changement de position gratuit, alors que sur les autres machines il faudra utiliser une interruption pour se synchroniser avec le balayage, et cela aura un gros cout sur le CPU.

il faudra aussi bien sûr precalculer toutes les étapes intermédiaire entre chaque changement de position

[Copper]

bon je m'excuse si je suis a coté de la plaque , j'ai pas trop suivi votre "débat"...  mais si c'est ce à quoi je pense ,   je pense que sur une Lynx ou une NEO GEO , ca doit être possible.

C'est possible mais bon ce genre de bidouille il faut mieux tester sur la vraie machine par contre car on peut avoir des surprises...

Par exemple le scrolling vertical de la Master System ne peut pas être changé en cours de balayage d'après ce que j'ai compris...

C'est comme les sprites bufferisés qui en théorie ne peuvent pas être réutilisés sur une même ligne contrairement à ceux de l'Amiga (qui ne sont pas bufférisés)

[touko]

Déjà, tu connais une machine capable de faire ça ? et bien, aucune .

oh bien on dirait que la nuit t'a porté conseil..
donc on passe de " je te l'ai expliqué 4 pages avant " à "aucune machine n'est capable de le faire"    trop fort

J'ai rien ammené du tout, je t'ai juste montré que pas besoin de précalc pour faire l'effet .Cependant a ton habitude, tu déformes

ça fait 5 pages que je te demandes comment tu fais la déformation X comme dans BTL. et donc aujourd'hui tu me dis que ce n'est plus possible sur PC Engine alors que hier "tu m'avais expliqué et que j'étais trop con pour trouver la réponse dans les pages ?"

et pour preuve que je ne déforme pas, je te cite à nouveau :

Ca change rien du tout, puisque le but est de modifier les registres de scrolling à chaque ligne, que tu le fasses sur X, Y ou X/Y ne change rien

propos, j'ai jamais dit que l'amiga ou la PCE changeaient le scrolling sur X au pixel, toi oui .

ah bon ? où cela ?  tu peux citer ?  au contraire, je t"expliques qu'il faut 11 étapes de précalcul...ce que tu ne comprends toujours pas  


tu sais à qui tu me fais penser

Bon écoute, j'arrête avec toi, ça devient pénible de lire tes élucubrations .Tu n'arrêtes pas de déformer les propos et de les adapter comme cela te chante .
Bref ,tu es clairement le sosie de zarchos, je comprends maintenant pk tu le prends comme modèle,vous avez exactement les mêmes façons de procéder avec vos interlocuteurs . 

[rocky007]

mais qu'est ce que je déforme ? 

Non mais arrêtes là tu es ridicule, je te parle de faire l'effet en temps réel, a la volée, le composant utilisé on s'en branle, ça n'a strictement aucun rapport puisque le principe est de modifier chaque ligne sur X/Y pendant l'affichage, arrêtes de t'accrocher aux branches pour pas passer pour un con .
Le but est de te démontrer que c'est du temps réel, point barre .

IL N'Y A AUCUN PRECALCUL GRAPHIQUE, puisque c'est ce que tu nous sors depuis 8 ans.

donc expliques moi comment tu fais cette déformation X sur PC Engine

ou alors arrêtons et admet simplement que tu t'es permis de m'insulter gratuitement alors que tu ne savais pas de quoi tu parlais.
tu fais décidement une fixation sur Zarchos, il a dû aussi sévèrement te traumatiser..

[Schmurz]

Par exemple le scrolling vertical de la Master System ne peut pas être changé en cours de balayage d'après ce que j'ai compris...

Pour faire simple le HUD de la SMS emmerde son monde.

Vers 57 minutes de la vidéo



Édit : n'empêche faire 5 pages sur un rouleau d'un jeu osef de nos jours faut vraiment le vouloir 

[Copper]

Quelques infos ici

BTW my proudest achievement was in the mini-games - the rotating crystal platforms on the 'mode 7' rotating tunnel backdrop. It was a demo effect I coded, and when my boss saw it he just wanted to include it, so we came up with those mini-games purely as an afterthought. Took a lot of fiddling to get the timing right, as it was using 6 bit-planes and you needed to update the scrollregister every ~16 pixels to hardware scale each line independently (with some pre-scaling as we could only shrink a line by 1-16 pixels) - and I had to re-do it all for the AGA version.

[touko]

Par exemple le scrolling vertical de la Master System ne peut pas être changé en cours de balayage d'après ce que j'ai compris...

Pour faire simple le HUD de la SMS emmerde son monde.

Vers 57 minutes de la vidéo



Édit : n'empêche faire 5 pages sur un rouleau d'un jeu osef de nos jours faut vraiment le vouloir 

Oui car la SMS ne peut pas changer les valeurs du scroll vertical pendant l'affichage, les regs sont bloqués .

Quelques infos ici

BTW my proudest achievement was in the mini-games - the rotating crystal platforms on the 'mode 7' rotating tunnel backdrop. It was a demo effect I coded, and when my boss saw it he just wanted to include it, so we came up with those mini-games purely as an afterthought. Took a lot of fiddling to get the timing right, as it was using 6 bit-planes and you needed to update the scrollregister every ~16 pixels to hardware scale each line independently (with some pre-scaling as we could only shrink a line by 1-16 pixels) - and I had to re-do it all for the AGA version.

Merde, ça confirme juste ce que je dis, c'est con pour rocky encore une fois 
J'avais bien dit aussi(en plus du zoom hard avec les scrolls X/Y) que l'amiga ne pouvais modifier le scroll X que tous les 8 voire 16 pixels qd rocky nous expliquait que c'était tous les pixels .
Il peut déjà aller rejoindre son modèle zarchos, a eux 2 ils arriveront peut être à comprendre 1 truc un jour . .

Pirouette de rocky dans 3......2.........1  

[stapha92]

Je croyais que tu demandais pourquoi ils n'utilisaient pas de plate-forme dans les tableaux classiques.

jolie pirouette , très artistique ... je t'ai posé plusieurs fois la question, mon 1er post de 2015 à ce sujet était même "vu qu'il y a qu'une seule plateforme, cela sous entend qu'il y a du precalc"...

Rocky ment encore... 

Quand à son premier post, c'était ça :

euh, encore une fois tu as l'air bien sûr de toi... moi tout ce que je vous, c'est un fond précalculé, ainsi qu'une plateforme précalculée également. Et rien du tout infaisable sur ST. Le shoot ? qu'y a-t-il de spéciale ? Le parallax précalculé comme on en faisait sur St depuis la Union Demo ?

Rocky nous dit clairement que:
- Tout est entièrement précalculé.
- Même le parallaxe du shoot est précalculé.
- Faisable sur ST
3 erreurs en 2 lignes...

Continuons sur la faisabilité sur ST. Rocky nous a fait une belle démonstration dans laquelle il a juste oublié pleins de choses :.
- 4 couleurs sur les 7. Donc il a prévu 2 plans au lieu de 3.
- Le masque. C'est 2 plans au lieu de 4 en fait... La façon dont il a essayé de s'en sortir en parlant du Dual playfield (il voulait soi disant prouver que l'effet est possible sur Amiga...) tout en oubliant que ses patterns se chevauchent, ce qui rend le masque obligatoire sur Amiga comme sur ST. Comme toujours : tout est facile et se fait tout seul dans son discours. 

Très drole la pirouette : montrer la faisabilité sur Amiga d'un truc qui existe sur... Amiga ! Faut douter de rien...

En tout cas, les 153 Ko viennent de doubler...

Mais c'est pas tout. Il a aussi oublié :
- Que quand on incline un rectangle, ça augmente sa largeur...Le 64 devient 80 et même 96 quand l'inclinaison est plus forte. On va dire 80 pixels de large en moyenne au lieu de 64 . Je suis sympa : je compte même pas la hauteur (car le nombre de lignes augmente aussi. Mais de 1 en 1 et non par palier de 16)
 - 5 patterns sur les 6 qu'il faudrait. 

On passe encore à plus du double...

La plateforme stockée en un bloc avec tous les angles précalculés a besoin de 600 Ko, est beaucoup plus rapide à manipuler et n'a plus de problème de rendu qu'auraient ses patterns...

J'adore les bonne idées de Rocky : c'est moins bien mais c'est plus cher !

Et il a oublié le preshift. Qui multiplie par plus de 16 la taille mémoire. Rien que ça...

Ne parlons pas de son miroring en X : il ne lui faisait rien gagner dans ses calculs, à cause de la table de 128 Ko qu'il a complètement oublié (encore !). Par contre, ça fait perdre énormément de temps. Là pour s'en sortir, il a fait 2 pirouettes :
 - Il a affirmé qu'il parlait de 32 lignes. Y a pas une seule fois le nombre 32 dans sa démonstration et son calcul est fait avec 16 lignes mais il prétend qu'il parlait de 32 lignes. Ok...

Donc on double la taille du tube et on ajoute 128 Ko. On passe de 128 à 384 Ko...

 - il a expliqué qu'il faisait le mirror X sur 1/4 de l'écran. IL s'était pas rendu compte que ça marche pas...

Donc on oublie le mirror X : on serait à 16 i/s pour le tube seul. Et ça ne s'appelle pas reproduire...

On est a combien de RAM pour sa version qui n'a "rien d'infaisable sur ST" ? 12 Mo ? 16 Mo ?

Dois-je rappeler que l'ordinateur soi disant "plus pro et plus polyvalent" ne peux avoir plus de 4 Mo, même avec un fer à souder ?
Tandis que ça ne pose pas de problème à notre "console à disquette"...


Ps : Moi aussi je peux parler de toi à la troisième personne Rocky...

as-tu répondu une seule fois en 8 ans à cette question "oui il y a des étapes precalc" ? non jamais, tu pensais que tout était fait en temps réel.  pourtant tu as eu largement l'occasion d'évoquer ce détail.  De plus tu prétendais même que Brian The Lion tournait sur 512ko

Ah bon j'ai vraiment dit 512 Ko ? M'en rappelle pas mais j'y reviendrai...

Tu n'a jamais demandé s'il y avait des étapes de précalc. Tu n'as pas demandé si c'était du précalc non plus. Tu as juste affirmé. Comme d'hab.

La rotation utilise un système qui génère des artefacts qui deviennent visibles quand l'angle de rotation est trop élevé. L'idéal étant d'avoir une image par octant.
Pour faire tourner (sans zoom...) correctement une image plein écran en 16 couleurs (32 Ko). Il faut donc 8 x 32 = 256 Ko.
On peut alors faire une rotation sur 1024 frames. Donc sur 1024 frames, il y en a 8 que l'on prend telles quelles. 0,8 %...

Faisons une analogie :
Rocky fait 10 Km en voiture pour aller chez un pote.
Il se gare à 80 mètres de la destination et marche jusqu'à la porte.
Son pote lui demande "comment t'es venu ?"
Rocky répond "à pied"...

C'est la même proportion...

et la seule réponse à "pourquoi d'après toi il n'y a qu'une plateforme" ta réponse a été "je sais pas, pour garder les 16 couleurs ?" alors que la bonne réponse "il n'y a pas assez de mémoire pour en mettre une deuxième"...mais vu que tu l'ignorais..

Ah mais alors je te pose la même question dans l'autre sens : les 2 autres tableaux de bonus n'ont pas de plateforme. pourquoi n'y a-t-il pas beaucoup plus d'éléments alors ? Après tout ça fait 700 Ko d'économie d'après toi...

surtout qu'on n'arrête pas de débattre de la taille mémoire nécessaire pour faire tenir cela sur un ST, et pas une seule fois tu as évoqué que ça bouffait 700ko sur Amiga.  Tu es juste d'une mauvaise foi dépassant tout ce que j'ai pu lire ici.

Tiens donc ?! La taille mémoire pour faire tenir ça sur un ST ? Mais tu as oublié ton mensonge ou tu affirmes, pour essayer de "sauver ta face", que tu parlais de le faire tenir sur Amiga...
Tu te rappelles ? Le mensonge que tu as sorti quand je t'ai rappelé qu'il fallait préshifter entre autres.
Tu me diras, c'est bien de te rendre compte que ce mensonge est inutile puisque pour tout le reste, ta démonstration est aussi bancale sur Amiga que sur ST. 

Avec toi tout est facile : pas de masque, pas de préshift, 5 patterns oubliés, 4 couleurs disparues, un mirroring X magique, une solution avec un rendu dégueu qui tournerai au ralenti...

Non ce n'est pas du précalc, c'est genant que tu ne t'en rendes pas compte....

ce qui est gênant c'est que c'est moi qui te l'apprends après 8 années que tu crois à du temps réel  
inutile encore de me faire passer pour un con, j'ai clairement indiqué que ce sont des étapes précalculées et que ce n'est pas toute l'animation.

Tu penses vraiment m'apprendre des choses ?
Je sais qu'il y a des étapes depuis que je sais que c'est du temps réel. Tout simplement car l'auteur a tout expliqué dans une interview quand le jeu est sorti. Il a quand même utilisé le terme temps réel et personne ne lui a dit 'mais vous venez de dire qu'il y a des étapes de précalc". Et le système the BTL a été commenté et expliqué des dizaines de fois et PERSONNE n'a jamais remis en cause le fait que ce soit du temps réel. Et il y a des gens très doués dans le tas.

Tu es la seule personne sur le net à dire que c'est du précalc. Soit tu es un génie, soit...

j'espère que tu est d'accord un logo stocké en RAM à différents angles,  cela s'appelle bien du pré calcul ?

ça ne veut pas dire que la rotation est du precalc. Enfin pour tout le monde sauf toi.

mais le pire n'est pas là : tu nous expliques que la rotation d'une image de 32 Ko sur 360° a besoin de 800-900 Ko de precalc et que la rotation d'une plate-forme de 8 Ko sur 100° a besoin de 600-700 Ko ? Y a pas un truc qui cloche ?

ah ? où ais-je indiqué cela ?  tu as beau inventer des textes sorti de nulle part pour me décrédibiliser et sauver ta face, ça ne marchera pas...cites moi ce passage qu'on rigole

Ah mais s'il n'y a que ça pour te faire plaisir :

S'il n'y a qu'une et unique plate forme qui fait une rotation c'est tout simplement par qu'elle prend au moins 6-700ko de RAM et qu'il n'y juste pas assez de place mémoire pour en caser d'autres.  

Les 800-900 ça représente le max de mémoire dispo dans l'intro.
Mais je vais le dire autrement :
Tu prétends que la pateforme prend "au moins" 600-700 Ko alors que son image prend 8 Ko et qu'elle n'éffectue qu'1/4 de tour. Mais dis moi, combien doit prendre la rotation de l'intro qui se fait sur une image 4x plus grande ? "au moins 2400-2800 Ko ? Et si tu ajoutes le fait qu'elle fait une rotation entière et qu'elle ajoute du zoom, on est à combien ?

Bon, je vais t'apprendre et te prouver quelque chose. Tu vas pas aimer parce que tu le répète sans arret depuis plusieurs jours avec des emojis dans tous les sens : 

LA PLATEFORME NE PEUT PAS FAIRE 600-700 KO, C'EST IMPOSSIBLE !

Parce qu'elle est dessinée avec le blitter et le copper, ce qui oblige à avoir tout en chipram. Or, toi qui t'amuse tant avec WinUAE, lance le avec 512 K de chip seulement (+512 k de fast ou slow) et tout fonctionne parfaitement ! Par défaut, WinUAE se lance comme ça. Tu as peut-être déjà testé sans savoir...

Ce n'est pas ça que j'aurai dit quand j'ai parlé de 512 Ko ?

Sur les 512 Ko de chip, il y a un écran en dual playfield de 320x206. En double buffer, ça prendrait déjà 100 Ko.
Le problème est que l'écran prend bien plus. En largeur il fait 336 pixels (et ils sont tous lus) mais le scrolling en fait disparaitre.
En hauteur c'est pire : le copper écarte pleins de lignes pour la partie verticale du zoom.

Il faut ajouter la copperlist, qui fait plusieurs dizaine de Ko.
Il faut les samples de musique et de bruitage.
Il faut les frames du perso : plus de 210 frames de 32*50 en 16 couleurs. ça fait 170 Ko. Allez on va supposer qu'ils n'ont gardé que les frames utiles pour le niveau et ont stocké les autres en fast.

S'il reste 300 Ko pour la plateforme et le tube c'est déjà un exploit...

Puisque tu prétends m'apprendre des choses, tu m'expliques comment tu cases ta plateforme d'"au moins 600-700 Ko" + le tube dans 300 Ko ?

Et donc les codeurs de BTL, qui sont vraiment des bons, ont besoin de 600-700 Ko par plateforme alors que toi tu as prétendu pouvoir le faire avec 128 Ko. Tu devrais aller leur montrer. A eux et à tous les codeurs ST. Car, précalc ou pas, on n'a jamais vu une rotation sur une image en 320x200x16 et en 1x1 dans les démos ST...

donc tu n'es pas d'accord avec mon calcul :

100 étapes , 100x100 pixels, 7 couleurs = 375 ko ?

Je me moque de ce calcul. Tu as annoncé qu'il fallait 128+153 tube + plateforme. Point barre. Et tu viens dire derrière que les gars de Reflexion ont besoin de "au moins 600-700 Ko" juste pour la pateforme.

Et c'est quoi ton 100x100 ? C'est la taille de quoi ? La plateforme fait 1/4 d'écran d'après toi (en fait plus que ça mais bon...), pourquoi tu pars pas sur 160x100 ?

Ah ben on avance ! Il y a 3 jours tu disais ça :

bref on arrive à 153+128ko, soit 281ko tube+plateforme

Tu passes de "128 Ko" à "moins de 400 Ko" en 3 jours !

tu es à ce point incompétent ?  si tu sors les chiffres du contexte dans lesquels ils étaient donné, forcément ça tourne pas très rond dans ta tête...

si je te donne un chiffre en 4 couleurs 160x100, ce n'est pas la même chose que 16 couleurs 320x100.. tu comprends ?  il n'y a pas que les chiffres, il y a le texte qui va autour...

Sauf que t'as jamais parlé de 16 couleurs... Et que tu es toujours resté sur 160 pixel de large, croyant que ton mirror X tenait la route...

[touko]

Rocky nous dit clairement que:
- Tout est entièrement précalculé.
- Même le parallaxe du shoot est précalculé.
- Faisable sur ST
3 erreurs en 2 lignes..

Clairement il a l'art de faire oublier ses conneries en te prenant de haut et pour un con,sans oublier de modifier subtilement ses propos et dire carrément le contraire de ce qu'il disait 5 mins auparavant .

Faisons une analogie :
Rocky fait 10 Km en voiture pour aller chez un pote.
Il se gare à 80 mètres de la destination et marche jusqu'à la porte.
Son pote lui demande "comment t'es venu ?"
Rocky répond "à pied"...

C'est exactement ça .

[Copper]

Pour faire simple le HUD de la SMS emmerde son monde.

Vers 57 minutes de la vidéo

Oui j'avais déjà vu cette vidéo...

[stapha92]

Rocky nous dit clairement que:
- Tout est entièrement précalculé.
- Même le parallaxe du shoot est précalculé.
- Faisable sur ST
3 erreurs en 2 lignes..

Clairement il a l'art de faire oublier ses conneries en te prenant de haut et pour un con .

Le plus drole c'est quand il va voir que ça tourne avec 512 Ko de chip. Il explique en sautant partout qu'elle prend au moins 600-700 Ko alors qu'il doit rester 300 Ko de chip pour la plateforme et le tube.

Après, s'il reconnait que, ce n'est pas possible effectivement, ben le débat seras clos. Et s'il veut rester le seul à penser que c'est du précalc, libre à lui.

On peut demander aux dev de faire une version en 25 fps : ça donnera plus de temps qu'il n'en faut pour calculer la prochaine étape pendant la rotation et tout le monde sera d'accord !

[touko]

Le plus drole c'est quand il va voir que ça tourne avec 512 Ko de chip. Il explique en sautant partout qu'elle prend au moins 600-700 Ko alors qu'il doit rester 300 Ko de chip pour la plateforme et le tube.

J'avoue que prendre l'intro, pour justifier ce qu'il dit sur le tube, là respect .

Après, s'il reconnait que, ce n'est pas possible effectivement, ben le débat seras clos. Et s'il veut rester le seul à penser que c'est du précalc, libre à lui.

Exact .

Et le système the BTL a été commenté et expliqué des dizaines de fois et PERSONNE n'a jamais remis en cause le fait que ce soit du temps réel. Et il y a des gens très doués dans le tas.

C'est exactement ce que je lui ai démontré avec les codeurs sur EAB, personne ne parle de précalc, mais bien de temps réel aussi .Sauf notre seconde star nationale, rocky . 

[Copper]

Je me demande quand même comment ils font pour le scrolling du premier plan vu que BPLCON1 modifie le scrolling pour les 2 plans en même temps... En théorie j'imagine bien qu'on peut faire 16 morceaux de Copperlist avec une vingtaine de changements de BPLCON1 pour gérer les différents cas (et ensuite appeler ses différents morceaux avec des COPJMP1 même si c'est un peu lourdingue sans "COPRET" que l'on peut toutefois simuler avec COPJMP2)

[stapha92]

Je me demande quand même comment ils font pour le scrolling du premier plan vu que BPLCON1 modifie le scrolling pour les 2 plans en même temps... En théorie j'imagine bien qu'on peut faire 16 morceaux de Copperlist avec une vingtaine de changements de BPLCON1 pour gérer les différents cas (et ensuite appeler ses différents morceaux avec des COPJMP même si c'est un peu lourdingue sans "COPRET")

Moi non plus je ne vois pas comment ils ont fait. La copperlist doit être trop longue pour en faire 16 versions. Mais va savoir...

[touko]

Demandez à rocky  

Ah non, on me dit qu'il n'est pas dispo pour le moment :

[stapha92]

Qu'est-ce que tu comprends pas dans "il n'y a jamais eu de texte caché dans les bordures de l'overscan" ?

bon je t'explique, c'est simple : si ton moniteur est réglé pour que par exemple ton 320x200 s'affiche avec le minimum de bordure, lorsque tu passeras en overscan, une partie de l'écran ne sera pas visible..

1) Donc l'impossibilité d'avoir un overscan est un avantage dans le monde ST. Belle pirouette...
2) Et ceux qui n'avait pas un écran avec des réglages de taille, ils faisaient comment ? Quand même dommage d'avoir bureau de 10 pouces sur un écran de 14...
3) Sur ST, on augmente la taille des pixels. Sur Amiga, on augmente le nombre de pixels....

Non : afficher des fichiers qui ne te servent à rien n'a aucune utilité. L'Amiga n'affichait que ce qui t'était utile. Si tu voulais bidouiller, tu avais le cli, infiniment plus puissant.
Même quand le workbench a eu l'option pour tout afficher, elle n'était pas activée par défaut.

Tout comme windows qui, par défaut, n'affiche pas pleins de fichiers...

on en a déjà discuté, cela ne prouve qu'une fois de plius ta mauvaise foi... c'est totalement ridicule d'être obligé d'avoir une icône associée à chaque nom de fichier. sur Windows, c'est exactement l'inverse, on ne cache que les fichiers que l'ont désire  ( excepté bien sûr les fichiers systèmes ).

Ah bon ? Il y avait des fichier système et des fichiers cachés sur ST ? Quand à windows, quand j'ai trop de fichiers, je ne les cache pas mais je les regroupe dans des répertoires. Faut dire que :
- Je peux créer autant de répertoire que je veux. Comme sur Amiga et contrairement au ST.
- Je peux y déplacer des fichiers. Comme sur Amiga et contrairement au ST.
- J'ai des fichiers avec des noms lisibles. Comme sur Amiga et contrairement au ST.
- J'ai des tas d'icones différentes. Comme sur Amiga et contrairement au ST

Et encore une fois : sur Amiga, tu avais le cli. Sur ST, tu restais coincé...

Et on te croit  : ça ne sert à rien de renommer un répertoire ou de déplacer des fichiers. On réorganise jamais le contenu de ses D7 sur Atari. On préfère le bordel...

avec 720ko t'es pas prêt un tel bordel...perso je faisait du rangement 3-4x par annéecomparé à 50 directory par jour...

Ah je comprend mieux maintenant : tu regardais le contenu de tes répertoires 50 fois par jour. C'est sur qu'avant de lancer le GFA, il fallait vérifier que tous les fichiers étaient là. Trrrrrrrrrrrrrès utile...

Perso, sur mon ST, il m'est arrivé plus d'une fois de devoir copier des fichiers sur une autre disquette, effacer les originaux avant de refaire la copie dans l'autre sens. Tout ça juste pour les déplacer. En priant pour ne pas avoir un problème et perdre mes fichiers (ce qui ne m'est jamais arrivé, merci à mon brave ST).
Par contre, plus d'une fois j'ai du chercher un petit moment ou était le fichier à lancer. Jamais sur Amiga...

Tu te fais encore avoir par les pubs Atari ?
Ça ne t'a pas servi de leçon le mensonge sur les 7 coprocesseurs (dont j'attend toujours la liste...) ? Ou celui sur l'étonnante rapidité qu'on a pu admirer quand on a vu le GEM se fait exploser par l'Amiga dans un petit programme GFA...

en parlant de publicité mensongère, Amiga était pas mal non plus... jaloux à mort du Falcon et du boulot de merde sur le A1200, ils n'hésitaient pas à tromper le client :  " empl. DSP"....   la belle carotte...

Tu as cherché longtemps ? Parce que tu as du te rabattre sur le 1200 dans un fight ST vs Amiga...

Euh... Tu réalises que c'est la pub de revendeurs et pas une pub de commodore ? Tu saisis pas la différence ?

Commodore a communiqué sur l'ajout d'un DSP dans le nouveau chipset. Ils ont abandonné l'idée, d'où la confusion. Il y a d'ailleurs des A3000 avec un DSP fonctionnel qui ont été retrouvés. La preuve que ça a bien été étudié et que c'est bien un abandon et non un mensonge éhonté...

Si je cherche, je ne trouverai pas des pubs qui prétendent que le Falcon est une machine 32 bits ? un peu plus grave que l'absence d'un emplacement...

Et Atari (et non un revendeur) n'a pas indiqué que le Falcon avait un mode True Color APRES sa commercialisation ? Alors qu'il n'a même pas une palette de 24 bits. J'ai lu une critique acerbe sur ce point dans le premier test du Falcon que j'ai lu. 

Il y a une autre erreur dans tes pubs : le HAM8 est donné pour 262000 couleurs alors qu'en fait c'est 16 millions. Il y avait aussi une confusion là-dessus : il avait été indiqué qu'en HAM, les 2 bits de poids fort dans la palette n'étaient pas pris en compte alors qu'en fait si. Tu peux donc avoir un dégradé avec 256 variations de la même couleur et non 64 seulement. Comme quoi les erreurs ne sont pas toujours assimilables à une escroquerie.

Atari, dans ses pubs, précisait que le "True color" n'existait pas dans toutes les résolutions ? Juste un oubli sans doute...

oui en effet GEM est vachement plus rapide que le WB.  J'ai fait une vidéo de manipulation de fenêtre dans WB VS Atari ( tu la retrouveras plus haut ), c'était juste une catastrophe, de mémoire ça avait même terminer par un Guru Meditation

Pas besoin de ta vidéo. Merci.
Moi j'ai fait un truc que tout le monde peut reproduire avec le GFA et qui montre l'écart monstrueux entre le GEM et le WB.

Et on parle du GFA, écrit pour le ST et juste adapté sur Amiga. D'ailleurs, dans l'exemple que je donne, si tu n'ouvres pas la fenêtre GEM, le GFA va travailler sur un écran, ce qui bien plus rapide. Bon boulot des codeurs qui avaient du voir, eux, que le GEM était lent.
Ils n'ont pas fait ça sur Amiga. Pas besoin...

Comme quoi la pub mensongère d'Atari a bien fonctionné sur toi...

Et tes vidéos, on connait tous les petits "problèmes" qu'elles rencontrent... Quand elles ne sont pas trafiquées...

Comme la vidéo de chaos engine que tu as produit pour prouver que la version ST était plus colorée que celle sur Amiga. Tu étais tout fier à l'époque (et tu as pris de haut je ne sais qui)... Sauf que la vidéo était sur SNES ! Pourtant ça se voyait que ce n'était pas sur ST : c'était fluide...

Ou l'une des fameuses vidéo que personne n'a jamais vu sur un vrai ST mais que tu as affirmé avoir testé sur ta machine.
Tu avais prévu de nous montrer ça pour me faire fermer mon clapet. On attend encore...

Donc laisse les gens constater la lenteur du GEM tous seuls et concentre toi sur celle que tu dois nous montrer...

[touko]

Il y a une autre erreur dans tes pubs : le HAM8 est donné pour 262000 couleurs alors qu'en fait c'est 16 millions. Il y avait aussi une confusion là-dessus : il avait été indiqué qu'en HAM, les 2 bits de poids fort dans la palette n'étaient pas pris en compte alors qu'en fait si. Tu peux donc avoir un dégradé avec 256 variations de la même couleur et non 64 seulement. Comme quoi les erreurs ne sont pas toujours assimilables à une escroquerie.

Effectivement, je m'étais posé la question pk sur OCS le HAM permettait d'afficher toute la palette, et pas sur AGA, bon j'ai la réponse . 

A votre avis rocky est :

A - Parti prendre sa retraite au camping des flots bleus avec zarchos.
B - A force de creuser, s'est marié avec rené la taupe pour visiter les galeries qu'il creuse ici depuis 15 ans .
C - Cherche encore où sont les 700ko de précalc dans les 512 ko de chipram.

[Copper]

Moi non plus je ne vois pas comment ils ont fait. La copperlist doit être trop longue pour en faire 16 versions. Mais va savoir...

Disons que ça ferait environ 320 BPLCON1 à modifier pour le scrolling du premier plan... La taille de la copperlist je sais pas par rapport à faire des boucles avec SKIP... C'est vrai que ça fait pas mal de COPJMPx et COPxLC en plus par contre (il est possible d'éviter des COPxLCH si on aligne la copperlist sur 64Ko)

[stapha92]

Moi non plus je ne vois pas comment ils ont fait. La copperlist doit être trop longue pour en faire 16 versions. Mais va savoir...

Disons que ça ferait environ 320 BPLCON1 à modifier pour le scrolling du premier plan... La taille de la copperlist je sais pas par rapport à faire des boucles avec SKIP... C'est vrai que ça fait pas mal de COPJMPx  et COPxLC en plus par contre (il est possible d'éviter des COPxLCH si on aligne la copperlist sur 64Ko)

Je me disais qu'il y a entre 0 et 16 modif de bplcon1 par ligne. donc 8 en moyenne x 200  = 1600 BPLCON1
Mais avec 320, ça semble jouable de les modifier au cpu.

[youki]

Il y a une autre erreur dans tes pubs : le HAM8 est donné pour 262000 couleurs alors qu'en fait c'est 16 millions. Il y avait aussi une confusion là-dessus : il avait été indiqué qu'en HAM, les 2 bits de poids fort dans la palette n'étaient pas pris en compte alors qu'en fait si. Tu peux donc avoir un dégradé avec 256 variations de la même couleur et non 64 seulement. Comme quoi les erreurs ne sont pas toujours assimilables à une escroquerie.

Effectivement, je m'étais posé la question pk sur OCS le HAM permettait d'afficher toute la palette, et pas sur AGA, bon j'ai la réponse . 

A votre avis rocky est :

A - Parti prendre sa retraite au camping des flots bleus avec zarchos.
B - A force de creuser, s'est marié avec rené la taupe pour visiter les galeries qu'il creuse ici depuis 15 ans .
C - Cherche encore où sont les 700ko de précalc dans les 512 ko de chipram.

Pourquoi 700kà de précal?    D'apres ce que je vois dans le tunnel , c'est une meme pattern qui se repete. il suffirait de precalculer juste pour chaque position de la pattern , par pour l'image entiere.  On serait a bien moins de 700k je pense.

[Copper]

Le fait d'avoir les 2 valeurs de scrolling horizontal dans un même registre n'aide pas dans ce cas de figure malheureusement (on peut pas tout prévoir)

[babsimov]

Commodore a communiqué sur l'ajout d'un DSP dans le nouveau chipset. Ils ont abandonné l'idée, d'où la confusion. Il y a d'ailleurs des A3000 avec un DSP fonctionnel qui ont été retrouvés. La preuve que ça a bien été étudié et que c'est bien un abandon et non un mensonge éhonté...

Ah bon, un 3000+ fabriqué par Commodore aurait été retrouvé avec le DSP fonctionnel ? J'ai pas entendu parler de ça.

Par contre la carte mère a été refaite (le AA3000+) avec quelques modifications. Il me semblait que ça avait été fait à partir de plans des cartes mères originales et non d'un A3000+ d'époque fonctionnel. 
Le DSP n'était pas fonctionnel sur le AA3000+, mais il a été rendu fonctionnel par des fans à partir des librairies de gestion du DSP développées par Commodore à l'époque. Elles ont été retrouvé par l'intermédiaire des disquettes système d'un appareil d'échographie qui embarquait une carte mère de 4000 et une carte avec plusieurs DSP 3210. Ensuite le développeurs a participé au forum sur le sujet et donné encore plus de sources et infos.

http://obligement.free.fr/articles/dsp3210_genese_amiga.php

Je me trompe ? En tout cas si tu as un lien vers des photos ou articles sur ce 3000+ original Commodore, je suis preneur.

Merci.

[stapha92]

Commodore a communiqué sur l'ajout d'un DSP dans le nouveau chipset. Ils ont abandonné l'idée, d'où la confusion. Il y a d'ailleurs des A3000 avec un DSP fonctionnel qui ont été retrouvés. La preuve que ça a bien été étudié et que c'est bien un abandon et non un mensonge éhonté...

Ah bon, un 3000+ fabriqué par Commodore aurait été retrouvé avec le DSP fonctionnel ? J'ai pas entendu parler de ça.

Par contre la carte mère a été refaite (le AA3000+) avec quelques modifications. Il me semblait que ça avait été fait à partir de plans des cartes mères originales et non d'un A3000+ d'époque fonctionnel. 
Le DSP n'était pas fonctionnel sur le AA3000+, mais il a été rendu fonctionnel par des fans à partir des librairies de gestion du DSP développées par Commodore à l'époque. Elles ont été retrouvé par l'intermédiaire des disquettes système d'un appareil d'échographie qui embarquait une carte mère de 4000 et une carte avec plusieurs DSP 3210. Ensuite le développeurs a participé au forum sur le sujet et donné encore plus de sources et infos.

http://obligement.free.fr/articles/dsp3210_genese_amiga.php

Je me trompe ? En tout cas si tu as un lien vers des photos ou articles sur ce 3000+ original Commodore, je suis preneur.

Merci.

Il faudra que je retrouve mais il s'agissait de prototypes d'A3000 avec un DSP si je me souviens bien. Il n'y a rien d'extraordinaire mais ça montre que Commodore travaillait dessus.

Par contre j'ignorais que les librairies avaient été développées. J'avais cru comprendre que c'était leur développement que Commodore ne voulait pas faire. Pourquoi ne pas avoir proposé de carte DSP en option ?
Même si je n'était pas plus fan que ça de DSP, ça aurait été une option très intéressante pour beaucoup.

Décidément, Commodore continue à me surprendre dans le mauvais sens du terme...

[babsimov]

Commodore a communiqué sur l'ajout d'un DSP dans le nouveau chipset. Ils ont abandonné l'idée, d'où la confusion. Il y a d'ailleurs des A3000 avec un DSP fonctionnel qui ont été retrouvés. La preuve que ça a bien été étudié et que c'est bien un abandon et non un mensonge éhonté...

Ah bon, un 3000+ fabriqué par Commodore aurait été retrouvé avec le DSP fonctionnel ? J'ai pas entendu parler de ça.

Par contre la carte mère a été refaite (le AA3000+) avec quelques modifications. Il me semblait que ça avait été fait à partir de plans des cartes mères originales et non d'un A3000+ d'époque fonctionnel. 
Le DSP n'était pas fonctionnel sur le AA3000+, mais il a été rendu fonctionnel par des fans à partir des librairies de gestion du DSP développées par Commodore à l'époque. Elles ont été retrouvé par l'intermédiaire des disquettes système d'un appareil d'échographie qui embarquait une carte mère de 4000 et une carte avec plusieurs DSP 3210. Ensuite le développeurs a participé au forum sur le sujet et donné encore plus de sources et infos.

http://obligement.free.fr/articles/dsp3210_genese_amiga.php

Je me trompe ? En tout cas si tu as un lien vers des photos ou articles sur ce 3000+ original Commodore, je suis preneur.

Merci.

Il faudra que je retrouve mais il s'agissait de prototypes d'A3000 avec un DSP si je me souviens bien. Il n'y a rien d'extraordinaire mais ça montre que Commodore travaillait dessus.

Si tu retrouves, ça m'intéresse.

A ma connaissance, c'est Dave Haynie qui avait le premier indiqué que Commodore travaillait sur le DSP. Je ne me souviens plus si c'était dès la faillite, ou s'il a mis les infos sur son site internet quelques années après.

Par contre j'ignorais que les librairies avaient été développées. J'avais cru comprendre que c'était leur développement que Commodore ne voulait pas faire.

Je ne sais pas si tu as lu le liens obligement que j'avais indiqué, mais il y a pas mal d'information sur le DSP et Commodore, notamment sa genèse.


Commodore (enfin Bill Sydnes, le sbire de Medhi Ali) a fait annuler le 3000+ (AGA et DSP) dès son arrivée. Après l'échec du 600 avec ECS et le fait que les filiales ont toute refusé son projet de nouvelle machine ECS pour 1992 (l'AGA leur avait été détaillé en 1991), il a fait reprendre les projets AGA dans la panique. Mais pour ne pas passer pour un imbécile total, il a prétendu que le DSP était une mauvaise idée, fait virer le SCSI. Bref il a fait un 3000+ au rabais qui est devenu le 4000. Dans l'histoire l'AGA a perdu 1 an.

Quand il a été viré, Lew Eggebrecht a étudié tout ça et a annoncé que pour la future génération Amiga (AA+) tous les Amiga auraient un DSP même l'entrée de gamme, mais il y a eu faillite. Les librairies et logiciels ont été montré à la DEVCON93 (avant ça restait de l'interne Commodore).

Une société tierce fan d'Amiga voulait faire un appareil d'échographie pas cher et pensait que l'Amiga avec DSP était une bonne solution. Ils ont engagé le développeur du DSP chez Commodore pour continuer le travail, adapter tout ça au 68060. L'appareil fut commercialisé avec un beau succès. Et c'est à partir de son OS que le DSP du AA3000+ a été rendu fonctionnel.

Je remet le lien 
http://obligement.free.fr/articles/dsp3210_genese_amiga.php

 Pourquoi ne pas avoir proposé de carte DSP en option ?
Même si je n'était pas plus fan que ça de DSP, ça aurait été une option très intéressante pour beaucoup.

C'était annoncé pour le 4000 et 1200. Mais ca n'a pas été réalisé. Au début le Falcon venait d'être mis sur le marché, Commodore se devait de proposer rapidement un DSP sur Amiga. Mais comme le Falcon a fait un bide et a été abandonné par Atari, Commodore a du juger qu'il n'y avait plus autant d'urgence. Et comme ils avaient déjà des problèmes de trésoreries.... le DSP fut reporté à la génération suivante.

Par contre, oui le DSP aurait été un apport non négligeable. Regarde les vidéo Youtube du lien Obligement. Pour un test mandelbrot, sans optimisation le DSP est a deux fois moins performant que la FPU du 68060... mais bon en 1991/93, ça aurait déjà été au moins aussi performant que la FPU d'un 040. Et avec optimisation, le DSP est 5 fois plus performant que la FPU du 68060, donc à l'époque ça aurait été extraordinaire.

Décidément, Commodore continue à me surprendre dans le mauvais sens du terme...

Malheureusement, Irvin Gould et la clique de Medhi Ali ont régulièrement l'habitude de nous surprendre dans ce sens là. C'est surement pas pour rien qu'il a coulé Commodore en seulement 2/3 ans 

[rocky007]

on peut donc résumer cette journée en 2 images simples :

Touko:



Stapha intervient avec son invention pour vitre effacer les conneries de Touko avec sa meilleure invention.