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

[iktos]

encore une fois on voit que tu ne connais rien au 68000 et au codé généré
ce qui est cohérent avec le fait que tu ne comprends pas pourquoi l'Amiga est supérieur à l'archi.

[The_Real_Zarchos]

Tu auras 15 couleurs ( bon c'est 16, mais je te pardonne vu ta grande bêtise )

Enorme, éééénorme, non c'est bien 15 vu que la 16 ieme, la 0 est utilisée pour la transparence de ton sprite hard.

Pas du tout.
Le sprite hard n'a que 3 couleurs ( 0 c'est pour la transparence ).
L'OP parlait de la palette 256 couleurs.
T'as toujours rien compris au film.
Les couleurs ne sont pas gérées pareil entre les modes graphiques, et le sprite hard.

[The_Real_Zarchos]

encore une fois on voit que tu ne connais rien au 68000 et au codé généré
ce qui est cohérent avec le fait que tu ne comprends pas pourquoi l'Amiga est supérieur à l'archi.

Perdu.
Toi tu ne comprends pas ce que sont les instructions de transferts registres <> mémoire sur Archie et toutes les possibilités d'optimisations quand de surcroît le 'burst mode' est utilisé par l'ARM, ce qui n'est pas le cas du 68000.

[iktos]

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.

[The_Real_Zarchos]

donc conclusion, tu dis toi même que le mode 256 couleurs de l'archi est inutilisable ????
oh my god, il avoue enfin !

même si je suis sur qu'un bon graphiste te montrerait facilement que tu as tort.

enfin bref, l'Amiga écrase l'archi coté couleurs.

Non, je dis qu'on peut avoir 3 voir 4 sélections des slots qui donnent 256 couleurs véritablement utilisables.
Ca a été détaillé sur le forum stardot.
http://www.stardot.org.uk/forums/viewtopic.php?f=29&t=3613
http://www.stardot.org.uk/forums/viewtopic.php?f=29&t=5212
Note que je ne l'ai jamais nié ( Prouve moi le contraire, c'est facile à longueur de posts de m'attribuer des propos que je n'ai jamais tenus ).

[Invité]

Tu auras 15 couleurs ( bon c'est 16, mais je te pardonne vu ta grande bêtise )

Enorme, éééénorme, non c'est bien 15 vu que la 16 ieme, la 0 est utilisée pour la transparence de ton sprite hard.

Pas du tout.
Le sprite hard n'a que 3 couleurs ( 0 c'est pour la transparence ).
L'OP parlait de la palette 256 couleurs.
T'as toujours rien compris au film.
Les couleurs ne sont pas gérées pareil entre les modes graphiques, et le sprite hard.

Au putain, de mieux en mieux   



Oui la couleur 0 c'est pour la transparence donc tu as bien 15 couleurs 1->15 et la 0 est pour la transparence et le border, donc invisible autre part que sur le border .
Donc oui en arrangeant tes gfx tu peux profiter de cette couleur, mais c'est juste une astuce, car elle n'est pas visible sinon, et ton sprite hard ne pourra jamais être derrière .

[The_Real_Zarchos]

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.

Ce n'est pas tant le problème du nombre d'instructions que celui du temps pris.
En chargement multiple mémoire vers registres ou registres vers mémoire tu bosses avec LDM et STM et la formule de calcul c'est ( simplifié ) 4 cycles pour le 1er registre + (n-1) cycles, n étant ton nombre de registres dans ta liste de transfert.
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.
Faut donc en théorie, quand tu as un sprite, établir la meilleure liste de chargement des différents segments composant tout ton sprite ( ce ne sont quasi jamais consécutivement les segments composant le sprite ).
Tu as aussi STRB avec pré offset, ou post offset
Et pour écrire tu ne vas pas toujours écrire en incrémentant dans la mémoire, ça pourra être optimal de le faire en décrémentant ( et si intéressant ou pas de faire ta mise à jour d'adresse en sortie ).
En plus tout ce qui est dans un quelconque registre dans les 8 bits de poids faible peut te servir avec STRB ( store byte ) car ce serait bien con de charger dans un registre ce que tu as déjà dans un de tes registres ( pour écrire juste 1 pixel ).
Avec l'ARM c'est aussi plus sympa ( gain de 1 cycle ) de lire ou charger à partir d'adresse mémoire multiple de 16, et puis LDR c'est mieux de l'avoir dans ton code à une adresse multiple de 16 + 4 ( économie d'un cycle ).
Evidemment tu as aussi à repérer les zones dans ton sprite qui ont les mêmes données pour ne pas les charger inutilement plusieurs fois.
Aussi quand les contenus sont proches, voir si la modif du contenu d'un ou plusieurs registres ne serait pas intéressante par rapport au fait de tout recharger.
Voilà déjà une partie du tout.
Là tu n'as qu'une partie des optimisations possibles.
ORR, ADD oui aussi tu les emploieras sauf que ADD tu pourras bcp l'éviter si tu emploies STRB avec son offset ( la mise à jour de l'adresse de destination coûte 0 cycle ).
BIC je n'en ai pas besoin, en employant une petite subtilité qui n'est décrite que dans les datasheets :-)
Les shifts je m'en sers pour les extrêmités du segment ( pas dans tous les cas ), quand je fais mon ADD ou ORR ( 1 cycle ) mais directement sur la 3è opérande ( ce shift en lui-même me coûte 0 cycle, puisqu'un shift sur registre en 3è opérande, avec une constante, est gratuit sur l'ARM  ).

