Re: Amiga/st vs Archimede

[Invité]

oui bien sur, l'amiga à la base c'est ça, avoir une machine 2D novatrice, pour un coût le plus bas possible .
Bien sur l'amiga à des faiblesses, et une grosse, la gestion des sprites .
En 84/85 ça déchirait, mais avec l'apparition des consoles 16 bit, il à montré ses limites, sans être ridicule techniquement.
Bien sur résumer l'amiga au 68000 est débile, pour pleins de raisons évidentes.

Mouai,
Avant je trouvais ça chiant les bitplans. Faut faire des masquage, faut se prendre la tête pour faire des trucs qui déchirent etc...
Mais en fait, c'était une astuce pour atteindre un bon niveau de puissance pour pas cher.
C'est un peu l'esprit sony.
je veux dire "adaptez vous au matériel et si vous êtes astucieux vous ferez des miracles"

Et ça c'est le boulot du blitter, de se faire chier pour ça .

Après les astuces de progs permettent de pousser les machines vraiment à leurs limites .
faut voir ce qui à été fait sur ST, c'est exceptionnel .

[MikeeMike_2008]

ton squoquo est a des années lumières du mig de 89 a 92 et jusqu'a ses productions sur pc, et sur pc il est de nouveau a des années lumières des groupes du mig passés sur pc en fait il est toujours a la traine :lol:

pour enfoncer le clou va matter le résultat de tous les démomakers de chaque année, de chaque démo partie depuis le début et tu verras ou en sont tes programmeurs d'archimèdes ..... si il y en a

http://www.pouet.net/

et tu crois que sur amiga il n'y en a pas qui ont participés a des jeux d'arcade, de consoles.... non mais franchement !!!! tu crois que les boites d'éditions ne lorgnaient pas sur les programmeurs "les vrais pas les factices" !!!

50 jeux sur archimèdes et tous le monde regarde les programmeurs :lol: +5 000 jeux sur le mig allez va te consoler avec ton arrière plan buggé ce sera déjà bien va....

[babsimov]

Ah oui : pour l'amiga, c'est sûr c'est bien les effets qu'on voit.
Le pôvre : on ne va pas lui en demander plus, avec le peu dont il est équipé par rapport à un Archie.

Là, je te trouve condescendant !
Que l'Archimède dispose d'un excellent processeur, c'est une chose, mais que tu dénigre à ce point une machine telle que l'Amiga est abusif.

Que pourras tu prouver si avec ta démo ou ton jeu tu arrives à faire ce que faisait l'Amiga 500 avec ses copros ? Tout simplement qu'Acorn aurait mis 4 à 6 ans de plus que l'équipe de l'Amiga originale pour offrir la même chose, mais sans copro.

D'accord, au niveau programmation ce sera très bien. Mais ça t'aura demandé une somme de travail considérable (d'après ce que je comprend de vos débats) pour faire ce que faisait l'Amiga sans difficulté avec ses copros. Ce qui ne fait que démontrer l'importance des copros dont le but est d'apporter un surcroit de puissance à un processeur "basique" et non pas "ridicule" comme tu dit.
Tu veux comparer deux générations différentes de machines une 16 BIT datant de 1985 (mais je dirais plutôt de 1982/83) et une 32 bits datant de 1988.
L'Amiga n'était pas parfait, mais je pense que sa réputation de puissance en 2D ne s'est pas faite toute seule sur la foi de prétendus programmeurs menteurs.
Par exemple, programme un clone de shadow of the beast à l'identique sur Archimède, un Battle Squadron, un Agony, un Project X, un Stardust. Tout ça fait uniquement avec le processeur ARM de l'Archimède et tu convaincras tout le monde que l'Archimède a été sous exploité en 2D.
Autre chose, tu va parler de "256 couleurs" au lieu de 32 couleurs.
Je te dirais, n'oublie
pas le copper ! Je me souviens du jeu Beneath a steel sky qui affichait
exactement les mêmes graphismes 256 couleurs/VGA sur OCS que sur AGA (et
les mêmes animations), justement parce que le programmeur avait
habillement utilisé le copper. Beast aussi avait plus de 32 couleurs, ou
Bio Challenge. Sans copro, l'Archimède ne peut pas faire ça je pense,
il est limité au 256 couleurs imposée par Acorn ?
Quoi qu'il en soit, pour l'instant je te laisse le bénéfice du doute. Il ne te reste plus qu'à démontrer que tous ici se trompent.

Je te remercie : tu viens de montrer qu'un PC puissant peut faire ce que l'Amiga sait faire.
Ca tombe bien : mon Archie avec ses 4 MIPS, son mode chunky 256 couleurs ressemble bien à un PC puissant de l'époque.

CQFD.

Là encore, je te trouve condescendant !
Les premières versions d'émulateurs Amiga (UAE) réclamaient au minimum un pentium 166/200 pour arriver à faire à peu près tourner correctement les démos et jeux Amiga (bien entendu uniquement OCS/ECS, pour l'AGA il faudra attendre encore un bon moment). Si je ne me trompe pas, un pentium à cette fréquence approchait des 200 MIPS ! Et même si on met de coté l'émulation du chipset (sans le son parfait), il y avait encore des scrolling saccadés sur des machines aussi puissantes. Donc je pense que dire qu'un processeur à 4 MIPS peut "écraser" un Amiga 500 et ses copros pour la 2D est peut être optimiste.
Autant je trouve normal qu'un PC 200 fois plus rapide qu'un Amiga parvienne (avec difficulté) à l'émuler. Autant, je suis dubitatif qu'il suffise de simplement 4 fois environ sa puissance pour l'égaler parfaitement ?

Mais, pour l'instant, comme je l'ai dit, je te donne le bénéfice du doute.

[stapha92]

Bon, Archie, il est temps que quelqu'un te remette en place. Normalement je ne devrais pas perder de temps avec toi mais, dans la mesure ou je te trouve trop hautain et irrespectueux je vais me faire un plaisir à détruire tes affirmation et à montrer aux lecteurs ce que valent VRAIMENT ton archimèdes et ton ARM...

Mais d'abord je vais répondre à certains de tes posts :

Je suis heureux que tu sois content... Il n'empeche qu'il y a eu plus d'utilisateurs qui ont utilisé de façon sérieuse un A500 sans second lecteur (j'en ai fait partie, donc le INUTILISABLE, tu peux te le garder) qu'il y a eu d'utilisateurs Archimedes en tout...

Oui, sûrement, et ces utilisateurs ont fait la fortune des opticiens ;-)
Un A500 de base, sérieusement ? Tu faisais tourner quoi dessus ? Là ça m'intéresse. Deluxe Paint ou un Soundtracker ?

Il y a des tas de logiciels qui fonctionnaient sur un A500 de base (ou sur un A1000). Deluxe paint en faisait partie et c'était le top en matière de dessin sur micro.
Quand aux opticiens, je te rappelle qu'un écran capable d'afficher du 30 khz en couleurs (seul moyen de dépasser 300 lignes sans scintillement) valait 2 ou 3 x plus cher qu'un Amiga. Rien d'étonnant à ce que les premiers modèles ne proposaient pas de mode vga donc : ceux qui pouvaient s'offrir un écran multisync pouvait prendre un désentrelaceur. Et le problème du cout du moniteur se posait tout autant avec l'Archimedes : beaucoup de ses utilisateurs devaient se contenter d'un moniteur 15 Khz non ? Mais peut-être que tu vas nous expliquer qu'un Archimedes affiche 480 lignes non entrelacées sur un téléviseur ?
Ou peut-être veux tu parler des modes entrelacés du mig ? Sauf que ce n'était pas une obligation : les modes graphiques de l'Amiga peuvent TOUS (y compris le HAM qui d'après toi flashouille...) être affichés en entrelacé ou en progressif. Et au lieu de te moquer en parlant des opticiens, explique nous : tu n'as jamais regardé la télévision ? Parce que les programmes sont entrelacés : quand une chaine émet en 576I, cela donne un signal entrelacé avec moins de lignes qu'un Amiga pouvait en afficher en pal, et il s'agit du format le plus utilisé sur la TNT...
Et à l'époque du mig c'était pire : toutes les vidéos (diffusées et enregistrées) qui existaient étaient entrelacées : On a tous remarqué que Zidane flashouillait en 98...

Donc arrete de parler d'écran qui scintille : ça montre juste que tu ne sais pas de quoi tu parles.

Oui bien sur, il n'empeche qu'il y avait beaucoup plus de logiciels pro sur Amiga que sur ta super machine...
Quand aux jeux, on sait tous que l'archimedes était à la peine...

Il y en avait plus, oui et alors. Quantité = qualité ?
Nous on en avait toujours un ou deux par domaine, vraiment excellents.
Il n'était pas à la peine pour les jeux, il n'a pas attiré de vraies équipes du fait de sa faible diffusion, c'est très très différent.

Disons que la quantité entraine la concurrence et augmente les chances d'avoir des perles. Prétendre que vous étiez aussi bien fourni que les amigaistes ou stistes en applications de qualité est une hérésie.

La ligne de commande, excuse moi, mais sous RISC OS, qui a un vrai GUI son usage est anecdotique.
Un browser sur Amiga500 ? Whaouuu ... ça doit donner ;-)
Les datatypes, comme tu as l'air d'en parler, c'est aussi dans le RISC OS, ça s'appelle filetypes chez nous.
Je ne sais pas comment NetSurf traite les données, en tout cas multithreading ou pas il est rapide et performant.
Pourquoi passes-tu le reste de l'intérêt du RISC OS ? Modulaire, ouvert, extrêmement bien documenté, très ergonomique ?
C'est là en partie : http://www.operating-system.org/betriebssystem/_french/bs-riscos.htm
Ca t'arracherait les tripes d'être objectif et de rendre à César ce qui appartient à César ?

