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

[stapha92]

Ouais ouais ouais.
Vous voyez des démos mais ne les comprenez pas
Vous êtes encore plus diminués que je ne le pensais.
Probablement je vous donnerai un petit cours cette semainede début octobre.
D'ici là :
- regardez ma p'tite démo jusqu'au bout
- relisez mon explication donnée à Stapha car elle est parfaite
- allez sur le site de Leonard, tout ce qu'il explique confirme ce que j'ai écrit sur la manière dont les records sont atteints sur ST et mig

Ah, au fait, des boules en 32x32 15 couleurs ce ne sont ni des étoiles ni des boules en 16x16  3 ou 4 couleurs.

Bisous les poux.

Oui je sais bien merci. Mais les coordonnées d'une étoile et d'une boule en 15 ou en 3 couleurs sont les mêmes.
C'est toi qui est allé sur le terrain du calcul des coordonnées...
Oui on ne comprend rien. J'imagine que l'on tire des conclusions hatives...
Mais corrige donc ça : montre nous que c'est utilisable dans un jeu : que ça prenne pas beaucoup de mémoire, avec des sprites différents, de n'importe quel forme (et donc avec des trous) et une restauration (ou n'importe quelle méthode pour préserver le fond).

Tiens, ça me donne une idée en parlant de préserver le fond :
Avec un mode chunky 256 couleurs tu peux simuler 2 plans de 16 couleurs. Dans chaque octet, tu réserves les 4 premiers bits pour le plan du fond et les 4 suivants pour celui de devant. Tu stocke tes éléments a appliquer au premier plan (que ce soit des tiles ou des sprites) en prenant un octet par pixel et en laissant les 4 premiers bits à 0. Quand tu veux appliquer un élément sur le fond, tu fais un OR entre les 2. Et tu le feras pour 4 pixels à la fois en 32 bits.
Il faudra arranger la palette pour que toutes les combinaisons qui sont identiques pour les 4 bits de fin aient la même couleur sauf pour la combinaison 0000 pour laquelle tu définie les 16 couleurs de fond. Il te reste 15 couleurs qui sont répétées 16 fois dans la palette aux bonnes position. Ce sont les 15 couleurs du premier plan.
Et tu peux aller plus loin : tu peux définir un effet de transparence. Au lieu que les 16 couleurs soient identiques, tu y place les bonnes combinaisons et le tour est joué. Plus foncé, plus clair, plus rouge, etc... : tu appliques l'effet de transparence que tu veux gratuitement.

C'est beaucoup plus simple avec du planar mais au prix de tiles/sprites qui prendront plus de place, tu peux faire des choses bien.

Ah mais attend ! C'est impossible sur l'Archimedes vu que tu ne choisis pas ta palette ! Quel dommage...
Ah trop con : ça t'aurait tellement aidé pour faire le niveau souterrain de SOTB sans prendre 16 Mo de ram...

[The_Real_Zarchos]

Merci pour ta solution qui ne marche pas 🥱
Je vais garder la mienne, qui marche.
Et l'ensemble tournera sans problème sur un Archie avec 2 Mo ( bien plus standard qu'un mig 1 Mo ).
Tu m'as encore fait rire.

A nouveau, relis ce que j'ai écrit et passe sur le site de Leonard, peut etre qu'ainsi te pousseront quelques neurones.
Tu n'as tj pas compris ce que sont les coordonnées dans les démos record st et mig, et ce qu'elles sont dans ma démo avec 251 bouboules ... 
Pour l'arrière plan non plus tu n'as pas pigé.
c'est juste triste ( m'enfin, pour toi. Tu resteras idiot, c'est ton problème après tout ).

[rocky007]

se résume à un algo du genre :

y += dy;
if (y == 0 or y == 255) {dy = -dy};
x += dx;
if (x == 0 or x == 319) {dx = -dx};

dommage que ton algo ne fonctionne pas si par exemple Dy=2, c'est pourtant le plus vieux et simple algo de jeux video  

[Invité]

Un petit &255 et un &319 règlent le problème . 

[stapha92]

Merci pour ta solution qui ne marche pas 🥱
Je vais garder la mienne, qui marche.
Et l'ensemble tournera sans problème sur un Archie avec 2 Mo ( bien plus standard qu'un mig 1 Mo ).
Tu m'as encore fait rire.

