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

[Invité]

La PCE a sa place partout. Respect à la PCE SVP.

Voilà, la PCE c'est le squatteur sympa de service à qui on ne dit jamais non.

Disons qu'elle à plus sa place parmi les 16 bits, que face à la nes ou la SMS .
Après chaque machine a ses limites/restrictions .

[ArchieForEver]

Ca a quand même plus de sens de mettre la PCE dans un débat snes vs Md, qu'un spectrum amélioré dans un débat sur des ordis 16 bits 

Tu vois que c'est toi qui troll... 

Tout le monde s'en fout mais j'ai entre 4,4 et 11 millions de pixels (octets) en mode 256 couleurs sur une machine ARM2 à 8 Mhz ( MAIS j'utilise toute la puissance dispo, et vraiment tout dépend de la taille des segments horizontaux : plus c'est petit, moins c'est bon )

Personne s'en fou ..
Une petite démos avec des bobs(et pas des boobs) 32x32 qui bougent ??

Faudrait déjà que je finisse le projet en cours.
Pour revenir à la vitesse de ma routine de remplissage, j'ai trouvé 11 sur un test, mais en me basant sur le remplissage d'un triangle ; j'aurais encore mieux pour un rectangle de surface double du triangle, tout ça lié au timing d'exécution de STM. (plus le segment est long, + le coût d'affichage d'un pixel est faible, et puis bon même ça n'est vrai que 90% du temps en réalité).
Je précise que la routine n'est pas limitée à des triangles ou des carrés, n'importe quelle forme peut être 'remplie' et en plus pas qu'en monochrome mais n'importe quel pattern de 2 pixels consécutifs de couleur.

Pour les bobs 32x32 j'y réfléchis depuis hier, il y a au moins 2 variantes, et chacune d'elle a une optimisation possible, mais je n'arrive pas à évaluer laquelle des 4 idées sera la + rapide, et si en fait l'optimisation a du sens s'il y a vraiment bcp de bobs à l'écran :-).
J'ai besoin de savoir si les trajectoires peuvent être ou non précalculées, ça change bcp de choses ( l'optimisation consiste à ne pas recopier l'écran de background, mais juste le tour du bob ; hors ça ne marche que si 2 bobs ne se touchent pas et pour éviter tous les tests il faudrait l'info de 'non collision' avec la liste précalculée des positions. En cas de touché l'affichage se ferait avec un type de routines, et si pas de touché, un autre. Et bien sûr + il y a de bobs à l'écran, moins la routine réécrivant juste le tour a d'intérêt car bcp de bobs vont se toucher, et ça c'est DRôLE )

[TotOOntHeMooN]

Disons qu'elle à plus sa place parmi les 16 bits, que face à la nes ou la SMS .
Après chaque machine a ses limites/restrictions .

C'est certain. C'est une machine très bien pensée qui mériterait d'avoir son topic Fight !

[ArchieForEver]

Ca a quand même plus de sens de mettre la PCE dans un débat snes vs Md, qu'un spectrum amélioré dans un débat sur des ordis 16 bits 

Tu vois que c'est toi qui troll... 

