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

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

[stapha92]

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.

Là tu as tout faux Rocky.

C'est exactement le même. Et quand tu utilises un genlock, c'est tellement le même qu'il se mélangent tous les 2...

Y a pas de principes différents...

[stapha92]

T'es juste un jaloux

Non mais sérieux t'as quel âge pour sortir un truc pareil ?? 

Poink, c'est ... personne !

T'es trop marrant la tanche, et bien sur toi tu es quelqu'un ! 
C'est bien ce qu'on dit, les mecs qui ont déjà fait bien plus que des WIP dans leur vie sont nuls, sauf zarchouille, qui n'a découvert qu'en 2008(et encore) comment la palette de l'archie fonctionne . 

Aller rien de mieux qu'un petit état des lieux de ton niveau : 
*ttps://atari-forum.com/viewtopic.php?p=338802#p338802

il y a quand même un jeu que tu le veuilles où non...

Exact, aussi basique qu'il soit, ça reste un jeu, avec tout ce qui caractérise un jeu en terme d'éléments .

D'ailleurs je l'ai bien mouché dans la file de discussions où il ose la ramener, pour disparaître à tout jamais dans le néant, where he belongs ..

 tu as mouché rien du tout, qd un mec te met face à tes contradictions, tu te lances dans l'insulte et le NAWAK pour éviter de répondre précisément à ce qu'il te demande,la preuve, t'es toujours pas foutu de proposer autres choses qu'une merde de WIP sans consistance, preuve que tu es un naze est rien d'autre 
D'ailleurs ça serait bien de mettre le lien vers la discussion qu'on rigole .

Et que le trou de balle dans l'histoire il n'y en a toujours eu qu'un ,et c'est bien zarchouille . 

Si tu l'écoutes ma démo avec les boules est impossible en 50 fps, le code WIP SOTB également, idem pour le scroll vertical full overscan ...