A nouveau, relis ce que j'ai écrit et passe sur le site de Leonard, peut etre qu'ainsi te pousseront quelques neurones.
Tu n'as tj pas compris ce que sont les coordonnées dans les démos record st et mig, et ce qu'elles sont dans ma démo avec 251 bouboules ... 
Pour l'arrière plan non plus tu n'as pas pigé.
c'est juste triste ( m'enfin, pour toi. Tu resteras idiot, c'est ton problème après tout ).

Donc tout ce que tu sais faire,  c'est dire : "t'as tout faux" "t'as rien cmpris" "tu piges pas"
Et si tu donnais 1 argument pour une fois ? Une explication de ce sur quoi j'ai tort ?
Pauvre imbécile que tu es... (tu as commencé à me traiter d'idiot : je me met à ton niveau)

Et n'as tu pas avoué que tu pigeais rien à la doc des couleurs ? Ne m'as tu pas accusé d'avoir désassemblé ton code ?
Tes sprites ne sont-ils pas du code généré qui prend plein de ram ?
N'as-tu pas dit qu'avec ton super timer (pas synchro avec l'affichage de ton archimerde) tu voulais faire du remplissage de ligne en changeant le pointeur video ?
N'as tu pas dit que "quelqu'un" avait découvert qu'une instruction pouvait prendre 0 cycle ?

Et qu'est-ce qui est faux dans "le calcul des coordonnées ne prend pas grand chose dans les records de bobs" ?
Expliques nous donc ? Pas d'autres disque que "tu comprends rien ?"

Moi par contre, tout ça je te l'ai renvoyé en pleine poire avec des explications et/ou des exemples. Tu n'as jamais répondu avec UN argument...

Tu te prends pour un génie mais tu nous as montré des tas d'exemples de doc ou de discussion et tu as soit :
- admis ne rien comprendre
- donné une explication foireuse (0 cycles :  ).

[The_Real_Zarchos]

se résume à un algo du genre :

y += dy;
if (y == 0 or y == 255) {dy = -dy};
x += dx;
if (x == 0 or x == 319) {dx = -dx};

dommage que ton algo ne fonctionne pas si par exemple Dy=2, c'est pourtant le plus vieux et simple algo de jeux video  

et le Stapha oublie le chargement et la sauvegarde.
Là où sur ST et mig il n'y a qu'un chargement, aucun test ou changement de vecteurs ( puisqu'il n'y en a pas ! ), et aucune sauvegarde, seulement un incrément à faire sur le pointeur de lecture de la trajectoire qui est entièrement précalculée ( si les trajectoires bouclent sur elle-même très rapidement, ce n'est pas pour rien ).
Quand tu répètes l'algo tout ça plusieurs centaines de fois par VBL, au final ça fait ou non des cycles consommés.
Quasi aucun dans les démos record de boules ( je précise bien : de boules, pas forcément de starfield même si ça a aussi été utilisé ) sur st et mig, et un sacré paquet sur l'Archie.
Dans le 1er cas sur st et mig c'est non utilisable dans un jeu, côté Archie ça l'est.
J'ai déjà expliqué pour l'effacement dans mon post initial, je n'ai pas envie de radoter.
M'enfin, je m'en fous.
( Hier la livre sterling a failli sauter, le système bancaire anglais aussi ; et ça sera peut-être la semaine prochaine, alors bof, vous expliquer ou vous convaincre de quoi que ce soit c'est loin de me préoccuper en ce moment ).
A un moment que chacun pense ce qu'il veut.
Je le répète : Leonard ( Oxygen ) explique tout ça très bien sur son site, au final je n'ai rien à expliquer que je n'aie déjà rédigé.
A lire, tout en lisant mon post originel.

[stapha92]

se résume à un algo du genre :

y += dy;
if (y == 0 or y == 255) {dy = -dy};
x += dx;
if (x == 0 or x == 319) {dx = -dx};

dommage que ton algo ne fonctionne pas si par exemple Dy=2, c'est pourtant le plus vieux et simple algo de jeux video  

Oui mais dans sa video c'est bien 1 ou -1 qu'il utilise. J'ai pas fait ça par hasard. ça évite une opération lorsque le test est positif.

Et pour info : ça marche très bien avec dy = 2 si on part sur des lignes impaires...  

Mais si tu veux :
y += dy;
if (y < 0 or y > 255) {dy = -dy; y += dy;};
x += dx;
if (x < 0 or x > 319) {dx = -dx; x += dx;};

Puisque tu veux m'aider, continuons sur cet algo :
Je veux que les coordonnées soient en virgule fixe pour améliorer le mouvement. Mais, au moment de calculer l'adresse, il faut forcément que je récupère la partie entière. Mais les décalages et les masquages ne sont pas gratuit sur ST (tout comme sur le mig hein ! ne t'énerve pas !). Tu as surement une astuce avec le plus vieux et simple algo de jeux video ?

inutile de m'apprendre à coder Rocky. Donnes nous plutôt les 2 principe d'entrelacements. Parce que là tu vas m'apprendre un truc...

[Firebird]

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

Tiens, peut-être tu pourras m'aider à dissiper un doute : le nombre de sprites hard sur l'Amiga est limité à 8 par ligne, mais j'ai lu à plusieurs reprises qu'il serait possible d'en afficher plus, via une sorte de multiplexage. Par ex., un sprite hardware de 16x16, pourrait être répété plusieurs fois sur une même ligne ? C'est vraiment possible un truc pareil ?

Sinon, sais-tu s'il est possible de changer la palette de chaque sprite hardware via le copper, de sorte que chaque sprite ait sa propre palette de 15 couleurs (15+15+15+15) dans le cas de 4 sprites de 16 couleurs ?

[Invité]

Par ex., un sprite hardware de 16x16, pourrait être répété plusieurs fois sur une même ligne ? C'est vraiment possible un truc pareil ?

Oui c'est une technique largement utilisée sur amiga, pour exemple les jeux risky woods ou jim power l'utilisent pour faire tout un layer .
Mais sinon 98% des jeux doivent l'utiliser .

Tu peux y trouver une explication des tricks sur les sprites dans les jeux amiga,ici : 
https://codetapper.com/amiga/sprite-tricks/

Puisque tu veux m'aider, continuons sur cet algo :
Je veux que les coordonnées soient en virgule fixe pour améliorer le mouvement. Mais, au moment de calculer l'adresse, il faut forcément que je récupère la partie entière. Mais les décalages et les masquages ne sont pas gratuit sur ST (tout comme sur le mig hein ! ne t'énerve pas !). Tu as surement une astuce avec le plus vieux et simple algo de jeux video ?

Tu fais tes calculs en 32 bits ,et tu récupères chaque partie par des accès 16 bits ?? 

[rocky007]

Oui mais dans sa video c'est bien 1 ou -1 qu'il utilise. J'ai pas fait ça par hasard. ça évite une opération lorsque le test est positif.

pourquoi alors d"utiliser une variable plutôt que mettre en dur la valeur ? perdre des cycles ?

inutile de m'apprendre à coder Rocky. Donnes nous plutôt les 2 principe d'entrelacements. Parce que là tu vas m'apprendre un truc...

pourquoi tu lis en diagonal ce que je t'explique ?

Je répète à nouveau :  tu peut soit entrelacer deux trames avec temporalité différente ( et donc avec un effet peigne ) comme les émissions TV, soit entrelacer deux trames avec temporalité identique ( exemple d' Interphase, sans effet peigne )

[stapha92]

se résume à un algo du genre :

y += dy;
if (y == 0 or y == 255) {dy = -dy};
x += dx;
if (x == 0 or x == 319) {dx = -dx};

dommage que ton algo ne fonctionne pas si par exemple Dy=2, c'est pourtant le plus vieux et simple algo de jeux video  

et le Stapha oublie le chargement et la sauvegarde.
Là où sur ST et mig il n'y a qu'un chargement, aucun test ou changement de vecteurs ( puisqu'il n'y en a pas ! ), et aucune sauvegarde, seulement un incrément à faire sur le pointeur de lecture de la trajectoire qui est entièrement précalculée ( si les trajectoires bouclent sur elle-même très rapidement, ce n'est pas pour rien ).
Quand tu répètes l'algo tout ça plusieurs centaines de fois par VBL, au final ça fait ou non des cycles consommés.
Quasi aucun dans les démos record de boules ( je précise bien : de boules, pas forcément de starfield même si ça a aussi été utilisé ) sur st et mig, et un sacré paquet sur l'Archie.
Dans le 1er cas sur st et mig c'est non utilisable dans un jeu, côté Archie ça l'est.
J'ai déjà expliqué pour l'effacement dans mon post initial, je n'ai pas envie de radoter.
M'enfin, je m'en fous.
( Hier la livre sterling a failli sauter, le système bancaire anglais aussi ; et ça sera peut-être la semaine prochaine, alors bof, vous expliquer ou vous convaincre de quoi que ce soit c'est loin de me préoccuper en ce moment ).
A un moment que chacun pense ce qu'il veut.
Je le répète : Leonard ( Oxygen ) explique tout ça très bien sur son site, au final je n'ai rien à expliquer que je n'aie déjà rédigé.
A lire, tout en lisant mon post originel.

Je comprend très bien comment ça marche. Mais je répète : le calcul des coordonnées ne prend pas grand chose par rapport au reste. Je t'ai donnée un exemple de calcul bien plus complexe et avec bien plus de coordonnées. Tu crois qu'il est magique le code qui fait ça ?
C'est le dessin des sprites qui prend la grande majorité du temps.

Mais prouve moi le contraire : utilises une table. D'après toi, cette modif devrait multiplier le nombre de boules que ton algo affiche, puisque ce calcul si pénalisant ne serait plus là...
Tu vas économiser 1 chargement, 2 sauvegardes, 2 additions et, dans ton cas (déplacement en 1 pixel), une affectation conditionnée : 6 instructions par boules.
ça fait quoi ? 10 cycles ? 15 cycles ? Donc a peu près 2 000 cycles par frame en 8 Mhz. 2 000 sur 160 000 -> Tu avais raison, le calcul des coordonnées ne coute pas rien dans ton algo, il doit prendre un peu plus de 1 %...

Et quand tu vas dire que je dis des betises, merci de préciser ou sont mes erreurs, pour changer...

Et passe en décimal : parler de calcul de coordonnées couteux quand tous les sprites vont à la même vitesse et qu'il n'y a que 4 trajectoires est un peu ridicule quand même...

[Copper]

Tiens, peut-être tu pourras m'aider à dissiper un doute : le nombre de sprites hard sur l'Amiga est limité à 8 par ligne, mais j'ai lu à plusieurs reprises qu'il serait possible d'en afficher plus, via une sorte de multiplexage. Par ex., un sprite hardware de 16x16, pourrait être répété plusieurs fois sur une même ligne ? C'est vraiment possible un truc pareil ?

Sinon, sais-tu s'il est possible de changer la palette de chaque sprite hardware via le copper, de sorte que chaque sprite ait sa propre palette de 15 couleurs (15+15+15+15) dans le cas de 4 sprites de 16 couleurs ?

Oui c'est du multiplexage et cela fonctionne car les sprites ne sont pas bufférisés... Par contre il faut bien tenir compte du fait qu'il faut 8 (voir même 12 ou 16 pixels quand il y'a 5 ou 6 bitplanes) pour changer un registre (et qu'il faut 3 registres pour déplacer et changer complètement la forme d'un sprite 3 couleurs)... C'est pour cela que dans risky wood le motif du fond se répète car les 2 sprites combinés sont seulement déplacés (il n'y a pas assez de temps pour les modifier en plus)... Par contre dans Brian The Lion les sprites 3 couleurs sont déplacés et modifiés en partie (seulement un des 2 plans)

Quand à changer la palette c'est possible mais il faut aussi tenir compte du temps nécessaire pour changer les 15 registres...

[stapha92]

Oui mais dans sa video c'est bien 1 ou -1 qu'il utilise. J'ai pas fait ça par hasard. ça évite une opération lorsque le test est positif.

pourquoi alors d"utiliser une variable plutôt que mettre en dur la valeur ? perdre des cycles ?

Je comprend pas : comment tu fais passer l'incrément de 1 à -1 si tu le mets en dur ?

inutile de m'apprendre à coder Rocky. Donnes nous plutôt les 2 principe d'entrelacements. Parce que là tu vas m'apprendre un truc...

pourquoi tu lis en diagonal ce que je t'explique ?

Je répète à nouveau :  tu peut soit entrelacer deux trames avec temporalité différente ( et donc avec un effet peigne ) comme les émissions TV, soit entrelacer deux trames avec temporalité identique ( exemple d' Interphase, sans effet peigne )

Je comprend pas non plus. Et je t'ASSURE que je ne fais pas ça pour t'emmerder. Et je suis certain que Copper non plus.
On ne doit pas parler de la même chose parce que je vois bien que toi aussi tu cherches vraiment à expliquer sans mauvaise foi.

Je te dis comment je vois le truc, peut-être que c'est une question de termes.
1 : Dans une TV, l'affichage des trames a toujours lieu tous les 1/50e de seconde.
2 : Une TV affiche toujours une ligne sur 2 à chaque trame.
3 : en mode entrelacée , qui est le mode normal pour une TV (en tout cas de cette époque), il y a un décalage d'une ligne entre les 2 trames. La 2eme vient remplir les lignes laissées vide par la première. Donc chaque ligne n'est rafraichie que tous les 2/50e de seconde. D'ou le scintillement.
4 : en mode progressif, on dit à la TV que toutes les trames sont paires (ou l'inverse) et du coup la deuxième se place sur la première (d'ou le terme de hack par Copper). Résultat : chaque ligne est bien rafraichie tous les 1/50e de seconde. Par contre, les lignes laissées vide le restent : d'ou les scanlines.

C'est pourquoi les TV 100 Hz supprimait tout scintillement (elle n'ont pourtant été inventées pour le mig...) : elle dédoublait chaque trame (la 1 et 3 sont identiques, comme la 2 et 4). Donc chaque ligne est raffraichie tous les 1/50e de seconde.
C'est pourquoi aussi il n'y avait plus de scintillement avec les LCD : la latence étant bien plus grande, les lignes mettent bien plus de temps à s'effacer. Et 2/50e de secondes deviennent suffisant.

Forcement, dans ce que je viens de dire, il y aura un truc avec lequel tu ne seras pas d'accord. Dis le et on devrait comprendre d'ou vient cette incompréhension.
Ou peut-être l'as tu trouvé en lisant.

Le fight ça peut être drole mais quand on en est à ne pas être d'accord sans pouvoir dire sur quoi, c'est qu'on est au bout du truc...

[The_Real_Zarchos]

Stapha, je propose que tu nous écrives le code 68000 pour l'algo du déplacement + test pour rebond, avec les cycles pris pour chaque instruction.
On verra si ce n'est que 15 cycles par bouboule.
Du peu que je connais du 68000 je pense qu'on va être à plus du double.
Tout à coup quand tu as un 'record' avec 300 boules à l'écran, tu vois bien le surcoût de cycles par rapport à la version 'je lis bêtement une valeur précalculée'.
Dans l'algo que j'ai pris, qui est coûteux en cycles, tu peux faire des tests de collision, car tu as un x et un y, c'est donc bon pour un jeu.
Dans la version précalculée des démos 'record' mig et ben non ...

Et à nouveau : sur Archie je réaffiche TOUT le décor de fond, alors que sur ST et MIG la zone à réafficher est calculée à l'avance ( comme un bloc 'unifié' ), du coup tu peux te gratter pour que ce soit utilisable dans un jeu ( exemple : ton tir touche une boule et ça la fait changer de course ... pas d'bol ça la fait sortir de ta zone précalculée de ré écriture 'unifiée' du fond, tu as un pic d'usage de cycles pour sa zone de recopie de son fond à elle, pouf tu passes de 50 fps à 25 fps si ces cas se repetent )
Moi sur Archie ça ne m'arrivera pas, je n'ai aucun surcoût.

Désolé si peu lisible, il est tard, mais ça doit se comprendre sauf à être d'extrême mauvaise foi.
Ce fut ma dernière tentative, après, je m'en fous.
Bon, en fait, déjà maintenant je m'en fous.
Faut aller lire sur le site de Leonard, je le répète.

[dlfrsilver]

Putain le niveau de ces mecs... 

En fait, et si au lieu de faire du hors sujet permanent, tu commentais vraiment sur le sujet, c'est à dire le Amiga vs ST pour changer ?

[dlfrsilver]

 Mais je suis bien consultant, ça c'est réel.

Tu es sur que ca ne serait pas plutot  : "con insultant" ?  ...  relis ton contrat de travail.

Ici sur Gamopat ? Euhh oui, on dirait 

[dlfrsilver]

Comment appelle-t-on une démo toute moche qui ne plait qu'à son auteur ?

Réponse:

Un.jeu amiga?

Laisse moi t'aider : un jeu ST 

[dlfrsilver]

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

Tiens, peut-être tu pourras m'aider à dissiper un doute : le nombre de sprites hard sur l'Amiga est limité à 8 par ligne, mais j'ai lu à plusieurs reprises qu'il serait possible d'en afficher plus, via une sorte de multiplexage. Par ex., un sprite hardware de 16x16, pourrait être répété plusieurs fois sur une même ligne ? C'est vraiment possible un truc pareil ?

Sinon, sais-tu s'il est possible de changer la palette de chaque sprite hardware via le copper, de sorte que chaque sprite ait sa propre palette de 15 couleurs (15+15+15+15) dans le cas de 4 sprites de 16 couleurs ?

Il suffit de recharger de manière continue les registres (ex: technique utilisée par Pieket Weeserik sur Silkworm et SWIV Amiga). Tu dépasses du coup les 8 sprites hardware d'origine.

[youki]

Oui mais dans sa video c'est bien 1 ou -1 qu'il utilise. J'ai pas fait ça par hasard. ça évite une opération lorsque le test est positif.

pourquoi alors d"utiliser une variable plutôt que mettre en dur la valeur ? perdre des cycles ?

Je comprend pas : comment tu fais passer l'incrément de 1 à -1 si tu le mets en dur ?

inutile de m'apprendre à coder Rocky. Donnes nous plutôt les 2 principe d'entrelacements. Parce que là tu vas m'apprendre un truc...

pourquoi tu lis en diagonal ce que je t'explique ?

Je répète à nouveau :  tu peut soit entrelacer deux trames avec temporalité différente ( et donc avec un effet peigne ) comme les émissions TV, soit entrelacer deux trames avec temporalité identique ( exemple d' Interphase, sans effet peigne )

Je comprend pas non plus. Et je t'ASSURE que je ne fais pas ça pour t'emmerder. Et je suis certain que Copper non plus.
On ne doit pas parler de la même chose parce que je vois bien que toi aussi tu cherches vraiment à expliquer sans mauvaise foi.

Je te dis comment je vois le truc, peut-être que c'est une question de termes.
1 : Dans une TV, l'affichage des trames a toujours lieu tous les 1/50e de seconde.
2 : Une TV affiche toujours une ligne sur 2 à chaque trame.
3 : en mode entrelacée , qui est le mode normal pour une TV (en tout cas de cette époque), il y a un décalage d'une ligne entre les 2 trames. La 2eme vient remplir les lignes laissées vide par la première. Donc chaque ligne n'est rafraichie que tous les 2/50e de seconde. D'ou le scintillement.
4 : en mode progressif, on dit à la TV que toutes les trames sont paires (ou l'inverse) et du coup la deuxième se place sur la première (d'ou le terme de hack par Copper). Résultat : chaque ligne est bien rafraichie tous les 1/50e de seconde. Par contre, les lignes laissées vide le restent : d'ou les scanlines.

C'est pourquoi les TV 100 Hz supprimait tout scintillement (elle n'ont pourtant été inventées pour le mig...) : elle dédoublait chaque trame (la 1 et 3 sont identiques, comme la 2 et 4). Donc chaque ligne est raffraichie tous les 1/50e de seconde.
C'est pourquoi aussi il n'y avait plus de scintillement avec les LCD : la latence étant bien plus grande, les lignes mettent bien plus de temps à s'effacer. Et 2/50e de secondes deviennent suffisant.

Forcement, dans ce que je viens de dire, il y aura un truc avec lequel tu ne seras pas d'accord. Dis le et on devrait comprendre d'ou vient cette incompréhension.
Ou peut-être l'as tu trouvé en lisant.

Le fight ça peut être drole mais quand on en est à ne pas être d'accord sans pouvoir dire sur quoi, c'est qu'on est au bout du truc...

Je pense que ce que Rocky dit , c est que sur les TV,  l'image affichée durant les lignes paires n est pas la même que  celle des lignes impaires.

[The_Real_Zarchos]

Disons qu'il y'en a un qui se fait ban un peu plus souvent que l'autre quand même...

D'autre part y a des fois où silver affirme des trucs je ne sais absolument pas s'il dit vrai ou pas

Exemple quand il dit que SOTB utilise des DW 8 voies... Si ca se trouve le format DW peut effectivement gérer 8 voies mais ceux de SOTB ne sont qu'en 4 voies

Par contre le format DW existe bien c'est quand même moins connu que le MOD

C'est bien ce que l'on avait tous déjà compris : tu n'as aucune oreille si tu penses que les ziks de SOTB pourraient être en 8 voies 

[The_Real_Zarchos]

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

Je viens de t'expliquer que c'est tout le contraire, justement.
Ma démo est spécialement pensée pour que le code serve dans un jeu ; là où c'est exactement le contraire dans les démos 'record' sur ST et mig.
Mais tu n'avoueras jamais t'être trompé, malgré mes explications.

[The_Real_Zarchos]

Je trouve scandaleux la critique permanente sur le travail de Zarchos.  A ce que j'ai vu de ce qui a été fait sur Archimede, personne n'a fait mieux que ses proof of concept, il faut avoir la décence de reconnaître son travail.    Critiques émanant de la part de personnes qui produisent rien officiellement.  Zarchos peut au moins se targuer d'énerver la plupart de ses détracteurs puisqu'ils sont obligé de passer des heures de déterrage de sujets datant plus de 10 ans !!

Voilà.

[The_Real_Zarchos]

Je trouve scandaleux la critique permanente sur le travail de Zarchos.  A ce que j'ai vu de ce qui a été fait sur Archimede, personne n'a fait mieux que ses proof of concept, il faut avoir la décence de reconnaître son travail.    Critiques émanant de la part de personnes qui produisent rien officiellement.  Zarchos peut au moins se targuer d'énerver la plupart de ses détracteurs puisqu'ils sont obligé de passer des heures de déterrage de sujets datant plus de 10 ans !!

Par contre tu mouftes pas sur la critique incessante de zarchos sur le travail des autres, tu as vraiment une belle mentalité . 
Si il avait le même genre de débilités pour les utilisateur/codeurs ST, tu tiendrais certainement pas le même discours .

En même temps, ce genres de choses méritent tellement d'être respectueux et complaisant:

Confession :
J'adore GP, car je sais que je suis intelligent, très intelligent même, doué d'une intelligence bien supérieure à la moyenne, et en venant ici je peux me faire plaisir, être féroce, et rembarrer du benêt qui se trouve ici véritablement à foison.
Merci GP !
Rhhhaaaa, ce que c'est bon, et drôle !!

Donc vu que cette raclure ne s'est jamais gêné pour ça, je vais pas prendre de gants;, et si tu trouves ça scandaleux, fais en sorte d'éduquer ton poulain, tu verras tout ira pour le mieux .

Le jour où toi et tes congénères auront compris que ce n'est à la base pas son envie de démontrer quoi que ce soit qui énerve, mais son attitude de merde, il arrêtera probablement ce genre de choses, alors que des gens comme vous font tout pour qu'il continue .

Je ne suis revenu ici qu'à cause des immondices déversés par Drlsfmeskouilles, qu'il faudra qu'il m'explique quand on se croisera en physique.
Et également car j'en avais marre que vous m'accusiez d'être sur GP sous un ou plusieurs autres pseudos, alors que ce n'est absolument pas le cas.

[The_Real_Zarchos]

On voit bien que c'est pas toi qui se fait insulter de buveur d'eau chaude tous les jours

Parce que ça paraît anondin comme ça , mais qui te dit que j'ai pas un problème de dépendance à l'eau chaude ?  Ou pire encore , j'ai peut être été brûlé au 3ème degré avec de l'eau chaude ?

Ne te méprends pas ,en ce qui me concerne je trouve ça ridicule au possible, on peut ne pas être d'accord, mais clairement il y a des limites,et dlfrsilver abuse clairement dans ses propos .

Mais j'insiste sur le fait, qu'on peut pas comparer les 2 ,car si tu trouves que le harcèlement et d'insultes maladifs de zarchouille est de la même veine que celui de dlfrsilver, c'est que tu ne sais clairement pas jusqu'où cet abruti de zarchouille va .
Il en est quand même à faire des vidéos où il insulte avec sa bande de trisos qui le suivent les gens,que je sache, dlfrsilver n'a jamais fait cela par exemple .

Prouve tes dires ?
Je n'ai fait aucune vidéo insultant qui que ce soit.
Je me suis moqué, démonstration à l'appui.
Tu affabules, Toukon, ça a toujours été ta méthode.

[The_Real_Zarchos]

- nous expliques qu'il y a des instructions qui prennent 0 cycles en nous montrant un texte qui n'affirme jamais pareille chose mais que tu n'avais pas compris, comme d'hab...

C'est bien le cas en fonction du placement en mémoire.
Tu gagnes 1 cycle donc dans ton code ça te fait une instruction à 1 cycle pour... 0 cycle.
AU FINAL, même si tu veux pinailler sur la terminologie que j'emploie.
Le code copié le démontre, tu n'as qu'à le relire.

[The_Real_Zarchos]

Sinon j'attends toujours que tu m'expliques comment le son de l'archimedes fonctionne, enfin surtout son DMA pour faire du multi channels   
Steve3000 doit être vraiment très con pour tout faire au CPU si on t'écoute . 

Tu ne comprends vraiment rien.
Tu peux très bien faire tout au CPU et avoir un seul DMA ; c'est exactement ainsi que tu codes un player sur Archie, donc oui c'est bien ce que fait Steve, forcément.
En réalité tu ne sais pas ce qu'est un DMA.
Pourquoi devrais-je te ré expliquer ?
Je l'ai fait par le passé, déjà.
N'avoir qu'un seul DMA n'empêche pas d'avoir du multi canaux ; les 2 n'ont rien à voir.
Le nombre de canaux n'est pas fonction du nombre de DMA, et oui.
C'est là où ça me fait marrer, car des types comme Stapha reste silencieux genre ' on se serre les coudes pour emmerder Zarchos ' alors qu'il pourrait très facilement intervenir et te corriger.

[The_Real_Zarchos]

N'as tu pas dit que "quelqu'un" avait découvert qu'une instruction pouvait prendre 0 cycle ?

Oui, je l'ai dit, car c'est vrai, c'était un type qui codait sur 3DO qui a découvert ça, et ça fonctionne aussi sur Archie, et c'est en fonction de la position en mémoire d'une instruction par rapport à une adresse quadword aligned.
Comme tu economises 1 cycle et la plupart des instructions sur ARM prenne 1 cycle ...
D'ailleurs j'ai posté l'extrait de code qui le montre.
Tu n'as qu'à relire.
C'est là :
https://www.gamopat-forum.com/t117369p450-guerre-st-amiga-fight-mauvaise-foi-assuree#3552920
CODE:

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:

+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

Tu peux toujours pinailler sur la terminologie, c'est tout ce que tu as pour tenter de me faire chier.

[Copper]

Je pense que ce que Rocky dit , c est que sur les TV,  l'image affichée durant les lignes paires n est pas la même que  celle des lignes impaires.

C'est pareil sur Amiga... De toute façon quand on considère qu'un 68020 n'est pas assez puissant pour changer les coordonnées des sprites hardwares 50 fois par seconde c'est que l'on a quand même du mal avec le concept de sprite hardware

Et de toute façon je ne suis même pas sur qu'il ait compris que l'interruption vblank reste à 50 hz et que si tu codes un truc du genre je calcule les nouvelles coordonnées de mes voitures, j'attend la vblank, je met à jour les coordonnées de mes sprites hardware dans ma copperlist et bien tu aura bien l'effet peigne car les sprites n'auront pas les mêmes coordonnées sur les trames paires et impaires... comme à la télévision

Maintenant on peut très bien trouver l'effet peigne horrible et faire en sorte de l'éviter... Surtout que l'on a la possibilité de savoir quel type de frame va être affiché avec le bit LOF (long frame qui est d'ailleurs toujours à 1 en mode non entrelacé)

[Copper]

C'est bien ce que l'on avait tous déjà compris : tu n'as aucune oreille si tu penses que les ziks de SOTB pourraient être en 8 voies 

Justement si je me fie à mon oreille je n'ai pas l'impression que c'est du 8 voies... Mais je n'en sais rien et ce n'est pas une preuve...

[The_Real_Zarchos]

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. 

Oui, je peux : la preuve c'est ce qui est dans mon code WIP SOTB.


La séquence de sprites du personnage, tu vois bien que chaque sprite de la planche de l'animation du perso a des trous.
Les dirigeables aussi.
Les éléments du muret avec la barrière en bois, aussi.
Les lettres 'BEAST' aussi.
Et sans prendre des Mo, car justement le code est très optimisé.
Ah oui, j'allais oublier : cette 'merde' WIP SOTB, elle est en 352x258, affiche 480 couleurs à l'écran, hein   en 50 fps bien sûr.

Le ST n'a pas de record plus élevé : montre moi donc ça avec des boules 32x32 en 15 couleurs puisque c'est ce que moi j'affiche ... et en 320x256 s'il te plait, pas en 240 lignes hein

En 16x16 sur ARM250 à 12 Mhz j'ai fait le calcul je peux en faire rebondir plus de 600, et chez moi elles sont en 4 couleurs, pas 3 et à nouveau en 320x256 ...
Sur ARM2 à 8 Mhz ce sera plus que sur le ST, et à nouveau, chez moi, ce sera utilisable dans un jeu, pas sur le ST.
Même avec du chunky le ST ne pourrait pas faire pareil, et c'est normal vu que c'est l'ARM avec le MEMC qui va faire la différence : par rapport au 68000, l'ARM+MEMC
va en moyenne être minimum 4 fois plus rapide lors des accès mémoire.

Je n'ai jamais attribué à l'ARM l'avantage du chunky : prouve donc tes dires.

Que ça vous plaise ou non, personne sur Archie à part moi n'optimise aussi bien l'affichage d'éléments 2D.
Je sais que ça vous chier, et moi ça me ravit.
Bon week end les haineux.

[Copper]

En même temps, que ça te plaise ou non, ca n'intéresse personne... Et de toute façon si tu n'es pas capable de faire le jeu complet avec 512 Ko et en un temps raisonnable ca ne sert à rien...