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

[drfloyd]

peut etre sur Amiga 1200 boosté à 50Mhz et 8Mo de RAM.... et refroidissement sous Azote.....

[Tryphon]

Non je pense pas. Juste avec un codeur compétent (mais c'est vrai que ça a pas l'air de courir les rues en ce moment sur Amiga )

[Zarnal]

si vous voulez des boulettes :



le jeu qui rend jaloux tous les Amigaleux

On en a des plus grosses ( exemple à 8:28 )  :

[Invité]

Y'a bcp de boulettes, mais 8x8 (peut être moins) ,et en 1 bp, pas de fond, donc forcément tu peux en mettre un paquet .
Ca reste néanmoins du bon boulot pour gérer tout ça et les collisions .

[Invité]

[ArchieForEver]

Ca a quand même plus de sens de mettre la PCE dans un débat snes vs Md, qu'un spectrum amélioré dans un débat sur des ordis 16 bits 

Tu vois que c'est toi qui troll... 

Tout le monde s'en fout mais j'ai entre 4,4 et 11 millions de pixels (octets) en mode 256 couleurs sur une machine ARM2 à 8 Mhz ( MAIS j'utilise toute la puissance dispo, et vraiment tout dépend de la taille des segments horizontaux : plus c'est petit, moins c'est bon )

Personne s'en fou ..
Une petite démos avec des bobs(et pas des boobs) 32x32 qui bougent ??

Bon, j'ai avancé un peu.
J'en suis à 110 bouboules affichées, j'en ai laissé 80 en fixe, et 30 qui scrollent.
La prochaine étape c'est de toutes les animer comme sur les démos Amiga et STE.
Sur machine à 12 Mhz.
Mode 320 x 256, 16 couleurs
En jouant à 20.833 kHz le module 8 canaux 'Unfertig'
50 fps
Je n'ai pas encore mis le bank switching, c'est pour bientôt.

Voilà ce que ça donne quand on ne programme pas un Archie avec les pieds.
Avec la méthode habituelle, je ne pense pas que plus de 30 serait possible.

Ici au final je pense que 120 boules animées avec une zik 8 canaux en 50 fps c'est jouable.

A 8 Mhz on sera je pense autour de 80.

Ca sera la V1, où les pixels pour chaque boule sont chargés dans les registres à chaque affichage d'une boule.

Après il faudra coder la V2 où les pixels ne sont chargés qu'une fois, et N affichages ont lieu.
Ca devrait être une sacrée claque au niveau du nombre de bouboules totales à l'écran, au final.
Un petit 150 ne m'étonnerait pas.

Enjoy !

[tristan33]

Je n'y connais pas grand chose, mais ton travail m'impressionne !

[ArchieForEver]

Je n'y connais pas grand chose, mais ton travail m'impressionne !

Merci :-)
On pourrait presque croire que j'ai les qualifications pour parler des possibilités de cette machine et estimer qu'elle a été grossièrement sous exploitée en 2D 

[cryodav76]

Ca a quand même plus de sens de mettre la PCE dans un débat snes vs Md, qu'un spectrum amélioré dans un débat sur des ordis 16 bits 

Tu vois que c'est toi qui troll... 