T'as toujours pas compris qu'on s'en bat les couilles de ça, et que ça n'apporte rien, que dalle ton code taillé pour ta démo pourrie avec des GFX identiques(si ça c'est pas beau), nous on veut du jeu,vu que c'est précisément là ,où tu te poses toi et ta machine en killer d'amiga, chose que tu n'es absolument pas capable de produire, c'est même pas une opinion ça fait déjà bien longtemps qu'on sait tous que c'est une réalité .
D'ailleurs le fait que tu te cherches des petits copains à droite à gauche dans tous les forum, en est une preuve de plus 
Pas besoin d'être un génie pour comprendre que 8 mhz+ bus 32 bits est plus rapide qu'un blitter 16 bits @3.5mhz, mais c'est qd tu fais pleins de choses en même temps que ça change la donne, et là ton intellect limité te permet pas de le comprendre .
Si tu veux des amis, essayes la prison,t'en trouveras tout plein là bas . 

2011 les gars :

Xavier

23 août 2011, 08:58:09

à
Hello.
I'm speaking here about the pre RISC PC series, with the 1st VIDC, so
yes that's the good old Archimedes series and the A30x0 series.

I'm a bit surprised to find different explanations about the 8 bit per
pixel 256 colour screen modes on these machines. (mode 13 and mode 15
for example).
On the one hand, I read the palette can be redefined in groups of 16,
and on the other hand that you can define 64 colours freely chosen
from 4096, and automatically 3 tints appear for each of these freely
chosen 64 colours.

What is the truth ?
Isn't it uncorrect to refer to the palette of these 256 colour screen
modes on these machines as 'fixed' if you can alter it, even if it
gives you a headache as it's impossible to get exactly what you want ?


Additionaly, I'd like to know if there is an application, or a piece
of code somewhere, to help one pick up the colours to define one's own
palette.
Thanks for your help.

Et c'est en 2012 qu'il a publié l'extrait de la doc qui explique tout sur gamopat. 
Et je lui ai expliqué comment ça marche alors que je ne connaissais pas la machine.
Et c'est pas exploit ! la doc est très claire. C'est juste qu'il pige rien...

Je viens juste d'en parler :

https://www.gamopat-forum.com/t113986p310-acorn-archimedes-3010-co#3552834


edit :
Et non, même pas : son ARM n'est pas forcément plus rapide que le blitter.
Pour une copie brute y a pas photo. Encore heureux pour une machine 2x plus chère.

Mais pour des sprites par exemples (c'est ce dont on parle), ça ne suit plus :
Le blitter peut lire 3 sources, appliquer des opération entre les 3, faire des décalage sur 2 d'entre elles (avec passages des bits perdu d'un registre à l'autre, là ça devient couteux mêe sur ARM) et écrire le résultat en protégeant le début et la fin de la ligne. Il va gérer les compteurs de pixel et de lignes.
Il a un pipeline et il parvient à faire tout ça uniquement pour le cout des lectures/écritures.

Meme si son ARM tournait tout le temps à 8 Mhz, il ne suivrait pas. Et ce n'est pas le cas, à cause de sa mémoire "fast-page" :
 - En lecture d'instructions séquentielle 1 lecture sur 4 prend un cycle de plus (dès qu'on change de page). C'est comme si son ARM tournait à 6, 4 Mhz.
 - A chaque branchement, on perd un cycle aussi. (En plus le pipeline est vidé : jusqu'à 3 cycles de perdus. Mais la vitesse de l'arm n'est pas modifiée).
 - Quand on fait une lecture ou une écriture (c'est un peu le sujet), ça sort de la page. Donc l'instruction perd 1 cycle avant d'accéder ou d'écrire la donnée. et l'instruction suivante en perd 1 aussi puisque la ram change encore de page.
 - Quand un autre circuit accède à la RAM, l'ARM est carrément bloqué et quand il reprend la main hop : 1 cycle de perdu en plus.

Pour afficher l'image, le circuit vidéo accède à la RAM en 32 bits et optimise l'utilisation des pages en en traitant une entière à chaque fois. 
Un écran en 320x200 en 16 couleurs prend 32 000 octets. Ce qui fait 2 000 pages (1 page fait 16 octets). Et il faut 5 cycles pour chacune (1 cycle de pénalité + 4 lectures de 32 bits). Donc 10 000 cycles par frame. Ou 500 000 par secondes.

Donc un programme sans branchement, sans lecture ou écriture de données avec un affichage en 320x200x16 tourne à 5,9 Mhz réels.
Quand tu rajoutes le reste, les 8 Mhz sont bien loin...

[Jacques Atari]

Ce que c'est devenu chiant ce topic... 

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

Là tu as tout faux Rocky.

C'est exactement le même. Et quand tu utilises un genlock, c'est tellement le même qu'il se mélangent tous les 2...

Y a pas de principes différents...

Et non tu as encore deux, ça devient une fâcheuse  habitude

[Copper]

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.

Tu te trompes... L'entrelacement est forcément le même que la TV vu que c'est le même principe... C'est obligé...

Ca n'a pas de sens ton histoire d'usage courant...

La question est clairement de savoir si c'est techniquement possible et pour Turbo Sprint s'il utilise des sprites hardware ça serait étonnant que ca ne soit pas possible... Sauf si le moteur de jeu est trop complexe pour tourner à 50 fps mais ca m'étonnerait...

[stapha92]

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.

Là tu as tout faux Rocky.

C'est exactement le même. Et quand tu utilises un genlock, c'est tellement le même qu'il se mélangent tous les 2...

Y a pas de principes différents...

Et non tu as encore deux, ça devient une fâcheuse  habitude

Et bien expliques nous donc c'est quoi les 2 principes qui existent.

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

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.

Là tu as tout faux Rocky.

C'est exactement le même. Et quand tu utilises un genlock, c'est tellement le même qu'il se mélangent tous les 2...

Y a pas de principes différents...

Et non tu as encore deux, ça devient une fâcheuse  habitude

Et bien expliques nous donc c'est quoi les 2 principes qui existent.

Il est le bon principe...et il y a le mauvais principe... c'est comme les chasseurs... Le bon principe, ben il est bon... et le mauvais.. voilà.. c est simple..

[stapha92]

De toute façon avec SOTB en général on ne voit que des demos jamais le jeu complet (et c'est un peu ridicule quand même car en fait ca n'a aucun intéret)

Oui car le but n'est pas de refaire le jeu, mais de montrer la faisabilité en collant au plus près de ce que serait le jeu complet .
Avec zarkouille c'est aussi proche que la distance terre->mars, donc forcément faut avoir une sacrée imagination pour y voir ne serait ce qu'un atome d'un jeu . 

T'as pas l'air de comprendre que je m'en branle.
L'Archie c'est juste une petite distraction dans la masse d'intérêts et de projets que j'ai ailleurs.

Ce mec est de plus en plus marrant,surtout que c'est exactement ce que tout le monde a constaté(zarchouille n'en parle jamais,et surtout ne fait que quelques vidéos), et son niveau en coding en témoigne aussi 

T'es juste un jaloux, Toukon, ah ah ah ça me fait marrer, t'as pas idée 

Tiens, regarde à nouveau ce que jamais ton mig, sur lequel tu aimes te pignoler, ne saura faire :


Ni un 500 ni un 1200 ne peuvent en faire autant, c'est trop drôle !

Bien sur...

Tu peux nous faire des VRAIS sprites ? C'est à dire : différents, avec des trous, et sans prendre des Mo  ?

Le ST a un record plus élevé que le tien. Je ne parle même pas du mig.
Evidemment, il y a moins de couleurs mais les bitplans complexifient ce genre de chose. Avec du chunky, un ST pourrait faire pareil.

L'affichage chunky a des avantage que tu attribues à l'ARM par ignorance. 

Faisons l'inverse : prenons un cas ou le bitplans est favorisé, comme pour les effets de transparence.

Reproduis ça avec ton Archimede (à 2 minutes). Pas compliqué mais tu es incapable d'y arriver :



Quand tu auras terminé. Je te montrerai d'autres effets de transparence sur 1200...
J'y vais doucement...

[The_Real_Zarchos]

Rien à voir avec les records sur le ST où tout est précalculé, positions d'affichage et zones optimisées d'effacement en évitant les recouvrements ... et tu le sais très bien.
Rien de tout ça chez moi.

Tu as tj été de mauvaise foi, mais avant c'était plus fin.
Tu vieillis, Stapha ...

[rocky007]

Tu te trompes... L'entrelacement est forcément le même que la TV vu que c'est le même principe... C'est obligé...

je vais pas passer posts après posts à répéter à l'infini la même chose... sur TV, le flux est constant, donc systématiquement tu auras images 0 sec + images 0.02 sec entrelacées... dans mon exemple d'Interphase, la plupart des images auront des trames identiques, tu ne peux pas faire autrement.
donc non, ce n'est pas la même chose.

[rocky007]

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.

et donc pendant 0.3 secondes tu auras une image dégueulasse avec un effet peigne jusqu'à la prochaine image dégueulasse.  c'est bien ce que tu suggères ?  le tout avec un lag encore + important

[Invité]

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

Ah, lequel ? celui de dans 100 ans ? 
T'as déjà mis 30 ans pour étudier le concept, crois tu arriver à faire une map avant la fin du monde ? 

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.

Bien vu stapha92, donc en 2012 tu savais toujours pas comment marchait la palette, c'est énorme .

On est dans 'autre chose', beaucoup plus zarbie.

Effectivement on est dans la dimension ZARCHOUILLE,celle où règne la bêtise . 

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

J'espère que tu sais depuis que les 2 n'ont absolument pas la même fonction ni utilisation ? ,et donc ne sont pas comparables .
Certes un timer peut faire une pseudo Hsync, mais pas avec la même précision,et encore moins avec le même nombre de cycles .

[dlfrsilver]

Ce que c'est devenu chiant ce topic... 

C'est normal, avec ton humour de fonctionnaire de mes couilles, si seulement t'avais le talent de Coluche 

[dlfrsilver]

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

Ah, lequel ? celui de dans 100 ans ? 
T'as déjà mis 30 ans pour étudier le concept, crois tu arriver à faire une map avant la fin du monde ? 

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.

Bien vu stapha92, donc en 2012 tu savais toujours pas comment marchait la palette, c'est énorme .

On est dans 'autre chose', beaucoup plus zarbie.

Effectivement on est dans la dimension ZARCHOUILLE,celle où règne la bêtise . 

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

J'espère que tu sais depuis que les 2 n'ont absolument pas la même fonction ni utilisation ? ,et donc ne sont pas comparables .
Certes un timer peut faire une pseudo Hsync, mais pas avec la même précision,et encore moins avec le même nombre de cycles .

La dimension Zarchouille, la dimension qui part en couilles 

[rocky007]

La dimension Zarchouille, la dimension qui part en couilles 

ouf, heureusement que tu es là pour relever le niveau

[dlfrsilver]

La dimension Zarchouille, la dimension qui part en couilles 

ouf, heureusement que tu es là pour relever le niveau

Ah tiens notre petit buveur d'eau chaude le voilà 

[Copper]

je vais pas passer posts après posts à répéter à l'infini la même chose... sur TV, le flux est constant, donc systématiquement tu auras images 0 sec + images 0.02 sec entrelacées... dans mon exemple d'Interphase, la plupart des images auront des trames identiques, tu ne peux pas faire autrement.
donc non, ce n'est pas la même chose.

On s'en fiche de ton exemple d'interphase c'est toi qui a sorti cet exemple à la con... On parlait de Turbo Sprint à la base

D'autre part la TV peut très envoyer plusieurs fois la même image (la mire par exemple à l'époque ) ca restera de l'entrelacé qu'un Amiga aurait d'ailleurs aucun mal à faire (en overscan qui plus est)

Enfin les 2 demi-images ne sont pas identiques de toute façon car sinon ca n'aurait aucun intérêt d'utiliser l'entrelacé...

[rocky007]

ben mon exemple est parfait pour te prouver que tu as tort.

 on dirait que tu viens enfin de comprendre, en effet la mire TV s'affichera comme l'Amiga le ferait

Enfin les 2 demi-images ne sont pas identiques de toute façon car sinon ca n'aurait aucun intérêt d'utiliser l'entrelacé...

évidement, c'est bien pour cela que j'ai toujours bien précisé la temporalité des 2 trames, c'est là toute la différence..et c'est ce qui t"échappe toujours

tu veux que je te dédicace ta bible Amiga ?

[stapha92]

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.

et donc pendant 0.3 secondes tu auras une image dégueulasse avec un effet peigne jusqu'à la prochaine image dégueulasse.  c'est bien ce que tu suggères ?  le tout avec un lag encore + important

Tu lis trop en diagonale. J'explique justement comment éviter un effet peigne.

Imagines un truc en 10 trames/secondes. ça serait en fait du 5 image seconde. tu es en 5 vbl quoi. Tu calcule pendant 5 vbl l'image avec 400 ignes. A la 6eme vbl tu affiches les 200 lignes paires et à la 7eme les 200 lignes impaires. Elles restent ensembles jusqu'à la prochaine image. Pas d'effet de peigne.
Et le lag sera bien plus court qu'avec 2 images : toute la trigo et les projections ne seront fait qu'une fois.

Tu lis trop vite et tu comprend l'inverse de ce qui est expliqué.

[rocky007]

je suis d'accord avec toi, dans ton exemple il n'y a pas d'effet peigne et par conséquent on n'est pas dans donc pas  un entrelacement "type TV" ( un entrelacement de 2 trames ayant une temporalité différente )...

[oiseau de proie]

Rien à voir avec les records sur le ST où tout est précalculé, positions d'affichage et zones optimisées d'effacement en évitant les recouvrements ... et tu le sais très bien.
Rien de tout ça chez moi.

Tu as tj été de mauvaise foi, mais avant c'était plus fin.
Tu vieillis, Stapha ...

D'autant plus que les records qui ont plus de boules sont en 16x16 3 couleurs, effectivement c'est clairement pas comparable.
J'aime bien cette histoire de record, cette volonté de toujours faire mieux et tout ce que fait Leonard mais je vois pas trop comment ce serait exploitable dans un jeu...
Les records de Bobs 32x32 sur ST et Amiga sont au Blitter car même en code généré (au cpu) on ne peut pas faire mieux et on est pourtant à des années lumières de ce que je vois sur ta démo.
Tu mettrais des trous un peu partout sur des sprites, il y en aurait certes moins affichés mais ça changerait pas les données du problème, il y aurait encore un gouffre avec les machines américaines.

La seule bécane qui pourrait battre l'Archimedes serait ironiquement... un PC avec le fameux mode X de la carte VGA (sorti la même année que l'Archimedes !) La seule inconnue reste avec quel CPU !
A bien y réfléchir, 1987 est une année charnière dans ce domaine où les Amiga et autres ST sont technologiquement dépassés par les Archimedes, X68000, PC/VGA !

