Re: Amiga/st vs Archimede

[ArchieForEver]

Ah non tu utilises pas plusieurs MO ??
C'est pour ça que tu précise que ca fonctionne avec 4 mo, et que ça doit fonctionner avec 3, dans les coms de ta video ..

Je l'ai modifié, la com, car après vérifcation ça tourne sur une machine avec 2 Mo.
C'est sur une 1 Mo que ça ne tourne pas, et il ne doit pas manquer grand'chose.
Faut dire aussi que je n'ai fait aucune optimisation mémoire.

Dois-je à nouveau répéter que ce n'est qu'une preview de démo dont le but a juste été de tester des routines ? Ce n'est ni un produit léché, ni fini, car ce n'était pas mon but. C'est bien pour ça que je ne la montre que 20 ans après sa réalisation.

J'ai déjà expliqué que désormais je ne bouffe quasiment plus de RAM pour le code généré car il est réutilisable.

[Invité]

Même 2 MO, sur amiga tu fais tourner ça sur 512 ko ..

Ta pas besoins de faire du double ou triple buffering en precalc comme tu fais, un scroll hard fait boucler un écran automatiquement .
C'est utile que dans le cas ou tu as 3 écrans différents ou plus, et là même un double suffit.
Avec le blitter tu peux facilement ajouter juste ce qu'il faut de tiles, pour éviter de remplir un écran complet.
Mais comme tu bouffes toutes la BP de la ram avec tes sprites soft, bah lol quoi .

Non l'amiga ne gère pas non plus les tiles .
Le but n'est pas critiquer ta demo, juste de te montrer que les routines que tu décris comme révolutionnaire ne le sont pas .
Car à t'écouter, ce que tu fais dans ta demo, quasi seul l'archimedes en est capable (toutes machines confondues, sauf NG) .
C'est pour ça que je voulais te montrer le contraire,qu'une machine n'as pas besoin d'un CPU surpuissant pour battre l'archimedes en 2D, un PCE avec son CPU 8 bit,dont ton arm s'inspire très fortement,et ses customs dédiés pour la 2D suffisent .

Maintenant si tu veux voir quelque chose sur amiga, va faire le malin sur un forum de dev amiga, en leur disant que leurs routines c'est de la grosse merde comparées aux tiennes, et que se sont tous des rigolos, comme tu nous le dis si souvent ici .

Et t'inquiètes pas pour ma demo.

Ps:édites correctement tes posts, parce que c'est illisible,tu t'auto cite, c'est n'importe quoi.

[ArchieForEver]

Même 2 MO, sur amiga tu fais tourner ça sur 512 ko ..

Ta pas besoins de faire du double ou triple buffering en precalc comme tu fais, un scroll hard fait boucler un écran automatiquement .
C'est utile que dans le cas ou tu as 3 écrans différents ou plus, et là même un double suffit.
Avec le blitter tu peux facilement ajouter juste ce qu'il faut de tiles, pour éviter de remplir un écran complet.
Mais comme tu bouffes toutes la BP de la ram avec tes sprites soft, bah lol quoi .

Non l'amiga ne gère pas non plus les tiles .
Le but n'est pas critiquer ta demo, juste de te montrer que les routines que tu décris comme révolutionnaire ne le sont pas .
Car à t'écouter, ce que tu fais dans ta demo, quasi seul l'archimedes en est capable (toutes machines confondues, sauf NG) .
C'est pour ça que je voulais te montrer le contraire,qu'une machine n'as pas besoin d'un CPU surpuissant pour battre l'archimedes en 2D, un PCE avec son CPU 8 bit,dont ton arm s'inspire très fortement,et ses customs dédiés pour la 2D suffisent .

Maintenant si tu veux voir quelque chose sur amiga, va faire le malin sur un forum de dev amiga, en leur disant que leurs routines c'est de la grosse merde comparées aux tiennes, et que se sont tous des rigolos, comme tu nous le dis si souvent ici .

Et t'inquiètes pas pour ma demo.

Ps:édites correctement tes posts, parce que c'est illisible,tu t'auto cite, c'est n'importe quoi.

Ben non, tu ne feras jamais tourner ça sur un Amiga, tout simplement parce que tu ne peux pas le faire sur un Amiga.
Ta description du double ou triple buffering en precalc (???????????) c'est du n'importe quoi toutconien.
T'es vraiment un demeuré.
Rien de ce que tu décris pour ma preview de démo ne correspond à son fonctionnement : RIEN !

Tu n'as auccune connaissance en programmation, sorti peut-être du pilotage des copros de ta PCE.
Je pense pouvoir mettre les pieds dans un forum de dev Amiga, mais toi, certainement pas.

Bouffon que tu es.

[Invité]

Puisque comme d'hab il faut tout t'expliquer parce que tu comprends rien, tu balances tes données graphiques dés le départ, dans ton buffer écran, ou bank comme tu l'appelles, y'a rien de dynamique dans ton scroll comme tes sprites, c'est moche c'est nul, et y a rien de technique, parce que je vais te prouver par A+B que ta merde de CPU tout puissant qu'il est, il se fera rétamer par une simple console 8 bit en matière de 2D ..

Mais comme tu es sur d'être une bête en prog, pourquoi tu vas pas faire le malin sur un forum de dev amiga au lieu de nous faire chier ici ??

Et tu leur diras bien qu'il sont trop nuls avec leurs routines de merde ..
Mais vas y qu'on rigole, au moins tu pourras pas dire qu'il y comprennent rien ..

Perso j'ai rien à te prouver, je ferai la demo comme promi, et je te montrerai que tu n'es rien qu'un imbécile prétentieux .
Tu crois que tu es une bête parce que tu sembles avoir compris que des demos maker utilisent du framebuffer dans leur demos, lol, c'est clair t'es trop fort .

Et bien si je comprends rien, expliques moi en detail (même en mp,si tu as peur que le kgb mette la main sur tes supers routines), en quoi elle consiste que je rigole ..

[stapha92]

Ok Archimerde, moi aussi je vais utiliser un surnom insultant...

En vrac pour tes réponses biaisées :

Sans rire, me sortir Deluxe Paint comme la grosse appli qui tournait bien sur un Amiga500, c'est marrant.
Et pour le traitement de texte, le DTP, les tableurs (tu sais : ce qui intéresse vraiment 80% des utilistaurs d'un ordinateur) vous aviez quoi sur votre superbe micro ?

Deluxe paint était LA référence des logiciels de dessin sur micro, tout simplement. Si ça c'est pas pro, je ne sais pas ce qu'il te faut...
Toi même tu as admis que vous n'aviez rien qui le valait sur l'Archimerde...
Quand aux autres applis, va regarder les vidéo de présentation de l'A1000 (qui est moins puissant qu'un A500) dans "computer chronicle" et tu verras ce type d'applis tourner en même temps avec même un copié collé d'un graphique généré par un tableur dans un traitement de texte.
Ah oui ? 80% des utilisateurs ? LOL !!!

Bon, ensuite pour les modes graphiques.
En gros tu m'expliques que la conception 'flashy entrelacé' c'est bien mieux que la conception 'désentrelacé' c'est ça ?
1ère nouvelle .
Avec l'Amiga, nous avons un nouveau concept :'moins bien, c'est mieux'.
Olé !

Oui c'est ça moque toi et relis ce que j'écris : je t'expliques juste que tous les modes sont disponibles en entrelacé ou en progressif. En quoi c'est moins bien ?

Pour le prix des moniteurs multisyncs, sache que, comme les Ataristes avec leur moniteur pseudo hi res monochrome, et bien sur Archie quand on n'avait pas les moyens de s'acheter un moniteur multisync (dont le prix a très vite décru, je dois le signaler pour bien souligner ta très grande mauvaise foi) et bien on s'achetait un switch, et on avait d'un côté un moniteur RGB, de l'autre un moniteur VGA.

Avoue : c'est complètement dingue et impensable, hein ?

Un moniteur VGA ? T'as pas compris : un moniteur VGA coutait très cher. Tu crois que seuls les multisync etaient dans ce cas ?
Alors t'as rien compris : c'est le coté 30 Khz qui rendait les moniteur couteux, pas la compatibilité avec le 15 Khz.
Sur le ST (puisque tu compares) ce n'est pas pareil : Atari a proposé un moniteur Noir et blanc, seul moyen d'avoir du 30 Khz pour pas trop cher.
En résumé : un moniteur 15 Khz + un moniteur vga + un switch = un ensemble plus couteux qu'un multisync. Bravo pour la solution...
C'est vrai qu'il faut être dingue.

Ta comparasion avec l'entrelacement sur une TV c'est encore un extême exemple de mauvaise foi : sur une télé tu as une image qui évolue (ça bouge quoi, tu comprends ça ? ce n'est pas statique) et donc l'entrelacement est supportable.

Ah oui ? Tu crois que c'est le problème de l'image fixe qui augmente le scintillement ? Ok oublions Zizou et parlons des tableaux de résultats ou de classement qui étaient affichés de façon FIXE pendant cette coupe du monde : c'était illisible ?
Le scintillement accru était du à un contraste qui pouvait être bien plus élevé avec le signal d'un micro en rvb qu'avec un signal vidéo...

Et je n'ai jamais dit que c'était fait pour un tableur...

Autre chose : moi à l'époque j'ai pris une télé 100 Hz comme moniteur et tu sais quoi ? Plus de scintillement ! Et elle coutait moins cher qu'un multisync ou un vga ! LOL !!!
Et je te rappelle qu'un A500 ECS sait générer du vga en natif...

Fais tes recherches sur Youtube, et tu verras les Xenon 2, lemmings, Lotus Turbo challenge, battle chess, cannon fodder, gods, speed ball 2, alone in the dark, flashback etc, etc ....

Oui c'est sur : Lotus, Xenon 2, speed ball 2, gods, ... : de super jeux qui existaient sur le ST et qui n'exploitent absolument pas le mig (ou un flashback qui n'a aucun scrolling...). Montre moi un Shadow of the beast, un brian the lion, un Lion heart, un M. Nutz, un super cars 2 (rien que pour l'écran splitté ou chaque moitié a son scrolling...). Quand tu auras réussi je rajouterai quelques dizaines de jeux. Mais tu comprendras que je ne vais pas commencer à recenser les jeux qui ne peuvent pas être faits sur ton Archimerde, puisque tu n'as aucune chance avec les quelques exemples que je viens de donner...

Je connais quoi à l'Archimedes ? Ben surement plus que tu n'en connais sur le mig : y a qu'a voir tes affirmations sur le blitter dont les données devraient être préparées par le 68000 (lol !), le copper qui ne serait qu'un timer (re-lol !) ou l'assembleur ARM qui serait meilleur et plus souple que le 68000 (re-re-lol !) alors que le principe du RISC c'est le contraire : on sacrifie la facilité et la souplesse de coding pour la vitesse.

Tu parles de qualité broadcast. Tu sais que ça implique un signal vidéo entrelacé ? LOL ! toi qui te moque de ces modes, tu viens les mettre en avant ! Tu montres encore une fois que tu n'y connais rien...

Quand au broadcasting, désolé mais l'Amiga était bien plus utilisé que ton Archimerde dans ce domaine. Evidemment peut-être pas par la BBC, c'est un peu logique...
Ta carte millipede, personne ne connait, tout le monde pense que c'est un jeu sur atari 2600.
Le vidéo toaster par contre, était le plus réputé. L'Amiga a été utilisé pour des pubs, des séries et même des films, renseigne toi petit rigolo!...

Pour le Basic en ROM, tu le fais exprès ?
On est en 1987, tu vois un énorme essort du C à l'époque ?
Le BBC basic est sans conteste parmi les meilleurs basics qui soient.
Rapides, structurés.
Tu veux mettre un compilo C dans les écoles ? Mais t'es un sacré bon, toi !

Si je vois un essor du C en 1987 ? Ben c'est simple : la majorité des applis et des jeux de la fin des années 80 et début 90 étaient codés en C. Y a que les débutants qui pensaient maitriser la programmation qui restaient coincés sur le BASIC...
Le C est né dans les années 70 : réveille toi. Tu confonds peut-être avec le C++ ? Ah ben ça a servi ta culture d'avoir un BASIC en ROM : tu ne savais que le C existait alors que c'est rien de moins que le langage le plus utilisé en 1987... Tu es vraiment trop ridicule...

Le basic BBC est le meilleur qui soit ? Au non de quoi tu dis ça ? T'as programmé sur combien de basic pour te permettre de telles affirmations ? Le GFA est surement meilleur, l'Omikron aussi, le blitz j'en parle même pas (il existe encore sur PC : ton BBC basic est tombé aux oubliettes...).
Mais admettons : et alors ? le meilleur BASIC ne vaudra jamais le C. Si t'es pas capable de le comprendre, arretes de parler programmation...

Dans les écoles ? Donc t'es en train de dire que l'Archimedes est une machine d'initiation ? Parce que le BASIC (tu sais ce que signifie ce sigle j'imagine...) c'était bon pour l'initiation, c'est tout...

Et tu vois : quand j'allume mon petit BBCA3000 de base, et qu'au bout de 6 secondes j'ai le RISC OS, je peux lancer mon éditeur, et commencer à coder dans un mélange de Basic et d'assembleur ARM parfaitement interfacé, parfaitement convivial, je me dis que c'est génial

Oui, en 6 secondes tu peux avoir l'éditeur BASIC : ça me rappelle les atari 8 bits, les C64 ou autres Amstrad... Une révolution ! LOL !

Bien sûr une ROM ne remplace pas un HD.
Je n'ai jamais dit ça. Ne me prête pas ce genre de propos, malhonnête que tu es.

Non tu n'as pas dit ça : tu as juste dit qu'il fallait au A500 un disque dur pour avoir l'équivalent de l'Archimerde avec ses applis en ROM. Fouille tes post, j'ai même pas envie de faire la recherche. Je cherche pas à te convaincre : tous ceux qui ont lu tes posts dans le fight ST/Amiga (rien que ça c'est drole : qu'est-ce l'archi venait faire la-dedans ?) savent ce qu'il en est...

Le MEMC n'est pas un coprocesseur OUI je te l'accorde.
Il permettait bien de faire ce que j'avançais.

Le 68030 meilleur que l'ARM pour déplacer de la mémoire ?

