Re: Amiga/st vs Archimede

[ArchieForEver]

Salut.

Dire que l'Archimedes n'avait pas de puces graphiques customs, ça me fait doucement rigoler.
D'une manière générale tout est custom dans l'Archimedes, (sauf le controleur disk, de la famille 1772) et c'est la conjonction d'usage de certaines capacités du MEMC, du VIDC et de l'IOC qui permet soit de faire, soit de s'approcher de ce que les puces customs de l'Amiga offraient.

Acorn a tout conçu dans l'Archimedes :
- l'ARM, le processeur, et d'une.
- le MEMC (MEMory Controler) qui permet le scroll hard vertical, et horizontal, au pixel près en modes 8 bit par pixel (256 couleurs).
- le seul sprite hard du VIDC permet de positionner n'importe où à l'écran n'importe quelle forme jusqu'à 32 pixels de large x pleine hauteur d'affichage, en 3 couleurs parmi 4096, la 4è couleur, valeur logique 0 étant la transparence.
Tout ça sous DMA, avec à chaque fois chargement d'une FIFO de 8 mots de 4 octets.
Le VIDC en lui-même est une puce hautement programmable, permettant toutes sortes d'affichage, du mode monochrome au mode 256 couleurs, avec si on veut de l'interlace.
L'overscan est faisable sans trick, faut juste le demander.
Le VIDC gère aussi le son, sous DMA, jusqu'à 8 voies, et nous on a 7 positions stéréo, pas 3 comme l'Amiga.
- l'IOC c'est le chip qui gère les interruptions, et entrées/sorties (Input Output Controler).
Il propose au programmeur 2 timers programmables à 2 Mhz.
En général on ne touche pas au timer0 car il s'occupe de l'horloge pour le RISC OS, on touche au Timer1 (voir le wiki angalis sur l'Archimedes, je l'ai amendé pour diriger vers le source. Ce source très longtemps caché par Acorn, qui ne voulait pas de programmation bas niveau dans les softs, et oui).

Vous pouvez sortir la calculette : avec 1 voire 2 timers à 2 Mhz, on peut mettre au cul des routines qui s'exécutent avec une granularité même supérieure à celle d'une H-Sync (non disponible pour le programmeur), et c'est pour ça qu'on peut faire ce genre de trucs que je vous poste après, contrairement à ce qu'affirmaient les Amigaïstes ('impossible de faire des raster bars sur Archimedes').
Bande de pauvres c.... Sans doute les mêmes qui pensent que le blitter tourne à 77 Mhz.







Bien sûr les fainénants ou autres nuls qui représentaient les 3/4 des programmeurs de jeux en ont rarement profité.

Il y a un patch pour Zool pour avoir le dégradé multicouleur, et une version de robocod qui est aussi belle que sur l'Amiga.

Sur Youtube, voir 'James Pond 2: Robocod [Acorn Archimedes A3010] gameplay'


Pour revenir au hard de l'Archie, il faut bien avouer que pas grand'chose de tout ça n'est documenté dans le PRM (Programmer's Reference Manual), 4 tomes sur le RISC OS, pour environ 3000 pages d'infos, tout simplement car Acorn voulait une programmation 'propre' pour assurer la compatibilité avec les machines à venir.
Et puis Acorn n'en a jamais rien eu à battre des jeux (seul le A3010 dispose de 2 ports joystick type Atari, c'es tout dire!).
Les appels système (SWI) mis à disposition du programmeur ne couvrent pas suffisamment le bas niveau pour aller taper dans le hardware.
Il faut donc travailler avec la doc de VLSI (le fondeur des puces Acorn) VL86C010 32-BIT RISC MPU AND PERIPHERALS USERS MANUAL pour aller au fonds des entrailles de la machine, et là, on commence un peu plus à rigoler.

Concernant la définition des couleurs, c'est trivial en 2, 4 ou 16 couleurs, mais c'est très franchement complexe à comprendre comment on les redéfinit pour avoir ce qu'on veut en 256 couleurs (on ne peut pas, on peut juste s'approcher).
Voici ce que dit la doc page 4-7 :
'Video Palette Logical Colors 0-FH: Adresses 00-3CH
In 1, 2, and 4 bits per pixel mode, data bits D12-D0 define the physical color corresponding to that logical color.
The data bus encoding is shown in Figure3.
Figure 3. Video palette logical color format
Bits 24, 25 , 30 et 31 : 0
Bits 29 à 26 : couleur logique
Bits 13 à 23 : ne pas modifier
Bits 0 à 12 : couleur physique

Figure 4 shows the physical color field specification.
Figure 4.
Renomons les bits 0 à 12 D0 à D12 ça donne :
D3-D0 define the red amplitude
D7-D4 define the green amplitude
D11-D8 define the blue amplitude
D12 defines the supremacy bit for that color

In 8 bits per pixel mode, only 9 bits are defined as shown in figure 5.
Figure 5. Video palette data encoding for 8 bits per pixel mode.
Dur à copier alors voilà en termes de bit :
Fixés à 0 : bits 31, 30, 25 et 24
Bits 26 à 29 : couleur logique
Ne pas programmer : bits 13 à 23, 11, 7, 6 et 3
Bits 12, 10, 9, 8, 5, 4, 2, 1, 0 : donnée pour la couleur physique


The palette outputs define the least significant bits of each color.
The most signifcant bits for each color now come directly from the upper 4 bits of the logical color field, giving the physical data field as shown in Figure 6.
Figure 6. Video palette definition for 8 bits per pixel mode.
Là attention ça décoiffe :

12___|11____10___9___8|___7____6___5___4___|___3___2___1___0
SUP__|______BLUE______|______GREEN_________|____RED
D12*_|L7**_D10*_D9*_D8*|L6**_L5**_D5*_D4*_|L4**_D2*_D1*_D0*

*Dn : these bits are from the palete field
**Ln : these bits are from the logical field.

Voilà, ça a surement un sens pour les spécialistes de la formation des couleurs, mais pour moi c'est du charabia.
A noter que de nombreux softs sur Archie (dont les excellents !Translator et !Creator de John Kortink) savent recréer les meilleures palettes pour une image à afficher.
http://web.inter.nl.net/users/J.Kortink/home/software/index.htm

En général la palette proposée au démarrage par le RISC OS pour les modes 256 couleurs était conservée, car assez bien équilibrée.

Et puis comme déjà dit, les programmeurs sur cette machine étaient des fainéants.
Même Zarch (Virus chez vous), n'est qu'une sombre m... car Braben n'a pas du tout optimisé ses routines d'affichage.

Il n'y a que StarFighter3000 et Scorpius qui soient à la hauteur des capacités de l'Archimedes (et mon futur shoot em up vertical, évidemment).
Je vous laisse baver devant en allant voir ça sur Youtube par vous-même.

Pour voir la palette, ordonnée ou non ordonnée par gradients, tu peux aller ici :
http://starfighter.acornarcade.com/mysite/index.htm
A gauche tu cliques sur 'Documents', puis tu choisis : 'Gradients in the RISC OS 8-bit palette'
Voilà un aperçu :
http://starfighter.acornarcade.com/mysite/articles/Images/gradr/Pic19.gif

