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

[drfloyd]

Le membre 'stapha92' a effectué l'action suivante : Lancer de dés !

---

'SUPPOS DE LA FORTUNE' :

Résultat :

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

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.

Non : ton code n'est pas pensé pour un jeu. ça fait 30 ans que tu nous le prouve : le shoot promis qui devait exploser la neo-geo n'existe toujours que dans ton esprit malade.

Tes explications ? J'en ai pas vu. J'ai juste vu des affirmations débiles.

30 ans ?
Pourquoi pas 3000 ?
'Promis' ?
T'es pas bien, non ?
Dans le sens où je vous devrais qqchose ?
Ah ah ah merci de m'avoir bien fait rire ... Heureusement les reseaux sociaux existent pour les types comme toi.
Xavier Tardy ne doit rien à des types comme toi, ou à qui que ce soit dans un domaine aussi futile, et surtout non rémunéré.

Tu m'as rien promis à moi et tu nous doit rien, à part la tranquilité. Mais t'as rédigé des tas de trucs, décrit ton futur jeu, fait des tonnes de video, publiés des tonnes de messages, subit des tas de bannissements, possède le record du nombre de WIP merdique, etc... etc...

Et tu viens me parler de réseaux sociaux ! c'est moi qui est mort de rire !

Bizarre, tu l'ouvres pas sur les autres sujets ou sur les réponses ou je t'ai remis en place (comme ton 0 cycle, ou ton pointeur vidéo...). C'était moins drole ?

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

Non : ton code n'est pas pensé pour un jeu. ça fait 30 ans que tu nous le prouve : le shoot promis qui devait exploser la neo-geo n'existe toujours que dans ton esprit malade.

Tes explications ? J'en ai pas vu. J'ai juste vu des affirmations débiles.

30 ans ?
Pourquoi pas 3000 ?
'Promis' ?
T'es pas bien, non ?
Dans le sens où je vous devrais qqchose ?
Ah ah ah merci de m'avoir bien fait rire ... Heureusement les reseaux sociaux existent pour les types comme toi.
Xavier Tardy ne doit rien à des types comme toi, ou à qui que ce soit dans un domaine aussi futile, et surtout non rémunéré.

Tu m'as rien promis à moi et tu nous doit rien, à part la tranquilité. Mais t'as rédigé des tas de trucs, décrit ton futur jeu, fait des tonnes de video, publiés des tonnes de messages, subit des tas de bannissements, possède le record du nombre de WIP merdique, etc... etc...

Et tu viens me parler de réseaux sociaux ! c'est moi qui est mort de rire !

Bizarre, tu l'ouvres pas sur les autres sujets ou sur les réponses ou je t'ai remis en place (comme ton 0 cycle, ou ton pointeur vidéo...). C'était moins drole ?

Bizarre car toi tu ne réponds pas sur les 15 cycles pour que le 68000 charge x y inc x inc y ajoute fasse le test pour le rebond inverse vecteur si besoin et sauvegarde le tout 

Pour le reste tu déformes mes propos, et tu le sais bien.
Par exemple pour remplir tu le fais en soft pour les extrêmités de segments horizontaux, et en hard pour l'essentiel ...
Tu vois, on peut continuer longtemps.
Moi j'attends ton code 68000 en 15 cycles, je sais que je vais attendre très longtemps ...

[The_Real_Zarchos]

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.

- C'est juste horrible.
- Ou sont les arbres ?
- Si : ça prend des Mo : le precalc super long au début le montrePourquoi c'est si long à démarrer ? Parce qu'il y a des tonnes de précalc bien sur. Et c'est utilisable dans un jeu soi-disant...
- ça demande combien de RAM ? Te connaissant, je sais qu'il faudra doubler ta réponse.
- ça tourne sur 12,5 Mhz.
- 480 couleurs ? Mais comme t'en choisis 1/16, t'en choisi 30 en fait. Et encore, les couleurs de base sont fixes. Ce sont les bits de poids fort que tu peux modifier. C'est bien plus coloré sur le mig.
- Oui 352x258. Mais à cause des couleurs approximatives, les graphismes sont au final moins fins que sur mig.
- Ils sont ou les niveaux a 2 layer ? SOTB sans la cave, le chateau et le shoot, c'est pas SOTB.