Le MEMC n'est pas un copro : on avance... Il permet de faire ce que tu disais ? Alors répond à ma question sur les modulos : car tu affirmais qu'il permettait de faire un scrolling horizontal sauf que j'attend toujours une réponse. Parce que sans ces modulos, c'est impossible (exemple : quand le STE a reçu l'équivalent des registres que tu as décris, il a aussi eu un registre qui gère ce modulo). Alors elle sont ou tes explications ? C'est ta vision simpliste qui te fait penser que les 2 registres que tu as indiqué suffisent...

Oui, un 68030 est bien plus performant que ton ARM pour manipuler des données. Renseigne toi. Et quelques exemples pourront t'aider :
Combien d'instructions ARM pour faire :
MOVE.L (A0)+,(A1)+ (copier une adresse vers une autre : une instruction sur 68000. 2 sur ARM)
OR.L offset(A2,D0.Wx4),(A3,D1) (faire un OR entre une adresse obtenue par un offset (sur 16 ou 32 bits : pas tes offset pourris hyper limités) + un registre d'adresse + les 16 premiers bits d'un registre de données scalés vers une adresse obtenue par l'addition de 2 registres. Là, il faudra plus de 2 instructions...
AND.l #$F0F0F0F0,(#$A100FF00) (Faire un AND entre une constante et une valeur à l'adresse mémoire indiqué par un pointeur). Sur ARM tu es obligé de charger la constante dans un registre (plusieurs instructions rien que pour ça...), charger l'adresse du pointeur (IDEM...), charger le pointeur, charger la valeur pointé, lui appliquer un AND et écrire le resultat... Ouf !!!
Et je pourrais te donner d'autres exemples mais il n'y en a pas besoin. Il suffit de savoir que l'ARM NE SAIT PAS TRAVAILLER DIRECTEMENT SUR LA MEMOIRE !!! Obligé de charger, traiter, sauver à chaque fois... Les 68000, eux, savent faire les mêmes choses sur leur registres ou de la mémoire (tu sais : c'est là que sont les données...).

Au fait, la première instruction prendra 2 octets sur 680x0 et la deuxième aussi s'il n'y a pas d'offset. Si elle se suivent, les 2 seront chargés en même temps et la 2eme commencera à s'éxécuter avant que la première soit terminée. Toi, pour reproduire la premiere, il te faut déjà 8 octets : génial l'ARM...

Tu peux ramener ton ARM3, ça changera rien, surtout avec une mémoire à 8 Mhz...

Je pense que dans les IUT d'info on en était encore au BASIC et au PASCAL ou au FORTRAN.
Vous avez tous décidés d'en tenir une couche simultanément ici ?

"encore au basic" ? parce que tu penses que le BASIC est né avant le C ? dans les iut d'info on tatait de l'unix et là c'est le C qui s'impose. Tu m'aurais dit COBOL ou GAP encore. Mais BASIC...

Les PC de 1987 et 1989 offraient des simulateurs de vol hyper fluides ?
Whaaaa écoute celle-là je la note.
Le 486 DX/33 date de quand, rappelle moi ? 1994 ou 95, non ?
Je crois qu'en dessous ce proc les simulateurs de vols fluides tu peux repasser.

En 1987 je crois qu'on était encore au 286 ou 386.
Quand l'Archimedes est sorti unanimememt la presse en est restée sur le cul de voir la puissance de la machine.

Encore n'importe quoi une fois de plus, Stapha.
Cassé

Ah bon ? le 486 date de 94/95 ? LOL !!! ça montre encore que tu étais enfermé dans ton monde : le 486 sort en 89 et il n'y en a pas besoin pour avoir des simulateurs de vol fluides : un 386 est plus que suffisant et celui-ci est sorti en 86... en 94/95, on était déjà aux pentium...
Essai f29 retaliator sur PC : c'est fluide avec un 286...
Je répète ce que j'ai dit : les PC de cette époque étaient doués pour la 3D surface pleine (et en 92, les 486 faisaient carrément tourner Comanche et son voxel : c'est plus la même catégorie...). Par contre, ils étaient nuls pour la 2D... Comme ton Archimerde ! LOL !!! (pour être honnete : encore plus nuls que lui...)

Ah c'est sur : cassé le stapha... LOL !!!

Béh non : tu commentes encore quelquechose que tu n'as pas compris.
Pour manipuler des données 32 bits l'ARM doit pointer sur une adresse multiple de 32 bits.
Donc c'est contraignant.
Faut écrire un code plus développé que pour simplement lire n'importe où sans contrainte 8 bits sur n'importe quelle adresse.

Ah bon j'ai pas compris ? Et quand je parle des accès en 8 bits nécessaires pour tes sprites jusqu'à tomber sur l'alignement qui permet de passer en 32, ça montre pas que j'ai compris ? Ne cherche pas : on n'a pas le même niveau. Ce que tu considères comme une découverte n'est qu'une évidence pour tous les vrais codeurs...
Au fait un 680x0 qui fait des accès 32 bits peut le faire sur une adresse non alignée : c'est lui qui gèrera les 2 accès mémoire nécessaires dans ce cas (1 en 24 bits et 1 en 8 bits par exemple si on est sur un multiple de 4 + 1). Et c'est l'ARM le plus souple ? Pour le même cas, c'est le programmeur qui devra faire 4 accès 8 bits : dans un cas on a 1 instruction + 2 accès mémoires et dans l'autre 4 instructions + 4 accès mémoires...

Arrete avec tes 16 registres : le 68000 les a aussi mais, pour lui, c'est 16 utilisables, le PC et les registre d'états n'ont font pas parti...

C'est toi qui nie la réalité. Alors je vais te résumer : L'ASSEMBLEUR EST BEAUCOUP MOINS BON QUE CELUI DU 68000. C'EST FAIT EXPRES : ON SACRIFIE LA SOUPLESSE ET LES FONCTIONNALITES POUR GAGNER DE LA VITESSE. C'EST UN CHOIX DES CONCEPTEURS !!! (et je pense que c'est une très bonne idée, surtout quand on considère que ton ARM a 2 fois moins de transistors qu'un 68000)

Ben dans l'esprit d'Acorn, ça permettait que personne n'aille taper dans le hard, pour garder la compatibilité avec de futurs modèles.
Acorn préconisait qu'on reste en soft, tu vois.

Bon choix de la part d'Acorn. Commodore a fait le même. La différence est qu'il y a dans l'OS toutes les fonctions qui permettent de faire ce genre de chose. Ces fonctions utilisent le hard mais en rendent les programmes appelant indépendant. Ces fonctions sont présentes en ROM dès le démarrage de la machine : ben non, y a pas juste une image de disquette. Y a un OS qui joue dans une autre catégorie que ton Archimerde coopératif.
Et je trouve ces fonctions en ROM bien plus utiles que ton BASIC en ROM...

Ta remarque sur les scrolls et parallaxes est juste puérile : tous les jeux que tu vois, où ça scrolle, comme Pacmania, gods etc ... sont faits en soft.C'est bien pour ça que je peste contre la fainéantise des programmeurs de jeux sur Archie qui se sont rarement casser la tête, en allant taper dans le hard.

Tu peux pester : tu crois qu'on peut faire un scroll hard sans modulo. Tu n'as pas compris que tu es loin du niveau de ceux que tu critiques ?

Je te parle de parallaxes et tu me sors Gods et Pacmania à nouveau ? Je laisse les lecteurs juger...

Tu sais ce que représentait le marché du jeu sur Archie ?

Oui c'est sur, le marché du jeu vidéo était une petite niche sur l'Archie. En fait, c'est le marché de l'Archie tout entier qui était une petite niche... Comment ont-ils pu faire des applis aussi géniales et des jeux aussi merdiques alors ?...
Et c'est sur qu'ils se foutaient du jeu vidéo : à tel point que quand Zarch est sorti, toute la communauté Archimedes nous a expliqué que ce type de jeu était totalement impossible sur un autre micro. ça a été mis en avant partout. On voit que la suite leur a donné raison...

Oui il faut bien une centaine d'instructions pour DEFINIR TOTALEMENT un mode écran sur Archie.
Je te rappelle que contrairement à ta merde d'Atari XL qui n'a qu'un seul mode, l'Archi va des plus basses résolutions, au plus hautes, et en 2, 4 16 ou 256 couleurs.

Ah oui ? Un chip versatile ? Et bien sur le mig tu choisi entre 2,4,8,16,32,64 ou 4096 couleurs, tu alimentes 32 couleurs sur la palette, tu choisi entre progressif et entrelacé, tu peux créer tes propres résolutions, tu choisis entre simple et dual-playfield, tu actives jusqu'à 8 sprites, tu choisis les adresses et les modulos de chaque bitplan, l'endroit ou commence et fini l'affichage, etc...
Et tu peux choisir de faire varier n'importe quel de ces éléments (ou tous) à n'importe quel moment de l'affichage, j'ai même vu des programmes qui affichait un écran dans une résolution pour la partie gauche et une autre pour la partie droite...
En terme de souplesse, ton chip graphique n'est pas mauvais, mais il est loin du mig...
Quand je disais 100 instruction, c'est parce que tu disais que c'est ce qu'il fallait pur activer l'overscan. D'ou mon interrogation... Ok maintenant c'est clair.

Et dire que le XL n'a qu'un mode montre que tu ne le connais pas plus que le mig. A croire que tu as découvert la micro avec l'Archimerde : ça expliquerait bien des choses;..

Concernant le sprite hard unique sur Archie c'est juste un plus intéressant à utiliser, que de ne pas s'en servir.
Je n'ai jamais dit que ça rivalisait avec de véritables sprites hard.
Ca apporte un +. Il a sa propre palette, je peux la changer même dans mon mode 256 couleurs où la rasterizastion est impossible, et je peux altérer sa position en x à chaque ligne.

Oui le sprite est un plus, pas seulement pour les jeux vidéos d'ailleurs...
Quand à la modification de la position à chaque ligne : c'est automatique avec les sprites du mig...

Et si je passais en mode 16 couleurs dégradant et moche typique d'un Amiga, j'aurais + du double de sprites à l'écran, et la possibilité de rasterization.

Oui c'est ça fait passer tes routines en 16 couleurs et tu verras qu'elles n'iront pas 2 fois plus vite. Et oui : là tu vas être obligé de lire des données de l'écran sur les bord du sprites (puisque l'ARM ne sait pas modifier 4 bits uniquement dans un octet) et tes aligements sur 4 octets seront plus long à atteindre (en 256 couleurs tu as au max 3 pixels avant de passer en 32 bits, en 16 couleurs ça sera jusqu'à 7 pixels avant d'être sur une adresse multiple de 4, donc tu profiteras moins du 32 bits). En plus tu seras obligé de gérer les décalage de 4 bits (en en reportant 4 d'un mot long sur l'autre à chaque fois : là ça ne sera pas du shifting gratuit...). A moins de stocker ton sprite (enfin ton code puisque c'est comme ça que tu travailles...) avec un décalage de plus en mémoire : tu auras des données qui prendront autant de place qu'en 256 couleurs... LOL !
"Et si je " : Nous on te donne des exemples concret. Tu me fais rire avec tes "si"...

Pour ce qui est des multiples prouesses de tes ressources hard : je dirai : 'mon oeil !'.
Les 9/10è des jeux sur Amiga sont du même niveau nullissime de l'Atari, et toutes tes belles prouesses de coprocesseurs ne sont que sur papier : il y a tellement de contraintes et de limitations que dans la pratique ça ne s'est jamais transcrit dans autres choses que des démos (où 100% du temps CPU est pris et il ne reste rien pour gérer toute la logique temps réel d'un jeu).
Retourne à tes wikis d'esbrouffe.

J'ai assez démonté ici les démos lamentables, juste bourrées d'astuces, qui n'ont rien à voir avoir la puissance d'une machine.

Je ne me base pas sur des wiki d'esbrouffe mais sur les jeux auxquels j'ai joué : Brian the lion, SOTB ou M. Nutz sont des jeux qui existent. Pas des démos...
Par contre, ce qu'ils arrivent à faire, je ne l'ai jamais vu sur un Archimerde, même pas dans une démo.
Toi par contre, tu passes ton temps à répéter que ta démo prouve que l'Archie fait mieux que le mig : il te faut 3 tonnes de mémoire et on est bien loin d'un jeu. En attendant, j'attend toujours des exemples concrets... Même quelque chose de simple comme le scrolling sur 2 layer dans SOTB avec les monstres qui occupent la moitié de l'écran n'existent toujours pas sur Archie. Alors que SOTB n'est pas du tout un jeu qui pousse le mig dans ses retranchements.
Et les tableaux bonus de Brian the lion, c'est uniquement sur Wiki ? 2 layers dont un applique un effet de tube (qui oblige à un zoom en x sur chaque ligne, pour le reproduire sur Archie, tu serais obligé de lire les données octets par octets : pas moyen d'utiliser des lectures 32 bits...) et des rotations sur l'autre (même problème...).

Oublie Wiki et essai Brian the lion. Quand tu auras vu ce qu'il propose trouve moi une démo qui fait la même chose. Tu as bien lu : je ne te demande même pas un jeu mais juste une démo. Je risque d'attendre longtemps....
Et ne rentre pas dans un débat du genre "c'est faisable parce que bla bla..." : tu dirais juste des betises encore une fois.

Tant que t'auras pas réussi, abstiens toi de dire que tu as prouvé que l'Archimerde était meilleur que le mig (tu as même dit que TOUS LES AMIGAS sur le tube : lol !!!), ça t'évitera de passer pour un débile encore une fois...

Et désolé mais la démo la plus minable que j'ai vu dans ce Topic, c'est la tienne. A cause de tous ces Mo nécessaires..

Arrête de suite : c'est peut-être comme ça que tu dois faire sur Miga, mais pas sur Archie.
Je ne suis pas là pour t'expliquer son architecture et ce que le MEMC propose.

Ah bon ? Pas besoin d'avoir un modulo sur Archie ? Ok : t'as rien compris aux scrollings en fait...
Ok arretons le blabla la-dessus : j'attends toujours un scroll horizontal du niveau de ce qu'il y a sur le mig...

Tu m'expliques tout le merveilleux qu'aurait pu produire ta machine où il y avait un marché énorme, pleins de $$$$ à se faire pour l'équipe qui sortirait ce que tu annonces qu'il est possible de faire, et tu me demandes de te croire.

Oui je parle de ce qu'aurais pu faire le mig et tu t'en moques. Mais je fais juste la même chose que toi : toi aussi tu avances pleins de théories mais pour l'instant on n'a rien vu. Note que je dis juste que le mig aurait pu faire bien mieux en 3D : je n'ai jamais affirmé qu'il aurait pu faire mieux qua l'Archi dans ce domaine (et je précise : même avec toutes les optimisations possibles, il n'aurait pas pu battre l'archie). Toi par contre tu t'en prives pas (et tu y crois : c 'est ça le pire...). Tu es même parti en guerre sur le tube avec un possesseur d'Archimedes à qui tu as fini par dire qu'il n'avait jamais eu ou vu cette machine. Sauf qu'il t'a proposé de te donner des preuves qu'il en avait un et tu as disparu...
Et tu sais quoi : je me tamponnais de la 3D sur le mig. Le seul jeu avec de la 3D que j'ai aimé était vroom : et sans aucune optimisation (c'est le même code que la version ST à part pour le son), il était hyper fluide.

Il n'a pas 2 mais 3 sprites.
Non, je n'utilise pas plusieurs Mo pour ça.
Comme je l'ai dit aujourd'hui le code généré est réutilisable et sorti des sprites, donc la gourmandise du truc est sorti (et je ne m'étendrai pas sur les détails, suis pas là pour t'éduquer et te filer mes algos).
Pour faire un scroll hardware, il faut une minimum 3 banks écrans : normal : en fixe : on travaille sur l'un pendant qu'on affiche l'autre, en scroll hardware il en faut un 3è pour 'glisser' et que donc ça scroll.
Rien d'extraordinaire à ce qu'en mode 8 bit par pixel overscan ça bouffe déjà près de 250 ko.
1+1=2 et ça même ton Miga ne peut rien y faire.