En gérant bien les couleurs en mode 256 couleurs on pourrait presque croire que l'Archie a un copper :





Bye.
PS : Tu comprendras que ce que tu dis est faux : il n'y a pas 240 couleurs fixées, et 16 choisies librement, en mode 256 couleurs.
On est dans 'autre chose', beaucoup plus zarbie.

[Invité]

En attendant rien d impressionnant dans les démos que tu montre .

On fait bien mieux sur amiga et même sur st .
Comparer le dma de l archi avec les 25 canaux de l amiga lol quoi .

Et quand je parle de custom ce sont des puces style blitter que n à pas l archi .
Certe il a aussi des atouts, mais bon .
Le son est bon, mais pas aussi clair que sur amiga .

[ArchieForEver]

En attendant rien d impressionnant dans les démos que tu montre .

On fait bien mieux sur amiga et même sur st .
Comparer le dam de l archi avec les 25 canaux de l amiga lol quoi .

Et quand je parle de custom ce sont des puces style blitter que n à pas l archi .
Certe il a aussi des atouts, mais bon .
Le son est bon, mais pas aussi clair que sur amiga .

Certainement.
Heureusement qu'avec 1 ratio de machines vendues de 1 pour 1000, les meilleurs programmeurs étaient sur ST et Amiga, et pas sur la bécane d'Acorn.
Ceci dit, je ne suis pas dupe : les belles démos sur Amiga c'est le plus souvent grâce à de très beaux graphismes et de belles musiques. Ca valorise les hommes, pas la machine.
J'ai posté les démos à titre technique, pour montrer que l'Archimedes en avait aussi sous le capot en 2D, techniquement, alors qu'on lit n'importe quoi sur ses capacités quand les amigaïstes s'expriment à son sujet.

Après il y a la 3D, là je ne reprendrai même pas le débat passé : un Archie de base enfonce un Amiga de base, et en 256 couleurs qui plus est.
Les 'belles' démos 3D Amiga qui ne sont que de la poudre aux yeux, avec jolie image de fond et 3 pauvres objet 3D avec un minimum de faces, le tout avec une tonne de précalculs, je les laisse à ceux qui se laissent bluffés.
J'admire les programmeurs qui ont été ingénieux, les graphistes et les musiciens, mais pas la machine.

En temps réel, là on arrête les pitreries astucieuses : j'attends toujours de voir un équivalent du jeu Starfighter3000 sur Amiga ...
J'attendrai longtemps, puisque déjà c'est en 256 couleurs sur l'Archie (Au fait : 320x256 soit 80 ko la bank écran, étonnant pour une bécane 'qui a un bus lent', non ? Ben oui, faut penser à privilégier LDMIA / STMIA plutôt que LDRB / STRB. LDRB/STRB ça donne Zarch, LDMI / STMIA ça donne Starfighter. Tout simplement 4 fois plus rapide.).



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.
L'usage du sprite hard aussi est à creuser .... Qui s'en est déjà soucié sur Archie ?
Personne ...

Pour le son il y a 2 points à prendre un compte :
- filtres : sur Amiga il est switchable on/off par soft, sur Archimedes il est physiquement on, et il coupe trop de hautes fréquences.
On peut le shunter si on souhaite. Pas bien compliqué car des connecteurs sont disponibles avant le filtrage de sortie, mais j'avoue c'est bien dommage.
En shuntant off le filtre, il faut que les samples soient vraiment de qualité car on a tout le son, ou bien passer par le filtrage d'un ampli, ce qui en soit est logique quand on a un équipement audio vidéo.

- logiciel : longtemps le player le plus employé a été un player buggé, qui ne restituait pas tous les effets, et en plus je crois qu'entre l'Archimedes et l'Amiga, l'un lit les samples en log, et l'autre en linéaire, et la conversion avant lecture n'était pas réalisée sur l'Archie, d'où un pitch inadéquat lors de la lecture du format Amiga.

Pour ce qui est des fameux DMA sur l'Amiga, un jour j'aimerais bien qu'on me donne plus de détails, notamment au niveau du bus, des temps de latence que ça implique sur le 68000, etc ... etc ...

[Invité]

Voilà un des points que tu ne met pas assez en avant, et qui fait la force de l archi, outre son cpu, ce sont ses capacités 3D .
Pour le son oui tu peux faire des filtres sons sur archi, tout comme l amiga peut faire des musiques sur 7 voix en soft, et bien d autre choses .

Le copper et le blitter permette des choses à un amiga qui sont simplement impossible sur l archi, même si le contraire est aussi vrai dans certains cas .
La force de l'archi est dans la 3D et non la 2D .
Ensuite pour le talent des profs, pas besoin d'en avoir des million si l archi était si puissant ,on aurai déjà vu des effets impossible à faire pour les autres 16bit.

Pour les rasters bar tu as raison, même un thomson y arrive, par contre vas faire du plasma en full screen sur archi .
L'amiga te fait ça avec quasi 0% de CPU,tout comme tout les effet de changement de palettes à la ligne, ou en milieu de ligne .
Pour tes 2 timers, le ST les à aussi, et alors, il casse quand même pas des briques .
Et faut pas oublier non plus que l'archi est sorti 3 ans après l'amiga.

Moi ce qui me choque, c'est cette façon de critiquer l'amiga, alors que tout les demos maker veulent faire de l'amiga dans leur demos, rien que les reprises de mod amiga me fait rire .

L'amiga n'est pas une machine parfaite, ça c'est clair, mais en 2D que ce soit par rapport au st ou à l'archi, il est intouchable .

[MacDeath]

PS : Tu comprendras que ce que tu dis est faux : il n'y a pas 240 couleurs fixées, et 16 choisies librement, en mode 256 couleurs.
On est dans 'autre chose', beaucoup plus zarbie.

ah oui en effet, merci pour toutes ces infos...

je vais éplucher tout ça pour ma culture perso.


Après je suis bien d'accord que les machines n'ayant pas eut un gros succés populaiure sont biaisé dans les productions car il n'y a pas eut assez de monde pour explorer le potentiel...

Les Amstrad PLUS et AtariSTE sont largement dans ce cas aussi d'ailleurs, bien que bénéficiant des explorations de la gamme d'avant, ça n'est pas pareil quand même.
que l'Archimede, y'a même pas l'avantage d'être une évolution d'un machine existante et ayant vendu des millions d'unités.

[ArchieForEver]

Voilà un des points que tu ne met pas assez en avant, et qui fait la force de l archi, outre son cpu, ce sont ses capacités 3D .
Pour le sort oui tu peu faire des filtres sont sur archi, tout comme l amiga peut faire des musiques sur 7 voix en soft, et bien d autre choses .

Le copper et le blitter permette des choses à un amiga qui sont simplement impossible sur l archi, même si le contraire est aussi vrai dans certains cas .
La force de l'archi est dans la 3D et non la 2D .
Ensuite pour le talent des profs, pas besoin d'en avoir des million si l archi était si puissant ,on aurai déjà vu des effets impossible à faire pour les autres 16bit.