Ca prend du temps à démarrer car le source s'assemble, voilà tout ...
Ca prend 2 Mo et c'est avec le source en mémoire, tu vois ... il fait déjà 600 ko ce source car je commente vraiment énormément mes sources,
et de plus je charge les graphismes de l'arrière plan.
C'est horrible ? Peut-être oui, sur un écran LCD bas de gamme comme le mien, oui, mais c'est superbe sur un cathodique.
Ca tourne sur une machine à 12 Mhz oui et alors ? Regarde tout ce qu'il y a et dont je n'ai pas besoin pour ce niveau de SOTB,
ça tournera au final sur bécane à 8 Mhz, avec juste ce qu'il faut ( et les arbres ).
Les arbres y seront, c'est ça qu'il faut que je code maintenant. Je l'ai dit, ça ne coûtera quasi rien en plus à afficher, il suffit de penser au bon algo, et je l'ai fait ( bien y penser ).
Non, ce n'est pas plus coloré sur le mig, trèèèèèèès loin de là.
Le seul niveau difficile pour l'Archie c'est celui de la forêt, ce sera d'abord celui-là, du coup

Tu nous le donnes ton code 68000 en 15 cycles stp ? On attend tous la, p'tit génie 

[stapha92]

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

Bien sur, et tu n'as que la partie entière à récupérer. Mais il y a une astuce :

Supposons que tu souhaites, par exemple, faire du rééchantillonnage sur un sample. En mode crado façon ST ou Archimedes, pas en appliquant un filtre hein...

Tu va gérer un compteur et un incrément. Disons D0 et D1.

Tu vas sotcker tes nombres au format 16.16. 16 bits pour la partie entiere (E) et 16 pour la partie décimale (D) :
EEEEEEEEEEEEEEEEDDDDDDDDDDDDDDDD

L'adresse du sample à lire se trouve dans A0 et celle du sample à créer se trouve dans A1.

Ta boucle va ressembler à ça :

Code:

Add.l D1,D0;            On ajoute l'incrément (D1) au compteur
Move D0, D2;            On copie le compteur
Swap D2;                On inverse les parties entières et décimale
Move (A0, D2.W),(a1)+   On lit le sample pointé dans la source et on l'écrit dans la destination

4 instruction pour calculer la prochaine position, récupérer la valeur et l'écrire c'est déjà bien. Merci aux modes d'adressages du 68000.

Mais on peut faire mieux en inversant les 2 parties. D0 et D1 auront cette aspect là :
 DDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEE

En y réfléchissant ça ne change pas grand chose vu que les 2 sont inversés. sauf pour les retenues : si l'addition de la partie décimale du compteur dépasse 1, il faudra incrémenter la partie entière. Encore une fois le 68000 nous aide : ADDX fait une addition et ajoute la retenue si la derniere opération en avait généré une (pour faire simple). Du coup la boucle devient :

Code:

Add.l D1,D0;            On ajoute l'incrément (D1) au compteur
Addx.l D3,D0;           D3 vaut 0. On ajoute l'éventuelle retenue au compteur
Move (A0, D0.W),(a1)+   On lit le sample pointé dans la source et on l'écrit dans la destination

Mais encore mieux : si on initialise le compteur avec la partie décimale au lieu de le mettre à 0, on peut se contenter de faire :

Code:

Addx.l D1,D0;           On ajoute le l'incrément et l'eventuelle retenue de l'addition précédente.
Move (A0, D0.W),(a1)+   On lit le sample pointé dans la source et on l'écrit dans la destination