Oui garde les tes algos : tu es le seul à croire qu'ils sont révolutionnaires...
Déjà un écran overscan en 256 couleurs ne prend pas 250 ko (en 320x256, il en prend 80, admettons 100 pour l'overscan comment tu obtiens 250 ?). Même sans le wrapping. Tu ne connais pas ? Dommage parce que c'est peut-être possible pour un scroll vertical sur Archie...
Ensuite il ne faut pas 3 buffer écrans pour faire un scrolling mais 2 (tu t'es pas demandé d'ou viennent les termes double et triple buffer ?) Un triple buffer permet de récupérer des cycles qui seraient inutilisés avec un double. Sur le mig pas besoin, tous les jeux avec scrolling sont en double buffer (voire en simple des fois) : on en n'est pas à récupérer les quelques cycles qui restent après avoir généré un écran.
Et c'est génial le triple buffer : ça augmente les temps de latence entre les action du joueurs et leur répercution à l'écran. Y a pas interet à passer en 25 i/s...
Mais admettons, il te faut 750 Kilos pour tes 3 buffers écran (rien que ça c'est pathétique sur une machine livré avec 1 Mo en standard). Mais après ? Il te faut plus d'1 Mo pour tes 2 sprites (T'en affiche 3 mais il n'y a que les données de 2 sprites à stocker) ? Trop drole : t'es au courant que SOTB tourne avec 512 K ? (avec une musique qui prend plein de place à cause des samples à 20 Khz...)

Au fait, dans tes 250 Ko, il y a la partie qui reçoit les futurs données à afficher ? Classique : on utilise la mémoire qui est situé avant et après l'écran, cette dernière n'étant pas lue par le circuit graphique et on applique les tiles 2 fois pour pouvoir faire revenir la partie affichée au début de la zone quand on en atteint la fin.
Comment tu fais pour un scroll horizontal ? Parce que là y a un problème : la mémoire située après le pixel le plus à droite est utilisée par le pixel le plus à gauche de la ligne suivante. Donc tu les prépares ou tes tiles ? Zut il faudrait de la mémoire non lue après chaque pixel le plus à droite et donc avant chaque pixel le plus à gauche sur chaque ligne...
Ah mais au fait ! Les modulos servent à ça !
Il te faut 250 Ko par frame buffer pour un scrolling vertical mais t'as pas besoin de modulos pour un scroll horizontal...

T'as jamais fait de scrolling horizontal : tu ignorais carrément ce problème et tu insultais ceux qui codent les scrolling horizontaux en soft dans des VRAIS JEUX qui tournent sur une machine standard...

Maintenant que je t'ai expliqué, tu retrouverais un peu de crédibilité en reconnaissant que quand tu as dit que le circuit graphique avait tout pour faire un scroll horizontal hardware, tu avais juste "oublié" ce détail...

Tu penses que c'est un hasard si Scorpius (TA référence) n'utilise pas de scroll hardware ?

Tu as tout faux pour les routines de collisions. Sans rire, si tu en es resté au box, t'as pas dû aller bien loin en programmation.

Euh non, moi je n'utilise pas de bouding box : je viens du monde Amiga donc détection au pixel près (en tenant compte des trous). Mais toi tu vas être obligé si tu ne veux pas ralentir énormément tes routines. Bien sur, dans ta démo n'y a aucune détection de collision mais tu n'arretes pas d'expliquer que tu vas utiliser tes routines dans un jeu. Faudra bien détecter les collisions non ?
Tu vas utiliser un tableau de coordonnées horizontales ou quelque chose comme ça ? Ca reste une boundig box evoluée, ça ne vaut pas une détection par opérations logiques sur des masques, ça ralentira quand même tes routines et augmentera la mémoire consommée...
Ah mais j'oubliais : tu crois qu'une démo et un jeu sont pareils....

je veux justement faire un jeu avec de gros sprites à l'écran.
Des gros vaisseaux, des gros bosses, des grosses explosions.

Allume une neo geo, une saturn ou une dreamcast, et tu verras que les shoot sont remplis de gros sprites.
Il n'y a que sur ta console de jeux avec clavier que tout est minablement petit, genre amstrad CPC.

Cassé !

Oui cassé : il est ou ton jeu avec des gros sprites partout ? Quand il existera là tu pourras l'ouvrir : encore une fois tu compares le mig à quelque chose qui n'existe que dans ta tête. C'est sur que je suis cassé... Et puisqu'il va bouffer Battle squadron d'après toi (au fait, tu as vu la taille des boss dans ce jeux ? Il ne sont pas minuscules. Et rien que le tirs des vaisseau remplissent plus l'écran), faudra qu'il intègre lui aussi un scroll horizontal.

Ah ? c'est pas prévu ? Je suis pas étonné...

Non, dès qu'il y a une texture, ça n'oblige pas à lire octet par octet, t'es vraiment incompétent en programmation pour écrire de telles inepties.

Et tu prouves encore ton niveau nullissime : quand tu appliques une texture, les pixels à ecrire qui seront contigus dans la destination ne le seront pas dans la source. Donc tu es bien obligé de les lire un par un. Tu les ecriras bien 4 par 4, ça pose pas de souci mais impossible d'en lire 4 en même temps...
Si tu comprends pas ça c'est que t'es encore plus nul que je croyais. J'ai déjà écris des routines de placage de texture plusieurs fois, je peux même expliquer ici la meilleure façon de faire sur ST/Amiga. Toi tu pourrais expliquer comment tu fais pour lire 4 pixels à la fois ? Encore du blabla...

En fait plus je te lis, plus je me rend compte que tu as un niveau merdique en programmation...

Je vais expliquer au lecteurs :
Prenons le cas de placage le plus simple : un zoom sans rotation.
Imaginons que le zoom est à un facteur 1/5 : pour l'obtenir il faudra lire un pixel sur 5 dans la texture (qui représente l'image taille 1) et écrire les pixels ainsi lus les uns à coté des autres dans la mémoire écran. Si on prend le cas d'un écran chunky en 256 couleurs pour faire simple, pour la première ligne, on lira les valeurs des octets situé au adresses mémoires suivantes :
Adresse de la texture
Adresse de la texture + 5
Adresse de la texture + 10
Adresse de la texture + 15

Pendant leur lecture ces octets seront stockés par 4 dans un registre pour être écris en même temps.

Et bien Archimerde le magnifique peut lire ces 4 adresse exemples en 1 seul accès mémoire !!!

Sur Amiga, à l'époque, on en était à gérer des mip-mappings avec les textures pour augmenter les "cache-hits". Mais toi tu expliques qu'il est possible de lire 4 pixels éparpillé en mémoire en même temps : t'es vraiment trop ridicule TU me traite d'incompétent...

OK : alors montre moi des Amiga avec plus de 64 Mo !
Tu m'affirmais que ton 68000 était meilleur car il adressait 2^32, et mon Archie 'seulement' 2^26.
C'est pas de la mauvaise foi ça ? Pour des machines qui a l'époque n'avait jamais plus de 16 Mo de RAM tellement ça coutait cher ?

Ah bon ? J'ai dit ça ? Je parlais de l'OS...

J'ai bien corrigé sur le nombre de MIPS : c'est 12 à 15 pour l'ARM3 à 25 Mhz

Oui bien sur avec une RAM à 8Mhz qui est déjà ralentie par le chipset... En plus ce sont toujoours des mips de processeurs RISC...

Et là attention je vais t'apprendre qqchose qu'un basher de ton genre va avoir du mal à intégrer : dans un algorithme en ARM on n'a que très rarement besoin de sauvegarder des données en cours de manipulation (sur la pile, donc accès mémoire couteux en temps).
Et devine pourquoi mon petit biquet ?
Parcequ'on a QUINZE registres 32 bits librement utilisables pour tout (adresse ou données, whatever), et donc en général les données on va les lire une fois, les traiter, et renvoyer les données de sortie.
Au cours de l'algo de traitement, on aura quasiment jamais besoin de sauvegarder des résultats intermédiaires, pour les recharger à nouveau et continuer l'algo.

Et là dessus ton 68000 de vieille conception, il est incapable de suivre.

Ah ah ah j'adore cette file de discussion, vraiment.

Et là attention je vais t'apprendre quelque chose : le 68000 a SEIZE registres 32 bits !!! LOL !!! Et il en a pourtant beaucoup moins besoin que ton Archimerde...

Moi j'adore pas ce fil : t'es juste idiot d'aborder des sujets que tu ne connais absolument pas...

Et quand tu avais ton 68060 moi j'avais le Strong ARM à 233 Mhz ou 266, et aussi avec mémoire rapide embarquée sur la carte fille (ça s'appellait Kinetic, et quand c'est sorti on était mort de rire en pensant au cout exhorbitant de ce qu'il vous fallait sur Amiga ou ST pour approcher nos benchs).

Ah bon ? un strongarm dans un Archimedes de 87 ?
Parce qu'il y avait des cartes 68060 pour tous les amigas...

Les études de taille de code sur ARM et autres processeurs ont montré une légère emphase de 15% côté ARM, ce qui n'est donc pas un gros désavantage.

Du bidon ces études. Suffit de lire les spécification du 68000 et de l'ARM pour ce rendre compte que c'est faux. Non seulement dans un programme 68000 la plupart des instructions font 16 bits, mais dès que ça les dépasse ce sera pour faire quelque chose qui obligera souvent ton ARM a en faire plusieurs (donc plusieurs fois 32 bits...)
Une division prend combien d'octet sur ARM ? des dizaine ou des centaines ? Sur 68000, c'est 2...
Tu dis "les études de taille" mais tu sors ça d'ou ? D'un magazine pour Archimedes ou d'un de tes reves ?

Tes inepties devraient être traduites et postées sur les forums Acorn.
Stupide à manger du foin, qu'il est le garçon.


Alors, démarrons le cassage :

Quand tu veux déplacer lentement un background, tu le fais tous les 25è de seconde, non ? Ben voilà, ça n'empêche pas que tout le reste soit en 50 images par seconde.
Et réfléchis, si vraiment ça posait un problème tu aurais une saccade tous les 25è de seconde, sur les sprites animés en 50 images par seconde, ce qui n'est pas le cas.


Un plan du fond en 4 couleurs ?
Mais t'as un petit vélo dans la tête ?
IL N'Y A PAS DE PLANS SUR ARCHIMEDES.
ON EST EN CHUNKY ET TOUS LES PIXELS PEUVENT ETRE DANS N'IMPORTE LAQUELLE DES 256 COULEURS CHOISIES DANS LA PALETTE.
Pfff.... et tu te prends pour un programmeur ou un type qui s'y connait en hardware ? Mais je suis mort de rire.

Oui le motif est répété 16 fois par ligne, et alors ?
Quand vous me montrez vos démos amigas débilitantes, ou un sprite est recopié 36 fois en scandant 'regarde mon Amiga c'est une super bécane' ça ne vous gêne pas ?
Là sur Archie on en fait en partie autant, et tu me démontes le truc ?
Mais t'es trop fort et impartial, j'aime.
Et t'as vu tous les autres éléments de décor qui bougent ?
Rêve toujours d'avoir ça un jour sur un Amiga de base, la bonne blague.

Tu ne sais pas de quoi tu parles : donne là ton hypothèse, basée sur des plans, sur une machine qui N'EN A QU'UN SEUL.

En effet en programmation tu me prouves bien que tu n'en touches pas une.

Ok alors commençons petit prétentieux qui ne comprend rien.