[dlfrsilver]

Rien à voir avec les records sur le ST où tout est précalculé, positions d'affichage et zones optimisées d'effacement en évitant les recouvrements ... et tu le sais très bien.
Rien de tout ça chez moi.

Tu as tj été de mauvaise foi, mais avant c'était plus fin.
Tu vieillis, Stapha ...

D'autant plus que les records qui ont plus de boules sont en 16x16 3 couleurs, effectivement c'est clairement pas comparable.
J'aime bien cette histoire de record, cette volonté de toujours faire mieux et tout ce que fait Leonard mais je vois pas trop comment ce serait exploitable dans un jeu...
Les records de Bobs 32x32 sur ST et Amiga sont au Blitter car même en code généré (au cpu) on ne peut pas faire mieux et on est pourtant à des années lumières de ce que je vois sur ta démo.
Tu mettrais des trous un peu partout sur des sprites, il y en aurait certes moins affichés mais ça changerait pas les données du problème, il y aurait encore un gouffre avec les machines américaines.

La seule bécane qui pourrait battre l'Archimedes serait ironiquement... un PC avec le fameux mode X de la carte VGA (sorti la même année que l'Archimedes !) La seule inconnue reste avec quel CPU !
A bien y réfléchir, 1987 est une année charnière dans ce domaine où les Amiga et autres ST sont technologiquement dépassés par les Archimedes, X68000, PC/VGA !