Tu me parles de la qualité du son, je te réponds sur la qualité du son.
Pour le nombre de voies (ce que tu évoques) l'Archie monte à 16 voies (voir player DigitalSymphony).

Avec si peu de programmeurs je ne pense pas comme toi : à mon avis justement on n'a pas tout vu sur cette machine.
La preuve par l'exemple : il n'y a qu'un jeu comme StarFighter3000.
Si son programmeur ne l'avait pas fait, je lirais ici que la 3D sur Archie ça s'arrête à Zarch (Virus) ...
Pour la 3D temps réel, je n'ai même pas envie d'en parler : l'Archimedes gagne haut la main.

Ce qui m'intéresse c'est de démontrer qu'en 2D, justement là où il est perçu comme faiblard, il en a en fait beaucoup sous le capot, car bien peu de 'bidouilles hard' ont été tentées.
Et même en soft, il y a encore bcp d'optimisations à réaliser (code généré, code auto modifiable, précalculs, disposition mémoire différente des datas sources pour gains de traitement).
J'ai des sources ARM pour des effets brouillards, déformations, zooms et rotations qui tournent très bien en 50 images par seconde, et il n'y a aucune de ces optimisations dedans, c'est du délire.
Comme la machine était suffisamment puissante, personne n'a décidé de suer un peu : c'est tout le contraire du programmeur ST ou Amiga qui a intérêt à être vraiment feinteux pour extraire du jus de sa petite machine limitée.

[Invité]

Il n'est pas faiblard en 2D, mais tu ne peux pas faire la même chose qu'un machine développé spécialement pour elle comme l'amiga ou les consoles .
Sur amiga outres ses copros, tout est DMA, c'est ce qui fait sa force, si en plus de la chip, tu utilise de la fast, ses perfs sont boostées .

Le jour ou on verra un shadow of the beast sur archi .
Dans les demos amiga tu as tout un tas d'effet impossible (en théorie) à faire sur un amiga, et pourtant c'est un temps réel .



Ok c'est de l'AGA, mais quand même, c'est autre chose.

[MacDeath]

Ensuite pour le talent des profs, pas besoin d'en avoir des million si l archi était si puissant ,on aurai déjà vu des effets impossible à faire pour les autres 16bit.

Pas aussi simple...
une machine puissante n'en est pas pour autant facile a programmer ou maitriser.

La Jaguar, et certaines playstations non ? (je sais plus)...

Les programmeurs de l'époque étaient limités par leur connaissances qu'ils avaient aquis sur les autres machines qui laisse souvent de mauvaises habitudes, mais aussi le fait qu'un machine n'était pas très bien documenté bien souvent (undocumented features, lol), que les accés aux info techniques n'étaient pas aisées non plus.
voire étaient simplement dépassé par l'évolution technique des machines lol... les années 90 ont prouvé que le passage systématique à la 3D était bien souvent hyper foireuse.

on ne pouvait pas simplement télécharger des pdf à l'époque. Et les codeurs gardaient jalousement leurs secrets techniques aussi.

Enfin explorer une machine soi-même ça prend du temps, temps que les ados boutonneux vraiment passionné avaient parfois, mais qu'un programmeur professionnel n'avait pas (plus).

Et puis plus une machine avait de bits, plus elle était longue a "explorer".

Quand on sait que les 8bit comme le CPC ou les Atari8bit (par exemple) ont bien mis 20ans pour être plus ou moins maitrisés... et que ça c'est surtout fait après la vie de ces machines grâce aux échanges d'info permis par internet... et fut permis aussi parceque ces machines ont réussit à vendre quelques millions d'exemplaires aussi.


Si l'Archimedes avait vendu euh... ils s'en est vendu combien d'ailleurs ?

Mais si ils en avaient vendu autant que des CPC (genre 2-3 millions) ça aurait sans doute bien changé la donne...

Ah, il y a aussi le publique visé.

les Amiga, ST et CPC ont très souvent finis entre les mains d'ados boutonneux, qui donc avaient le temps et la patience de les explorer parfois.

Les Archimedes, peu ont du vraiment finir comme "jouets"..


Et puis le problème de l'archi c'est qu'il est tellement rare qu'il a peu de chance de finir entr les mains d'un passionné lambda comme pourrait le faire un ST ou autre que l'on toruve aisément a un vide grenier.

L'amiga n'est pas une machine parfaite, ça c'est clair, mais en 2D que ce soit par rapport au st ou à l'archi, il est intouchable .

Bof, si la Megadrive avait un clavier, un lecteur de D7 et 512K (ou 1024K) de RAM... seule la palette 512 (au lieux de 4096) serait un poil faiblarde et encore...

[Invité]

Pas aussi simple...
une machine puissante n'en est pas pour autant facile a programmer ou maitriser.

Ca c'est le dogme des faignants, car machines simples, ne veut pas dire que t'en chie pas pour faire des effets quand rien ne t'aide dans le hard ..
C'est ce qui s'est passé avec la snes, les progs trop feignants (et manquant de temps aussi) pour utiliser correctement la machine perstaient sur son CPU à 3 mhz .
Quand on voit ce que donne le 6502 @ 0.967 mhz du C64, ca fait rigoler .

De toutes façons, l'amiga n'est pas réputée pour être un machine difficile à programmer, certe surement plus que le ST vu que seul le CPU est programmable, mais va dire à un prog ST de faire un scrolling fluide sur ST, il va en chier de la vaisselle cassée .

Toutes machines recelles des possibilités même les plus simples, mais celles avec des customs, en ont bien plus, car tu peux bcp plus jouer avec le hard, et surtout, garder du CPU pour avoir de meilleurs effets .Je sais que dans des jeux comme alien breed sur amiga, qui pourtant en jette, le 68000 est programmé avec les pied .

Sinon je programme sur le CPU de la nec qui est un peu l'ancêtre de l'arm, et franchement ces CPU sont géniaux à programmer, mais ne plaisent pas aux fans des Z80 et autres 68000, qui ne savent rien faire sans 60.000 registres .

[ArchieForEver]

En attendant rien d impressionnant dans les démos que tu montre .

On fait bien mieux sur amiga et même sur st .
Comparer le dma de l archi avec les 25 canaux de l amiga lol quoi .

Et quand je parle de custom ce sont des puces style blitter que n à pas l archi .
Certe il a aussi des atouts, mais bon .
Le son est bon, mais pas aussi clair que sur amiga .

Stp donne moi plus d'info sur tes 25 canaux... quant aux DMA sur Archie, ils sont bien évidemment plusieurs : pour la mémoire vidéo, pour la mémoire du sprite hard, pour la mémoire son.
Pour le son, si quelqu'un peut comparer avec l'Amiga, voilà son codage sur Archimedes :
Sound data field format :
sur 8 bits nommés D0 à D7 :
D0 : signe
D1-D4 : point sur la corde
D5-D7 : sélection de la corde

Caractéristiques de la lecture par le DAC : 8 segments linéaires sont lus (cordes).
Chaque corde est constituée de 16 parties, et chaque partie dans une corde dure 2 fois la durée de la corde précédente.
Cela donne une approximation de la 'loi mu255".
http://en.wikipedia.org/wiki/%CE%9C-law_algorithm