[Invité]

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é mémoire à tes sprites compilés qui est aggravé dès qu'il y a des trous, sans parler des cycles supplémentaires que le fetch va te prendre pour chaque instructions sup .

[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 ?

[Invité]

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

Non mais expliques moi comment tu fais pour avoir un code optimal si tu copies 2 pixels, puis tu passes le trou, et tu recopies X pixels ??
Tu vas bien lancer 2x ton instruction de copie .
Alors que sans trou tu peux copier un max de pixels consécutifs avec 1 seule instruction, c'est pas une erreur, c'est juste de la logique.

[The_Real_Zarchos]

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

Non mais expliques moi comment tu fais pour avoir un code optimal si tu copies 2 pixels, puis tu passes le trou, et tu recopies X pixels ??
Tu vas bien lancer 2x ton instruction de copie .
Alors que sans trou tu peux copier un max de pixels consécutifs avec 1 seule instruction, c'est pas une erreur, c'est juste de la logique.

A part des cas extrêmes il n'y a pas tant de trous que ça dans les sprites.
Si ce que tu décris était si lent, jamais tu ne verrais tout ce que j'affiche dans mon WIP SOTB.
As-tu bien vu TOUT ce qui est à l'écran ?
Tu as la preuve de ton erreur de raisonnement par l'exemple.
Tu ne piges pas que ça ne coûte en fait que 3 à disons 9 cycles supplémentaires de redémarrer une écriture de segment horizontal du sprite ( selon l'offset 0 1 2 ou 3 octets de l'adresse de destination, par rapport à l'adresse multiple de 4 octets de cette adresse de destination d'écriture de ton segment ), plutôt que d'être resté en écriture séquentielle rapide à la 'burst mode'
( Je te le souligne et mets en gras pour que tu comprennes bien, car c'est capital ).
Et je t'ai vu écrire que j'affichais plusieurs fois le même personnage principal, ben non, c'est chacune des 11 séquences de son animation
( donc pas de multiplexing qui m'aurait fait économiser des cycles ).
Par contre les 2 nuages qui scrollent vite ( juste sous le Soleil ) sont eux en multiplexing, ça oui.

Je te repose la question, puisque tu veux parler de densité de code, parlons de densité de datas graphiques également  :
'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 ?

'

[rocky007]

Tu sais très bien que c'est faux. Tu n'es pas de mauvaise foi, tu es un menteur.

Je voulais même pas répondre à ton dernier post : ceux qui lisent ont bien vu qui disait n'importe quoi. Je ne cherche pas à convaincre votre secte.

oooh que c'est mignon, quand merdoz est complétement détruit, son double vient le sauver...  c'est marrant, si je voulais insulter à tout va des gens anonymement sans griller mon prestigieux pseudo, je m'y prendrais exactement comme toi, voir j'ajouterais qq pseudo de plus pour encore plus noyer le poisson et faire effet meute.  T'as un abo gold chez NordVPN ?    

sinon tu peux retourner autant de fois la situation, faire des saltos avant, arrières, du yoyo, du négationnisme, des inversion de charges, bref toutes tes techniques habituelles, tu n'éblouiras que babsinov, ton seul et unique fan... je t'ai démonté en long et en large sur tout ces points, suffit de relire...je suis pas un perroquet comme toi, je ne vais pas reperdre mon temps à ré-écrire, j'ai ma dose avec ta meute.   si t'es assez grand pour retrouver il y a 15 ans que j'ai dit "amiga , de mémoire, c'est 16 couleurs par ligne", tu sauras facilement revenir qq pages en arrière et enfin digérer ...quitte à faire exploser une hemoride

sinon, bravo pour ta découverte sur le mensonge de la pub Quantum Paint, c'est surement le point culminant de ta carrière, vu la quantité de fois que tu ressasses cela avec tellement de fierté... bravo, tu devrais le breveter.
mais tu sais de mon côté, moi aussi j'ai démoli de nombreuses publicités mensongères, comme par exemple la pub Commodore qui annonçait l'Amiga comme un ordinateur et non une console.

[The_Real_Zarchos]

Je pense que les adorateurs du mig sont en fait vexés de voir qu'ils ont été couillonnés par Commocrotte.
Pour sauver la face, ils ne peuvent que persévérer dans leur déni, au point de déifier leur ordibouse et les nullos de l'équipe à Jay l'obèse diabétique atteint du cerveau par l'excès de sucres dans le sang.

C'est une variante du syndrome de Stockholm.
Je me souviendrai toujours de leurs têtes stupéfaites quand je leur faisais une petite démonstration de RISC OS   ( le 1er, RISC OS 2, d'octobre 1988 )
C'était vraiment jouissif 
La tête de chien battu qu'ils faisaient tous, mazette, j'en rigolerai toute ma vie 
Ensuite une petite partie de Zarch, Conqueror et Chocks Away ah ah ah le coup de grâce final.

[Invité]

A part des cas extrêmes il n'y a pas tant de trous que ça dans les sprites.

Dsl mais il y a bcp de trous sur les sprites dans la vraie vie que représente un jeu, rien que le sprite de SOTB en a un bon paquet .

Si ce que tu décris était si lent, 

J'ai pas dit, si lent, j'ai dit plus lent, nuance .Forcément ce sera plus lent qu'un cas d'école, comme un sprite rond sans trous par exemple où les pixels sont contigus .

Je te repose la question, puisque tu veux parler de densité de code, parlons de densité de datas graphiques également   :

Une fois de plus tu lis et interprètes comme bon te semble,je parle pas de densité du code, mais de densité mémoire, faire des sprites compilés a un gros coût en RAM, Et plus il y a de trous, et donc le sprite est complexe, plus cette densité mémoire augmente,puisque tu vas augmenter le nb de copies de blocs de pixels .
Car forcément utiliser 10 instructions de copies, prend bien plus de RAM qu'une seule, pas besoin d'avoir fait math sup pour le comprendre .

Mais vu que tu ne produis aucun source, on ne peut même pas voir ce que prend une planche de sprites comme celle du perso principal, avec la planche classique .
Pour le demo STE, l'auteur avoue que rien que pour l'arbre en sprite, le coût mémoire est très important, alors qu'il n'a aucun pattern d'anims .

[The_Real_Zarchos]

A part des cas extrêmes il n'y a pas tant de trous que ça dans les sprites.

Dsl mais il y a bcp de trou dans la vraie vie  que représente un jeu, rien que le sprite de SOTB en à un bon paquet .

Si ce que tu décris était si lent, 

J'ai pas dit, si lent, j'ai dit plus lent, nuance .Forcément ce sera plus lent qu'un ca d'école, comme un sprite rond sans trous par exemple .

Je te repose la question, puisque tu veux parler de densité de code, parlons de densité de datas graphiques également   :

Une fois de plus tu lis et interprète comme bon te semble,je parle pas de densité du code, mais de densité mémoire, faire des sprites compilés a un gros coût en RAM, Et plus il y a de trous et donc le sprite est complexe, plus cette densité mémoire augmente .

non, ça n'a pas un gros coût en RAM.
La preuve, mon truc SOTB, même en ayant tout le source en RAM ( un fichier de plus de 600 ko vu que je commente énormément mes routines. Toutes mes routines. C'est ça qui me permet de pouvoir ne pas coder pendant des mois et reprendre sans être perdu ),
et malgré l'usage d'une sacrée résolution ( 352 x 258, en 256 couleurs, un truc impensable pour un A500 ou un A1200 stock )
et avec un module son en mémoire,
et bien tout tourne sur un Archie avec 2 Mo.
Je n'ai même pas fait d'optimisation pour les bandes qui scrollent par 2 pixels ou 4 pixels d'un coup, j'ai les 4 versions pré shiftées en mémoire, ce qui n'est pas optimal.

Je sais que tu veux absolument avoir raison, mais les faits sont que tu ne tiens jamais compte de ce que j'écris, alors que je prends le temps de t'expliquer pourquoi tu te trompes.


En effet je ne fournirai plus jamais aucun source.
Pourquoi le ferais-je ?
Pour qu'un Dezert passe par là et s'attribue mon boulot ?
Non merci, ce sera sans moi.
Si tu veux voir pour l'affichage super rapide de la sphère 16x16, c'est MON code, tu peux donc aller regarder sur son GitHub.
Ca n'a aucun intérêt sans le fichier explicatif, que je lui avais pourtant fourni.
Il a aussi viré l'essentiel des commentaires in-line que j'avais écrits, ce qui est stupide ( donc : sans surprise de sa part ).

[Invité]

600 ko c'est énorme vu ce que tu as à l'écran, CAD une répétition de quelques sprites, si tu dev ais faire un jeu avec des vrais sprites, donc pas identiques, animés et qui bougent sur tout l'écran de façons différentes + un vraie map, sans parler du mur de pierre qui est immobile chez toi, et bien cela m'étonnerait fort que ça rentre dans 2Mo, et encore tu as de la chance, la map de beast est basique,sur un vrai jeu, c'est mort ,clair et net .
D'ailleurs cela métonnerait fort que tu mettes le second layer avec les arbres, car non seulement il faut avoir tout ça en RAM, mais en plus faut de la place pour la musique, les sons, et bien sur le code pour gérer un jeu .

D'ailleurs on est tous conscient, que si tu pouvais le faire, tu aurais déjà fait un moteur depuis belle lurette,et non des WIP à répétition .

[The_Real_Zarchos]

600 ko c'est énorme vu ce que tu as à l'écran, CAD une répétition de quelques sprites, si tu dev ais faire un jeu avec des vrais sprites, donc pas identiques, animés et qui bougent sur tout l'écran de façons différentes + un vraie map, sans parler du mur de pierre qui est immobile chez toi, et bien cela m'étonnerait fort que ça rentre dans 2Mo, et encore tu as de la chance, la map de beast est basique,sur un vrai jeu, c'est mort ,clair et net .
D'ailleurs cela métonnerait fort que tu mettes le second layer avec les arbres, car non seulement il faut avoir tout ça en RAM, mais en plus faut de la place pour la musique, les sons, et bien sur le code pour gérer un jeu .

Tu comprends ce que c'est un source ? Tu le fais vraiment exprès ?
Bien sûr qu'avec les arbres tout tiendra dans 2 Mo, tu crois que ça va me prendre 600 ko ou plus ?
Réfléchis, si tu le peux.

[Invité]

Tu comprends ce que c'est un source ? Tu le fais vraiment exprès ?

C'est toi qui comprends pas, tu crois que le premier niveau se limite à ce que tu proposes dans ton WIP niveau données graphiques ? rassures moi, tu le sais j'espère,parce que j'en ai pas l'impression ? 
Rien que pour animer le second layer, tu vas doubler la taille de tes 600 ko, à supposer que tu sois capable de le faire,ce qui à mon avis n'est clairement pas le cas .

Bien sûr qu'avec les arbres tout tiendra dans 2 Mo

Mais bien sur, c'est pour ça qu'au bout de 2 ans, non seulement le second layer n'y est pas, mais en plus rien n'a évolué dans ton WIP, qui reste le même WIP, malgré les 50 vidéos que tu as faite sur ce sujet .

Aussi pour répondre à ta critique sur le fait que ce que tu affiches sur ton truc, est infaisable sur A500/A1200, et bien moi je prends ça :


Qui est infaisable sur ton archie 8 ou 12 mhz, et même en 16 couleurs .

[The_Real_Zarchos]

Tu comprends ce que c'est un source ? Tu le fais vraiment exprès ?

C'est toi qui comprends pas, tu crois que le premier niveau se limite à ce que tu proposes dans ton WIP niveau données graphiques ? rassures moi, tu le sais j'espère ? 
Rien que pour animer le second layer, tu vas doubler la taille de tes 600 ko, à supposer que tu sois capable de le faire .

Mais non, tu ne comprends pas comment on peut faire.
Et tu ne comprends pas que j'écraserai code et datas graphiques de :
- l'affichage des 2 glands verts
- l'affichage du scroll sinusoidal

[The_Real_Zarchos]

Mais bien sur, c'est pour ça qu'au bout de 2 ans, non seulement le second layer n'y est pas, mais en plus rien n'a évolué dans ton WIP, qui reste le même WIP, malgré les 50 vidéos que tu as faite sur ce sujet .

J'ai une vie et des priorités.
Tu ne vis peut-être qu'au travers de ta bouse de mig, moi j'ai d'autres préoccupations, surtout maintenant vu l'état du monde et de l'économie.
Faut être un TARé pour avoir comme priorité de coder sur une bécane rétro datant de 35 ans, et je n'en suis pas un.

[Invité]

Mais non, tu ne comprends pas comment on peut faire.

Non je comprends rien ,je constate juste, que pour un mec comme toi qui connais tout, tu nous ponds toujours les mêmes vidéos, avec les mêmes sprites clonés .
Le jour où tu présenteras du concret, soit un moteur qui montre quelque chose de conforme à ce qu'est un vrai jeu, tu pourras fanfaronner, mais pour le moment, il y a que dalle .

Faut être un TARé pour avoir comme priorité de coder sur une bécane rétro datant de 35 ans, et je n'en suis pas un.

Marrant, c'est pas moi qui fait des vidéos de teubé, en insultant les gens, parce que son archimedes il est tout pourri pour les jeux .
Tu parles de tarés, mais c'est clair que chez toi ça va pas, t'as pondu combien de vidéos de ce style sur ta chaine ? facilement plus d'une centaine rien qu'avec tes WIP,et ce sont les autres que tu traites de tarés ? 

[The_Real_Zarchos]

Tu comprends ce que c'est un source ? Tu le fais vraiment exprès ?

C'est toi qui comprends pas, tu crois que le premier niveau se limite à ce que tu proposes dans ton WIP niveau données graphiques ? rassures moi, tu le sais j'espère,parce que j'en ai pas l'impression ? 
Rien que pour animer le second layer, tu vas doubler la taille de tes 600 ko, à supposer que tu sois capable de le faire,ce qui à mon avis n'est clairement pas le cas .

Bien sûr qu'avec les arbres tout tiendra dans 2 Mo

Mais bien sur, c'est pour ça qu'au bout de 2 ans, non seulement le second layer n'y est pas, mais en plus rien n'a évolué dans ton WIP, qui reste le même WIP, malgré les 50 vidéos que tu as faite sur ce sujet .

Aussi pour répondre à ta critique sur le fait que ce que tu affiches sur ton truc, est infaisable sur A500/A1200, et bien moi je prends ça :


Qui est infaisable sur ton archie 8 ou 12 mhz, et même en 16 couleurs .

C'est du 288 pixels de large, non ?
C'est faisable en 50 fps en 256 couleurs sur Archie à 8 Mhz, et tant pis si tu ne me crois pas.
OK faudra 2 Mo.
De toute façon si on t'écoutait ce que j'ai fait jusqu'à présent sur Archie c'est impossible, alors bon, ton avis ... 

[The_Real_Zarchos]

Mais non, tu ne comprends pas comment on peut faire.

Non je comprends rien ,je constate juste, que pour un mec comme toi qui connais tout, tu nous ponds toujours les mêmes vidéos, avec les mêmes sprites clonés .
Le jour où tu présentera du concret, soit un moteur qui montre quelque chose de conforme à ce qu'est un vrai jeu, tu pourras fanfaronner, mais pour le moment, il y a que dalle .

Les mêmes sprites clonés ?
Ah bon, où ça ?
Consulte un ophtalmo, tu en as besoin ...
La démo des bouncing balls c'était par gentillesse de ma part, vu que tu voulais savoir combien un Archie pourrait en afficher ...
ben tu as vu : bien plus que ton ordibouse de mig ne le peut

[Invité]

Manque de pot c'est du plein écran 50 fps, et environ 80/100 couleurs à l'écran, dual playfield, multidirectionnel, avec parallaxes à la ligne sur le second plan,et grandes map pour les niveaux .

La démo des bouncing balls c'était par gentillesse de ma part, vu que tu voulais savoir combien un Archie

Ils sont pas clonés la dedans ? 
Bon arrêtons le H.S tu as une capture à nous présenter je crois . 

[The_Real_Zarchos]

Manque de pot c'est du plein écran 50 fps, et environ 80/100 couleurs à l'écran, dual playfield, multidirectionnel, avec parallaxes à la ligne sur le second plan,et grandes map pour les niveaux .

La démo des bouncing balls c'était par gentillesse de ma part, vu que tu voulais savoir combien un Archie

Ils sont pas clonés la dedans ? 
Bon arrêtons le H.S tu as une capture à nous présenter je crois . 

C'est cloné vu que c'est le principe des démos équivalentes sur mig et st, t'es lourd, là.


Je vérifierai pour Kid Chaos si c'est du plein écran.
si c'est le cas a priori ça ne me semble pas possible sur Archie à 8 Mhz en 256 couleurs.

[Invité]

C'est que je dis, là pour ton code c'est top, par contre dans le cadre d'un jeu, c'est mort,et un jeu comme kid chaos tu peux te grâter pour le faire sur archimedes, et c'est pas les 2 Mo qui te sauveront,même en passant en 16 couleur,c'est un fait .

Je vérifierai pour Kid Chaos si c'est du plein écran.
si c'est le cas a priori ça ne me semble pas possible sur Archie à 8 Mhz en 256 couleurs.

Même dans une réso comme celle de beast(ce qui n'est pas le cas) c'est impossible,t'as déjà du mal avec 3 arbres qui défilent de gauche à droite .
Enfin si tu dois démontrer quelque chose, j'espère que tu ferra pas de la copie de gfx à 2 balles comme tu fait tout le temps, et qu'il y aura au minimum un semblant de moteur, avec contrôle du perso+ tous les scrollings et gestion de map,mais là je suis certains que ce sera pas demain la veille .

Ni en 256 ni en 16,sinon cela ferait longtemps qu'il y aurait quelque chose de similaire .

[The_Real_Zarchos]

C'est que je dis, là pour ton code c'est top, par contre dans le cadre d'un jeu, c'est mort,et un jeu comme kid chaos tu peux te grâter pour le faire sur archimedes, et c'est pas les 2 Mo qui te sauveront,même en passant en 16 couleur,c'est un fait .

Je vérifierai pour Kid Chaos si c'est du plein écran.
si c'est le cas a priori ça ne me semble pas possible sur Archie à 8 Mhz en 256 couleurs.

Même dans une réso comme celle de beast(ce qui n'est pas le cas) c'est impossible,t'as déjà du mal avec 3 arbres qui défilent de gauche à droite .
Enfin si tu dois démontrer quelque chose, j'espère que tu ferra pas de la copie de gfx à 2 balles comme tu fait tout le temps, et qu'il y aura au minimum un semblant de moteur, avec contrôle du perso+ tous les scrollings et gestion de map,mais là je suis certains que ce sera pas demain la veille .

Ni en 256 ni en 16,sinon cela ferait longtemps qu'il y aurait quelque chose de similaire .

Non, ce n'est pas un 'fait'.
C'est une assertion de plus de ta part, sans preuve.
Je te l'ai déjà dit, avec tes assertions, rien de ce que j'ai produit jusqu'à présent ( que ce soit inachevé n'y change rien ) n'existerait, cela démontre donc des erreurs de jugement de ta part.
Ca, ce sont des faits.

[youki]

Tant qu'on y est. Puisque t'arrêtes pas de parler de story telling en sortant des bobards genre "L'équipe Amiga habitait en face de chez moi pendant 10 ans", expliques nous quelques petites choses qui sont de notoriéré publique ou, encore mieux, sont des éléments techniques incontestables.

Donc, si l'Amiga devait être une console expliques nous ces incohérences :
- Le chipset a été conçu au départ pour faire du TSL. Et le HAM a été pensé pour ça au départ. C'est Commodore qui a fait basculer vers le RGB (Et le HAM a failli être enlevé). Les stations de travail genre Sparc font du TSL : c'était des consoles ? C'est certain : Jay Miner ignorait que les TV de l'époque ne géraient pas ce type d'entrée...
 - Choisir un 68000 ? ça coutait une fortune et ça apportait rien pour une console.
 - avoir besoin de 512 Ko de RAM pour être exploitable ? sérieusement ? Une SMS, sortie plus tard, avait 24 Ko. Une NES bien moins. Meme une mégadrive, sortie 4 ans plus tard, c'est 136 Ko. Une SNES (6 ans plus tard...) c'est 192 Ko. Y a pas un problème ?
 - Une console sans mode tile ? Il est con Jay Miner ? Il faut savoir qu'implémenter un mode Tile serait plus simple que d'implémenter le mode HAM qui, comme chacun le sait, est un mode qu'on retrouve dans toutes les consoles...
 - Avoir un mode bitplan inutile dans une console ? Bien plus pratique et économique de faire du chunky comme toutes les consoles (y compris celles de Jay Miner). 
 - Avoir mis si peu de sprites ? L'amiga possède assez de slots DMA dispos pour avoir 20 sprites par ligne. Comme la Mégadrive.
 - Avoir une détection de collision moins bonne qu'un atari 8 bits ? Tout le monde sait que ça sert à rien dans une console.
 - Un blitter avec des fonctionnalités utiles (et utilisées) dans les GUI (tracé de lignes...), et inutilisées dans les jeux. C'est vrai que toutes les consoles affichent des fenêtres... 
 - Un controleur DMA qui traite les données (accès disques) en priorité 1. Tandis que ce qu'il sacrifie en premier, ce sont justement les sprites. C'est vrai que dans une console, les sprites ne sont pas utiles...
 - Pas de port cartouche et, surtout, pas de possibilité d'en créer un accessible au chipset. Donc pas d'économie de ram avec les données de la cartouche et un 68000 qui aurait passé son temps à copier depuis la ROM vers la Chipram...
 - 720x576 : à quoi ça sert pour une console ? A jouer avec Deluxe paint ou WordWorth ? Meme la SNES n'atteint pas ça. Et la megadrive n'en parlons pas. Quand aux consoles contemporaines à l'amiga, oublions...
 - La Fast-Ram qui permet de bien mieux exploiter le mig. Y en a que dans le TT chez Atari. C'est la console de la gamme ? Et il faut une extension de mémoire : ça arrive souvent dans les consoles de cette époque ?
 - Paula qui gère les lecteurs de disquette. Tiens donc ?!!! donc c'est prévu dès le début ? Ils n'ont pas ajouté un composant off-the-shell au dernier moment ? C'est bien connu : une bonne console doit prévoir 4 lecteurs de disquettes dès le début de sa conception... 
 - Les possibilité d'extension et l'auto-config (équivalent du plug & play) : tous les 2 présents sur toutes les consoles de l'époque. C'est vrai qu'une bonne console était bardé d'extensions en tout sens...

Je peux en sortir pleins d'autres...

Alors déja ce qui est de notoriété publique n'est pas forcement vrai , surtout dans le monde Amiga.    Pour les elements techniques inconstestables... si ils sont incontestables, ils doivent être vrai... mais le sont ils vraiment?

- Le chipset a été conçu au départ pour faire du TSL. Et le HAM a été pensé pour ça au départ. C'est Commodore qui a fait basculer vers le RGB (Et le HAM a failli être enlevé). Les stations de travail genre Sparc font du TSL : c'était des consoles ? C'est certain : Jay Miner ignorait que les TV de l'époque ne géraient pas ce type d'entrée...

Le TSL , c'est le YUV?      Si c'est ca, c'etait utilisé partout au U.S sur les machines de l'époque.  Et tout les télé le supportait , il me semble bien.  

Choisir un 68000 ? ça coutait une fortune et ça apportait rien pour une console.

Le 68000 datait déjà, son prix commencait deja bien a chuter.  Et Jay , lui voulait faire une console next generation,  il a pris le processeur qui etait d'actuallité a l'epoque.  C'est tout.  Il aurait pu choisir un Intel , mais venant du monde du 6502 , qui lui est un derivé de 6809 de motorola ,  c'etait simplement plus naturel d'aller vers le 68000 qui date de 79.

 - avoir besoin de 512 Ko de RAM pour être exploitable ? sérieusement ? Une SMS, sortie plus tard, avait 24 Ko. Une NES bien moins. Meme une mégadrive, sortie 4 ans plus tard, c'est 136 Ko. Une SNES (6 ans plus tard...) c'est 192 Ko. Y a pas un problème ?

Premierement , c'est a partir du moment ou il a pris la decision de transformer sa console a micro a cause des contraintes du marché , qu'il a augementé la memoire.  Et en plus n a partir du moment où tu veux mettre les jeux en RAM , tu en besoin de plus de Ram qu'une console a Cartouche.

Une console sans mode tile ? Il est con Jay Miner ? Il faut savoir qu'implémenter un mode Tile serait plus simple que d'implémenter le mode HAM qui, comme chacun le sait, est un mode qu'on retrouve dans toutes les consoles...

tu considère peut etre jay miner comme un dieu , mais non, c'etait un tres bon ingenieur , mais pas forcement un visionnaire , ou alors avec ses propres vues .  Deja il venait d'Atari 2600 ou il n'y avait pas de mode tile .  son obsession avant tout , c'est les simulateurs de vol , ou tu n'a pas besoin de mode tile...   et je pense aussi qu'il sait dit qu'avec beaucoup de RAM et un blitter tu peux te passer d'un mode tile.  Mais bon, j'etais pas dans sa tete.. mais c'est fort probable.

 - Avoir un mode bitplan inutile dans une console ? Bien plus pratique et économique de faire du chunky comme toutes les consoles (y compris celles de Jay Miner). 

En 83-85 , c'etait bien moins cher de faire du bitplan que du chuncky si tu voulais avoir plus de couleur.

 - Avoir mis si peu de sprites ? L'amiga possède assez de slots DMA dispos pour avoir 20 sprites par ligne. Comme la Mégadrive.

Il a du se dire, bah, ya le blitter  , pas besoin de beaucoup de sprite... ca fait toujours des economies.  Et pour l'epoque le nombre de sprite etait deja pas si mal.  

 - Avoir une détection de collision moins bonne qu'un atari 8 bits ? Tout le monde sait que ça sert à rien dans une console.

Erreur de conception peut etre?    

 - Un blitter avec des fonctionnalités utiles (et utilisées) dans les GUI (tracé de lignes...), et inutilisées dans les jeux. C'est vrai que toutes les consoles affichent des fenêtres... 

alors, je vois pas le rapport?  Tu trace pas de ligne sur une console ?    Et si tu as comme lui dans le viseur des simulateurs de vol... le tracer de ligne il sert bien...

 Un controleur DMA qui traite les données (accès disques) en priorité 1. Tandis que ce qu'il sacrifie en premier, ce sont justement les sprites. C'est vrai que dans une console, les sprites ne sont pas utiles...

ca fait peut etre partie des modifications qu'il a fait apres avoir decidé de transformer la console en ordi.  Ou alors il s'est dit les sprites on s'en fou , on a le blitter.

720x576 : à quoi ça sert pour une console ? A jouer avec Deluxe paint ou WordWorth ? Meme la SNES n'atteint pas ça. Et la megadrive n'en parlons pas. Quand aux consoles contemporaines à l'amiga, oublions...

Je ne vois pas pourquoi une super resolution ne serait pas bon pour une console,   mais bon à l'epoque je dirai a pas grand chose.... mais a quoi ca sert sur un amiga 1000 avec 256 k?  ...  

- La Fast-Ram qui permet de bien mieux exploiter le mig. Y en a que dans le TT chez Atari. C'est la console de la gamme ? Et il faut une extension de mémoire : ça arrive souvent dans les consoles de cette époque ?

toi , tu aurais envie de faire une console next gen performante, tu ne penserais pas a utiliser de la fast ram aussi?

 - Paula qui gère les lecteurs de disquette. Tiens donc ?!!! donc c'est prévu dès le début ? Ils n'ont pas ajouté un composant off-the-shell au dernier moment ? C'est bien connu : une bonne console doit prévoir 4 lecteurs de disquettes dès le début de sa conception... 

Les lecteurs de disquettes sur les consoles a l'epoque c'etait à la mode.  Il s'y sont tous mis , ca a toujours été une solution envisagé ... on a eu droit au cassette, au disquettes et puis au CD.  C'est dans la meme optique ... stocké plus a cout moindre.

Le NES , la SNES  , meme la megadrive devait en avoir un.   C'etait juste a la mode. 

 Les possibilité d'extension et l'auto-config (équivalent du plug & play) : tous les 2 présents sur toutes les consoles de l'époque. C'est vrai qu'une bonne console était bardé d'extensions en tout sens...

La encore, oui a l'epoque c'etait tres courant,  les consoles etait tout tres extensible ,  et on pouvait pour la plupart les transformé en micro.  C'etait juste la tendance, il a fait comme les autres. Et elles etaient plug'n play. Principe de base d'une console..

[The_Real_Zarchos]

En réalité j'aime bcp les amigoloïds.
Ils sont tellement 'gullible' comme disent les British, que ça en a un côté attendrissant, on aurait presque de la compassion pour eux ... 

[Seb]

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.

[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