Le X68000 est hors de portée de l'occidental moyen même avec un salaire d'ingé, et le PC VGA est impossible à acquérir en 1987 pour un particulier. 

Donc rien à battre & rien à foutre 

Les oranges, les pommes, les bananes (les Aut(ari)istes hein) 

[dlfrsilver]

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.

et donc pendant 0.3 secondes tu auras une image dégueulasse avec un effet peigne jusqu'à la prochaine image dégueulasse.  c'est bien ce que tu suggères ?  le tout avec un lag encore + important

Tu lis trop en diagonale. J'explique justement comment éviter un effet peigne.

Imagines un truc en 10 trames/secondes. ça serait en fait du 5 image seconde. tu es en 5 vbl quoi. Tu calcule pendant 5 vbl l'image avec 400 ignes. A la 6eme vbl tu affiches les 200 lignes paires et à la 7eme les 200 lignes impaires. Elles restent ensembles jusqu'à la prochaine image. Pas d'effet de peigne.
Et le lag sera bien plus court qu'avec 2 images : toute la trigo et les projections ne seront fait qu'une fois.

Tu lis trop vite et tu comprend l'inverse de ce qui est expliqué.

Et avec ça, Jean-Calculerien ose se foutre de ma gueule, l'hopital, la charité, toussa.... 