Tout le monde s'en fout mais j'ai entre 4,4 et 11 millions de pixels (octets) en mode 256 couleurs sur une machine ARM2 à 8 Mhz ( MAIS j'utilise toute la puissance dispo, et vraiment tout dépend de la taille des segments horizontaux : plus c'est petit, moins c'est bon )

Personne s'en fou ..
Une petite démos avec des bobs(et pas des boobs) 32x32 qui bougent ??

Après y avoir réfléchi, je me lance ...
Comme je n'ai pas envie pour l'instant de reprendre le projet de portage de Shadow Of The Beast, et bien je m'attaque aux bobs.
Ce soir je viens de finir un outil sous Excel.
Demain soir début de commencement de mise en application.
Suis vraiment très confiant, en 320 x 200, 16 couleurs je pense que le résultat devrait en surprendre plus d'un 
En passant ce sera la même bouboule que celle de la démo STE, mais elle n'aura pas 15 couleurs, mais 16, puisque mes routines n'ont pas besoin de garder une couleur pour la transparence, au contraire d'un blitter.

[ArchieForEver]

Précision sur les sprites : c'est 8 en 2 bits ou 4 en 4 bits contrairement à ce qui a été écrit plus haut.

Point de 8 couleurs.

Détail qui a son importance : ce sera 8 en 2 bits mais pas 8 en 4 couleurs car une des couleurs sert à la transparence ; donc 8 sprites avec 3 couleurs possibles par sprite.
Pareil pour les 4 en 4 bits, ce sera 4 mais avec 15 couleurs, et non pas 16 couleurs.

Ca me fait penser au dual playfield cette histoire : le plan sera en 3 bits, on pourrait s'attendre donc à avoir 8 couleurs, mais non, il en faut une pour la transparence, du coup c'est 7 couleurs.

Heureusement oui le copper permet d'augmenter le nombre de couleurs, mais ce n'est pas la même souplesse que d'avoir dès l'origine plus de bits.

[TotOOntHeMooN]

Oui, enfin... 15 ou 16 couleurs ça va. Ce n'est pas comme avec des sprites en 1bit ou tu perds la moitié de tes couleurs avec la transparence. 

Mais effectivement, cette histoire de couleur de transparence inhérente à la gestion des sprites hard c'est toujours la bête noire des graphistes à qui il manque comme par hasard toujours une couleur. 

[ArchieForEver]

ouais mais de 16 à 15 soudainement ça fait 6,66 % de couleurs en moins, et de 8 à 7 12,5 %

Des sprites en 1 bit ?
Ca existe ça ? Sur quelles bécanes ?
Même sur les ordis 8 bits tu avais au moins 4 couleurs, enfin 3 visibles.

[TotOOntHeMooN]

Des sprites en 1 bit ? Ca existe ça ?
Même sur les ordis 8 bits tu avais au moins 4 couleurs, enfin 3 visibles.

C'est le cas sur MSX.

[ArchieForEver]

Ah ok je pige mieux.
J'allais citer la vcs sans même être sûr, ou la colecovision.

[TotOOntHeMooN]

Ah ok je pige mieux.
J'allais citer la vcs sans même être sûr, ou la colecovision.

La Colecovision utilise le même VDP donc forcément. Et le C64 en pixel ratio 1:1 si je m'abuse.
2bit c'est vraiment le strict minimum pour commencer à faire quelque chose avec outline sans gaspiller un autre sprite.

Sur Archi, j'imagine que tes sprites sont du code et qu'il skip juste l'affichage des zones définies comme transparentes, indépendamment de la palette.

[Invité]

Heureusement oui le copper permet d'augmenter le nombre de couleurs, mais ce n'est pas la même souplesse que d'avoir dès l'origine plus de bits.

Bah non c'est sur, cependant ça permet de la souplesse contrairement à une console(et c'est le but à la base d'avoir une machine la plus flexible possible),mais forcément avec aussi des inconvénients . 
Avec une console tu peux très difficilement sortir des limites imposées par le hardware .

Sur archimedes, tu as aussi des limites liées a son architecture et aux choix techniques, mais il faudrait que tu ais le même oeil critique avec lui que tu as avec les autres machines .
La palette par exemple, n'est pas une vraie palette 8 bits, tu ne peux choisir que 16 couleurs le reste est choisi automatiquement en fonction des 16 premières, cependant que ce passe t'il si tu modifies une ou plusieurs couleurs de ta palette de 16 couleurs, les autres sont elles modifiées aussi ??

[ArchieForEver]

oh mais je suis bien d'accord.
L'Archimedes n'est absolument pas une machine parfaite.
Pour les 256 couleurs c'est pire que ce que tu écris : tu as 16 registres de définition et de là les 256 couleurs se font.
Je ne pense même pas que tu puisses ainsi réellement définir 16 couleurs au choix, mais tu vas être très proche.
Et en effet si tu changes le contenu d'une seule des entrées et bien tu affectes, je pense, le rendu de 16 couleurs.

[ArchieForEver]

Ah ok je pige mieux.
J'allais citer la vcs sans même être sûr, ou la colecovision.

La Colecovision utilise le même VDP donc forcément. Et le C64 en pixel ratio 1:1 si je m'abuse.
2bit c'est vraiment le strict minimum pour commencer à faire quelque chose avec outline sans gaspiller un autre sprite.

Sur Archi, j'imagine que tes sprites sont du code et qu'il skip juste l'affichage des zones définies comme transparentes, indépendamment de la palette.

Oui sur Archie c'est bien cela.
Après, c'est comme tout le reste, c'est l'optimisation de ton code généré qui fera que tu vas au final être rapide, ou très rapide.
Il n'y pas qu'une solution.
De + des trucs rigolos ont été découverts au fil du temps.
Par exemple aligner les datas sur des adresses multiples de 16 octets va te faire éviter la pénalité de blocage du CPU lors de l'accès DMA vidéo.
Il a aussi été trouvé que tu peux avoir des instructions utilisant l'ALU qui vont coûter 0 cycle si elles sont placées juste après une instruction LDR ou STR.
Ca paraît con mais grapiller 1 cycle par ici, 2 cycles par là, sur l'affichage de chaque segment horizontal d'un sprite, et bien au final tu libères plusieurs %
de cycles pour le CPU.
En appliquant tout ça dans mes routines de remplissage pensé pour la 3D, j'ai trouvé que j'avais jusqu'à 4% de gain en vitesse d'exécution.

Evidemment rien de tout ça n'est mis clairement dans une doc Acorn, il aura fallu que ce soit découvert par hasard, ou bien par des quasi électroniciens
en déchiffrant la doc de VLSI, le fondeur des puces ARM.
C'est tout de même malheureux.
Il y a 2 bouquins pour apprendre l'assembleur ARM, aucun ne te donne les timings des instructions.
Là encore il faut avoir le bouquin de VLSI, ou bien avoir été direct en relation avec Acorn, pour avoir + de détails.
On savait que les instructions de transferts multi registres étaient à privilégier, mais pour le timing exact, et bien il fallait faire soi-même les tests
pour comprendre ce que ça donnait ( non pas que c'était extrêmement difficile de coder ces tests, mais bon, ça aurait aider d'avoir les infos dès le départ ).
Il y a même des trucs limite faux dans les bouquins : genre pour les transferts multiples il faut être sur des adresses multiples de 4.
Ben non, les instructions utilisent d'elles-mêmes l'adresse multiple de 4 de l'adresse utilisée.
En cas d'accès simple pour 1 seul registre avec LDR ou STR il faut être sur une adresse multiple de 4.
Ben non, là encore si on n'est pas aligné et bien LDR charge 4 octets en effectuant une certaine rotation ( et c'est super intéressant pour le code généré pour afficher du graphisme)
et STR automatiquement se place sur l'adresse multiple de 4 de l'adresse utilisée.
Ca paraît tout con tout ça, mais au final ça permet d'économiser bien des cycles.