Tout le monde s'en fout mais j'ai entre 4,4 et 11 millions de pixels (octets) en mode 256 couleurs sur une machine ARM2 à 8 Mhz ( MAIS j'utilise toute la puissance dispo, et vraiment tout dépend de la taille des segments horizontaux : plus c'est petit, moins c'est bon )

Personne s'en fou ..
Une petite démos avec des bobs(et pas des boobs) 32x32 qui bougent ??

Bon, j'ai avancé un peu.
J'en suis à 110 bouboules affichées, j'en ai laissé 80 en fixe, et 30 qui scrollent.
La prochaine étape c'est de toutes les animer comme sur les démos Amiga et STE.
Sur machine à 12 Mhz.
Mode 320 x 256, 16 couleurs
En jouant à 20.833 kHz le module 8 canaux 'Unfertig'
50 fps
Je n'ai pas encore mis le bank switching, c'est pour bientôt.

Voilà ce que ça donne quand on ne programme pas un Archie avec les pieds.
Avec la méthode habituelle, je ne pense pas que plus de 30 serait possible.

Ici au final je pense que 120 boules animées avec une zik 8 canaux en 50 fps c'est jouable.

A 8 Mhz on sera je pense autour de 80.

Ca sera la V1, où les pixels pour chaque boule sont chargés dans les registres à chaque affichage d'une boule.

Après il faudra coder la V2 où les pixels ne sont chargés qu'une fois, et N affichages ont lieu.
Ca devrait être une sacrée claque au niveau du nombre de bouboules totales à l'écran, au final.
Un petit 150 ne m'étonnerait pas.

Enjoy !

oua l'archi a un blitter? je savais pas

[ArchieForEver]

L'Amiga n'a pas dit son dernier mot ( maux ) :

[Invité]

Il doit être à limite théorique du blitter là .

[ArchieForEver]

Il doit être à limite théorique du blitter là .

Ah bon ?
Ce serait un coprocesseur avec limitations, comme je l'ai maintes fois déclaré ?
Ca alors, on va en apprendre, aujourd'hui 
11 août 2020, une date qui marquera l'Histoire sur Gamopat

[Invité]

Sois pas bête tout proc/copro a des limites, comme si l'ARM2 n'en avait pas,et comme si l'amiga se résumait au seul blitter .
Je l'ai déjà dit, un machine c'est un tout, pas juste un composant pris tout seul parce que ça arrange .

[ArchieForEver]

Sois pas bête tout proc/copro a des limites, comme si l'ARM2 n'en avait pas .

Ah bah je ne sais pas, comme il paraît qu'il bosse 'gratuitement' ...
Si Babsimov nous lit, il va tomber de haut (et nous sortir 3 pages).
En tout cas, je note, et je m'en félicite, on progresse.

L'ARM2 a évidememnt des limites, la différence c'est que je n'ai jamais affirmé le contraire.

[Invité]

Bah ça reste gratuit, vu que c'est hardware, gratuit ne veut pas dire illimité .
Les sprites sur consoles sont gratuits, ça ne les empêchent pas d'avoir des limites,des contraintes et d'être limités .

[ArchieForEver]

Bah ça reste gratuit, vu que c'est hardware, gratuit ne veut pas dire illimité .

On est bien d'accord.
Une 'subtilité' pas si subtile que cela, et qui semble échapper à bcp.

Et puis 'gratuit' ça reste à voir, puisque ce codeur sur Amiga explique qu'il ne lui reste que de quoi afficher les sprites hardware et de quoi jouer un MOD ... donc 'gratuit' hum hum hum
Si c'était gratuit il aurait toute la puissance du 68000 pour afficher des éléments en software, et là, désolé, il ne peut pas.

[Invité]

Et puis 'gratuit' ça reste à voir, puisque ce coder sur Amiga explique qu'il ne lui reste que de quoi afficher les sprites hardware et de quoi jouer un MOD ... donc 'gratuit' hum hum hum

C'est ce que je dis, il est aux limites de la BP du blitter, donc d'un point de vue hardware il ne reste que le reste du hardware, et plus avec le blitter si il utilisait de la fastram .

[ArchieForEver]

Et puis 'gratuit' ça reste à voir, puisque ce coder sur Amiga explique qu'il ne lui reste que de quoi afficher les sprites hardware et de quoi jouer un MOD ... donc 'gratuit' hum hum hum

C'est ce que je dis, il est aux limites de la BP du blitter, donc d'un point de vue hardware il ne reste que le reste du hardware, et plus avec le blitter si il utilisait de la fastram .

Donc ce n'est pas gratuit puisque cela prend les cycles normalement dispos pour le 68000 si le blitter n'était pas en usage.
CQFD.

[Invité]

Bah c'est comme un CPU, tu peux pas consommer plus de cycles que ceux dont tu disposes, aucun composant ne peut faire plus que le nb de cycles dont il dispose .
Et dans l'amiga c'est surtout la RAM(pour des questions de coûts) qui bride, puisque l'architecture est organisée pour utiliser au maximum de la DRAM 240ns(il me semble) .

[ArchieForEver]

Bah c'est comme un CPU, tu peux pas consommer plus de cycles que ceux dont tu disposes, aucun composant ne peut faire plus que le nb de cycles dont il dispose .

Et le Blitter prend les cycles au 68000 ...
A nouveau : CQFD

L'usage du blitter doit être limité si tu veux quand même garder des cycles pour ton CPU.
C'est bien pour cela que je parle de copro limité et ayant des contraintes d'utilisation.

[Invité]

Non pas du tout,ça peut arriver,mais le blitter utilise les cycles impairs non utilisés par le CPU, c'est pour cela qu'ils fonctionnent en // contrairement au blitter du ST qui lui prend tous les cyles dispos et bloque le CPU .
Avec de la fastram, plus de soucis, le blitter ne prend plus rien sur amiga au CPU .

Donc si sur amiga il peut jouer un mod et utiliser les sprites hard, c'est bien que le CPU n'est pas bloqué .

[ArchieForEver]

Non pas du tout,ça peut arriver,mais le blitter utilise les cycles impairs non utilisés par le CPU, c'est pour cela qu'ils fonctionnent en // contrairement au blitter du ST qui lui prend tous les cyles dispo et bloque le CPU .
Avec de la fastram, plus de soucis, le blitter ne prend plus rien sur amiga .

On va voir ce que le codeur de cette démo 'blitter' Amiga répond, je lui ai posé la question.
Moi j'avais compris qu'il y a un bit de priorité Blitter face au CPU, il doit bien servir à qqchose 

[ArchieForEver]

Non pas du tout,ça peut arriver,mais le blitter utilise les cycles impairs non utilisés par le CPU, c'est pour cela qu'ils fonctionnent en // contrairement au blitter du ST qui lui prend tous les cyles dispos et bloque le CPU .
Avec de la fastram, plus de soucis, le blitter ne prend plus rien sur amiga au CPU .

Donc si sur amiga il peut jouer un mod et utiliser les sprites hard, c'est bien que le CPU n'est pas bloqué .

ah non non non car pour ces 2 tâches il n'y a quasiment besoin de rien en termes d'usage CPU ...
Ca veut dire qu'il n'est pas bloqué à 100%.
'pas bloqué à 100%' <> 'pas bloqué'
Pour les sprites hard et jouer un MOD sur Amiga il faut à peine 2% du CPU.
A nouveau, on va voir ce que ce codeur répond.

[Invité]

Non pas du tout,ça peut arriver,mais le blitter utilise les cycles impairs non utilisés par le CPU, c'est pour cela qu'ils fonctionnent en // contrairement au blitter du ST qui lui prend tous les cyles dispo et bloque le CPU .
Avec de la fastram, plus de soucis, le blitter ne prend plus rien sur amiga .

On va voir ce que le codeur de cette démo 'blitter' Amiga répond, je lui ai posé la question.
Moi j'avais compris qu'il y a un bit de priorité Blitter face au CPU, il doit bien servir à qqchose 

Oui il sert soit à prendre tous les cycles, soit à fonctionner en //, mais cela devient inutile avec de la fastram, puisque cette ram est sur un autre bus accessible seulement par le CPU .

ah non non non car pour ces 2 tâches il n'y a quasiment besoin de rien en termes d'usage CPU ...
Ca veut dire qu'il n'est pas bloqué à 100%.

Bah si, car sur ST tu peux difficilement faire autre chose si tu utilises le blitter au max, sur amiga oui .
Après je sais pas dans quel mode il utilise le blitter pour sa démo,et je répète qu'avec de la fast, tu n'as aucun problème, le CPU peut être utilisé à 100% .

[ArchieForEver]

Non pas du tout,ça peut arriver,mais le blitter utilise les cycles impairs non utilisés par le CPU, c'est pour cela qu'ils fonctionnent en // contrairement au blitter du ST qui lui prend tous les cyles dispo et bloque le CPU .
Avec de la fastram, plus de soucis, le blitter ne prend plus rien sur amiga .

On va voir ce que le codeur de cette démo 'blitter' Amiga répond, je lui ai posé la question.
Moi j'avais compris qu'il y a un bit de priorité Blitter face au CPU, il doit bien servir à qqchose 

Oui il sert soit à prendre tous les cycles, soit à fonctionner en //, mais cela devient inutile avec de la fastram, puisque cette ram est sur un autre bus accessible seulement par le CPU .

Ca c'est super, la FastRam, effectivement.

[Invité]

Le but est d'accéder à la RAM entre les cycles CPU, hors le 68k accède à la RAM tout les 4 cycles en général .

[babsimov]

Sois pas bête tout proc/copro a des limites, comme si l'ARM2 n'en avait pas .

Ah bah je ne sais pas, comme il paraît qu'il bosse 'gratuitement' ...
Si Babsimov nous lit, il va tomber de haut (et nous sortir 3 pages).
En tout cas, je note, et je m'en félicite, on progresse.

Pourquoi je tomberais de haut, tout ce que tu sembles découvrir sur le fonctionnement du blitter avait été expliqué bien avant ton arrivée dans l'un de ces sujets par la personne que tu critiques pour son manques de connaissances. Je parle bien sur de Stapha92. Et si tu avais lu les citations fournies plusieurs fois pour te l'expliquer, tu l'aurais su.

L'ARM2 a évidememnt des limites, la différence c'est que je n'ai jamais affirmé le contraire.

Disons juste que tu as omis de le dire contraire. ARM Power n'est ce pas...

Tout le monde reconnait que l'Archimedes avait un processeur puissant pour son temps et en plus novateur puisque RISC. Mais cracher comme tu le fais sur l'Amiga et sa conception, c'est à mon avis, bien mal reconnaître la qualité du travail de l'équipe de Jay Miner.

[ArchieForEver]

Bouuuhhh il est tout fâché et tout tristounet.
C'est clair que lorsque je parle de jeux comme DarkWood à ne même pas lancer sur une machine à 8 Mhz, tellement ça va être lent, je ne parle pas de la limite de l'ARM.
Non non non, pas du tout.
Qu'est ce qu'on se marre ici, vraiment.

Le gars qui fait la blitter demo sur Amiga a répondu sur YT, il semble que Jay Miner a produit un blitter bien limité...

[ArchieForEver]

Le but est d'accéder à la RAM entre les cycles CPU, hors le 68k accède à la RAM tout les 4 cycles en général .

Le codeur a répondu.
Reste rien pour le CPU dans la blitter démo sur Amiga.
Il est donc 100% bloqué.



Zarchosil y a 5 heures

Could you plot some additional elements if you use the 68000 or you have no cycles left for the CPU ?








RÉPONDRE













Réponse sélectionnée


Aexomer

il y a 3 heures

No, not in this version of the program. The blitter has its 'nasty' bit set, which locks the CPU out of Chip RAM entirely and, apart from a small amount of processing in Fast RAM, it spends the vast majority of each frame waiting on the blitter finishing. With the last blitter operation completing about half a scanline before it's time to go around again, there's zero time left to do anything.



Mince alors 
C'est con, ça calme.
there's zero time left to do anything.
Snif, les larmes m'en coulent. Enfin, presque 
On y aurait presque cru au blitter aux performances miraculeuses de Jay, ce génie.
M'enfin, Stapha92 nous le démontrera sûrement, un jour. Sur papier, évidemment.
De mon côté, pour le 'ARM POWER' qui semble bouleverser notre ami Babsimov, je pense avoir mis les mains dans le cambouis.

Mais je sais, je sais, on résout tous les problèmes avec de la fast RAM.
Encore un truc en plus à acheter pour sortir cette machine de la médiocrité.
Seulement 25 bobs au blitter ah ah ah je me marre, et encore il faut être en résolution timbre poste 320 x 200.

Youkaïdi youkaïda

[Invité]

Reste rien pour le CPU dans la blitter démo sur Amiga.
Le codeur a répondu.

Oui parce qu'il a utilisé le mode nasty,donc il alloue tout pour le blitter juste pour cette version et un bob en plus .

il semble que Jay Miner a produit un blitter bien limité...

Il semble rien du tout, ça c'est toi qui aimes bien conclure cela,je te l'ai dit, c'est la DRAM qui limite pas le blitter ni le reste d'ailleurs .
Avec la même RAM que l'archie,on aurait des perfs quasiment x2 .

[Zarnal]

Le but est d'accéder à la RAM entre les cycles CPU, hors le 68k accède à la RAM tout les 4 cycles en général .

Reste rien pour le CPU dans la blitter démo sur Amiga.
Le codeur a répondu.



Zarchosil y a 5 heures

Could you plot some additional elements if you use the 68000 or you have no cycles left for the CPU ?








RÉPONDRE













Réponse sélectionnée


Aexomer

il y a 3 heures

No, not in this version of the program. The blitter has its 'nasty' bit set, which locks the CPU out of Chip RAM entirely and, apart from a small amount of processing in Fast RAM, it spends the vast majority of each frame waiting on the blitter finishing. With the last blitter operation completing about half a scanline before it's time to go around again, there's zero time left to do anything.




C'est con, ça calme.
there's zero time left to do anything.
Snif, les larmes m'en coulent. Enfin, presque 
On y aurait presque cru au blitter aux performances miraculeuses de Jay, ce génie.
M'enfin, Stapha92 nous le démontrera sûrement, un jour. Sur papier, évidemment.
De mon côté, pour le 'ARM POWER' qui semble bouleverser notre ami Babsimov, je pense avoir mis les mains dans le cambouis.

Mais je sais, je sais, on résout tous les problèmes avec de la fast RAM.
Encore un truc en plus à acheter pour sortir cette machine de la médiocrité.
Seulement 25 bobs au blitter ah ah ah je me marre, et encore il faut être en résolution timbre poste 320 x 200.

Youkaïdi youkaïda

Il faut voir le bon coté des choses, on arrive à 76 bobs en 320*256 * 3 en 16*16.