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

[Copper]

Ce qui serait impressionnant c'est de découvrir cette "demo" seulement maintenant

[Copper]

s'il n'y a pas de problématique, expliques moi enfin.. ça fait jsute 8 fois que je te pose la question

En fait tu te poses des problèmes qui n'existent pas... Pour la 3D on utilise un double buffer ni plus ni point... Et ca ne change pas grand chose en interlace... Même s'il faut évidemment permuter les adresses des bitplanes dans les 2 copperlistes...

[The_Real_Zarchos]

s'il n'y a pas de problématique, expliques moi enfin.. ça fait jsute 8 fois que je te pose la question

En fait tu te poses des problèmes qui n'existent pas... Pour la 3D on utilise un double buffer ni plus ni point... Et ca ne change pas grand chose en interlace... Même s'il faut évidemment permuter les adresses des bitplanes dans les 2 copperlistes...

Mais kilékon à bouffer du foin.
Je suis plié en 4 derrière mon écran...

[Copper]

Et pourquoi donc ?

[rocky007]

parce que t'es juste complétement à coté de la plaque, j'ai l'impression de discuter avec dlfrsilver

[Copper]

C'est toi qui est à coté de la plaque mais c'est pas grave...

Mais n'hésite pas expliquer ton problème et comment tu ne le résoudrais pas surtout

[Invité]

Mais kilékon à bouffer du foin.
Je suis plié en 4 derrière mon écran...

Dixit la zarchouillette qui a mis 25 ans pour comprendre le fonctionnement d'une palette de 16 couleurs 

Arrêtes de faire celui qui sait de quoi ils parlent, et retourne faire tes copier/coller, je pense que tu dois avoir une vidéo à faire sur les méchants "amigoloids lololol" non ?
Sinon dès qu'on fera un diner, tu seras le premier invité, promis .

Mais t'inquiètes pas, dès que je vais pouvoir poster des liens, je vais raconter la fabuleuse histoire de "zarchouille et la quette du coding", je vais te chouchouter ma tanche, et quand j'en aurai fini avec toi,tu verras que la napperon c'est pas si mal en fait, pas besoin de réfléchir 

[rocky007]

ok si je suis à côté de la plaque, cites moi u seul jeu sur Amiga qui a un "entrelacement comme à la TV (c) Copper ", c'est à dire avec une trame impair de l'image suivante de 0,02 secondes 

sacré Dlfrsil... oups pardon..Copper..

Pour la 3D on utilise un double buffer ni plus ni point... Et ca ne change pas grand chose en interlace... Même s'il faut évidemment permuter les adresses des bitplanes dans les 2 copperlistes...

ah toi aussi tu fais comme dlfrsilver, tu codes ton moteur 3D  en copperlist ?  

[Copper]

T'es à coté de la plaque comme souvent...

Les jeux entrelacés ne sont pas légion...

Another World le propose je crois...

http://nerdlypleasures.blogspot.com/2013/01/another-world-aka-out-of-this-world.html

[youki]

Ben en fait y'a pas de problèmatique surtout

Par contre on peut t'expliquer le principe d'un double buffer...

Tiens si ca peut t'aider, je trouve l'explication assez claire.  Même Rocky et toi pouvait comprendre...  je ne suis pas sur que vous maitrisiez la chose tout les 2.


Description d'un buffet à deux corps - Type de meuble caractéristique à identifier (meubliz.com)

[Copper]

ah toi aussi tu fais comme dlfrsilver, tu codes ton moteur 3D  en copperlist ?  

Non par contre mon double buffer je change l'adresse des bitplanes dans la copperlist....

Et en interlace on fait 2 copperlist une pour les long frame et une autre pour les short frame...

D'ou le fait de devoir changer les adresses dans les 2 copperlist...

Mais j'imagine bien que tout çà est un peu trop technique pour toi...

[rocky007]

mais t'es complétement bouché ou quoi ?

Je répète :  " "entrelacement comme à la TV (c) Copper ", c'est à dire avec une trame impair de l'image suivante de 0,02 secondes  "