C'est comment sur Amiga ou St ?

[ArchieForEver]

Le jour ou on verra un shadow of the beast sur archi .
.

Ce jour n'est peut-être pas si loin que tu ne le penses.

[Invité]

Stp donne moi plus d'info sur tes 25 canaux... quant aux DMA sur Archie, ils sont bien évidemment plusieurs : pour la mémoire vidéo, pour la mémoire du sprite hard, pour la mémoire son.
Pour le son, si quelqu'un peut comparer avec l'Amiga, voilà son codage sur Archimedes :
Sound data field format :
sur 8 bits nommés D0 à D7 :
D0 : signe
D1-D4 : point sur la corde
D5-D7 : sélection de la corde

Caractéristiques de la lecture par le DAC : 8 segments linéaires sont lus (cordes).
Chaque corde est constituée de 16 parties, et chaque partie dans une corde dure 2 fois la durée de la corde précédente.
Cela donne une approximation de la 'loi mu255".
http://en.wikipedia.org/wiki/%CE%9C-law_algorithm

C'est comment sur Amiga ou St ?

pour le DMA sur amiga là par exemple : http://membres.multimania.fr/synapse/fonction/dma.html

Pour le DMA sprite de l'archi rassures moi, c'est pas un seul est unique sprite
Pour le son ça correspond à rien ..

Sur amiga c'est 4 canaux DMA, en 8 bit mais pouvant aller jusqu'a 14 bits (en combinant 2 voix) ,fréquence d'échantillonnage 28 khz (plus pour les AGA), et un rapport signal bruit de 70 db.

[ArchieForEver]

Il n'est pas faiblard en 2D, mais tu ne peux pas faire la même chose qu'un machine développé spécialement pour elle comme l'amiga ou les consoles .
Sur amiga outres ses copros, tout est DMA, c'est ce qui fait sa force, si en plus de la chip, tu utilise de la fast, ses perfs sont boostées .

Le jour ou on verra un shadow of the beast sur archi .
Dans les demos amiga tu as tout un tas d'effet impossible (en théorie) à faire sur un amiga, et pourtant c'est un temps réel .



Ok c'est de l'AGA, mais quand même, c'est autre chose.

Ma preview de démo avec les 3 gros sprites, c'est aussi en théorie impossible sur Archimedes... tu sais, cette machine avec 'un bus lent' et pourtant voilà, dès 92 ça existait.

Maintenant si tu me parles d'AGA je te mets en face le RISC PC sorti un an après, ou bien la version cut-down (A7000) et Acorn gagne haut la main ( en 3D et 2D ).
Faut comparer ce qui est comparable, sinon on ne va plus s'en sortir.

[Invité]

Attention, ne te méprend pas, l'archi est pour moi une super machine, mais je reste convaincu que la 2D n'est pas son point fort du tout .
Et mes critiques n'était pas pour ta demo qui est pas du tout finie, mais les précédentes postées .

C'est une machines comme toutes les autres qui à certe des qualités mais aussi des faiblesses, manque de pot elle est sortie au moment ou la 2D dominait .

[ArchieForEver]

Stp donne moi plus d'info sur tes 25 canaux... quant aux DMA sur Archie, ils sont bien évidemment plusieurs : pour la mémoire vidéo, pour la mémoire du sprite hard, pour la mémoire son.
Pour le son, si quelqu'un peut comparer avec l'Amiga, voilà son codage sur Archimedes :
Sound data field format :
sur 8 bits nommés D0 à D7 :
D0 : signe
D1-D4 : point sur la corde
D5-D7 : sélection de la corde

Caractéristiques de la lecture par le DAC : 8 segments linéaires sont lus (cordes).
Chaque corde est constituée de 16 parties, et chaque partie dans une corde dure 2 fois la durée de la corde précédente.
Cela donne une approximation de la 'loi mu255".
http://en.wikipedia.org/wiki/%CE%9C-law_algorithm

C'est comment sur Amiga ou St ?

pour le DMA sur amiga là par exemple : http://membres.multimania.fr/synapse/fonction/dma.html

Pour le DMA sprite de l'archi rassures moi, c'est pas un seul est unique sprite
Pour le son ça correspond à rien ..

Sur amiga c'est 4 canaux DMA, en 8 bit ,frequ d'echantillaunage 8 bit, mais pouvant aller jusqu'a 14 bits, en 28 khz (plus pour les AGA) et un rapport signal bruit de 70 db.

Intéressant. En ce sens aussi l'Archimedes a plus de DMA (sur ses ports d'extension) mais un seul vers la video car il ne fonctionne pas en bitplans mais en 'chunky' donc un seul DMA pour lire la mémoire vidéo.
Combien de sprites hard gère l'Amiga et quelles sont les vraies caractéristiques (y compris les contraintes, parceque les descriptions élogieuses qui oublient toujours les contraintes, comme pour le C64, ça me fatigue).

[ArchieForEver]

Attention, ne te méprend pas, l'archi est pour moi une super machine, mais je reste convaincu que la 2D n'est pas son point fort du tout .
Et mes critiques n'était pas pour ta demo qui est pas du tout finie, mais les précédentes postées .

C'est une machines comme toutes les autres qui à certe des qualités mais aussi des faiblesses, manque de pot elle est sortie au moment ou la 2D dominait .

Ok ok.
J'essaie juste de comprendre cette espèce d'intime conviction qui à mon sens ne repose sur rien de concret : juste la vision du travail d'excellents programmeurs (sur ST et Amiga) face à des fainéants (sur Archimedes).
C'est anormal par exemple qu'un type comme moi ait fait à mon coup d'essai un truc qui explose la concurrence alors que je débutais en assembleur.
Ca me fait vraiment penser que pour ce qui est jeu et démo l'Archie n'a pas eu les programmeurs qu'il méritait.

[Invité]

Oui la scene archi est petite comme celle du CPC, donc forcement la demo sur cette machine ne peut que faire évoluer lentement les connaissances .

Un question sur les demos rasters que tu as posté, tu est sur que ce sont de vrais rasters ??
On dirai juste un swap de palette pour donner l'effet de rasters !! .

[Invité]

Intéressant. En ce sens aussi l'Archimedes a plus de DMA (sur ses ports d'extension) mais un seul vers la video car il ne fonctionne pas en bitplans mais en 'chunky' donc un seul DMA pour lire la mémoire vidéo.
Combien de sprites hard gère l'Amiga et quelles sont les vraies caractéristiques (y compris les contraintes, parceque les descriptions élogieuses qui oublient toujours les contraintes, comme pour le C64, ça me fatigue).

Normal ,qu'un seul DMA, ca n'a rien à voir avec le chunky ou le BP, mais sur le fait que sur AMIGA, outre le CPU, Tout les custom y ont accès aussi .
car la mémoire de base de l'amiga la chip ram, est une mémoire unifiée .