Donc tu sous-entend que l'AmigaOS n'a pas une vrai GUI ? Tu devrais te renseigner sur ce que sait gérer intuition en natif : je pense que tu serais surpris de découvrir des choses que ta "vrai gui" ne sait pas gérer... Et je parlais de l'AmigaOS par rapport au RISC OS. Que vient faire l'A500 là dedans ? Parce que un browser sur le moins cher des Archimedes (qui valait beaucoup plus cher qu'un A500), ça doit donner aussi. Surtout quand tu veux faire défiler une page web pendant qu'elle s'affiche...
Objectivité ? Tu crois en faire preuve ? On verra ça quand on abordera les VRAIS specs de ta machine.
Quand à l'idée révolutionnaire des applis en ROM (ce qui était la mode avec les 8 bits et a été abandonné depuis...) : aucun intérêt d'avoir un BASIC en rom (là c'est du "8 bit style" tout craché...) à un moment ou la POO commençait à décoller par exemple. Sur le mig il y a eu un BASIC original (made in Microsoft, donc pas terrible) très vite supplanté par le GFA qui a été très vite dépassé par AMOS et encore plus par le blitz. je ne parle même pas du E (hyper puissannt, dédié à la POO et totalement gratuit). Je suis bien content qu'il y ait eu cette évolution et de ne pas être resté coincé avec le même langage pendant plusieurs années...
Et le BASIC, c'est bon pour les débutant, mettre un compilateur C aurait été bien plus sérieux (mais ça n'aurait pas convenu à la BBC peut-être ? lol !)
Donc je ne suis pas pour l'intégration de logiciels en ROM, car ils évoluent trop vite.
Et oui, le coté modulaire est un plus, que l'AmigaOS avait aussi. A tel point que lorsque les premières cartes PowerPC sont sorties, il a suffit de créer des librairies pour l'exploiter. Idem pour les cartes graphiques, 3D, ports pci, cartes USB...
Quand à l'usage anecdotique de la ligne de commande, j'ai bossé à l'époque sur des stations SPARC et je ne pouvais pas m'en passer. Pourtant, il y avait X-Window dessus. Donc, si je te comprend bien, X-Window n'est pas une vrai GUI ?
Les filestypes ? Est-ce vraiment l'équivalent des datatypes (qui correspondent au codecs de windows mais pour tous les types de données) ? N'est-ce pas plutot un système qui compense l'absence d'extension de fichier ?...

Oui des applis en standard en ROM c'est une excellente idée... avec un super BASIC incluant un assembleur.
Pour le même prix tu ne pouvais pas avoir l'équivalent d'un Archimedes, réfléchis :à l'époque sur un Amiga500 tu aurais dû lui ajouter une carte 68030, de la mémoire, un disque dur (pas besoin sur l'Archimedes puisque l'OS est en ROM) un désentrelaceur, un vrai basic, un vrai assembleur, et un beau gros boitier externe pour 4 cartes additionnelles ... et t'aurais juste eu du poussif rajeuni.
Tu cites le DP, t'inquiètes sur Archimedes on était extrêmement bien fourni, les développeurs étant dès le départ des universitaires, des étudiants et des scientifiques qui avaient la machine dans leurs établissements ou laboratoires via l'équipement de l'éducation nationale anglaise.

Je t'ai déjà expliqué pourquoi, pour moi, les applis en ROM ce n'est pas une bonne idée, d'autant que ça peut dissuader les éditeurs de sortir des applis si elles sont en concurrence avec quelque chose livré en standard.
Maintenant ta comparaison est biaisée : une rom ne peut pas à elle seule remplacer un disque dur. le désentrelaceur, il n'y en pas besoin sur un A500 ECS qui peut afficher du VGA (et on retombe sur le problème du prix du moniteur...) et un 68030 est bien plus puissant que ton ARM.
Un A500 avec un boitier GVP qui intégrait tout ce que tu cites (hormis le désentrelaceur mais avec la possibilité de mettre une carte graphique) le rendait très puissant. Je t'assure que ce n'était pas du tout "poussif"...

Ah ? T'es sûr d'avoir déjà vu tourner l'OS ?
Aucun copro ? Le MEMC permet de faire scroll hard horizontal et vertical au pixel près.
Tu ne l'as pas vu dans les jeux, car les programmeurs avaient en général 8 jours pour convertir un jeu Amiga ou ST sur la machine, avec un budget misérable ... Sur youtube tu as des demos tout de même, tu pourrais être un peu curieux.
https://www.youtube.com/watch?v=1VtnaGabyoc
Pas de ma faute si Youtube est infoutu de la montrer en 50 images/seconde.
Pas de ma faute non plus si d'autres démos genre Blackhole de Squoquo ne sont pas sur le Tube, mais tu les as là avec bien d'autres : squoquo.de avant 2000
elles tournent bien sous émulation avec Arculator.

Euh, la presence de registres d'adresse pour l'écran associé à un offset permet de faire du scrolling hard mais ne fait pas du MEMC un coprocesseur. Etudie un peu l'architecture du mig et tu sauras ce qu'est un coprocesseur, car lui en a 2. Ces registres sont très pratiques mais n'aident en rien lorsque l'OS doit afficher ou déplacer un élément graphique par exemple, ce qui lui arrive très souvent (et pour ce genre de travail, un ARM est moins doué qu'un 680x0), surtout quand ce dernier dispose d'une "vrai" gui...
Le scrolling hard ne sert que pour les jeux ou pour les bureau virtuels. Y avait ça sur Archie ? parce que ça existe depuis longtemps sur le mig qui n'a pas une vrai gui soi-disant...

Ah ? Vous avez Virus en 256 couleurs sur Amiga ?
T'es au courant que 256 couleurs ça veut dire 2 fois la masse de données à afficher par rapport à du 16 couleurs ?

T'es au courant que c'est pas aussi simple ? En fait afficher un pixel en 16 couleurs sur Amiga ou ST oblige à écrire 4 fois plus de données que pour 1 pixel en 256 couleurs sur Archimedes. Soit on positionne 4 bits (et accéder à un bit coute autant qu'accéder 1 octet), soit on construit des mots qui devront subir des opérations logiques avec les données déjà présentes dans le buffer écran : il faut en lire autant qu'il faut en écrire...
L'architecture des ST/Amiga est tellement pénalisante lorsqu'il faut faire un traitement pixel par pixel qu'il est bien plus avantageux de travailler avec un buffer dans lequel les pixels seront stockés sous forme chunky et de convertir ce buffer entièrement vers du planar à chaque réaffichage...
Les PC de cette époque disposaient d'un affichage de type chunky et offraient des simulateurs de vol hyper fluides. Pourtant ils ne disposaient pas d'un ARM...

On est d'accord : l'Amiga peut faire en 2 fois moins (16 couleurs) bien ce que sait faire l'Archimedes.(256 couleurs).
L'accès à la RAM était lent pour les nazes qui n'ont jamais compris comment LDR/STR fonctionne par rapport à LDRB/STRB ... pour les autres (ceux qui ont des neurones et savent lire une doc) la RAM était bien assez rapide ;-)

Ah bon ? Faut être un dieu de la programmation sur Archimedes pour comprendre que les accès peuvent se faire par 8 ou 32 bits bits ? Pourtant c'est le B.A.BA de la programmation : tous les codeurs 68000 savent faire la différence entre un move.b, un move.w et un move.l. Parce que sur 680x0, les accès sont en 8/16/32 bits. Et tu dis que l'assembleur ARM est plus souple ? Trop drole, mais on y reviendra...
Et ça contredit ce que tu dis quand tu expliques que les codeurs sur Archie étaient très bons...

Ah ah ah comme c'est drôle de lire de telles bêtises !
'Un scrolling fluide est si compliquée sur Archimedes.' : t'as pas honte d'écrire de telles inepties ?
Ou alors tu veux dire scroll hardware ?
Re ah ah ah ! Excuse moi, je ne peux m'en empêcher : sur Archimedes, avec le MEMC, tu changes l'adresse où le VIDC va chercher les données à lire pour les afficher... dur dur, ça prend 20 instructions à tout casser, ça doit bien prendre 0,03% du nombre de cycles processeur disponible par VBL !
Il y a un registre qui détermine le déplacement de l'adresse de lecture, par 'paquets' de 32 bits, donc 4 pixels en mode 256 couleurs (1 octet=1 pixel). C'est cette adresse qu'on utilise pour les scrolls hard verticaux.
Pour le déplacement horizontal, au pixel près, ça semble donc rapé, hein ?. Hé hé ! C'est sûr ce n'est pas marqué dans la doc de VLSI noir sur blanc, du coup beaucoup sont passés à côté, mais en fait il y a aussi un registre qui gère le décalage de 1 octet, donc 1 pixel en mode 256 couleurs.
Ceux qui avaient raté ça changeaient le départ de la bordure gauche via le VIDC (avec lequel, en passant, on définit des modes overscan 'vrais', en moins de 100 instructions).
Une fois de plus, parceque tu ne l'as pas vu, ou bien tu ne sais pas le faire, ou alors tu as cotoyé des types qui ont eu un Archie et ne savaient pas le faire, tu en conclues à tort que l'Archie ne savait pas le faire.
Je t'invite à regarder ma démo où avec le code généré j'affiche à l'écran 3 sprites de 80x80, sur un scroll vertical, avec un soundtracker lisant un mod 4 voies, dans un mode graphique overscan 384*256, en 256 couleurs.
Il n'y a même pas d'astuce sur le fait que le sprite sphère est affiché 2 fois.
http://www.retrosoftware.co.uk/wiki/index.php/XTHOPAC_STUARC
C'est en 50 images par seconde.
Depuis je fais largement mieux. Et je ne suis pas un dieu de la programmation comme vous en avez eu sur l'Amiga.
Si ces personnes s'étaient penchées un peu plus sur l'Archimedes, je pense que tu en aurais tout simplement avalé ton chapeau.
Dès que l'Archimedes a commencé à être distribué en Allemagne, on a très bien vu ce que les demomakers qui s'amusaient avant sur ST et sur Amiga ont su en faire. (Dommage ce n'est pas sur Youtube, il n'y a que des vieilleries là).

Donc si je résume, il existe des astuces non documentées et qui n'étaient pas utilisées à l'époque pour faire un simple scroll horizontal ? Et ça servait à quoi ? D'autant qu'en matière de scroll, on est loin du compte même avec ces astuces par rapport à un Amiga. Normalement, pour faire un jeu comme M. Nutz ou Brian the lion, l'affichage en chunky de l'Archimedes est un avantage énorme pour appliquer les effets de zoom et/ou de rotation qu'on trouve dans ces jeux. Et pourtant je n'ai rien vu d'équivalent. Faut dire que pour reproduire tous les plans de scrolls et de parrallaxe, tes 2 registres magiques ne servent plus à grand chose, il faut réellement déplacer les données...
Donc AH AH AH : désolé mais c'est moi qui ne peut m'en empecher. Il y a des dizaines de jeux qui ne peuvent pas être reproduits sur ta machine qui valait une fortune...
100 instructions pour faire du 'vrai' overscan ? Que veux tu dire ? Un atari 800XL le fait avec 1 instruction. Un amiga avec 2 (un move pour dire ou l'affichage commence et un pour dire ou il s'arrete).
Doubler le sprite ? Génial ! Sur Amiga il était courant de les multiplexer PLEINS de fois sur la MEME ligne, ça permettait de rajouter un layer complet. et tu sais quoi ? tu pouvais aussi le faire avec un sprite en 16 couleurs (15+transparence). C'est pas du tout du même niveau et ce n'était pas réservé aux démos : pleins de jeux ont utilisé ce système. Le plus beau, c'est que ça n'utilise même pas le 68000 puisque le mig dispose d'un VRAI copro qui va tout prendre en charge...

Maintenant continuons sur tes explications : pour faire un scroll horizontal, les éléments que tu as donné ne suffisent pas. Il faut également une zone non affichées et pour ça, il faut créer un décalage de l'adresse de l'écran entre chaque ligne (on appelle cela le modulo). La zone mémoire non affichée sert alors à recevoir les futurs élements. Ce décalage est-il automatique ou faut-il confier ça au proc ? parce que si c'est le cas, c'est plus vraiment 0,03% du nombre de cycles par vbl... Et comme il faut travailler à chaque ligne et qu'il n'y a pas de syncho horizontal, ce n'est pas des plus pratiques...
Evidemment, pour un scroll vertical, le problème ne se pose pas. Bizarrement, c'est ce que tu as choisi de faire dans ta démo...
Je ne parle pas d'un scrolling parrallaxe ou chaque ligne (ou groupe de lignes) défile à une vitesse différente : il faut jouer avec une modification de l'adresse en cours (et pas l'adresse de départ) de traitement du circuit graphique et sur l'offset de décalage de pixels. Même si ça s'avère possible sur Archie (ce qui n'est pas dit), ça s'avèrera encore une fois très gourmand...
Je ne parle même pas des techniques de scrolling évoluées comme celles qui utilisent le wrapping : utilisées tardivement sur le mig, elle permettent d'utiliser beaucoup moins de mémoire écran et de blitter 2 fois moins de tiles (et bon courage pour implémenter la même méthode sur l'Archimedes...). L'amiga n'en a pas eu besoin pour faire des scrollings en 50 i/s au pixel près. C'est dire la marge qu'il avait.
Idem pour les écrans dont les lignes sont entrelacés en mémoire : très peu utilisés dans les jeux alors que cela augmente l'autonomie du blitter juste en fixant une certaine valeur de modulo... Encore une fois, cela montre la marge que l'Amiga avait et qu'il n'était pas du tout exploité à fond, contrairement à ce que tu dis.
Et pour la 3D, c'est pire : on a eu que des conversions ST alors que les optimisations possible en 3D sont multiples :
- Utilisation du blitter pour effacer l'écran.
- Utilisation d'un modulo permettant d'espacer chaque ligne d'un nombre octet qui soit une puissance de 2, afin d'utiliser des décalages en lieu et place des multiplications lors des conversions coordonnées->adresse
- Utilisation du blitter pour dessiner les lignes et/ou remplir les triangles
- contruction de chaque triangle dans un buffer sur 1 plan puis copie de celui dans les plans affichés (le blitter saura faire toutes les opérations logiques nécessaires tout seul)
- Utilisation du mode HAM. dans ce mode, on peut tracer une ligne en jouant uniquement sur les points situés aux extrémités (le HAM a été inventé pour ça à la base)
Tout ça n'a pas été utilisé dans les jeux. Pour une raison simple : les jeux 3D surfaces pleines n'avaient pas la cote. En gros ton Archie était doué pour les types de jeux les moins recherchés... LOL !

Je peux aussi te montrer des effets très simples à reproduire avec un affichage par plans (genre appliquer une surimpression ou un ombrage sur des grosses portions de l'écran) et qui mettrait l'Archie à genoux (car dans ce cas c'est lui qui devrait manipuler beaucoup plus de données et qui serait obligé de le faire dans les 2 sens)
L'affichage chunky est un énorme plus de l'Archimedes dès qu'il faut faire de la 3D. Mais tu as l'air d'attribuer tous les gains de ce type d'affichage à l'architecture de l'Archi alors que ce n'est pas du tout aussi simple.

Maintenant ta démo : ce que je vois c'est un scrolling vertical sans application de tile. un simple changement de l'adresse de l'écran et le tour est joué : rien d'extraordinaire. Si tu faisais un scrolling horizontal avec tiles ? LOL !!! Les scrollings horizontaux sont légions sur Amiga. Il y en a avec plusieurs plans, des parallaxes, etc... Alors essaie d'en faire un avant d'affirmer que ta démo explose le mig. Ensuite il y a des 2 sprites. Genial ! Mais tu oublies de préciser que :
- tu utilises un code généré et couteux en terme de place. Plusieurs Mo pour afficher 3 sprites sur un écran : ta démo montre bien les limites de l'archimedes...
(en gros tu parles de précalc tout le temps mais, en l'occurrence, c'est ton code qui est précalculé dans ta démo)
- il n'y a aucune gestion de masque : donc bonjour la détection de collision et une bouding box avec une sphère, ça doit être génial pour la jouabilité (les bounding box consistent à tester une collision en vérifant si les rectangles qui contiennent 2 sprites se chevauchent : je vous laisse tous imaginer ce que ça donne avec une sphère... lol !). On ne peut même pas parler de sprites en fait...
- tu utilises le cas qui t'arrange le plus : plus tes sprites seront gros et pleins et plus tu auras un grand nombre d'accès en 32 bits. Avec des petits sprites, ça sera bien moins bénéfique. Et avec des sprites non pleins aussi...
La seule chose qui mettrait en difficulté le mig, ce sont les 256 couleurs. Et encore, je vais revenir sur tes 256 couleurs...

Faudrait que tu regardes les démos en 256 couleurs qui existent en googlant.co.uk (et y a pas que Youtube dans la vie)... Allez, quelques pistes chez Karl Morton, entre autres, un demo coder qui était auparavant sur ST.
Si tu les veux je te les envoie, elles tournent sous Arculator.
La 3D texturée... ben tiens regarde ça :
http://squoquo.de/ releases 1998 et avant, il y en a.
https://www.youtube.com/watch?v=p3REoZ41AhI Pas mal, et en jeu.

Euh je trouve que le jeu en 3D texturé rame beaucoup quand même. On n'imagine pas avoir 4 mips et du chunky... Alors que dès que c'est de la 3D surface pleine sur Archimede, c'est toujours hyper fluide. Normal que ça n'aille pas aussi vite mais là la différence est quand même énorme (et il y a sur l'Archimede des tas de jeux en 3D surface pleine qui sont hyper fluide alors qu'ils affichent bien plus de polygones que l'exemple de jeu texturé que tu as posté). Tu es sur que la RAM ne ralentit pas ? parce que dès qu'il y a une texture à appliquer, cela oblige à lire des données octet par octet : ta méthode que tu penses révolutionnaire ne marche plus... Prend un Amiga avec un 68030 : un jeu texturé sera bien plus fluide que ton exemple et, pourtant, il y aura beaucoup moins que 4 mips dispo une fois la conversion chunky -> planar effectuée. Bizarre...

Totale ineptie : étudie l'architecture ARM et reviens discuter ensuite. Le PC, c'est à dire R15, contient et le Program Counter, et les status flags, c'est pour ça que l'adressage est limité à 2^26, ce qui à l'époque est totalement cohérent.
Faudra que tu m'en montres des Amiga avec 2^32 bits de RAM (MDR).
Pour la puissance on a eu aucun problème non plus : l'ARM3 à 33 Mhz était disponible à une fraction du prix de vos cartes 68030 ou 40...ce qui donnait 25 à 30 mips hé oui !
Chez nous on changeait une puce ARM pour une autre avec un quartz, chez vous on ajoutait presque une nouvelle carte mère, avec toute une circuiterie invraisemblable, tu parles d'une super trouvaille.
C'est à partir du RISC PC et son Strong Arm que le PC (registre R15) est devenu totalement dédié à l'adressage 32 bits, et les status flags sont passés dans un registre spécifique (MSR) mais je ne me suis pas aventuré à programmer ça.

Tu m'as mal compris : tu devrais relire au lieu de te moquer. Déjà tu parles de 4 Go, mais pourquoi allez à l'extreme ? la limite d'un adressage en 26 bits, c'est 64 Mo. Ensuite je pourrais parler de mémoire virtuelle : là tu dépasse 64 Mo sans problème à l'aide d'un swapfile et, ce dernier étant géré via la MMU, tout ça doit être vu comme un espace unique par le proc.
Mais, et surtout, je ne parlais pas de taille mémoire mais de compatibilité ! A partir du 68020, l'adressage est en 32 bits. Pour autant, l'AmigaOS reste totalement compatible (ce n'est pas le cas du TOS d'ailleurs...). N'y a-t-il pas un problème de compatibilité pour faire tourner le noyau de RISC OS sur un Strong ARM justement à cause de cet adressage ? N'y a-t-il pas une ré-écriture de ce noyau qui a été initiée (et peut-être terminé à l'heure qu'il est.) pour contourner ce problème ?
Mais je dois me tromper : il n'y a aucun problème dans ton RISC OS coopératif, puisqu'il est parfaitement écris...
Pour le coup du changement de proc, là c'est clair que c'est un avantage. Tu me permettras de le modérer un peu : quel interet de mettre un proc à 33 mhz avec une RAM qui a déjà du mal à suivre avec 8 Mhz ? Tu penses vraiment atteindre 25/30 mips de cette façon ? Faut que tu refasses des tests alors...
Tu es moqueur dans tes posts et tu prends les gens de haut mais tu nous expliques en étant sur de toi qu'on peut faire 25/30 millions d'instructions par seconde avec une mémoire qui permet de n'en lire que 8 millions par seconde. Et je dis lire, pas executer, car les instructions ont souvent besoin de lire ou d'écrire dans la RAM (c'est quand même le principe...) et "j'oublie" le fait que la RAM est utilisée par d'autre circuits, comme le circuit graphique par exemple.
Pour te citer : 25/30 mips ? MDR !!!
Nos cartes accélératrice avait une "circuiterie invraisemblable" justement parce qu'elle embarquaient de la RAM bien plus rapide que celle qu'il y avait d'origine et qui, de part l'architecture du mig, n'était pas ralentie par le chipset. Du coup les 80 mips d'un 68060 étaient parfaitement exploitables...
Et ne confond pas les mips d'un proc RISC et ceux d'un CISC. Il est communément admis qu'un Arm à 8 Mhz est 2 fois plus rapide qu'un 68000 à la même vitesse alors qu'il est annoncé pour 4 fois plus de mips. C'est normal car le 68000 génère un code plus concis (l'avantage de disposer de beaucoup d'instructions : on décompose moins). Et n'oublie pas que le calcul des mips sur un processeur tient compte des intructions disponible : sur l'ARM, il n'y a que des instructions simples, donc il sera avantagé (il n'y a pas de division sur l'ARM par exemple). En fait, aujourd'hui, plus personne ne compare la puissance d'un processeur RISC et d'un CISC via les mips... sauf toi !
Mais tu devrais étudier un peu le 680xx, : les instructions prennent moins de place. La plupart prenant 16 bits (en fait toutes celles qui n'ont pas d'opérandes direct. Et plus encore...) les 68020 et suivants en chargent 2 en un accès mémoire et utilisent l'overlaping pendant leur execution (pour peu que l'on sache vraiment coder en assembleur ou que l'on utilise un bon compilo), ce qui permet d'obtenir des durées d'executions réelles plus petites que les théoriques. A l'extreme, un 68040/60, exécute 2 instructions en même temps pour la plupart en un seul cycle. Et là, au niveau puissance, je t'assure que l'ARM ne suis pas. Rien que le fait que ses instructions prennent toujours 32 bits (même un simple ldr...) le pénalise fortement, sans même parler du fait qu'il en faudra en général plus pour faire la même chose ou des limitations lorsqu'on veut travailler sur la mémoire et non sur des registres.

Il y a 2 timers à 2 Mhz dans l'IOC, ça permet de faire pas mal de trucs. C'est sûr peu de programmeurs ont utilisé ces possibilités, car, une fois de plus, les programmeurs de jeux et démos les + talentueux n'étaient pas sur Archimedes, MAIS ça n'enlève rien aux qualités de cette machine.
Pour bien t'expliquer : l'usage de ces timers a été caché par Acorn (pour des questions de futures compatibilités hardware avec les futures bécanes) et il faut fouiller dans la doc de VLSI pour bien comprendre leur usage.
Je suis d'accord avec toi sur le fait qu'il est dommage que la H-Sync ne génère pas d'interruption sur laquelle on puisse brancher une routine. Ce fut un choix délibéré d'Acorn : ils n'ont pas voulu que le pipelining de l'ARM (cad le fait que l'ARM 'traite' 3 instructions en permanence) soit 'cassé' à la fin de chaque rasterline pour cause d'interruption levée, ce qui aurait dégradé les performances globales de la bécane.

Je ne vois pas en quoi mettre la possibilité de déclencher des interruptions horizontales aurait pénalisé la machine lorsqu'elles ne sont pas utilisée. Le ST et le mig possèdent ce type d'interruption et ça ne pose pas de problème, alors que c'est le domaine dans lequel l'ARM est le plus doué par rapport au 68000. Conception parfaite tu disais ?...

Une cinquantaine d'instructions seulement oui, c'est bien ça qui est superbe (ou alors tu n'as rien compris à l'intérêt du RISC face au CISC). N'oublie pas : 16 registres, opérations possibles sur 3 opérandes, quasiment toutes les instructions peuvent être conditionnelles, on a les shifts, la pré ou post incrémentations sur les transferts mémoires. La souplesse d'utilisation est jouissive.
Tous ceux qui ont taté du 68000 puis de l'ARM te diront que l'ARM c'est puissant et un jeu d'enfant à manipuler.
Qu'entends-tu par 'façon statique' ? Explique car je crois que je vais pouvoir t'en apprendre sur le MEMC (MEMory Controler).
En effet le VIDC gère la vidéo et le son (8 voies, au fait), et donc ? C'est mauvais parce que les 2 fonctions sont intégrées dans la même puce ? Sacré argument technique, j'adore. Parties son et vidéo sont traités sous DMA, de manière indépendante.
Et il y a un sprite hard : 32 pixels de large, hauteur illimitée, couleur 0 pour la transparence.
Personne ne s'en est servi (si moi lol), sauf que c'est en fait bien pratique, avec sa palette indépendante de 4096 couleurs, on peut faire des trucs bien rigolo avec.

L'interet du RISC n'est pas d'avoir 50 instructions, pas du tout. C'est de permettre de s'en contenter car lorsque le nombre d'instruction est réduit, il devient possible toutes les cabler. et elle s'executent alors plus vite que dans un CISC ou du microcode est utilisé...
La simplicité, c'est ça qui est superbe dans le RISC.
Par la suite, les procs CISC apprendront a faire une ou plusieurs instructions par cycle d'horloge. Mais au prix d'un nombre de transistor encore augmenté (gestion d'un ou plusieurs pipelines, architecture superscalaire). C'est pas pour rien que tous les appareils mobile d'ajourd'hui utilisent du RISC : moins de transistor = moins de consommation.
Je ne critique pas le fait qu'un même circuit gère le son et la video pas du tout, dans le mig PAULA gère bien une partie des entrée-sorties... Je parle de la simplicité de l'architecture : elle est hyper classique alors que tu la donne pour 10 fois mieux pensée que tout ce qu'il y avait. La simplicité peut être un avantage (et là il y a matière à un débat interessant), mais ce n'est pas ce que tu avais l'air de dire.
"8 voies, au fait" ? C'est vrai que le mig n'en a que 4. Mais encore une fois, son architecture lui donne un avantage énorme : lorsque l'on joue un sample, on indique l'écart en chaque lecture d'échantillon, ce qui permet de retrouver toutes les tonalités possibles sans surcout. Pour faire la même chose sur l'Archi, il faut obligatoirement rééchantillonner les samples en temps réel : non seulement c'est beaucoup plus couteux en cpu mais, en plus, le son est beaucoup moins bon (il le serait même si le rééchantillonage était accompagné d'un flitrage bi ou trilinéaire, ce qui n'est évidemment pas le cas). Résultat des courses : les mod sont souvent sur 4 voies (seulement "au fait"...) et ont un son moins bon que sur le mig. Alors que, sur le papier, les DAC de l'Archie n'ont rien à envier à ceux du mig et sont 2 fois plus nombreux. Architecture 10 fois mieux conçue ? LOL !

Et puisque tu as parlé d'augmenter de façon logicielle le nombre de voies dans un post, abordons ce sujet. Chaque fois que tu doubles le nombre de voies sur un canal tu perds un bit de résolution (assez simple à comprendre : pour mixer 2 samples, il faut faire la moyenne de leur valeur. Or la moyenne de 2 valeurs 8 bits correpond à la somme de 2 valeurs 7 bits). Donc tu perds en résolution sonore ce que tu gagnes en voies. Donc en passant sur 16 voies, tu descend à 7 bits. ça serait drole d'entendre ce que ça donne...

Sur le mig, à l'inverse de l'Archie, il y a des tas de choses qui n'étaient pas mises en avant. Par exemple, on peut basculer sur un autre mode qui n'offre que 2 voies mais sur 14 bits. En utilisant ce système, si on reproduit 16 voies, les samples auront une résolution de 11 bits...

Ben non, tu mettais en avant les petits softs du domaine public sur ta machine préférée, sur Archies aussi on a vite eu ce qu'il fallait pour remédier aux TRES RARES problèmes qu'on pouvait avoir. Les applications mal fagotées étaient peu, très peu nombreuses sur Archimedes, vois-tu.
On avait peu d'applis, mais toutes de très bonnes factures (tu peux retrouver les tests de l'époque, l'Amiga était souvent loin derrière, tout comme le Mac, ça ce sont des faits objectifs vérifiables).

Honnetement, je ne pense pas que le nombre de DP disponible était comparable. Quand à la qualité des applications, on va faire simple :
- Y avait PRO-24 ou Bar & Pipes sur Archi ?
- Y avait TVPaint, Brillance, photon paint, Deluxe paint ?
- Y avait Cygnus ED ?
- Y avait SCALA MM ?
- Y avait Lightwave, Real 3D, Imagine ?
- Y avait PageStream ?
Ce n'est qu'un petit échantillon d'applis considérés comme des références dans leur domaine et qui existent sur le mig, la plupart sont nées dessus et certaines lui sont exclusives (note aux ST-istes : et oui, PRO-24 existe sur le mig !)
L'existence ou non sur une machine d'applications unanimement considérés comme des références est aussi un fait objectif vérifiable.
Y a des applications qui sont nées sur l'Archie et sont devenues des références ? Au point de continuer à évoluer et à être commercialisées aujourd'hui ?
Parce qu'il y a des applis qui sont nées sur ST ou le mig et y ont acquis leur réputation avant d'être portées sur PC et de continuer aujourd'hui à évoluer et à être commercialisées (comme Cubase ou LightWave, pour citer un exemple sur chacune des machines qui te font marrer...)

Ne vous fiez pas à ce que vous voyez sur Youtube, qui doit être la démo tournant sous l'émulateur disponible sur PC, ça rame à mort, car plus le code d'origine se sert du hard de la machine, plus l'émulateur peine à le convertir.
(D'ailleurs ma démo 'technique' ne passe tout simplement pas sous émulateur, c'est dire !).
Cette démo du jeu est bien en 50 images par seconde sur un vrai Archimedes, et oui il y a du son : explosions et tirs, du plus bel effet.
Vous pouvez la récupérer ici :
http://acorn.revivalteam.de/?site=Downloads (Scorpius , section Gamedemos)
C'est une démo jouable.
Dommage le jeu complet n'est jamais paru, car l'éditeur a fait faillite entre temps.
Alors, pas mal pour une machine soit disant super nulle pour la 2D, non ? Et ça date de 1992.

Ok, alors analysons un peu ce que l'on voit : tu parles de 50 i/s. On voit tout de suite que c'est faux : les objets bougent bien plus souvent que le décor de fond. Donc les 50 i/s, ce n'est pas pour tout ce qui est affiché...
ça nous fait donc un plan du fond en 4 couleurs (trop fort ! alors que tu parles des 256 couleurs toutes les 3 phrases dans tes posts...) qui n'est qu'un motif répété 16 fois sur chaque ligne. Sur l'Archie, ça permet de limiter les accès mémoires (1 lecture pour 16 ecritures dans la RAM. Bizarre... Pourquoi limiter les accès mémoires s'ils ne sont pas pénalisant ?).
Sur Amiga, tu peux reproduire le scrolling du fond avec 1 seul sprite et en ajoutant un parrallaxe pour améliorer l'effet de profondeur. Et tu peux le faire sans utiliser le cpu : 16 petites copperlists a préparer au début du jeu et après le copper gèrera ça tout seul. Et encore, les jeux qui utilisent ce système le font en regroupant 2 sprites qu'il répètent sur la même ligne : là ça fait 16 couleurs pour le plan du fond...
Une question : pourquoi un fond en 4 couleurs ? Tu sais pourquoi ? Tu passes ton temps à insulter les gens ici en disant qu'ils ne savent pas coder. Et bien moi j'ai une hypothèse pour la méthode utilisée pour afficher le fond alors que j'ai jamais codé sur Archimedes. Et toi en as-tu une ? Je parle d'une méthode qui permettrait de gagner du temps dans l'affichage du décor de fond et qui expliquerait pourquoi seuls 4 couleurs sont utilisées. Evidemment mon hypothèse répond à ces 2 conditions et je n'ai eu besoin pour la formuler que de regarder la vidéo et lire ce que tu as expliqué sur l'assembleur ARM. Je peux la poster si tu veux : ça t'interdira de dire que je ne sais pas de quoi je parle.

En nettement moins bien techniquement, mais beaucoup plus connu, avec des musiques superbes et des explosions 'spacialiasées" (profitant du fait qu'il y a 7 positions stéréo sur Archimedes, et pas seulement le full left/full right comme sur Amiga (une petite quenelle en passant)), j'ai nommé : Nevryon, ici :
https://www.youtube.com/watch?v=jOwhIlMoZZs
Le programmeur s'est un peu cassé la tête pour avoir environ une 20aine de routines d'affichage différentes selon ce qu'il avait à afficher à l'écran (incroyable ! enfin quelqu'un qui réfléchit ! Moi j'en ai juste 4*32=128 et je fonctionne par raster, donc les 'lignes' de mes sprites peuvent être affichées en suivant n'importe quel décalage en X .Et j'en ai encore pas mal pour le 'unplotting'. Tout le secret est là. Evidemment il n'y a aucun masque. Ainsi c'est juste de 3 à 7 fois plus rapide que les routines traditionnelles (voire même de 12 à 28 fois plus rapide que la méthode des nazes consistant à n'utiliser que des LDRB/STRB pour manipuler pixel par pixel, une hérésie absolue sur un ARM où manipuler 1 octet prend le même temps qu'en manipuler 4 d'un coup).
Il voulait montrer que l'Archimedes pouvait se hisser au niveau de l'Amiga.
La suite de Nevryon, Technodream est encore meilleure, mais pas visible sur Youtube.

Il voulait peut-être le montrer mais il n'a pas réussi : ça ne tourne même pas à 25 i/s ton truc...
Dis moi : aucun masque ? Donc la détection de collision se fait avec des "bouding box" ? Sur le mig, on utilise plutot la collision au pixel près (le circuit le prend en charge pour les sprites et le blitter sait le gérer pour les objets qu'il déplace grace à ces fameuses opération logiques dont je parlais). C'est quand même meilleur pour le gameplay. Evidemment, l'absence de masque évite des accès mémoires. Encore...

Et les programmeurs qui ont taté de l'ARM avant qu'il ne devienne la norme dé facto dans tout ce qui est 'hand held' rigolent au nez des adorateurs du 68000 et autres power pc.

Ah oui ? Y a quoi comme ordinateur avec un ARM ? Y a que des trucs portables, pas de vrais ordinateurs (alors que le powerpc lui a été utilisé et l'est encore). Quand à l'assembleur ARM, je sais pas ou tu as vu qu'il était si bien : beaucoup de programmeurs qui ont travaillé avec pleins d'assembleurs considèrent le 68000 comme le meilleur. Et tu n'as pas l'air au courant mais, aujourd'hui, les ARM peuvent basculer en mode ByteCode (assembleur JAVA : une belle merde...) et seront capable de l'éxécuter en natif. Dans ce cas, du microcode sera utilisé. En clair tous les androids qui tournent sur un ARM n'utilisent pas l'assembleur ARM et utilise l'ARM dans un mode CISC. Et android est l'OS le plus utilisé sur ARM...

Voilà, ça a surement un sens pour les spécialistes de la formation des couleurs, mais pour moi c'est du charabia.

Ah bon ? Aucun sens ? Et bien un amigaiste, donc amateur de console d'après toi va t'expliquer.
Cela signifie que tu ne choisis tes 256 couleurs. Tu choisis uniquement les 2 (pour le vert) ou les 3 (pour le rouge et le bleu) bits les moins significatifs pour chacune des composantes. ça fait 16 possibilités qui correspondent aux 16 slots de la palette. Les bits les plus significatifs prendront, eux, toutes les valeurs possibles en fonction du numéro de couleur à afficher.
Par exemple, si tu définis la couleur 0 comme étant noire (valeurs rvb = 0,0,0), ta palette contiendra les couleurs suivantes :
couleur 0 : 0,0,0
couleur 16 : 8,0,0
couleur 32 : 0,4,0
couleur 48 : 8,4,0
couleur 64 : 0,8,0
couleur 80 : 8,8,0
couleur 96 : 0,12,0
couleur 112 : 8,12,0
couleur 128 : 0,0,8
couleur 144 : 8,0,8
etc...

En résumé, c'est nul :
- Tu ne peux pas choisir tes 256 couleurs
- Tu auras, par exemple, systématiquement 16 couleurs avec la composante verte presque à fond, ou 16 avec la composante rouge à la moitié, etc... : très utile...
- Quand tu veux modifier 1 couleur, tu en altères 15 autres : génial pour les rasters... lol !

Franchement, t'arrete pas de jurer par ton mode 256 couleurs mais ce mode est une arnaque. Je te donne un exemple comcret : imaginons que dans une image tu as besoin d'un dégradé complet de rouge. Il te faut 16 couleurs et, pour les obtenir, tu vas utiliser 8 slots sur ta palette, ce qui bloquera 128 couleurs dans ta palette. Le pire est que ça reste la même chose avec 10 bleus (toujours 8 slots bloqués). Donc si tu veux afficher une image avec 3 dégradés de 10 couleurs, tu... pourras pas ! L'amiga, avec ses 32 slots, y arrivera sans problème lui...
Et de plus, comme le copper peut modifier la palette facilement à chaque ligne, ça donne plus de couleurs que ton archi pourra jamais en afficher...
C'est ça l'Archimedes : soit disant une machine génialement conçue et qui, sur le papier, explose tout ce qu'il avait. Sauf que quand on étudie la réalité, on se rend compte que ça n'est pas le cas du tout...

J'ajouterai qu'à mon avis l'Archie peut faire du remplissage de face partiellement sous DMA, en changeant le pointeur video grâce au Timer1 de l'IOC, et ça à mon avis personne n'y a jamais pensé. C'est un des prochains points que je veux étudier.

Oui mais à ton avis l'Archie peut TOUT faire. Sauf que tu es ridiciule : en basse résolution, un pixel est affiché toutes les 140 nanosecondes (en pal/ntsc). Ce qui fait 7,14 millions de pixels/secondes. Avec une machine de 4 mips, je te souhaite bon courage. En plus ton pointeur vidéo travaille comment ? J'ose espérer que c'est en 32 bits. Donc si t'arrivait à changer ce pointeur entre chaque lecture, tu aurais une résolution de 80 pixels de large en 256 couleurs et 40 pixels de large en 16 couleurs. tu aurais plus de chance en jouant sur la palette mais inutile d'étudier ça aussi : c'est tout aussi ridicule.
Et dire que tu traites les gens ici de nuls...

On peut parler raytracing, dessin vectoriel, DTP et autres logiciels sérieux où l'Archimedes PULVERISE l'Amiga et le ST tellement le lent 68000 est une poubelle

Ah oui ? faire tout ça avec processeur qui ne sait pas diviser ? LOL !!!
Soyons sérieux, les type de logiciels que tu cites, avait besoin d'une fpu pour tourner et, là, ton ARM peut retourner dormir.

Tu n'as pas compris le coup du timer à 2 Mhz...ben il permet de faire s'executer une routine tous les x/2 000 000 è de seconde... ahhhhhh soudain tu entrevois quelques possibilités niveau changement de palette etc ?

Moi je comprend que ce timer est débile : il aurait été bien plus efficace en étant calé sur l'affichage à 7,14 Mhz (genre 7,14/4 = 1,785 : zut ! pas loin !). Parce que là quand tu déclencheras tes interruptions, tu auras un forcément un décalage qui grandit avec la fin de chaque ligne. Il te faudra donc le corriger régulièrement...
Encore une fois : un choix de merde dans une machine soi-disant idéalement conçue...

Je reviens toujours à ma question : sur Amiga tu arrives à afficher quoi sur un écran dont le background est déformé par changement du x à chaque rasterline ? Il te reste quoi en terme de bitplan ? Tu vas mettre 1 sprite monochrome et te gargariser de la puissance de ton super ordi au CPU faiblard doté de copros ?

Y a pleins de jeux qui le font : Lion heart par exemple. Sur le fond, chaque ligne défile à une vitesse différente, et il ne reste pas qu'un bitplan...
D'abord déformer le background par modification des x est hyper simple sur le mig (même pas besoin du 68000 : le copper peut le faire tout seul), ensuite il n'y a pas de sprites monochromme sur le mig : c'est soit 8 sprites en 3+1 couleurs, soit 4 en 15+1 couleurs. et ces sprites font, comme sur l'archimedes, toutes la hauteur de l'écran. Sauf qu'ils se sentent moins seuls que sur ton archie, qu'il peuvent avoir bien plus de couleurs et que le multiplexage vertical est automatique...



https://www.youtube.com/watch?v=BoiHk_3siYg

Et ça c'est IMPOSSIBLE à faire sur ton Archimedes...

Car il peut déplacer de gros bloc de données en mémoire, sans solliciter le CPU .' c'est du bidon : l'Amiga n'est pas une Neo Geo. Sont où les jeux avec des personnages où des bosses énormes ?

Y en a pleins. Shadow of the beast par exemple (la moitié de l'écran pour certains). Ou M. Nutz : lui il utilise zooms et rotations en temps réel sur des boss qui peuvent devenir très gros.

Si en face tu me mets l'Amiga AGA avec carte accélératrice, moi je te mets en face un Archie boosté avec un ARM3, à 25, 33 ou 35 Mhz (tous overclockables au fait !).
Là, coté Amiga AGA, tu gagneras sur le nombre de couleurs, mais toujours pas sur la puissance donnée par l'ARM3, et ses 256 couleurs disponibles pour tout, sans contraintes de l'AGA.

Oui bien sur... Renseigne toi : un 68040 explose ton arm3 même overclocké...
Et quels contraintes de l'aga ? tu te trompes : l'aga a 256 couleurs sans contraintes lui...

L'OS en ROM sur Amiga500 ?
Tu rigoles j'espère.
Tout ce que tu as sur cette console de jeux c'est l"affichage d'une image d'une diskette (pour mettre un jeu, bien évidemment).

Et bien si... Y avait bien l'OS en ROM. Tu ne connais décidément rien du mig...

Ca encore, c'est une affirmation bidon de plus : le BLITTER a forcément besoin d'être programmé, ou de lire des valeurs crées via le 68000, pour réaliser ses opérations. Et ça ce n'est pas gratuit.
C'est bien pour ça que tous les super effets qu'on voit dans les démos ne se retrouvent jamais dans les jeux : pour chaque nouvelle image à obtenir et afficher à la synchro VBL suivante, il faut recalculer les nouvelles tables pour préparer la trame suivante....et ça bouffe un max de cycles du CPU 68000 misérablement lent.

Ah bon ? Tu sors ça d'ou ? Le blitter a juste besoin qu'on lui décrive le travail à faire et c'est tout. Pas de données à préparer avec le 68000. Tu dis n'importe quoi encore une fois.
Le blitter peut lire 3 zones mémoires différentes, leur appliquer des opérations logiques entre elles (256 différentes...) appliquer des décalages de bits (des vrais : avec les retenues qui sont recopiés d'un mot sur l'autre et pas tes décalages "gratuits"...), masquer des bits prédéfinis en début et fin de chaque ligne et écrire le résultat dans une 4eme zone mémoire. On peut remplacer chaque source par une pattern et dans ce cas son utilisation devient gratuite. Dans le pire des cas (3 sources activées), il lui faut 8 cycles pour traiter 16 pixels/plan.
Toi tu expliques que tu as besoin de 4 cycles pour une simple copie de 8 pixels en 16 couleurs. Et encore, ce n'est pas tout, il faut compter les copies des octets qui ne sont pas alignés sur 32 bits, en début et fin du sprite (et là c'est 4 cycles pour 2 pixels...) et il faut compter les branchements de fin de ligne et de bloc (on va pas parler en code déroulé : je parle de routines utilisables dans un jeu...). Au final ça fait combien ? 6 ou 7 cycles par copie simple ? On multiple par combien s'il y a 3 sources et qu'on applique les opérations que j'ai citées ? Tu crois vraiment que ton ARM peut suivre ? On t'a montré des jeux avec des tas d'effets hyper évolués. Des effets qu'on ne voit pas sur Archie, même pas dans les démos...
Tu ne connais décidément rien du mig...

Warf, un copper c'est exactement la même chose qu'un timer qui déclenche une routine de changement de palette.

Le copper est un processeur autonome qui execute son propre programme. Il sait vérifier et/ou attendre une colonne, une ligne ou une position de l'affichage ou même la fin d'une action du blitter.
Il peut d'ailleur piloter le blitter ou modifier la valeur de n'importe quel registre et sait faire des branchements. C'est lui qui est utilisé quand tu fais défiler un écran sous l'OS : là, il change de mode graphique, de résolution, d'adresse de départ et de modulo pour chaque bitplan, de pointeur souris et de valeurs pour les 32 couleurs de la palette. Tout ça en moins d'une ligne sans intervention du cpu. Si tu crois que c'est juste un timer c'est que tu ne connais décidément rien du mig...
Ah mais c'est vrai : tu ne dois même pas savoir ce que sont les défilements d'écrans. Inexistants dans ton petit os coopératif à la mode win 3.1...

Rien que le 68ec020 du 1200
peut l'exploser sur une simple copie de bloc !

C'est faux, c'est uniquement pour une écriture simple. Et même ton ARM s'en sort dans ce cas (genre : effacement de l'écran ou écriture d'un pattern répété. A la Scorpius... LOL !). Mais quand on fait des choses réelles, là le 68020 est jusqu'à plus de 10 fois plus lent que le blitter (et le 68020 est plus doué que l'ARM pour déplacer des données). Et pour te dire qu'il faut raisonner plus que ça : meme pour effacer l'écran, je préfère utiliser le blitter que le 68020 puisque ce dernier pourra faire autre chose en même temps. tu vois ? tu comprends rien à l'utilisation de copros...

Ce sera mon petit ARM blitter à moi, pleinement utilisable, lui, pour tout : jeux, démos, applis hors environnement GUI

Et le blitter, lui, était utilisé partout, y compris par les applis système, donc sous environnement GUI...

Maintenant que j'ai répondu à certaines de tes élucubrations, je vais expliquer ce que vaut vraiment ta machine. N'hésites pas à me corriger si je me trompe...

Tes 4 mips vs 1 mips, tu peux les oublier : comparer les mips entre du RISC et du CISC est complètement débile. Y a quoi comme instructions possibles dans tes 4 mips ? et y a quoi dans celles du 68000 ?

Décrivons l'ARM maintenant. Le principe qu'il a adopté est de tout simplifier pour que les instructions qu'il execute soit toutes cablées. Mais cela donne des contraintes énormes, que tu oublies dans tes descriptions élogieuses de l'assembleur ARM (qui n'arrive pas à la cheville de celui du 68000). Si tu étais plus ouvert tu t'en serais rendu compte depuis longtemps. Imagine simplement la compilations d'un code en C ou C++ en ARM d'un coté et en 68000 de l'autre : le code 68000 sera beaucoup plus court. Accéder au membre X de l'élément Y d'un tableau de structures ou de classes se fait en 1 seule instruction sur 68000 et c'est quelque chose que tous les programmes font tout le temps. Combien d'instructions en ARM ?

Et copier cet élément à la place du membre U de l'élément V d'un autre tableau d'objets prend toujours 1 seule instruction. On en est à combien là sur ARM ?

Revenons sur les contraintes de ton ARM : Toutes les instructions occupent 4 octets. Ni plus ni moins. Même la simple addition de 2 registres par exemple. Déjà qu'un ARM a besoin de plus d'instructions qu'un 68000 pour faire la même chose, si en plus ses instructions prennent plus de place, c'est vraiment merdique. A tel point que, bien après ton Archimedes, l'ARM a reçu l'extension THUMB, qui offre un jeu d'intruction 16 bits. Si ça a été jugé necessaire à une époque ou la RAM 32 bits valait bien moins cher qu'à l'époque de ton Archimedes, c'est que ça devait être un sacré handicap en 87...
Dans ces 4 octets, il faut tout mettre, y compris ce qui est commun à la plupart des instructions. Il y a toujours des bits réservés au décalage à appliquer par exemple (4 bits, ce qui fait que 12,5% des programmes est occupé par les décalages à appliquer, même s'ils n'en utilisent pas ou presque !), et d'autres réservés au conditions d'éxécution et au final, il ne reste que 8 bits pour stocker des constantes. Du coup si on veut affecter une valeur de 32 bits à un registre, il faut 4 instructions ! On affectera un octet à chaque fois tout en déclenchant un décalage (ah oui ! vu comme ça heureusement qu'il est gratuit !) sur 3 des 4 instructions. Génial l'ARM ! Bien sur en assembleur, on affecte surement une valeur de 32 bits en une instruction mais une fois le code assemblé, il y en aura bien 4 (ou bien stockage de la valeur pas loin du code qui l'affecte et utilisation de l'adressage indirect via le PC mais c'est pas toujours possible : les offset sont petits sur ARM...). Idem pour les affectations d'adresse bien entendu et pour les branchements relatifs : ceux-ci doivent être très court ou seront également décomposés en plusieurs intructions...
Enfin toutes les opération logiques et arithmétique (en gros tout ce qu'il sait faire) ne peuvent porter que sur des registres. Le 68000 peut travailler sur des registres, des constantes, des adresses mémoire absolues ou relatives, des pointeurs stockés en mémoire ou dans des registres voire les 2 en même temps (et il reste encore pleins de possibilités...). L'ARM est obligé de passer son temps à charger et décharger ses registres (d'ou le nom de son architecture : load/store). Pourtant, le 68000 possède lui aussi 16 registres internes et ils sont TOUS utilisable, le PC est un registre en plus, alors que sur ARM, il fait partie des 16. Dommage : une architecture qui a besoin de davantage de registre sans en avoir plus que le 68000...

Et ton ARM ne sait pas diviser : combien de mips dévellope ton ARM si tu inclus un algo de division dans le test ?

Et tu prétendais l'ARM doué pour du ray-tracing ? alors que ça demande des calculs trigonométriques dans tous les sens... LOL !

Maintenant les avantages :
- il est très doué pour les interruptions. Grace au sacrifice d'un registre qui sera utilisé pour l'adresse de retour (bien plus rapide mais moins souple quand il s'agit d'empiler des interruptions) et à la possibilité de swaper des registres en internes.
- il est capable de faire un accès mémoire à chaque cycle. Donc quand il charge une valeur à une adresse, c'est 2 cycles : un pour lire l'instruction et 1 pour lire la valeur et l'affecter au registre demandé. Et qu'est-ce que ça donne dans l'Archimedes ? Réponse : des engorgements !
Et oui, un 68000 ne peut accéder à la mémoire qu'un cycle sur 2 : donc dans un Amiga on a entrelacé les cycles. 1 pour le chipset et 1 pour le 68000 et ainsi de suite. Bien sur, sur le mig, on peut être obligé, selon l'exploitation du chipser, d'utiliser certains des cycles réservés au 68000 et c'est pour cela qu'il possède de la fast-ram : cette dernière n'est jamais ralentie.
Dans un Archimedes, il y a TOUJOURS des cycles processeurs qui sont perdus et, pourtant, aucune mémoire du type de la fast du mig... Bizarre, ça aurait été bien plus utile dans un Archi mais ça n'a pas été implémenté : et tu oses parler de conception parfaite ?

Faisons les comptes : un écran en 320x256 en 16 couleurs occupe 40 960 octets. Le circuit graphique aura donc besoin de 10 240 cycles (car j'ose espérer qu'il travaille en 32 bits...) par frame. Ce qui fait 512 000 cycles perdus par seconde ! Donc tes 8 Mhz tu peux les oublier. Avec ce type d'écran, c'est comme si l'ARM tournait à 7,488 Mhz. Tiens tes 4 mips de type RISC viennent de passer à 3,74 ! Et ce n'est pas fini : si tu passes en 256 couleurs, ça double le nombre de cycles perdus : on vient de passez sous les 7 Mhz ! Et ça peut être bien pire : passe en overscan et tu perdras encore des cycles. Affiche ton sprite et tu perdras encore des cycles. Joue un sample et tu en perdras encore... LOL ! Je n'ose aborder le cas des écrans vga ou de la haute résolution en 256 couleurs...

Resumons : on a une machine avec :
- 256 couleurs qui sont une esbrouffe car seules 16 peuvent être définies.
- le processeur le plus doué de sa génération pour les interruptions et aucune source qui permet de les utiliser correctement (à par la vbl mais, dans ce cas, la vitesse de déclenchement des interruptions est bien moins importante)
- un processeur capable d'accéder à la mémoire hyper rapidement mais qui subira systématiquement des temps de latence
- 8 voies sonores de samples qui bouffent du cpu pour jouer un mod (combien pour jouer un mod sur 8 voies ? 10 % ? 20 % Un amiga n'a que 4 voies mais utilise moins de 1 % de cpu pour les jouer avec une meilleure qualité...). mod dont la qualité sera forcément altérée par le rééchantillonnnage...
- 1 Mo mais un processeur qui a besoin de plus de 2 x plus de mémoire qu'un 68000 pour faire la même chose...

C'est ça l'Arhimedes : une machine hyper douée sur le papier mais qui, dans les faits, ne fait pas mieux qu'un pc de sa génération. A savoir de la 3D surface pleine fluide. Et c'est bien plus grace à son affichage chunky qu'à son ARM soi-disant 4 x plus puissant qu'un 68000, comme tu n'arretes pas de l'affirmer partout...

Allez maintenant, sors de tes routines "révolutionnaires" et trouve la méthode utilisée par Scorpius pour afficher le fond. Envoie là en MP à quelqu'un (par exemple Babsimov) si tu veux prouver que tu as compris comment ça marche mais que tu souhaites que je poste mon hypothèse d'abord...

Tu traites tout le monde d'ignare mais pour moi tu es un petit codeur qui ne découvre que la surface des choses et passe son temps à insulter les gens qui ont fait des jeux sur l'Archie (et tu compares leur travail à une pauvre de démo qui ne fait pas grand chose mais qui a besoin de plusieurs méga pour tourner).

Moi je pourrai aussi te considérer comme un ignare...

[Invité]

De toutes façons les mips ça veut rien Dire en utilisation réelle ,cad dans un programme .
Si on prend les 4 mips de l arm à 8mhz ça veut dire que les instructions sont à 2 cycle constants, comme il doit faire des tests,des branchement,des accès ram, des appels de fonctions, etc, çe sont des instructions qui consomment plus de 2 cycles,donc en conditions réelles, il dégagera jamais ses 4 mips.

Sans oublier le dma qui halte le cpu, donc quand il fait un transfert dma, le cpu il joue à 1 2 3 soleil.

[ArchieForEver]

Bon, Archie, il est temps que quelqu'un te remette en place. Normalement je ne devrais pas perder de temps avec toi mais, dans la mesure ou je te trouve trop hautain et irrespectueux je vais me faire un plaisir à détruire tes affirmation et à montrer aux lecteurs ce que valent VRAIMENT ton archimèdes et ton ARM...

Mais d'abord je vais répondre à certains de tes posts :

Je suis heureux que tu sois content... Il n'empeche qu'il y a eu plus d'utilisateurs qui ont utilisé de façon sérieuse un A500 sans second lecteur (j'en ai fait partie, donc le INUTILISABLE, tu peux te le garder) qu'il y a eu d'utilisateurs Archimedes en tout...

Oui, sûrement, et ces utilisateurs ont fait la fortune des opticiens ;-)
Un A500 de base, sérieusement ? Tu faisais tourner quoi dessus ? Là ça m'intéresse. Deluxe Paint ou un Soundtracker ?

Il y a des tas de logiciels qui fonctionnaient sur un A500 de base (ou sur un A1000). Deluxe paint en faisait partie et c'était le top en matière de dessin sur micro.
Quand aux opticiens, je te rappelle qu'un écran capable d'afficher du 30 khz en couleurs (seul moyen de dépasser 300 lignes sans scintillement) valait 2 ou 3 x plus cher qu'un Amiga. Rien d'étonnant à ce que les premiers modèles ne proposaient pas de mode vga donc : ceux qui pouvaient s'offrir un écran multisync pouvait prendre un désentrelaceur. Et le problème du cout du moniteur se posait tout autant avec l'Archimedes : beaucoup de ses utilisateurs devaient se contenter d'un moniteur 15 Khz non ? Mais peut-être que tu vas nous expliquer qu'un Archimedes affiche 480 lignes non entrelacées sur un téléviseur ?
Ou peut-être veux tu parler des modes entrelacés du mig ? Sauf que ce n'était pas une obligation : les modes graphiques de l'Amiga peuvent TOUS (y compris le HAM qui d'après toi flashouille...) être affichés en entrelacé ou en progressif. Et au lieu de te moquer en parlant des opticiens, explique nous : tu n'as jamais regardé la télévision ? Parce que les programmes sont entrelacés : quand une chaine émet en 576I, cela donne un signal entrelacé avec moins de lignes qu'un Amiga pouvait en afficher en pal, et il s'agit du format le plus utilisé sur la TNT...
Et à l'époque du mig c'était pire : toutes les vidéos (diffusées et enregistrées) qui existaient étaient entrelacées : On a tous remarqué que Zidane flashouillait en 98...

Donc arrete de parler d'écran qui scintille : ça montre juste que tu ne sais pas de quoi tu parles.

Bienvenu à la guerre !
Effectivement tu n'aurais pas dû perdre tout ce temps pour me sortir autant de sophismes.
Je vais perdre mon temps à te répondre, mais par fractions (à chaque jour suffit ça peine avec les malhonêtes).

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 ?
Je sais qu'en appli bureautique sur le Spectrum par exemple, on pouvait
vraiment faire du traitement de texte avec Tasword... si ... si ... quel
confort d'utilisation, magique. J'imagine bien le même genre sur Miga.

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é !

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 ?


PS : 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.
Rien à voir avec un bureau fixe, ou une page fixe de traitement de texte ou je ne sais quoi : là tu te détruis les yeux à coup sûr.

Voilà : déjà ça de fait pour te moucher, je vais attaquer la suite.

[make_me_a_sandwich]

stapha92 win

[MikeeMike_2008]

c'est clair archi-bouffon se défend avec un spectrum et laisse de côté son archimèdes.... etrange :lol:

l'archimèdes est quand même bien mieux que les mo5 que l'on a eut en france a l'école

[ArchieForEver]

Oui bien sur, il n'empeche qu'il y avait beaucoup plus de logiciels pro sur Amiga que sur ta super machine...
Quand aux jeux, on sait tous que l'archimedes était à la peine...

Il y en avait plus, oui et alors. Quantité = qualité ?
Nous on en avait toujours un ou deux par domaine, vraiment excellents.
Il n'était pas à la peine pour les jeux, il n'a pas attiré de vraies équipes du fait de sa faible diffusion, c'est très très différent.

Disons que la quantité entraine la concurrence et augmente les chances d'avoir des perles. Prétendre que vous étiez aussi bien fourni que les amigaistes ou stistes en applications de qualité est une hérésie.

Non, ce n'est pas une hérésie.
C'est juste ta vision de Français qui ne connait pas le monde Acorn et ne sait pas tout ce qui a existé sur Archimedes.
Pour les jeux, je le redis, on en a eu peu, certes, mais dans chaque domaine on a eu les hits des ST / AMIGA et d'autres, originaux à la plateforme, qui sont remarquables.
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 ....
De toutes façons je n'ai jamis nié que pour jouer évidemment il fallait prendre une machine de jeux, c'est à dire un Amiga.
Acorn ne visait pas le marché du jeu vidéo.
Acorn a créé un veritable ordinateur pour les écoles, et pas une pseudo console de jeux avec clavier comme l'Amiga.
Sors de ta vision 'Frenchie' et passe sur les sites anglais, tu verras à quel point l'Archimedes était utilisé en bureautique, dans la recherche, les labos, la vidéo (le broadcasting : nombreuses émissions à la BBC avec les cartes de Millipede.
Tu sais quoi, j'ai même une de ces cartes à la maison, que j'ai récupéré chez le programmeur de la BBC qui faisait les effets vidéos avec.
L'ingénieur de Millipede était un fou furieux et en comparaison sur les autres plateformes il fallait débourser 5 fois le prix de ses cartes pour obtenir à peu près l'équivalent).
Mais t'y connais quoi au fait à l'Archimedes ?
Etais-tu comme moi abonné à BBC Acorn User, Archimedes World, RISC USER, Archive Magazine ?
Non.
Alors reste à ta place de basher avant de la ramener sur un monde que, de France, tu ne peux appréhender.

[MikeeMike_2008]

pour la tv tu peux oublier l'archimèdes l'amiga 2000 rapport qualité prix c'était le top

et pour ce qui est du domaine scientifique de pointe (comme la nasa) c'est le l'amiga 4000 qui était utilisé pour sa fiabilité générale donc..... pas d'archi...

pour les écoliers c'était pas mal on va dire ....

en tout cas tu n'as pas les bogdanoff qui présente l'archimèdes

[ArchieForEver]

------Début de la citation de Stapha

La ligne de commande, excuse moi, mais sous RISC OS, qui a un vrai GUI son usage est anecdotique.
Un browser sur Amiga500 ? Whaouuu ... ça doit donner ;-)
Les datatypes, comme tu as l'air d'en parler, c'est aussi dans le RISC OS, ça s'appelle filetypes chez nous.
Je ne sais pas comment NetSurf traite les données, en tout cas multithreading ou pas il est rapide et performant.
Pourquoi passes-tu le reste de l'intérêt du RISC OS ? Modulaire, ouvert, extrêmement bien documenté, très ergonomique ?
C'est là en partie : http://www.operating-system.org/betriebssystem/_french/bs-riscos.htm
Ca t'arracherait les tripes d'être objectif et de rendre à César ce qui appartient à César ?

Donc tu sous-entend que l'AmigaOS n'a pas une vrai GUI ? Tu devrais te renseigner sur ce que sait gérer intuition en natif : je pense que tu serais surpris de découvrir des choses que ta "vrai gui" ne sait pas gérer... Et je parlais de l'AmigaOS par rapport au RISC OS. Que vient faire l'A500 là dedans ? Parce que un browser sur le moins cher des Archimedes (qui valait beaucoup plus cher qu'un A500), ça doit donner aussi. Surtout quand tu veux faire défiler une page web pendant qu'elle s'affiche...
Objectivité ? Tu crois en faire preuve ? On verra ça quand on abordera les VRAIS specs de ta machine.
Quand à l'idée révolutionnaire des applis en ROM (ce qui était la mode avec les 8 bits et a été abandonné depuis...) : aucun intérêt d'avoir un BASIC en rom (là c'est du "8 bit style" tout craché...) à un moment ou la POO commençait à décoller par exemple. Sur le mig il y a eu un BASIC original (made in Microsoft, donc pas terrible) très vite supplanté par le GFA qui a été très vite dépassé par AMOS et encore plus par le blitz. je ne parle même pas du E (hyper puissannt, dédié à la POO et totalement gratuit). Je suis bien content qu'il y ait eu cette évolution et de ne pas être resté coincé avec le même langage pendant plusieurs années...
Et le BASIC, c'est bon pour les débutant, mettre un compilateur C aurait été bien plus sérieux (mais ça n'aurait pas convenu à la BBC peut-être ? lol !)
Donc je ne suis pas pour l'intégration de logiciels en ROM, car ils évoluent trop vite.
Et oui, le coté modulaire est un plus, que l'AmigaOS avait aussi. A tel point que lorsque les premières cartes PowerPC sont sorties, il a suffit de créer des librairies pour l'exploiter. Idem pour les cartes graphiques, 3D, ports pci, cartes USB...
Quand à l'usage anecdotique de la ligne de commande, j'ai bossé à l'époque sur des stations SPARC et je ne pouvais pas m'en passer. Pourtant, il y avait X-Window dessus. Donc, si je te comprend bien, X-Window n'est pas une vrai GUI ?
Les filestypes ? Est-ce vraiment l'équivalent des datatypes (qui correspondent au codecs de windows mais pour tous les types de données) ? N'est-ce pas plutot un système qui compense l'absence d'extension de fichier ?...
[/quote]


-------- Fin de la citation de Stapha

Ma réponse :
Pour l'histoire du browser lis la file au lieu de rebondir bêtement dessus ; je répondais sur le même thèmes (car non je ne saute pas du coq à l'âne comme le toutcon pour esquiver).

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 !
Prétentieux élististe, va.
Si tu voulais un C, tu prenais celui d'Acorn.

Que je sache à la fin des années 80 le basic avec le pascal était omniprésent.
Acorn a donc tout bon, une fois de plus.

Pour tes histoires de dataypes, donne moi exactement plus d'infos et je te répondrai.
CE que je peux te dire c'est que sous RISC OS les types des fichiers vont déterminer quelles applis doivent les lancer. Le Filer gère ça très bien.
Acorn allouait les types pour les différents types de fichiers (comme texte, image gif, image jpeg, image tiff, image targa, etc ...) et il y avait une 'nomenclature' officielle à respecter pour que tout soit correctement géré et que chaque éditeur ait son type pour les fichiers spécifiques correspondant à ses applications spécifiques.

Pour te parler comme à un gamer : tous les types de fichiers MODs ont leur types spécifiques selon que ce soit du stracker, du stmodule, du digital symphony (spécifique archi), du qtm (queue the music) etc ...
Débattons là dessus, je ne demande que ça de sortir des Toukonneries subies jusqu'à présent.
I mean it.

Pour ce qui est de la ROM, qu'est-ce que tu veux que ça m'importe ton avis personnel sur la question, franchement ?
Pour des écoles ou autres, l'intérêt d'un sytème qui ne peut pas être bidouillé est tout simplement logique, flagrant, indiscutable.
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. Et ça l'est !
Et tous ceux qui ont eu ça entre les mains te diront la même chose, objectivement : c'est convivial et puissant.

[MikeeMike_2008]

eh oui tu subis le touko car ton 32bits est a la ramasse pour faire ce qu'il fait sur une 8bits la core c'est con hein (le mig non il arrive a faire mieux faut pas déconner quand même !!!)

[make_me_a_sandwich]

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 !
Prétentieux élististe, va.
Si tu voulais un C, tu prenais celui d'Acorn.

le C, élitiste ? par sur ! Si tu fais un tour sur des site tel que le site du zéro tu verra que beaucoup de personne lisant les tutoriel on 10/12 ans.

[ArchieForEver]

Maintenant ta comparaison est biaisée : une rom ne peut pas à elle seule remplacer un disque dur. le désentrelaceur, il n'y en pas besoin sur un A500 ECS qui peut afficher du VGA (et on retombe sur le problème du prix du moniteur...) et un 68030 est bien plus puissant que ton ARM.
Un A500 avec un boitier GVP qui intégrait tout ce que tu cites (hormis le désentrelaceur mais avec la possibilité de mettre une carte graphique) le rendait très puissant. Je t'assure que ce n'était pas du tout "poussif"...

Ah ? T'es sûr d'avoir déjà vu tourner l'OS ?
Aucun copro ? Le MEMC permet de faire scroll hard horizontal et vertical au pixel près.
Tu ne l'as pas vu dans les jeux, car les programmeurs avaient en général 8 jours pour convertir un jeu Amiga ou ST sur la machine, avec un budget misérable ... Sur youtube tu as des demos tout de même, tu pourrais être un peu curieux.
https://www.youtube.com/watch?v=1VtnaGabyoc
Pas de ma faute si Youtube est infoutu de la montrer en 50 images/seconde.
Pas de ma faute non plus si d'autres démos genre Blackhole de Squoquo ne sont pas sur le Tube, mais tu les as là avec bien d'autres : squoquo.de avant 2000
elles tournent bien sous émulation avec Arculator.

Euh, la presence de registres d'adresse pour l'écran associé à un offset permet de faire du scrolling hard mais ne fait pas du MEMC un coprocesseur. Etudie un peu l'architecture du mig et tu sauras ce qu'est un coprocesseur, car lui en a 2. Ces registres sont très pratiques mais n'aident en rien lorsque l'OS doit afficher ou déplacer un élément graphique par exemple, ce qui lui arrive très souvent (et pour ce genre de travail, un ARM est moins doué qu'un 680x0), surtout quand ce dernier dispose d'une "vrai" gui...
Le scrolling hard ne sert que pour les jeux ou pour les bureau virtuels. Y avait ça sur Archie ? parce que ça existe depuis longtemps sur le mig qui n'a pas une vrai gui soi-disant...

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.
J'ai juste un question à te poser ... on va rire !
Tu veux bien me donner le prix d'un HD en 1987, voire 1989, juste pour rire ?
Avec sa carte contrôleur, hein ? n'oublie pas.
Sur mon Archie, avoir une ROM où quasi tout ce dont on a besoin est dedans, et de la mémoire (1 Mo minimum, et ce fut vite 2), avec le RAM DISK du RISC OS, que le Filer gère comme n'importe quelle unité de stockage, ça tu peux le retourner dans tous les sens c'était absolument brillant.
Ca fait des économies extraordinaires pour travailler, justement sans un HD hyper onéreux dont tu as besoin sur ton Miga, qui va doubler le prix d'achat de ta petite machine qui semblait si bon marché au premier abord.

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 ?
Ah bon ? J'espère oui qu'il battra mon ARM à 8 Mhz.
Et tu veux que je te mette mon ARM3 en face, qui coutait une fraction de ton 68030 car ça sortait de chez Acorn, et il y avait juste un ARM3 et un quartz sur la carte fille qu'on insérait en lieu et place de l'ARM d'origine ?

Combien ça coutait vos cartes 680x0 bardées de toute la logique et RAM nécessaire pour fonctionner ?
Une fois de plus Acorn gagne haut la main.
Et quelle que soit la fréquence de ton 680x0, mon ARM à la même fréquence l'écrase littéralement, pour une fraction du prix.
On sortira les tableaux de drhystones etc etc si tu veux.
Tes sources c'est tirées du même wiki que le toutcon ?

Allez à demain pour la suite, je me régale d'avance en considérant le tissu de bêtises que tu as rédigé.

EDIT : j'ajoute que oui, on avait les bureaux virtuels. Moultes toutes petites applis domaine publique (tu sais, genre 5 Kb) le proposaient, à diverses sauces.
Le simple fait que tu poses la question prouve que tu ne connais rien au monde de l'Archimedes, mais comme tout bon Amiga basher tu penses pouvoir descendre en flammes cette superbe machine qui renvoit ton Amiga à la préhistoire du monde des 8 bits.

[ArchieForEver]

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 !
Prétentieux élististe, va.
Si tu voulais un C, tu prenais celui d'Acorn.

le C, élitiste ? par sur ! Si tu fais un tour sur des site tel que le site du zéro tu verra que beaucoup de personne lisant les tutoriel on 10/12 ans.

Tu le faix exprès ?
On parle de DIX NEUF CENT QUATRE VINGT SEPT.

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 ?

[ArchieForEver]

pour la tv tu peux oublier l'archimèdes l'amiga 2000 rapport qualité prix c'était le top

et pour ce qui est du domaine scientifique de pointe (comme la nasa) c'est le l'amiga 4000 qui était utilisé pour sa fiabilité générale donc..... pas d'archi...

pour les écoliers c'était pas mal on va dire ....

en tout cas tu n'as pas les bogdanoff qui présente l'archimèdes

Encore une fois c'est juste ta vision étriquée de franchouillard, qui ne connait rien au monde Acorn car la presse informatique française en a si peu parlé.

Tu vois
la BBC fonctionnait avec les cartes de Millipede (qualité broadcast avec
incrustation et effets vidéos variés en temps réel, et je crois que TF1
aussi s'est servi d'Archie.).

Y a que vous les Amigaïstes pour
penser que votre machine est si exceptionnelle alors qu'une petite
société comme Acorn et de petites boites d'ingénieurs en Angleterre
faisaient mieux.
Faut dire que le nombre d'universitaires ayant eu un Archie sous la main, ça a énormément apporté.
Mais ça vous êtes incapables de l'assimiler.

Je te laisse les 2 tricheurs plagiaires, c'est effectivement bien à l'image de l'Amiga.

[ArchieForEver]

@Stapha92.
Je reprends ainsi ta prose sinon c'est trop lourd à gérer.

Je te cite :
'

ArchieForEver a écrit:

Ah ? Vous avez Virus en 256 couleurs sur Amiga ? T'es au courant que 256 couleurs ça veut dire 2 fois la masse de données à afficher par rapport à du 16 couleurs ?

T'es
au courant que c'est pas aussi simple ? En fait afficher un pixel en 16
couleurs sur Amiga ou ST oblige à écrire 4 fois plus de données que
pour 1 pixel en 256 couleurs sur Archimedes. Soit on positionne 4 bits
(et accéder à un bit coute autant qu'accéder 1 octet), soit on construit
des mots qui devront subir des opérations logiques avec les données
déjà présentes dans le buffer écran : il faut en lire autant qu'il faut
en écrire...
L'architecture des ST/Amiga est tellement pénalisante
lorsqu'il faut faire un traitement pixel par pixel qu'il est bien plus
avantageux de travailler avec un buffer dans lequel les pixels seront
stockés sous forme chunky et de convertir ce buffer entièrement vers du
planar à chaque réaffichage...
Les PC de cette époque disposaient
d'un affichage de type chunky et offraient des simulateurs de vol hyper
fluides. Pourtant ils ne disposaient pas d'un ARM...
'
Ben oui je suis bien au courant que c'est hype merdique mais vous allez m'expliquer que c'est super.

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

[ArchieForEver]

@Stapaha.

Citation :
'

ArchieForEver a écrit:

On est d'accord : l'Amiga peut faire en 2 fois moins (16 couleurs) bien ce que sait faire l'Archimedes.(256 couleurs). L'accès à la RAM était lent pour les nazes qui n'ont jamais compris comment LDR/STR fonctionne par rapport à LDRB/STRB ... pour les autres (ceux qui ont des neurones et savent lire une doc) la RAM était bien assez rapide ;-)

Ah bon ? Faut être
un dieu de la programmation sur Archimedes pour comprendre que les accès
peuvent se faire par 8 ou 32 bits bits ? Pourtant c'est le B.A.BA de la
programmation : tous les codeurs 68000 savent faire la différence entre
un move.b, un move.w et un move.l. Parce que sur 680x0, les accès sont
en 8/16/32 bits. Et tu dis que l'assembleur ARM est plus souple ? Trop
drole, mais on y reviendra...
Et ça contredit ce que tu dis quand tu expliques que les codeurs sur Archie étaient très bons...
'

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.

Oui l'assembleur ARM reste plus souple, malgré tout.
Et je l'affirme, signe et persiste : 16 registres, opération sur 3 opérandes pouvant toutes être conditionnelles, barrel shifter pour 0 cycle supplémentaire.
Tu peux aller te rhabiller avec ton 68000.
Tous ceux qui ont codé en ARM venant du 68000 ont oublié le 68000.

Ca t'arrache le coeur les réalités ?
Ben grandis et vis avec.

Je n'ai jamais dit que les codeurs sur Archie étaient très bons.
Prouve moi ce que tu me prêtes comme propos.
J'ai dit que c'était tous des fainéants sauf quelques uns comme les codeurs de StarFighter3000 et Scorpius.

C'est comme pour la souplesse de l'ARM : apprends à lire et ensuite viens me contredire.

[ArchieForEver]

Je cite Stapha92 :
-----------------
'

ArchieForEver a écrit:

Ah ah ah comme c'est drôle de lire de telles bêtises ! 'Un scrolling fluide est si compliquée sur Archimedes.' : t'as pas honte d'écrire de telles inepties ? Ou alors tu veux dire scroll hardware ? Re ah ah ah ! Excuse moi, je ne peux m'en empêcher : sur Archimedes, avec le MEMC, tu changes l'adresse où le VIDC va chercher les données à lire pour les afficher... dur dur, ça prend 20 instructions à tout casser, ça doit bien prendre 0,03% du nombre de cycles processeur disponible par VBL ! Il y a un registre qui détermine le déplacement de l'adresse de lecture, par 'paquets' de 32 bits, donc 4 pixels en mode 256 couleurs (1 octet=1 pixel). C'est cette adresse qu'on utilise pour les scrolls hard verticaux. Pour le déplacement horizontal, au pixel près, ça semble donc rapé, hein ?. Hé hé ! C'est sûr ce n'est pas marqué dans la doc de VLSI noir sur blanc, du coup beaucoup sont passés à côté, mais en fait il y a aussi un registre qui gère le décalage de 1 octet, donc 1 pixel en mode 256 couleurs. Ceux qui avaient raté ça changeaient le départ de la bordure gauche via le VIDC (avec lequel, en passant, on définit des modes overscan 'vrais', en moins de 100 instructions). Une fois de plus, parceque tu ne l'as pas vu, ou bien tu ne sais pas le faire, ou alors tu as cotoyé des types qui ont eu un Archie et ne savaient pas le faire, tu en conclues à tort que l'Archie ne savait pas le faire. Je t'invite à regarder ma démo où avec le code généré j'affiche à l'écran 3 sprites de 80x80, sur un scroll vertical, avec un soundtracker lisant un mod 4 voies, dans un mode graphique overscan 384*256, en 256 couleurs. Il n'y a même pas d'astuce sur le fait que le sprite sphère est affiché 2 fois. http://www.retrosoftware.co.uk/wiki/index.php/XTHOPAC_STUARC C'est en 50 images par seconde. Depuis je fais largement mieux. Et je ne suis pas un dieu de la programmation comme vous en avez eu sur l'Amiga. Si ces personnes s'étaient penchées un peu plus sur l'Archimedes, je pense que tu en aurais tout simplement avalé ton chapeau. Dès que l'Archimedes a commencé à être distribué en Allemagne, on a très bien vu ce que les demomakers qui s'amusaient avant sur ST et sur Amiga ont su en faire. (Dommage ce n'est pas sur Youtube, il n'y a que des vieilleries là).

Donc si
je résume, il existe des astuces non documentées et qui n'étaient pas
utilisées à l'époque pour faire un simple scroll horizontal ? Et ça
servait à quoi ? D'autant qu'en matière de scroll, on est loin du compte
même avec ces astuces par rapport à un Amiga. Normalement, pour faire
un jeu comme M. Nutz ou Brian the lion, l'affichage en chunky de
l'Archimedes est un avantage énorme pour appliquer les effets de zoom
et/ou de rotation qu'on trouve dans ces jeux. Et pourtant je n'ai rien
vu d'équivalent. Faut dire que pour reproduire tous les plans de scrolls
et de parrallaxe, tes 2 registres magiques ne servent plus à grand
chose, il faut réellement déplacer les données...
Donc AH AH AH :
désolé mais c'est moi qui ne peut m'en empecher. Il y a des dizaines de
jeux qui ne peuvent pas être reproduits sur ta machine qui valait une
fortune...
100 instructions pour faire du 'vrai' overscan ? Que veux
tu dire ? Un atari 800XL le fait avec 1 instruction. Un amiga avec 2 (un
move pour dire ou l'affichage commence et un pour dire ou il s'arrete).
Doubler
le sprite ? Génial ! Sur Amiga il était courant de les multiplexer
PLEINS de fois sur la MEME ligne, ça permettait de rajouter un layer
complet. et tu sais quoi ? tu pouvais aussi le faire avec un sprite en
16 couleurs (15+transparence). C'est pas du tout du même niveau et ce
n'était pas réservé aux démos : pleins de jeux ont utilisé ce système.
Le plus beau, c'est que ça n'utilise même pas le 68000 puisque le mig
dispose d'un VRAI copro qui va tout prendre en charge...
'
----------------

Ma réponse :
A quoi ça servait de ne pas documenter comment faire un simple scroll horizontal ?
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.

Faut que je te refasse un dessin à nouveau ?
Acorn ne visait pas le marché du jeu vidéo, mais sa chasse gardée constituée des collèges, lycées, universités, écoles d'ingénieurs du Royaume Uni.
Tu piges ou c'est vraiment trop compliqué à assimiler ?

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 sais ce que représentait le marché du jeu sur Archie ?
Un très bon titre se vendait entre 1500 et 3000 copies, sinon fallait pas espérer plus de 500 copies ...
Ceux qui avaient un archie se foutaient des jeux.
C'était essentiellement des programmeurs, des profs, des gens qui tenaient un journal, un fanzine, une publication d'association etc ....
Vous ne comprenez rien au monde de l'Archie, c'est absolument aberrant.

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.
Alors si tu veux définir un mode écran il te faut définir tous les paramètres qui définissent une résolution.
Je ne vois pas en quoi ce serait une tare : c'est juste la preuve que son chip graphique est extrêmement versatile et hautement programmable.
Il n'y a qu'un basher dans ton style pour ne pas le comprendre.

En redéfinition overscan par rapport à son mode de base, évidemment ça prend beaucoup moins : suffit d'étendre l'affichage en mettant l'info de bordure à zéro.

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.
C'est mieux que rien, personne ne s'en est servi jusqu'à présent, c'est moi qui leur ai fait découvrir ça sur les forums anglais.
Pour les autres affichages de sprites, j'ai mes routines et la puissance de l'ARM, et ça fonctionne donc très bien.
Ma preview de démo est loin de ce que je peux obtenir aujourd'hui.
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.

Je sais, c'est dur à avaler pour un Amigaïste mais c'est bien le cas.

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.

[ArchieForEver]

Je cite Stapha92 :
'Maintenant continuons sur tes explications : pour
faire un scroll horizontal, les éléments que tu as donné ne suffisent
pas. Il faut également une zone non affichées et pour ça, il faut créer
un décalage de l'adresse de l'écran entre chaque ligne (on appelle cela
le modulo). La zone mémoire non affichée sert alors à recevoir les
futurs élements. Ce décalage est-il automatique ou faut-il confier ça au
proc ? parce que si c'est le cas, c'est plus vraiment 0,03% du nombre
de cycles par vbl... Et comme il faut travailler à chaque ligne et qu'il
n'y a pas de syncho horizontal, ce n'est pas des plus pratiques...
Evidemment, pour un scroll vertical, le problème ne se pose pas. Bizarrement, c'est ce que tu as choisi de faire dans ta démo...
'
Stop !
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.
La méthode est différente, et tu verras ça dans une de mes prochaines publications.

'Bizarrement' j'ai choisi le scroll vertical dans ma démo, c'est ça que tu avances ?
Bah ouais : pour faire un shoot em up à scrolling vertical, ça semble logique, hein ? T'as pas lu le texte ou tu ne comprends pas ce que tu lis ?

[ArchieForEver]

Je cite 'Stapha92' :

-----------------------
'Je ne parle pas d'un scrolling parrallaxe ou
chaque ligne (ou groupe de lignes) défile à une vitesse différente : il
faut jouer avec une modification de l'adresse en cours (et pas l'adresse
de départ) de traitement du circuit graphique et sur l'offset de
décalage de pixels. Même si ça s'avère possible sur Archie (ce qui n'est
pas dit), ça s'avèrera encore une fois très gourmand...
Je ne parle
même pas des techniques de scrolling évoluées comme celles qui utilisent
le wrapping : utilisées tardivement sur le mig, elle permettent
d'utiliser beaucoup moins de mémoire écran et de blitter 2 fois moins de
tiles (et bon courage pour implémenter la même méthode sur
l'Archimedes...). L'amiga n'en a pas eu besoin pour faire des scrollings
en 50 i/s au pixel près. C'est dire la marge qu'il avait.
Idem pour
les écrans dont les lignes sont entrelacés en mémoire : très peu
utilisés dans les jeux alors que cela augmente l'autonomie du blitter
juste en fixant une certaine valeur de modulo... Encore une fois, cela
montre la marge que l'Amiga avait et qu'il n'était pas du tout exploité à
fond, contrairement à ce que tu dis.
Et pour la 3D, c'est pire : on a eu que des conversions ST alors que les optimisations possible en 3D sont multiples :
- Utilisation du blitter pour effacer l'écran.
-
Utilisation d'un modulo permettant d'espacer chaque ligne d'un nombre
octet qui soit une puissance de 2, afin d'utiliser des décalages en lieu
et place des multiplications lors des conversions
coordonnées->adresse
- Utilisation du blitter pour dessiner les lignes et/ou remplir les triangles
-
contruction de chaque triangle dans un buffer sur 1 plan puis copie de
celui dans les plans affichés (le blitter saura faire toutes les
opérations logiques nécessaires tout seul)
- Utilisation du mode HAM.
dans ce mode, on peut tracer une ligne en jouant uniquement sur les
points situés aux extrémités (le HAM a été inventé pour ça à la base)
Tout
ça n'a pas été utilisé dans les jeux. Pour une raison simple : les jeux
3D surfaces pleines n'avaient pas la cote. En gros ton Archie était
doué pour les types de jeux les moins recherchés... LOL !

'
------------------------
Bon le verbiage technique sur les prouesses supposées de l'Amiga, je m'en tamponne grave.

Je résume :
- 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.

- De mon côté je te dis que l'Archie n'a pas été exploité pour les jeux et les démos car ce n'était pas son credo, et là vous m'envoyez tous une volée de bois vert.

Conclusion évidente : vous me faites bien rire avec votre absence totale d'objectivité, pro Amiga et basher.

'Si ma tante en avait, on l'appellerait mon oncle' : c'est ce que je pense de tes élucubrations.

[Invité]

Débattons là dessus, je ne demande que ça de sortir des Toukonneries subies jusqu'à présent.
I mean it.

Tu as raison parles plutôt .bat, .exe, et de raccourcis clavier, parce que côté technique on sait maintenant que tu vaux rien .

le C n'a rien d'élitiste, c'est un langage proche du pascal, d'ailleurs c'est 2 langages date du début des années 70 .

conditionnelles, barrel shifter pour 0 cycle supplémentaire.

Non, sur l'arm tu ne peux pas toucher directement aux registres d'états .
effectivement quand tu fait une addition par exemple (adds) tu positionnes les retours d'eventuelles erreur (overflow,val neg etc..) dans un registre qui n'est pas celui d'état .

Effectivement tu peux lancer directement une routine conditionnée après, mais tu es loin d'un 2 cycles .
Et ca prend pas plus de cycle, ca m'étonnerai qu'une instruction du type adds prenne juste 2 cycles, c'est juste valable dans certains cas style un dépassement ou une val= ou <>0, pas si tu dois tester une valeur style 7fff par exemple, tu es obligé de passer par un CMP -> branchement .

[ArchieForEver]

Je cite Stapha92 :
_____________
'
Maintenant ta démo : ce que je vois c'est un
scrolling vertical sans application de tile. un simple changement de
l'adresse de l'écran et le tour est joué : rien d'extraordinaire. Si tu
faisais un scrolling horizontal avec tiles ? LOL !!! Les scrollings
horizontaux sont légions sur Amiga. Il y en a avec plusieurs plans, des
parallaxes, etc... Alors essaie d'en faire un avant d'affirmer que ta
démo explose le mig. Ensuite il y a des 2 sprites. Genial ! Mais tu
oublies de préciser que :
- tu utilises un code généré et couteux en
terme de place. Plusieurs Mo pour afficher 3 sprites sur un écran : ta
démo montre bien les limites de l'archimedes...
(en gros tu parles de précalc tout le temps mais, en l'occurrence, c'est ton code qui est précalculé dans ta démo)
-
il n'y a aucune gestion de masque : donc bonjour la détection de
collision et une bouding box avec une sphère, ça doit être génial pour
la jouabilité (les bounding box consistent à tester une collision en
vérifant si les rectangles qui contiennent 2 sprites se chevauchent : je
vous laisse tous imaginer ce que ça donne avec une sphère... lol !). On
ne peut même pas parler de sprites en fait...
- tu utilises le cas
qui t'arrange le plus : plus tes sprites seront gros et pleins et plus
tu auras un grand nombre d'accès en 32 bits. Avec des petits sprites, ça
sera bien moins bénéfique. Et avec des sprites non pleins aussi...
La seule chose qui mettrait en difficulté le mig, ce sont les 256 couleurs. Et encore, je vais revenir sur tes 256 couleurs...
'
_____________


Bon ça commence mal, déjà.
C'est une preview de démo.
Oui il y a bien des tiles... j'en ai défini juste quelques uns, pour le reste ça va lire dans la mémoire (mais toujours pour afficher un tile).
Tu ne les vois pas les chiffes inversés à l'écran, 12, 16, etc ...
Quelle mauvaise foi, une fois de plus.

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.

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.

Oui j'utilise ce qui m'arrange le plus, ça tombe bien c'est exactement comme ça que je vis au quotidien
C'est dingue mais mes routines sont en effet assez bien adaptés pour des gros sprites.
Trop fort : 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é !

[ArchieForEver]

Je cite Stapha92 :
'
________________________

ArchieForEver a écrit:

Faudrait que tu regardes les démos en 256 couleurs qui existent en googlant.co.uk (et y a pas que Youtube dans la vie)... Allez, quelques pistes chez Karl Morton, entre autres, un demo coder qui était auparavant sur ST. Si tu les veux je te les envoie, elles tournent sous Arculator. La 3D texturée... ben tiens regarde ça : http://squoquo.de/ releases 1998 et avant, il y en a. https://www.youtube.com/watch?v=p3REoZ41AhI Pas mal, et en jeu.

Euh je trouve que le jeu en 3D texturé rame beaucoup quand même. On
n'imagine pas avoir 4 mips et du chunky... Alors que dès que c'est de la
3D surface pleine sur Archimede, c'est toujours hyper fluide. Normal
que ça n'aille pas aussi vite mais là la différence est quand même
énorme (et il y a sur l'Archimede des tas de jeux en 3D surface pleine
qui sont hyper fluide alors qu'ils affichent bien plus de polygones que
l'exemple de jeu texturé que tu as posté). Tu es sur que la RAM ne
ralentit pas ? parce que dès qu'il y a une texture à appliquer, cela
oblige à lire des données octet par octet : ta méthode que tu penses
révolutionnaire ne marche plus... Prend un Amiga avec un 68030 : un jeu
texturé sera bien plus fluide que ton exemple et, pourtant, il y aura
beaucoup moins que 4 mips dispo une fois la conversion chunky ->
planar effectuée. Bizarre...
'
________________________

Tu trouves que ça rame car tu as des peux de saucisson dans l'oeil.
Ca se soigne, même quand on est Amigaïste.

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.
Réfléchis donc un peu : même toi tu devrais comprendre ton erreur.

Ah ah ah je me régale : continue d'écrire absolument n'importe quoi, ce débat me plait vraiment beaucoup.

[Invité]

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

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.

LOL n'importe quoi, sur archi peut être, reffléchi 2s (si c'est pas trop dur), comment tu ferrais pour faire des jeux sur 5 ou 6 écrans(voire plus) sur consoles, si ça prenait autant de place .
Tu crois quoi qu'elles ont 512 ko de vram ou de ram ??

Sur pce, un fond comme le tien ne me prend pas plus de 5 ko,et je suis très large là .

Comme d'hab, tu veux faire le malin, mais tu n'y connais rien ..

[ArchieForEver]

Je cite Stapha92 :
---------------------
'

ArchieForEver a écrit:

Totale ineptie : étudie l'architecture ARM et reviens discuter ensuite. Le PC, c'est à dire R15, contient et le Program Counter, et les status flags, c'est pour ça que l'adressage est limité à 2^26, ce qui à l'époque est totalement cohérent. Faudra que tu m'en montres des Amiga avec 2^32 bits de RAM (MDR). Pour la puissance on a eu aucun problème non plus : l'ARM3 à 33 Mhz était disponible à une fraction du prix de vos cartes 68030 ou 40...ce qui donnait 25 à 30 mips hé oui ! Chez nous on changeait une puce ARM pour une autre avec un quartz, chez vous on ajoutait presque une nouvelle carte mère, avec toute une circuiterie invraisemblable, tu parles d'une super trouvaille. C'est à partir du RISC PC et son Strong Arm que le PC (registre R15) est devenu totalement dédié à l'adressage 32 bits, et les status flags sont passés dans un registre spécifique (MSR) mais je ne me suis pas aventuré à programmer ça.

Tu
m'as mal compris : tu devrais relire au lieu de te moquer. Déjà tu
parles de 4 Go, mais pourquoi allez à l'extreme ? la limite d'un
adressage en 26 bits, c'est 64 Mo. Ensuite je pourrais parler de mémoire
virtuelle : là tu dépasse 64 Mo sans problème à l'aide d'un swapfile
et, ce dernier étant géré via la MMU, tout ça doit être vu comme un
espace unique par le proc.
Mais, et surtout, je ne parlais pas de
taille mémoire mais de compatibilité ! A partir du 68020, l'adressage
est en 32 bits. Pour autant, l'AmigaOS reste totalement compatible (ce
n'est pas le cas du TOS d'ailleurs...). N'y a-t-il pas un problème de
compatibilité pour faire tourner le noyau de RISC OS sur un Strong ARM
justement à cause de cet adressage ? N'y a-t-il pas une ré-écriture de
ce noyau qui a été initiée (et peut-être terminé à l'heure qu'il est.)
pour contourner ce problème ?
Mais je dois me tromper : il n'y a aucun problème dans ton RISC OS coopératif, puisqu'il est parfaitement écris...
Pour
le coup du changement de proc, là c'est clair que c'est un avantage. Tu
me permettras de le modérer un peu : quel interet de mettre un proc à
33 mhz avec une RAM qui a déjà du mal à suivre avec 8 Mhz ? Tu penses
vraiment atteindre 25/30 mips de cette façon ? Faut que tu refasses des
tests alors...
Tu es moqueur dans tes posts et tu prends les gens de
haut mais tu nous expliques en étant sur de toi qu'on peut faire 25/30
millions d'instructions par seconde avec une mémoire qui permet de n'en
lire que 8 millions par seconde. Et je dis lire, pas executer, car les
instructions ont souvent besoin de lire ou d'écrire dans la RAM (c'est
quand même le principe...) et "j'oublie" le fait que la RAM est utilisée
par d'autre circuits, comme le circuit graphique par exemple.
Pour te citer : 25/30 mips ? MDR !!!

'
---------------------

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 ?

La réécriture du noyau RISC OS pour fonctionner sur strong arm est juste finie depuis ... 1995... alors trouve encore autre chose.

Pour ton swap file ça va ça va c'est bien beau.
L'algorithmie pour gérer des gros fichiers ce n'est pas ça qui va étouffer l'Archie, là on est au niveau du bac à sable de l'informatique. Si t'as que ça comme argument pro Amiga, ça fait pitié.

J'ai bien corrigé sur le nombre de MIPS : c'est 12 à 15 pour l'ARM3 à 25 Mhz
Et oui, c'est vrai, on a bien toute cette puissance.
Même avec une RAM lente.
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.

[ArchieForEver]

Je cite Stapha92 :
-----------------
'Pour te citer : 25/30 mips ? MDR !!!
Nos
cartes accélératrice avait une "circuiterie invraisemblable" justement
parce qu'elle embarquaient de la RAM bien plus rapide que celle qu'il y
avait d'origine et qui, de part l'architecture du mig, n'était pas
ralentie par le chipset. Du coup les 80 mips d'un 68060 étaient
parfaitement exploitables...
Et ne confond pas les mips d'un proc
RISC et ceux d'un CISC. Il est communément admis qu'un Arm à 8 Mhz est 2
fois plus rapide qu'un 68000 à la même vitesse alors qu'il est annoncé
pour 4 fois plus de mips. C'est normal car le 68000 génère un code plus
concis (l'avantage de disposer de beaucoup d'instructions : on décompose
moins). Et n'oublie pas que le calcul des mips sur un processeur tient
compte des intructions disponible : sur l'ARM, il n'y a que des
instructions simples, donc il sera avantagé (il n'y a pas de division
sur l'ARM par exemple). En fait, aujourd'hui, plus personne ne compare
la puissance d'un processeur RISC et d'un CISC via les mips... sauf toi !
Mais
tu devrais étudier un peu le 680xx, : les instructions prennent moins
de place. La plupart prenant 16 bits (en fait toutes celles qui n'ont
pas d'opérandes direct. Et plus encore...) les 68020 et suivants en
chargent 2 en un accès mémoire et utilisent l'overlaping pendant leur
execution (pour peu que l'on sache vraiment coder en assembleur ou que
l'on utilise un bon compilo), ce qui permet d'obtenir des durées
d'executions réelles plus petites que les théoriques. A l'extreme, un
68040/60, exécute 2 instructions en même temps pour la plupart en un
seul cycle. Et là, au niveau puissance, je t'assure que l'ARM ne suis
pas. Rien que le fait que ses instructions prennent toujours 32 bits
(même un simple ldr...) le pénalise fortement, sans même parler du fait
qu'il en faudra en général plus pour faire la même chose ou des
limitations lorsqu'on veut travailler sur la mémoire et non sur des
registres.
'
------------------

Ma réponse.

Bon, ça part dans tous les sens, mais ça reste n'importe quoi, comme pour le reste.
C'est clair les cartes 68060 ça courrait les rues, c'était super exploitables, ça valait juste un bras, une jambe, et les balloches.
Non mais c'est ça ton argument ? Il est où l'Amiga là-dedans, tellement ce n'est plus la même machine.
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).


Tes arguments sur le CISC face au RISC sont tous discutables car l'ARM n'est pas un exemple de RISC fort, et c'est bien là encore une de ses forces.(inspiration du 6502, qu'aimait beaucoup Roger/Sophie Wilson)

L'overlapping que tu cites sur le 68020 me laisse froid, puisque l'ARM fonctionne lui sur 3 instructions en 'pipelining'.
La taille des instructions est toujours à 32 bits sur ARM, et donc ?
Regarde les tailles que tu as sur ton CISC.
Pourquoi tu me parles du 68020 ou 68040 ?
Ca n'existe pas dans un Amiga pre AGA que je sache, non ?
Alors qu'est-ce que ça vient faire ici ?

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.

Mais oui mais oui ton 68040 ou 60 qui ne dépasse pas les 80 Mhz il est meilleur que mon Strong Arm à 266 Mhz, 283 Mhz, overclockable à 350 Mhz par rajout d'un ventilo.
Y a pas à dire, t'es super convaincant.

[ArchieForEver]

Je cite Stapha92 :
-----------
'

ArchieForEver a écrit:

Ne vous fiez pas à ce que vous voyez sur Youtube, qui doit être la démo tournant sous l'émulateur disponible sur PC, ça rame à mort, car plus le code d'origine se sert du hard de la machine, plus l'émulateur peine à le convertir. (D'ailleurs ma démo 'technique' ne passe tout simplement pas sous émulateur, c'est dire !). Cette démo du jeu est bien en 50 images par seconde sur un vrai Archimedes, et oui il y a du son : explosions et tirs, du plus bel effet. Vous pouvez la récupérer ici : http://acorn.revivalteam.de/?site=Downloads (Scorpius , section Gamedemos) C'est une démo jouable. Dommage le jeu complet n'est jamais paru, car l'éditeur a fait faillite entre temps. Alors, pas mal pour une machine soit disant super nulle pour la 2D, non ? Et ça date de 1992.

Ok,
alors analysons un peu ce que l'on voit : tu parles de 50 i/s. On voit
tout de suite que c'est faux : les objets bougent bien plus souvent que
le décor de fond. Donc les 50 i/s, ce n'est pas pour tout ce qui est
affiché...
ça nous fait donc un plan du fond en 4 couleurs (trop fort
! alors que tu parles des 256 couleurs toutes les 3 phrases dans tes
posts...) qui n'est qu'un motif répété 16 fois sur chaque ligne. Sur
l'Archie, ça permet de limiter les accès mémoires (1 lecture pour 16
ecritures dans la RAM. Bizarre... Pourquoi limiter les accès mémoires
s'ils ne sont pas pénalisant ?).
Sur Amiga, tu peux reproduire le
scrolling du fond avec 1 seul sprite et en ajoutant un parrallaxe pour
améliorer l'effet de profondeur. Et tu peux le faire sans utiliser le
cpu : 16 petites copperlists a préparer au début du jeu et après le
copper gèrera ça tout seul. Et encore, les jeux qui utilisent ce système
le font en regroupant 2 sprites qu'il répètent sur la même ligne : là
ça fait 16 couleurs pour le plan du fond...
Une question : pourquoi
un fond en 4 couleurs ? Tu sais pourquoi ? Tu passes ton temps à
insulter les gens ici en disant qu'ils ne savent pas coder. Et bien moi
j'ai une hypothèse pour la méthode utilisée pour afficher le fond alors
que j'ai jamais codé sur Archimedes. Et toi en as-tu une ? Je parle
d'une méthode qui permettrait de gagner du temps dans l'affichage du
décor de fond et qui expliquerait pourquoi seuls 4 couleurs sont
utilisées. Evidemment mon hypothèse répond à ces 2 conditions et je n'ai
eu besoin pour la formuler que de regarder la vidéo et lire ce que tu
as expliqué sur l'assembleur ARM. Je peux la poster si tu veux : ça
t'interdira de dire que je ne sais pas de quoi je parle.
'
-----------------------

Ma réponse :

Ah alors là on touche au sublime de la bêtise amigaïste.

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.
Fais une association des bras cassés avec Toukon et le p'tit Mickey, ça vaudra mieux.

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

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.

LOL n'importe quoi, sur archi peut être, reffléchi 2s (si c'est pas trop dur), comment tu ferrais pour faire des jeux sur 5 ou 6 écrans(voire plus) sur consoles, si ça prenait autant de place .
Tu crois quoi qu'elles ont 512 ko de vram ou de ram ??

Sur pce, un fond comme le tien ne me prend pas plus de 5 ko,et je suis très large là .

Comme d'hab, tu veux faire le malin, mais tu n'y connais rien ..

Sur Archie en mode chunky 256 couleurs c'est ainsi.
Comme sur un PC.

Dis tu devais pas te casser toi ?

T'en es où de la démo que tu dois me montrer ?

Ne prend pas l'exemple de ta PCE qui comme la SNES gère en hard le tile : l'AMiga ne gère pas le tile en hard, non ?
Ici on parle de l'Archimedes, du ST et de l'Amiga, t'es au courant ?

[65c02]

:p

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