Another World ne tourne pas à 60 FPS, donc je ne vois pas comment il pourrait le faire... bref tu piges rien de rien, ça en devient embarrassant pour toi

[rocky007]

ah toi aussi tu fais comme dlfrsilver, tu codes ton moteur 3D  en copperlist ?  

Non par contre mon double buffer je change l'adresse des bitplanes dans la copperlist....

Et en interlace on fait 2 copperlist une pour les long frame et une autre pour les short frame...

D'ou le fait de devoir changer les adresses dans les 2 copperlist...

Mais j'imagine bien que tout çà est un peu trop technique pour toi...

ah on ne sait pas changer l'adresse des bitplanes sans copperlist sur amiga ?

[Copper]

Mais on s'en fiche ca ne change rien au fait que l'affichage est le même que la télévision...

Et tu mélanges tout évidemment que si tu n'es pas à 50 fps tu n'aura pas l'effet de peigne...

Mais un jeu comme Turbo Sprint peut tout à fait y arriver vu qu'il utilise des sprites hardwares

[Copper]

ah on ne sait pas changer l'adresse des bitplanes sans copperlist sur amiga ?

Si on sait mais utiliser la Copperlist est une meilleure solution...

[rocky007]

ah on ne sait pas changer l'adresse des bitplanes sans copperlist sur amiga ?

Si on sait mais utiliser la Copperlist est une meilleure solution...

donc vu qu'on parle d'interphase, tu suggères que ce jeu utilise 2 copperlists...pour changer l'adresse bitplans ?   amusant

[rocky007]

Mais on s'en fiche ca ne change rien au fait que l'affichage est le même que la télévision...

Et tu mélanges tout évidemment que si tu n'es pas à 50 fps tu n'aura pas l'effet de peigne...

Mais un jeu comme Turbo Sprint peut tout à fait y arriver vu qu'il utilise des sprites hardwares

ben non ce n'est pas le même justement, c'est bien joli de répéter inlassablement que je mélange tout alors que tu es incapable de comprendre la base :

TV : trame pair = image 0    trame impair = image 0,02 sec suivante
AMIGA : trame pair = image 0    trame impaire = image 0

[stapha92]

un truc qui 'oscille entre 12 et 16 bits' dixit ton gourou Meynaf qui n'est que dans l'approximatif, comme tous les médiocres, et bien ce n'est pas 14 bits.

On s'en tamponne, le son fait un sacré bon en avant et c'est ce qui compte, mais comme ton intellect de poule te permet pas de comprendre que le 14bits, c'est surtout la particularité de la technique, technique identique que tu ventes sur ta daube, et qui n'apporte strictement rien .Mais bon je peux pas décemment demander à une huitre de comprendre les bases,c'est foutu .

Tu crois quoi que le 15bits de steve3000 est différent ? 
Toi oui tu le crois, et tu es bien le seul,vu que même son créateur le dit .

Si si il a raison ! C'est bien différent ! Le système de steve30000 permet d'avoir des samples 10 bits : a aucun moment tu vas pouvoir faire mieux. Il additionne 4 canaux qui ont le même volume. ça fait 2 bit de plus c'est tout...

Et l'autre qui rigole en disant 11 bits (ce qui est faux, je suis d'accord avec toi), alors que ce serait déjà 1 de mieux que l'archi...

Et on est bien plus sérieux sur le mig : oui les dacs de cette époque n'étaient pas aussi bon que ceux d'aujourd'hui. C'est pour ça que, sur Amiga, tu peux calibrer le son en fonction de ta machine 
Le pire : il y a des combinaisons qui devraient donner la même chose mais ne le font pas à cause des DACs. Du coup, une calibration va te donner plus de valeurs que les 16 384 valeurs différentes disponibles en 14 bits.

Et ce calibrage est géré par AHI, des tas de programmes l'utiliserons : Le AHI est proposé comme n'importe quelle carte son par l'OS.
(Et ceux qui gèrent le 14 bits en natif peuvent récupérer le calibrage).
Même pour ce genre de hack, les choses sont faites proprement sur mig : os-friendly et mutualisable. Et c'est utilisé du coup. Et il veut comparer ça avec une expérimentation isolée...