[stapha92]

Rien à voir avec les records sur le ST où tout est précalculé, positions d'affichage et zones optimisées d'effacement en évitant les recouvrements ... et tu le sais très bien.
Rien de tout ça chez moi.

Tu as tj été de mauvaise foi, mais avant c'était plus fin.
Tu vieillis, Stapha ...

L'affichage que tu utilises ne s'appuie pas sur du code généré ? C'est la même chose que sur ST. 
Ou tu parles des coordonnées des sprites ? Voyons ! C'est un déplacement linéaire, ça va plus vite des les calculer !

Et tes routines, elles sont pas présentes plusieurs fois en fonction de l'alignement ?
Et s'il y a des trous dans tes sprites, ça déscend à combien ? (Affiche nous les lettres de l'alphabet par exemple)
Et si les sprites sont différents ? ça donne quoi ?


Parce que le petit exemple d'utilisation du blitter dont tu te moquais fait tout ça. Du coup, lui est utilisable dans un jeu...
Et le petit exemple sur 1200 qui a été posté en fait bien plus.

Autre cas ou le chunky est moins bon que le planar : fais le même algo en variant leur couleur pour qu'il y ait plusieurs dégradés différents. Mais fais ça en stockant la source dans une seule couleur. Pas en stockant le sprite dans chaque couleur (pour que ce soit utilisable dans un jeu). Quasiment aucun surcout en planar et un surcout enorme en chunky (là il faut faire plusieurs opérations sur chaque pixel...).