A chaque itération, on aurait une valeur décimale erronée (elle aura la valeur de l'itération suivante). Par contre la partie entière sera exacte. Et c'est d'elle dont on a besoin.

2 instructions pour calculer la prochaine position, récupérer la valeur et l'écrire.
Et ça prend la place d'une seule instruction ARM...

[stapha92]

Ca prend du temps à démarrer car le source s'assemble, voilà tout ...
Ca prend 2 Mo et c'est avec le source en mémoire, tu vois ... il fait déjà 600 ko ce source car je commente vraiment énormément mes sources,
et de plus je charge les graphismes de l'arrière plan.
C'est horrible ? Peut-être oui, sur un écran LCD bas de gamme comme le mien, oui, mais c'est superbe sur un cathodique.
Ca tourne sur une machine à 12 Mhz oui et alors ? Regarde tout ce qu'il y a et dont je n'ai pas besoin pour ce niveau de SOTB,
ça tournera au final sur bécane à 8 Mhz, avec juste ce qu'il faut ( et les arbres ).
Les arbres y seront, c'est ça qu'il faut que je code maintenant. Je l'ai dit, ça ne coûtera quasi rien en plus à afficher, il suffit de penser au bon algo, et je l'ai fait ( bien y penser ).
Non, ce n'est pas plus coloré sur le mig, trèèèèèèès loin de là.
Le seul niveau difficile pour l'Archie c'est celui de la forêt, ce sera d'abord celui-là, du coup

Tu nous le donnes ton code 68000 en 15 cycles stp ? On attend tous la, p'tit génie 

Bla bla bla...

J'ai jamais parler d'un code 68000 en 15 cycles. Je t'ai déjà répondu que je parlais de l'ARM, p'tit con

Continue à te raccrocher au branches : t'en ai à me reprocher des choses que je n'ai jamais dites.

En plus me parle pas de calcul de coordonnées quand tout ce que tu obtiens avec le tien c'est une seule vitesse et 4 trajectoires...

[Copper]

Tu devrais nous poster le lien youtube que tu mentionnais en parlant de 8 voies pour le format DW.

A priori c'est bien 4 voies d'après DeliPlayer...

[The_Real_Zarchos]

Ca prend du temps à démarrer car le source s'assemble, voilà tout ...
Ca prend 2 Mo et c'est avec le source en mémoire, tu vois ... il fait déjà 600 ko ce source car je commente vraiment énormément mes sources,
et de plus je charge les graphismes de l'arrière plan.
C'est horrible ? Peut-être oui, sur un écran LCD bas de gamme comme le mien, oui, mais c'est superbe sur un cathodique.
Ca tourne sur une machine à 12 Mhz oui et alors ? Regarde tout ce qu'il y a et dont je n'ai pas besoin pour ce niveau de SOTB,
ça tournera au final sur bécane à 8 Mhz, avec juste ce qu'il faut ( et les arbres ).
Les arbres y seront, c'est ça qu'il faut que je code maintenant. Je l'ai dit, ça ne coûtera quasi rien en plus à afficher, il suffit de penser au bon algo, et je l'ai fait ( bien y penser ).
Non, ce n'est pas plus coloré sur le mig, trèèèèèèès loin de là.
Le seul niveau difficile pour l'Archie c'est celui de la forêt, ce sera d'abord celui-là, du coup

Tu nous le donnes ton code 68000 en 15 cycles stp ? On attend tous la, p'tit génie 

Bla bla bla...

J'ai jamais parler d'un code 68000 en 15 cycles. Je t'ai déjà répondu que je parlais de l'ARM, p'tit con

Continue à te raccrocher au branches : t'en ai à me reprocher des choses que je n'ai jamais dites.

En plus me parle pas de calcul de coordonnées quand tout ce que tu obtiens avec le tien c'est une seule vitesse et 4 trajectoires...

Quand je te mets le nez bien dedans, et bien, tu n'as plus que 'blabla' à sortir ...


Ben quand tu considères que l'ARM a l'essentiel de ces instructions qui prennent 1 cycle, et pour le nombre de boules, ça fait donc un paquet de cycles qui valent qqchose.
Montre nous le même code sur 68000, on comprendra vite pourquoi dans les démos records sur ST ou Mig il n'y a pas ces lectures calculs tests et sauvegardes,
mais juste la lecture d'une valeur par sprite, depuis une table précalculée.
Car là, ça lui prendrait un vrai sacré paquet de cycles au lentissime 68000, de faire comme moi je fais.
Du coup dans ces démos record le code n'est pas ré utilisable pour un jeu ; alors que sur l'Archie : oui.
CQFD, t'es mouché.

[tapomag]

Pour tout faire au CPU, il faut une machine qui suive.
Tout faire au CPU pour les jeux, ce fut la politique PC pendant bien des années.

Ça n'a bien fonctionné qu'à partir du 486 , le 386 était un peu juste sur le sujet.
C'est du bourrin, la carte graphique n'a qu'un rôle passif d'affichage , afin de présenter les résultats du cogito CPU. Il n'y avait que l'astuce du « mode X » pour accélérer le tracé, mais ça restait un simple remplissage de buffer en manipulant les registres latches de la carte VGA (l'avantage était surtout de disposer de 4 buffers 320×200 adressables par la fenêtre du segment de 64ko accessible du DOS sans entrées-sorties à coup de in/out sur la carte).

Mais même sur PC, CPU ultra-puissant ou pas, ça n'a rapidement plus suivi lors de la montée en résolution des jeux. Les cartes graphiques ont repris l'essentiel du traitement avec au départ un peu de blitting, puis avec la 3D, le lissage de textures (3DFX!) et le traitement de l'éclairage (le T&L de nvidia), pour arriver aux shaders actuels qui sont d'ailleurs très amusants à programmer. Même le SIMD (MMX , SSE, AVX et AVX512 arrivé récemment), qui permet un traitement parallélisé avec des registres découpables en unités séparées, n'a jamais tenu la route pour du traitement de pixels, face à un bête APU. Le SIMD connaît un regain d'intérêt en ce moment car il est intégré à tous les langages et c'est de l'optim gratuite car présente dans les libs standards des langages : une comparaison de chaine en C++ ne se fait plus avec un strcmp bourrin comparant octet par octet, mais avec une instruction vectorisée de la classe string qui va comparer rapidement plusieurs caractères avec un système de masque. Mais tout ça, c'est récent et de toutes façons hors de portée du programmeur au quotidien, qui a d'autres choses à faire que de réinventer la roue.

Partir sur la voie du tout CPU avec du matériel plus ancien montre rapidement ses limites. Il est plus intéressant de déporter les traitements sur un coprocesseur dédié que saturer le bus avec de la copie de données. C'est d'ailleurs bien pour cela que l'Amiga a eu bien du mal à avoir son « doom ». Les calculs de projection raycast n'étaient pas hors de sa portée, mais ce qui le tuait était de peupler les bitplans. Un simple buffer unique (le fameux «chunky») eut changé la donne.
Il y « Dread » sur Amiga qui montre de façon admirable ce qu'on peut faire avec l'art martial du détournement des limites.

C'est dommage de vouloir singer le PC qui est de toutes façons un modèle inatteignable pour les 16/32 bits de l'époque, sans carte accélératrice. Il est plus intéressant de faire avec les limites de la machine, et de les utiliser à son avantage.

C'est comme cela qu'on arrive à « shadow of the pig » sur une machine 16 couleurs (avec contraintes) et un z80 à 3mhz:
w w w.youtube.com/watch?v=JdyIJvCvj6o

Et on ne peut pas dire que le VDP du MSX-1 soit un modèle d'efficacité (honnête pour l'époque cependant).

[stapha92]

Ca prend du temps à démarrer car le source s'assemble, voilà tout ...
Ca prend 2 Mo et c'est avec le source en mémoire, tu vois ... il fait déjà 600 ko ce source car je commente vraiment énormément mes sources,
et de plus je charge les graphismes de l'arrière plan.
C'est horrible ? Peut-être oui, sur un écran LCD bas de gamme comme le mien, oui, mais c'est superbe sur un cathodique.
Ca tourne sur une machine à 12 Mhz oui et alors ? Regarde tout ce qu'il y a et dont je n'ai pas besoin pour ce niveau de SOTB,
ça tournera au final sur bécane à 8 Mhz, avec juste ce qu'il faut ( et les arbres ).
Les arbres y seront, c'est ça qu'il faut que je code maintenant. Je l'ai dit, ça ne coûtera quasi rien en plus à afficher, il suffit de penser au bon algo, et je l'ai fait ( bien y penser ).
Non, ce n'est pas plus coloré sur le mig, trèèèèèèès loin de là.
Le seul niveau difficile pour l'Archie c'est celui de la forêt, ce sera d'abord celui-là, du coup

Tu nous le donnes ton code 68000 en 15 cycles stp ? On attend tous la, p'tit génie 

Bla bla bla...

J'ai jamais parler d'un code 68000 en 15 cycles. Je t'ai déjà répondu que je parlais de l'ARM, p'tit con

Continue à te raccrocher au branches : t'en ai à me reprocher des choses que je n'ai jamais dites.

En plus me parle pas de calcul de coordonnées quand tout ce que tu obtiens avec le tien c'est une seule vitesse et 4 trajectoires...

Quand je te mets le nez bien dedans, et bien, tu n'as plus que 'blabla' à sortir ...


Ben quand tu considères que l'ARM a l'essentiel de ces instructions qui prennent 1 cycle, et pour le nombre de boules, ça fait donc un paquet de cycles qui valent qqchose.
Montre nous le même code sur 68000, on comprendra vite pourquoi dans les démos records sur ST ou Mig il n'y a pas ces lectures calculs tests et sauvegardes,
mais juste la lecture d'une valeur par sprite, depuis une table précalculée.
Car là, ça lui prendrait un vrai sacré paquet de cycles au lentissime 68000, de faire comme moi je fais.
Du coup dans ces démos record le code n'est pas ré utilisable pour un jeu ; alors que sur l'Archie : oui.
CQFD, t'es mouché.

CQFD ? Tu sais ce que ça veut dire ?

Donc quand as-tu prouvé que le code est utilisale dans un jeu ? T'en as fait un a nous montrer ? Ou alors un vrai codeur les a utilisées dans un vrai jeu que tu peux nous montrer ?
Tout ce que l'on peut admetttre, c'est que TU es persuadé que c'est réutilisable dans un jeu. Vu la crédibilité que tu as ici (ou ailleurs) autant dire qu'il n'y a rien.

[Invité]

Faux, comme je viens de l'expliquer précédemment.

ah bon ducon, tu viens de dire que tu precalculais X et Y ,donc tu sais clairement pas ce que tu racontes .

'[tu] veux [MON] explication' ... heeuuuu ... faut que tu comprennes un truc : ça fait un moment que je ne prends plus les ordres.
Sauf si tu veux des coups de pieds au cul, là t'inquiète, je peux répondre.
Ah mais c'est déjà ce que je fais post après post, mon p'tit Toukon.
Je répète, n'avoir qu'un seul DMA n'implique en rien de n'avoir qu'un seul canal.
Tu verras, un membre de ton club de tarés pro amibe va bien finir par t'expliquer.
Tu peux aussi remonter les posts, la question 'elle a déjà été vite répondue' lol.

Pirouette,cacahuette, bon t'as encore fait uh HS pour pas répondre car de toutes évidences tu ne sais pas y répondre, mais bon je m'en doutais déjà   

Si ça peut te faire plaisir, c'était dans les faits un abus de langage, je le reconnais.
Ce qui est intéressant c'est que jamais personne ne l'avait mentionné avant que ce codeur sur 3DO ne le découvre.

Abus de langage mon derche, Venant d'un mec qui se prétend êtes un dieu du français ça colle pas,assumes d'être un gros guignol et de dire n'importe quoi, tu fais peut être illusion auprès de tes gogols de potes,mais là ça marche pas .
Quand on sort instructions qui prennent 0  cycles, il n"y a pas d'abus,c'est explicite, surtout en justifiant avec le truc le plus foireux existant .

Zarchouille le mec au record du monde du départ en WE le plus court de l'histoire 

[oiseau de proie]

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.

Non tu es venu ici, comme à chaque fois car tu es un gros con, et parce que tu sais très bien que tu peux maintenant insulter les gens à loisir, arrêtes de te défausser sur des excuses complètement bidons, tu es une sombre merde et un sale con, c'est un fait,qui plus est un sale raciste homophobe en plus .
Donc soit cela vient de ton enfance, soit ton cas relève de la psychiatrie, mais en attendant, tu t'invente une vie, tes vidéo toutes aussi injurieuses que merdique cela n'a rien à voir avec les pseudos gens qui seraient méchant avec toi et ta machine en carton .
Tu as gratifié de ta sale personne même des forums sans fanboys amiga, preuve que tu n'es qu'une raclure qu'il faut éliminer de tous forum, tu n'as rien a faire sur l'espace public .

Bref le cassos par excellence .

Touko se lâche, t'as passé une mauvaise journée?   
Gamopat à son meilleur, j'en suis tout ébaubi; j'utilise cette expression pour te donner raison, elle va bientôt appartenir au language courant 

[oiseau de proie]

Partir sur la voie du tout CPU avec du matériel plus ancien montre rapidement ses limites. Il est plus intéressant de déporter les traitements sur un coprocesseur dédié que saturer le bus avec de la copie de données. C'est d'ailleurs bien pour cela que l'Amiga a eu bien du mal à avoir son « doom ». Les calculs de projection raycast n'étaient pas hors de sa portée, mais ce qui le tuait était de peupler les bitplans. Un simple buffer unique (le fameux «chunky») eut changé la donne.
Il y « Dread » sur Amiga qui montre de façon admirable ce qu'on peut faire avec l'art martial du détournement des limites.

Cette histoire de chunky vs planar est un peu l'arbre qui cache la foret, la vérité c'est que même si le 1200 avait eu un mode chunky, Doom aurait été infaisable dessus, un 68020 est trop faible pour ça. C'est un moteur beaucoup plus lourd que Dread.
C= a été trop radin, couplé au fait que Motorola vendait ses CPU plus chers qu'Intel ce qui n'a pas arrangé la situation...

[dlfrsilver]

Tu devrais nous poster le lien youtube que tu mentionnais en parlant de 8 voies pour le format DW.

J'ai trouvé l'info en 2018. Je crois me rappeller avoir posté sur youtube au sujet de shadow of the beast, et DW a répondu, en indiquant 8 voix. 

2018 => 2022, soit 4 ans, j'ai simplement pas le temps de chercher. Je sais juste qu'après avoir récupéré l'info, j'ai posté sur Amiga Impact l'information, et qu'elle y est toujours.

Mais chercher dans la tonne de coms de Youtube, désolé....

[Copper]

Cette histoire de chunky vs planar est un peu l'arbre qui cache la foret, la vérité c'est que même si le 1200 avait eu un mode chunky, Doom aurait été infaisable dessus, un 68020 est trop faible pour ça. C'est un moteur beaucoup plus lourd que Dread.
C= a été trop radin, couplé au fait que Motorola vendait ses CPU plus chers qu'Intel ce qui n'a pas arrangé la situation...

C'est sur que de toute façon Motorola c'est planté... Même si paradoxalement Wolfeinstein et Doom ont été développés sur Next Cube à base de 68030 ou 68040...

[The_Real_Zarchos]

Parce que là, ce que tu comprends pas Touko, c'est qu'avec ta démarche, Zarchos "kiff sa race" (language courant) en lisant tes messages.
C'est fou d'avoir aussi peu de lucidité !

Je confirme.

Ca me donne la pêche et encore plus le sourire, autour de moi on s'étonne que je pète encore plus le feu que d'habitude.
Mon p'tit Toukon, je t'aime, en réalité.
Stapha, toi aussi je t'aime.
Vos crassitudes me rendent plus beau encore.
Merci.
Je m'aimais déjà bcp, mais grâce à vous je m'estime encore plus dorénavant.
Une autre explication pour Denis : je vous aime comme j'aime l'étron qui sort de mon rectum, et me laisse ainsi meilleur.

[The_Real_Zarchos]

https://www.gamopat-forum.com/t117135p900-etes-vous-prets-pour-les-factures-d-electricite-a-1000eur-par-mois#3553716

[Yoyost]

A priori c'est bien 4 voies d'après DeliPlayer...

Oui, mais ça je le savais déjà. J'attendais juste la confirmation des dires de l'ami dlfrsilver...

[The_Real_Zarchos]

A priori c'est bien 4 voies d'après DeliPlayer...

Oui, mais ça je le savais déjà. J'attendais juste la confirmation des dires de l'ami dlfrsilver...

' caca prout golem golem buveur d'eau chaude pipi caca golem sans âme ' ??

[Copper]

Oui, mais ça je le savais déjà. J'attendais juste la confirmation des dires de l'ami dlfrsilver...

J'ai préféré vérifier par moi même (mais ca prend du temps)

[cryodav76]

Partir sur la voie du tout CPU avec du matériel plus ancien montre rapidement ses limites. Il est plus intéressant de déporter les traitements sur un coprocesseur dédié que saturer le bus avec de la copie de données. C'est d'ailleurs bien pour cela que l'Amiga a eu bien du mal à avoir son « doom ». Les calculs de projection raycast n'étaient pas hors de sa portée, mais ce qui le tuait était de peupler les bitplans. Un simple buffer unique (le fameux «chunky») eut changé la donne.
Il y « Dread » sur Amiga qui montre de façon admirable ce qu'on peut faire avec l'art martial du détournement des limites.

Cette histoire de chunky vs planar est un peu l'arbre qui cache la foret, la vérité c'est que même si le 1200 avait eu un mode chunky, Doom aurait été infaisable dessus, un 68020 est trop faible pour ça. C'est un moteur beaucoup plus lourd que Dread.
C= a été trop radin, couplé au fait que Motorola vendait ses CPU plus chers qu'Intel ce qui n'a pas arrangé la situation...

le 68020 est certe un vieux processeur meme pour un amiga 1200 mais avec de la fast ram ça double sa puissance, en mode planar il ce défend pas si mal.
en mode chunky ça aurai fait tourné un équivalent de doom sans problème, le mode planar est vraiment lourd a gerer pour de la 3d, ça eté longtemps considérer comme infaisable d'ailleurs.
en moteur dedier a 14mhz


et doom avec le wad original en planar tourne, meme si c'est lent voir a 26min



évidement c'est sur code super optimiser rien a voir avec ceux d'époque mais pour quelque chose d'impossible c'est pas mal.

[The_Real_Zarchos]

[le 68020 à 14 Mhz avec de la fast ram]

en mode chunky ça aurai fait tourné un équivalent de doom sans problème

Affirmation totalement gratuite, et stupide.

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

Non : ton code n'est pas pensé pour un jeu. ça fait 30 ans que tu nous le prouve : le shoot promis qui devait exploser la neo-geo n'existe toujours que dans ton esprit malade.

Tes explications ? J'en ai pas vu. J'ai juste vu des affirmations débiles.

30 ans ?
Pourquoi pas 3000 ?
'Promis' ?
T'es pas bien, non ?
Dans le sens où je vous devrais qqchose ?
Ah ah ah merci de m'avoir bien fait rire ... Heureusement les reseaux sociaux existent pour les types comme toi.
Xavier Tardy ne doit rien à des types comme toi, ou à qui que ce soit dans un domaine aussi futile, et surtout non rémunéré.

Tu m'as rien promis à moi et tu nous doit rien, à part la tranquilité. Mais t'as rédigé des tas de trucs, décrit ton futur jeu, fait des tonnes de video, publiés des tonnes de messages, subit des tas de bannissements, possède le record du nombre de WIP merdique, etc... etc...

Et tu viens me parler de réseaux sociaux ! c'est moi qui est mort de rire !

Bizarre, tu l'ouvres pas sur les autres sujets ou sur les réponses ou je t'ai remis en place (comme ton 0 cycle, ou ton pointeur vidéo...). C'était moins drole ?

te dit le mec qui n'a rien à son actif et débite ânerie sur ânerie ... whhhhaaaa que je me gausse.
Merci !

[Copper]

La fastram ne double pas sa puissance c'est juste que ca permet au processeur de tourner normalement

Mais de toute façon c'était complètement stupide de la part de C= de ne pas mettre de fastram avec un 68020...

En revanche je pense quand même que le planar était un sacré boulet pour ce genre de jeu... Car pour le reste doom était quand même optimisé pour ne pas utiliser de FPU par exemple

Mais à partir du moment ou Motorola n'était plus capable de suivre Intel et que même le PowerPC a été une catastrophe... C'était forcément cuit pour l'Amiga et toutes les machines à base de 680x0 de toute façon... Apple a eu de la chance d'en réchapper...

[The_Real_Zarchos]

La fastram ne double pas sa puissance c'est juste que ca permet au processeur de tourner normalement

Mais de toute façon c'était complètement stupide de la part de C= de ne pas mettre de fastram avec un 68020...

En revanche je pense quand même que le planar était un sacré boulet pour ce genre de jeu... Car pour le reste doom était quand même optimisé pour ne pas utiliser de FPU par exemple

Mais à partir du moment ou Motorola n'était plus capable de suivre Intel et que même le PowerPC a été une catastrophe... C'était forcément cuit pour l'Amiga et toutes les machines à base de 680x0 de toute façon... Apple a eu de la chance d'en réchapper...

Merci d'avoir enfin admis les faits : les migs de Commocrotte ne sont que des poubelles technologiques.
On est bien d'accord.

[Copper]

Mais Acorn aussi c'est planté avec son ARM qui ne faisait pas le poids face à Intel et à MIPS non plus dans les années 90

Et Acorn était mauvais en affichage et en puce sonore

[The_Real_Zarchos]

Mais Acorn aussi c'est planté avec son ARM qui ne faisait pas le poids face à Intel et à MIPS non plus dans les années 90

Et Acorn était mauvais en affichage et en puce sonore

Un 'plantage' dont la dernière valorisation connue est 32 milliards de dollars 

Regarde les specs du VIDC20 qui se retrouve dans les RISC PC et on en reparle.

[Copper]

Certes mais ca n'a plus rien à voir et puis ce n'est plus Acorn non plus

Et puis ca ne durera pas éternellement non plus... Déjà quand Apple décidera de passer à autre chose par exemple

Acorn n'a pas réussi à s'imposer en tant que constructeur d'ordinateur...

[tapomag]

Oui c'était cuit pour Commodore avec son 1200. J'en ai acheté un à l'époque parce que je voulais y croire, mais tout au fond de moi je sentais que c'était mal barré. J'aurai au moins un peu pratiqué l'assembleur 68x00 dessus :)

Ils ont abusé avec le 68020, même pour l'époque. Pour une machine censée durer quelques années, c'était le choix mesquin. La fausse économie à la con.

Le Falcon était mieux logé avec son 68030 et son DSP. Il était limité par un bus qui bridait les transferts, si je me souviens bien. Il avait aussi un mode chunky en plus des planars. Ce mode était-il exploitable ? Je lis sur wikipedia que c'était un mode 16 bits, deux octets par pixel, donc surement un mode direct (genre RGB 556) plutôt que palette. Pas mal de données à transférer à chaque passe. Il y a surement eu des doom-likes sur Falcon, mais je ne connais pas du tout cette machine.

[The_Real_Zarchos]

Certes mais ca n'a plus rien à voir et puis ce n'est plus Acorn non plus

Et puis ca ne durera pas éternellement non plus... Déjà quand Apple décidera de passer à autre chose par exemple

De même que les chips d'Intel n'ont plus rien à voir avec ceux de l'époque 
Quand Apple passera à autre chose, on en reparle.
Et puis ARM c'est bien plus que l'usage des IPs par Apple, qui n'est qu'un client parmi d'autres ... 

[tapomag]

AMHA, c'est plus le RiscV qui va faire très mal à ARM.