[youki]

Et tu mélanges tout évidemment que si tu n'es pas à 50 fps tu n'aura pas l'effet de peigne...

[Invité]

Si si il a raison ! C'est bien différent ! Le système de steve30000 permet d'avoir des samples 10 bits : a aucun moment tu vas pouvoir faire mieux. Il additionne 4 canaux qui ont le même volume. ça fait 2 bit de plus c'est tout...

Je parle évidement de la technique, dont le principe est d'utiliser 2 voix ou plus couplées pour faire mieux que les 8 bits de base, mais au final le résultat est plus ou moins ce qu'on a sur amiga à l'oreille,donc si l'archie était bien meilleurs sur 8 bits, il serait bien meilleurs là aussi, hors ce n'est pas le cas .

Donc si c'est fake sur amiga,ça l'est tout autant sur archimedes .

[YannAros]

For interlaced mode, the video beam scans the screen at the same rate (1/60th of a second per complete NTSC video display field); however, it takes two display fields to form a complete video display picture and twice as much display memory to store line data. During the first of each pair of display fields, the system hardware shows the odd-numbered lines of an interlaced display (1, 3, 5, and so on). During the second display field, it shows the even-numbered lines (2, 4, 6 and so on). The second field is positioned slightly lower so that the lines in the second field are “interlaced” with those of the first field, giving the higher vertical resolution of this mode.