Comme quoi comparer avec un exemple ne prouve rien. Même si ton exemple est interessant.
Il faut comparer des éléments complets. Comme on est sur Gamopat, il faut comparer des jeux ou des moteurs de jeu. 

Un A500 peut afficher 128 sprites de 16x16 (différents, avec la gestion des trous et tout le toutim) en consomnant 1% de cpu, 0 % de blitter et 0% de copper dans un ecran en 320x256. Rien que ça est bien au-dessus de ton record en 8 Mhz (vu que là ce sont des vrais sprites...)
Mais ils seront limités à 8 par lignes. Comme je disais, un exemple seul n'est pas toujours significatif...

[dlfrsilver]

Rien à voir avec les records sur le ST où tout est précalculé, positions d'affichage et zones optimisées d'effacement en évitant les recouvrements ... et tu le sais très bien.
Rien de tout ça chez moi.

Tu as tj été de mauvaise foi, mais avant c'était plus fin.
Tu vieillis, Stapha ...

L'affichage que tu utilises ne s'appuie pas sur du code généré ? C'est la même chose que sur ST. 
Ou tu parles des coordonnées des sprites ? Voyons ! C'est un déplacement linéaire, ça va plus vite des les calculer !

Et tes routines, elles sont pas présentes plusieurs fois en fonction de l'alignement ?
Et s'il y a des trous dans tes sprites, ça déscend à combien ? (Affiche nous les lettres de l'alphabet par exemple)
Et si les sprites sont différents ? ça donne quoi ?


Parce que le petit exemple d'utilisation du blitter dont tu te moquais fait tout ça. Du coup, lui est utilisable dans un jeu...
Et le petit exemple sur 1200 qui a été posté en fait bien plus.

Autre cas ou le chunky est moins bon que le planar : fais le même algo en variant leur couleur pour qu'il y ait plusieurs dégradés différents. Mais fais ça en stockant la source dans une seule couleur. Pas en stockant le sprite dans chaque couleur (pour que ce soit utilisable dans un jeu). Quasiment aucun surcout en planar et un surcout enorme en chunky (là il faut faire plusieurs opérations sur chaque pixel...).

Comme quoi comparer avec un exemple ne prouve rien. Même si ton exemple est interessant.
Il faut comparer des éléments complets. Comme on est sur Gamopat, il faut comparer des jeux ou des moteurs de jeu. 

Un A500 peut afficher 128 sprites de 16x16 (différents, avec la gestion des trous et tout le toutim) en consomnant 1% de cpu, 0 % de blitter et 0% de copper dans un ecran en 320x256. Rien que ça est bien au-dessus de ton record en 8 Mhz (vu que là ce sont des vrais sprites...)
Mais ils seront limités à 8 par lignes. Comme je disais, un exemple seul n'est pas toujours significatif...

Autant de sprites en 16x16 ? ahahah, il se défend rudement bien l'Amiga et en 320x256 en plus.