[Invité]

Ce que tu dis là ne m'étonne pas, car c'est pareil pour toutes les machines, on découvre plein de trucs avec le temps, parce que justement optimiser le code au maximum et tester le hardware aujourd'hui est bcp plus simple qu'a l'époque ou tu avais des contraintes et des deadlines pour sortir un truc, surtout les jeux .

C'est aussi l'avantage d'avoir une scène,ça permet de justement accélérer le processus,mais bon même avec une machine comme le C64 qui a été retourné jusqu'à l'os à l'époque, les codeurs trouvent encore des trucs 30 ans après .

[ArchieForEver]

Ce que tu dis là ne m'étonne pas, car c'est pareil pour toutes les machines, on découvre plein de trucs avec le temps, parce que justement optimiser le code au maximum et tester le hardware aujourd'hui est bcp plus simple qu'a l'époque ou tu avais des contraintes et des deadlines pour sortir un truc, surtout les jeux .

C'est aussi l'avantage d'avoir une scène,ça permet de justement accélérer le processus,mais bon même avec une machine comme le C64 qui a été retourné jusqu'à l'os à l'époque, les codeurs ont trouvé encore des trucs 30 ans après .

Exact.
J'ai ajouté des infos pendant que tu postais.

Quand tu vois qu'enfin on a une interruption de fin de ligne stable sur Archie ( et qui ne bloque pas tout, mais permet aussi de jouer un module et scanner le clavier ), après toutes ces années ...
Si les codeurs avaient trouvé ça dès les 1ères années, les jeux et la demo scene auraient été très différents.
En fait ça avait + ou - été trouvé, déjà, mais pas partagé.