Pour les sprites l'amiga en gere 8 hard, mais via le blitter et même le copper tu peux en gérer bcp plus .
Les contrainte sont la taille, je sais plus qu'elle taille il peut gerer, mais ca s'efface grâce au blitter .
L'amiga à 2 plans de scroll, mais il est en 16 couleur si tu es sur 1 plan, et 8 par plan en 2 plans.
Les problème sont surtout dans la gestion des sprites et tiles, pas de swap de sprite sur X et Y comme les consoles, donc tu uses 2 * plus de ram pour le même nombre d'anims .
Le son, 4 voix ca devient vite limite .

Après je dev pas sur amiga, donc je pourrais pas t'en dire vraiment plus .
La gestion des sprites, tiles, et ses 2 plans limités sont pour moi de gros défaut face aux console s 16 bits.

[ArchieForEver]

Oui la scene archi est petite comme celle du CPC, donc forcement la demo sur cette machine ne peut que faire évoluer lentement les connaissances .

Un question sur les demos rasters que tu as posté, tu est sur que ce sont de vrais rasters ??
On dirai juste un swap de palette pour donner l'effet de rasters !! .

La CopperSine demo je pense que c'est du swap de palette 256 couleurs.

Les autres c'est bien du raster.

[MacDeath]

houlà, la guerre se réveille, on voit qu'on est en pleine élections...
:)

bon c'est vrai que Shadow of the beast, c'est le truc toujours cité, du genre "tiens quand ta machine fera shadow of the beast comme sur Amiga elle sera aussi bonne qu'un Amiga...

euh lol...

Quand l'Amiga500 fera Wing Commander aussi bon que sur PC, ils sera... ah bin non tiens.

Bon, SotB fut une "Démo presque jouable" taillée spécialement autour de l'Amiga... Mais un jeux n'as pas beson de tout ça pour être bon, lol.

De mémoire il me semble que l'Amiga500 avait quand même pas mal de limitations concernant le nombre de couleurs sur les sprites, ils étaient limités en largeur mais pas en hauteur (sorte de multiplexing vertical "intégré quoi).


L'Archimede n'a qu'un théoriquement seul sprite Hard ?
juste pour le curseur souris ou quoi ?

y compris les contraintes, parceque les descriptions élogieuses qui oublient toujours les contraintes, comme pour le C64, ça me fatigue

De ce côté là je suis bien d'accord...
on casse trop souvent du sugar sur le dos du CPC comme quoi les graphismes ont de gros pixels moches alors que sur C64, c'est fin, y'a plein de couleures et c'est les meilleurs graphismes du monde...muarf...


En tout cas une chose est sûr... l'Atari ST est une bonne machine largement exploitable et exploité, l'Archimede est forcément largement "mieux".

C'est anormal par exemple qu'un type comme moi ait fait à mon coup d'essai un truc qui explose la concurrence alors que je débutais en assembleur.

[ArchieForEver]

Intéressant. En ce sens aussi l'Archimedes a plus de DMA (sur ses ports d'extension) mais un seul vers la video car il ne fonctionne pas en bitplans mais en 'chunky' donc un seul DMA pour lire la mémoire vidéo.
Combien de sprites hard gère l'Amiga et quelles sont les vraies caractéristiques (y compris les contraintes, parceque les descriptions élogieuses qui oublient toujours les contraintes, comme pour le C64, ça me fatigue).

Normal ,qu'un seul DMA, ca n'a rien à voir avec le chunky ou le BP, mais sur le fait que sur AMIGA, outre le CPU, Tout les custom y ont accès aussi .
car la mémoire de base de l'amiga la chip ram, est une mémoire unifiée .

???
Bien sûr que si ça a rapport avec le fait d'être un mode chunky.
Pour un mode chunky tu n'as besoin que d'un seul DMA.
Pour un mode bitplan il te faut un DMA par plan.

Ensuite heureusement que tes copros graphiques travaillent sous DMA.
Sur Archie j'ai le processeur graphique et son (VIDC), et pas de copro dédié donc évidemment ça nécessite moins de DMA.

Que le controleur disk bosse sous DMA ça c'est bien.
Je ne connais rien au 1772 de l'Archie, mais je vois mal comment ça pourrait fonctionner autrement que sous DMA.

En vérité ce concept de DMA n'a rien d'extraordinaire, et est juste cohérent avec les différents composants d'une bécane.
C'est l'interaction avec le bus du CPU, et les interactions entre les différents accès DMA quand ils se font en même temps, qui doit faire toute la différence.

[ArchieForEver]

houlà, la guerre se réveille, on voit qu'on est en pleine élections...
:)

bon c'est vrai que Shadow of the beast, c'est le truc toujours cité, du genre "tiens quand ta machine fera shadow of the beast comme sur Amiga elle sera aussi bonne qu'un Amiga...

euh lol...

Quand l'Amiga500 fera Wing Commander aussi bon que sur PC, ils sera... ah bin non tiens.

Bon, SotB fut une "Démo presque jouable" taillée spécialement autour de l'Amiga... Mais un jeux n'as pas beson de tout ça pour être bon, lol.

De mémoire il me semble que l'Amiga500 avait quand même pas mal de limitations concernant le nombre de couleurs sur les sprites, ils étaient limités en largeur mais pas en hauteur (sorte de multiplexing vertical "intégré quoi).


L'Archimede n'a qu'un théoriquement seul sprite Hard ?
juste pour le curseur souris ou quoi ?

y compris les contraintes, parceque les descriptions élogieuses qui oublient toujours les contraintes, comme pour le C64, ça me fatigue

De ce côté là je suis bien d'accord...
on casse trop souvent du sugar sur le dos du CPC comme quoi les graphismes ont de gros pixels moches alors que sur C64, c'est fin, y'a plein de couleures et c'est les meilleurs graphismes du monde...muarf...


En tout cas une chose est sûr... l'Atari ST est une bonne machine largement exploitable et exploité, l'Archimede est forcément largement "mieux".

C'est anormal par exemple qu'un type comme moi ait fait à mon coup d'essai un truc qui explose la concurrence alors que je débutais en assembleur.

Oui l'Archimedes n'a qu'un seul sprite hard, pensé pour afficher le curseur de la souris sous l'OS ... alors qu'on peut faire bien mieux avec.
N'importe quelle forme dans un rectangle de 32 pixels de large x hauteur max, avec sa propre palette de 3 couleurs parmi 4096, quand on dispose à côté d'un timer à 2 Mhz, ça donne beaucoup de possibilité de forme et de couleurs par ligne... hé hé ...

[Invité]

Non un canal DMA est 1 accès mémoire direct par une puce .
Donc si seul le CPU par exemple à un canal DMA, il peut accéder à la RAM/VRAM .
Le chunky ou le BP, defini seulement comment sont organisé les données en vram .
sur le chunky c'est contigu pour modifier la couleur d'un pixel, sur du BP, il faut modifier les 4 plans pour modifier un pixel .

Donc quand tu envoie des données par DMA, tu modifies ce que tu veux, ca depend du nombre de données que tu y envoie .
Comme je te l'ai dit, la ram de base de l'amiga sert pour tout, ram/vram/ram audio, donc toutes les chips y ont 1 ou plusieurs canaux DMA (ex paula pour le son, 1 canal/voix) .

@MacDeath: y'a pas de guerre, on essaye juste de se comprendre .

[ArchieForEver]