Je serais curieux de savoir combien peut en balancer un ST tiens en 320x200 :)

[stapha92]

Rien à voir avec les records sur le ST où tout est précalculé, positions d'affichage et zones optimisées d'effacement en évitant les recouvrements ... et tu le sais très bien.
Rien de tout ça chez moi.

Tu as tj été de mauvaise foi, mais avant c'était plus fin.
Tu vieillis, Stapha ...

D'autant plus que les records qui ont plus de boules sont en 16x16 3 couleurs, effectivement c'est clairement pas comparable.
J'aime bien cette histoire de record, cette volonté de toujours faire mieux et tout ce que fait Leonard mais je vois pas trop comment ce serait exploitable dans un jeu...
Les records de Bobs 32x32 sur ST et Amiga sont au Blitter car même en code généré (au cpu) on ne peut pas faire mieux et on est pourtant à des années lumières de ce que je vois sur ta démo.
Tu mettrais des trous un peu partout sur des sprites, il y en aurait certes moins affichés mais ça changerait pas les données du problème, il y aurait encore un gouffre avec les machines américaines.

La seule bécane qui pourrait battre l'Archimedes serait ironiquement... un PC avec le fameux mode X de la carte VGA (sorti la même année que l'Archimedes !) La seule inconnue reste avec quel CPU !
A bien y réfléchir, 1987 est une année charnière dans ce domaine où les Amiga et autres ST sont technologiquement dépassés par les Archimedes, X68000, PC/VGA !

300 boules en 3 couleur ne se comparent pas avec 150 boules en 15 couleurs ? Parce que c'est la même quantité de données avec 2 fois moins de calcul de coordonnées.

Avec un Archimedes à 8 Mhz, la démo affiche 151 boules. C'est pas si incomparable que ça.

[oiseau de proie]

Ce sont des sprites de 32x32 les records de Bob, pas de 16x16 et pas non plus le même nombre de couleurs avec des techniques qui n'ont rien à voir car totalement inutilisable dans un jeu.
Et jamais au grand jamais tu n'afficheras 151 bobs de 32x32 en 15 couleurs avec le Blitter. On est a mille lieux de ça.

[oiseau de proie]

Rien à voir avec les records sur le ST où tout est précalculé, positions d'affichage et zones optimisées d'effacement en évitant les recouvrements ... et tu le sais très bien.
Rien de tout ça chez moi.

Tu as tj été de mauvaise foi, mais avant c'était plus fin.
Tu vieillis, Stapha ...

D'autant plus que les records qui ont plus de boules sont en 16x16 3 couleurs, effectivement c'est clairement pas comparable.
J'aime bien cette histoire de record, cette volonté de toujours faire mieux et tout ce que fait Leonard mais je vois pas trop comment ce serait exploitable dans un jeu...
Les records de Bobs 32x32 sur ST et Amiga sont au Blitter car même en code généré (au cpu) on ne peut pas faire mieux et on est pourtant à des années lumières de ce que je vois sur ta démo.
Tu mettrais des trous un peu partout sur des sprites, il y en aurait certes moins affichés mais ça changerait pas les données du problème, il y aurait encore un gouffre avec les machines américaines.

La seule bécane qui pourrait battre l'Archimedes serait ironiquement... un PC avec le fameux mode X de la carte VGA (sorti la même année que l'Archimedes !) La seule inconnue reste avec quel CPU !
A bien y réfléchir, 1987 est une année charnière dans ce domaine où les Amiga et autres ST sont technologiquement dépassés par les Archimedes, X68000, PC/VGA !

Le X68000 est hors de portée de l'occidental moyen même avec un salaire d'ingé, et le PC VGA est impossible à acquérir en 1987 pour un particulier. 

Donc rien à battre & rien à foutre 

Les oranges, les pommes, les bananes (les Aut(ari)istes hein) 

On parle de technique, d'affichage de sprites, de code, rien à voir avec tes histoires de prix, t'es totalement hors sujet !
Mais bien essayé ta technique de diversion 