Rien ne t'empêches de soit:
- calculer les deux demis images avec 20msec de delta et de les entrelacer en mémoire, au pire tu auras 20 msec de latence (on est loin de ce qu'on a dans des jeux récents avec parfois plusieurs centaines de msec de latence)
- Calculer la deuxième demi trame pendant l'affichage de la première et écrire dans les lignes correspondantes en mémoire.

[Copper]

De toute façon je sais même pas pourquoi tu nous parles d'interphase...

On utilise 2 Copperlistes pour faire de l'interlace de manière générale

Mais on pourrait très bien faire 2 copperlist pour permuter toutes les bitplanes en une opération...

Mais la méthode normale est plutôt de changer les adresses dans la copperliste

Il n'y a pas qu'une seule façon de faire les choses...

[rocky007]

For interlaced mode, the video beam scans the screen at the same rate (1/60th of a second per complete NTSC video display field); however, it takes two display fields to form a complete video display picture and twice as much display memory to store line data. During the first of each pair of display fields, the system hardware shows the odd-numbered lines of an interlaced display (1, 3, 5, and so on). During the second display field, it shows the even-numbered lines (2, 4, 6 and so on). The second field is positioned slightly lower so that the lines in the second field are “interlaced” with those of the first field, giving the higher vertical resolution of this mode.

Rien ne t'empêches de soit:
- calculer les deux demis images avec 20msec de delta et de les entrelacer en mémoire, au pire tu auras 20 msec de latence (on est loin de ce qu'on a dans des jeux récents avec parfois plusieurs centaines de msec de latence)
- Calculer la deuxième demi trame pendant l'affichage de la première et écrire dans les lignes correspondantes en mémoire.

bien sûr c'est possible, sauf que cela n'existe pas en pratique... tu ne peux faire cela que sur un jeu 50 FPS.
j'imagine mal un jeu 15 FPS dont l'image entrelacée de deux trames décalées dans le temps s’afficherait pendant +-0,3 secondes

[rocky007]

De toute façon je sais même pas pourquoi tu nous parles d'interphase...

On utilise 2 Copperlistes pour faire de l'interlace de manière générale

Mais on pourrait très bien faire 2 copperlist pour permuter toutes les bitplanes en une opération...

Mais la méthode normale est plutôt de changer les adresses dans la copperliste

Il n'y a pas qu'une seule façon de faire les choses...

bref, comme d'habitude tu évites la question 

[Copper]

ben non ce n'est pas le même justement, c'est bien joli de répéter inlassablement que je mélange tout alors que tu es incapable de comprendre la base :

TV : trame pair = image 0    trame impair = image 0,02 sec suivante
AMIGA : trame pair = image 0    trame impaire = image 0

Non justement pendant que la trame pair s'affiche tu as le temps de modifier l'image de la trame impaire... Par exemple l'interruption vblank reste à 50 fps mais ça je ne suis pas sur que tu l'ais compris... Et tu as largement le temps de changer les coordonnées des sprites hardware

[rocky007]

donc je répète, montres moi un jeu qui le fait .. tu m'as cité Another World comme exemple, pas de chance pour toi, il n'y a pas 2 images différentes dans le temps entrelacées..

[Copper]

Another World est le seul jeu en entrelacé que je connaisse... Et d'ailleurs je ne savais même pas que c'était le cas à l'époque.

Mais il n'empêche que c'est possible... Turbo Sprint devrait le faire (ou du moins il aurait sans doute pu )

[youki]

Another World est le seul jeu en entrelacé que je connaisse... Et d'ailleurs je ne savais même pas que c'était le cas à l'époque.

Mais il n'empêche que c'est possible... Turbo Sprint devrait le faire (ou du moins il aurait sans doute pu )

Tiens pour apprendre l'entre lacage ... ya pas mieux...    Tu peux même le faire en 3D!

[rocky007]

Another World est le seul jeu en entrelacé que je connaisse... Et d'ailleurs je ne savais même pas que c'était le cas à l'époque.

Mais il n'empêche que c'est possible... Turbo Sprint devrait le faire (ou du moins il aurait sans doute pu )

on progresse... mais non Another World n'a pas un entrelacement type "TV"

la question n'est pas de savoir si techniquement c'est possible, c'était de contredire ton affirmation que l’entrelacement Amiga était du même type que celui des chaînes TV.
et non ce n'est pas le cas, en usage courant, le principe est complétement différent.

[stapha92]

Tu peux toujours rigoler    
Il s'agissait d'une découverte d'un codeur sur 3DO quant au comportement de l'ARM, dont personne ne connaissait l'existence sur le forum stardot ( donc Sarah non plus ) ... et oui, j'ai encore amélioré mes routines, dont celles de remplissage, avec cette découverte.
Je m'en sers pour le 'wobbling Acorn' dans mon code SOTBish ...
Ah Toukon, tu nous feras toujours rire ... il avance ton 'shoot' en version 'alpha' ?

Arrêtes de raconter n'importe quoi, les sprites/datas compilés existaient bien avant la 3D0;c'était déjà largement utilisé sur ST,surtout par la scène démo .
Après nous les avoir brisées pendant des années sur une technique inventée par ton cerveau malade, maintenant tu l'aurais reprise de la 3DO 
En fait t'es encore plus nul,mytho et débile que je le pensais, 30 ans sur la même routine, et en plus c'est un plagiat 

Tu confonds tout, tu ne comprends rien.
Les 'sprites compilés' il y a moultes manières de les coder sur un Archie, du fait de la grande variété des différentes instructions de transfert registre <-> mémoire de l'ARM.
Je n'ai rien 'repris' sur 3DO concernant les sprites compilés.
J'ai utilisé une découverte d'un codeur sur 3DO, qui fait que tu peux avoir des instructions qui prennent 0 cycle, dans certaines configurations d'enchaînement des instructions ARM.
http://www.verycomputer.com/24_b0ac6730883ec9fe_1.htm
et c'est intéressant à utiliser dans les sprites compilés, mais dans tout ton code en réalité.

En plus compréhensible :
What it's essentially saying is that by positioning an N-cycle instruction (ie STR) at +4 in the Quad word, the instruction following the write won't be converted to an N - as it's an N already.

For example:
CODE: 
[ltr]SELECT ALL[/ltr]

Code:

+0  MOV R0, #2         ;1N   <-   N due to RAS being strobed for the next 4 instructions being fetched
+4  STR R0, [R1], #4   ;2N
+8  ADD R2, R0, #2     ;1S
+C  ADD R1, R1, #&1000 ;1S
+10 MOV R0, #0         ;1N   <-   N due to RAS being strobed for the next 4 instructions being fetched
+14 MOV R3, #0         ;1S

The code above will execute 1 cycle quicker than the code below:
CODE: 
[ltr]SELECT ALL[/ltr]

Code:

+0  MOV R3, #0         ;1N   <-   N due to RAS being strobed for the next 4 instructions being fetched
+4  MOV R0, #2         ;1S
+8  STR R0, [R1], #4   ;2N
+C  ADD R2, R0, #2     ;1S
+10 ADD R1, R1, #&1000 ;1N   <-   N due to RAS being strobed for the next 4 instructions being fetched
+14 MOV R0, #0         ;1N   <-   S becomes an N due to the pipelined STR at +0

Note that these two examples don't show what's actually going on, as the STR is actually a 1S at the time its decoded and only becomes a 2N once the execution stages happen further along in the pipeline. Its just simpler to say it's a 2N up front and ignore the pipeline stages.

T'as rien compris comme d'hab...

Il n'y a pas de 0 cycles. Et aucune découverte. C'est du BABA.

Pour faire simple : lors de la lecture de certaines instructions, l'accès à la mémoire est pénalisé d'un cycle. Pour les autres, il n'y a pas de pénalité.
Tout ça dépend de leur alignement. 
Et il y a des instruction qui entrainent systématiquement cette pénalité (parce qu'elle accèdent à la mémoire).

Tout ce qui est expliqué est qu'il vaut mieux placer ces instruction à un endroit ou il y la pénalité de toute façon. Rien de révolutionnaire. N'importe quel compilateur C fait ce genre de chose tout seul.

T'as juste pas compris. come d'hab...

Et non : il n'y a pas d'instruction à 0 cycles sur ton ARM. ça n'est possible qu'avec les processeurs super-scalaires comme le 68060...

[stapha92]

For interlaced mode, the video beam scans the screen at the same rate (1/60th of a second per complete NTSC video display field); however, it takes two display fields to form a complete video display picture and twice as much display memory to store line data. During the first of each pair of display fields, the system hardware shows the odd-numbered lines of an interlaced display (1, 3, 5, and so on). During the second display field, it shows the even-numbered lines (2, 4, 6 and so on). The second field is positioned slightly lower so that the lines in the second field are “interlaced” with those of the first field, giving the higher vertical resolution of this mode.

Rien ne t'empêches de soit:
- calculer les deux demis images avec 20msec de delta et de les entrelacer en mémoire, au pire tu auras 20 msec de latence (on est loin de ce qu'on a dans des jeux récents avec parfois plusieurs centaines de msec de latence)
- Calculer la deuxième demi trame pendant l'affichage de la première et écrire dans les lignes correspondantes en mémoire.

bien sûr c'est possible, sauf que cela n'existe pas en pratique... tu ne peux faire cela que sur un jeu 50 FPS.
j'imagine mal un jeu 15 FPS dont l'image entrelacée de deux trames décalées dans le temps s’afficherait pendant +-0,3 secondesJe 

ça c'est si tu calcule une demi image à la fois. ça serait idiot et plus couteux.

Tu calcules une seule image avec la résolution verticale cumulée des 2 trames. Au moins toutes les opérations mathématiques ne seront faites qu'une seule fois.

Quand c'est terminé tu bascules les adresses des 2 copperlists : chaque trame sera affichée dès que possible. A la vbl qui suit la fin du rendu et celle d'après.
L'avantage des 2 copperlist est que tu ne t'occupes plus de la demi image suivante. C'est le copper qui bascule tout seul d'une copperlist à l'autre (grace aux branchements qu'il sait faire...). 

Si tu le fais au cpu, il faudra, au moment de basculer la première demi-image placer une interruption pour la demi-image suivante.

Du coup, tes 2 trames restent ensembles pendant les 0.3 secondes pour reprendre ton exemple.

Inutile de préciser que pour le rendu, il n'y aura pas besoin de le faire sur 2 zones mémoire séparées sur le mig . ce qui ferait perdre un peu de temps ou consommerait plus de registres (ce qui revient au meme...).
Tu auras bien une seule zone mémoire, comme pour un affichage en progressif. C'est Denise qui s'occupera de prendre 1 ligne sur 2 dans ton image.