Non un canal DMA est 1 accès mémoire direct par une puce .
Donc si seul le CPU par exemple à un canal DMA, il peut accéder à la RAM/VRAM .
Le chunky ou le BP, defini seulement comment sont organisé les données en vram .
sur le chunky c'est contigu pour modifier la couleur d'un pixel, sur du BP, il faut modifier les 4 plans pour modifier un pixel .

Donc quand tu envoie des données par DMA, tu modifies ce que tu veux, ca depend du nombre de données que tu y envoie .
Comme je te l'ai dit, la ram de base de l'amiga sert pour tout, ram/vram/ram audio, donc toutes les chips y ont 1 ou plusieurs canaux DMA (ex paula pour le son, 1 canal/voix) .

@MacDeath: y'a pas de guerre, on essaye juste de se comprendre .

OK l'Archie c'est pareil : c'est aussi un système de RAM unifiée.
Rassure moi quand même : quand mon Archie envoie les données au VIDC pour qu'il les affiche, cette lecture a lieu sous DMA. Comme c'est un système chunky, le VIDC n'a besoin que d'un DMA.
Quand ton Amiga lui doit lire les différents plans, il faut donc que ton chip graphique accède via DMA à chacun des plans, non ? Donc si tu as 8 plans possibles sur Amiga tu as 8 DMA pour cette tâche de lecture de la vidéo écran hors le reste : sprites hards, etc ...) ?

Si ça marche comme sur mon Archie, ça remplit une pile FIFO pour ton processeur graphique qui va la lire pour former les données à envoyer au DAC.

En cela le nombre de DMA supérieur chez l'Amiga par rapport à l'Archie ne signifie pas qu'il est meilleur.
C'est juste qu'en chunky un seul DMA suffit et il te faut en mode bitplan autant de DMA que de plans nécessaires à la formation d'un data de pixel à afficher.

Je me trompe ou bien on ne se comprend toujours pas ?

PS : Dans les faits ce n'est pas pour un pixel à la fois, mais toute une série.
PS 2 : je n'ai peut être rien compris à la formation des pixels dans un système bitplan.

[ArchieForEver]

Intéressant. En ce sens aussi l'Archimedes a plus de DMA (sur ses ports d'extension) mais un seul vers la video car il ne fonctionne pas en bitplans mais en 'chunky' donc un seul DMA pour lire la mémoire vidéo.
Combien de sprites hard gère l'Amiga et quelles sont les vraies caractéristiques (y compris les contraintes, parceque les descriptions élogieuses qui oublient toujours les contraintes, comme pour le C64, ça me fatigue).

Normal ,qu'un seul DMA, ca n'a rien à voir avec le chunky ou le BP, mais sur le fait que sur AMIGA, outre le CPU, Tout les custom y ont accès aussi .
car la mémoire de base de l'amiga la chip ram, est une mémoire unifiée .

Pour les sprites l'amiga en gere 8 hard, mais via le blitter et même le copper tu peux en gérer bcp plus .
Les contrainte sont la taille, je sais plus qu'elle taille il peut gerer, mais ca s'efface grâce au blitter .
L'amiga à 2 plans de scroll, mais il est en 16 couleur si tu es sur 1 plan, et 8 par plan en 2 plans.
Les problème sont surtout dans la gestion des sprites et tiles, pas de swap de sprite sur X et Y comme les consoles, donc tu uses 2 * plus de ram pour le même nombre d'anims .
Le son, 4 voix ca devient vite limite .

Après je dev pas sur amiga, donc je pourrais pas t'en dire vraiment plus .
La gestion des sprites, tiles, et ses 2 plans limités sont pour moi de gros défaut face aux console s 16 bits.

Heuuu excuse moi mais pour flipper via copro des tiles sur X tu as juste ta routine de lecture et d'affichage à enrichir de cette fonction, et pas à avoir les tiles déjà flippés en RAM ....
En tout cas sur mon Archie sans blitter pas de soucis dans le shoot em up que je code : tous les chargements et affichage de tiles sont faits en soft et gèrent les flips.
Peut-être qu'en bitplan et comme tout doit passer par votre blitter, c'est un soucis... M'enfin à nouveau s'il sait copier des data, le flip par rapport à x ne devrait pas poser de soucis.(celui par rapport à y : oui).

Quand je vois toutes ces contraintes que vous avez avec l'usage de vos copros, dont les fonctions sont limitées et incomplètes, je me dis que la pureté du concept de l'Archimedes (un CPU puissant et hyper simple à programmer) est LA force de la machine d'Acorn.

PS : J'ajouterai que l'Archie a, lui, dès sa version de base 1 Mo de RAM, et son OS est dans une ROM de 512 Ko.
C'est sûr on est loin du concept console de jeux avec clavier de l'Amiga de base et ses 512 Ko.
Sur Archie, travailler sans disque dur, et sans un 2è lecteur de D7, ne pose pas de soucis, d'autant plus que l'OS gère le RAMdisk comme un filing system... sur le A500 on en est loin, bien loin de cette intelligence de conception. Ah évidemment l'Archie était plus cher, mais c'était bien justifié.

[MacDeath]

Lol au final (toute proportion gardée) comparer un Amiga500 et a Archimedes, c'est comme comparer un CPC6128 avec un TO8D finalement.

Sauf que l'Archimedes n'est pas si mauvais en sons, lol...

Concernant le "plan sprite" de l'archimedes...
Quid du multiplexage ?

C'est une seule "zone sprite" par scanline ?
verticalement, on peut l'étirer sur toute la hauteur... comme les sprites Amiga d'ailleurs si j'ai bonne mémoire, ou comme le multiplexing classique (C64...).

Y'a t'il des tricks pour en a fficher plus sur une même ligne ?

clignoter d'un affichage à l'autre déjà... (genre passer en 2x25hz au lieux de 50hz par exemple)
Il est "pointé" (C64) ou uploadé dans la puce (Amstrad PLUS) ?

N'importe quelle forme dans un rectangle de 32 pixels de large x hauteur max, avec sa propre palette de 3 couleurs parmi 4096, quand on dispose à côté d'un timer à 2 Mhz, ça donne beaucoup de possibilité de forme et de couleurs par ligne... hé hé ...

3 couleurs (donc 4 plus transparence en fait) c'est aussi peu que pour les sprites d'une NES ça (ou d'un C64 en pixels larges)

mais j'ai pas compris le coup du timer 2mhz par contre ?

Après bon, si faire du sprite en soft est plus lourd, ce n'est pas tant un handicap non plus qui empèche de faire quoi que ça soit non plus, la puissance brut de la machine suffit souvent a bien se démerder... on n'est plus justement sur un spectrum, CPC ou MO6... :)

[ArchieForEver]

Lol au final (toute proportion gardée) comparer un Amiga500 et a Archimedes, c'est comme comparer un CPC6128 avec un TO8D finalement.

Sauf que l'Archimedes n'est pas si mauvais en sons, lol...

Concernant le "plan sprite" de l'archimedes...
Quid du multiplexage ?

C'est une seule "zone sprite" par scanline ?
verticalement, on peut l'étirer sur toute la hauteur... comme les sprites Amiga d'ailleurs si j'ai bonne mémoire, ou comme le multiplexing classique (C64...).