Et regarde le Spectrum : sans déconner ils ont maintenant des moteurs graphiques qui permettent certes avec certaines contraintes de mettre + de couleurs par bloc de je ne sais combien de pixels.
si ça avait été trouvé à l'époque, mamamia ça aurait été une vraie tuerie.

[Invité]

Et regarde le Spectrum : sans déconner ils ont maintenant des moteurs graphiques qui permettent certes avec certaines contraintes de mettre + de couleurs par bloc de je ne sais combien de pixels.
si ça avait été trouvé à l'époque, mamamia ça aurait été une vraie tuerie.

Oui le spectrum a vachement évolué malgré les contraintes de la machine, et surtout côté démos(jeux aussi) .
Le CPC également, on a vu de sacrées prods sur cette machine,avec les + qui commencent enfin a émerger .

[ArchieForEver]

Elle est visible où la demo du blitter avec les bouboules affichées au blitter, sur Amiga ?
Lien YT SVP ?

[Invité]

Là :


D'ailleurs faits étonnants le blitter de l'A1200 est plus rapide, c'est bien sur le même, mais je pense qu'il dispose de bien plus de cycles DMA, puisqu'il permet d'afficher autant de bobs en 8 bpp que l'ocs en 5 .

[Tryphon]

Il a aussi été trouvé que tu peux avoir des instructions utilisant l'ALU qui vont coûter 0 cycle si elles sont placées juste après une instruction LDR ou STR.

Dans les MIPS, il me semble que les instructions suivant un branchement sont gratuitement et automatiquement exécutées, même si le branchement a lieu (ce qui est assez déstabilisant quand tu codes la première fois dessus) (et même les suivantes )

[Invité]

Dans les MIPS, il me semble que les instructions suivant un branchement sont gratuitement et automatiquement exécutées

Pipeline prédictif ??

[Tryphon]

Dans les MIPS, il me semble que les instructions suivant un branchement sont gratuitement et automatiquement exécutées

Pipeline prédictif ??

Je suis pas sûr de savoir ce que c'est, mais je pense pas, parce que l'instruction qui suit est toujours exécutée (et ça ne peut pas être n'importe quelle instruction, je crois que c'est que des ld). Je crois que c'est surtout que les instructions sont toujours lues 2 par 2 (elles font toutes la même taille). D'ailleurs dans le code que j'ai parcouru, y'a souvent des nop après les sauts, j'ai pas compris pourquoi tout de suite

