Re: Amiga/st vs Archimede

[babsimov]

@Babsimov: pour moi la vram, n'est que de la mémoire dédiée au chip graphique ..
La chip ram de l'amiga est en quelque sorte de la vram ..
Rien n'empeche d'utiliser cette vram, sur PCe comme mémoire pour les données (c'est plus lent par contre, car il faut passer par un port) .

La vram semble quand même offrir des avantages par rapport à la dram. Le X68000 en est équipé. Ca n'explique bien sur pas tout, il y a aussi les copros, mais ca doit aider.

Pour le CPU, je parle en perfs que dans le domaine du jeu, car le 68000 n'a pas été développé dans ce sens, mais pour une utilisation générale ..
Le huc 6280, est bien plus performant que le 65C02 .

Le CPU de la nec comme le 65C02 (et 6502), à ses intructions pipelinées, donc dans certains cas les intructions ne prennent que la moitié des cycle qu'elles doivent prendre habituellement .

il suffit juste de voir ce que donne le CPU du C64 qui tourne à juste 0,9 mhz et des brouettes .

En effet, le 6502 était un très bon processeur pour l'époque au niveau rapport performance/fréquence. C'est bien dommage que Commodore n'est pas continué la lignée avec du 32 bits etc...

[Invité]

La vram semble quand même offrir des avantages par rapport à la dram. Le X68000 en est équipé. Ca n'explique bien sur pas tout, il y a aussi les copros, mais ca doit aider.

Oui bien sur à condition qu'elle soit en doublons, vram pour les chips graphiques, et dram pour le CPU ..

Après je suppose que la rapidité des puces joue aussi .

En effet, le 6502 était un très bon processeur pour l'époque au niveau rapport performance/fréquence. C'est bien dommage que Commodore n'est pas continué la lignée avec du 32 bits etc...

Oui,en définitive, le vrai succésseur de la serie 65XX, c'est l'arm ..

Mais je pense que commodore n'avait pas les moyens financiers de développer aussi un nouveau CPU .

[guybrush14]

En tous cas chapeau Touko, sympa ta démo, c'est carrément plus sympa que 3 bouboules.

[MacDeath]

Non.

ça ! c'est un parallax.


Et oui, je m'appelle Olivier et j'ai un Arc chez moi...(histoire vrai)


Blague à part, c'est vrai que la différence entre les 2 (paral. et différentiel) est assez subtiles voire quasi inexistante en fait.


Pour le notion de VRAM c'est pareil.
si techniquement c'est une RAM vraiment dédié et parfois/souvent non accessible par le CPU directement... dans les Fait en employant le terme VRAM on comprend que c'est la RAM utilisé par le chip Video... même si il va la prendre dans la RAM centrale du CPU et fout un système d'arbitrage quelconque pour qu'il n'y ai pas de conflits genre foutre le CPU en wait state comme c'est bien souvent le cas pour les 8bit anglais genre...CPC ou speccy d'ailleurs...


Oui, le bon vieil argument de merde du "muarf c'est du 8bit"...

SegaGénésis... ou même la Jaguar... axaient leurs pub là dessus lol... Plus de bit.


Sauf que bon, pour une machine dédié aux jeux (notamment 2D d'ailleurs)...
un Z80 à 16mhz c'est quand même mieux qu'un 68000 à 8mhz non ?
Et puis bon, d'autres facteurs joues comme les customs donc, et la RAM réellement dispo, etc...


Y'a t'il au moins eut des jeux en "3D" sur CoreGraphix/NEC ?

Oui bien sur à condition qu'elle soit en doublons, vram pour les chips graphiques, et dram pour le CPU ..

Après je suppose que la rapidité des puces joue aussi .

Quand on parle des vieilles machines, avoir la VRAM prise sur la RAM "classique" offre aussi des avantages, surtout pour les ordinateurs d'ailleurs...(qui abusaient de ce trick) mais hélas peu de machine compensaient ça par un overclockage ou quelque chose dans le genre.

(le drâme du CPC voire du ST donc... Drâme, ne pas confondre avec DRAM... )

Exemple des MSX1&2 qui ne savaient même pas scroller alors que le CPC y arrive quand même un peu finalement...


Donc bon, le rapport entre super superCPU qui peu compenser en soft et puces dédiées qui compensent aussi largement, il est vrai qu'à une certaine époque charnière, ça restait relativement kifkif.
d'un côté on avait des limitation sur les trucs spécialisés mais une machine alors équilibré capable d parfois mieux se démerder sur la 3D ou le "pro" (non jeux).
D'un autre côté de superbes machines 2D qui te font de bons jeux d'arcade "facilement"... mais ne font rien d'autre.

Restons honnètes, l'Amiga avait quand même la chance d'être un peu le plus "équilibré vers le haut" finalement, et était quand même très joueur.

Après ça me fait rire que certains disent que leur machine étant la meilleur le reste c'est de la merde.
les 80 des débuts ont eut un gros lot de machines 8 bit vraiment merdiques quand même...

Mais les ST, Miga, Archi... que des bonnes machines finalement.
Et oui même le ST... va faire du MIDI et tu verras que c'est vrai.

[Ricco59_59]

En tous cas chapeau Touko, sympa ta démo, c'est carrément plus sympa que 3 bouboules.

étant programmeur du dimanche , je pense que c'est bien plus que 3 bouboules (tu t'imagines pas le boulot qu'il doit y avoir derrière).

touko, continue ton boulot BB sur amiga

[guybrush14]

En tous cas chapeau Touko, sympa ta démo, c'est carrément plus sympa que 3 bouboules.

étant programmeur du dimanche , je pense que c'est bien plus que 3 bouboules (tu t'imagines pas le boulot qu'il doit y avoir derrière).

touko, continue ton boulot BB sur amiga

C'était juste pour chambrer sur le coté esthétique et féliciter Touko, je suis conscient du travail que cela représente je te rassure :)

[Invité]

Merci pour les encouragements

Tout dev demande du boulot, c'est pour ça que je me suis énervé sur archie quand il traitait les devs sur ST/AMIGA de quasi devs du dimanche,que tout n'était que tricherie .

Pour BB sur amiga ça sera pas demain la veille lol, j'ai un projet de beat them all sur sgx avant .

[MacDeath]

que tout n'était que tricherie .

Comment peut on tricher sur ST ? tout est en soft...

[Invité]

justement tricher ou trics en anglais veut dire simuler des trucs qui ne sont pas prévus à l'origine dans la machine, par des moyens détournés ..

Faire un plasma sur ST,c64,CPC, archimedes, est un tric .
Un scrolling hardware sur ST est un trics .

Le sprites multiplexing est un tric, sauf sur amiga, car c'est prévu par le hardware .

[Lesarthois]

Sauf que à ce moment là c'est une mauvaise traduction...
Trick ici ça serait plutôt "astuce". Triche c'est "cheat".

Côté gamer/joueur : Un cheat code c'est un code de triche, par contre utiliser un raccourci dans un jeu c'est un trick ou une astuce... (sauf si c'est un raccourci par manque de prévoyance du concepteur, mais bon ne compliquons pas l'explication XD).

Et donc justement en programmation j'entends souvent parler d'astuce de programmation, pour simuler des effets, il ne s'agit pas de triche
Au contraire on pourrait dire que les machines qui trichent ce sont celles qui ont des effets câblés

[Invité]

Bah si, tu triches avec le matériel

En prog, tricher, n'a pas le même sens que dans la vie ..

[MacDeath]

trick : trucage ou astuce...
cheat : triche. (mais aussi "tromper" son sa/son conjoint(e))

Mais bon, c'est pareil que pour le paralaxe différentiel, c'est subtil tout ça.

[stapha92]

Justement, je me posais la question à propos du choix de langage de programmation à utiliser. SamuraiCrow, un Amigaiste qu'on peut croiser sur amiga.org ou eab, fait souvent référence à l'AmigaE. Il avait même organisé des cours sur IRC à une époque. Il semblait conseiller ce langage aux personnes désireuses de se lancer dans la programmation de jeu. Mais AmigaE est peut-être un peu trop compliqué pour un "grand débutant", non ?
Quant aux besoins, pour commencer, je pense que ce serait sans doute de tutos dont j'aurais besoin.

Le E est un très bon langage, mais comme il est destiné à faire de la programmation orientée objet, je ne le conseille pas pour débuter. Il vaut mieux maitriser tous les éléments d'un langage procédural classique avant de se lancer dans la POO. On peut bien sur se contenter de programmer le E uniquement de façon procédurale mais dans ce cas ça n'a pas grand interet...

Le langage que je conseillerais est le blitz basic (devenu Amiblitz 3 il me semble). Ne serait-ce que parce que c'est celui dans lequel j'aurais le plus de plaisir à me replonger s'il faut donner un coup de main.:lol:

Il permet une programmation propre et structurée (il possède la création de types qui manque à Amos par exemple). C'est très important pour bien apprendre. Il permet de concevoir des applis qui respectent l'OS aussi bien que des applis qui le contournent. Il possède un assembleur totalement intégré (on met le contenu d'une variable blitz dans un registre processeur en 1 instruction par exemple).

Sinon il y a le C qui reste THE langage. Mais il est ardu...

Quand aux tutos, ça dépend de ce que tu veux faire et, surtout du niveau que tu veux acquérir. Vouloir à terme faire des choses évoluées (démos ou jeux animés) nécessite l'apprentissage du fonctionnement de la machine avant même de commencer à coder quoi que ce soit. Alors que pour se contenter de jeux simples à faire, un apprentissage sommaire de la programmation (niveau BASIC) peut suffire.

[stapha92]

@Touko,

Bravo pour la démo. T'as quand même fait quelques erreurs :

- Tu fais un scrolling horizontal et à plusieurs vitesse : la manipulation du registre d'adresse ne suffira pas sur l'Archimedes...

- Tes sprites sont trop évolués : ceux d'Archimerde ne peuvent pas contenir de trous à cause de son "optimisation". Et il ne peuvent pas gérer de détection de collision. je soupçonne les tiens d'en être capables...

T'as utilisé quel trick pour gérer ton scrolling sans timer à 2 Mhz ?

[stapha92]

Ci dessous un extrait de https://www.youtube.com/all_comments?v=Zw1fnarunoA

I went to the gamopat forum and read some pages of the thread you mentioned. Arf ! It's quite comical ! The most hiliarous are, as usual, those Amigan who teach lessons (they know so much about nothing at all ;-P ) while their technical knowledge about their beloved computer is very approximate (bcp de bétises ds ce thread), so when it comes to "exotic" machines such as Archimedes, hem... Anyway, I think I will join the discussion, to learn more about the Archie. A bientôt sur le ring ! ;-P

Et bien viens me dire ce que j'ai pu dire comme "bétises" sur l'Amiga dans ce thread ? Tu te moques sur youtube mais tu restes bien à l'écart. Pauvre rigolo...

Ah par contre j'ai dit une connerie sur l'Archimede : j'ai calculé le nombre de cycles perdus rien que pour l'écran dans "l'architecture parfaite" de l'Archimedes. En fait, la RAM ne tourne à 8Mhz qu'en mode séquentiel au sein d'une même page. Donc il y a encore plus de cycles perdus que ce que je disais.

Etrangement, Archimerde ne m'a pas corrigé. Tout comme il n'a pas corrigé la personne qui expliquait la complexité d'un circuit graphique avec 256 slots de palette quand elle pensait que c'était le cas sur archimedes. Il s'est juste contenté de dire que ça montrait ce que la machine valait...

[Invité]

@Touko,

Bravo pour la démo. T'as quand même fait quelques erreurs :

- Tu fais un scrolling horizontal et à plusieurs vitesse : la manipulation du registre d'adresse ne suffira pas sur l'Archimedes...

- Tes sprites sont trop évolués : ceux d'Archimerde ne peuvent pas contenir de trous à cause de son "optimisation". Et il ne peuvent pas gérer de détection de collision. je soupçonne les tiens d'en être capables...

Pas de soucis pour moi,une simple détection par bounding box suffit .
Mes sprites sont hard, donc complètement indépendants du décors .

T'as utilisé quel trick pour gérer ton scrolling sans timer à 2 Mhz ?

Non, j'ai pas cette chance d avoir un timer à 2mhz,j ai juste une interruption Hsync

Sur YouTube il m attaque sur la gestion des tiles dans ma demo, lol j ai préféré pas lui répondre, car si on parle de la gestion des tiles sur pce,ça risque de lui faire mal

[ArchieForEver]

@Touko,

Bravo pour la démo. T'as quand même fait quelques erreurs :

- Tu fais un scrolling horizontal et à plusieurs vitesse : la manipulation du registre d'adresse ne suffira pas sur l'Archimedes...

- Tes sprites sont trop évolués : ceux d'Archimerde ne peuvent pas contenir de trous à cause de son "optimisation". Et il ne peuvent pas gérer de détection de collision. je soupçonne les tiens d'en être capables...

T'as utilisé quel trick pour gérer ton scrolling sans timer à 2 Mhz ?

Hello me revoilà.
Avant l'heure, car j'avais dit que je me prenais 15 jours 'off' de ce forum.
Oui : bravo pour la démo :
- pas de scrolling vertical avec tiles
- une résolution graphique HYPER LAMENTABLEMENT BASSE, genre 40% (QUARANTE POUR CENT !) de pixels en moins que sur ma démo.
C'est pour ça d'ailleurs que le rendu visuel est tout simplement immonde.
- pas de soundtracker, mais la lecture d'un CD
On est donc très très loin de ma démo Archie.

Concernant les couleurs des sprites de cette ersatz de démo toutconnienne, je n'ai pas encore regardé les caractéristiques de la PCE, mais là je n'en vois pas bcp.

Ah, au fait, TOUT DE MEME : le point capital : on ne sait toujours pas si ce serait réalisable sur Amiga, mais bon comme ce forum tourne au grand n'importe quoi. Vive la PCE à la rescousse de l'Amiga. Ca c'est une console taillée avec de vrais customs, et pas les petits gadgets qui équipent l'Amiga, et ne lui serviront que pour des démos (rien à voir avec un vrai jeu, pour de multiples raisons).

Et pour mes routines, elles gèrent bien évidemment les trous, et ce, de manière optimale, pour tous les cas possibles.
Stapha, soyons sérieux : ne fais pas les questions et les réponses à ma place, tu n'as pas le niveau pour ça.
La seule petite lumière d'intelligence que je puisse te reconnaitre c'est qu'en effet je ne ferai pas du changement de pointeur vidéo correctement avec mes timers à 2 Mhz, (pour mon histoire de remplissage) mais PRINCIPALEMENT PAS pour les raisons que tu as données.
Je dois préciser à ceux qui ne savent pas lire, que j'avais évoqué le remplissage PARTIEL de face avec cette technique (et oui : il faut utiliser le changement de palette). Ce qui signifie : traiter la périphérie en soft (là où il faut de la précision) et 'l'intérieur' par la méthode hard.

PS : Il n'y a pas que les rounding boxes dans la vie, pour la détection de collisions, vous me faites vraiment pitié.
Sachant que rien que sur ma démo il me reste 15% de temps CPU dispo par VBL, et avec mes routines revisitées ce sera 35%, vos commentaires sont d'une rare médiocrité.

Vous me permettrez de me remettre en congé à nouveau quelques jours.
Ce que je lis de ce forum ne m'invite toujours pas à lui consacrer beaucoup de temps.
Lire des commentaires sur la V-RAM quand personne n'en donne les caractéristiques électroniques, ça me fait doucement rigoler.
Le RISC PC avait un slot pour une barrette de 1 ou 2 Mo de V-RAM.
Et de la vraie V-RAM, hein... pas de la vidéo RAM ou je ne sais quoi.

[65c02]

ahhhh re-voila notre archi préféré :)

Je suis tout à fait d'accord. La demo de touko ne peut être comparé avec celle d'archi.
Il manque le scrolling sinusoidale
non pardon
il manque les sprites sinusoidaux
non pardon
il manque les sprites qui bougent en y

Mais je ne devrais pas critiqué la demo de touko.
C'est un pote à chuck norris

:p

[Invité]

ahhhh re-voila notre archi préféré :)

Mais je ne devrais pas critiqué la demo de touko.
C'est un pote à chuck norris

:p

LOL, j'allais composer les derniers chiffres du num de tel de chuck, t'es passé à 2 doigts de l'emasculation
Bon tu resteras encore un homme pendant quelques posts
Sangoku tue 1 personne en 50 épisodes, chuck tue 50 personnes en 1 épisode .


@archieforever: c'est sur qu'entre 256*256 et 320*256, y'a un gouffre monumental .
a la rigeur tu ferais du 640*480, je comprendrai, mais là, de la pure mauvaise fois bidon .
Franchement la différence visuelle est nulle, y'a qu'a voir les jeux pce façe aux jeux MD.
Comme je l'ai dit peut importe la réso, sur pce ça change rien, j'ai fait ça en 256 pour des raisons pratiques non de perfs .
Cependant moi elle tourne à 60 fps et non 50, sur une machine 8 bit et 8 ko de ram .

lol, si tu veux parler de tiles on peut y aller .
Pour les tiles si on part du principe que tu utilises la même pour tout ton écran, il te faut (pour une tile de 8*8) 64 octets/tile, donc sur un écran 320*256 il te faut raffraichir 1280 tiles*64 octets
soit 81920 octets/frame (merci les 2 mo de ram) ..
Pour faire comme toi j'ai juste besoin de raffraichir la seule tile en vram sur pce soit 32 octets/frame, tu commences à comprendre ???
Donc je peux facilement rafraîchir un écran complet et ce à 60 fps sans le moindre soucis, toi
ça m'étonnerai fort (ou alors tu fais plus rien à côté).

Si on prend 1280 tiles différentes, pour toi ça change pas, pour moi, j'ai juste à modifier 2 octets/tile (emplacement vram+num palette)*1280 = 2560 octets/frame, tu comprends toujours là ??

Donc au pire on a 2560(PCE) vs 81920(archimedes) octets,
au mieux on a 32(PCE) vs 81920(archimedes) octets ..
Et tu prétends pouvoir égaler une NG .

Pour la demo, mon écran ne me prend que 16 tiles 8*8 soit 512 octets .
Donc changer de tile à la volée sur pce n'est en rien une prouesse .

Quoi qu'il arrive en manipulation de tiles, la pce explose ton cpu 32 bit risc, et je parle même pas du reste qu'il faut animer à l'écran ..
Pour le son chui dsl, c'est pas ma faute si acorn a foutu du son DMA qui bouffe tes ressources, car quand tu utilises le DMA pour raffraichir tes samples, ton CPU ne peut rien faire (contrairement à l'amiga) .
et puis j'adore la comparaison d'une musique mod, qui est de base sur archimedes (même si c'est moins bon que sur amiga),avec un générateur de son ..
Tu n'a aucun mérite, car en plus le player n'est même pas de toi .
Comme moi pour la musique CD.

A pour info la PCe est capable de jouer des fichiers XM sur 6 voix (ça bouffe 70% de CPu certe).
Au fait pourquoi tu joues pas un xm avec tes 8 voix plutôt qu'un mod sur 4 ??
Ca bouffe trop de ressources .

Pour les scrollings, tu as raison, j'en ai pas 1 mais 14

pas de scrolling vertical avec tiles

Si au début, pour te montrer que c'est pas un problème .
et je vois pas l'intérêt d'un scroll vertical, avec des parallaxes horizontaux en même temps .
Je l'ai même ralenti pour pas qu'il tourne à la VBL ..

PS : Il n'y a pas que les rounding boxes dans la vie, pour la détection de collisions, vous me faites vraiment pitié.

Non bien sur, mais ça m'étonnerai fort que tu fasses du pixel perfect avec tes 15%
Et vu qu'il te reste si peu, on va rigoler pour ton shoot .

Sachant que rien que sur ma démo il me reste 15% de temps CPU dispo par VBL, et avec mes routines revisitées ce sera 35%, vos commentaires sont d'une rare médiocrité.

C'est sur que comparer avec mes 95% restant ton archimedes il fait pitié .

Concernant les couleurs des sprites de cette ersatz de démo toutconnienne, je n'ai pas encore regardé les caractéristiques de la PCE, mais là je n'en vois pas bcp.

Lol, j'ai à dispo 241 couleurs pour le background et 240 pour les sprite, soit au total 481 couleurs(complètement redéfinissables contrairement à toi), comparé à tes ridicules 256 ..
déjà sans forcer je suis à 289 dans ma demo .
Les couleurs pour les sprites j'en ai utilisé seulement 48 (et déjà ils sont bien plus jolis que dans ta demo),mais rien ne m'empêche d'avoir les 240 couleurs (à part la perte de temps) .

Et puis faut pas déconner, ta demo est loin de montrer que tu affiches 256 couleurs tellement c'est moche.
Mes sprites en 16 couleurs chacun, semblent plus colorés que les tiens en 256..

Ah, au fait, TOUT DE MEME : le point capital : on ne sait toujours pas si ce serait réalisable sur Amiga, mais bon comme ce forum tourne au grand n'importe quoi. Vive la PCE à la rescousse de l'Amiga. Ca c'est une console taillée avec de vrais customs, et pas les petits gadgets qui équipent l'Amiga, et ne lui serviront que pour des démos (rien à voir avec un vrai jeu, pour de multiples raisons).

Euh, ça n'a rien de secours envers l'amiga, mais si je relis bien le topic, c'est bien toi qui me demandait l'évolution de ma demo pce à chaque post, d'un air ironique non ??
Donc tu pensais bien qu'elle ne pouvait(ou que je ne savais) pas le faire ..

Bien sur que dans une demo, l'archimedes peut faire des effets impossibles sur amiga, et l'inverse est vrai aussi, mais en terme de jeux(2D) je pense que l'amiga est bien plus adapté.
Maintenant si tu veux prouver ta théorie sur l'amiga, vas sur un forum de dev amiga, et lances leur un défit ..
Franchement rien de plus facile non, puisque tu es sur de toi (comme tu l'étais pour la PCE) .
et tu peux même demander de l'aide/conseil à ton copain le piaf .

PS: j'ai peut être 50 éditions dans ce post, mais 0 insultes .

[MikeeMike_2008]

ah de retour notre wanker, il ne s'est pas amélioré comme d'hab

au fait archi-wanker on attend tous ton optimisation et débuggage de ton intro (car a ce stade ca n'a rien a voir avec une démo)

[babsimov]

Vous me permettrez de me remettre en congé à nouveau quelques jours.
Ce que je lis de ce forum ne m'invite toujours pas à lui consacrer beaucoup de temps.
Lire des commentaires sur la V-RAM quand personne n'en donne les caractéristiques électroniques, ça me fait doucement rigoler.
Le RISC PC avait un slot pour une barrette de 1 ou 2 Mo de V-RAM.
Et de la vraie V-RAM, hein... pas de la vidéo RAM ou je ne sais quoi.

Toujours égale à toi même.
Au lieu de prendre encore cet air "supérieur", si tu as remarqué une erreur ou inexactitude au sujet de la V-RAM, pourquoi ne pas simplement en donner la définition avec quelques explications ?

Ne serait ce pas plus constructif pour tout le monde et ça pourrait arriver à changer ton image ici je pense.

Bien sur, tu va répondre "google", c'est sur que ça ça aide bien et c'est "convivial" comme comportement.

http://en.wikipedia.org/wiki/VRAM

Malgré que je sois Amigaiste, j'ai réussi à chercher sur google :)

Mais, je suis intéressé par toutes infos complémentaires que tu pourras apporter. Par exemple l'extension de 2 MO de VRAM c'était pour quel modèle d'Archimède, je pense pas pour la série 3020/3010 ?

Si mon souvenir est bon ce type de mémoire coutait horriblement cher à l'époque (1987/88), c'est pour ça que commodore aurait refusé le chipset RANGER conçu par Jay Miner et qui demandait 2 MO de VRAM pour pouvoir afficher 1024x1024 en 128 couleurs :
http://obligement.free.fr/articles/ranger.php
De même que le chipset AAA qui pouvait utiliser la VRAM ou de la DRAM.

[stapha92]

Hello me revoilà.
Avant l'heure, car j'avais dit que je me prenais 15 jours 'off' de ce forum.
Oui : bravo pour la démo :
- pas de scrolling vertical avec tiles

Ah bon ? Y a pas de tiles ? T'es même pas foutu de comprendre la démo de Touko. Non seulement il y en a mais, contrairement à ta démo, il ne s'agit pas du même tile répété sur toute la ligne.
Pas de scrolling vertical : c'est vrai. Sauf qu'un scrolling vertical est plus facile à faire sur ton archimedes qu'un scrolling horizontal. Je sais même pas si toi tu serais capable de faire un scroll horizontal.
Quand au scrollings avec des vitesses différentes, comme celui de Touko tu peux juste en rever avec ta machine, alors que sur le mig c'est courant (et même avec une vitesse différente par ligne...).
Et quand je dis courant, je parle de jeux...

- une résolution graphique HYPER LAMENTABLEMENT BASSE, genre 40% (QUARANTE POUR CENT !) de pixels en moins que sur ma démo.

Apprend à compter : 256x256, c'est 20% de moins que 320x256...
320 x 0,2 = 64 et 320 - 64 = 256. Alors ? On se prend pour un cador mais on ne sait même pas compter ? LOL !

Ah, au fait, TOUT DE MEME : le point capital : on ne sait toujours pas si ce serait réalisable sur Amiga, mais bon comme ce forum tourne au grand n'importe quoi. Vive la PCE à la rescousse de l'Amiga. Ca c'est une console taillée avec de vrais customs, et pas les petits gadgets qui équipent l'Amiga, et ne lui serviront que pour des démos (rien à voir avec un vrai jeu, pour de multiples raisons).

Et quelles sont ces raisons ? Le fait que le copper ne soit qu'un timer ? le fait que les données à afficher doivent être préparées par le processeur avant que le blitter ne puisse les traiter ?
Je cite 2 des énormes erreurs que tu as dites sur le mig. C'est ça les multiples raisons ?
Des jeux qui utilisent les copros du mig, il y en a des tonnes. Même l'OS les utilise. Tu crois qu'ils sont là pourquoi ?

Et Brian the lion (dont rien que la partie shoot ridiculise ton Scorpius...) ?
Et Soccer kid (2 vrais layers : aucun jeux n'y arrive sur l'archimede) ?
Et Shadow of the beast (idem pour les layer + des boss monstrueux + des scrollings différentiels...) ?
Et M. Nutz (des boss qui subissent des zooms qui les font remplir l'écran, des tableaux avec des éléments texturés) ?
Et Kid chaos (1 layer avec plus de parallaxes que sotb et 1 layer plein écran en même temps. une vitesse de scrolling digne de sonic par endroits (les codeurs comprendront la difficulté sans tiles) des layers animés (idem)) ?
Et Battle squadron (avec des boss aussi gros que tes sprites + des tirs qui remplissent l'écran + un scrolling vertical ET horizontal. tout ça en même temps ?

Des jeux que l'Archi ne peut pas reproduire, il y en a des tonnes.
Rien que le tableau de bonus de brian the lion : 2 layer dont un déformé avec un zoom différent sur les X et un scroll qui fait "tourner" ce layer + un layer en avant plan avec des plateformes aussi grosses que tes sprites mais qui, en plus de se déplacer, subissent des rotations en temps réel.
Rien que ce tableau de bonus EXPLOSE ta démo. Et il est IMPOSSIBLE à reproduire sur un Archimedes, même si on se contente d'une démo...
Pas d'accord ? Trouve moi une démo qui le prouve et d'ici là ferme là : n'importe qui peut aller sur le tube (même si ça vaut pas la vrai bécane) et regarder les jeux que j'ai cités...

Alors si tous ces effets n'utilisent pas les copros ("pour les multiples raisons" qui n'existent que dans ton esprit malade) ben ça veut dire que le 68000 est au moins 10x plus puissant que je ne le pensais.

Bizarrement, le ST possède aussi un 68000 et n'a pas de copros : suffit de comparer les jeux sur les 2 bécanes pour se rendre compte de ce que ça apporte... Y a qu'un tordu comme toi pour imaginer le contraire

Et pour mes routines, elles gèrent bien évidemment les trous, et ce, de manière optimale, pour tous les cas possibles.
Stapha, soyons sérieux : ne fais pas les questions et les réponses à ma place, tu n'as pas le niveau pour ça.

Oui je n'ai pas ton niveau. En fait je l'avais quand ça faisait 3 jours que je codais. Depuis j'ai progressé. Ne cherche pas : t'aura jamais mon niveau. En fait t'auras jamais le niveau d'un vrai codeur, y compris ceux qui ont fait DES VRAIS JEUX qui tournent sur un ARCHIMEDE STANDARD. Toi ça fait 2 ans que tu nous parles de ton shoot révolutionnaire et tout ce que tu as obtenu c'est 3 gros sprites (et encore : 3...) qui ont besoin de 2Mo pour pouvoir se bouger... J'ose pas imaginer combien ton jeux nécessitera... N'oublie pas que le controleur RAM de l'Archimedes ne gère que 4 Mo...
En fait t'as vraiment pas LE niveau pour faire un jeu, monsieur "Un scrolling oblige à avoir 3 buffers écrans"...

Maintenant comment tes routines merdiques vont gérer les trous ? Je vais expliquer, ça te permettra de comprendre pourquoi je fais les réponses. Et tu pourras encore m'accuser de désassembler ton code merdique histoire de passer pour un con une fois de plus.

Donc, si tu veux gérer des trous, il va falloir que tes restore multiples sur 32 bits s'arretent au dernier mot de 32 bits calé avant le trou, puis tu passeras en accès 8 bits jusqu'au dernier pixel avant le trou, puis tu reprendra des accès 8 bits après le trou jusqu'à la première adresse calée et tu retrouveras les accès 32 bits.

il y a aussi le fait que tu passes d'un accès séquentiel à un accès aléatoire sur ta RAM à chaque trou mais oublions : tu ne dois même pas être au courant...

Au final, tu auras affiché moins de pixels et, pourtant, ça aura pris plus de temps : trop drole...

Au fait, tu savais que tous les 680x0 avaient des instructions (et encore une fois, pratiquement toutes les instructions, pas juste une pour charger et une pour restorer...) pour accéder en 8, 32 ET 16 bits ? Tu sais : comme sur les ARM qui sont sorti bien après celui que tu expliques être LA perle pour la 2D...

Mais c'est pas tout : ça va augmenter le nombre de routines ! Jusqu'ici il t'en fallait une pour chaque taille de ligne et chaque calage. Il faudra qu'elles soient également adpatées au trous dans les sprites

Tu crois que je ne sais pas pourquoi tes 3 sprites sont pleins ? LOL !

Parce qu'il faut que j'explique aux lecteurs : Cet hurluberlu qui nous parle de précalcs dans les démos sans arret est obligé de les utiliser avec ces routines merdiques.
Non seulement ses sprites doivent être stockés plusieurs fois en fonction du calage (tu précalcule les différentes images) mais même son code est précalculé ! LOL !

Et c'est bien pour ça qu'il a besoin de 2 Mo ! LOL !

Quand je pense que SOTB ne tourne qu'avec 512 Ko et qu'il s'agit d'un vrai jeu (encore une fois : totalement infaisable sur ta machine)...

La seule petite lumière d'intelligence que je puisse te reconnaitre c'est qu'en effet je ne ferai pas du changement de pointeur vidéo correctement avec mes timers à 2 Mhz, (pour mon histoire de remplissage) mais PRINCIPALEMENT PAS pour les raisons que tu as données.
Je dois préciser à ceux qui ne savent pas lire, que j'avais évoqué le remplissage PARTIEL de face avec cette technique (et oui : il faut utiliser le changement de palette). Ce qui signifie : traiter la périphérie en soft (là où il faut de la précision) et 'l'intérieur' par la méthode hard.

Oui c'est ça : tu parles de palette après que je t'ai expliqué que c'est beaucoup mieux que de travailler sur l'adresse. Sauf que pointeur vidéo, ça ne veut pas dire palette mais bien adresse de l'écran (pour les non codeurs : pointeur = adresse en programmation...). Tu essaies de dévier mais tu restes ridicule...

Analysons : pour modifier la palette (tu vois je t'accorde la méthode la meilleure, celle que je t'ai soufflée) il te faudra déclencher une interruption à chaque changement à appliquer, aller chercher la couleur à afficher et l'adresse du registre qui doit la recevoir et écrire la valeur de la couleur; Il faudra ensuite déterminer à quel moment devra se déclencher l'interruption suivante, calculer la valeur de la prochaine couleur à modifier et positionner la prochaine interruption. Il te faut combien de cycles pour faire tout ça ? Réponse : trop, beaucoup beaucoup trop...

Même s'il n'en fallait qu'un, ça serait impossible. Alors que ça se compte en dizaines, beaucoup de dizaines...

Mais ce n'est pas tout ! A chaque interruption, ton ARM serait hyper ralenti puisque son pipeline devrait se recharger : super l'idée d'une interruption multiple avec ton timer révolutionnaire...

Mais ce n'est pas tout ! Tu t'es demandé à quel moment tu devrais faire ces changement ? Et bien il faudrait les synchroniser avec le balayage vidéo. Ce qui implique que tu devrais faire tout ça AU MOMENT MEME OU L'ARCHIMEDES EST LE PLUS LENT ! Et oui : il s'agit du moment précis ou le circuit graphique accède sans arret à la RAM pour lire les données à afficher...

Le plus drole de tout : tu parles de remplissage de faces alors que dans ce domaine, l'Archimedes n'a aucun problème : les jeux 3D hyper fluides sont légions sur cette machine. Donc même si ta méthode était réalisable, elle n'aurait aucun interet...

PS : Il n'y a pas que les rounding boxes dans la vie, pour la détection de collisions, vous me faites vraiment pitié.
Sachant que rien que sur ma démo il me reste 15% de temps CPU dispo par VBL, et avec mes routines revisitées ce sera 35%, vos commentaires sont d'une rare médiocrité.

Vous me permettrez de me remettre en congé à nouveau quelques jours.
Ce que je lis de ce forum ne m'invite toujours pas à lui consacrer beaucoup de temps.
Lire des commentaires sur la V-RAM quand personne n'en donne les caractéristiques électroniques, ça me fait doucement rigoler.
Le RISC PC avait un slot pour une barrette de 1 ou 2 Mo de V-RAM.
Et de la vraie V-RAM, hein... pas de la vidéo RAM ou je ne sais quoi.

Y a pas que les "B"ounding box (bizarre : le B et le R ne sont pas à cotés pourtant...) dans la vie ? C'est vrai dans la vie (t'imagines même pas ce que le blitter peut faire en détection par masque, c'est à dire au pixel près : bizarrement c'est inutile dans les démos...) mais dans ta démo IL N'Y A AUCUNE DETECTION DE COLLISION !!!
Ce qui ne t'empeche pas de proclamer partout sur le net que ta démo prouve que l'Archimedes explose l'amiga (tu as même dit TOUS LES AMIGAS : LOL !!!) en terme de jeux 2D...

Ah mais c'est vrai ! tu as dit la même chose de Scorpius...

Sauf que moi, quand je vois Scorpius, je vois un layer de fond (software le layer : ne recommence pas...) en 4 couleurs qui est une répétion d'un motif horizontalement et verticalement. Je vois un layer d'avant plan qui ne prend jamais plus de la moitié de l'écran : 1/4 en bas et 1/4 en haut. Ah si : il y a des passages qui se resserrent mais 2 remarques : ces passages ne sont jamais très larges et ils n'apparaissent jamais en même temps que les plus gros ennemis (je veux dire les ennemis rouges : gros c'est par rapport aux autres ennemis).

2 layers qui n'ont rien d'impressionnant : les jeux que j'ai cités ont 2 VRAIS LAYERS COMPLETS et s'amusent à y ajouter des effets (il y a d'ailleurs des jeux sur les migs avec plus de layers que ça...).

Quand aux tirs : regarde battle squadron. tu verras ce que sont des tirs... Un grand nombre de ceux de Scorpius sont obtenus avec des tracés de ligne : normal, ça va bien plus vite que de gérer ça avec des sprites.

Scorpius est très impressionnant par rapport à tout ce qu'on voit sur l'Archimedes (et je félicite le travail des codeurs comme toujours) mais quand on le compare au mig, c'est de la rigolade.

Et ne refait pas la réponse du layer du fond répété pour économiser le nombre de disquettes : c'est ENCORE une réponse débile. Personne ne ferait ça uniquement pour cette raison et calcule un peu : une image ENTIERE (donc non répétée) en 4 couleurs en 320x256 prend 20 Ko (non compressée : sur la disquette c'est encore moins...). Tu crois que c'est ça qui obligerait à "passer sur 10 disquettes" ?

Rends toi à l'évidence : Scorpius utilises cette astuce (et d'autres comme l'avant plan à moitié rempli) pour limiter les données à déplacer parce que, comme je l'ai toujours dit, l'Archimedes n'est pas au niveau là-dessus.

En somme, ton jeu référence me donne raison... LOL !

Ah, au fait : d'après certains possesseurs d'Archimedes, Scorpius tourne à 25 i/s sur les machines de base. Y en même un qui te l'a fait remarque sur Youtube. Note que ça ne me pose pas de problème : 25 i/s c'est très fluide (le cinéma est à 24 i/s...). C'est juste pour te rappeler ton habitude de coller du 50 i/s partout...
Une nuance : le 25 i/s peut être pénalisant avec un triple buffer car ça augmente le temps de réaction entre les mouvements du joueur et leur application à l'écran. Je le précise puisque tu crois qu'un scrolling en a forcément besoin...

Et inutile de revenir avec tes 256 couleurs (le mode 256 couleurs le plus nul de l'histoire des modes 256 couleurs...) : tous les jeux que j'ai cité sont, au final, plus coloré que Scorpius ou ta démo...

C'est bien de revenir. Mais on voit tous comment tu cherches la petite bête en déviant ou en disant des betises sur certains points que j'ai avancé et en oubliant la plupart. Et tout le monde voit que j'ai été en mesure de te te moucher sur TOUTES tes attaques. Moi je reprend tout ce que tu dis (y compris pour dire que j'avais tort pour les tiles de ta démo...)

Ne va pas croire que les astuces que je cite correspondent à l'optimisation que dont j'ai parlée (Tu pourrais le croire : tu crois bien que des sprites avec des décalages précalculés pour faire des accès 32 bits en sont une). L'optimisation va quand même un peu plus loin. Babsimov peut en être témoin : il m'a demandé l'explication et, comme je l'avais promis je lui ai envoyée (et ça tient toujours : je l'envoi à tous ceux qui la demanderont. ils pourront être témoins).

@Babsimov :
La VRAM, c'est pour le RISC-PC, il l'a expliqué. Le RISC-PC, c'est cette "superbe" machine qui pouvait recevoir un strong-arm à 233 Mhz + un x86 et qui disposait pour alimenter tout ça d'un bus à 16 Mhz : géniale la conception...

[babsimov]

Ne va pas croire que les astuces que je cite correspondent à l'optimisation que dont j'ai parlée (Tu pourrais le croire : tu crois bien que des sprites avec des décalages précalculés pour faire des accès 32 bits en sont une). L'optimisation va quand même un peu plus loin. Babsimov peut en être témoin : il m'a demandé l'explication et, comme je l'avais promis je lui ai envoyée (et ça tient toujours : je l'envoi à tous ceux qui la demanderont. ils pourront être témoins).

Je confirme en effet que Stapha m'a envoyé son explication. Un long mail détaillé qui présente les optimisations qu'il envisage pour des routines Archimèdes.
Bien sur, n'étant pas programmeur, certaines parties m'ont un peu échappées, mais globalement j'ai compris le principe et ça m'a l'air plutôt bien pensé.
D'ailleurs, je ne comprend pas vraiment pourquoi ArchieForEver refuse le dialogue entre programmeurs et considère qu'il est le seul à avoir "la vérité".
Echanger des astuces, des idées c'est surement le meilleur moyen de progresser en programmation ?

@Babsimov :
La VRAM, c'est pour le RISC-PC, il l'a expliqué.

Mea Culpa, j'avais lu un peu rapidement.

Le RISC-PC, c'est cette "superbe" machine qui pouvait recevoir un strong-arm à 233 Mhz + un x86 et qui disposait pour alimenter tout ça d'un bus à 16 Mhz : géniale la conception...

La dessus, je dirais que le RISCPC était tout de même intéressant dans son principe, j'avais envisagé d'en prendre un après la faillite de Commodore, mais j'ai déjà expliqué ça.
Pour cette histoire de bus, il n'y a pas de machine parfaite. Le bus processeur du 4000 est en fait le même que celui du 3000, le 4000 était un mauvais hack du 3000+ (sans DSP, sans SCSI). Ne parlons pas de l'AGA qu'on nous avait présenté comme une réelle évolution (sur le papier), mais qui dans la pratique n'était qu'un hack lui aussi. C'est sur que c'était acceptable, mais en 1990, pas en 1992. J'étais quand même bien content de mon 1200 :)
Et l'AmigaOS 3.0 était un petit bijou à l'époque, il renvoyait les autres OS loin derrière. Je m'arrête là, je pourrais en écrire beaucoup, mais j'ai déjà eu ce débat dans un autre sujet ici.
Edit : bien entendu je parle des OS grand public, pas des UNIX sur les machines professionnels qui étaient la référence. D'ailleurs beaucoup des idées de l'AmigaOS 1.x à 3.x sont adapté d'Unix. On avait tous les avantages d'Unix sans la lourdeur :)

[Invité]

Pas de scrolling vertical : c'est vrai. Sauf qu'un scrolling vertical est plus facile à faire sur ton archimedes qu'un scrolling horizontal. Je sais même pas si toi tu serais capable de faire un scroll horizontal.

Normal, c'est le seul scrolling hard au pixel que l'archimedes peut faire sans trics(et comme archieforever ne fait jamais de trics) ..

[ArchieForEver]

@babsimov: Oui il s'agit d'une piste audio CD, car j'ai fais une version pour scdrom .
Pour la reso, j'ai utilisé le 256*256, non pas pour des raison de perfs, ça change rien sur la console que l'on soit en 320*256 ou même 512*256, ça consomme juste plus de VRAM .
Le CPU est un Hudson 6280, un custom de 65C02(pas 6502),avec des modes d'adressages sup, et des instructions sup, comme des instructions de transfert de blocs, et effectivement en terme de jeu il vaut (voire dépasse), un 68000 à fréquence égale .
l'affichage est planar, à base de tiles .

@mikeemike_2008: Oui l'intro de BB est plus aboutie techniquement, mais elle est pas finie, et j'ai encore pas mal de ressources, pour rajouter des trucs (ce que ferai), mais j'ai pas passé le même temps dessus non plus .

Ben voyons : ça ne change rien, ah ah la bonne blague.

Touko escroc : ajoute 40% de pixels à ta démo en 256 x 256 pour être en 384 x 240 comme sur ma démo Archimedes, et là, combien te faudra-t-il utiliser de sprites hard pour en voir 3 gros à l'écran ?
Comme les pixels seront plus fins, tu vas bien devoir en utiliser entre 30 et 40% de plus.

Touko, ta place est effectivement au cirque.

Ma 'démo' n'était, je le rappelle, qu'une preview de démo à vocation de tests de mes premières routines.
Quand tu verras ma version 2 en 384 x 288 voire 416 x 288, on va rire.

Sans le vouloir, Touko, tu démontres parfaitement mes idées : un processeur puissant bien programmé fait mieux qu'une petite machine avec ses copros limités.

PS : Je ne parle même pas du coup de la lecture d'un CD audio pour le son, c'est à dire la solution 0% temps CPU ou copro, qui n'a rien à voir avec ma version soundtracker.

[ArchieForEver]

Pas de scrolling vertical : c'est vrai. Sauf qu'un scrolling vertical est plus facile à faire sur ton archimedes qu'un scrolling horizontal. Je sais même pas si toi tu serais capable de faire un scroll horizontal.

Normal, c'est le seul scrolling hard au pixel que l'archimedes peut faire sans trics(et comme archieforever ne fait jamais de trics) ..

Totalement faux : l'Archie sait faire du scroll hard horizontal au pixel près, mais uniquement en mode 256 couleurs (ça tombe bien hein ?).
Pour les autres modes graphiques, c'est à 2 pixels près.

Seuls vous, bandes d'ignares, qui n'en avez jamais eu un dans les mains, pouvez sortir ce genre d'inepties.
Quelqu'un ici avait parlé de cette démo, de 1988, qui démontre bien cela :
Brothers In Arm Demo 2


En passant je rigole de savoir que l'Amiga ne serait jamais capable de gérer autant de bobs qui rebondissent ainsi en temps réel au gré des formes rencontrées.

Ah ! L'Archimedes, ça c'était une vraie machine.
Mais c'est sûr il y aura bien un idiot de service pour me dire qu'il y a plus de bobs dans les démos Amiga avec technique de mémoire de N trames précédentes.
J'en jouis d'avance.

[ArchieForEver]

Ne va pas croire que les astuces que je cite correspondent à l'optimisation que dont j'ai parlée (Tu pourrais le croire : tu crois bien que des sprites avec des décalages précalculés pour faire des accès 32 bits en sont une). L'optimisation va quand même un peu plus loin. Babsimov peut en être témoin : il m'a demandé l'explication et, comme je l'avais promis je lui ai envoyée (et ça tient toujours : je l'envoi à tous ceux qui la demanderont. ils pourront être témoins).

Je confirme en effet que Stapha m'a envoyé son explication. Un long mail détaillé qui présente les optimisations qu'il envisage pour des routines Archimèdes.
Bien sur, n'étant pas programmeur, certaines parties m'ont un peu échappées, mais globalement j'ai compris le principe et ça m'a l'air plutôt bien pensé.
D'ailleurs, je ne comprend pas vraiment pourquoi ArchieForEver refuse le dialogue entre programmeurs et considère qu'il est le seul à avoir "la vérité".
Echanger des astuces, des idées c'est surement le meilleur moyen de progresser en programmation ?

@Babsimov :
La VRAM, c'est pour le RISC-PC, il l'a expliqué.

Mea Culpa, j'avais lu un peu rapidement.

Le RISC-PC, c'est cette "superbe" machine qui pouvait recevoir un strong-arm à 233 Mhz + un x86 et qui disposait pour alimenter tout ça d'un bus à 16 Mhz : géniale la conception...

La dessus, je dirais que le RISCPC était tout de même intéressant dans son principe, j'avais envisagé d'en prendre un après la faillite de Commodore, mais j'ai déjà expliqué ça.
Pour cette histoire de bus, il n'y a pas de machine parfaite. Le bus processeur du 4000 est en fait le même que celui du 3000, le 4000 était un mauvais hack du 3000+ (sans DSP, sans SCSI). Ne parlons pas de l'AGA qu'on nous avait présenté comme une réelle évolution (sur le papier), mais qui dans la pratique n'était qu'un hack lui aussi. C'est sur que c'était acceptable, mais en 1990, pas en 1992. J'étais quand même bien content de mon 1200 :)
Et l'AmigaOS 3.0 était un petit bijou à l'époque, il renvoyait les autres OS loin derrière. Je m'arrête là, je pourrais en écrire beaucoup, mais j'ai déjà eu ce débat dans un autre sujet ici.
Edit : bien entendu je parle des OS grand public, pas des UNIX sur les machines professionnels qui étaient la référence. D'ailleurs beaucoup des idées de l'AmigaOS 1.x à 3.x sont adapté d'Unix. On avait tous les avantages d'Unix sans la lourdeur :)

Je ne discuterai pas avec un type de mauvaise foi qui mélange vérités et contre vérités.
Tu peux te faire berner car tu n'es pas programmeur, mais ce n'est pas mon cas.
Quand j'ai l'intention d'optimiser une routine je me penche dessus et bizarrement, j'y arrive sans aide.
Ce qu'il a vomi sur ce forum jusqu'à ce jour ne m'a rien appris : c'est moi qui ai donné tous les indices, et en retour j'ai eu des solutions nettement moins intéressantes que celles auxquelles je suis parvenue.
Et, GROSSE différence, chez moi c'est codé, ce n'est pas de la 'théorie' formulée sur un forum , par un type qui n'a rien de plus productif à faire de son temps, que de sortir des pages et des pages de galimatias.

Tu vois très bien comment l'Amiga est décrit par le Môsieur comme une machine idéale alors que tu sais très bien que ce n'est absolument pas le cas.

Perso, je n'ai jamais prétendu que les machines d'Acorn étaient idéales, j'ai juste avancé qu'elles étaient meilleures et plus cohérentes que ce qu'offrait la concurrence.

[ArchieForEver]

Vous me permettrez de me remettre en congé à nouveau quelques jours.
Ce que je lis de ce forum ne m'invite toujours pas à lui consacrer beaucoup de temps.
Lire des commentaires sur la V-RAM quand personne n'en donne les caractéristiques électroniques, ça me fait doucement rigoler.
Le RISC PC avait un slot pour une barrette de 1 ou 2 Mo de V-RAM.
Et de la vraie V-RAM, hein... pas de la vidéo RAM ou je ne sais quoi.

Toujours égale à toi même.
Au lieu de prendre encore cet air "supérieur", si tu as remarqué une erreur ou inexactitude au sujet de la V-RAM, pourquoi ne pas simplement en donner la définition avec quelques explications ?

Quel intérêt ?
J'ai par le passé (file 'Archimedes A3020') pris le temps de donner moultes explications, pour que très rapidement ça finisse en eau de boudin.
J'ai mieux à faire que d'éduquer des enfants mal polis, et de toutes façons pas intéressés par la construction, mais la destruction.

[MikeeMike_2008]

tu n'as pas fini de vanter des démos sur archimèdes a 2 balles, 50 bobs a l'écran et t'as la gaulle !!

allez montre moi une démo archimèdes avec plus de 7000 bobs a l'écran (vu que tu as un faibles pour les bobs)

moi je te montre ca sur st (et pense que le mig est bien meilleur )

mais bon le st suffit a botter le cul a l'archimèdes



et pour tes bobs qui rebondissent soit disant infaisable sur mig va faire un tour a 5'20



je vais finir par t'appeler n°9

et sinon elle avance ton optimisation de ta "preview-demo" depuis le temps que tu en parles ....qu'on rigole un peu...

[ArchieForEver]

Scorpius est bien en 256 couleurs, 50 images par seconde, sur un Archimedes de base à 8 Mhz.

Stapha peut toujours tenter de vous enfumer, comme avec le reste de ses propos où il distille ses mensonges fielleux, mais au final il ne fait que montrer qu'il n'y connait pas grand'chose.
Pauvre type.
Et ça veut donner des leçons. Quelle blague.

Achetez vous un Archimedes de base, 8 Mhz, et vous le vérifierez.
Ce n'est pas avec les vidéos capturées en 25 images par seconde, et le débit de Youtube, en 30 images par seconde, que vous apprécierez quoi que ce soit.

Si en plus vous prenez les commentaires Youtube de trolls pro Amiga pour argent comptant, c'est le pompon.
Du petit lait pour les toutcons and co.
Ah mais pardon oui bien sûr ! C'est comme wikipedia : si c'est marqué c'est vrai.

Et vous pensez vraiment que je vais venir consacrer bcp de temps ici à des débiles pro Amiga ?
Tss...tsss...

[MikeeMike_2008]

pas de bol a chaque fois on a un contre exemple en bien mieux que ce que tu proposes sur archimèdes... ca fait chier hein et même sur 8 bits (non pas pro-amiga, maintenant je me mets au st ca suffit .....)

sinon tu connais la série tv avec le fameux n°9 ?