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

[Copper]

Je supposes que les icones du WB sont sur disquettes, donc les faire en 4 couleurs permettaient de mettre de la couleur sans consomme trop de RAM

Ce que tu as entouré n'est pas sur la disquette... La seule chose qui est sur la disquette ce sont les icônes des applications dans des fichiers .info (ainsi que la bibliothèque appelée icon.library qui gère ces icônes d'ailleurs)

Le Workbench est ce qu'on appelle une tâche résidente et elle est en ROM la commande LoadWB ne fait que la lancer (et on peut d'ailleurs utiliser GoWB qui ne fait que 296 octets à la place de LoadWB / EndCLI)

[Yastuna Lynx]

Ca tombe bien, je n'ai jamais dit que c'était sur la disquette.
Pour la disquette, je parlais des icones (ce que tu confirmes d'ailleurs dans la suite de ton message) 
Avec les éléments entourés, je parlais des éléments de dessin des fenêtres pour lesquels je subodore qu'ils utilisent comme dans le GEM des caractères ASCII pour limiter la taille de la routine.

[Copper]

Je sais bien et en fait c'est pire que ça : Le ST ne permet pas de choisir le nombre de plans alloué ni de les positionner indépendamment les uns des autres dans la RAM.
L'amiga le fait sans soucis et même plus...

Le ST aurait tout aussi bien pu être en chunky. Ne pas l'avoir fait et ne proposer que 2,4 ou 16 couleurs est un non sens...
Et ses plans entrelacés rendent plus difficile les effets adaptés à un affichage par bitplan (comme la transparence par exemple).

Par un gros coup de chance, ça lui permet d'exploiter le movep dans une c2p. Une instruction efficace seulement avec le 68000 et carrément supprimée du 68060.

La démo 18 Years a été écrite pour comparer les performances d'une c2p entre Amiga et ST. Et l'auteur a expliqué que le ST l'emportait largement. Sauf que pour faire une c2p, il faisait comme sur ST pour ensuite désentrelacer les plans avec le blitter. En fait la démo émule un affichage ST sur un Amiga.
Ce qui a fait dire à certains que le ST faisait mieux que l'Amiga. Ceci bien que l'auteur ait expliqué qu'il s'était rendu compte que ça allait bien plus vite avec une autre méthode. En plus, le movep fait ramer la démo sur 68060.

Ce n'est pas une critique du travail de l'auteur qui n'a juste pas pris la bonne direction mais a fourni une belle démo qui tourne pas mal, malgré l'émulation de l'affichage :
Lien vers la démo dans Pouet

Je connais un peu vu qu'à l'époque j'avais fait une routine pour charger des images Degas...

Pour le reste oui c'est un peu étrange de choisir du planar pour ne faire que 4 ou 16 couleurs (pour le monochrome ça change rien) même si j'imagine que ca doit permettre d'adapter plus facilement l'affichage monochromedu GEM sur les modes couleurs (en utilisant qu'un mot sur les 2 ou 4)

Après c'est sur que plein d'effets intéressants avec les bitplanes indépendants ne sont pas faisable sur ST (ou si tu le fais ca n'a aucun intérêt)

Pour le reste programmer un Amiga comme un ST n'a jamais donné de bon résultat c'est sur (et l'inverse est impossible)

[youki]

Le Workbench est ce qu'on appelle une tâche résidente et elle est en ROM la commande LoadWB ne fait que la lancer (et on peut d'ailleurs utiliser GoWB qui ne fait que 296 octets à la place de LoadWB / EndCLI)

ducoup , tu la charge en RAM pour l'utiliser?  Je comprend pas trop le concept là de "tâche  en rom"

une tache , grosso-modo,  c'est une unité d'exécution  (une sorte d'instance pour simplifier) d'un programme qui tourne en RAM.  chaque tâche a ses propres resources allouées .

Et ducoup je n'arrive pas a comprendre cette notion de "tâche résidente" que tu lancerais avec loadWB?

A la limite que tu persiste la tache et ses ressources allouées sur ton harddisk  pour garder son état ,  et que tu la recharge plus tard pour retrouver l'etat précédent , je vois ... mais en ROM??? la je vois pas dutout.

[Copper]

Ca tombe bien, je n'ai jamais dit que c'était sur la disquette.
Pour la disquette, je parlais des icones (ce que tu confirmes d'ailleurs dans la suite de ton message) 
Avec les éléments entourés, je parlais des éléments de dessin des fenêtres pour lesquels je subodore qu'ils utilisent comme dans le GEM des caractères ASCII pour limiter la taille de la routine.

Certains pensent que le WB est sur disquettes donc autant repréciser les choses...

[youki]

pour le reste programmer un Amiga comme un ST n'a jamais donné de bon résultat c'est sur (et l'inverse est impossible)

Oui, programmer une console de jeu comme un ordinateur  c'est possible mais ca ne donne pas de  resultat optimal effectivement.   Et programmer un ordinateur comme une console de jeu  effectivement ca ne marche pas , le hardware n'est pas là.

[stapha92]

Je n'ai jamais parlé de plateforme à 360° puisqu'elle n'en fait que 90. Tes smileys et tes guillemets ne sont que de la manip.

oui comme d'habitude, quand je te prouve le contraire c'est au final soit "je n'ai jamais dit" ou  "tu me l'as pas demandé, mais je le savais"  

Tu tournes en rond : tu ne mets pas de lien vers ma soi-disant affirmation et tu retire de la citation la partie ou je le réclame. Mais tout va bien : tu as mis un smiley de diversion...

Scoop : c'est trop tard. Tu as crié partout que les plateformes faisaient 700 Ko de precalc tout en te vantant de pouvoir les faire tenir (avec 100 étapes...) sur 128 Ko. Tu te penses meilleurs que les gars de Reflexion ?

si en plus tu ne sais pas lire que puis je y faire ?  quand je pense que tu as même été obligé de donner défendre l'overscan de l'Amiga...à partir d'une image humoristique, c'est dire comme ta vie ne doit pas être simple

Pas savoir lire ? Qu'est-ce que j'ai mal lu ?  le 7 ou l'un des deux 0 ? Faut vraiment avoir rien à répondre pour dire ça. 

Avant de réaliser comment tu t'étais planté, t'arrêtais pas de la ramener sur les 700 Ko et le fait que tu m'apprenais leur existence. C'est sur que depuis que tu as réalisé à quel point tu t'étais planté, tu n'en parles plus... Ou c'est ton pavé numérique qui ne marche plus ?

Dévies vers un truc bidon si tu veux et continues à parler de mes compétence en lecture ou de ma vie.. Mais réponds d'abord à la question :

Tu te penses meilleurs que les gars de Reflexion ou c'est juste une incohérence de plus ?

Ce n'est pas que je ne sais pas comment déplacer les fichier sur ST. C'est que le ST ne peut pas le faire. Nuance.

ne peut pas faire ?  donc il y a un coprocesseur spécial dans l'Amiga qui permet de déplacer un fichier ?

Non : dans l'Amiga, il y a un OS qui sait le faire. Y en avait pas dans ton ST.

pourquoi te sens tu obligé de relancer des sujets de 2015, pour lesquels tu avais tort... pour rendre le forum pénible à nouveau ?  c'était reparti dans le bonne humeur et tu viens à nouveau tout gâcher.

Ah bon ? T'as pas fait ta relance mensuelle de "l'amiga n'affiche pas tous les fichier et ma mamie ne sait pas utiliser le cli, donc le ST est meilleur" ?
Désolé, lorsque tu parles de la gestion des fichier, de répondre par. la gestion des fichiers...

C'est bien de répéter que j'avais tort mais faudrait le prouver de temps en temps.

Remarque, t'as bien cru pouvoir prouver une erreur il y a peu et tu as mis du cœur à l'ouvrage. Pour finalement te faire honte...

Plus de 7 500 posts vs moins de 800 : qui fait du blabla ?

parce que contrairement à toi, je ne viens pas ici uniquement tenter de répondre à 1 personne...

Oui et tu en as fait fuir plusieurs, y compris des pro-st, lassés de tes élucubrations et de ton attitude. En tout cas, c'est ce qu'ils ont dit.
Et tu me parles de bonne humeur que je gâcherai...

Tu parlais de "ma vie qui ne doit pas être simple". Et si je parlais de la tienne et en disant que tu la passes ici ? Tu ne trouverais pas ça déplacé ?

[Yastuna Lynx]

Ca tombe bien, je n'ai jamais dit que c'était sur la disquette.
Pour la disquette, je parlais des icones (ce que tu confirmes d'ailleurs dans la suite de ton message) 
Avec les éléments entourés, je parlais des éléments de dessin des fenêtres pour lesquels je subodore qu'ils utilisent comme dans le GEM des caractères ASCII pour limiter la taille de la routine.

Certains pensent que le WB est sur disquettes donc autant repréciser les choses...

Donc si on démarre un Amiga sans disquette, il affiche le workbench comme le ST affiche le bureau GEM ?
Wow, ce topic mauvaise foi m'aura au moins appris quelque chose.

[Copper]

ducoup , tu la charge en RAM pour l'utiliser?  Je comprend pas trop le concept là de "tâche  en rom"

une tache , grosso-modo,  c'est une unité d'exécution  (une sorte d'instance pour simplifier) d'un programme qui tourne en RAM.  chaque tâche a ses propres resources allouées .

Et ducoup je n'arrive pas a comprendre cette notion de "tâche résidente" que tu lancerais avec loadWB?

A la limite que tu persiste la tache et ses ressources allouées sur ton harddisk  pour garder son état ,  et que tu la recharge plus tard pour retrouver l'etat précédent , je vois ... mais en ROM??? la je vois pas dutout.

Après je sais pas exactement comme ça fonctionne dans le détail mais le code de cette tâche lui doit pouvoir être exécuté directement dans la ROM (comme les autres fonctions des différentes bibliothèques en ROM comme exec, dos, graphics, intuition, ...)

Dans le code source de la commande GoWB :

Code:

   /* find the Workbench in ROM */
    struct Resident *wbres=FindResident("workbench.task");

[Copper]

Donc si on démarre un Amiga sans disquette, il affiche le workbench comme le ST affiche le bureau GEM ?
Wow, ce topic mauvaise foi m'aura au moins appris quelque chose.

Non tu ne peux pas démarrer sans disquette mais y'a pas grand chose sur la disquette...

[Copper]

Oui, programmer une console de jeu comme un ordinateur  c'est possible mais ca ne donne pas de  resultat optimal effectivement.   Et programmer un ordinateur comme une console de jeu  effectivement ca ne marche pas , le hardware n'est pas là.

T'auras quand même plus de mal à programmer une MegaDrive comme un ST qu'un Amiga (qui par ailleurs arrive même à émuler le ST)

[youki]

ducoup , tu la charge en RAM pour l'utiliser?  Je comprend pas trop le concept là de "tâche  en rom"

une tache , grosso-modo,  c'est une unité d'exécution  (une sorte d'instance pour simplifier) d'un programme qui tourne en RAM.  chaque tâche a ses propres resources allouées .

Et ducoup je n'arrive pas a comprendre cette notion de "tâche résidente" que tu lancerais avec loadWB?

A la limite que tu persiste la tache et ses ressources allouées sur ton harddisk  pour garder son état ,  et que tu la recharge plus tard pour retrouver l'etat précédent , je vois ... mais en ROM??? la je vois pas dutout.

Après je sais pas exactement comme ça fonctionne dans le détail mais le code de cette tâche lui doit pouvoir être exécuté directement dans la ROM (comme les autres fonctions des différentes bibliothèques en ROM comme exec, dos, graphics, intuition, ...)

le code ,oui il peut etre en rom , mais bon comme n'importe quel code peut etre mis en rom.  Apres quoi que ce soit que tu "executes"  l'instance est forcement en RAM.   A moins que ce soit une sorte de snapshot d'exécution qui soit stocker en rom et qui soit chargé en RAM pour demarrer dans un état pré-determiné. Mais je vois pas trop l'interet de faire ça plutot que d'initialisé avec des valeurs par defaut ce que tu as besoin.  C'est la première fois que j'entend ce concept de "tâche résidente en rom".

Enfin surtout si tu fais un LoadWB , ca doit bien vouloir dire que tu mets quelque chose en RAM.    sinon tu ferais juste un Jump  demarrer ton code en rom.

Stapha , tu sais toi?

[youki]

Oui, programmer une console de jeu comme un ordinateur  c'est possible mais ca ne donne pas de  resultat optimal effectivement.   Et programmer un ordinateur comme une console de jeu  effectivement ca ne marche pas , le hardware n'est pas là.

T'auras quand même plus de mal à programmer une MegaDrive comme un ST qu'un Amiga (qui par ailleurs arrive même à émuler le ST)

Pourquoi?  je pense que tu peux tres bien programmer une megadrive comme un ST ,  mais bon c'est sur les resultats ne seront pas optimaux.

Tu aura la meme chose que les ST port sur Amiga , grosso modo.

[Yastuna Lynx]

Donc si on démarre un Amiga sans disquette, il affiche le workbench comme le ST affiche le bureau GEM ?
Wow, ce topic mauvaise foi m'aura au moins appris quelque chose.

Non tu ne peux pas démarrer sans disquette mais y'a pas grand chose sur la disquette...

Oui je sais bien, et la fameuse disquette s'appelle Workbench non ?
Alors, je veux bien qu'on joue sur les mots en disant "Certains pensent que le WB est sur disquettes donc autant repréciser les choses...", mais ça ne change rien.
L'OS de l'Amiga est découpé en une partie en ROM et une partie sur disquette.

[Copper]

le code ,oui il peut etre en rom , mais bon comme n'importe quel code peut etre mis en rom.  Apres quoi que ce soit que tu "executes"  l'instance est forcement en RAM.   A moins que ce soit une sorte de snapshot d'exécution qui soit stocker en rom et qui soit chargé en RAM pour demarrer dans un état pré-determiné. Mais je vois pas trop l'interet de faire ça plutot que d'initialisé avec des valeurs par defaut ce que tu as besoin.  C'est la première fois que j'entend ce concept de "tâche résidente en rom".

Enfin surtout si tu fais un LoadWB , ca doit bien vouloir dire que tu mets quelque chose en RAM.    sinon tu ferais juste un Jump  demarrer ton code en rom.

Stapha , tu sais toi?

Après tu peux étudier le code source de GoWB si ça t'intéresse

[Copper]

Pourquoi?  je pense que tu peux tres bien programmer une megadrive comme un ST ,  mais bon c'est sur les resultats ne seront pas optimaux.

Tu aura la meme chose que les ST port sur Amiga , grosso modo.

Non je ne crois pas surtout avec le peu de mémoire disponible et le format vidéo bien trop différent mais bon

[rocky007]

Mais tout va bien : tu as mis un smiley de diversion...

ce n'est pas un smiley de diversion, mais un smiley de foutage de gueule, tu n'es pas très perspicace

Tu te penses meilleurs que les gars de Reflexion ou c'est juste une incohérence de plus ?

apparemment toi oui.. moi je n'ai jamais prétendu cela, j'avais juste prétendu (en 2015 )que c'était du précalcul.  et je n'avais que partiellement tort.  Ais-je critiqué le travail de Reflexion ? dis que je faisais mieux ?  ben non...donc range ton pétard mouillé.  quoique je pense que 8 ans plus tard, tu crois toujours que mon troll "je refais Brian the Lion en GFA" était une affirmation ?

mais je comprends très bien comment tu fonctionnes : je te démontre des choses par A+B, et toi tu passes 6 mois à écumer les forums pour venir me répondre.    Je suis content qu'après 8 années, tu as compris que le tube nécessites 11 blocs 320x50 de precalculs.  Pour la rotation  1024 angles,  en effet il faut là aussi des images entière précalculés, exactement comme je te l'ai expliqué dans le passage que tu as cité de moi  et que tu viens ensuite répéter comme un perroquet après avoir vérifié mes propos.  

ah mais oui j'oubliais ta phrase fétiche  "oui je le savais, mais tu ne m'as jamais demandé"
comme avec le blitter... "ah on peut interrompe ?  ah ben mes calculs  de cycles sont à la ramasse ok, mais je le savais"..
"ah une instruction executable en // avec le blitter ?  ridicule"...ah ben tiens, je viens d'apprendre qu'une demo est basée sur cela.    ta réponse surement "ah mais oui tu m'apprends rien, je le savais..."  

Ah bon ? T'as pas fait ta relance mensuelle de "l'amiga n'affiche pas tous les fichier et ma mamie ne sait pas utiliser le cli, donc le ST est meilleur" ?

exactement...si un mamie arrive à taper sa recette de confiture sur un ST et qu'elle n'y arrive pas sur un Amiga, c'est qu'en effet le ST est bien meilleur.  tu commences enfin à comprendre la logique

Désolé, lorsque tu parles de la gestion des fichier, de répondre par. la gestion des fichiers...

C'est bien de répéter que j'avais tort mais faudrait le prouver de temps en temps. 

oh si tu insistes.. moi je veux bien, mais ça va encore terminer à 50 pages "oui mais non ça je le savais, tu déformes, c'est pas le bon contexte , j'ai jamais dit ça"...blablabla

Donc selon Stapha, seul l'Amiga est capable de déplacer un fichier :  "Non : dans l'Amiga, il y a un OS qui sait le faire. Y en avait pas dans ton ST. "



et toujours selon notre expert Stapha, je cite +- "seul l'Amiga peut cacher des fichiers, c'est révolutionnaire que même Windows 11 a dû copier le système d'Amiga"

plus précisément : 

Ah bon ? Il y avait des fichier système et des fichiers cachés sur ST ?

tu vois, tu as fait un seul post et je pointe 2 affirmations fausses... on continue ?   

Remarque, t'as bien cru pouvoir prouver une erreur il y a peu et tu as mis du cœur à l'ouvrage. Pour finalement te faire honte...

en disant que le tube pouvait être reproduit sur ST en précalc avec mirroring et que tu prétendais que c'était impossible ?
tout comme tu ne sais pas toujours pas reconnaitre qu'en effet, on aurait pu precalc ces deux effets en +-700ko, comme je l'ai toujours prétendu ?  

Oui et tu en as fait fuir plusieurs, y compris des pro-st, lassés de tes élucubrations et de ton attitude. En tout cas, c'est ce qu'ils ont dit.
Et tu me parles de bonne humeur que je gâcherai...

et combien se sont barré à cause de toi, le donneur de leçon, qui reprend n'importe qui sur n'importe quoi pour apporter ta vérité absolue...dans un sujet de troll ...   depuis que le doc a demandé d'arrêter ces discussions stériles, combien de fois tu me relances alors qu'on te demande rien ?  tu dors si mal la nuit ?

Tu parlais de "ma vie qui ne doit pas être simple". Et si je parlais de la tienne et en disant que tu la passes ici ? Tu ne trouverais pas ça déplacé ?

justement, cela prouve que j'ai du temps à perdre et que par conséquent ma vie est simple

[youki]

et toujours selon notre expert Stapha, je cite +- "seul l'Amiga peut cacher des fichiers, c'est révolutionnaire que même Windows 11 a dû copier le système d'Amiga"

J'ai pas suivi votre conversation  mais cacher des fichiers on peut le faire sous CP/M  , MS-DOS  et je pense tout les OS que j'ai connu.    Ca date de bien avant l'Amiga ou le ST?

C'est considéré comme révolutionnaire par les Amigateux?

[Copper]

Non absolument pas c'est juste un choix d'afficher des icônes dans des fichiers .info plutôt que d'afficher des fichiers avec des icônes (moches) par défaut

Mais pour un utilisateur non technicien c'est plus logique comme le Menu démarrer qui n'affiche pas tous les fichiers non plus

[rocky007]

oui apparemment, selon Stapha, ne pas pouvoir faire un directory dans WB est un atout, que bill Gate a jalousé jusqu'à aujourd'hui.

[rocky007]

Non absolument pas c'est juste un choix d'afficher des icônes dans des fichiers .info plutôt que d'afficher des fichiers avec des icônes (moches) par défaut

Mais pour un utilisateur non technicien c'est plus logique comme le Menu démarrer qui n'affiche pas tous les fichiers non plus

tellement logique que cela n'existe plus..quand  on me file une USB avec des fichiers dont les extensions sont inconnues, ils s'affichent pourtant bien..quel autre GUI utilisait cette merveilleuse idée d'être obligé d'associer une icone à un fichier pour qu'il apparaisse ?
donc si je fais 20 textes notepad, je me retrouve avec 40 fichiers  : 20 fichiers texte + 20 fichier .info pour qu'ils s'affichent... c'est merveilleux

[stapha92]

ducoup , tu la charge en RAM pour l'utiliser?  Je comprend pas trop le concept là de "tâche  en rom"

une tache , grosso-modo,  c'est une unité d'exécution  (une sorte d'instance pour simplifier) d'un programme qui tourne en RAM.  chaque tâche a ses propres resources allouées .

Et ducoup je n'arrive pas a comprendre cette notion de "tâche résidente" que tu lancerais avec loadWB?

A la limite que tu persiste la tache et ses ressources allouées sur ton harddisk  pour garder son état ,  et que tu la recharge plus tard pour retrouver l'etat précédent , je vois ... mais en ROM??? la je vois pas dutout.

Après je sais pas exactement comme ça fonctionne dans le détail mais le code de cette tâche lui doit pouvoir être exécuté directement dans la ROM (comme les autres fonctions des différentes bibliothèques en ROM comme exec, dos, graphics, intuition, ...)

le code ,oui il peut etre en rom , mais bon comme n'importe quel code peut etre mis en rom.  Apres quoi que ce soit que tu "executes"  l'instance est forcement en RAM.   A moins que ce soit une sorte de snapshot d'exécution qui soit stocker en rom et qui soit chargé en RAM pour demarrer dans un état pré-determiné. Mais je vois pas trop l'interet de faire ça plutot que d'initialisé avec des valeurs par defaut ce que tu as besoin.  C'est la première fois que j'entend ce concept de "tâche résidente en rom".

Enfin surtout si tu fais un LoadWB , ca doit bien vouloir dire que tu mets quelque chose en RAM.    sinon tu ferais juste un Jump  demarrer ton code en rom.

Stapha , tu sais toi?

Un code peut être exécuté sans problème en ROM. Mais il est évident que tout ce qu'il aura besoin de stocker, devra être en RAM. La notion de "résident" est associé à la notion de "code réentrant". Ce qui signifie qu'un même code doit pouvoir s'exécuter plusieurs fois sans que les différentes instances ne se gênent.

Ce qui interdit, par exemple, le stockage d'information dans une zone relative au code ou du code automodifiant. La routine est donc en ROM, mais les infos sont stockées en RAM à un endroit différent pour chaque instance.

Donc tu as raison : quand tu lances un LoadWB, il faut bien qu'il stocke les infos du bureau qu'il va gérer et il va bien le faire en RAM.
Et si tu en lances un deuxième, celui-ci va  faire la même chose. Par contre les 2 exécuteront exactement le même code qui peut donc rester en ROM.

Ça ne se limite pas au code en rom : les librairies chargées en RAM peuvent être allouées plusieurs fois sans que le code n'est besoin d'être copié plusieurs fois SI leur code est réentrant. C'est hérité du monde Unix.

J'espère que j'ai été assez clair.

Dans les faits je suis plutôt d'accord avec toi : une tache réside en RAM puisque ce qui la caractérise, ce sont les ressources qu'elle y stocke. C'est intuitif ou contre-intuitif selon le sens ou on se met. D'autres pourraient donc penser le contraire.

En POO, on parle d'objets en se disant qu'ils représentent une instance de la classe qui les décrits. Mais dans les faits, le compilateur n'alloue de la place que pour les attributs et pas pour les méthodes. C'est donc bien, au moins dans ce cas, les données qui comptent et pas le code.

En développement, on arrive souvent à des débats qui deviennent théologiques...

[Copper]

Je crois que c'est la même chose pour les commandes résidentes du CLI / Shell

[stapha92]

Ben tu prétends que dans ton premier post tu parlais de la probable présence de précalc (la partie en gras). Alors qu'en fait, dans ton premier post, tu as affirmé que tout était en précalc. Y compris le shoot. Pour le shoot, tu as vite compris. Pour le reste, tu as continué à prétendre que TOUT était en précalc.

ah bon, donc par exemple pour mon tube, c'est quoi d'après toi ? du 100% précalc ? pourtant il y a 50% de l'effet qui est fait en software non ? 

Trop fort celle là...
L'effet du tube consiste en un zoom différent pour chaque ligne. Le zoom est obtenu en supprimant des pixels.

Est-ce que pour ton tube, la moitié des pixels sont supprimés par ton code ? Donc la réponse est non. Est-ce que tu supprimes ne serait-ce qu'un seul pixel par code ? Donc c'est 100% précalc.

Ton mirror X ne participe pas à l'effet. En fait il le réduit : tu as du voir sur les étapes intermédiaire que l'image est entière pour chaque ligne. Avec ton mirror X, tu ne peux avoir qu'une demi-image. Rien que ça devrait suffire à le disqualifier.

Juste au-dessus, il y a la citation ou tu dis :
"Et rien du tout infaisable sur ST"

le sujet c'était le tube et la plateforme.. maintenant tu parles refaire le jeu ?  je suppose que c'est une blague, es-tu au courant que le ST n'a pas de scroll hardware, qu'aucun jeu ST n'a 2 layers de scroll en 50 FPS, et à ma connaissance, 1 seul y arrive avec un syncscroll.  donc soit tu es idiot, soit tu es de mauvaise foi

Euh... La citation est la tienne..
Et je l'ai interprétée comme affirmant qu'on pouvait reproduire les 2 effets e même temps. J'ai jamais parlé de refaire le jeu. Ni avant. Ni maintenant.

Quand vas tu cesser de me faire dire des choses que je n'ai jamais dites ?

On a vu ta capacité d'analyse : Du scroll sur ST sans préshift. Des patterns masqués sans masque. Des rectangles qui s'inclinent sans prendre plus de place en largeur.

cf plus haut : ais-je prétendu refaire le jeu ?  qui plus est en GFA en 50 FPS sur un ST

Ah oui : le coup de mettre le GFA sur la table pour que mon affirmation paresse ridicule en ajoutant 3 émojis pour que ça paresse crédible...
Essaies avec 30 emoji, ça marchera peut-être...

Les éléments que tu as oublié n'ont rien à voir avec un jeu. Ils sont nécessaires pour reproduire l'effet avec la méthode que TU as proposée il y a quelques jours...

Ou mieux : trouve moi la citation ou je dis que tu as prétendu refaire le jeu en GFA ?

Tu as dit "Et rien du tout infaisable sur ST". On pourrait conclure que tu parles du jeu mais je suis beau joueur : je me contenterai des 2 effets sans le perso et sans musique. Juste les 2 effets. Et c'est infaisable sur ST. Même en precalc...

Y a même pas le mot GFA dans la citation que tu as choisie. De plus, elle montre bien je ne m'attendais pas à ce que tu refasses le jeu.

Donc je répète : trouve moi la citation ou je dis que tu as prétendu refaire le jeu en GFA.

Et pour rappel, ton tube en GFA tourne en plus de 2 vbl et est tout seul. Pour ton "résultat" tu repasseras...

et non pour rappel mon tube tourne à 50 FPS sans Vsync

C'est faux. La copie que tu fais demande pratiquement une frame entière en assembleur avec un code optimisé. 

Le GFA va aussi vite que de l'assembleur optimisé ?
Il serait peut-être temps que tu découvres le ST...

Et pour rappel tu avais indiqué que ton effet tournait à 23 fps sans sync. Avec la synchro ça ferait 16,6 FPS.

Mais tu peux fournir le code de la copie sans les images et il sera facile de vérifier...

Ah bon ? D'un bord à l'autre, l'animation dure 2 secondes. à 50 fps, ça fait 100 frames. Mais admettons puisque tu es sympa avec moi.

mais t'es super doué toi..donc la rotation de la plateforme est linéaire maintenant ?   donc si la plateforme met 0,5 secondes pour démarrer sa rotation et faire 5 angles pour ensuite s'accélérer et ralentir à la fin, ton calcul est 2 seconds / 50 FPS ?  t'es vraiment doué..

Quand tu fais des attaques perso à coup de "super doué" et de smileys, ça serait bien de pas te planter à chaque fois : l'animation dure 2,5 secondes. Donc ça ferait 125 frames. J'en enlève déjà 25... J'étais pas juste rentré dans le détail. J'oubliais que tu t'accroches à tout ce que tu peux trouver...

Au final, tu retires 55 frames pour arriver à 70. 44% des frames, rien que ça. C'est pas plutôt toi qui fait des calculs bizarres ?
Ah oui, c'est bien toi : il y a quelques jours tu fais tenir tube + plateforme ave 100 étapes en précalc dans 281 Ko...

Et avant que tu dises que je raconte n'importe quoi :

Chronomètres le temps pour 10 oscillations : Plus de 25 secondes...

Et ce n'est pas 1 motif mais 6. Mais admettons puisque tu es sympa avec moi.

non c'est 1 motif central..et comme j'avais déjà expliqué, tu dois ajouter le sol, et les cristaux gauche et droite.. donc 3 motifs.  par besoin de me ré-expliqué ce que je t'ai expliqué.

Ah bon ? Tu peux me montrer le post ou tu m'as expliqué qu'il y avait 3 motifs ? Parce que je peux te sortir celui ou tu calcule avec un seul motif et c'est moi qui t'ai signalé qu'il y en plusieurs...

Maintenant tu dis qu'il y en a 4. C'est bien : encore 50 post et tu comprendras qu'il y en a 6..
.
Tiens, regarde :


Tu les vois maintenant les 6 patterns ? Tu comprends enfin que tu continues à oublier le 1 et le 3 ?

Pour infos, les patterns 4 et 6 prendront plus de place que le pattern central. Et tu les avais oublié de ton calcul magique qui arrive à 128 Ko...

D'autant que, te connaissant, tu as du essayer et constaté que je ne mentais pas : BTL tourne avec 512 Ko de chip.

est qu'est ce que cela change ?   il faut au total 1mo, point barre, tu t'es encore vautré

Et tu oses dire "encore"... tu deviens pathétique. Vraiment...
Ce que ça change, c'est que tu as expliqué à tout le monde que je m'étais planté et que les plateforme prenaient "au moins 600-700 Ko". Sauf que faire tenir ça dans 512 Ko de chip est impossible... Voilà ce que ça change : tu t'es encore vautré.
Et quand je parle de 512 ko, il faut déduire les écrans, copperlist, frames de Brian, musique et, surtout, le tube. Continue Rocky, tu m'aides beaucoup là...

Quel blabla ? Celui ou je dis qu'un mirror en X est lent contrairement au mirror en Y ?
Ou celui ou je te dis que tu as besoin d'une table de 128 Ko ?
Ou celui ou je te dis que tu ne pourras pas mirrorer en Y la partie de l'écran qui a été mirroré en X ?

sauf que tu m'apprends rien du tout, alors que je t'ai appris que ton fameux BTL que tu pensais sans le moindre précalcul est loin du compte

Ah je ne t'apprend rien du tout ? Donc j'en conclu que tu n'as toujours pas compris toutes tes erreurs que je t'ai expliquées.
J'ai parlé de trick$102 dès le début. Et tout le monde sait que le scroll hardware ne joue que sur 16 pixels.
Du coup tu t'es concentré sur les plateformes (tu ne parles que de ça dans le fameux post) jusqu'à que tu tu réalises ton énorme erreur...

tu t'es aussi planté sur les FPS..je t'ai claqué l'effet et enfin tu l'a fermé

Oui ça se voit que je l'ai fermé. Tu nous le donnes ton code magique de 50 fps en GFA que je vérifie ?

Oui, c'est sur tu m'expliques pleins de choses. Mais toujours pas comment tu cases 600-700 Ko dans 300 Ko de chip...

c'est toi qui parles de 300ko.. j'ai toujours parlé de 1mo, donc maintenant que tu es face au mur, tu sors ton chiffres magique de 300ko pour te sortir du pétrin ? 
cadeau :

T'as rien compris : je maintiens les 1 Mo. Et avec un 1 Amiga équipé de 1 Mo en 512+512, il te restera moins 300 Ko de chip max (et je suis trèèèèèèèèèèèèès gentil...).
Comment tu y cases 600-700 Ko de chip alors ?

T'as parlé de 1 Mo sans savoir que BTL tourne avec 512+512. C'est con hein ?
Je te l'ai expliqué, tu as vérifié et tu continues à insister bêtement en prétendant que j'utilise ta tactique connue de tous

En fait je me moque qu'il y ait des étapes ou pas. Le sujet était que, l'effet pouvait être refait en précalc sur ST. j'ai soutenu depuis 8 ans que 1 Mo ne seraient pas suffisant pour les 2 effets. J'avais besoin de préciser que ça tenait en moins d'1 Mo s'il n'y avait que quelques étapes ?

ah ben maintenant c'est plus 300ko, mais on reparle bien de 1Mo.. t'es trop fort, dans le même texte tu arrives à te contredire

Pas du tout : je soutiens qu'il n'est pas possible reproduire l'effet sur ST avec 1 Mo en precalc, même à 25 fps.
Et je soutiens que dans la version Amiga, les plateformes ne peuvent occuper la moitié de la place que tu leur attribues.
Si t'arrives pas à suivre, j'y peux rien. Les 300 Ko, c'était pour répondre à ton post sur les 600-700 Ko.
Tu la ramènes plus sur ça...

donc petit récap  :

tube : 160x100x7 couleurs x 50 étapes = 300ko
 
il reste donc 700ko pour faire 70 rotation d'un motif de 64x64 + bordure gauche 32x64  + bordure droite 32x64
107ko +53ko + 53ko = 213 ko
soit au total 513ko... il te reste donc 500ko pour tes masques, les dépassements de rotations etc.. donc tu prétends toujours que ça ne tient pas en 1mo comme je le dis depuis 8 ans ?

Ah on repart vers les calculs débiles...
C'est bien maintenant tu parles de masques, de dépassement et de 2 autres pattern. Du coup tu es passé de 281 Ko à 513 tout en passant de 100 à 70 frames pour les plateformes. Tu progresses, c'est bien.
Bizarre que ce soit moi, le type "sans bagage", avec "une capacité d'analyse limité", etc... qui ait du te l'expliquer...

Et quand on passe de 281 à 513 Ko, ce n'est pas un "petit récap", c'est un début de rétropédalage

Donc c'est mieux mais ton calcul est encore faux :
Déjà le tube : tu t'accroches à ton mirror x alors que ça ferait passer le tube seul à 2 fps en assembleur optimisé. De plus tu sais maintenant, pour avoir fouillé la RAM, que le tube est une image qui peut être différente sur toute sa largeur. Au moins, pendant 8 ans, tu n'utilisais pas cette échappatoire...
Mais admettons...
Tu as dit que le tube avec 11 étapes précalculées. Comme il y en a une tous les 16 pixels, ça  fait 176 étapes. Grace à toi on connait le bon nombre. Pour infos, ça ferait 1 Mo de precalc pour le tube seul.
Mais admettons...

Ensuite les plateformes :
Déjà tu sais maintenant que c'est 100 étapes, puisque 2,5 secondes.
On va ajouter 1 mot, donc 16 pixels à chaque motif. Ce qui est le minimum dès que ça dépasse d'un pixel.
Chaque motif est sur 3 plans + masque. Donc 4 plans.

1 motif de 64x64, -> 80x64/8*4*100 = 250 Ko
2 Motifs de 32x64 -> 48x64/8*4*100*2 = 300 Ko
2 Motifs de 32x32 -> 48x32/8*4*100*2 = 150
1 motif de 64x32 -> 80x32/8*4*100 = 125 Ko

Ça fait déjà 825 Ko pour les plateformes. Et je n'ai pas compté les dépassements verticaux.

Et, avec ton système de patterns, ça va ramer.

Donc :
Tube  : 300 Ko
Table pour ton mirror X (encore oubliée...) : 128 Ko
Plateforme : 825 ko
Ecran (que tu as oublié quand tu dis "il reste 500 Ko") : 64 Ko
Total : 1 317 Ko. Pour un effet qui sera loin, très loin des 25 fps même avec un code ultra optimisé...

Mais le pire n'est pas là. Tu avait dit :

moi tout ce que je vous, c'est un fond précalculé, ainsi qu'une plateforme précalculée également. Et rien du tout infaisable sur ST.

Sur ST, il faut préshifter les 825 Ko de patterns. On passe à plus de 13 Mo...
Mais tu peux shifter à la volée : tu n'es plus à 1 ou 2 vbl près...

L'argument qui aurait du faire mouche, c'est que pleins de codeurs réputés disent que c'est du temps réel. Tu es le seul à dire le contraire.
Et cet argument, Touko n'a pas eu besoin de moi pour te le sortir...

apprend à me lire, j'ai précisément expliquer cela...

Ah bon ? Tu as précisément expliqué que tous les codeurs disaient que c'était du temps réel à part toi ? Et bien on est d'accord...

par contre toi, en 8 ans, tu n'as pas été foutu de comprendre les précalculs pour les rotations , ni les précalcs entre chaque changement registre scroll.
ah oui j'oubliais ton excuse " je le savais, mais tu me l'as pas demandé "..trop fort, surtout de la part d'un mec qui passe 10 pages a expliquer ce qu'est l'overscan de l'amiga à cause d'une blague photomontage

J'ai parlé du 102 trick dès le début. Quand aux rotations, on a parlé de celles des plateformes pendant 8 ans. Et tu as trouvé combien de précalc M. "700 Ko " pour les plateformes ?

comme la claque avec le blitter ou 3 pages après t'avoir détruit tes calculs "ah mais ça je le savais"

T'arrêtes pas de répéter ça mais t'es toujours pas capable de sortir le post ou tu "détruis mes calculs".
Le "ah mais ça je le savais" concernait l'instruction bonus. Et tu ne m'en as jamais parlé. C'est moi qui l'ai fait quand tu disais que le blitter pouvait bosser en même temps que le cpu.
Je croyais que tu parlais de l'instruction "bonus" totalement inutile mais en fait même pas : pour toi le mode share c'est génial.

Y donc pas eu de claque : juste un Rocky qui tourne en rond pour ne pas admettre que le blitter et le cpu ne peuvent pas bosser conjointement de façon efficace, contrairement à l'Amiga. C'est connu dans le monde ST. tu es le seul à parler de "blitter qui peut travailler en même temps que le cpu avec le mode share". Personne d'autre ne le fait, instruction bonus ou pas.

Donc arrête de réécrire l'histoire et réponds à la fameuse question :
Pourquoi la version avec blitter de Lotus, malgré ses optims, tourne moins vite que la version sas blitter sur ST ? Et pourquoi Dread est si lent sur ST malgré un cpu et un blitter plus rapide ?

En fait, tu devrais arrêter de parler de blitter, parce que, en terme de claque, tu te les mets tout seul :

Je suis pas spécialiste,  mais il me semble que blitter de l'amiga est assez rigide.  Il très pratique pour déplacer des gros blocs de mémoire, mais certainement pas pour aider à faire du polyfill sur des scènes complexes et encore moins pour du C2P.

pour le C2P blitter, peux-tu citer une démo qui utiliser cette technique sur un A500 ?

et idem pour c2p sur un A500 de base, montres-nous donc une routine plus rapide que sur un ST, grâce au blitter...très impatient également

Et y en a des tas comme ça. Juste sur le blitter.
Admires ta propre certitude quand tu expliques ton impatience...

bref tu sais toujours tout, jusqu'à preuve du contraire

Ah non il m'en manque plein ! Par exemple je ne sais pas comment faire tenir 600-700 Ko dans la chip. Et je ne saurais jamais...

 et tu n'as toujours pas réagit sur les erreurs de Touko ?   te te vantais encore il y a peu d'être neutre, d'être ici pour faire apparait la vérité, avoir corrigé dlfrsilver  etc...  il est beau le robin des bois que tu tentes de nous vendre

J'ai déjà corrigé des erreurs formulées du coté pro-amiga, tu l'as reconnu. Par contre, je ne t'ai jamais vu faire la même chose et tu veux me donner des leçons ?

Et non, je suis clairement dans le camp Amiga. Je l'ai toujours dit. Je me suis bien mis dans le camp ST une fois mais je n'ai jamais été neutre.

[touko]

Pour la rotation partielle de la plateforme, c'est la même technique qui a été utilisée pour le boss du niveau 1(le bateau) de pugsy sur MD, la version amiga de ce boss reprend l'effet partiellement,pas de changement de scroll X j'ai l'impression .



Mais globalement c'est pareil, utilisation du scroll Y sur 16 pixels + déformation H via les regs de scroll X .

[dlfrsilver]

L'Amiga 1200 est l'équivalent d'un 386DX. Donc pas de 68000.

le premier 386 date de 1986 et le  386DX de 88..

Certes, mais hors de portée à ce moment là de la plupart des bourses familiales.

[dlfrsilver]

Certes, mais le WB est fluide, alors que le GEM ça se traine.....

piqure de rappel sur la fluidité du GEM vs WB

Steem ne reproduit pas la vitesse réelle de la machine. Un vrai ST ou STE va beaucoup moins vite.

Là ce que tu nous présente, on dirait le GEM qui tourne en émulation sur un Amiga.

[dlfrsilver]

Ben tu prétends que dans ton premier post tu parlais de la probable présence de précalc (la partie en gras). Alors qu'en fait, dans ton premier post, tu as affirmé que tout était en précalc. Y compris le shoot. Pour le shoot, tu as vite compris. Pour le reste, tu as continué à prétendre que TOUT était en précalc.

ah bon, donc par exemple pour mon tube, c'est quoi d'après toi ? du 100% précalc ? pourtant il y a 50% de l'effet qui est fait en software non ? 

Trop fort celle là...
L'effet du tube consiste en un zoom différent pour chaque ligne. Le zoom est obtenu en supprimant des pixels.

Est-ce que pour ton tube, la moitié des pixels sont supprimés par ton code ? Donc la réponse est non. Est-ce que tu supprimes ne serait-ce qu'un seul pixel par code ? Donc c'est 100% précalc.

Ton mirror X ne participe pas à l'effet. En fait il le réduit : tu as du voir sur les étapes intermédiaire que l'image est entière pour chaque ligne. Avec ton mirror X, tu ne peux avoir qu'une demi-image. Rien que ça devrait suffire à le disqualifier.

Juste au-dessus, il y a la citation ou tu dis :
"Et rien du tout infaisable sur ST"

le sujet c'était le tube et la plateforme.. maintenant tu parles refaire le jeu ?  je suppose que c'est une blague, es-tu au courant que le ST n'a pas de scroll hardware, qu'aucun jeu ST n'a 2 layers de scroll en 50 FPS, et à ma connaissance, 1 seul y arrive avec un syncscroll.  donc soit tu es idiot, soit tu es de mauvaise foi

Euh... La citation est la tienne..
Et je l'ai interprétée comme affirmant qu'on pouvait reproduire les 2 effets e même temps. J'ai jamais parlé de refaire le jeu. Ni avant. Ni maintenant.

Quand vas tu cesser de me faire dire des choses que je n'ai jamais dites ?

On a vu ta capacité d'analyse : Du scroll sur ST sans préshift. Des patterns masqués sans masque. Des rectangles qui s'inclinent sans prendre plus de place en largeur.

cf plus haut : ais-je prétendu refaire le jeu ?  qui plus est en GFA en 50 FPS sur un ST

Ah oui : le coup de mettre le GFA sur la table pour que mon affirmation paresse ridicule en ajoutant 3 émojis pour que ça paresse crédible...
Essaies avec 30 emoji, ça marchera peut-être...

Les éléments que tu as oublié n'ont rien à voir avec un jeu. Ils sont nécessaires pour reproduire l'effet avec la méthode que TU as proposée il y a quelques jours...

Ou mieux : trouve moi la citation ou je dis que tu as prétendu refaire le jeu en GFA ?

Tu as dit "Et rien du tout infaisable sur ST". On pourrait conclure que tu parles du jeu mais je suis beau joueur : je me contenterai des 2 effets sans le perso et sans musique. Juste les 2 effets. Et c'est infaisable sur ST. Même en precalc...

Y a même pas le mot GFA dans la citation que tu as choisie. De plus, elle montre bien je ne m'attendais pas à ce que tu refasses le jeu.

Donc je répète : trouve moi la citation ou je dis que tu as prétendu refaire le jeu en GFA.

Et pour rappel, ton tube en GFA tourne en plus de 2 vbl et est tout seul. Pour ton "résultat" tu repasseras...

et non pour rappel mon tube tourne à 50 FPS sans Vsync

C'est faux. La copie que tu fais demande pratiquement une frame entière en assembleur avec un code optimisé. 

Le GFA va aussi vite que de l'assembleur optimisé ?
Il serait peut-être temps que tu découvres le ST...

Et pour rappel tu avais indiqué que ton effet tournait à 23 fps sans sync. Avec la synchro ça ferait 16,6 FPS.

Mais tu peux fournir le code de la copie sans les images et il sera facile de vérifier...

Ah bon ? D'un bord à l'autre, l'animation dure 2 secondes. à 50 fps, ça fait 100 frames. Mais admettons puisque tu es sympa avec moi.

mais t'es super doué toi..donc la rotation de la plateforme est linéaire maintenant ?   donc si la plateforme met 0,5 secondes pour démarrer sa rotation et faire 5 angles pour ensuite s'accélérer et ralentir à la fin, ton calcul est 2 seconds / 50 FPS ?  t'es vraiment doué..

Quand tu fais des attaques perso à coup de "super doué" et de smileys, ça serait bien de pas te planter à chaque fois : l'animation dure 2,5 secondes. Donc ça ferait 125 frames. J'en enlève déjà 25... J'étais pas juste rentré dans le détail. J'oubliais que tu t'accroches à tout ce que tu peux trouver...

Au final, tu retires 55 frames pour arriver à 70. 44% des frames, rien que ça. C'est pas plutôt toi qui fait des calculs bizarres ?
Ah oui, c'est bien toi : il y a quelques jours tu fais tenir tube + plateforme ave 100 étapes en précalc dans 281 Ko...

Et avant que tu dises que je raconte n'importe quoi :

Chronomètres le temps pour 10 oscillations : Plus de 25 secondes...

Et ce n'est pas 1 motif mais 6. Mais admettons puisque tu es sympa avec moi.

non c'est 1 motif central..et comme j'avais déjà expliqué, tu dois ajouter le sol, et les cristaux gauche et droite.. donc 3 motifs.  par besoin de me ré-expliqué ce que je t'ai expliqué.

Ah bon ? Tu peux me montrer le post ou tu m'as expliqué qu'il y avait 3 motifs ? Parce que je peux te sortir celui ou tu calcule avec un seul motif et c'est moi qui t'ai signalé qu'il y en plusieurs...

Maintenant tu dis qu'il y en a 4. C'est bien : encore 50 post et tu comprendras qu'il y en a 6..
.
Tiens, regarde :


Tu les vois maintenant les 6 patterns ? Tu comprends enfin que tu continues à oublier le 1 et le 3 ?

Pour infos, les patterns 4 et 6 prendront plus de place que le pattern central. Et tu les avais oublié de ton calcul magique qui arrive à 128 Ko...

D'autant que, te connaissant, tu as du essayer et constaté que je ne mentais pas : BTL tourne avec 512 Ko de chip.

est qu'est ce que cela change ?   il faut au total 1mo, point barre, tu t'es encore vautré

Et tu oses dire "encore"... tu deviens pathétique. Vraiment...
Ce que ça change, c'est que tu as expliqué à tout le monde que je m'étais planté et que les plateforme prenaient "au moins 600-700 Ko". Sauf que faire tenir ça dans 512 Ko de chip est impossible... Voilà ce que ça change : tu t'es encore vautré.
Et quand je parle de 512 ko, il faut déduire les écrans, copperlist, frames de Brian, musique et, surtout, le tube. Continue Rocky, tu m'aides beaucoup là...

Quel blabla ? Celui ou je dis qu'un mirror en X est lent contrairement au mirror en Y ?
Ou celui ou je te dis que tu as besoin d'une table de 128 Ko ?
Ou celui ou je te dis que tu ne pourras pas mirrorer en Y la partie de l'écran qui a été mirroré en X ?

sauf que tu m'apprends rien du tout, alors que je t'ai appris que ton fameux BTL que tu pensais sans le moindre précalcul est loin du compte

Ah je ne t'apprend rien du tout ? Donc j'en conclu que tu n'as toujours pas compris toutes tes erreurs que je t'ai expliquées.
J'ai parlé de trick$102 dès le début. Et tout le monde sait que le scroll hardware ne joue que sur 16 pixels.
Du coup tu t'es concentré sur les plateformes (tu ne parles que de ça dans le fameux post) jusqu'à que tu tu réalises ton énorme erreur...

tu t'es aussi planté sur les FPS..je t'ai claqué l'effet et enfin tu l'a fermé

Oui ça se voit que je l'ai fermé. Tu nous le donnes ton code magique de 50 fps en GFA que je vérifie ?

Oui, c'est sur tu m'expliques pleins de choses. Mais toujours pas comment tu cases 600-700 Ko dans 300 Ko de chip...

c'est toi qui parles de 300ko.. j'ai toujours parlé de 1mo, donc maintenant que tu es face au mur, tu sors ton chiffres magique de 300ko pour te sortir du pétrin ? 
cadeau :

T'as rien compris : je maintiens les 1 Mo. Et avec un 1 Amiga équipé de 1 Mo en 512+512, il te restera moins 300 Ko de chip max (et je suis trèèèèèèèèèèèèès gentil...).
Comment tu y cases 600-700 Ko de chip alors ?

T'as parlé de 1 Mo sans savoir que BTL tourne avec 512+512. C'est con hein ?
Je te l'ai expliqué, tu as vérifié et tu continues à insister bêtement en prétendant que j'utilise ta tactique connue de tous

En fait je me moque qu'il y ait des étapes ou pas. Le sujet était que, l'effet pouvait être refait en précalc sur ST. j'ai soutenu depuis 8 ans que 1 Mo ne seraient pas suffisant pour les 2 effets. J'avais besoin de préciser que ça tenait en moins d'1 Mo s'il n'y avait que quelques étapes ?

ah ben maintenant c'est plus 300ko, mais on reparle bien de 1Mo.. t'es trop fort, dans le même texte tu arrives à te contredire

Pas du tout : je soutiens qu'il n'est pas possible reproduire l'effet sur ST avec 1 Mo en precalc, même à 25 fps.
Et je soutiens que dans la version Amiga, les plateformes ne peuvent occuper la moitié de la place que tu leur attribues.
Si t'arrives pas à suivre, j'y peux rien. Les 300 Ko, c'était pour répondre à ton post sur les 600-700 Ko.
Tu la ramènes plus sur ça...

donc petit récap  :

tube : 160x100x7 couleurs x 50 étapes = 300ko
 
il reste donc 700ko pour faire 70 rotation d'un motif de 64x64 + bordure gauche 32x64  + bordure droite 32x64
107ko +53ko + 53ko = 213 ko
soit au total 513ko... il te reste donc 500ko pour tes masques, les dépassements de rotations etc.. donc tu prétends toujours que ça ne tient pas en 1mo comme je le dis depuis 8 ans ?

Ah on repart vers les calculs débiles...
C'est bien maintenant tu parles de masques, de dépassement et de 2 autres pattern. Du coup tu es passé de 281 Ko à 513 tout en passant de 100 à 70 frames pour les plateformes. Tu progresses, c'est bien.
Bizarre que ce soit moi, le type "sans bagage", avec "une capacité d'analyse limité", etc... qui ait du te l'expliquer...

Et quand on passe de 281 à 513 Ko, ce n'est pas un "petit récap", c'est un début de rétropédalage

Donc c'est mieux mais ton calcul est encore faux :
Déjà le tube : tu t'accroches à ton mirror x alors que ça ferait passer le tube seul à 2 fps en assembleur optimisé. De plus tu sais maintenant, pour avoir fouillé la RAM, que le tube est une image qui peut être différente sur toute sa largeur. Au moins, pendant 8 ans, tu n'utilisais pas cette échappatoire...
Mais admettons...
Tu as dit que le tube avec 11 étapes précalculées. Comme il y en a une tous les 16 pixels, ça  fait 176 étapes. Grace à toi on connait le bon nombre. Pour infos, ça ferait 1 Mo de precalc pour le tube seul.
Mais admettons...

Ensuite les plateformes :
Déjà tu sais maintenant que c'est 100 étapes, puisque 2,5 secondes.
On va ajouter 1 mot, donc 16 pixels à chaque motif. Ce qui est le minimum dès que ça dépasse d'un pixel.
Chaque motif est sur 3 plans + masque. Donc 4 plans.

1 motif de 64x64, -> 80x64/8*4*100 = 250 Ko
2 Motifs de 32x64 -> 48x64/8*4*100*2 = 300 Ko
2 Motifs de 32x32 -> 48x32/8*4*100*2 = 150
1 motif de 64x32 -> 80x32/8*4*100 = 125 Ko

Ça fait déjà 825 Ko pour les plateformes. Et je n'ai pas compté les dépassements verticaux.

Et, avec ton système de patterns, ça va ramer.

Donc :
Tube  : 300 Ko
Table pour ton mirror X (encore oubliée...) : 128 Ko
Plateforme : 825 ko
Ecran (que tu as oublié quand tu dis "il reste 500 Ko") : 64 Ko
Total : 1 317 Ko. Pour un effet qui sera loin, très loin des 25 fps même avec un code ultra optimisé...

Mais le pire n'est pas là. Tu avait dit :

moi tout ce que je vous, c'est un fond précalculé, ainsi qu'une plateforme précalculée également. Et rien du tout infaisable sur ST.

Sur ST, il faut préshifter les 825 Ko de patterns. On passe à plus de 13 Mo...
Mais tu peux shifter à la volée : tu n'es plus à 1 ou 2 vbl près...

L'argument qui aurait du faire mouche, c'est que pleins de codeurs réputés disent que c'est du temps réel. Tu es le seul à dire le contraire.
Et cet argument, Touko n'a pas eu besoin de moi pour te le sortir...

apprend à me lire, j'ai précisément expliquer cela...

Ah bon ? Tu as précisément expliqué que tous les codeurs disaient que c'était du temps réel à part toi ? Et bien on est d'accord...

par contre toi, en 8 ans, tu n'as pas été foutu de comprendre les précalculs pour les rotations , ni les précalcs entre chaque changement registre scroll.
ah oui j'oubliais ton excuse " je le savais, mais tu me l'as pas demandé "..trop fort, surtout de la part d'un mec qui passe 10 pages a expliquer ce qu'est l'overscan de l'amiga à cause d'une blague photomontage

J'ai parlé du 102 trick dès le début. Quand aux rotations, on a parlé de celles des plateformes pendant 8 ans. Et tu as trouvé combien de précalc M. "700 Ko " pour les plateformes ?

comme la claque avec le blitter ou 3 pages après t'avoir détruit tes calculs "ah mais ça je le savais"

T'arrêtes pas de répéter ça mais t'es toujours pas capable de sortir le post ou tu "détruis mes calculs".
Le "ah mais ça je le savais" concernait l'instruction bonus. Et tu ne m'en as jamais parlé. C'est moi qui l'ai fait quand tu disais que le blitter pouvait bosser en même temps que le cpu.
Je croyais que tu parlais de l'instruction "bonus" totalement inutile mais en fait même pas : pour toi le mode share c'est génial.

Y donc pas eu de claque : juste un Rocky qui tourne en rond pour ne pas admettre que le blitter et le cpu ne peuvent pas bosser conjointement de façon efficace, contrairement à l'Amiga. C'est connu dans le monde ST. tu es le seul à parler de "blitter qui peut travailler en même temps que le cpu avec le mode share". Personne d'autre ne le fait, instruction bonus ou pas.

Donc arrête de réécrire l'histoire et réponds à la fameuse question :
Pourquoi la version avec blitter de Lotus, malgré ses optims, tourne moins vite que la version sas blitter sur ST ? Et pourquoi Dread est si lent sur ST malgré un cpu et un blitter plus rapide ?

En fait, tu devrais arrêter de parler de blitter, parce que, en terme de claque, tu te les mets tout seul :

Je suis pas spécialiste,  mais il me semble que blitter de l'amiga est assez rigide.  Il très pratique pour déplacer des gros blocs de mémoire, mais certainement pas pour aider à faire du polyfill sur des scènes complexes et encore moins pour du C2P.

pour le C2P blitter, peux-tu citer une démo qui utiliser cette technique sur un A500 ?

et idem pour c2p sur un A500 de base, montres-nous donc une routine plus rapide que sur un ST, grâce au blitter...très impatient également

Et y en a des tas comme ça. Juste sur le blitter.
Admires ta propre certitude quand tu expliques ton impatience...

bref tu sais toujours tout, jusqu'à preuve du contraire

Ah non il m'en manque plein ! Par exemple je ne sais pas comment faire tenir 600-700 Ko dans la chip. Et je ne saurais jamais...

 et tu n'as toujours pas réagit sur les erreurs de Touko ?   te te vantais encore il y a peu d'être neutre, d'être ici pour faire apparait la vérité, avoir corrigé dlfrsilver  etc...  il est beau le robin des bois que tu tentes de nous vendre

J'ai déjà corrigé des erreurs formulées du coté pro-amiga, tu l'as reconnu. Par contre, je ne t'ai jamais vu faire la même chose et tu veux me donner des leçons ?

Et non, je suis clairement dans le camp Amiga. Je l'ai toujours dit. Je me suis bien mis dans le camp ST une fois mais je n'ai jamais été neutre.

De toute façon on peut bien retourner tout ça dans le sens qu'on veut, Brian the lion est infaisable sur Atari ST.

[youki]

De toute façon on peut bien retourner tout ça dans le sens qu'on veut, Brian the lion est infaisable sur Atari ST.

Franchement même si c'était faisable , je n'en voudrais pas.  C'est donc pas plus mal si c'est le cas. 

[dlfrsilver]

De toute façon on peut bien retourner tout ça dans le sens qu'on veut, Brian the lion est infaisable sur Atari ST.

Franchement même si c'était faisable , je n'en voudrais pas.  C'est donc pas plus mal si c'est le cas. 

Le jeu est fun et très mignon, avec plein de super effets impossible à faire sur Atari ST. C'est la qu'on voit que les 2 machines sont pas du tout au même niveau...... 

T'en voudrais pas parce que tu boudes tout simplement, t'es juste pas content qu'on te le dise ahaha MDR 

[rocky007]

Est-ce que pour ton tube, la moitié des pixels sont supprimés par ton code ? Donc la réponse est non. Est-ce que tu supprimes ne serait-ce qu'un seul pixel par code ? Donc c'est 100% précalc.

donc d'un coté 50% des pixels supprimé sur Amiga  VS 100% des pixels ajouté avec mon code sur ST

Et je l'ai interprétée comme affirmant qu'on pouvait reproduire les 2 effets e même temps. J'ai jamais parlé de refaire le jeu. Ni avant. Ni maintenant.

ben tu parlais bien de scrolling non ainsi que de la place nécessaire pour les sprites, la musique etc..qui n'auraient pas tenu dans 1mo

Et pour rappel tu avais indiqué que ton effet tournait à 23 fps sans sync. Avec la synchro ça ferait 16,6 FPS.
Mais tu peux fournir le code de la copie sans les images et il sera facile de vérifier...

tu oublies que c'est un demi écran qui est copié.    le code avait été partiellement publié, je n'ai plus rien depuis 8 ans.
mais c'est facile à refaire, tu peux vite le vérifier

. Donc ça ferait 125 frames. J'en enlève déjà 25... J'étais pas juste rentré dans le détail. J'oubliais que tu t'accroches à tout ce que tu peux trouver...

donc si pendant 10 frames la plateforme ne s'est incliné que de 2 angles, pour toi ça fait 10 étapes...de plus en plus fort..t'as toujours rien compris.

Maintenant tu dis qu'il y en a 4. C'est bien : encore 50 post et tu comprendras qu'il y en a 6..

très bien tu as progressé puisque tu disais à la base que c'était un et unique écran de 320x200..tu arrives maintenant à décomposer la plateforme.
pourtant j'avais été clair dans mon disclaimer : chiffres à la louche non destiné à être précision laser..mais tu n'as surement pas lu.   mais continues, analyse mon photomontage avec le moteur d'essuie glace, tu vas surement trouver une erreur dans le nombre de spires du bobinage.

J'ai parlé de trick$102 dès le début. Et tout le monde sait que le scroll hardware ne joue que sur 16 pixels.
Du coup tu t'es concentré sur les plateformes (tu ne parles que de ça dans le fameux post) jusqu'à que tu tu réalises ton énorme erreur...

tu parles du trick depuis le début, mais perfectionniste comme tu l'es, alors qu'on était en plein débat sur le précalc, tu n'as jamais abordé le détail, pourtant principal, qu'il fallait 11 blocs précalcs de 50x320...  quel oubli malheureux toi qui est si pointilleux.. tu comptes les sprites, le copper, le double buffering, la musique...mais tu oublies les précalcs..comme par hasaaaard  

Et quand on passe de 281 à 513 Ko, ce n'est pas un "petit récap", c'est un début de rétropédalage

comparé à tes 60 FPS x 320x 200x 3 secondes x 7 couleurs...tout en fanfaronnant que ça ne tiendra même pas sur 4 mo 

Déjà le tube : tu t'accroches à ton mirror x alors que ça ferait passer le tube seul à 2 fps en assembleur optimisé.
Tu as dit que le tube avec 11 étapes précalculées. Comme il y en a une tous les 16 pixels, ça  fait 176 étapes. Grace à toi on connait le bon nombre. Pour infos, ça ferait 1 Mo de precalc pour le tube seul.
Mais admettons...

ça fait 100 posts que je compte pas le mirror X dans mes calculs.  et pourquoi mélanges-tu les 11 étapes précalculées pour reproduire l'effet en temps réel VS les 50 étapes nécessaires pour du 100% précalculs ?   tu n'arrives plus à suivre ?

je répète :  hauteur du bloc : 50 pixels, soit 50x 160 x 3 = 3ko par image...x 100 hauteur = 300ko

Ensuite les plateformes :
Déjà tu sais maintenant que c'est 100 étapes, puisque 2,5 secondes.
On va ajouter 1 mot, donc 16 pixels à chaque motif. Ce qui est le minimum dès que ça dépasse d'un pixel.
Chaque motif est sur 3 plans + masque. Donc 4 plans.

1 motif de 64x64, -> 80x64/8*4*100 = 250 Ko
2 Motifs de 32x64 -> 48x64/8*4*100*2 = 300 Ko
2 Motifs de 32x32 -> 48x32/8*4*100*2 = 150
1 motif de 64x32 -> 80x32/8*4*100 = 125 Ko

et non puisqu'il n'y a que 70 étapes, ça fait 577 Ko, tu rejoins donc bien mon calcul, merci d'avoir confirmé.

Tube  : 300 Ko
Table pour ton mirror X (encore oubliée...) : 128 Ko

je rêve, le mec il t’additionne les 300ko pour non tube non mirroré X avec 128ko d'une table pour le mirror X, juste pour que les chiffres lui donne raison

Ah bon ? Tu as précisément expliqué que tous les codeurs disaient que c'était du temps réel à part toi ? Et bien on est d'accord...

cites moi où j'ai dit que c'était pas en précalc ( à part mon 1er post de 2015 ) ?  dire qu'il y'a du precalc pour réaliser l'effet ne veut pas dire qu'il est précalc à 100%.  do you speak french ?

T'arrêtes pas de répéter ça mais t'es toujours pas capable de sortir le post ou tu "détruis mes calculs".
Le "ah mais ça je le savais" concernait l'instruction bonus. Et tu ne m'en as jamais parlé. C'est moi qui l'ai fait quand tu disais que le blitter pouvait bosser en même temps que le cpu.

oui oui réécris l'histoire...mais bon si tu y tiens, je veux bien...je voulais préserver un peu de ta dignité
je te cite :

Sur ST, si le blitter est en mode HOG, il faudra attendre qu'il ait terminé pour lancer la division. Et quand elle sera lancé, il faudra attendre qu'elle soit terminée pour relancer le blitter.
Et en mode Share, il faudra attendre une permutation pour lancer la division. Ensuite, le blitter attendra la fin des 64 cycles (=128 cycles cpu...) pour reprendre la main. Donc pendant une soixante de cycles, aucun des 2 n'accédera à la mémoire. On a un blitter qui perdra la moitié des cycles dispo... Et le 68000 mettra plus de temps à faire la division. Elle mettra 256 cycles cpu si elle ne peut pas se terminer avant que le blitter reprenne la main.

je te réponds

Le ST peut lui aussi faire sa division pendant que le blitter tourne.

réponse :

tu m'expliquera comment lancer ta division et, avant qu'elle soit terminée, lancer le blitter. Il fait des instructions en parallèle le 68000 du ST ? C'est parce que c'est une version 8Mhz ?

et évidement, après, tu dirais "ah mais je savais, je vais t'expliquer"..' c'est moi qui te l'ai expliqué"..

et tu ajouteras même que c'est tellement tordu que impossible à mettre en pratique...apparemment si.

rocky007 a écrit:Je suis pas spécialiste,  mais il me semble que blitter de l'amiga est assez rigide.  Il très pratique pour déplacer des gros blocs de mémoire, mais certainement pas pour aider à faire du polyfill sur des scènes complexes et encore moins pour du C2P.

tu vois, j’avoue moi même ne pas être spécialiste et pourtant tu m’agresses continuellement  

J'ai déjà corrigé des erreurs formulées du coté pro-amiga, tu l'as reconnu. Par contre, je ne t'ai jamais vu faire la même chose et tu veux me donner des leçons ?

ah ? tu parles de l'unique fois où tu as corrigé Dlfrsilver ?    donc tout le clan Amiga peut sortir n'importe quelle connerie, Robin des Bois ne corrigera que ceux qui oseront parler en bien du ST.

tu démolis en permanence le ST, quitte à cacher ou déformer pour que cela t'arrange pour valoriser l'Amiga.
Tu ne peux même pas admettre que GEM peut être plus conviviale, c'est pour le mamies : WB c'est mieux parce qu'il cache les fichiers et qu'il n'y a pas de DIRECTORY.