Je sais bien que le fond est à 25 i/s (et encore je me demande si c'est pas moins) à cause de sa vitesse. Et tu crois que c'est un hasard ? Sors nous un jeu avec le même scroll mais en plus rapide. On t'a cité des tas de jeux avec 2 layers (comme scorpius) voire plus qui scrolle bien plus vite sur Amiga. La technique du "je fais un scrolling lent comme ça je ne suis pas obligé de géré un layer entier à chaque frame et je récupère pleins de cycles" est hyper connue. Mais faut en tenir compte quand tu dis que le jeu tourne à 50 i/s.

Un Amiga de base ? Regarde les jeux qu'on t'a cité : il explosent ton scorpius en terme d'animation. Il affichent beaucoup plus de couleurs sur chaque plan et sans répétition du motif (alors que d'après toi c'est ce qu'il ya dans les démos : c'est faux même pour les jeux). Certains introduisent un scrolling différentiel sur CHAQUE ligne (Lion heart), d'autres ont encore plus de plans (M. Nutz). En plus, au final, il paraissent plus colorés que ton jeux en 256 couleurs... LOL !

Décidément tu comprends toujours de travers ; Scorpius est bien un jeu ou il y a un scrolling sur plusieurs plans (layer si tu préfères) ? Sur celui le plus au fond, il n'y a que 4 couleurs, n'est-ce pas ? Tu crois que c'est un choix artistique ? Et bien non, c'est pour économiser des cycles : tu sais pas comment ? Reconnais le et je vais t'expliquer comment on peut avoir un affichage chunky en 256 couleurs et limiter étrangement le nombre de couleurs sur certains éléments affichés...

Mon hypothèse n'est pas basé sur des plans, je sais bien qu'il n'y en a qu'un sur l'Archimedes...

Et ton hypothèse, elle serait basée sur quoi ? LDR/LDA comme d'habitude ? Le b.a.ba que tu crois être une révolution !

Reconnais publiquement que tu ne comprends pas pourquoi le fond ne contient que 4 couleurs et je te donnerai mon hypothèse. tu iras la soumettre dans des forums Acorn et de vrais codeurs te diront si elle est valable...

ça serait trop drole : un amigaiste qui n'a jamais touché un Archimedes qui expliquerait une optimisation à un type qui se prend pour un dieu de la programmation.

[Invité]

Que dire, à part qu'il à fallut encore une fois que stapha passe en mode explication pour benêts pour que tu comprennes .

je veux justement faire un jeu avec de gros sprites à l'écran.
Des gros vaisseaux, des gros bosses, des grosses explosions.

Allume une neo geo, une saturn ou une dreamcast, et tu verras que les shoot sont remplis de gros sprites.
Il n'y a que sur ta console de jeux avec clavier que tout est minablement petit, genre amstrad CPC.

On en reparlera quand tu auras autres choses à gérer qu'un scroll pourris et 3 gros sprites, le tout en soft, et avec une bande passante mémoire qui suivra pas(déjà dans ta demo, elle doit souffrir pas mal) .
Surtout avec tes DMA qui haltent le CPU .
déjà vu les besoins en RAM que nécessite ta demo, avec tout ce qu'il faut pour un shoot on va rigoler .

Lol, ça y'est tu vises la saturn maintenant, décidemment il est pleins de ressources l'archimedes
Tu penses qu'avec 2 teras de ram, tu pourras égaler une PS2 ???

@stapha: une division sur arm2 prend 480 octets et 176 cycles .

[MikeeMike_2008]

stapha 92 tu as mis du temps pour te rendre compte que c'est une bille en programmation notre archi-bouffon !!!

rien qu'en regardant son scroll (10 secondes) ca suffit pour se faire une opinion et le reste de sa préview-demo :lol: confirme l'avis des 10 premières secondes

[stapha92]

stapha92 win

LOL !

Mais pas de mérite... Il est tellement à coté de la plaque par moment (nous on a QUINZE registres : je lui avait déjà dit que le 68000 en a 16...)

Je vais expliquer le genre d'optimisations qu'on peut mettre en place sur ce genre de machine (parce qu'il ne va jamais expliquer ses routines à Touko vu qu'il les croit révolutionnaire...).

D'abord garder à l'esprit que l'Archimedes est une machine 32 bits, donc il faut privilégier ce type d'accès en lisant les octets 4 par 4 sur des adresses multiples de 4 (comme pour toutes les machines 32 bits).

Pour appliquer 4 pixels du sprite, il faut charger 32 bits dans un registre et écrire le contenu de ce registre dans une adresse mémoire qui correspond à la zone à traiter :

- 2 instructions,3 registres (2 pour les 2 adresse et 1 pour stocker les 32 bits) et 8 octets pour faire ça sur ARM.

- 1 instructions, 2 registres (uniquement les adresses, pas besoin de stocker la source dans un registre avant de l'écrire dans la destination : quand je dis que le 68000 utilise moins de registres et qu'il est plus souple) et 2 octets pour un 68000 (15% d'écart de taille en moyenne il disait ?). L'incrémentation des registres utilisés sera faite en même temps (et à mon avis sur l'ARM aussi)

Mais pour faire ça, il faut que la source ET la destination soient alignés sur 4 octets. Sinon il faut soit travailler octet par octet, soit faire un décalage de la source (genre, il y a un décalage d'un octet entre l'alignement de la source et la destination) avant de l'écrire. Mais ce décalage n'est pas si simple car il faut transférer les 8 bits qui se trouvent au début d'un registre vers la fin d'un autre (ou vice-versa). Là, son "décalage de bits gratuits ne marche plus dans ce cas. Donc ça bouffera des cycles.

La solution sera donc de stocker l'image du sprite à afficher 4 fois : une fois à une adresse multiple de 4, une fois a (une adresse multiple de 4) + 1, une fois à (une adresse multiple de 4) + 2 et une fois en + 3. Après il suffit de reprendre le même alignement que celui de la destination : si le sprite est aligné sur du + 1, on prendra la 2eme version du sprite.

1ere optimisation : ça multiplie la taille de ce qu'il faut afficher par 4. Et il critique les codeurs de jeux qui n'avaient pas 2 Mo, eux...

Continuons sur ce dernier exemple :

L'alignement est en +1 : il y a donc 3 pixels à afficher avant d'arriver sur un alignement de 4. On doit donc faire 3 accès en 8 bits (en fait pas forcément mais ça ne serait pas plus rentable).Si on fait une boucle qui va vérifier que l'adresse à traiter est un multiple de 4 (en fait on fait un compteur qui est initialisé en fonction des 2 derniers bits de l'adresse), ça perdra du temps. Donc on fait 4 routines d'affichage qui auront de 0 a 3 accès 8 bits qui se suivront avant de passer sur des accès en 32 bits.

Deuxième optimisation : on perd encore de la place mais rien de grave. c'est même négligeable (on a 4 fois une routine qui est toute petite), pour l'instant...

Que fais-ton après ? Et bien une boucle sur les accès 32 bits et on finit par retomber sur les derniers pixel qui ne seront pas forcément alignés (pour respecter l'alignement jusqu'au bout, il faut que le dernier pixel soit sur du +3 puisqu'il doit correspondre au dernier d'une série de 4 alignée). On utilse le même système qu'au début.

deuxième optimisation (suite) : là on a 4x4=16 fois la fameuse routine. Toujours rien de grave...

Ensuite ? Et bien on déroule tout ! On prépare des lignes de codes composés de :

- 0 a 3 lecture écriture en 8 bits

- 0 à n lecture écriture en 32 bits

- 0 à 3 lecture écriture en 8 bits

Là tout le monde comprend pourquoi je disais que les gros sprite avantageaient sa méthode : c'est avec eux que le n sera le plus grand et qu'il y aura le plus d'accès optimisés. Evidemment, ça c'est à condition qu'il n'y ait pas de trous dans le sprite car chaque trou génère 2 séquences 0 a 3 lecture écriture en 8 bits...

Tout le monde comprend le choix des sphères qu'il affiche : que des lignes pleines...

Revenons sur l'optimisation. ça revient à quoi de tout dérouler ?

Et bien c'est simple : plus de boucle. En fait on va générer, pour chaque sprite, le code qui correspond à chaque taille de ligne (cad le nombre d'octets à traiter) possible. C'est à dire 4 routines x le nombre de tailles de ligne. Pourquoi 4 et pas 16 ? Et bien on a toujours 4 possibilités d'alignement au début de la ligne mais pour, chacune d'elle, un seul alignement de fin possible puisque chaque routine traite un nombre fixe d'octets.

deuxième optimisation (fin) : ça prend de la place quand même ! parce que ce satané ARM a besoin de 2 instructions pour chaque lecture ecriture. Donc c'est 8 octets dans la routine pour traiter 4 ou 1 pixels...

Conclusion : ça tourne pas avec 1 Mo...

@Touko : 480 octets 176 cycles : Et il dit que ses ARM3 tiennent tete à un 68040/60 (qui eux intègrent une fpu...) ou que son Archimedes est le top pour le ray-tracing ? LOL !

@MikeeMike : LOL ! Mais au départ je n'aurai jamais critiqué son travail. Sauf que le voir insulter tout le monde, y compris ceux qui ont écris des VRAIS jeux, m'a pousser à adopter une attitude inhabituel : normalement je respecte le travail de tous les gens qui codent quelque soit le niveau de ce qu'il font et j'apporte mon aide avec grand plaisir à ceux qui le demande (même avec Archie : s'il remplit la condition, je lui expliquerais une optimisation qu'il n'a peut-être pas comprise)

[Invité]

petite appartée

Autre chose : moi à l'époque j'ai pris une télé 100 Hz comme moniteur et tu sais quoi ? Plus de scintillement ! Et elle coutait moins cher qu'un multisync ou un vga ! LOL !!!
Et je te rappelle qu'un A500 ECS sait générer du vga en natif...

j'utilisais une commande dos dans la startup du nom de "lace"quand cela était possible ça diminuait fortement l'effet de scintillement sur mon 1084.

une division sur arm2 prend 480 octets et 176 cycles

ah ouais quand même .

[ArchieForEver]

stapha92 win

LOL !

Mais pas de mérite... Il est tellement à coté de la plaque par moment (nous on a QUINZE registres : je lui avait déjà dit que le 68000 en a 16...)

Je vais expliquer le genre d'optimisations qu'on peut mettre en place sur ce genre de machine (parce qu'il ne va jamais expliquer ses routines à Touko vu qu'il les croit révolutionnaire...).

D'abord garder à l'esprit que l'Archimedes est une machine 32 bits, donc il faut privilégier ce type d'accès en lisant les octets 4 par 4 sur des adresses multiples de 4 (comme pour toutes les machines 32 bits).

Pour appliquer 4 pixels du sprite, il faut charger 32 bits dans un registre et écrire le contenu de ce registre dans une adresse mémoire qui correspond à la zone à traiter :

- 2 instructions,3 registres (2 pour les 2 adresse et 1 pour stocker les 32 bits) et 8 octets pour faire ça sur ARM.

- 1 instructions, 2 registres (uniquement les adresses, pas besoin de stocker la source dans un registre avant de l'écrire dans la destination : quand je dis que le 68000 utilise moins de registres et qu'il est plus souple) et 2 octets pour un 68000 (15% d'écart de taille en moyenne il disait ?). L'incrémentation des registres utilisés sera faite en même temps (et à mon avis sur l'ARM aussi)

Mais pour faire ça, il faut que la source ET la destination soient alignés sur 4 octets. Sinon il faut soit travailler octet par octet, soit faire un décalage de la source (genre, il y a un décalage d'un octet entre l'alignement de la source et la destination) avant de l'écrire. Mais ce décalage n'est pas si simple car il faut transférer les 8 bits qui se trouvent au début d'un registre vers la fin d'un autre (ou vice-versa). Là, son "décalage de bits gratuits ne marche plus dans ce cas. Donc ça bouffera des cycles.

La solution sera donc de stocker l'image du sprite à afficher 4 fois : une fois à une adresse multiple de 4, une fois a (une adresse multiple de 4) + 1, une fois à (une adresse multiple de 4) + 2 et une fois en + 3. Après il suffit de reprendre le même alignement que celui de la destination : si le sprite est aligné sur du + 1, on prendra la 2eme version du sprite.

1ere optimisation : ça multiplie la taille de ce qu'il faut afficher par 4. Et il critique les codeurs de jeux qui n'avaient pas 2 Mo, eux...

Continuons sur ce dernier exemple :

L'alignement est en +1 : il y a donc 3 pixels à afficher avant d'arriver sur un alignement de 4. On doit donc faire 3 accès en 8 bits (en fait pas forcément mais ça ne serait pas plus rentable).Si on fait une boucle qui va vérifier que l'adresse à traiter est un multiple de 4 (en fait on fait un compteur qui est initialisé en fonction des 2 derniers bits de l'adresse), ça perdra du temps. Donc on fait 4 routines d'affichage qui auront de 0 a 3 accès 8 bits qui se suivront avant de passer sur des accès en 32 bits.

Deuxième optimisation : on perd encore de la place mais rien de grave. c'est même négligeable (on a 4 fois une routine qui est toute petite), pour l'instant...

Que fais-ton après ? Et bien une boucle sur les accès 32 bits et on finit par retomber sur les derniers pixel qui ne seront pas forcément alignés (pour respecter l'alignement jusqu'au bout, il faut que le dernier pixel soit sur du +3 puisqu'il doit correspondre au dernier d'une série de 4 alignée). On utilse le même système qu'au début.

deuxième optimisation (suite) : là on a 4x4=16 fois la fameuse routine. Toujours rien de grave...

Ensuite ? Et bien on déroule tout ! On prépare des lignes de codes composés de :

- 0 a 3 lecture écriture en 8 bits

- 0 à n lecture écriture en 32 bits

- 0 à 3 lecture écriture en 8 bits

Là tout le monde comprend pourquoi je disais que les gros sprite avantageaient sa méthode : c'est avec eux que le n sera le plus grand et qu'il y aura le plus d'accès optimisés. Evidemment, ça c'est à condition qu'il n'y ait pas de trous dans le sprite car chaque trou génère 2 séquences 0 a 3 lecture écriture en 8 bits...

Tout le monde comprend le choix des sphères qu'il affiche : que des lignes pleines...

Revenons sur l'optimisation. ça revient à quoi de tout dérouler ?

Et bien c'est simple : plus de boucle. En fait on va générer, pour chaque sprite, le code qui correspond à chaque taille de ligne (cad le nombre d'octets à traiter) possible. C'est à dire 4 routines x le nombre de tailles de ligne. Pourquoi 4 et pas 16 ? Et bien on a toujours 4 possibilités d'alignement au début de la ligne mais pour, chacune d'elle, un seul alignement de fin possible puisque chaque routine traite un nombre fixe d'octets.

deuxième optimisation (fin) : ça prend de la place quand même ! parce que ce satané ARM a besoin de 2 instructions pour chaque lecture ecriture. Donc c'est 8 octets dans la routine pour traiter 4 ou 1 pixels...

Conclusion : ça tourne pas avec 1 Mo...

@Touko : 480 octets 176 cycles : Et il dit que ses ARM3 tiennent tete à un 68040/60 (qui eux intègrent une fpu...) ou que son Archimedes est le top pour le ray-tracing ? LOL !

@MikeeMike : LOL ! Mais au départ je n'aurai jamais critiqué son travail. Sauf que le voir insulter tout le monde, y compris ceux qui ont écris des VRAIS jeux, m'a
pousser à adopter une attitude inhabituel : normalement je respecte le travail de tous les gens qui codent quelque soit le niveau de ce qu'il font et j'apporte mon aide avec grand plaisir à ceux qui le demande (même avec Archie : s'il remplit la condition, je lui expliquerais une optimisation qu'il n'a peut-être pas comprise)

Les 15 registres de l'ARM (au fait : c'est en mode USER) sont librement utilisables pour tout : adresses et données.

Ton 68000 est contraint : il en a la moitié de ses registres pour des adresses (7), l'autre pour des données (8).
Ca change énormément la donne : sur ARM j'ai nettement plus de possibilités de traiter un algo sans sauvegarde intermédiaire de données.
Et ça aide bien pour la taille du code.


Tes exemples où l'ARM doit faire l'équivalent en plusieurs instructions sont merveilleusement bien choisis.
Je peux t'en sortir quelques uns aussi.
CMP R0,R3
ADDGT R0,R1,R3,LSL#8 : si R0 strictement supérieur à R3, alors R0=R1+R3*256
ADDLT R0,R1,R10,LSR#2 : si R0strictement inférieur à R3, alors R0=R1+R10/4
LDREQ R0,[R12,R8,LSL#5]! : si R0=R3, alors R0=contenu de ce qui est à l'adresse R12+R8*32, puis R12=R12+R8*32
Donne moi le code 68000, juste pour rire un peu .... et taille et nombre de cycles.
Là sur ARM c'est 1 cycle par instruction, que les additions soient effectuées ou non.
1 cycle si l'accès mémoire n'est pas réalisée, sinon c'est 4.
Et ça prend 16 octets, soit 4 octets par instruction.
Je parie qu'à moins de 25 octets ton 68000 est incapable d'en faire autant.
Et je parie que le résultat sera incomparablement plus lent, quelque soit le cas logique.
:compress:

Puisque tu aimes bien parler de la mémoire, dis moi en combien d'instructions tu vas transférer 15 résultats 32 bits issus de calculs (donc tous fraichement dans les registres).
Combien d'instruction au 68000, qui n'a que 8 registres de données ?
Sur ARM :
STMIA R0,{R1-R14} : envoie les contenus de R1 à R14 à l'adresse R0, R0+4,R0+8 etc ...
Avec l'incrémentation de R0 en fin d'opération en 0 cycle si je rajoute '!'
STMIA R0!,{R1-R14}

Alors tu vois, ton 68000 est dépassé.
Au final l'ARM sort gagnant, car la majorité des opérations effectuées dans les algos tombent dans le cas des instructions rapides de l'ARM, et les cas d'optimisations où l'ARM s'en sort gagnant haut la main avec très peu d'instructions.
Tu le sais mais tu l'omets, car comme les autres Amiga bashers tu n'es pas objectif.
Tu ne vaux pas mieux que le toutcon : toujours prompt à cracher sur un système qu'il ne connait pas, et incapable de supporter l'idée que l'Amiga lui soit inférieur.

L'ARM n'est pas que 2 fois plus rapide que le 68000, non non non.
Le facteur est en moyenne de 4 à 6.
C'est objectivement ce que tous les magazines d'infos ont pubilé en benchmarkant un ARM à 8 Mhz et un 68000 à 8 Mhz.


Tu te donnes bcp de mal pour tes explications sur ce que pourraient être des optimisations pour des routines graphiques sur Archie.
Mon commentaire: 'peut BEAUCOUP mieux faire'.
Tu as compris certains principes, mais l'essentiel t'échappe.
Ne cherche pas à faire croire que tu maîtrises le sujet : ce n'est pas le cas.
Tu tâtonnes et tu merdoies dans tes conclusions et la mise en oeuvre.
Quasiment tout ce qui est subtile t'échappe, en vérité.
La version la + rapide que tu donnes correspond à mes premières beta versions de routines.
Depuis je fais minimum 30% + rapide, et bcp plus léger en RAM.

Et pour Scorpius : tu peux toujours tenter une explication, mais sachant qu'il n'y a pas de bitplans sur Archie, tu ferais mieux de la garder car tu seras forcément ridicule.


Ahhh... la fameuse division sur ARM.
C'est vrai : un CPU passe son temps à faire des divisions, hein ? C'est bien connu
Ca vient d'où cette taille de code et ce nombre de cycles, en 'worst case scenario' je parie ?
Page 2-47 du manuel de VLSI j'ai un code en 12 instructions, soit 48 octets.
C'est 48, pas 480 comme le toutcon le dit.
Et tu reprends ses propos calomnieux, montrant que toi aussi tu n'es qu'un membre de la team force des débileux pro Amiga obstinés de ce forum.
Mais c'est vrai j'oubliais que toutcon c'est notre spécialiste du blitère à 77 Mhz !

Donne moi donc les cycles pour ta superbe instruction de division sur 68000, qu'on rigole.
C'est tellement lent sur tous les CPU, y compris les 68000, que n'importe quel bon programmeur évite de diviser, et va procéder avec des décalages quand il connait son dénominateur, ou bien des tables.

Je rappellerai aussi les bases des mathématiques : A / B = A * 1/B
Alors Stapha92, tu es suffisamment de mauvaise foi pour ne pas préciser ça dans tes 'démonstrations' ? T'es bien juste un Amigaïste, version moins bêta qu'un toutkon.

Je te réaffirme que le MEMC m'offre la possibilité de scroll horizontal sans les soucis que tu évoques. C'est très mal expliqué dans la doc de VLSI, mais je l'ai fait, ça tourne.
Tu le verras (j'imagine bien avant de voir la démo de toutcon censée copier ma démo Archie).

Puisque tu es prompt à tenter de donner des cours de programmation, stp explique à toutcon que pour faire un scroll hardware sur une bécane chunky, on a bien besoin d'au moins 3 banks écran.
Pourquoi ?
Quand on ne scrolle pas, il en faut déjà 2 : on affiche l'une, pendant qu'on travaille sur l'autre.
Pour pouvoir se déplacer, c'est à dire 'scroller', il faut bien au moins une autre bank.

Je ne sais pas d'où tu sors le besoin d"avoir 740 Kb pour faire ça, sans doute de ton esprit malade, mais bon si tu aimes fort divaguer, ça me va.

Je confirme à nouveau que pour faire du mapping de texture, on n'a pas besoin de lire en byte à byte.
C'est logique, réfléchis. Sans doute la plus grosse erreur que tu fasses en raisonnement ARM.

PS : Et oui l'Archie explosait l'Amiga pour le raytracing : car tous les 2 travaillaient sur des entiers, mais comme l'ARM calcule 4 à 6 fois plus vite que le 68000 de ton Amiga, l'Archimedes était loin devant.
Tout le monde l'admet, sauf toi.
Ensuite, en ce qui concerne l'ARM3, il n'a pas de copro, mais le FPU Acorn existait, on pouvait l'ajouter sur les cartes mères d'Archimedes.
Mais, l'ARM3, à 25 Mhz, s'en sortait tellement bien, et mieux en fait que ton 68020 à 14 Mhz avec son copro mathématique ...

[Invité]

une division sur arm2 prend 480 octets et 176 cycles

ah ouais quand même .

Oui l'arm2 ne dispose pas d'instruction de division, donc c'est fait en soft .
Ce que je donne comme valeur, ce sont celles d'un prog arm qui avait fait sa routine de division .
Donc c'est variable .

@MikeeMike : LOL ! Mais au départ je n'aurai jamais critiqué son travail. Sauf que le voir insulter tout le monde, y compris ceux qui ont écris des VRAIS jeux, m'a pousser à adopter une attitude inhabituel : normalement je respecte le travail de tous les gens qui codent quelque soit le niveau de ce qu'il font et j'apporte mon aide avec grand plaisir à ceux qui le demande (même avec Archie : s'il remplit la condition, je lui expliquerais une optimisation qu'il n'a peut-être pas comprise)

Exactement, je pense la même chose, dire que les devs ST/AMIGA sont trop nul parce que lui il déchire, etc.., m'a gonflé au plus haut point.
Je critique pas sa demo, mais son attitude et ses propos sur les autres devs, par rapport à ce qu'il a fait.

@archiotte,elle est variable entre 32 et 116 cycles et prend 452 octets.
Et c'est fou ta faculté à esquiver quand ca arrange pas ton arm2 ..

http://www.renan.org/ARM/
Mais je suppose que ce mec doit être un gros guignol, d'ancien amigaiste /STiste.
D'ailleurs il fait une remarque intéressante sur la fpu des arm.

C'est vrai : un CPU passe son temps à faire des divisions, hein ? C'est bien connu
Ca vient d'où cette taille de code et ce nombre de cycles, en 'worst case scenario' je parie ?
Page 2-47 du manuel de VLSI j'ai un code en 12 instructions, soit 48 octets.
C'est 48, pas 480 comme le toutcon le dit.

Mouai, tu dois être le seul à la connaitre alors, soumets lui, et n'oublies pas aussi de le traiter de sous merde, qui sais pas faire une routine de div correctement au passage..

Déjà vas comprendre le fonctionnement d'un blitter, d'ailleurs je te vois plus en parler lol ..
La doc t'aurait elle calmé ?? .

[ArchieForEver]

une division sur arm2 prend 480 octets et 176 cycles

ah ouais quand même .

Oui l'arm2 ne dispose pas d'instruction de division, donc c'est fait en soft .
Ce que je donne comme valeur, ce sont celles d'un prog arm qui avait fait sa routine de division .
Donc c'est variable .

N'importe quoi ! Encore une superbe Toukonnerie de plus.
Il n'y a que ta connerie qui soit variable : de immense à incommensurable !

La routine de division prend en tout et pour tout 48 octets.
Tes 480 octets, soit 10 fois plus, c'est ta mauvaise foi amigaïste qui est une fois de plus passée par là.

[ArchieForEver]

une division sur arm2 prend 480 octets et 176 cycles

ah ouais quand même .

Oui l'arm2 ne dispose pas d'instruction de division, donc c'est fait en soft .
Ce que je donne comme valeur, ce sont celles d'un prog arm qui avait fait sa routine de division .
Donc c'est variable .

@MikeeMike : LOL ! Mais au départ je n'aurai jamais critiqué son travail. Sauf que le voir insulter tout le monde, y compris ceux qui ont écris des VRAIS jeux, m'a pousser à adopter une attitude inhabituel : normalement je respecte le travail de tous les gens qui codent quelque soit le niveau de ce qu'il font et j'apporte mon aide avec grand plaisir à ceux qui le demande (même avec Archie : s'il remplit la condition, je lui expliquerais une optimisation qu'il n'a peut-être pas comprise)

Exactement, je pense la même chose, dire que les devs ST/AMIGA sont trop nul parce que lui il déchire, etc.., m'a gonflé au plus haut point.
Je critique pas sa demo, mais son attitude et ses propos sur les autres devs, par rapport à ce qu'il a fait.

@archiotte,elle est variable entre 32 et 116 cycles et prend 452 octets.
Et c'est fou ta faculté à esquiver quand ca arrange pas ton arm2 ..

http://www.renan.org/ARM/
Mais je suppose que ce mec doit être un gros guignol, d'ancien amigaiste /STiste.
D'ailleurs il fait une remarque intéressante sur la fpu des arm.

C'est vrai : un CPU passe son temps à faire des divisions, hein ? C'est bien connu
Ca vient d'où cette taille de code et ce nombre de cycles, en 'worst case scenario' je parie ?
Page 2-47 du manuel de VLSI j'ai un code en 12 instructions, soit 48 octets.
C'est 48, pas 480 comme le toutcon le dit.

Mouai, tu dois être le seul à la connaitre alors, soumets lui, et n'oublies pas aussi de le traiter de sous merde, qui sais pas faire une routine de div correctement au passage..

Déjà vas comprendre le fonctionnement d'un blitter, d'ailleurs je te vois plus en parler lol ..
La doc t'aurait elle clamé ?? .

Petite mise au point : j'ai dit que ce que vous montriez comme extraordinaire sur Amiga ne pouvait que faire sourire un possesseur d'Archimedes.
Pourquoi ? Car vous vous gargarisez de ce que vous pouvez faire de mieux qu'un ST, là où l'Archimedes plane bien au dessus.
C'est sûr que sur Archie tout le monde s'en tape de faire des parallax ou de la démultiplication de sprites identiques à l'écran... On est vite fait passé à la 3D, au mapping, etc ... c'est bien pour ça que j'entends m'occuper de la 2D, qui a été délaissé.

C'est vrai que sur ST et Amiga, qui ne sont que de petites machines de jeux, on peut admirer les grosses feintes et ficelles employées par les demomakers.
Ca plussoit les developpeurs, pas les machines, faiblardes et dépassées par rapport à un Archie, même de base.

Pour la division, oui Renan se trompe.
Il a une routine parmi d'autres.
Devinez quoi : INCROYABLE ! Il n'existe pas qu'un seul algo pour diviser !
Hé ! C'est fou non ? Grâce à moi vous allez encore vous coucher moins stupides ce soir.

Tiens, voilà celle de la doc VLSI, histoire de vous mettre bien le nez dedans :
Référence: manuel VL86C010 32-BIT RISC MPU AND PERIPHERALS USERS MANUAL
(ISBN 0-13-944968-X. Prentice Hall, Englewood Cliffs, N.J. 07632)
Page 2-47

Division and remainder
;Paramètres d'entrée : R0 et R1

MOV R4,#1

.Div1
CMP R1,#&80000000
CMPCC R1,R0
MOVCC R1,R1,LSL#1
BCC Div1
MOV R2,#0

.Div2
CMP R0,R1
SUBCS R0,R0,R1
ADDCS R2,R2,R4
MOVS R2,R4,LSR#1
MOVNE R1,R1,LSR#1
BNE Div2

Le résultat de la division est dans R2
Le reste de la division est dans R0

La belle affaire !

J'attends toujours les temps pour une division sur 68000.


Et ne prenez pas ce qui est sur son site pour argent comptant.
Tsss tsss : on dirait du toutcon qui boit les infos des wikis comme si c'était l'Evangile.
Bien évidemment les ray tracers savent travailler sans flottant, uniquement avec des entiers qui vont ensuite être décalés.
Ca s'appelle de l'arithmétique en point fixe.
C'est sûr sur votre 68000 de merde où ça prend nettement plus de temps que sur ARM de traiter 32 bits, vous n'irez pas bien loin. (Votre ALU a une largeur de 16 bits, autant dire que c'est une poubelle par rapport celui d'un ARM).
Ainsi, sur ARM, en point fixe, on aura de meilleurs résultats que sur votre trottinette.

Je viens une fois de plus de démontrer que vous déblaterez sur une famille de machines que vous ne connaissez pas.
Cassé !

[ArchieForEver]

@ all

Je reviens sur un point qui sort souvent ici.
Avec un bon petit air narquois, vous me demandez comment l'Archimedes pouvait soit disant avoir autant de bons softs que je le dis.
Et bien voilà l'équation : Acorn a toujours eu des développeurs pour ses machines (Atom, BBC B, Master).
Les débouchés des machines d'Acorn c'était l'éducation.
Ca couvre donc :
- collège
- lycée
- université (avec ses labos de recherche)
- école d'ingénieur
ce qui fait que le marché n'était pas inintéressant, loin de là, car ces entités PAIENT les softs et ne vont pas s'amuser à prendre une licence monoposte pour mettre sur de multiples machines.
A ce marché on peut ajouter celui de tous les enseignants et chercheurs.
Hé oui ! Quand il y a l'ordi sur le lieu de travail, c'est bien tentant d'avoir le même à la maison, non ? (surtout qu'Acorn faisait des tarifs spéciaux pour enseignants).
Voilà comment tant de nombreux softs de qualité sont arrivés sur les machines d'Acorn.
Sans oublier qu'il y avait la remontée des projets développés en université sur machines Acorn, qui ensuite allaient être étoffés et publiés sous forme de softs commerciaux par une société déjà installée.

C'est sûr, on est loin du marché de l'Amiga, où l'âge mental moyen de l'utilisateur oscillait autour de 5 ans, et il était si fier de montrer ses boîtes entières de softs piratés. Areuuhhh areuhhh.
Pas étonnant que dès que les éditeurs ont pu dire 'FUCK' au monde ST/Amiga en allant sur PC, ils l'ont fait.


Juste pour rire, je retrouve un article sur Eidos dans un Acorn User de mai 1996.
Saviez vous que Eidos était une société qui n'oeuvrait que sur Archimedes ?
Béh non, hein.
Il faisait des CODECs MPEG tout en soft, et uniquement sur ARM, tellement c'était supérieur au PC de l'époque en termes de rapport qualité / prix.
On ne parle même pas de 680x0 ou de powerPC tellement c'est loin du compte.

A tel point qu'Oracle signait ce mois là avec Eidos un accord de partenariat pour ses set top boxes et autres produits.

Ah... mais c'est vrai j'oubliais : vous vomissez l'Archimedes sans jamais en avoir eu un entre les mains, sans jamais en avoir programmé un, sans jamais avoir eu entre les mains un seul magazine qui lui était consacré.

En bref : vous êtes juste des gros .... d'amigaïstes.

[Invité]

N'importe quoi ! Encore une superbe Toukonnerie de plus.
Il n'y a que ta connerie qui soit variable : de immense à incommensurable !

La routine de division prend en tout et pour tout 48 octets.
Tes 480 octets, soit 10 fois plus, c'est ta mauvaise foi amigaïste qui est une fois de plus passée par là.

T'es tellement con que tu n'as même pas remarqué que je parlais de variable en nombre de cycle, pas de place sombre crétin .
Mais c'est pas possible de comprendre que ce qui t'arrange,et de m'insulter, sans avoir rien compris.
Lis les post correctement avant de la ramener .
bien sur ta science comme celle du piaf, est au dessus de tout ça ..
Pauvre archiotte, tu me fais pitié .

LOL tes exemples ne gérent que les nombres entiers, et positifs .
Contrairement à celle de ronan qui elle gére les nombres négatifs, tout comme l'instruction DIVS du 680x0, donc ta tentative d'esbrouffe, ca sera pour la prochaine fois .

Donc avec des exemple qui font la moitié des choses à faire sur une division, effectivement ça va vite, et ça prend pas bcp de place .

Voilà ce que fait le 680x0 pour les divs :

DIVU performs unsigned division, and DIVS performs signed
division on two's complement numbers.
– The 32-bit long word in the data register is divided by the 16-bit
word at the effective address.
– The 16-bit quotient is stored in the lower-order word of the register
and the remainder is stored in the upper-order word.

Maintenant je parierais pas qu'elles soient plus rapide que la routine de ronan .

On vomis pas l'archimedes, mais plutôt sur un gros con qui se prend pour un dieu mais qui n'est rien d'autre qu'un michael vendetta de la prog,et qui se la péte avec sa PROGRAMITUDE .
Alors que tu es le seul dev sur archimedes à être aussi débile, et prendre tout le monde de haut.
Comme je te l'ai dit, au lieu de perdre ton temps ici,vas sur un forum de dev amiga/ST, et tu tiens le même discours sur la nullité des devs sur ces machines, et on verra se qu'il se passe, puisque on est que des incompétents ici .

Et j'attends toujours la description des techniques utilisées dans ta demo ..

Et arrêtes de parler feinte, parce que tu en fais des kilos dans ta demo, rien que le fait d'utiliser tes timer comme interruption hsync/vblanc, ou ton triple buffering, etc ...
Les dernières super demos que tu à montré, en lisant les NFO (ce que tu n'as pas fait), le mec expliquait qu'il avait utilisé plein de trics et de precalc, alors stp, arrêtes de te faire du mal en passant pour un trou d'uc, en soutenant mordicus, que les trics c'est que sur ST/AMIGA que ça existe .
Dans ta demo il te reste tellement peu de ressources que tu es obligé de charger tes 3 écrans en mémoire pour ton scroll pour éviter qu'il se casse la figure ..

[babsimov]

@ all

Je reviens sur un point qui sort souvent ici.
Avec un bon petit air narquois, vous me demandez comment l'Archimedes pouvait soit disant avoir autant de bons softs que je le dis.
Et bien voilà l'équation : Acorn a toujours eu des développeurs pour ses machines (Atom, BBC B, Master).
Les débouchés des machines d'Acorn c'était l'éducation.
Ca couvre donc :
- collège
- lycée
- université (avec ses labos de recherche)
- école d'ingénieur
ce qui fait que le marché n'était pas inintéressant, loin de là, car ces entités PAIENT les softs et ne vont pas s'amuser à prendre une licence monoposte pour mettre sur de multiples machines.
A ce marché on peut ajouter celui de tous les enseignants et chercheurs.
Hé oui ! Quand il y a l'ordi sur le lieu de travail, c'est bien tentant d'avoir le même à la maison, non ? (surtout qu'Acorn faisait des tarifs spéciaux pour enseignants).
Voilà comment tant de nombreux softs de qualité sont arrivés sur les machines d'Acorn.
Sans oublier qu'il y avait la remontée des projets développés en université sur machines Acorn, qui ensuite allaient être étoffés et publiés sous forme de softs commerciaux par une société déjà installée.

Avoir un monopole sur un marché est un avantage, mais regarde Thomson ça les a pas aidé à obtenir des logiciels "phares".
L'Archimède ou Archimèdes avait certainement de bons logiciels, mais ça ne veut pas dire que l'Amiga et aussi le ST n'avaient pas des logiciels de niveau professionnels. D'ailleurs on t'a ici donné des exemples tout de même reconnus unanimement dans le milieu pro et tu n'arrêtes pas de dire que c'est "limite" des petits logiciels DP dévelloppé par un adolescent dans son garage. Cubase et Lightwave QUAND MEME ! J'ai volontairement forcé le trait, mais quand on te lit il y a de quoi.

Reprenons la stratégie commerciale d'Acorn, n'est il pas dommage de disposer d'une machine qui semble aussi puissante et de ne pas chercher à augmenter son marché ? Si ce que tu avances au sujet de l'Archimède se vérifie, Acorn et ses ingénieurs devaient tout de même bien savoir qu'ils avaient le top du top en informatique ? Parce que si on t'écoute l'Amiga était largué, alors le MAC et le PC on en parle même pas ! Avec ces deux machines (PC/MAC) on reste bien dans le marché visé par Acorn, (tout sauf le familial) ? Il fallait alors créer des filiales tout autour du monde et ECRASER tous les autres ? Mais, ça n'a pas été le cas. Les ingénieurs d'Acorn connaissaient peut être les limites de leur machine ?
Comme je l'ai dit, je te donne le bénéfice du doute. Je pense effectivement que l'Archimède était une machine fort sympathique et puissante pour l'époque.
Toutefois, tu me sembles un peu trop imbu de ta personne. En te relisant, j'ai découvert que la démo que tu présentes date de 20 ans. Quand ici, les programmeurs la critiquent, tu te défend avec l'argument "c'est vieux, ça fait 20 ans, depuis c'est super au top". Dans ce cas, il valait mieux mettre sur youtube ta démo d'aujourd'hui, optimisée à fond. Même une béta, mais quelque chose de récent.
Tu t'es tellement vanté que je pense tu as exaspéré tout le monde. Si tu veux vraiment "casser" comme tu dit, alors montre ton super jeu ou ta super démo récente qui doit égaler, sinon surpasser un Amiga 500 voir même une Néo Géo.

C'est sûr, on est loin du marché de l'Amiga, où l'âge mental moyen de l'utilisateur oscillait autour de 5 ans, et il était si fier de montrer ses boîtes entières de softs piratés. Areuuhhh areuhhh.
Pas étonnant que dès que les éditeurs ont pu dire 'FUCK' au monde ST/Amiga en allant sur PC, ils l'ont fait.

Parce que tu penses qu'à l'époque sur Archimède, en Angleterre, il y avait pas aussi des "échanges de logiciels" entre utilisateurs ? Ca existe sur toutes les machines et c'était encore plus vrai sur PC à l'époque (peu de protection) et parc installé encore plus important que ST/Amiga.
Quand à ton image de l'Amigaiste je la trouve outrancière !
Tu te prends pour qui pour donner des leçons ? Et c'est toi qui prétendait que le ton que j'employais te semble "outrancier" alors que je posais une simple question.
Personne ne dit que l'Archimède n'est pas une bonne machine. Ici on te dit juste qu'on doute de tes affirmations sur la supériorité de cette machine en 2D sur un Amiga avec ses coprocesseurs. Insulter tout ceux qui ont une opinion différente de la tienne ou qui te font des remarques que je trouve constructives ne fait que nuire à ta crédibilité.
Montre quelque chose de plus récent qu'une ancienne démo, à tes débuts sur Archimède. Ou alors un niveau du jeu que tu prépares et ça permettra de voir si tu as raison ou non.

Juste pour rire, je retrouve un article sur Eidos dans un Acorn User de mai 1996.
Saviez vous que Eidos était une société qui n'oeuvrait que sur Archimedes ?
Béh non, hein.
Il faisait des CODECs MPEG tout en soft, et uniquement sur ARM, tellement c'était supérieur au PC de l'époque en termes de rapport qualité / prix.
On ne parle même pas de 680x0 ou de powerPC tellement c'est loin du compte.

A tel point qu'Oracle signait ce mois là avec Eidos un accord de partenariat pour ses set top boxes et autres produits.

Ne trouves tu pas assez logique que dans une revue Archimède on évite de parler 680x0 et PowerPC ?
J'arrive pas à comprendre pourquoi tu as une telle haine du 68000 ? Tu le compares avec un processeur 32 bits conçu dix ans après ? Tu n'a pas l'impression que c'est normal qu'un ARM soit plus puissant à fréquence égale ? Compare plutôt avec un Amiga 2500 (68020/68030 je sais plus) pour la puissance pure.
Tu négliges toujours l'impact des coprocesseurs sur Amiga.
On peut aussi prendre le X68000 japonais. Les jeux portés dessus étaient tout de même quasi identique à ceux de l'arcade ! Mais, il avait des coprocesseurs aussi, curieux. Un processeur SEUL ne fait pas tout. J'en ai toujours été convaincu.
http://en.wikipedia.org/wiki/Sharp_X68000
https://www.gamopat-forum.com/t38282-le-x68000-et-la-superiorite-japonaise

Je n'ai pas trouvé le nombre de couleurs affichables et les résolutions. Mais, il me semble que c'était au moins 256. Tu vas nous dire que l'ARM éclate un X68000 ? Regarde un peu les vidéos sur le sujet gamopat.
Au vu des vidéos, n'est il pas préférable d'avoir un processeur "basique" accompagné de coprocesseurs spécifiques pour l'affichage, le son ? Tu vois ce qu'il est possible de faire en 1987 avec un simple 68000 de 1979 et des copros.
Je doute qu'un ARM avec ses 4 mips puisse arriver à faire la même chose, SEUL, la puissance brute ne fait pas tout. Autrement, un PC 386 avec une carte VGA aurait du surpasser de loin un Amiga en 2D, ce n'était pas le cas. Comment tu l'expliques ?

Ah... mais c'est vrai j'oubliais : vous vomissez l'Archimedes sans jamais en avoir eu un entre les mains, sans jamais en avoir programmé un, sans jamais avoir eu entre les mains un seul magazine qui lui était consacré.

En bref : vous êtes juste des gros .... d'amigaïstes.

Je rappel qu'il était très difficile de se procurer un Archimède en France à l'époque ou d'avoir la chance de connaitre quelqu'un qui en avait un.
Par contre c'est plutôt toi qui vomi l'Amiga et qui ne semble pas en avoir eu un entre les mains (ou alors juste vu dans une vitrine, puisque tu ne sais pas ce que contient réellement la ROM Kickstart).

J'ai l'impression que c'est ta façon d'être imbu de toi qui est vomi sur le forum.
Personne ne dit que l'Archimède n'avait pas des qualités, il y a juste un doute sur tes affirmations qu'il peut égaler ou mieux surpasser l'Amiga en 2D.
Les quelques vidéos que tu as posté ne sont pas vraiment concluantes pour l'instant.

S'il te plait, montre nous une version RECENTE de tes routines (ta démo, ou ton jeu) et il sera plus facile de ramener un peu de sérénité dans ce sujet et de parler vraiment avec du concret, plutôt que tes affirmations invérifiables telles quelles.

Merci

[Invité]

Juste pour dire que j'avais très envie de m'intéresser à l'Archimedes mais que maintenant, je suis un peu dégoûté. Ce sujet de discussion est haineux, les insultes (et pas les rigolotes, comme on pouvait en trouver sur le sujet ST vs Amiga) fusent, c'est chiant à lire.

Dommage.

[ArchieForEver]

@babsimov : relis la file depuis le début, et celle intitulée 'Archimedes A3020' et tu comprendras mieux qui a insufflé un tel ton : le toutcon, comme l'a presque renommé Oiseaudeproie.
Il ne déblatère que des stupidités, d'une mauvaise foi inimaginable.
Comme je suis très loin du genre à être sympathique quand on quitte un débat équilibré, j'ai suivi le guide.

En vrac d'autres réponses :
- je fais bien ce que je veux avec ce que j'envoie sur Youtube, personne n'est obligé de regarder. A mon sens ça servait de teaser puisque la suite sera visible dans moins d'un mois. Donc, en fait avec des mots simples : ton avis sur la question dans ce cas précis tu te le gardes, je ne me lève pas le matin ni ne me couche le soir avec l'idée de te contenter.
- pour quoi ne dites-vous pas halte à la mauvaise foi de toutcon 1er ?
Il évoque clairement 480 octets, je le cite :
'une division sur arm2 prend 480 octets et 176 cycles
'
puis maquille ça en autre chose, comme il a fait sur tous ces autres posts, et ça vous laissez pisser ?
Il parle de scroll hardware précalculé etc etc mais ça non pas de soucis pour vous.
Il n'y a pas un post sans de grossières erreurs de logiques, des attaques infondées, des trucs tellement stupides que sur un forum de développeurs il se ferait descendre en flammes.
Mais vous cautionnez par votre silence.

Du coup :allez faire la morale à d'autres que moi dans ce cas, qui suis quasiment seul contre tous. Faut dire, ça tombe bien : je suis le seul à avoir un Archimedes et m'y connaitre en programmation.

A dans plusieurs jours, vous m'avez tous bien assez fatigué aujourd'hui.
Et je vous emmerde, clairement, si vous voulez vraiment connaître le fond de ma pensée (en 48 octets, et en signé c'est bon aussi).

L'Amiga ça restera bien pour moi une machine de 99% de trouducs qui n'ont fait que jouer et jamais rien apprendre ou créer.

[Lesarthois]

La mauvaise foi, les insultes et la mauvaise foi (oui, ça compte double) ca fatigue aussi...

[65c02]

Donc en résumé

l'Amiga à un blitter et un copper
l'archimede à un arm
- merde!
- toi même connard !

l'amiga à des bitplans
- trop nul, faut écrire 5 octets pour un pixel !
- t'es trop con parce que lorsqu'on écrit 5 octets on définit 8 pixels taré !

l'amiga a maximum 5 plans donc 32 couleurs encodables
- ouai, c'est de la merde tout est en 16 couleurs
- si tu savais te servir d'un copper tu changerait tellement souvent de palette que tes 256 couleurs te semblerait fadasse

...

C'est couillon, j'aurai bien aimé connaitre les rapports de puissance de transfert entre un 68000, l'arm de l'archiméde et le blitter amiga...

[babsimov]

@babsimov : relis la file depuis le début, et celle intitulée 'Archimedes A3020' et tu comprendras mieux qui a insufflé un tel ton : le toutcon, comme l'a presque renommé Oiseaudeproie.
Il ne déblatère que des stupidités, d'une mauvaise foi inimaginable.
Comme je suis très loin du genre à être sympathique quand on quitte un débat équilibré, j'ai suivi le guide.

N'étant pas programmeur, il m'est difficile de vous départager entre vous dans vos débats.
Pour me faire mon opinion, je me base sur les vidéos que tu as mise (démo et jeux Archimèdes). En dehors du shoot (Scorpius, si je me trompe pas, pas tout relu), je n'ai pas vu grand chose en 2D qui soit exceptionnel sur Archimèdes.
Ma première réaction dans le sujet a été pour le raccourci que tu as fait concernant le bi-processeur. On ne va pas dire que c'est de la mauvaise foi de ta part, mais que c'est une manière d'embellir l'Archimèdes, si tant es qu'il en ait besoin, bien sur.

En vrac d'autres réponses :
- je fais bien ce que je veux avec ce que j'envoie sur Youtube, personne n'est obligé de regarder. A mon sens ça servait de teaser puisque la suite sera visible dans moins d'un mois. Donc, en fait avec des mots simples : ton avis sur la question dans ce cas précis tu te le gardes, je ne me lève pas le matin ni ne me couche le soir avec l'idée de te contenter.

Oui, mais quand on met quelque chose sur youtube et à fortiori sur un sujet "guerre" dans un forum, on doit bien s'imaginer qu'il y aura des avis contradictoire ? Ou au minimum des commentaires ?
D'autant plus que je dit que je te laisse le bénéfice du doute.
Content d'apprendre que dans un mois on sera fixé.

- pour quoi ne dites-vous pas halte à la mauvaise foi de toutcon 1er ?
Il évoque clairement 480 octets, je le cite :
'une division sur arm2 prend 480 octets et 176 cycles
'
puis maquille ça en autre chose, comme il a fait sur tous ces autres posts, et ça vous laissez pisser ?

N'étant pas programmeur, je peux pas savoir lequel dit la vérité là dessus. Par contre, j'ai été quand même épaté d'apprendre qu'il y avait pas de division sur l'ARM (mais c'est peut être comme ça sur tous les RISC ?)

Il parle de scroll hardware précalculé etc etc mais ça non pas de soucis pour vous.
Il n'y a pas un post sans de grossières erreurs de logiques, des attaques infondées, des trucs tellement stupides que sur un forum de développeurs il se ferait descendre en flammes.
Mais vous cautionnez par votre silence.

Le problème c'est qu'il n'est pas le seul à remettre en cause tes propos niveau programmation. Et, comme tu viens de le faire aussi, il te conseille d'aller sur un forum de développeurs.
La meilleure chose qui reste à faire est d'attendre un mois pour que tu nous présente ta démo ou ton jeu terminé. Là on verra si l'Archimède à été sous exploité en 2D.

Du coup :allez faire la morale à d'autres que moi dans ce cas, qui suis quasiment seul contre tous. Faut dire, ça tombe bien : je suis le seul à avoir un Archimedes et m'y connaitre en programmation.

A dans plusieurs jours, vous m'avez tous bien assez fatigué aujourd'hui.
Et je vous emmerde, clairement, si vous voulez vraiment connaître le fond de ma pensée (en 48 octets, et en signé c'est bon aussi).

L'Amiga ça restera bien pour moi une machine de 99% de trouducs qui n'ont fait que jouer et jamais rien apprendre ou créer.

Le seul à t'y connaitre en programmation, surement pas je pense. Mais un défenseur "acharné" de l'Archimèdes certainement (je le dis dans le bon sens du terme, attention).

Mais, prétendre qu'il n'y a pas eu de créateurs/artistes sur l'Amiga, c'est quand même méconnaitre son Histoire.

Personnellement, j'attends juste de voir ta démo/jeu pour confirmer ou non mon opinion sur le fait que l'Archimèdes peut égaler ou battre un Amiga en 2D.

[Invité]

Ah oui, en fait, je viens de comprendre. Il a cru que le Doc était un vrai docteur qui pouvait le soigner...

[babsimov]

Donc en résumé


C'est couillon, j'aurai bien aimé connaitre les rapports de puissance de transfert entre un 68000, l'arm de l'archiméde et le blitter amiga...

Il ne fait pas de doute qu'un ARM écrase un 68000 seul.

Par contre un 68000 et des copros pour la 2D, là c'est moins sur.

[guybrush14]

Ben flûte alors, tout comme Romano je trouvais super intéressant ce topic, mais là...

J'ai rarement vu un débat aussi haineux...

Même en cas de grosses divergences d'avis, lorsque l'on est bien élevé on arrive logiquement à discuter sans insulter personne, enfin du moins pour des choses aussi futiles...

Tu peux dire ce que tu veux Archiforever, tu perds toute crédibilité alors que tes propos étaient intéressants.

ArchieForEver a écrit:
A dans plusieurs jours, vous m'avez tous bien assez fatigué aujourd'hui.
Et je vous emmerde, clairement, si vous voulez vraiment connaître le fond de ma pensée

Tu sais quoi, t'es carrément pas obligé de revenir, quand je me sens pas bien quelque part j'y reviens pas.

[Invité]

Ah oui, en fait, je viens de comprendre. Il a cru que le Doc était un vrai docteur qui pouvait le soigner...

,ça faisait longtemps que j'avais pas rigolé comme ça sur ce topic ..
Bien trouvée,ça fait plaisir un peu d'humour :thumright: .

Donc en résumé

l'Amiga à un blitter et un copper
l'archimede à un arm
- merde!
- toi même connard !

l'amiga à des bitplans
- trop nul, faut écrire 5 octets pour un pixel !
- t'es trop con parce que lorsqu'on écrit 5 octets on définit 8 pixels taré !

l'amiga a maximum 5 plans donc 32 couleurs encodables
- ouai, c'est de la merde tout est en 16 couleurs
- si tu savais te servir d'un copper tu changerait tellement souvent de palette que tes 256 couleurs te semblerait fadasse

...

C'est couillon, j'aurai bien aimé connaitre les rapports de puissance de transfert entre un 68000, l'arm de l'archiméde et le blitter amiga...

Putin, c'est excellent aussi ..

@archiottes, où es ce que j'ai marqué texto, scrolling hardware précalculé ??
J'ai juste dis que tu foutais toutes les données de tes écrans dans un buffer, parce que tu ne pouvais rien réactualiser au niveau du fond car tu n'as plus de ressources pour le faire à la volée .
ca correspond plus ou moins à du precalc, surtout quand on se permet de critiquer des codeurs bien plus tallentueux que soit(demomakers AMGA/ST), en ayant pondu des routines à 2 balles .

Ensuite pour tes 48 octets ,fais les choses correctement au lieu de faire une routine de division édulcorée, qui arrange tes propos,quand on se dit programmeur, on fait attention de comparer 2 routines qui font la même chose ..
Et surtout ta salle habitude de me faire dire ce que je ne dis pas, ex la taille variable de la routine ta réflexion n'est même pas digne d'un programmeur, qui aurai vite vu que je parlais de cycles variables.
la routine, je l'ai prise sur un blog d'un dev archimedes(que tu as dénigré encore une fois), j'ai rien inventé.
Ensuite, pour ce qui est des insultes, tout le monde te connais maintenant, et c'est pas seulement sur ce post ou tu t'es distingué,même en changeant 3 ou 4 fois de pseudo, ton style haineux à vite refait surface à chaque fois, et n'essayes pas de me faire porter le chapeau, je pense avoir suffisamment été courtois jusqu'a présent, mais bon ça commence à me saouler de me faire insulter par une larve,qui à un gros problème d'ego (et psycho aussi) .

Je vais vous dire le fond de ma pensé, au début j'étais vraiment intéressé par son projet, montrer que l'archimedes pouvais faire mieux que l'amiga,je l'ai même encouragé, puis il à commencer (re) , à devenir hautin et insulter, critiquer tout et tout le monde de maniere détestable, et là tout est partie en sucette .
ils vous suffit d'aller jeter un coup d'oeil sur le tube, aux demos archimede son pseudo c'est archimedes75009, ça se résume en insulte,et amiga c'est de la merde, à tout ces coms .

[kenshiraoh]

L'Amiga ça restera bien pour moi une machine de 99% de trouducs qui n'ont fait que jouer et jamais rien apprendre ou créer.

Je viens de me (re)survoler vos 17 pages de débats indigestes pour le simple trouduc que je suis .

Une question me taraude : Archi, tu as une sorte de frustration du fait que l'Archi a eu en son temps que des branleurs (d'ou ses capacités vidéoludiques non développées).
Mais au final, qu'est-ce qu'on en a à faire puisque cette période est révolue et fait partie de l'histoire ? De plus, tu essayes de nous faire croire que l'Archi pouvait concurrencer l'amiga en 2D mais cela reste de l'ordre de l'hypothèse et du projet !! (une bien belle idée mais qui n'a jamais trouvé de concrétisation).
Pouvoir faire n'est pas faire, ce qui est magistralement résumé dans un de tes posts :

"Bien sûr pour le jeu l'Amiga s'impose. Je ne dirai jamais le contraire.
Je dis que l'Archie de base n'a jamais vraiment été exploité.
S'il avait été mis entre les mains de Team17 ou autre Psygnosis, on aurait vu ce qu'il a dans le ventre.
S'il n'y avait pas eu un fou pour faire StarFighter, les gens penseraient encore que la 3D sur Archie c'est Zarch, ou Elite ...
Si'l n'y avait pas eu les demomakers SICK pour créer Scorpius, on penserait encore qu'en 2D Nevryon est le maximum que l'Archie puisse faire.
Si je ne m'étais pas un peu creusé les méninges pour faire des routines 2D absolument optimales vue l'architecture de l'Archie, on penserait encore, comme je crois tu l'as écrit par le passé, que l'Archie a un bus tout pourri et n'est bon qu'à la 3D ....
L'ignorance sur ces machines me fait bondir, voilà peut-être pourquoi tu me trouves un peu agressif.
J'ai hâte d'avoir le temps de finir mon projet, qui devrait en étonner plus d'un.
Et je ne suis absolument pas un pro, un vrai geek, ou un type naturellement doué pour la programmation, comme ceux que j'ai déjà croisés sur ST ou Amiga... Misère, l'Archie n'a vraiment pas eu les passionnés qu'il méritait."

Tu ne pourras jamais élever l'Archi au niveau que tu souhaites puisque cette histoire est faite.
Au lieu de te perdre ton temps à argumenter des pages de débats, fignole ta démo/ton jeu en mode homebrew rétro-développement et fais nous rêver afin de t'élever au niveau de ceux que tu sembles vénérer : les créateurs de Starfighter, Scorpius....

[MacDeath]

En bref : vous êtes juste des gros .... d'amigaïstes.

Lol non...moi je ne suis qu'un peu Amstardé sur les bords.

[stapha92]

@ArchieForEver,

Tu t'accroches aux branches sur quelques sujets mais tu évites de la ramener sur plusieurs autres sans pour autant reconnaitre que tu avais tout faux (blitter moins bon que ton ARM et dont il faudrait préparer les données, le copper qui serait un timer, le HAM qui n'existerait qu'en entrelacé, etc...)

Regarde, je vais te montrer :

Je reconnais m'être trompé sur ta démo car tu appliques bien de nouveaux Tiles. Bon, ils sont répétés sur chaque, donc c'est pas plus impressionnant. Il n'empeche que :

JE RECONNAIS MON ERREUR !

Tu vois ? Je ne suis pas mort...

Les 15 registres de l'ARM (au fait : c'est en mode USER) sont librement utilisables pour tout : adresses et données.

Ton 68000 est contraint : il en a la moitié de ses registres pour des adresses (7), l'autre pour des données (8).
Ca change énormément la donne : sur ARM j'ai nettement plus de possibilités de traiter un algo sans sauvegarde intermédiaire de données.
Et ça aide bien pour la taille du code.

ah oui, t'as consulté Wikipédia ? C'est vrai ce que tu dis mais c'est 8+8 : t'es pas obligé d'utiliser le A7 pour la pile et le PC et le SR sont 2 registres EN PLUS (et le 68000 peut appliquer tous ses modes d'adressage sur le PC aussi. c'est bien un registre supplémentaire). Donc, nous, c'est 16. Pas 15....

Maintenant, continuons sur le 68000...

Déjà beaucoup d'instructions fonctionnent aussi bien avec les registres d'adresse que ceux de données. Ensuite il est possible d'utiliser les registres de données pour de l'adressage (t'as pas remarqué dans mes exemples qu'il y a des cas ou l'adresse est obtenue via la conjonction d'un An et d'un Dn ?). On peut donc utiliser des registres d'adresse pour les données et vice-versa. Enfin, et surtout, contrairement à ce que tu dis, le 68000 utilise moins de registres (franchement si tu vois pas les inconvénients de l'architecture LOAD/STORE alors que tu es sur ARM depuis plus de 20 ans, c'est pathétique).

Je donne un exemple (pour les lecteurs, pas pour toi : je sais que tu ne reconnaitras jamais les évidences)

Supposons que tu as besoin de faire une opération entre une constante et un registre (ce qui arrive TRES souvent, tous les programmeurs le savent, même les débutants). Et bien sur 68000, tu te contentes de mettre la constante et c'est tout :
Par exemple OR.L D0,#$F0F0F0F0

Sur ARM, tu es obligé de stocker ta constante dans un registre. Et hop un registre de perdu ! (et du temps, et de la place aussi...). Le plus drole, c'est qu'il te faudra plusieurs instruction pour affecter cette valeur...

Encore plus drole, tu souhaites faire une opération entre un registre et une valeur situé à une adresse :

Sur 68000 : AND.W D4,$DFF102
sur ARM, tu vas devoir mettre la valeur $DFF102 (qui parle à tous les codeurs amiga... ;-) ) dans un registre (plusieurs instructions...), charger la valeur situé à cette adresse dans un autre registre, faire le AND et réécrire la valeur.
Sur 68000 : 1 registre.
Sur ARM : 3 registres...

Et tu crois que tes algos suvegarderont moins souvent les données ?

Je peux aller plus loin :

MOVE.L #FFF,$DFF000
Sur 68000 : 0 registre.
Sur ARM : 3 registres...

Je le répete : l'ARM ne sait travailler que sur ses registres. Il en est forcément beaucoup plus dépendant et il en consomme forcément plus...

LTes exemples où l'ARM doit faire l'équivalent en plusieurs instructions sont merveilleusement bien choisis.

Oui bien sur...
Tu sais combien de fois tu nous as parlé de "LDR / STR" dans tes posts ? 10 ? 20 ? 30 fois ?
Parce que mon premier exemple (MOVE.L (A0)+,(A1)+) fait exactement la même chose ! (rappel : en 1 instruction au lieu de 2 et 2 octets au lieu de 8). J'AI PRIS LE CAS QUE TU N'ARRETES PAS DE CITER !!! LOL !!! Tu t'en es pas rendu compte ? Pourtant je l'ai expliqué, ce n'était pas un piège. Cet exemple est l'instruction qu'on utilise quand on copie quelque chose. ça arrive souvent...

Même quelqu'un d'aussi imbu de sa personne que toi doit se sentir ridicule tout d'un coup...

Je peux t'en sortir quelques uns aussi.
CMP R0,R3
ADDGT R0,R1,R3,LSL#8 : si R0 strictement supérieur à R3, alors R0=R1+R3*256
ADDLT R0,R1,R10,LSR#2 : si R0strictement inférieur à R3, alors R0=R1+R10/4
LDREQ R0,[R12,R8,LSL#5]! : si R0=R3, alors R0=contenu de ce qui est à l'adresse R12+R8*32, puis R12=R12+R8*32
Donne moi le code 68000, juste pour rire un peu .... et taille et nombre de cycles.
Là sur ARM c'est 1 cycle par instruction, que les additions soient effectuées ou non.
1 cycle si l'accès mémoire n'est pas réalisée, sinon c'est 4.
Et ça prend 16 octets, soit 4 octets par instruction.
Je parie qu'à moins de 25 octets ton 68000 est incapable d'en faire autant.
Et je parie que le résultat sera incomparablement plus lent, quelque soit le cas logique.

Oui tu peux en sortir quelques uns mais là c'est un cas extreme ou 3/4 des instructions utilises TOUS les bits existants (avec des décalages pairs dans les 2 premiers cas, forcément...) mais, surtout, le sujet était "le 68030 est bien plus doué pour déplacer les données" ...
C'est du traitement de données ça ? Pas du tout... C'est un algo ne correspond à rien. Moi je t'ai donné un exemple de code qui correspond au code arm que tu mets en avant tout le temps et des exemples qui correspondent à des choses générés par des compilos lorsque l'on manipule des tableaux ou des listes chainés, des objets ou des structure...

Donne ton algo complet avec le chargement et l'utilisation de tes registres et on verra. Je le réécrirai de façon adaptée au 68000.

Puisque tu aimes bien parler de la mémoire, dis moi en combien d'instructions tu vas transférer 15 résultats 32 bits issus de calculs (donc tous fraichement dans les registres).
Combien d'instruction au 68000, qui n'a que 8 registres de données ?
Sur ARM :
STMIA R0,{R1-R14} : envoie les contenus de R1 à R14 à l'adresse R0, R0+4,R0+8 etc ...
Avec l'incrémentation de R0 en fin d'opération en 0 cycle si je rajoute '!'
STMIA R0!,{R1-R14}

Alors tu vois, ton 68000 est dépassé.
Au final l'ARM sort gagnant, car la majorité des opérations effectuées dans les algos tombent dans le cas des instructions rapides de l'ARM, et les cas d'optimisations où l'ARM s'en sort gagnant haut la main avec très peu d'instructions.

Ben oui j'aime bien parler de la mémoire puisque je parlais de manipulation de données.
Faut pas m'en vouloir : quand tu veux faire de l'animation 2D, c'est le plus important. C'est pas le sujet depuis le début ? C'est pas sur la 2D que tu nous gonfles depuis un bon moment ?

Donc tu y reviens, c'est bien !

Dis moi : tu écris "15 résultats" mais ton instruction en transfère 14. Bizarre...
En fait ton code est plus honnete que ta prose : le r15 est réservé au PC et aux bits d'état et il serait idiot de transférer le registre qui contient l'adresse de destinations.

Donc 14 registres en 1 instruction : ça c'est bien.
Sauf que... Le 68000 sait le faire aussi (movem)! Lui c'est 15 registres (toujours cet avantage d'avoir un PC et un SR en plus...) en 1 instruction aussi. Avec également l'incrémentation gratuite du registre indiquant la destination...

Tu pensais que les registres d'adresses ne pouvaient être tranférés de cette façon parce que tu ne savais pas qu'il pouvait contenir des données ?
Ou tu croyais que le 68000 n'avait pas d'instruction de ce type ?

En tout cas t'arretes pas de montrer que tu ne connais pas le 68000 (ça fait combien "d'avantages" que tu cites sur ton arm pour apprendre que le 68000 les a aussi ?) et ça ne t'a pourtant jamais empeché d'en parler...

Tu le sais mais tu l'omets, car comme les autres Amiga bashers tu n'es pas objectif.
Tu ne vaux pas mieux que le toutcon : toujours prompt à cracher sur un système qu'il ne connait pas, et incapable de supporter l'idée que l'Amiga lui soit inférieur.

Je ne sais pas ce que je sais mais tu as déjà montré que toi tu ne sais pas que tu ne sais rien... LOL !

L'ARM n'est pas que 2 fois plus rapide que le 68000, non non non.
Le facteur est en moyenne de 4 à 6.
C'est objectivement ce que tous les magazines d'infos ont pubilé en benchmarkant un ARM à 8 Mhz et un 68000 à 8 Mhz.

Oui bien sur, c'est ça : encore du blabla sorti d'on ne sait ou...

Tu te donnes bcp de mal pour tes explications sur ce que pourraient être des optimisations pour des routines graphiques sur Archie.
Mon commentaire: 'peut BEAUCOUP mieux faire'.
Tu as compris certains principes, mais l'essentiel t'échappe.
Ne cherche pas à faire croire que tu maîtrises le sujet : ce n'est pas le cas.
Tu tâtonnes et tu merdoies dans tes conclusions et la mise en oeuvre.
Quasiment tout ce qui est subtile t'échappe, en vérité.
La version la + rapide que tu donnes correspond à mes premières beta versions de routines.
Depuis je fais minimum 30% + rapide, et bcp plus léger en RAM.

D'accord, donc en un post et en me basant simplment sur 2 éléments (32 bits et chunky pixel) j'ai réussi à trouver des optimisations simplement 30% plus lentes que celles sur lesquelles tu travailles depuis plus de 20 ans ?

Et tu trouves que je "tâtonne" et que je "merdoie" ?

Plus de 20 ans sur une machine (et en étant abonné à " BBC Acorn User, Archimedes World, RISC USER, Archive Magazine'... lol !!) contre quelques minutes sans y avoir touché et je suis déjà à 30% de toi...

Moi je pense qu'avec ce post, tu as montré à tous qu'on n'avait pas le même niveau en programmation.

Et j'ai juste posté un truc rapidement en m'arretant à la 2eme optimisation. J'aurai pu continuer en ajoutant l'utilisation de LDM,STM pour les accès 32 bits : ça permettrait de gagner un peu de temps et beaucoup de place pour les routines...

Et là je suis à combien de % de tes routines de la mort qui tuent ?
Me dit pas que ça y est, je t'ai rattrapé ! LOL !!!

Toi au bout de plus de 20 ans par contre, y a des trucs qui continuent à t'échapper toujours. L'hypothese pour Scorpius que j'attend toujours par exemple...

Et pour Scorpius : tu peux toujours tenter une explication, mais sachant qu'il n'y a pas de bitplans sur Archie, tu ferais mieux de la garder car tu seras forcément ridicule.

C'est vrai que j'ai toujours joué avec des écrans bitplans mais je ne suis pas stupide : ma solution ne fonctionne qu'avec un écran chunky. là encore tu tentes un trucs minable pour me faire exposer ma solution sans avoir reconnu que tu n'en avais aucune.

T'es le genre à ne pas partager tes algos on dirait. je vais peut-être me contenter d'envoyer ma solution à tous ceux que tu as insultés ici et qui veulent bien être témoins...

Non, si tu reconnais que tu coinces sur l'optimisation dont je parle, je te la donnerais. pas pour toi, mais pour l'Archimedes (contre lequel je n'ai rien du tout vois tu, comme tout le monde ici : t'es le seul à ressentir de la haine envers une machine...)

Ahhh... la fameuse division sur ARM.
C'est vrai : un CPU passe son temps à faire des divisions, hein ? C'est bien connu
Ca vient d'où cette taille de code et ce nombre de cycles, en 'worst case scenario' je parie ?
Page 2-47 du manuel de VLSI j'ai un code en 12 instructions, soit 48 octets.
C'est 48, pas 480 comme le toutcon le dit.
Et tu reprends ses propos calomnieux, montrant que toi aussi tu n'es qu'un membre de la team force des débileux pro Amiga obstinés de ce forum.
Mais c'est vrai j'oubliais que toutcon c'est notre spécialiste du blitère à 77 Mhz !

N'empeche que TOUKO t'as répondu là dessus et t'a mouché...
Et il t'a donné un lien sur la page d'un fan de l'ARM...

Donne moi donc les cycles pour ta superbe instruction de division sur 68000, qu'on rigole.
C'est tellement lent sur tous les CPU, y compris les 68000, que n'importe quel bon programmeur évite de diviser, et va procéder avec des décalages quand il connait son dénominateur, ou bien des tables.

Oui : un 68000 mettra du temps à faire une division (122 cycles max : ça reste plus rapide que l'ARM...). Mais l'avantage est que l'instruction existe. ça permet un code plus concis (très important pour l'utilisation des caches...) et surtout, quand on execute ce code sur un 680x0 plus évolué, on en tire un gros bénéfice. Une division écrite sur un ARM2 et portée sur n'importe quel modèle continuera à prendre pleins d'instruction donc pleins de cycles, c'est inévitable. La division prend un cycle sur 68040. Tu vois la différence de gain potentiel ?

Quand aux tables, le sujet était le ray-tracing (et là on ne connait pas les nombres à traiter à l'avance : on oublie les décalages) : Non seulement, les tables ne suffiront pas mais les tables peuvent présenter un gros défaut : elle provoque des cache-miss pour les données (quand on accède à la table, le processeur se met à précharger les mots autour de celui qu'on a lu alors qu'on en veut pas...).

Mais la gestion des caches d'un proc sont des concepts qui te dépassent sans doute...

Maintenant, l'absence de division n'est pas un drame si on fait de la 2d ou de la 3d face pleine. je le précise aux lecteurs. C'est bien pourquoi j'en ai parlé quand tu as prétendu que ton arm était hyper doué pour le ray-tracing...

Je rappellerai aussi les bases des mathématiques : A / B = A * 1/B
Alors Stapha92, tu es suffisamment de mauvaise foi pour ne pas préciser ça dans tes 'démonstrations' ? T'es bien juste un Amigaïste, version moins bêta qu'un toutkon.

Préciser que A/B = A* 1/B ? c'est très bien mais dis moi : "1/B" ça reste une division, non ? ou alors l'ARM sait diviser 1 par n'importe quelle valeur ? LOL !!!
T'es trop drole : on voit tout de suite le genre de personne qui a lu pleins de choses mais sans les comprendre complètement...

Le 1/B est justement la solution pour utiliser des tables : tu te répètes sans t'en rendre compte.

Encore une fois : on s'en fout pour le ray-tracing...

Je te réaffirme que le MEMC m'offre la possibilité de scroll horizontal sans les soucis que tu évoques. C'est très mal expliqué dans la doc de VLSI, mais je l'ai fait, ça tourne.
Tu le verras (j'imagine bien avant de voir la démo de toutcon censée copier ma démo Archie).

Oui tu réaffirmes : n'empeche que tout le monde a vu que tu ignorais cette histoire de modulo. Moi j'ai donnée des explications claires pour tous (sauf pour toi on dirait...). Toi tu "réaffirmes" en disant que c'est mal expliqué mais que tu l'as fait mais... blablabla quoi...

Oui, en attendant, Touko a posté un exemple (avec un scrolling horizontal, dommage pour toi...) de quelque chose que je n'ai jamais vu sur Archimedes...

Puisque tu es prompt à tenter de donner des cours de programmation, stp explique à toutcon que pour faire un scroll hardware sur une bécane chunky, on a bien besoin d'au moins 3 banks écran.
Pourquoi ?
Quand on ne scrolle pas, il en faut déjà 2 : on affiche l'une, pendant qu'on travaille sur l'autre.
Pour pouvoir se déplacer, c'est à dire 'scroller', il faut bien au moins une autre bank.

Non c'est à toi que je vais expliquer que pour faire un scroll hardware, il n'y a pas besoin de 3 écrans sur une bécane chunky. Y avait des jeux sur PC qui permettait de choisir entre double et triple buffer (et là c'était pour ne jamais laisser le proc en attente de la vbl et récupérer tous les cycles disponibles)...

Je ne comprend meme pas ton explication

En double buffer : tu affiches un écran, et tu travaille sur un autre qui sera n lignes plus haut, tu permutes l'affichage et tu retournes sur le 1er écran en te positionnant 2xn lignes plus haut et ainsi de suite. A chaque fois que tu travailles sur un écran tu ajoutes 2xn lignes au-dessus et tu les mets également 1 écran + 2xn lignes plus bas. Quand dans l'un de tes buffer tu es arrivé tout en haut de ta bank écran, tu bascules d'un coup tout en bas et tu auras une copie identique de l'écran que tu viens de quitter. C'est tout (j'ai raisonné par lignes et non par tile pour simplifier l'explication mais ça ne change rien au principe).

2 choses encore :
- y a mieux que la méthode ci-dessus pour un scroll hardware sur un écran chunky. Y a moyens d'économiser la moitié de la mémoire sur chaque buffer et d'accélerer la préparation des tiles... Rien que là y a de a place encore pour des optimisations pour ta démo... Je t'expliquerait le jour ou tu changeras d'attitude...
- Tu peux faire un scroll hardware avec 1 seul buffer écran ! et sans saccades (bien sur que dans certains cas...)

Faudrait que tu te mettes à la vrai programmation un de ces 4 : ça te plairait.

Je confirme à nouveau que pour faire du mapping de texture, on n'a pas besoin de lire en byte à byte.
C'est logique, réfléchis. Sans doute la plus grosse erreur que tu fasses en raisonnement ARM.

Ah oui tu confirmes ? Et bien expliques moi (encore une fois moi j'ai donné une explication et pas toi) comment tu fais pour lire 4 octes éparpillés en mémoire en 1 seul accès 32 bits... Meme si l'ARM disposait d'une intruction capable d'aller chercher ces 4 octets pour les stocker dans un registre (et ce n'est pas le cas), il aurait FORCEMENT besoin de 4 accès en lecture : c'est la façon dont fonctionne la mémoire sur TOUS les ordinateurs depuis la nuit des temps qui l'oblige...

Ton "sans doute la plus grosse erreur que tu fasses en raisonnement ARM" est idiot une fois de plus. Tu es sur de toi ? Va poster ton affirmation sur un forum de codeurs Acorn et tu verras les vrais codeurs te rire au nez...
Et mets nous un lien sur les réponses, qu'on rigole aussi...

PS : Et oui l'Archie explosait l'Amiga pour le raytracing : car tous les 2 travaillaient sur des entiers, mais comme l'ARM calcule 4 à 6 fois plus vite que le 68000 de ton Amiga, l'Archimedes était loin devant.
Tout le monde l'admet, sauf toi.

Oui 4 a 6 fois plus vite pour les calculs. Avant c'était 4 fois plus de mips et a augmente ?
Je te le répète il est COMMUNEMENT admis qu'un ARM à 8 Mhz est à peu près 2 fois plus rapide qu'un 68000.

Et aucun des deux n'était adapté au ray-tracing : là il faut une fpu.

Ensuite, en ce qui concerne l'ARM3, il n'a pas de copro, mais le FPU Acorn existait, on pouvait l'ajouter sur les cartes mères d'Archimedes.
Mais, l'ARM3, à 25 Mhz, s'en sortait tellement bien, et mieux en fait que ton 68020 à 14 Mhz avec son copro mathématique ...

Et tu continues... Trop ridicule :
- Déjà à l'époque, tous les grand logiciels 3D étaient sur le mig et le PC : Y a eu Lightwave (qui a été utilisé pour des films ou des séries, comme babylon5) sur Archie ? Ou Real 3D ? Ou 3D studio ? Bizarre...
- Visiblement tu ne sais pas non plus ce qu'est une fpu : combien de temps mets un processeur qui ne sait même pas diviser pour calculer un cosinus par exemple ( parce qu'en raytracing, on ne peut pas se contenter de tables) ? ça se compte en secondes ou en minutes ? Et tu crois que tu peux remplacer les calculs sur virgule flottante par des fixes (CAD des entiers) ?

J'attend ta solution pour Scorpius, si tu en trouves une (depuis le temps je pense que tu as trouvé : il m'a fallu 5 minutes...)

[stapha92]

Dis donc Archie, ça veut dire quoi 50 i/s pour toi ?

J'invite tous les monde à lancer les 2 vidéos postées par Archie directement sur cette page (j'ai déplacé le commentaire qu'il y avait entre les 2 sous la 2eme : ce n'est pas pour trafiquer le post, c'est pour rapprocher les 2 vidéos) :

La version Amiga plein écran grâce à son blitter :





La version Archimedes calqué sur l'Amiga, mais tout en soft : il n'y a aucune utilisation faite des scrolls hardware.
ARM + bus pourri on rigole :albino:
(50 images par seconde même sur le plus lent des Archies).

Tout le monde voit la différence de fluidité ? Pourtant YouTube tourne à 25 i/s : donc la version Archimedes de Pacmania ne tourne même pas à 25 i/s. Et vu à quel point la différence de fluidité saute aux yeux, on en est loin. Et comme on peut comparer la vitesse de défilement qui est bien identique, on voit clairement que ce n'est pas un problème d'émulateur qui ne tournerait pas à 100% de la vitesse...

La version Amiga tourne à 50 i/s : c'est encore plus fluide que ça (et l'écart s'agrandit...). Et c'est pas grace au blitter, qui n'a pratiquement rien à faire. C'est un jeu que tous les micros qui ont un scrolling hardware peuvent faire facilement. Maintenant Mossieur Archi nous explique comment fonctionne un Amiga : lol !

Quand au "calqué sur Amiga" : c'est toi Archie qui a besoin d'un opticien. Au niveau couleur, ça n'a rien à voir : les dégradés n'ont pas la finesse du mig et ce dernier est en overscan...

Pas d'utilisation du scroll hardware. C'est marrant : y a un jeu à scrolling horizontal qui l'utilise ? Au bout de 25 ans quand même ! Non ? Bizarre... Comme si l'absence de modulos posait problème... Mais je dois me tromper : tu as prétendu que ton Archimedes magique n'en a pas besoin...

[drfloyd]

Je passe une tête :

Et si on ouvrait une section le coin des développeurs ??????

[MikeeMike_2008]

a force de ne voir que les démos de l'archimèdes il est convaincu que tout est en 50i/s que c'est du vrai copper (même si c'est des cycles de couleurs...)

jouer a 50 jeux en boucle au bout d'un moment ca retourne l'esprit ! la preuve !!

et après ca critique les programmeurs amiga :lol: (les meilleurs des années 88/94)

en tout cas l'archimèdes n'égalera jamais le migouze en 2D et surtout dans le niveau des démomakers et c'est pas archi-bouffon qui relèvera le niveau ... même sur hp 48 en rpl (a 2mhz) j'arrive a faire son scroll... (ca c'était du bon matos pour étudiant ... au moins c'est portatif !!!!)