Kannagi doit en savoir beaucoup sur ces trucs-là (c'était sur PS2).

[ArchieForEver]

Dans les MIPS, il me semble que les instructions suivant un branchement sont gratuitement et automatiquement exécutées

Pipeline prédictif ??

Je suis pas sûr de savoir ce que c'est, mais je pense pas, parce que l'instruction qui suit est toujours exécutée (et ça ne peut pas être n'importe quelle instruction, je crois que c'est que des ld). Je crois que c'est surtout que les instructions sont toujours lues 2 par 2 (elles font toutes la même taille). D'ailleurs dans le code que j'ai parcouru, y'a souvent des nop après les sauts, j'ai pas compris pourquoi tout de suite

Kannagi doit en savoir beaucoup sur ces trucs-là (c'était sur PS2).

Hé bé au niveau de la densité du code ça ne doit pas être top si à chaque fois il faut mettre un NOP

[ArchieForEver]

Là :


D'ailleurs faits étonnants le blitter de l'A1200 est plus rapide, c'est bien sur le même, mais je pense qu'il dispose de bien plus de cycles DMA, puisqu'il permet d'afficher autant de bobs en 8 bpp que l'ocs en 5 .

OK.
Intéressant.
Pas de musique ?
Il y a une raison à cela ?

[Invité]

Dans les MIPS, il me semble que les instructions suivant un branchement sont gratuitement et automatiquement exécutées

Pipeline prédictif ??

Je suis pas sûr de savoir ce que c'est, mais je pense pas, parce que l'instruction qui suit est toujours exécutée (et ça ne peut pas être n'importe quelle instruction, je crois que c'est que des ld). Je crois que c'est surtout que les instructions sont toujours lues 2 par 2 (elles font toutes la même taille). D'ailleurs dans le code que j'ai parcouru, y'a souvent des nop après les sauts, j'ai pas compris pourquoi tout de suite

Kannagi doit en savoir beaucoup sur ces trucs-là (c'était sur PS2).

En gros le pipeline peut prédire la prochaine instruction et la préparer avant, pendant qu'il exécute celle en cours, normalement c'est sans surcoût, sauf si il se goure    .
Aujourd'hui c'est bien plus complexe et précis et ça permet d'exécuter 2/3 instructions par cycle .

Pas de musique ?
Il y a une raison à cela ?

Non, je pense que c'était pas le but,dans le sens où c'est plus un test qu'une démo .

[Zarnal]

Bon alors, en fin de compte qui gagne ?

[tristan33]

Bon alors, en fin de compte qui gagne ?

L'Amiga, comme toujours...

[ArchieForEver]

Ceux qui aiment le vert, assurément...

[ArchieForEver]

Pas de musique ?
Il y a une raison à cela ?

Non, je pense que c'était pas le but,dans le sens où c'est plus un test qu'une démo .

Ici 
https://youtu.be/s6cGWF_ERrg
 le codeur précise qu'il faut 1000 cycles pour du son (j'imagine, que ça veut dire jouer un MOD).
'Audio requies 4 cycles in each line, but not each line is used I would say 1000cycles total.'
Je lui ai posé la question dans sa dernière vidéo pour savoir s'il pourrait jouer un MOD (lui reste-t-il 1000 cycles ?)

Ca prend 1000 cycles de jouer un MOD 4 canaux sur Amiga ?
C'est classe, c'est hyper rapide.

Les infos techniques données sont intéressantes :
Amiga ocs has 312 display lines each with 226 cycles which gives us 70512 cycles total.

Blitting 32x32 bob into 4 bitplane requies 2304cycles each
Blitting 32x32 bob into 5 bitplane requies 2880cycles each
Blitting 32x32 bob into 6 bitplane requies 3456cycles each
Blitting 48x48 bob into 4 bitplane requies 5184cycles each
Blitting 48x48 bob into 5 bitplane requies 6480cycles each
Blitting 48x48 bob into 6 bitplane requies 7776cycles each
Blitting 64x64 bob into 4 bitplane requies 9216cycles each
Blitting 64x64 bob into 5 bitplane requies 11520cycles each
Blitting 64x64 bob into 6 bitplane requies 13824cycles each
Blitting 80x80 bob into 4 bitplane requies 14400cycles each
Blitting 80x80 bob into 5 bitplane requies 18000cycles each
Blitting 80x80 bob into 6 bitplane requies 21600cycles each
Blitting 96x96 bob into 4 bitplane requies 20736cycles each
Blitting 96x96 bob into 5 bitplane requies 25920cycles each
Blitting 96x96 bob into 6 bitplane requies 31104cycles each
Blitting 112x112 bob into 4 bitplane requies 28224cycles each
Blitting 112x112 bob into 5 bitplane requies 35280cycles each
Blitting 112x112 bob into 6 bitplane requies 42336ycles each
Blitting 128x128 bob into 4 bitplane requies 36864cycles each
Blitting 128x128 bob into 5 bitplane requies 46080cycles each
Blitting 128x128 bob into 6 bitplane requies 55296cycles each
Screen mode of 320x200lines in 4 bitplanes requies 80cycles in each line so 16000total
Screen mode of 320x200lines in 5 bitplanes requies 100cycles in each lin, so 20000total
Screen mode of 320x200lines in 6 bitplanes requies 120cycles in each line, so 24000total
Screen mode of 256x200lines in 4 bitplanes requies 64cycles in each line, so 12800total
Screen mode of 256x200lines in 5 bitplanes requies 80cycles in each line, so 16000total
Screen mode of 256x200lines in 6 bitplanes requies 96cycles in each line, so 19200total

All 8 sprites used requies 16 cycles in each line they are displayed.
Audio requies 4 cycles in each line, but not each line is used I would say 1000cycles total.

What does it all mean?

Take a look for example at comparing 320x200x16c requies the same DMA as 256x200x32c, but we still need more DMA for blitting which allows us to draw 20% BOBs less.

320x200x16c allows to draw about 21 32x32 BOBs in single frame
256x200x32c allows to draw about 17 32x32 BOBs in single frame
256x200x64c allows to draw about 13 32x32 BOBs in single frame

Ca serait cool d'avoir ces mêmes infos pour le STE, pour comparer (quand le STE a des modes graphiques équivalents)

[Tryphon]

Hé bé au niveau de la densité du code ça ne doit pas être top si à chaque fois il faut mettre un NOP

Bah non justement, si t'exploites le truc correctement, ça fait au contraire du code plus compact.

[ArchieForEver]

Hé bé au niveau de la densité du code ça ne doit pas être top si à chaque fois il faut mettre un NOP

Bah non justement, si t'exploites le truc correctement, ça fait au contraire du code plus compact.

Ah ?
Faudra que tu m'expliques, parce que si tu es obligé de placer des NOP partout, je ne vois pas où est le gain au niveau taille du code.
Que tu aies un gain en vitesse d'exécution,car, je cite
'
l'instruction qui suit est toujours exécutée (et ça ne peut pas être n'importe quelle instruction, je crois que c'est que des ld). Je crois que c'est surtout que les instructions sont toujours lues 2 par 2
'
 je pige ; mais pour la taille du code, non.

[Tryphon]

Hé bé au niveau de la densité du code ça ne doit pas être top si à chaque fois il faut mettre un NOP

Bah non justement, si t'exploites le truc correctement, ça fait au contraire du code plus compact.

Ah ?
Faudra que tu m'expliques, parce que si tu es obligé de placer des NOP partout, je ne vois pas où est le gain au niveau taille du code.
Que tu aies un gain en vitesse d'exécution,car, je cite
'
l'instruction qui suit est toujours exécutée (et ça ne peut pas être n'importe quelle instruction, je crois que c'est que des ld). Je crois que c'est surtout que les instructions sont toujours lues 2 par 2
'
 je pige ; mais pour la taille du code, non.

Ben c'est pas compliqué : au lieu de faire un :

Code:

ld r1, qqch
test sur r2
branchement

tu fais

Code:

test sur r2
branchement
ld r1, qqch

J'ai jamais dit qu'il fallait qu'il y ait un nop après chaque branchement, j'ai dit que sur le code que j'ai analysé (Phantasy Star Generations I et II sur PS2) il y avait certains nops que je m'expliquais pas. C'était certainement du C compilé, peut-être que le compilateur optimise mal.