Amiga blitter vs Archimedes ARM power ;-)

15 sujets de 46 à 60 (sur un total de 119)

  • Zarchos

      #353885

      Je vais de mon côté t’apprendre un truc : en affichage chunky il n’y a pas non plus de couleur perdue

      Ben ca dépends des API. Avec la lib SDL si tu perds une couleur systématiquement si tu veux faire des blits avec transparence.

      Les sprites compilés « en dur » sont à la mode en ce moment. On en parlait coté 8bits: http://www.logicielsmoto.com/phpBB/viewtopic.php?p=6231#p6231

      Je te parle, évidemment, sur Archie …

      Et oui, pas de surprise : sur des systèmes qui n’ont pas d’accélération hardware, puisque tu dois passer par le CPU, la qualité du ‘compilage’ du sprite fait toute la différence.
      Dernièrement j’en ai discuté avec un type qui s’en sert sur le Sam Coupé pour son portage en cours de R-Type … dans le groupe FB du Sam Coupé.
      Là encore, personne n’en croit ses yeux, genre ‘Fichtre, comment cela est-il possible ?’ … Ben c’est possible si tu te creuses un peu les méninges, voilà tout.
      Joli, non ?

      Xavier Louis Tardy I guess you are using compiled sprites. Does the game include the generator or are your sprites already loaded compiled ?
      Modifier ou supprimer
      J’aime
      · Répondre · 4 sem
      Balor Price
      Balor Price Xavier, you guessed correctly :). It uses three different compiler routines so far, though I’m sure there will be more coming. The scenery blocks use the stack to print quickly but have black borders. The logo letters and enemies are compiled but fully masked, with the logo letters also clipping on the right of the screen.
      The actual compilers aren’t optimised yet, so they’re a bit slow to run, but I can see a 5-second wait between levels as tolerable… If I ever do more levels…
      3
      Masquer ou signaler ceci
      J’adore
      · Répondre · 4 sem
      Xavier Louis TardyEn ligne
      Xavier Louis Tardy Balor Price Thanks for your detailed answer.

      thellier

        #353895

        Bonjour.
        En 3 mots tu peut nous dire ce que sont des “sprites compilés” ?
        Merci

        Zarchos

          #353896

          Bonjour.
          En 3 mots tu peut nous dire ce que sont des « sprites compilés » ?
          Merci

          C’est du code assembleur qui réalise l’affichage du sprite.
          Ce code est totalement fonction de la forme et du contenu du sprite, il est optimisé pour prendre le moins de cycles CPU pour réaliser l’affichage.

          C’est très différent de la méthode classique qui consiste à ( simplifié ) :
          – avoir un buffer avec chaque segment horizontal correspondant au rectangle dans lequel s’inscrit le sprite ( on a donc et du vide et du pur sprite )
          – avoir le masque correspondant au sprite dans un buffer contenant chaque segment horizontal du rectangle dans lequel s’inscrit le masque
          – charger le contenu de la mémoire vidéo ( idem, rectangle ) là où tu veux afficher ton sprite
          – charger le masque
          – trouer le contenu de la mémoire vidéo avec le masque
          – charger le sprite
          – ORRer le sprite avec le contenu de la mémoire vidéo trouée
          – écrire le résultat à l’écran

          le code ( que tu as manuellement écrit, ou bien que ton générateur de code va générer quand on lui file le sprite à analyser ) du sprite compilé, lui va faire ça ( je simplifie à mort)
          – pointer sur l’emplacement mémoire vidéo où il faut afficher le 1er segment horizontal du sprite
          – charger le contenu du 1er segment horizontal de pur sprite
          – écrire ce segment
          – ignorer le vide entre le segment précédemment affiché pour pointer sur l’emplacement où doit être écrit le segment horizontal suivant
          – charger le contenu du 2è segment horizontal de pur sprite
          – écrire ce segment
          boucler jusqu’à ce que tous les segments horizontaux composant le sprite soient mis à l’écran

          __sam__

            #353899

            Dernièrement j’en ai discuté avec un type qui s’en sert sur le Sam Coupé pour son portage en cours de R-Type … dans le groupe FB du Sam Coupé.
            Là encore, personne n’en croit ses yeux, genre ‘Fichtre, comment cela est-il possible ?’ … Ben c’est possible s tu te creuses un peu les méninges, voilà tout.

            Oui c’est exactement pareil avec le mission lift-off sur thomson (les sprites sont du code et pas des data): http://www.logicielsmoto.com/phpBB/viewtopic.php?p=5382#p5382

            C’est rigolo le SamCoupé et les Thomson ont le même processeur ancêtre du 68000: le 6809.

            Samuel.

            Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
            A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
            A500 Vampire V2+ ^8^ 🙂
            (mais aussi TO8, TO8D, TO9. Groupe PULS.)

            Zarchos

              #353900

              Dernièrement j’en ai discuté avec un type qui s’en sert sur le Sam Coupé pour son portage en cours de R-Type … dans le groupe FB du Sam Coupé.
              Là encore, personne n’en croit ses yeux, genre ‘Fichtre, comment cela est-il possible ?’ … Ben c’est possible s tu te creuses un peu les méninges, voilà tout.

              Oui c’est exactement pareil avec le mission lift-off sur thomson (les sprites sont du code et pas des data):
              C’est rigolo le SamCoupé et les Thomson ont le même processeur ancêtre du 68000: le 6809.

              Non le Sam Coupé a un Z80 à 6 Mhz ( le Sam est un super Spectrum, pensé pour être compatible avec lui )

              et oui hors du code généré pour les sprites ( ou ‘sprites compilés’ ) point de performance.

              Quand tu penses que sur Archimedes cette technique n’ a quasiment pas été utilisée …
              Les codeurs de Scorpius y ont quand même pensé, heureusement :
              https://youtu.be/nlK-Y8FqCHI
              Ce n’est que la 1ère démo, non jouable, il y a bien plus à l’écran dans la 2nde jouable. Il faudra que je fasse une vidéo et l’uploade sur ma chaîne, prochainement.

              Pacmania sur Archie fait carrément du shifting de sprites ( et donc de masques aussi ) à la volée, puis utilise la méthode d’affichage super crasse évoquée précédemment, et il réussit quand même à être plein écran et à 50 fps, tellement l’Archie est puissant :
              https://youtu.be/hU23fEL154k
              Bien lire la description de la vidéo, après avoir écouté Shaun, et ce qu’il pense de l’Archimedes ‘it’s amazing what you could do with the ARM CPU’ 🙂

              modulo

                #353905

                si je comprends bien, les sprites compilés sont une succession de «move» vers le segment vidéo avec des nombres entiers. J’ai vu cette technique sur MSX également.

                Ça évite une boucle, et surtout un accès mémoire pour récupérer la valeur du sprite.
                Par contre, ça occupe plus de ram, chose peu importante sur un ordinateur où la norme est de charger tout le jeu d’un coup (que les données soient dans le code ou dans un buffer, ça ne change pas grand chose vu la taille des sprites sure ces machines).
                Autrement (cas d’un ordinateur où les chargements sont envisageables depuis l’extérieur, lecteur de d7 par exemple), il faudrait gérer son code comme des données: en chargeant des segments de code et en les relogeant de manière plus ou moins élégante (ça va du releogeage sauvage à une adresse prédéfinie à une phase de link à la volée pour le recalcul des adresses).

                Bref… je garde mon baril de sprites hardware, malgré ses limitations 🙂

                Zarchos

                  #353906

                  si je comprends bien, les sprites compilés sont une succession de «move» vers le segment vidéo avec des nombres entiers. J’ai vu cette technique sur MSX également.

                  Ça évite une boucle, et surtout un accès mémoire pour récupérer la valeur du sprite.
                  Par contre, ça occupe plus de ram, chose peu importante sur un ordinateur où la norme est de charger tout le jeu d’un coup (que les données soient dans le code ou dans un buffer, ça ne change pas grand chose vu la taille des sprites sure ces machines).
                  Autrement (cas d’un ordinateur où les chargements sont envisageables depuis l’extérieur, lecteur de d7 par exemple), il faudrait gérer son code comme des données: en chargeant des segments de code et en les relogeant de manière plus ou moins élégante (ça va du releogeage sauvage à une adresse prédéfinie à une phase de link à la volée pour le recalcul des adresses).

                  Bref… je garde mon baril de sprites hardware, malgré ses limitations

                  Peut-être sur système 68000 et autres, mais sur Archie ce sont principalement les instructions de chargements et transferts rapides, famille d’instructions LDM et STM qui vont être utilisées.
                  Ce sont elles qui blittent super vite car elles opèrent avec une liste de registres, et le 1er coûte 4 cycles, mais chaque registre suivant ne coûte que 1 cycle.
                  Et ces registres sont 32 bits … tu vois ce que tu peux arriver à charger, selon que tu sois en mode 8 bits ou 4 bits par pixel … tu peux avoir jusqu’à 12 registres dans ta liste, et blitter dans un cas idéal 48 pixels en mode 256 couleurs qui vont te coûter 2 x (4 + 11*1) cycles = 30 cycles ( il faut charger de la mémoire vers les registres, puis envoyer leurs contenus vers la mémoire )

                  Pour être tout à fait exact à chaque extrêmité de ton segment, 80% des fois il faut charger le contenu de la mémoire vidéo, pour faire le trou et mettre les pixels du bord, pour tout envoyer ensuite rapidement avec STM.

                  Oui le code généré prend plus de place que la méthode classique, mais pas énormément plus ( on ne stocke pas le vide des sprites, et on n’a pas besoin du masque ) et de toutes façons l’idée c’est d’avoir un moteur qui te génère ton code quand tu sais que tu vas en avoir ultérieurement besoin ( imagine un boss de fin de niveau : tu n’encombres pas ta mémoire avec son code : tu appelles ton générateur quand tu vas arriver vers la fin du niveau, là tu te sers du code, que tu détruits une fois le boss tué. Il te faut un générateur capable de générer ton code un petit peu par VBL, pour ne pas ralentir ton action, mais c’est faisable tout ça, faut juste être un peu malin et pas paresseux )

                  __sam__

                    #353907

                    Ah oui zut.. Rien ne va plus, je confonds Coupé et (TRS) Coco à présent.

                    Les LDM/STM (load/store avec liste de registres) de l’ARM sont très voisins des MOVEM du 680×0. C’est pas pour rien qu’à partir du 68020+fastram 32bits le cpu est plus rapide que le blitter.

                    Samuel.

                    Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
                    A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
                    A500 Vampire V2+ ^8^ 🙂
                    (mais aussi TO8, TO8D, TO9. Groupe PULS.)

                    Zarchos

                      #353910

                      Ah oui zut.. Rien ne va plus, je confonds Coupé et (TRS) Coco à présent.

                      Les LDM/STM (load/store avec liste de registres) de l’ARM sont très voisins des MOVEM du 680×0. C’est pas pour rien qu’à partir du 68020+fastram 32bits le cpu est plus rapide que le blitter.

                      Ce que je me tue à expliquer à certains : le blitter est incorporé dans l’ARM, dès le 1er Archimedes.
                      La bécane n’a pas besoin de blitter séparé.
                      Elle a par contre besoin de codeurs qui se cassent un peu la tête pour sortir du code vraiment optimisé, donc un bon générateur de sprites compilés.
                      Là, l’Archimedes se révèle en 2D.
                      ( Pour la 3D les routines optimisées pour le remplissage ont bien été codées, fort heureusement )

                      A nouveau, regardez tout ce qu’il y a à l’écran ici.
                      C’est du 50 fps sauf à la fin quand j’affiche les carrés et la lettre de Beast en plus, où ça passe régulièrement à 25 fps.
                      Et on est en résolution 352 x 258, 256 couleurs !
                      Le personnage ce n’est pas 1 sprite 1 chargement N affichages, c’est chaque sprite de son animation :
                      https://youtu.be/f1O75mzto0A

                      __sam__

                        #353915

                        C’est du chunky les 256 couleurs sur Archimède ?

                        En chunky l’affichage des sprites est super simple: pas de mask à gérer, il faut juste “sauter” par dessus les pixels (octets). En planar, il faut pour chacun des bitplans, lire, masquer, ajouter, écrire. C’est vraiment beaucoup d’opérations. C’est extrêmement dommage que les modes graphiques 256 couls ou ham8 aient été conçus planar sur amiga 1200 (mais bon tout le chipset du 1200 est bâti autour d’accès bitplan).

                        Le RTG de la vampire est de ce point de vu nettement mieux (à combiner avec l’instruction AMMX STOREM, qui est une écriture en mémoire mais avec des trous sans sur-coût…)

                        Samuel.

                        Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
                        A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
                        A500 Vampire V2+ ^8^ 🙂
                        (mais aussi TO8, TO8D, TO9. Groupe PULS.)

                        Zarchos

                          #353918

                          C’est du chunky les 256 couleurs sur Archimède ?

                          En chunky l’affichage des sprites est super simple: pas de mask à gérer, il faut juste « sauter » par dessus les pixels (octets). En planar, il faut pour chacun des bitplans, lire, masquer, ajouter, écrire. C’est vraiment beaucoup d’opérations. C’est extrêmement dommage que les modes graphiques 256 couls ou ham8 aient été conçus planar sur amiga 1200 (mais bon tout le chipset du 1200 est bâti autour d’accès bitplan).

                          Le RTG de la vampire est de ce point de vu nettement mieux (à combiner avec l’instruction AMMX STOREM, qui est une écriture en mémoire mais avec des trous sans sur-coût…)

                          Tous les modes sont chunky sur Archimedes ( et RISC PC )

                          ‘super simple’ ‘ il faut juste’ : oui si tu fais un truc pas vraiment optimisé.
                          Si tu veux un truc ultime, crois-moi, il y a du boulot, notamment pour les petits segments, où il est idiot de faire chargement, écriture pour chaque : il faut grouper les chargements de plusieurs segments pour que ça tienne dans une seule instruction LDM
                          Il y a d’autres optimisations à réaliser, comme optimiser les chargements des pixels en les ayant stockés sur des adresses multiples de 16, ce qui permet d’éviter la pénalité de 1 cycle dû au DMA vidéo de rafraîchissement de l’écran.
                          Une routine optimisée va également regarder si des séquences de pixels peuvent être ré utiliser ailleurs, pour plusieurs segments de sprite.
                          Elle va aussi savoir gérer les segments dune seule couleur, ou bien ayant le même motif couleur1,couleur2,couleur 1, couleur 2 ( tu ne charges ce motif qu’une fois dans les registres, et réalises plusieurs écritures, comme pour les routines de remplissage utilisées en 3D )
                          Et quand tu dois charger le contenu de ta mémoire vidéo, tu dois optimiser ce chargement dans des registres qui ont déjà été déchargés en mémoire vidéo, pour limiter les chargements LDM de pixels du sprite.
                          De plus STM sait décharger en incrémentant (STMIA), mais également en décrémentant (STMDA et STMDB), ce qui permet encore des optimisations.

                          Et tu as aussi STMIB qui servira à d’abord incrémenter pour ne pas avoir de ADD destination, destination,# valeur

                          Quand tu as un bord de segment qui est en offset par rapport à un word boundary ( une adresse multiple de 4 donc ) +3 à gauche, ou bien + 0, à droite, il est judicieux d’utiliser STRB ( store 1 byte ), et là tu peux optimiser en n’ayant jamais chargé ce pixel (byte), si sa valeur existe déjà dans les registres contenant des paquets de 4 pixels que tu as déjà chargés.

                          et il y a encore qques autres trucs bien rigolos à faire, comme utiliser le fait que tu peux avoir des instructions qui s’exécutent gratuitement sur Archie 🙂
                          C’est un codeur sur 3DO qui a trouvé ça, et c’est très intéressant, crois-moi.

                          fenrix

                            #353926

                            Bonjour,

                            même si je salue tes efforts pour pousser l’Archimèdes et montrer ce qu’il a réellement dans le ventre et que je suis content d’apprendre des choses en ayant l’impression de presque tout comprendre en vous lisant (je ne suis pas programmeur en autre chose qu’en Basic et PHP, donc…), j’avoue que la comparaison me semble assez faussée dès le départ au vu de l’écart entre les deux processeurs (le RISC de base traitant 4 ou 5 fois plus d’instructions par seconde que le 68000).

                            Je me souviens très bien d’articles dans la presse Amiga du milieu des années 90 qui suivaient de près ce type de processeurs et certains espéraient/prédisaient même une évolution vers celui-ci… qui évidemment n’a eu lieu que de manière indépendante de Commodore avec le passage au PowerPC. Donc je ne pense en fait pas qu’il y ait quelque chose à prouver, le processeur de l’Archimède faisait déjà rêver il y a 25 ans (y compris les Amigaïstes).

                            Après pour te voir très actifs ici et là, tu sembles avoir un ressenti très fort contre la communauté Amiga et l’insistance avec laquelle tu t’étonnes de ne pas te faire insulter ici devrait te faire réfléchir. Ce n’est pas parce que tu es tombé à quelques reprises sur des extrémistes stupides (c’est un pléonasme) que tu dois généraliser. Donc oui, les Amigaïstes sont aussi très sympa – même quand ils sont passionnés 🙂

                            Au-delà de la performance, j’espère surtout voir des projets arriver au bout sous forme de jeux terminés. Le shmup dont tu as montré une vidéo a l’air très prometteur et c’est vraiment le genre de jeux qui seraient excellents comme vitrine de la machine aujourd’hui.

                            Et plutôt que de faire un portage de Shadow of the Beast (qui montre encore et toujours que l’Amiga sert de pierre de touche, ce qui est contre-productif à ton message), développe ton propre jeu! La force de l’Amiga comme de toutes les plates-formes qui ont eu la chance d’accueillir un choix pléthorique de jeux, ce ne sont pas seulement ses caractéristiques techniques mais aussi ses créatifs (musiciens, graphistes, game designers, etc.). C’est clairement ce que l’Archimèdes n’avait pas – probablement en partie à cause d’Acorn qui n’avait pas positionné sa machine comme telle en pensant probablement surfer sur le secteur éducatif comme avec les BBC, ce qui fut au final un échec.

                            Un dernier point pour terminer, je suis allé vérifier sur Wikipedia le prix de lancement de l’A305 (le moins cher) et de l’Amiga 500, puisque c’est lui aussi un modèle moins cher et qu’ils sont sortis la même année. L’A305 coûtait 800£ alors que l’Amiga 500 coûtait 500£. Ça fait tout de même une sacré différence!

                            Zarchos

                              #353929

                              Bonjour,

                              même si je salue tes efforts pour pousser l’Archimèdes et montrer ce qu’il a réellement dans le ventre et que je suis content d’apprendre des choses en ayant l’impression de presque tout comprendre en vous lisant (je ne suis pas programmeur en autre chose qu’en Basic et PHP, donc…), j’avoue que la comparaison me semble assez faussée dès le départ au vu de l’écart entre les deux processeurs (le RISC de base traitant 4 ou 5 fois plus d’instructions par seconde que le 68000).

                              Je me souviens très bien d’articles dans la presse Amiga du milieu des années 90 qui suivaient de près ce type de processeurs et certains espéraient/prédisaient même une évolution vers celui-ci… qui évidemment n’a eu lieu que de manière indépendante de Commodore avec le passage au PowerPC. Donc je ne pense en fait pas qu’il y ait quelque chose à prouver, le processeur de l’Archimède faisait déjà rêver il y a 25 ans (y compris les Amigaïstes).

                              Après pour te voir très actifs ici et là, tu sembles avoir un ressenti très fort contre la communauté Amiga et l’insistance avec laquelle tu t’étonnes de ne pas te faire insulter ici devrait te faire réfléchir. Ce n’est pas parce que tu es tombé à quelques reprises sur des extrémistes stupides (c’est un pléonasme) que tu dois généraliser. Donc oui, les Amigaïstes sont aussi très sympa – même quand ils sont passionnés 🙂

                              Au-delà de la performance, j’espère surtout voir des projets arriver au bout sous forme de jeux terminés. Le shmup dont tu as montré une vidéo a l’air très prometteur et c’est vraiment le genre de jeux qui seraient excellents comme vitrine de la machine aujourd’hui.

                              Et plutôt que de faire un portage de Shadow of the Beast (qui montre encore et toujours que l’Amiga sert de pierre de touche, ce qui est contre-productif à ton message), développe ton propre jeu! La force de l’Amiga comme de toutes les plates-formes qui ont eu la chance d’accueillir un choix pléthorique de jeux, ce ne sont pas seulement ses caractéristiques techniques mais aussi ses créatifs (musiciens, graphistes, game designers, etc.). C’est clairement ce que l’Archimèdes n’avait pas – probablement en partie à cause d’Acorn qui n’avait pas positionné sa machine comme telle en pensant probablement surfer sur le secteur éducatif comme avec les BBC, ce qui fut au final un échec.

                              Un dernier point pour terminer, je suis allé vérifier sur Wikipedia le prix de lancement de l’A305 (le moins cher) et de l’Amiga 500, puisque c’est lui aussi un modèle moins cher et qu’ils sont sortis la même année. L’A305 coûtait 800£ alors que l’Amiga 500 coûtait 500£. Ça fait tout de même une sacré différence!

                              Pourquoi parler en terme d’année fixe, là où il faudrait raisonner en prix de lancement.
                              Le A305 est moins cher que l’Amiga1000 ( et le 305 a 512 ko, le A1000 que 256 ko )
                              Si tu veux comparer sur la même année, 1987, l’Archie A305 ou le A310, compare le au prix de l’A2000 ( tous 2 clavier et boitier séparés, ce sera un peu plus juste que de comparer un A305 boitier et clavier séparés avec un A500 monobloc )

                              Le shoot il me faut plein de graphismes que je n’ai pas.
                              SOTB j’ai récupéré de l’existant sur le Net, et tout fait tout seul.
                              Je trouve ça plus parlant d’en faire une version très améliorée sur Archie, que n’importe quoi d’autre.
                              De surcroît j’ai été défié de le faire, genre ‘*Jamais un Archimedes ne pourra avoir SOTB, ou alors ce sera incroyablement moins bien’ dixit DamienD, modérateur d’eab :c’est sur ma vidéo où ensuite je reprends les propos de Vascillious, que je partage entièrement :

                              Je sais très bien que de très nombreux Amigaïstes sont cool.
                              Ce qui est vrai c’est que quand tu te pointes sur eab et dis du bien de l’Archie tu finis par te faire virer.
                              Tu passes sur Gamopat tu te fais lyncher …

                              A nouveau, qui veux les pages d’insultes reçues directement dans ma BAL, de la part de Graeme Cowie, l’auteur de Rygar AGA ?
                              Tout ça car il pense que je suis Vascillious ?
                              Je ne suis pas lui, et de surcroît Vascillious sur eab n’a franchi aucune borne : c’est bien lui qui a été copieusement insulté, très rapidement.

                              Si vous ne voyez pas qu’il y a de gros problèmes dans votre communauté d’amoureux de l’Amiga, je n’y peux rien, alors que c’est une criante vérité.

                              Pour revenir à l’argumentaire prix, sans prendre en compte les caractéristiques des machines, c’est le Spectrum 128K la meilleure machine du monde.
                              Ou bien l’Atari ST quand ilvalait 2790 francs en France ( et plus de 4000 francs pour l’Amiga ).
                              Bref : comparer le prix des pommes et des poires, ce n’est pas parlant.

                              L’Archimedes était à sa sortie le micro ordinateur le + rapide du monde a moins de 10 000 francs HT ( Titre de SVM micro à l’époque ) et une des rares machines pour ce prix ( je pense même la seule ) à offrir des résolutions non entrelacées 640×480 256 couleurs, 800×600 en 16, et 8 canaux hardware PCM, avec 7 positions stéréo indépendantes par canal.
                              Aucune autre machine n’offrait tout ça dans cette gamme de prix, ou alors svp indiquez moi laquelle.

                              EDIT : le post de DamienD, modérateur sur eab, concernant SOTB sur Archie : http://eab.abime.net/showthread.php?p=1195620#post1195620

                              fenrix

                                #353952

                                Salut,

                                Pourquoi parler en terme d’année fixe, là où il faudrait raisonner en prix de lancement.

                                C’est exactement ce que je fais en prenant l’année 1987, qui sauf si Wikipedia dit des bêtises, est à la fois l’année de lancement de l’A305 et de l’Amiga 500. Et comme les deux ont 1/2 Mo de RAM, au moins de ce côté là, c’est comparable aussi.

                                Qu’une machine qui coûte 800£ à son lancement soit plus performante qu’une machine qui coûte 500£, je trouve ça logique mais à nouveau je me demande du coup ce que tu essayes de prouver.

                                Mais… je suis quand même allé regarder le prix de lancement de l’Amiga 2000, tu as éveillé ma curiosité 🙂

                                Apparemment, son prix de lancement était un peu plus du double de celui de l’Amiga 500 (1500$, ce qui convertit doit faire un peu plus de £1000 de l’époque). Il est cependant peu probable que ce soit le boitier qui justifie la différence de prix, comme tu le suggères.

                                D’une part l’Amiga 2000 propose une série de ports d’extensions (5 ports Zorro et 4 ports ISA) que ne possèdent pas l’Amiga 500, lui permettant d’être bien plus ouvert et modulable.

                                D’autre part, le prix plus élevé se justifie car le public ciblé est le milieu professionnel, c’est à dire un milieu qui à la fois peut se permettre de payer un tel prix (c’est un investissement) et qui en même temps associe souvent un prix élevé à de la qualité (à tort ou à raison). Apparemment l’Amiga 2000 n’était même pas en vente dans la grande distribution, ce qui confirme cette orientation marketing.

                                Attention, je ne fais cependant évidemment pas de lien strict entre prix, puissance et qualité globale. Au rapport qualité/prix, les machines 8 bit (en particulier le Commodore 64 et le Spectrum) passeraient certainement devant les autres, comme tu le dis si bien. Et la Super Nintendo à 1290 FF au lancement, qui a été l’une des consoles les plus abordables de l’histoire. Mais ça, c’est une autre histoire…

                                Et à nouveau, la qualité globale d’une machine et, au final, son succès ne se mesurent absolument pas à ses performances. La Game Gear enfonçait la GameBoy pour un prix raisonnable. On a vu le résultat.

                                Je reviens donc à la conclusion qu’à mon avis, même si ce que tu montres est très intéressant, tu enfonces des portes ouvertes et c’est dommage que ça n’aboutisse pas à la création de jeux à part entière. Sans faire tout tout seul (je conçois très bien que tu ne puisses pas être doué en tout) il y a dans la communauté homebrew plein de talents qui pourraient sans doute te filer un coup de main pour les aspects artistiques. Beaucoup sont investis dans des projets multiplateformes et travailler pour l’Archimèdes en plus serait sans doute une découverte intéressante pour beaucoup. Et à défaut de jeu complet, peut-être serait-ce l’occasion de faire une megadémo dans l’esprit de la demoscène, ce qui là aussi valoriserait ton travail (et pour le coup, c’est un milieu dans lequel la performance technique est aussi un but en soi).

                                Après si ton seul but c’est de gagner une guerre déjà gagnée (techniquement) et perdue (commercialement) il y a 30 ans… bon courage!

                                Ce qui ne m’empêchera pas de suivre attentivement tes progrès 🙂

                                modulo

                                  #353953

                                  Plus haut, on parlait d’un émulateur de neo-geo. Ce n’est pas si absurde que ça sur Archimede (Zarchos n’avait pas l’air d’y croire, si j’ai bien lu). La neo-geo n’avait aucun sprite et ne travaillait que sur des gros blocs bitmaps (je crois que c’était même sa structure de données de base, il n’y avait rien d’autre).

                                  L’archimède avec ses capacités de copie de données s’en rapproche donc fortement.

                                15 sujets de 46 à 60 (sur un total de 119)

                                • Vous devez être connecté pour répondre à ce sujet.

                                Forums AmigaOS, MorphOS et AROS Développement Amiga blitter vs Archimedes ARM power ;-)

                                Amiga Impact