Y'a t'il des tricks pour en a fficher plus sur une même ligne ?

clignoter d'un affichage à l'autre déjà... (genre passer en 2x25hz au lieux de 50hz par exemple)
Il est "pointé" (C64) ou uploadé dans la puce (Amstrad PLUS) ?

N'importe quelle forme dans un rectangle de 32 pixels de large x hauteur max, avec sa propre palette de 3 couleurs parmi 4096, quand on dispose à côté d'un timer à 2 Mhz, ça donne beaucoup de possibilité de forme et de couleurs par ligne... hé hé ...

3 couleurs (donc 4 plus transparence en fait) c'est aussi peu que pour les sprites d'une NES ça (ou d'un C64 en pixels larges)

mais j'ai pas compris le coup du timer 2mhz par contre ?

Après bon, si faire du sprite en soft est plus lourd, ce n'est pas tant un handicap non plus qui empèche de faire quoi que ça soit non plus, la puissance brut de la machine suffit souvent a bien se démerder... on n'est plus justement sur un spectrum, CPC ou MO6... :)

Ton lol me fait pitié : t'as à peine 1 MIPS de puissance CPU au niveau du 68000 de l'Amiga, et t'en as 4 chez l'Archimedes avec son ARM2 à 8Mhz...
Faut bien comprendre dans toutes nos discussions que je m'abaisse à rester au niveau du jeu et de la démo.
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, et de toute façon les ST et Amiga dans leur version de base ne sont pas fonctionnels pour faire tourner correctement de tels softs, à la différence de l'Archimedes de base qui lui le peut (c'est normal : l'Archimedes est un ordinateur, l'Amiga et le ST des consoles de jeu avec clavier).
Après vos petites machines doivent s'équiper de cartes accélératrices hors de prix là où sur Archimedes je sors mon ARM3 à 25 ou 33 Mhz que j'installe en lieu et place de l'ARM2, et à nouveau je suis loin devant, pour un cout moindre.

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 ?

Je ne comprends rien à ton histoire de multiplexing.
Je te reprends sur le sprite : chaque pixel est codé sur 2 bits donc 4 couleurs possibles par pixel, sauf que la couleur 0 (donc 00b) est la transparence. Ca laisse donc 3 couleurs (01b 10b 11b) pour former un sprite, et chcune des couleurs peut être n'importe laquelle parmi la palette de 4096 couleurs de l'Archimedes.
Ce que je peux te dire du sprite hard sur Archimedes, c'est qu'à chaque lecture sous DMA de la mémoire vidéo à afficher, toutes les 2 lignes raster, la lecture du buffer du sprite a lieu (sous DMA) (toutes les 2 lignes car une lecture lira 2 lignes de définition du sprite hard).
Le contenu de la lecture est superposé au contenu de chaque raster, avec 0 (couleur sprite) pour la transparence.
Donc, non, il n'y aura pas de trick pour 2 affichages par ligne.
Par contre tu peux bien sûr faire un affichage par 25è de seconde pour en avoir 2 à l'écran. Selon les couleurs ça flashotera plus ou moins mais ça peut être super intéressant : par exemple dans mon shoot em up vertical ça me fera des tirs laser.(et pas forcément dans une verticale, mais n'importe quelle déformation en X, puisqu'avec le timer à 2 Mhz je peux altérer le x de l'affichage du sprite hard à chaque scan line. Et je m'occuperai de sa palette aussi).

Verticalement tu es toute hauteur.
Tu peux l'afficher au pixel près où tu veux, il a un pointeur de début et de fin de lecture que tu peux altérer, à la fois en x et en y.
Le buffer est fixe à côté de la mémoire vidéo (oui il faut le remplir si on veut chnager le sprite hard, on ne peut pas pointer n'importe où en mémoire. Mais on peut pointer n'importe où dans le buffer du sprite hard donc si tu veux animer un petit sprite et que tes différentes images sont dans le buffer, il suffira de pointer sur chaque image successive de l'animation.).
Il n'y a pas de fonction d'étirement, maintenant tu sais pour recopier 32 pixels en 2 bits (donc une ligne du sprite) ça correspond à lire 8 octets et les recopier...whaou ! 16 cycles dis donc : terrrrriiiible .... lol (16 cycles car chaque ligne du buffer est sur une adresse multiple de 4 donc on peut utiliser LDMIA / STMIA, on aura 2 mots de 32 bits à lire et mettre en registre, et les mêmes registres à stocker ensuite en mémoire, soit 2 x 4 cycles à chaque fois)
M'enfin peut-être que tu devrais mieux regarder ma preview de démo où je suis en 256 couleurs, overscan, en 50 images par seconde.
Imagine donc la tuerie que ce serait en 16 couleurs... mais je ne m'abaisserai pas à un mode graphique de ST ou d'Amiga.
Tu devrais voir que l'Archie rien qu'avec son ARM est bien né pour manipuler de la donnée 2D.
Les routines que je suis en train de finir ajouteront la déformation en X et seront encore un peu plus rapide.
Tu fais ça sur Amiga ? En 256 couleurs ? Ah oui avec le HAM super flashy qui te détruit les yeux au bout de 30 secondes, bien sûr.
Un autre point sur les fameux super copros de l'Amiga : faire des déformations plasma et autres c'est bien mignon, mais si ensuite tu ne peux de toute façon rien afficher dessus, car tu as bouffé tous les plans disponibles, ou bien tu es en changement de pointeur video en temps réel ligne à ligne, pour moi c'est bullshit.
Ca en met plein la vue dans les démos, mais pour quoi que ce soit d'autres ça ne sert strictement à rien, puisque tu ne peux rien afficher dessus, ou alors ce sera en monochrome.

Sur Archie, comme sur un PC, tu as 256 couleurs et elles sont là pour tout : ton scrolling background, tes sprites, ton HUD, etc ...

[65c02]

Vous êtes marrant à vous mettre sur la gueule comme ça :)

Sérieux, si l’Archimède est un "vrai ordinateur" et les st amiga "des consoles avec des claviers" : pourquoi les comparer ?
Et si le proc de l'Archimède et si puissant, l'honneur va aux dév st et amiga pour avoir fait tant avec si peux :)