[stapha92]

Rien à voir avec les records sur le ST où tout est précalculé, positions d'affichage et zones optimisées d'effacement en évitant les recouvrements ... et tu le sais très bien.
Rien de tout ça chez moi.

Tu as tj été de mauvaise foi, mais avant c'était plus fin.
Tu vieillis, Stapha ...

L'affichage que tu utilises ne s'appuie pas sur du code généré ? C'est la même chose que sur ST. 
Ou tu parles des coordonnées des sprites ? Voyons ! C'est un déplacement linéaire, ça va plus vite des les calculer !

Et tes routines, elles sont pas présentes plusieurs fois en fonction de l'alignement ?
Et s'il y a des trous dans tes sprites, ça déscend à combien ? (Affiche nous les lettres de l'alphabet par exemple)
Et si les sprites sont différents ? ça donne quoi ?


Parce que le petit exemple d'utilisation du blitter dont tu te moquais fait tout ça. Du coup, lui est utilisable dans un jeu...
Et le petit exemple sur 1200 qui a été posté en fait bien plus.

Autre cas ou le chunky est moins bon que le planar : fais le même algo en variant leur couleur pour qu'il y ait plusieurs dégradés différents. Mais fais ça en stockant la source dans une seule couleur. Pas en stockant le sprite dans chaque couleur (pour que ce soit utilisable dans un jeu). Quasiment aucun surcout en planar et un surcout enorme en chunky (là il faut faire plusieurs opérations sur chaque pixel...).

Comme quoi comparer avec un exemple ne prouve rien. Même si ton exemple est interessant.
Il faut comparer des éléments complets. Comme on est sur Gamopat, il faut comparer des jeux ou des moteurs de jeu. 

Un A500 peut afficher 128 sprites de 16x16 (différents, avec la gestion des trous et tout le toutim) en consomnant 1% de cpu, 0 % de blitter et 0% de copper dans un ecran en 320x256. Rien que ça est bien au-dessus de ton record en 8 Mhz (vu que là ce sont des vrais sprites...)
Mais ils seront limités à 8 par lignes. Comme je disais, un exemple seul n'est pas toujours significatif...

Autant de sprites en 16x16 ? ahahah, il se défend rudement bien l'Amiga et en 320x256 en plus.

Je serais curieux de savoir combien peut en balancer un ST tiens en 320x200 :)

Oui mais ce n'est pas utilisable. Un amiga possède 8 sprites qui font toute la hauteur de l'écran et qui peuvent se multiplexer tous seuls. Donc s'il font 16 lignes, chaque sprite se divise en 16. Mais il n'y en aura toujours que 8 par lignes.

Une mégadrive affiche, si je me souviens bien, 80 sprites. Mais elle, c'est 20 par lignes. Le mig est largué sur ce point. Comme quoi, les chiffres...

Dans risky woods par exemple, il y a un layer complet en 16 couleurs fait uniquement de sprites. Un écran entier rempli de sprites ! ça en fait plus de 300 ! et il y a un jeu qui tourne avec tout ça (y compris des sprites...).
Mais ça ne change rien, c'est un cas particulier encore.

Et le mig va a la même vitesse quel que soit la taille de l'écran quand on est en 16 couleurs. 
Le ST ne peut pas adapter sa résolution mais lui aussi ne perd aucun cycle pour l'affichage.
Ce n'est pas le cas de l'Archi. 

Sinon, en sprite software, donc sans limite par ligne, le record sur ST est de plus de 300. 
.

[stapha92]

Ce sont des sprites de 32x32 les records de Bob, pas de 16x16 et pas non plus le même nombre de couleurs avec des techniques qui n'ont rien à voir car totalement inutilisable dans un jeu.
Et jamais au grand jamais tu n'afficheras 151 bobs de 32x32 en 15 couleurs avec le Blitter. On est a mille lieux de ça.

Je suis au courant, merci. Je connais 2 ou 3 trucs sur le mig...

Mais la démo affichée sur l'archimedes est à mille lieux de ce qui est exploitable dans un jeu aussi...