Bon, j’arrête de troller (surtout que c'est pour déconner)

En tout cas, en lisant Archiforever, je regrette de ne pas avoir connu l’Archimède en son temps.

[Invité]

archiforever j'ai l'impression que tu sais pas trop à quoi sert un copro .

Le copper est un chip programmable, qui te permet d'avoir le contrôle entier sur le faisseau, ainsi que sur la palette.
Avec ce qu'on appelle le copper list il fait des distorsions d'écrans ou du swap de palette comme un grand, pendant que le CPU fait autres chose .

Le plasma est juste un effet pour monter sa flexibilité, et ce qu'on peut faire avec 0% de CPU .
Toi pour le faire tu dois faire des routines entierement synchro avec un affichage sous timer (vachement pratique hein) .
Le St fait la même chose que l'archi, il à 2 timers, bah il est à la ramasse .
Bien sur que tu peux faire tout les effets du monde en soft, mais à force de tout faire en soft, bah t'as plus de cycles pour faire le reste.
Dans une demo ca va, mais dans un jeu, bah c'est problématique .

L'amiga peut faire tourner un jeu avec quasiment très peu de CPU, c'est d'ailleurs à cause du fait que dans une architecture amiga de base, donc juste avec de la chip ram, le CPU, est celui qui à la priorité la plus basse pour l'accès à la ram .
Donc les codeurs amiga, ont appris à s'en passer le plus possible,contrairement aux codeurs ST .
il y a des demos en mode HAM, et qui ne flashent pas du tout .
Mais si on suit ton résonement les japs sont des cons d'avoir mis des copros dans leurs consoles .

Les perfs du blitter sont bien meilleures à ton arm @ 8mhz, bien meilleures .
Car il peut déplacer de gros bloc de données en mémoire, sans solliciter le CPU .
Et chose importante, il ne bloque pas le 68000 pendant ses transferts .

Bien sur en perfs pure l'arm explose le 68000, ca c'est sur .

Le multiplexing de sprites,est une astuce pour avoir plus de sprites à l'écran, que la machine ne peut en gérer
Ex ton sprite tu le mets en haut à gauche de l'écran (on va dire qu'il fait 16*16 pixels)
et bien à la ligne 17 tu le déplace en bas à droite, donc visuellement tu aura 2 sprites hard à l'écran .
En bref ca consiste à déplacer des sprites hard déjà affichés dans zones écran qui ne le sont pas encore.

En plus n'oublies pas que l'archi est sorti 3 ans après l'amiga .

Tu peux voir des infos technique sur le blitter ici: http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0118.html

[MacDeath]

The sprite multiplexing technique is based on the idea that before the video hardware displays the next frame, the computer program will program the hardware to display those sprites that are first to be displayed. After those sprites have been displayed, the program then reprograms the hardware to display the remaining sprites. That way, the number of sprites that appear on the screen may be doubled, or increased even more.

The programmer must carefully consider the layout of the screen. If the video graphics hardware is not reprogrammed in time for the extra sprites to be displayed, they will not appear.

The technique relies on the program being able to identify what part of the screen is being drawn at the moment, or being triggered by the video hardware to run a subroutine at the crucial moment.

Mais cette technique n'est plus d'actuallité à partir du moment ou le sprite peut nativement avoir une hauteur variable, il te suffit d'une ligne à l'autre de simplement l'afficher ailleurs en axe X, je suppose.


La comparaison CPC6128 et TO8D était surtout sur le côté RAM dispo... (128 pour le CPC, 256 pour le TO8D) et divers truc genre le 6809 qui passe pour être un bon processeur...
Et la différence de prix des deux machines aussi.

Après je te l'accorde, c'est spécieux comme comparaison et a ne pas prendre trop formellement.


Bin c'est quand même un peu dommage que l'Archimedes n'ai pas eut un peu plus de slots de sprites je trouve.
8 sprites (comme celui qu'il a) ça aurait largement suffit pour en faire une bonne console de jeux ou améliorer le panel d'effets 2D de type démo...


ça coutait combien un Archi à l'époque ?

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, et de toute façon les ST et Amiga dans leur version de base ne sont pas fonctionnels pour faire tourner correctement de tels softs, à la différence de l'Archimedes de base qui lui le peut (c'est normal : l'Archimedes est un ordinateur, l'Amiga et le ST des consoles de jeu avec clavier).

Ok pour la supériorité du systeme ARM...

Mais sinon je te trouve un peu dure avec l'Atari ST... si il y a bien un ordinateur qui ne peut être qualifié de console de jeux, c'est bien l'Atari St.

"Peu puissant" comparativement, peut être, mais de la a en faire une console...

C'est par la force des choses que le ST est devenue une machine de jeux : pas cher, il a finis dans les chambres des gamins...
Mais moi mon PC286 EGA 12mhz... il a aussi finis en machine de jeux finalement, et de ce côté là un ST aurait presque été mieux alors (du son, une meilleur palette en simple mode 320x200) pour 3x moins cher.
(même si sur les simulateurs de vol en 3D, mon PC déchirait bien... 12mhz quand même...)

L'Atari St n'est il pas d'ailleurs un poil plus performant en 3D que l'Amiga500 d'ailleurs ? aidé par le fait que des sprites 2D ça aide peu, et que il est plus léger en affichage (32K de "VRAM", ou pas plombé par certains trucs des coprocesseurs justement...

Et puis un Atari ST, ça coutait pas 2x moins cher qu'un Archimede ? sachant qu'il était aussi équippé bien souvent avec pas mal de RAM.

un 1040STE c'était pas cher et assez bien quand même, et il avait la bonne idée d'avoir sa RAM sur barrettes...

De ce côté là, le 68000 se place bien comme le Z80 des 16/32bit.
une technologie maitrisée et relativement peu couteuse.

ça coutait combien un Archi à l'époque, déjà ?


Bon, y'a pas eut de postage de photos des machines me semble t'il..

Les modèles compacts... la classe.


A3020
(sortis en 1992)

J'aime bien la forme plus arrondis de la coque, il ressemble furieusement a un Amstrad PLUS d'ailleurs.

Le 3010 est le modèle familial à £500. On le reconnais à ses touches de fonction grises et non rouges. il intègre deux ports joysticks, une sortie TV et un ou deux Mo de RAM.

Le 3020 est le modèle avancé à £1000. Il est destiné à l'éducation. Sans sortie TV ou port joystick, il dispose d'un connecteur réseau ou peuvent se mettre une carte Ethernet ou Econet. Il a un disque dur 60Mo.

Le 4000 est un 3020 dans un boîtier d'Archimedes 5000 à clavier séparé et coûte £1100.

mmm je ne sais pas trop ce que ça donne les prix.
500£ pour un 3010 ? ça peut sembler relativement pas trop cher quand même... ça faisait 5000frs non ?
Mais on est en 1992 alors...

Archimedes est une série d'ordinateurs de plusieurs modèles. Retenons :

la première série 300 et 400 (305, 310, 410, 420 et 440), en 1987,
le modèles 3000 sort en mai 1989,
les modèles 410/1, 420/1 et 440/1 en juillet 1989
le 540 avec processeur ARM 3,
5000 puis A4 et 4000 ont suivi avec un ARM250.
les 3010 et 3020 qui remplacent le 3000 en août 1992,
le 4000, un 3020 en format desktop,
le RiscPC, serie 600, A7000 en 1995
la seconde génération de RiscPC avec la série 700 en juillet 1995

[ArchieForEver]

Vous êtes marrant à vous mettre sur la gueule comme ça :)

Sérieux, si l’Archimède est un "vrai ordinateur" et les st amiga "des consoles avec des claviers" : pourquoi les comparer ?
Et si le proc de l'Archimède et si puissant, l'honneur va aux dév st et amiga pour avoir fait tant avec si peux :)

Bon, j’arrête de troller (surtout que c'est pour déconner)

En tout cas, en lisant Archiforever, je regrette de ne pas avoir connu l’Archimède en son temps.

Et je suis bien d'accord : chapeau bas aux développeurs ST et Amiga.