Re: Amiga/st vs Archimede

[ArchieForEver]

@ArchieForEver,



Supposons que tu as besoin de faire une opération entre une constante et un registre (ce qui arrive TRES souvent, tous les programmeurs le savent, même les débutants). Et bien sur 68000, tu te contentes de mettre la constante et c'est tout :
Par exemple OR.L D0,#$F0F0F0F0

Sur ARM, tu es obligé de stocker ta constante dans un registre. Et hop un registre de perdu ! (et du temps, et de la place aussi...). Le plus drole, c'est qu'il te faudra plusieurs instruction pour affecter cette valeur...

Ah ouais ?
Mais on est encore une fois de plus dans le grand n'importe quoi

BIC R3,R5,#255 :R3=R5 avec 8 bits bas mis à 0
AND R2,R1,#24 :R2=R1 R1 AND 24

RSB R2,R3,#7 : R2=7-R3

c'est quoi à ton avis ?
Tu ne connais rien à la programmation ARM et tu trolles ici comme si tu étais un spécialiste, c'est une blague.

Tu ne connais pas l'ARM et tu déblatères.

Oui c'est ça... Tu peux donner un exemple avec une constante 32 bits ? Utiliser la valeur que j'ai donné par exemple ?

La valeur que tu as donnée, peut-être, faudrait que je vérifie.
Au pire je la formerai en 3 MOV, pas de quoi fouetter un chat.
Les cas où on doit travailler directement avec une constante 32 bits, ce n'est quand même pas la majorité.
Et tu t'abstiens bien de me donner la taille de l'instruction, et le nombre de cycles.
QQchose me dit que ce sera très mauvais par rapport à un Archie, alors vas y, stp donne.

Sur l'ARM on peut évidemment avoir en constante des valeurs 32 bits, elles doivent répondre à des règles de divisabilité par 2^n.
En gros tu parles d'un truc dont tout le monde se fout en programmation, ou presque, tu n'as que ça pour défendre ton miga.
Avec MOV, MVN, ADD SUB et RSB et les shifts, on résoud très bien ces problèmes qui n'en sont pas et très vite.

J'imagine que cette vision de l'absolue nécessité de pouvoir former rapidement des constantes 32 bits est liée à ton système bitplan et/ou aux adresses ou valeurs à mettre dans ton bliteur ou ton copeur. Ce dont on se contrefout royalement sur un système ARM (où, d'ailleurs, les adresses vidéo, hardware, tables pointeurs IRQ et FIRQ, etc ... sont des valeurs directement encodables dans une seule instruction MOV. Ah ah ! je rigole).

[Snafu]

Bah Romano, entre quelques Archinepties, on peut perdre son "basic ", comme lire

[Invité]

Oui, je pense. C'est dingue comme quelqu'un peut défendre un ordi comme ça, comme si sa vie en dépendait

[stapha92]

POURQUOI LA VERSION ARCHIMEDES EST-ELLE MOINS FLUIDE QUE LA VERSION AMIGA à 25 i/s !

Après faut voir aussi comment est configuré l'émulation Amiga... vu que c'est un longplay il aurait pas overclocké un poil pour gagner du temps ???
Et puis euh... ça semble même plus rapide que l'arcade sur cette video... je vois pas trop l'intéret...

ça sert à rien de faire un jeux ultra rapide si ça foire le gameplay, il faut surtout faire un jeux "assez" rapide.

Non pas du tout : j'ai terminé ce jeu sur mon A500 à l'époque et il est hyper fluide du début à la fin. Et ça n'a rien d'extraordinaire : un scroll multi-directionnel et quelques fantome à dessiner : y a pas grand chose à animer si on dispose d'un vrai scoll hardware.

Plus rapide que l'arcade ? ça c'est curieux... peut-être un problème de versions 50/60Hz

[ArchieForEver]

Oui, je pense. C'est dingue comme quelqu'un peut défendre un ordi comme ça, comme si sa vie en dépendait

Non, au royaume des cons, je suis docteur. Voilà tout.

[ArchieForEver]

@Stapha92 :

Tu as écrit en me citant :
--------------------------
'

ArchieForEver a écrit:

Je confirme à nouveau que pour faire du mapping de texture, on n'a pas besoin de lire en byte à byte. C'est logique, réfléchis. Sans doute la plus grosse erreur que tu fasses en raisonnement ARM.

Ah
oui tu confirmes ? Et bien expliques moi (encore une fois moi j'ai
donné une explication et pas toi) comment tu fais pour lire 4 octes
éparpillés en mémoire en 1 seul accès 32 bits... Meme si l'ARM disposait
d'une intruction capable d'aller chercher ces 4 octets pour les stocker
dans un registre (et ce n'est pas le cas), il aurait FORCEMENT besoin
de 4 accès en lecture : c'est la façon dont fonctionne la mémoire sur
TOUS les ordinateurs depuis la nuit des temps qui l'oblige...

Ton
"sans doute la plus grosse erreur que tu fasses en raisonnement ARM"
est idiot une fois de plus. Tu es sur de toi ? Va poster ton affirmation
sur un forum de codeurs Acorn et tu verras les vrais codeurs te rire au
nez...
Et mets nous un lien sur les réponses, qu'on rigole aussi...

'
--------------------------
Ma réponse :

Spécifiquement, quand tu dis :
'Meme si l'ARM disposait
d'une intruction capable d'aller chercher ces 4 octets pour les stocker
dans un registre (et ce n'est pas le cas), il aurait FORCEMENT besoin
de 4 accès en lecture : c'est la façon dont fonctionne la mémoire sur
TOUS les ordinateurs depuis la nuit des temps qui l'oblige...
'
et bien c'est FAUX.

Et l'Archimedes n'a pas cette instruction, on est d'accord, il doit lire ou écrire sur une adresse multiple de 4 quand il traite des mots de 4 octets.
Si l'adresse n'est pas alignée, ta conclusion c'est que l'Archie doit donc lire le mot en procédant à 4 accès de 1 octet, ce qui donne une grande lenteur : 4 x 4 cycles = 16 cycles.
Ouais, ouais, je me disais aussi : t'es bien un idiot patenté 'made in Amiga'.
Je constate à nouveau que tu ne connais rien à la programmation ARM car ton affirmation est fausse.
T'es juste un gros nul, inapte.
Compte pas sur moi pour t'éclairer, ça me ferait mal.
Reste avec ton air supérieur alors qu'aux 3/4 du temps t'es bien à côté de la plaque.

Juste de façon anecdotique : tu sais comment se comporte un ARM quand il fonctionne sur des adresses non alignées (question non liée à ce que j'ai dit plus haut, mais c'est histoire de rire un peu, parce que par exemple le compilateur C sur Archie s'en servait énormément. Vite, vite, va googler, jeune padawan pour ramener une réponse que tu ignorais Une de plus :cherry: ).

[stapha92]

Me voilà de retour du marché où ça pèle, et je vais me faire le petit plaisir de te moucher, à nouveau.
Oui 95% des codeurs de jeux sur Archie étaient des gros nuls, ou paresseux, ou pas désireux d'en faire plus vu le salaire qu'il recevait et/ou le temps imparti pour produire.
Je persiste et signe.
Tout comme 95% des démos sur Amiga pré AGA ne sont pas impressionnantes, car elles utilisent de la grosse ficelle pour faire croire que 1/ la machine en a dans le ventre, et / ou 2/ que le code est divin ou super optimisé.
Voilà, ça déjà, c'est dit.

Mon jeu va tourner sur des machines standard.
Tout comme ma preview.
Au cas où tu ne le saurais pas dès fin 1988 tous les Archies avaient soit 2 soit 4 Mo en standard. :viking:
Les rares machines qui sortaient encore en 1 Mo était upgradé à 2 directement par les revendeurs.
Mais ça, détracteur absurde de la machine, tu ne risquais pas de le savoir.

Tes idées d'optimisation je m'en tape : ce que je lis de toi sonne faux, et ce que tu as vu sur Scorpius est
- d'une part, faux
- d'autre part ne représente pas le 1/3 de ce que je pense les codeurs de Scorpius ont réalisé en termes d'optimisation (que je n'ai aucune envie de te détailler, ça m'ferait mal).

Au fait : par rapport à ma preview, où il me restait 15% de cycles dispo par VBL, non seulement mes routines d'affichage sont améliorées depuis d'environ 30%, et le player bien lent que j'utilisais va être remplacé par un autre véritablement optimisé, qui me libère environ 3 à 4% de cycles dispos par VBL pour mon code.

Donne moi donc l'équivalent code 68000 et nombre de cycles de ce que j'ai posté en ARM.
Tu passes ton temps à raconter n'importe quoi.
Juste quelques exemples :
- as tu désormais compris comment on pouvait diviser facilement sur ARM ?
- dis moi comment tu multiplies :
1/ par (2^n)+1
2/ par (2^n)-1
3/ ou plus simple :
par 5,
par 7,
par 10 sur ton 68000... et donne moi bien les cycles pour des valeurs 32 bit, et pas 16 bit que seules ton ALU sait traiter sans cycle supplémentaire.
Je te donnerai la version ARM, et tu verras toute l'importance du barrel shifter pour 0 cycle supplémentaire, et intégré à l'instruction (=gain de place mémoire) que vous n'avez eu sur la gamme 68000 qu'à partir du 68020 (et c'est bien pour ça que je trouve que le 1200 est une machine sympathique, comme je l'ai dit depuis le début de cette 'discussion').

Quelqu'un peut être toi, a parlé de la version thumb de l'Arm, où bcp d'instructions sont codées en 16 bit, et pas 32.
Bien évidemment en prenant cet argument pour dire :'Donc l'Archie est nul'.
Ben non.
Le thumb a principalement répondu au besoin de sortir des microcontroleurs ARM avec très peu de besoin en RAM ou ROM, pour de la production de masse, à fin d'intégration dans une gamme vaste qui doit aller des imprimantes, routeurs, au GPS, ordinateurs de bord dans les voitures etc ...
Bref : ce passage à 16 bit n'est en rien la reconnaissance d'une erreur d'aiguillage dans le choix originel d'Acorn (cad 32 bits pour la taille d'instruction), ça a juste correspondu au choix d'ARM de répondre aux attentes du marché des microcontroleurs.
Mais bon, encore une fois vous préférez travestir la vérité.

Ce qui me plait c'est qu'aujourd'hui tout ce que vous utilisez regorge de processeurs ARM. Sans rire : pour des pro amiga ça doit être un calvaire. Je me marre rien que d'y penser.

Me moucher de nouveau ? Quand m'as tu mouché avant ? Y a quelqu'un qui a posté un truc dans ce sens ? Parce que le contraire est arrivé... Mais ça doit être un complo anti-archimedes...

T'es vraiment qu'une pauvre merde qui n'arriverait jamais au niveau des codeurs que tu traite de nul...
Idem pour les démos pre-aga : tu ne sais pas de quoi tu parles, ferme là ou va donner tes explication aux codeurs de ces démos sur pouet ou ada...

Oui 2 Mo : c'est déjà ce qu'il te faut pour ta démo ridicule...

Qu'est-ce qui est faux sur Scorpius ? Qui ne tourne pas à 50 i/s, qui a un layer (software le layer : viens pas me refaire la leçon) en 4 couleurs, qui a des tirs rikiki (t'as vu ceux de battle squadron ? A 2 joueurs, il remplissent l'écran à eux tous seuls...)

Ah maintenant t'attaques plus mon optimisation mais tu prétend connaitre les optimisations de Scorpius mais tu veux pas les donner. Arrete de mentir: tu crois avoir réinventé la roue parce que tu as découvert les accès 32 bits et le registre d'adresse de l'écran...

En attendant t'as besoin de 3 buffer écrans pour faire un scroll vertical...

Ta préview tout le monde s'en fout : elle n'a impressioné personne ici et en 2 post j'ai trouvé toutes les "optimisations révolutionnaires" (du moins toi tu crois que c'en est...) que tu utilises. Je pourrais te citer des tonnes d'effets des démos que tu critiques et tu serais incapable de m'expliquer UNE SEULE des optimisations utilisées.

Non : donne moi un algo de manipulation de données : tu t'écartes totalement du sujet s'en t'en rendre compte. Mais je suis trop gentil : donne moi l'algo complet et je le réécris...

Ah ? c'est pas un algo ? c'est juste du code inutile ?...

N'importe quoi ?
Petit rigolo : j'ai jamais dit qu'on pouvait pas diviser. J'ai même expliqué que l'absence de division n'est pas dramatique du tout quand on veut faire de la 2D ou de la 3D surface pleine. Toi dans le même temps, tu nous expliques que les programmes pro de ray-tracing peuvent fonctionner sans fpu et, pire, avec des tables...

Comment je multiple ? C'est quoi cette question bidon ? T'as pas compris que je t'as rien à m'apprendre en programmation ?
Mossieur "je comprend pas comment fonctionne la palette en mode 256 couleurs mais j'arrete pas d'en parler tous les 2 posts". Quoique c'était avant : tu ne la ramènes plus la-dessus. Comme pour plein de sujet que j'ai abordés... LOL !

Je te répond quand même : tu serais capable de croire que j'en suis incapable sinon :
- pour faire (2^n)+1 : on décale de n bits et on ajoute 1 fois la valeur initiale
- pour faire (2^n)-1 : on décale de n bits et on enlève 1 fois la valeur initiale
(et précise aux lecteurs pourquoi tu auras tout interet à ce que n soit pair...)

Tu ne m'apprend rien, je maitrise les décalage bien plus que toi. Je critiques le fait que 12,5% des programmes soit systématiquement occupé à ça (4 bits sur les 32 occupés par les instructions). même l'algo de division que tu as posté : on ne voit pas beaucoup de décalages (pourtant on est dans un cas ou c'est utile), mais pourtant, ils prennent 12 octets sur les 48 de ta routines de merde (qui atteint combien de cycles au max pour faire une division ? J'ai donné le max sur 68000...). les décalages sur arm ont été faits de cette façon surtout pour permettre de positionner une valeur 8 bits à n'importe quelle position paire d'un registre ou d'un calcul. C'est élégant mais ça ne vaut pas la possibilité de manipuler des valeurs de 32 bits sans contrainte...


Et je vais même te dire autre chose : même pour une vrai multiplication (parce que les décalage ne suffisent que dans certains cas...) l'arm doit surement laisser le 68000 sur place. J'ai jamais nié que pour des opérations sur des registres (hors division...) l'arm était très fort. On parle animation 2D : donc de manipulation de la mémoire.

"que vous n'avez eu sur la gamme 68000 qu'à partir du 68020" : je sais pas de quoi tu parles mais t'as tout faux, comme à chaque fois que tu parles du 68000. LES DECALAGES SONT IDENTIQUES DANS TOUTES LES VERSIONS 680x0 ET N'ONT JAMAIS ETE INTEGRES AUX INSTRUCTIONS (normal : tu te souviens qu'elle prennent moins de place sur 680x0 ?)

Oui bien sur : le thumb c'est pour les micro-controleurs maintenant...

C'est clair tu m'as mouché : tu croyais m'apprendre des trucs évidents sur les décalages et t'as ENCORE (!!!!) sorti une betise sur le 680x0...

[stapha92]

Je pense que même un crétin des Alpes de ton espèce peut comprendre la différence qu'il y aura au niveau du rendu visuel sur Youtube pour ces 2 types de vidéo envoyée :
- Une vidéo capturée à 50 images par seconde sur une source à 50 images par seconde (Amiga)

- Une vidéo capturée à 25 images par seconde sur une source à 50 images par seconde (Archimedes)

T'as vraiment pas le niveau, comme pour tout le reste, ou presque.

Au fait : Youtube, sauf erreur, c'est 30 images par seconde, ceci explique donc cela sur le rendu du flux final pour le spectateur.

Crétin de Alpes ? Voilà :

15 avenue du Ponant - 92390 - Villeneuve-la-Garenne : viens assumer tes insultes en face ou arretes d'en formuler pauvre merde que tu es (moi j'assume : donne ton adresse...)

Oui c'est ça j'ai pas le niveau...

[stapha92]

@ArchieForEver,



Supposons que tu as besoin de faire une opération entre une constante et un registre (ce qui arrive TRES souvent, tous les programmeurs le savent, même les débutants). Et bien sur 68000, tu te contentes de mettre la constante et c'est tout :
Par exemple OR.L D0,#$F0F0F0F0

Sur ARM, tu es obligé de stocker ta constante dans un registre. Et hop un registre de perdu ! (et du temps, et de la place aussi...). Le plus drole, c'est qu'il te faudra plusieurs instruction pour affecter cette valeur...

Ah ouais ?
Mais on est encore une fois de plus dans le grand n'importe quoi

BIC R3,R5,#255 :R3=R5 avec 8 bits bas mis à 0
AND R2,R1,#24 :R2=R1 R1 AND 24

RSB R2,R3,#7 : R2=7-R3

c'est quoi à ton avis ?
Tu ne connais rien à la programmation ARM et tu trolles ici comme si tu étais un spécialiste, c'est une blague.

Tu ne connais pas l'ARM et tu déblatères.

Oui c'est ça... Tu peux donner un exemple avec une constante 32 bits ? Utiliser la valeur que j'ai donné par exemple ?

La valeur que tu as donnée, peut-être, faudrait que je vérifie.
Au pire je la formerai en 3 MOV, pas de quoi fouetter un chat.
Les cas où on doit travailler directement avec une constante 32 bits, ce n'est quand même pas la majorité.
Et tu t'abstiens bien de me donner la taille de l'instruction, et le nombre de cycles.
QQchose me dit que ce sera très mauvais par rapport à un Archie, alors vas y, stp donne.

Sur l'ARM on peut évidemment avoir en constante des valeurs 32 bits, elles doivent répondre à des règles de divisabilité par 2^n.
En gros tu parles d'un truc dont tout le monde se fout en programmation, ou presque, tu n'as que ça pour défendre ton miga.
Avec MOV, MVN, ADD SUB et RSB et les shifts, on résoud très bien ces problèmes qui n'en sont pas et très vite.

J'imagine que cette vision de l'absolue nécessité de pouvoir former rapidement des constantes 32 bits est liée à ton système bitplan et/ou aux adresses ou valeurs à mettre dans ton bliteur ou ton copeur. Ce dont on se contrefout royalement sur un système ARM (où, d'ailleurs, les adresses vidéo, hardware, tables pointeurs IRQ et FIRQ, etc ... sont des valeurs directement encodables dans une seule instruction MOV. Ah ah ! je rigole).

Inutile de vérifier : toi t'as peut-être besoin d'y réfléchir mais pour moi c'est évident.
3 MOV pour affecter une valeur 32 bits ? trop drole, mais c'est 4 (ou alors tu utiliseras un registre intémédiaire). Et le sujet c'était, je te le rappelle, les registres perdus, relis la portion que tu cites..

Arretes de revenir sur la taille de l'algo : donne un VRAI algo qui sert à quelque chose. Donnes en un qui manipule des données.
T'arretes pas de revenir la dessus mais j'attend toujours pour l'optimisation du layer du fond dans Sorpius...

Non : tu ne peux pas avoir de constante 32 bits. Tu peux avoir des constantes 8 bits positionnées qu'à partir des bits 0,2,4,...

Ah bon ? tout le monde se fout des constantes 32 bits en programmation ? LOL !!!
C'est lié à l'Architecture du mig (qui est en 16 bits : on en a moins besoin que ton Archimedes...) ? re-lol !!!

Tu dis vraiment n'importe quoi...

Le premier exemple que je donne permet, par exemple, de forcer les même 4 bits sur 4 pixels à ecrire dans ton écran chunky (donc TON ARCHITECTURE). Donc pour le faire, il te faudrait 1 registre de plus sur arm que sur 68000. Note que c'est un exemple concret de manipulation de données : moi je ne dévie pas du sujet avec des trucs débiles...

[stapha92]

Spécifiquement, quand tu dis :
'Meme si l'ARM disposait
d'une intruction capable d'aller chercher ces 4 octets pour les stocker
dans un registre (et ce n'est pas le cas), il aurait FORCEMENT besoin
de 4 accès en lecture : c'est la façon dont fonctionne la mémoire sur
TOUS les ordinateurs depuis la nuit des temps qui l'oblige...
'
et bien c'est FAUX.

Et l'Archimedes n'a pas cette instruction, on est d'accord, il doit lire ou écrire sur une adresse multiple de 4 quand il traite des mots de 4 octets.
Si l'adresse n'est pas alignée, ta conclusion c'est que l'Archie doit donc lire le mot en procédant à 4 accès de 1 octet, ce qui donne une grande lenteur : 4 x 4 cycles = 16 cycles.
Ouais, ouais, je me disais aussi : t'es bien un idiot patenté 'made in Amiga'.
Je constate à nouveau que tu ne connais rien à la programmation ARM car ton affirmation est fausse.
T'es juste un gros nul, inapte.
Compte pas sur moi pour t'éclairer, ça me ferait mal.
Reste avec ton air supérieur alors qu'aux 3/4 du temps t'es bien à côté de la plaque.

Juste de façon anecdotique : tu sais comment se comporte un ARM quand il fonctionne sur des adresses non alignées (question non liée à ce que j'ai dit plus haut, mais c'est histoire de rire un peu, parce que par exemple le compilateur C sur Archie s'en servait énormément. Vite, vite, va googler, jeune padawan pour ramener une réponse que tu ignorais Une de plus :cherry: ).

Pauvre idiot... j'ai jamais parlé de cycles sur ARM. J'ai symplement dit que pour, appliquer une texture, tu étais obligé de lire les pixels un par un. Y a rien à faire si t'es même pas capable de comprendre ça...

Et je parle pas d'accès non aligné : je parle de lire 4 octets à 4 adresses completement différentes. Tu piges rien ou quoi ? T'es vraiment plus nul que je croyais...

Tu crois que si je devais lire une adresse non alignées sur un arm je serais assez idiot pour faire 4 lectures ? Encore une fois : on n'a pas le même niveau. Je ferais 2 accès 32 bits sur l'adresse alignée précédente et je me servirai de masques et de décalage (pour lesquels l'arm est très performant) pour récupérer les 4 octets dont j'ai besoin : pour toi c'est peut-être une astuce mais pour n'importe quel vrai codeur, c'est le B.A.BA.

En fait, tu ne vois pas du tout ce qu'implique un placage de texture, c'est quelque chose qui te dépasse, comme les scrolls horizontaux, le double-buffer, la palette de TA bécane, etc...

Et je le répète pour les lecteurs : ça n'a rien à voir avec l'ARM. Même une carte graphique qui applique une texture est obligée de lire les pixels un par un et les écrira en groupe. C'est pour ça qu'en général, elle manipule moins de texels (les pixels à lire) que de pixels (ceux à écrire) par seconde...

T'arretes pas de la ramener mais en fait tu ne sais rien faire d'autre que ce qu'on a vu dans ta préview. Tu ne connais rien en texture mais tu la ramènes. T'expliques pleins de choses à tout le monde mais t'es pas foutu de comprendre comment fonctionnent les balises dans tes posts : même avec ça t'es ridicule...

En attendant, ta mauvaise foi est si grande que t'ose pas admettre que t'as pas la moindre idée de la façon dont le fond est affiché dans Scorpius...

[ArchieForEver]

Vous ne comprendrez jamais rien à cette machine en la jugeant par Youtube.

ni même avec un émulateur d'ailleurs... hélas c'est pas facile à trouver un Archi...

L'émulateur Archie est là, c'est quand même pas dur à trouver :
http://b-em.bbcmicro.com/arculator/
tout le reste se trouve comme les films... trop dur pour vous, sans doute.

Et lire correctement une phrase qui t'explique c'est difficile de trouver un archimedes et pas l'émulateur, c'est trop dur pour toi ?

Ah pardon ! C'est encore meilleur : c'est vrai qu'en acheter un pour 100 à 120 euros sur ebay.co.uk pour un neuneu d'amigaïste on touche à l'impensable.
Mea culpa, j'avais oublié que si tout n'est pas fourni tout cuit sur diskette piratée, ça tombe bien au delà de vos capacités.

[ArchieForEver]

Spécifiquement, quand tu dis :
'Meme si l'ARM disposait
d'une intruction capable d'aller chercher ces 4 octets pour les stocker
dans un registre (et ce n'est pas le cas), il aurait FORCEMENT besoin
de 4 accès en lecture : c'est la façon dont fonctionne la mémoire sur
TOUS les ordinateurs depuis la nuit des temps qui l'oblige...
'
et bien c'est FAUX.

Et l'Archimedes n'a pas cette instruction, on est d'accord, il doit lire ou écrire sur une adresse multiple de 4 quand il traite des mots de 4 octets.
Si l'adresse n'est pas alignée, ta conclusion c'est que l'Archie doit donc lire le mot en procédant à 4 accès de 1 octet, ce qui donne une grande lenteur : 4 x 4 cycles = 16 cycles.
Ouais, ouais, je me disais aussi : t'es bien un idiot patenté 'made in Amiga'.
Je constate à nouveau que tu ne connais rien à la programmation ARM car ton affirmation est fausse.
T'es juste un gros nul, inapte.
Compte pas sur moi pour t'éclairer, ça me ferait mal.
Reste avec ton air supérieur alors qu'aux 3/4 du temps t'es bien à côté de la plaque.

Juste de façon anecdotique : tu sais comment se comporte un ARM quand il fonctionne sur des adresses non alignées (question non liée à ce que j'ai dit plus haut, mais c'est histoire de rire un peu, parce que par exemple le compilateur C sur Archie s'en servait énormément. Vite, vite, va googler, jeune padawan pour ramener une réponse que tu ignorais Une de plus :cherry: ).

Pauvre idiot... j'ai jamais parlé de cycles sur ARM. J'ai symplement dit que pour, appliquer une texture, tu étais obligé de lire les pixels un par un. Y a rien à faire si t'es même pas capable de comprendre ça...

Et je parle pas d'accès non aligné : je parle de lire 4 octets à 4 adresses completement différentes. Tu piges rien ou quoi ? T'es vraiment plus nul que je croyais...

Tu crois que si je devais lire une adresse non alignées sur un arm je serais assez idiot pour faire 4 lectures ? Encore une fois : on n'a pas le même niveau. Je ferais 2 accès 32 bits sur l'adresse alignée précédente et je me servirai de masques et de décalage (pour lesquels l'arm est très performant) pour récupérer les 4 octets dont j'ai besoin : pour toi c'est peut-être une astuce mais pour n'importe quel vrai codeur, c'est le B.A.BA.

En fait, tu ne vois pas du tout ce qu'implique un placage de texture, c'est quelque chose qui te dépasse, comme les scrolls horizontaux, le double-buffer, la palette de TA bécane, etc...

Et je le répète pour les lecteurs : ça n'a rien à voir avec l'ARM. Même une carte graphique qui applique une texture est obligée de lire les pixels un par un et les écrira en groupe. C'est pour ça qu'en général, elle manipule moins de texels (les pixels à lire) que de pixels (ceux à écrire) par seconde...

T'arretes pas de la ramener mais en fait tu ne sais rien faire d'autre que ce qu'on a vu dans ta préview. Tu ne connais rien en texture mais tu la ramènes. T'expliques pleins de choses à tout le monde mais t'es pas foutu de comprendre comment fonctionnent les balises dans tes posts : même avec ça t'es ridicule...

En attendant, ta mauvaise foi est si grande que t'ose pas admettre que t'as pas la moindre idée de la façon dont le fond est affiché dans Scorpius...

OK ok.
Dans l'ordre :
- donne le code 68000 et le nbre de cycles pour ce que je t'ai demandé.
- quel était le but de ta question pour les accès mémoire de l'ARM.
Sur 68000 tu peux lire simultanément 4 octets à des endroits différents ?
En une instruction super rapide ?
Si c'est le cas, ce que je ne savais pas, ça semble être un +.
Que je te concède au moins ça.
Sinon, intérêt de la question ?
Et pour l'historique du thumb, c'est exactement ce que j'ai dit.
Je peux meme ajouter qu'à un moment dans l'évolution des ARM, notamment pour le XSCALE, le CPU était capable de manipuler des mots de 16 bits, bien pratique pour les modes graphiques 16 et 24 bits.
ARM s'est adapté au fur et à mesure des besoins, pas pour corriger des erreurs initiales.

Pour Scorpius, c'est bien, déjà tu ne parles plus de plan pour le fond.
Comme je te l'ai dit, je ne donnerai pas mes recettes de cuisine.
Pourquoi le devrais-je ? Il suffira de voir ce que je sortirai.
De la même manière que mon vieux code de démo étant téléchargeable, ce n'est pas bien compliqué de le désassembler un peu pour m'expliquer ensuite ici ce que j'ai fait ou pas fait (en plus le commentaire Youtube donne toutes les pistes nécessaires).
Bref : rien de fantastiquement intelligent dans tes propos.
Et remarque bien que je n'ai jamais dit que j'étais très doué : j'ai dit que les autres étaient dans l'ensemble vraiment mauvais.
J'ai dit que personne ne relevait les toutconneries grossières, et que c'était plus qu'agaçant pour mener un débat constructif.
Donc : il n'y a plus de débat constructif.
Pourtant simple à comprendre, même pour un amigaïste.

[babsimov]

Vous ne comprendrez jamais rien à cette machine en la jugeant par Youtube.

ni même avec un émulateur d'ailleurs... hélas c'est pas facile à trouver un Archi...

L'émulateur Archie est là, c'est quand même pas dur à trouver :
http://b-em.bbcmicro.com/arculator/
tout le reste se trouve comme les films... trop dur pour vous, sans doute.

Et lire correctement une phrase qui t'explique c'est difficile de trouver un archimedes et pas l'émulateur, c'est trop dur pour toi ?

Ah pardon ! C'est encore meilleur : c'est vrai qu'en acheter un pour 100 à 120 euros sur ebay.co.uk pour un neuneu d'amigaïste on touche à l'impensable.
Mea culpa, j'avais oublié que si tout n'est pas fourni tout cuit sur diskette piratée, ça tombe bien au delà de vos capacités.

Dans le sujet Archimèdes3020 on a vu comment un néophyte sur Archimèdes N'A PAS OBTENU de l'aide d'un spécialiste de l'Archimedes. D'ailleurs il a cessé de s'intéresser à cette machine qu'il avait acheté avec l'intention d'en découvrir l'univers.
Résultat, il est revenu sur Amiga, suite à ce déplorable exemple d'un Archimèdiste.

Encore un mot sur les émulateurs. Si on récupère un émulateur d'une machine qu'on ne connait pas, il est souvent laborieux de le configurer, de trouver les logiciels etc... Il est donc bien agréable d'avoir de l'aide et du soutient par des connaisseurs de la machine qu'on veut émuler.
Configurer WINUAE si on a jamais eu un Amiga on est vite perdu, c'est pour ça qu'il existe de sympathiques fans qui ont fait des configurations clés en main (AIAB, AmigaSYS).

J'avais récupéré un émulateur Archimèdes, je l'ai lancé après avoir trouvé quelques démo Archimèdes sur internet. Mais aucune n'a démarré. J'imagine que c'est une question de ROM, mais les discussions ici ne m'ont pas donné envie d'aller plus loin pour l'instant.

[Invité]

Et remarque bien que je n'ai jamais dit que j'étais très doué : j'ai dit que les autres étaient dans l'ensemble vraiment mauvais.

Non effectivement c est pas la même chose ...
Quand on juge quelqu un de mauvais c'est forcément qu on se place au dessus.
Et quand tu parles d'élite pour les possesseurs d archimedes,c est pas se considérer meilleurs ??
Ou parler de routines révolutionnaires,c'est pas se dire surdoué ???
avoir la conviction que les codeurs ST/amiga sont que des codeurs du dimanche par rapport à soit, c est pas se croire surdoué ??
Etc ...
Depuis un bon moment tu ne convaincs que toi mon Blaise .

J'ai dit que personne ne relevait les toutconneries grossières, et que c'était plus qu'agaçant

Peut être parce que tout le monde est occupé à reprendre les tiennes de toutconneries mon Ptit archiottes ...
D'ailleurs j'attends encore les specs de ta demo qui déchire !!!

[Invité]

"

Dans le sujet Archimèdes3020 on a vu comment un néophyte sur Archimèdes N'A PAS OBTENU de l'aide d'un spécialiste de l'Archimedes. D'ailleurs il a cessé de s'intéresser à cette machine qu'il avait acheté avec l'intention d'en découvrir l'univers.
Résultat, il est revenu sur Amiga, suite à ce déplorable exemple d'un Archimèdiste"

+1000 000 je m'en souviens le spécialiste ne pensait qu'a démontrer son code fabuleux et a complétement zappé les questions du newbie.

d'ailleurs qu'est il devenu ce fantastique codeur, sévit-il toujours sur le forum ? :

[Invité]

Oui il a changé 150 fois de pseudo,la c'est archieforever.
Tu le reconnaîs facilement à ses posts autins, et son code della muerte.

[stapha92]

OK ok.
Dans l'ordre :
- donne le code 68000 et le nbre de cycles pour ce que je t'ai demandé.
- quel était le but de ta question pour les accès mémoire de l'ARM.
Sur 68000 tu peux lire simultanément 4 octets à des endroits différents ?
En une instruction super rapide ?
Si c'est le cas, ce que je ne savais pas, ça semble être un +.
Que je te concède au moins ça.
Sinon, intérêt de la question ?
Et pour l'historique du thumb, c'est exactement ce que j'ai dit.
Je peux meme ajouter qu'à un moment dans l'évolution des ARM, notamment pour le XSCALE, le CPU était capable de manipuler des mots de 16 bits, bien pratique pour les modes graphiques 16 et 24 bits.
ARM s'est adapté au fur et à mesure des besoins, pas pour corriger des erreurs initiales.

Pour Scorpius, c'est bien, déjà tu ne parles plus de plan pour le fond.
Comme je te l'ai dit, je ne donnerai pas mes recettes de cuisine.
Pourquoi le devrais-je ? Il suffira de voir ce que je sortirai.
De la même manière que mon vieux code de démo étant téléchargeable, ce n'est pas bien compliqué de le désassembler un peu pour m'expliquer ensuite ici ce que j'ai fait ou pas fait (en plus le commentaire Youtube donne toutes les pistes nécessaires).
Bref : rien de fantastiquement intelligent dans tes propos.
Et remarque bien que je n'ai jamais dit que j'étais très doué : j'ai dit que les autres étaient dans l'ensemble vraiment mauvais.
J'ai dit que personne ne relevait les toutconneries grossières, et que c'était plus qu'agaçant pour mener un débat constructif.
Donc : il n'y a plus de débat constructif.
Pourtant simple à comprendre, même pour un amigaïste.

Donne un code qui fait vraiment quelque chose sur le sujet, cad traiter des données, et je te donnerai l'équivalent. Tant que c pas fait, tu peux la fermer : on a tous vu comment tu insistes sur ce point avec tes exemples bidons quand les miens sont en plein dans le sujet. Et je te rappelle que ça vient de ta réaction quand j'ai dit que le "68030 est plus doué que l'ARM pour manipuler des données" et j'ajoute : y compris un ARM3.

Relis les posts si t'es pas capable de te souvenir du sujet.

Idem pour les accès mémoires : je disais que pour un placage de texture tu ne pourrais plus utiliser des lectures en 32 bits et que c'est pénalisant avec ton achitecture. Tu m'as répondu que si, toi tu pouvais. Et maintenant tu reviens là dessus ?

Et non : le 68000 n'est pas plus capable de le faire. Il dispose d'une instruction destinée à positionner un registre de 32 bits sur 4 octets espacés de 2 à chaque fois (Movep) mais, même dans ce cas, les accès mémoires sont multipliés. Y a pas plus de magie dans un mig que dans un archimedes.

Oui, c'est ça : c'est sur que pouvoir utiliser des constantes de 16 ou 32 bits n'aurait servi à rien en 87 sur une architecture 32 bits avec un proc qui dispose de 16 registres 32 bits.

Pathétique...

Et je n'ai jamais dit que c'était une erreur de conception : le RISC apporte tout un lot de contraintes, c'est comme ça. La question est comment les limiter. Et je n'ai jamais dit que les choix n'étaient pas bon. Toi par contre tu prétends que l'assembleur arm est le meilleur et que le code n'est pas plus gros (ah si : mais de 15 %...) ou que tu n'utilises jamais plus de registres qu'un 68000...

Encore du blabla sur le plan du fond de Scorpius. Arrete des mensonges merdiques et sort moi les posts ou je dis que :

- le plan du fond est un layer hardware

- l'astuce utilise des bitplans

Parce que tout le monde a vu que tu me reprochais ça alors que je ne l'ai jamais dit. J'ai toujours affirmé la même chose : le fond n'a que 4 couleurs, peux tu donner une optimisation qui l'explique ? Et tu dévies à chaque fois...

Maintenant tu pars sur tes algo que tu gardes jalousement (ce qui n'est pas grave : il ne valent rien...) et tu ments :

TU NE SAIS ABSOLUMENT PAS COMMENT FAIT SCORPIUS POUR AFFICHER LE PLAN DU FOND.

Tant que tu me contrediras autrement qu'en expliquant une optimisation plausible, tu n'auras aucune crédibilité.

Moi par contre :

J'ENVERRAI EN MP A TOUS CEUX QUI LE DEMANDERONT UNE EXPLICATION

Rien de bien extraordinaire dans mes propos quand j'ai trouvé toutes tes optimisations ? Je n'ai pas expliqué les optimisations pour paraitre extraordinaire, je l'ai fait :

- parce que touko te les avait demandé et je sais que t'es du genre egoiste

- pour te montrer qu'elles ne valaient rien puisqu'elles peuvent être déduites par quelqu'un qui ne connait pas ta machine.

Parce que tu crois vraiment que pour trouver tes optimisations j'ai installé un émulateur, désassemblé ton code, appris l'arm, etc... ? LOL !!!! Non désolé : j'ai réfléchis le temps du post.

Non, rend toi à l'évidence : Y a rien d'extraordinaire dans mes propos parce que tes "optimisations" n'ont rien d'extraordinaire. Celle que je propose pour Scorpius est assez simple, mais elle est déjà d'un autre niveau.

Je pensais que ta rage allait te pousser assez pour la trouver (ça fait quand même plusieurs jours maintenant) mais non : t'es vraiment trop nul...

Et toi ? pourquoi tu désassemble pas Scorpius ? Si c'est "pas bien compliqué" pour moi, ça devrait, toi, ne prendre que quelques secondes ? Je constate qu'au bout de quelques jours t'as toujours pas réussi...

T'es vraiment un imbécile : je t'ai donné l'indice le plus important pour la trouver, bien plus utile qu'un code désassemblé...

ps : évite les "ok ok. dans l'ordre" : tu essaies de faire croire que vas être en mesure de tout contredire alors que t'ose plus aborder 9/10 des sujets sur lesquels j'ai répondu. Et ça tout le monde le voit : ça te rend encore moins crédible...

[stapha92]

"

Dans le sujet Archimèdes3020 on a vu comment un néophyte sur Archimèdes N'A PAS OBTENU de l'aide d'un spécialiste de l'Archimedes. D'ailleurs il a cessé de s'intéresser à cette machine qu'il avait acheté avec l'intention d'en découvrir l'univers.
Résultat, il est revenu sur Amiga, suite à ce déplorable exemple d'un Archimèdiste"

+1000 000 je m'en souviens le spécialiste ne pensait qu'a démontrer son code fabuleux et a complétement zappé les questions du newbie.

d'ailleurs qu'est il devenu ce fantastique codeur, sévit-il toujours sur le forum ?

Oui Touko a raison : c'est bien ArchieForEver.

Et ce n'est pas du tout un fantastique codeur. C'est juste un codeur qui a besoin de 2 Mo pour faire quelque chose de simple (et 3 buffers pour faire un scrolling...) et qui pense que ça lui donne le droit d'insulter des codeurs qui ont fait de vrais jeux...

Quand à son code fabuleux. Je peux résumer l'échange que j'ai eu dessus avec lui comme ça :

- mes optimisation sont géniales personne ne peut les trouver. Surtout pas ici avec tous les idiots qu'il y a

- tes optimisations en gros c ça

- ah... euh... non... ça compte pas ! je faisais ça y a 20 ans ! depuis j'ai gagné 30 % ! hé hé hé

- ouais genre t'as fait ça en plus quoi

- ah... euh... non... t'as triché ! t'as volé mon code ! Vilain !

[ArchieForEver]

Vous ne comprendrez jamais rien à cette machine en la jugeant par Youtube.

ni même avec un émulateur d'ailleurs... hélas c'est pas facile à trouver un Archi...

L'émulateur Archie est là, c'est quand même pas dur à trouver :
http://b-em.bbcmicro.com/arculator/
tout le reste se trouve comme les films... trop dur pour vous, sans doute.

Et lire correctement une phrase qui t'explique c'est difficile de trouver un archimedes et pas l'émulateur, c'est trop dur pour toi ?

Ah pardon ! C'est encore meilleur : c'est vrai qu'en acheter un pour 100 à 120 euros sur ebay.co.uk pour un neuneu d'amigaïste on touche à l'impensable.
Mea culpa, j'avais oublié que si tout n'est pas fourni tout cuit sur diskette piratée, ça tombe bien au delà de vos capacités.

Dans le sujet Archimèdes3020 on a vu comment un néophyte sur Archimèdes N'A PAS OBTENU de l'aide d'un spécialiste de l'Archimedes. D'ailleurs il a cessé de s'intéresser à cette machine qu'il avait acheté avec l'intention d'en découvrir l'univers.
Résultat, il est revenu sur Amiga, suite à ce déplorable exemple d'un Archimèdiste.

Encore un mot sur les émulateurs. Si on récupère un émulateur d'une machine qu'on ne connait pas, il est souvent laborieux de le configurer, de trouver les logiciels etc... Il est donc bien agréable d'avoir de l'aide et du soutient par des connaisseurs de la machine qu'on veut émuler.
Configurer WINUAE si on a jamais eu un Amiga on est vite perdu, c'est pour ça qu'il existe de sympathiques fans qui ont fait des configurations clés en main (AIAB, AmigaSYS).

J'avais récupéré un émulateur Archimèdes, je l'ai lancé après avoir trouvé quelques démo Archimèdes sur internet. Mais aucune n'a démarré. J'imagine que c'est une question de ROM, mais les discussions ici ne m'ont pas donné envie d'aller plus loin pour l'instant.

Ah oui ? De l'aide j'en ai donné.
Il y a encore des vendeurs de softs sur Archimedes, et je suis contre le piratage, ok ?
Le piratage a tué le ST et l'Amiga, et tout ce que j'ai je l'ai payé : soit à des particuliers anglais, soit aux rares professionnels qui continuent de soutenir le monde Acorn.
Enfin, en temps que développeur, tu crois que je vais donner des copies de ROM alors qu'elles sont encore copyrightées ?
Car elles le sont : le détenteur c'est Castle Technology.
Tu crois que je vais donner des copies de jeux alors que ces mêmes jeux sont encore vendus, et que leurs auteurs touchent les droits qui leur reviennent, tout à fait honnêtement ?
En ce qui me concerne, c'est indiscutablement non.
Donc, si tu souhaites faire n'importe quoi, tu le fais ; moi ce n'est pas mon cas.
J'ai donné assez de liens utiles à quelqu'un qui de toutes façons, est arrivé en critiquant directement la machine, le manque de ceci ou de cela, alors qu'une simple recherche google 'monde' apportait de nombreux résultats.

Encore une fois : MERCI de travestir les faits.

PS : Pour faire tourner l'émulateur, ôôôôh que c'est dur : il y a un readme.txt qui explique tout, très, mais alors très simplement.
Je n'aide jamais les paresseux qui arrivent en critiquant sans se donner la peine de quoi que ce soit, genre 'esclave, fais le travail pour moi'.

[Invité]

Et ce n'est pas du tout un fantastique codeur. C'est juste un codeur qui a besoin de 2 Mo pour faire quelque chose de simple (et 3 buffers pour faire un scrolling...) et qui pense que ça lui donne le droit d'insulter des codeurs qui ont fait de vrais jeux...

Quand à son code fabuleux. Je peux résumer l'échange que j'ai eu dessus avec lui comme ça :

- mes optimisation sont géniales personne ne peut les trouver. Surtout pas ici avec tous les idiots qu'il y a

- tes optimisations en gros c ça

- ah... euh... non... ça compte pas ! je faisais ça y a 20 ans ! depuis j'ai gagné 30 % ! hé hé hé

- ouais genre t'as fait ça en plus quoi

- ah... euh... non... t'as triché ! t'as volé mon code ! Vilain !

[ArchieForEver]

OK ok.
Dans l'ordre :
- donne le code 68000 et le nbre de cycles pour ce que je t'ai demandé.
- quel était le but de ta question pour les accès mémoire de l'ARM.
Sur 68000 tu peux lire simultanément 4 octets à des endroits différents ?
En une instruction super rapide ?
Si c'est le cas, ce que je ne savais pas, ça semble être un +.
Que je te concède au moins ça.
Sinon, intérêt de la question ?
Et pour l'historique du thumb, c'est exactement ce que j'ai dit.
Je peux meme ajouter qu'à un moment dans l'évolution des ARM, notamment pour le XSCALE, le CPU était capable de manipuler des mots de 16 bits, bien pratique pour les modes graphiques 16 et 24 bits.
ARM s'est adapté au fur et à mesure des besoins, pas pour corriger des erreurs initiales.

Pour Scorpius, c'est bien, déjà tu ne parles plus de plan pour le fond.
Comme je te l'ai dit, je ne donnerai pas mes recettes de cuisine.
Pourquoi le devrais-je ? Il suffira de voir ce que je sortirai.
De la même manière que mon vieux code de démo étant téléchargeable, ce n'est pas bien compliqué de le désassembler un peu pour m'expliquer ensuite ici ce que j'ai fait ou pas fait (en plus le commentaire Youtube donne toutes les pistes nécessaires).
Bref : rien de fantastiquement intelligent dans tes propos.
Et remarque bien que je n'ai jamais dit que j'étais très doué : j'ai dit que les autres étaient dans l'ensemble vraiment mauvais.
J'ai dit que personne ne relevait les toutconneries grossières, et que c'était plus qu'agaçant pour mener un débat constructif.
Donc : il n'y a plus de débat constructif.
Pourtant simple à comprendre, même pour un amigaïste.

Donne un code qui fait vraiment quelque chose sur le sujet, cad traiter des données, et je te donnerai l'équivalent. Tant que c pas fait, tu peux la fermer : on a tous vu comment tu insistes sur ce point avec tes exemples bidons quand les miens sont en plein dans le sujet. Et je te rappelle que ça vient de ta réaction quand j'ai dit que le "68030 est plus doué que l'ARM pour manipuler des données" et j'ajoute : y compris un ARM3.

Relis les posts si t'es pas capable de te souvenir du sujet.

Idem pour les accès mémoires : je disais que pour un placage de texture tu ne pourrais plus utiliser des lectures en 32 bits et que c'est pénalisant avec ton achitecture. Tu m'as répondu que si, toi tu pouvais. Et maintenant tu reviens là dessus ?

Et non : le 68000 n'est pas plus capable de le faire. Il dispose d'une instruction destinée à positionner un registre de 32 bits sur 4 octets espacés de 2 à chaque fois (Movep) mais, même dans ce cas, les accès mémoires sont multipliés. Y a pas plus de magie dans un mig que dans un archimedes.

Oui, c'est ça : c'est sur que pouvoir utiliser des constantes de 16 ou 32 bits n'aurait servi à rien en 87 sur une architecture 32 bits avec un proc qui dispose de 16 registres 32 bits.

Pathétique...

Et je n'ai jamais dit que c'était une erreur de conception : le RISC apporte tout un lot de contraintes, c'est comme ça. La question est comment les limiter. Et je n'ai jamais dit que les choix n'étaient pas bon. Toi par contre tu prétends que l'assembleur arm est le meilleur et que le code n'est pas plus gros (ah si : mais de 15 %...) ou que tu n'utilises jamais plus de registres qu'un 68000...

Encore du blabla sur le plan du fond de Scorpius. Arrete des mensonges merdiques et sort moi les posts ou je dis que :

- le plan du fond est un layer hardware

- l'astuce utilise des bitplans

Parce que tout le monde a vu que tu me reprochais ça alors que je ne l'ai jamais dit. J'ai toujours affirmé la même chose : le fond n'a que 4 couleurs, peux tu donner une optimisation qui l'explique ? Et tu dévies à chaque fois...

Maintenant tu pars sur tes algo que tu gardes jalousement (ce qui n'est pas grave : il ne valent rien...) et tu ments :

TU NE SAIS ABSOLUMENT PAS COMMENT FAIT SCORPIUS POUR AFFICHER LE PLAN DU FOND.

Tant que tu me contrediras autrement qu'en expliquant une optimisation plausible, tu n'auras aucune crédibilité.

Moi par contre :

J'ENVERRAI EN MP A TOUS CEUX QUI LE DEMANDERONT UNE EXPLICATION

Rien de bien extraordinaire dans mes propos quand j'ai trouvé toutes tes optimisations ? Je n'ai pas expliqué les optimisations pour paraitre extraordinaire, je l'ai fait :

- parce que touko te les avait demandé et je sais que t'es du genre egoiste

- pour te montrer qu'elles ne valaient rien puisqu'elles peuvent être déduites par quelqu'un qui ne connait pas ta machine.

Parce que tu crois vraiment que pour trouver tes optimisations j'ai installé un émulateur, désassemblé ton code, appris l'arm, etc... ? LOL !!!! Non désolé : j'ai réfléchis le temps du post.

Non, rend toi à l'évidence : Y a rien d'extraordinaire dans mes propos parce que tes "optimisations" n'ont rien d'extraordinaire. Celle que je propose pour Scorpius est assez simple, mais elle est déjà d'un autre niveau.

Je pensais que ta rage allait te pousser assez pour la trouver (ça fait quand même plusieurs jours maintenant) mais non : t'es vraiment trop nul...

Et toi ? pourquoi tu désassemble pas Scorpius ? Si c'est "pas bien compliqué" pour moi, ça devrait, toi, ne prendre que quelques secondes ? Je constate qu'au bout de quelques jours t'as toujours pas réussi...

T'es vraiment un imbécile : je t'ai donné l'indice le plus important pour la trouver, bien plus utile qu'un code désassemblé...

ps : évite les "ok ok. dans l'ordre" : tu essaies de faire croire que vas être en mesure de tout contredire alors que t'ose plus aborder 9/10 des sujets sur lesquels j'ai répondu. Et ça tout le monde le voit : ça te rend encore moins crédible...

Whaou dis donc, ce sera encore un post mémorable.
Tu évites de fournir le moindre code 68000 pour mon code ARM, même technique que Touko pour sa démo.
Je n'ai pas vraiment réfléchi aux optimisations de Scorpius, et, ô incroyable, c'est sans doute dû au fait que mon jeu a un scroll vertical, pas horizontal.
Sachant qu'en horizontal je travaillerais avec un registre tout à fait spécifique et extrêmement mal documenté du MEMC, je vais te dire que le fait d'avoir de multiples tiles identiques à l'écran (donc utiliser une technique 1 chargement, n recopies ...) et bien ... je pourrai m'en passer très bien.
Il y fort à parier que ce soit plus un moyen de ne pas livrer un jeu sur 10 disquettes bourrées de graphs de niveau, en répétant les tiles du décor, qu'un véritable 'trick' soft.
Que tu te perdes dans des conjectures au travers de ton filtre d'analyse Amiga, c'est clair je m'en tape.
Et non je ne désassemblerai pas Scorpius, mon plaisir c'est de trouver par moi-même les solutions.
Je sais que sur Amiga ou ST vous procédiez ainsi, mais je n'en vois aucunement l'intérêt.

Au fait : on est bien d'accord : mes optimisations n'ont rien d'extraordinaire, puisque j'ai un Archimedes sous la main, pour produire ce genre de résultats.
Ce qui est fou c'est que si peu de codeurs soient arrivés aux mêmes routines.
Faut juste être un peu malin.
C'est, par analogie, le même raisonnement que j'ai tenu pour ce que vous m'avez montré sur l'Amiga : franchement ça n'a rien d'extraordinaire, d'ailleurs j'ai donné les solutions et les grosses ficelles, grâce au copert etc ... et comment refaire ça sur Archie.
Mais ça hou la la, surtout je n'aurais jamais dû le dire, j'ai touché la corde ultrasensible du fanatique pro Amiga, persuadé que SA machine a quelquechose d'unique, qui la place loin devant le reste. La bonne blague.
Celui qui fond d'émotion devant des bobsprites par centaines, ou une petite anim 'sprite' d'une toute petite anim' 3D, recopiée n fois à l'écran, me fait me tordre de rires.
Surtout quand comme le toutcon ou le petit Mickey il lance rageur 'tiens regarde ça ton Archie en serait bien incapable'.

Y a pas à dire, quelle bécane, l'Amiga. Quel talent, j'en suis sur le luc.
Amen.

[Invité]

Whaou dis donc, ce sera encore un post mémorable.
Tu évites de fournir le moindre code 68000 pour mon code ARM, même technique que Touko pour sa démo.

Si je prends le même temps que toi pour faire ma demo j'ai encore 19 ans et 11 mois, j'ai de la marge .
J'attends les specs que tu dois me donner depuis 3 plombes, pour savoir si je dois utiliser 256 ou 512 octets de ram(rigolez pas c'est important )
Sinon j'ai déjà les 3 gros sprites affichés à l'écran, 2 de 80*192 et 1 de 96*192 et déjà 46 couleurs ..
Ca m'a quand même pris 30 mins, dont 25 pour trouver et retoucher les sprites.

Personne a dit que l'amiga était unique, et le jour ou tu comprendras, que c'est en aucun cas le fait d'avoir dit que tu allais faire mieux que l'amiga en 2D sur archimedes qui nous gonfle (ça tant mieux pour toi, et la machine), mais ton égo tellement épais, tes critiques sur les demomakers, qui te cloueraient le bec (d'ailleurs je t'ai pas vu sur des forums de dev pour les critiquer, aurais tu les chocottes ???).
Surtout ,et là c'est risible de parler de trics, alors que tu en fais des tonnes.
Rien que le scroll sur archimedes, en hard il est de 2 bytes(soit 2 pixels), et non au
pixel, il faut trifouiller le memc pour l'avoir au pixel, et ça c'est pas de la bidouille crade ??

Des défauts sur amiga, je t'en donne quand tu veux .

[ArchieForEver]

Whaou dis donc, ce sera encore un post mémorable.
Tu évites de fournir le moindre code 68000 pour mon code ARM, même technique que Touko pour sa démo.

Si je prends le même temps que toi pour faire ma demo j'ai encore 19 ans et 11 mois, j'ai de la marge .
J'attends les specs que tu dois me donner depuis 3 plombes, pour savoir si je dois utiliser 256 ou 512 octets de ram(rigolez pas c'est important )
Sinon j'ai déjà les 3 gros sprites affichés à l'écran, 2 de 80*192 et 1 de 96*192 et déjà 46 couleurs ..
Ca m'a quand même pris 30 mins, dont 25 pour trouver et retoucher les sprites.

Personne a dit que l'amiga était unique, et le jour ou tu comprendras, que c'est en aucun cas le fait d'avoir dit que tu allais faire mieux que l'amiga en 2D sur archimedes qui nous gonfle (ça tant mieux pour toi, et la machine), mais ton égo tellement épais, tes critiques sur les demomakers, qui te cloueraient le bec (d'ailleurs je t'ai pas vu sur des forums de dev pour les critiquer, aurais tu les chocottes ???).
Surtout ,et là c'est risible de parler de trics, alors que tu en fais des tonnes.

Des défauts sur amiga, je t'en donne quand tu veux .

Voilà encore une fois typiquement le genre de posts complètement crétin du super imbécile de service qui bousille toujours les discussions qui pourraient être constructives : toutcon.
J'ai maintes fois écrit que ma preview de démo datait de 1992, c'est même dans le descriptif de Youtube, et lui me ressort que j'ai mis 20 ans pour la créer.

Relisez la file sur l'Archimedes A3020, déjà il arrive en descendant en flammes la bécane (notez d'ailleurs Oiseaudeproie qui lui explique poliment que c'est un con).
Vous laissez bien faire, histoire de pourrir la file.
OK.
Donc, Messieurs, ne vous étonnez pas si je vous envoie tous chier, vous ne méritez pas mieux.
Par dessus ça le Doc était passé pour dire que c'était l'esprit du forum.
Ok, roule Raoul, j'ai encore de la réserve pour être également excécrable.

[Invité]

C'est fou, tu essayes toujours de me faire passer pour le vilain petit canard, avec tes insultes archiottes (tu vois ça marche aussi) ..
Pourtant je vois pas ce qui te choque dans mon post, peut être parce que contrairement à toi je n'insulte pas , ou parce que je tape dans ce qui te sert d'égo en disant que je fais facilement mieux que toi avec une machine 8 bit .
Ce qui te fais chier c'est que je peux démontrer à tout le monde, que tu n'es rien qu'un bouffon prétentieux, car si moi qui suis pas un kaddor j'y arrive, imagines réellement les mecs de la scène ST/AMIGA .

Si ta demo ne te fait pas justice, vires là, et mets autre chose, t'as bien fait autre chose sur archimedes depuis 20 ans, à part insulter les coders ST/AMIGA, non ??
Rassures moi !!
Tu aimes bien te servir des posts des autres pour cracher ta merde, alors ne pleures pas si on fait pareil.

Surtout que tu te permettes de dire que ce que j'ai montrer est moche, alors que ta demo est à 1000 lieux,c'est culotté quand même.
Surtout que la version que j'ai mis en téléchargement direct sur le topic, fous une fessée magistrale à ta demo, et ses super routines, et ce sur un 8 bit coutant prés de 10 fois moins cher que ton archimedes.

Tiens tu prends le piaf comme témoin maintenant ???
Si il est venu un peu t'aider,c'est parce que j'ai un passif avec lui, et on s'aime pas bcp, pas parce qu'il te prend pour un génie, il doit bien se bidonner en lisant tes posts .
Toi c'est pas une personne, mais une bonne dizaine qui te disent poliment que tu es un con prétentieux, mais tu ne change pas pour autant.
Mais le pire, c'est que tu oses sortir que tout est de ma faute si ca dérape , sur ça j'ai même pas besoin d'argumenter quoi que ce soit .

Donc si tu veux pas que je te réponde, évites de m'attaquer dans tes posts, et réponds comme un grand a stapha92, qui t'a mouché plus d'une fois, ou a babsimov, que tu as presque envoyé chier ,alors qu'il échangeait simplement avec toi, sans attaque sur quoi que ce soit .

Alors au lieu de m'insulter,et de dire que je suis nul, DONNES MOI LES SPECS DE TA DEMO, et on en reparlera après.
Puisque comme le piaf tu dis que j'y connais rien en prog, je ferrais d'une pierre 2 coups.

[stapha92]

Whaou dis donc, ce sera encore un post mémorable.
Tu évites de fournir le moindre code 68000 pour mon code ARM, même technique que Touko pour sa démo.
Je n'ai pas vraiment réfléchi aux optimisations de Scorpius, et, ô incroyable, c'est sans doute dû au fait que mon jeu a un scroll vertical, pas horizontal.
Sachant qu'en horizontal je travaillerais avec un registre tout à fait spécifique et extrêmement mal documenté du MEMC, je vais te dire que le fait d'avoir de multiples tiles identiques à l'écran (donc utiliser une technique 1 chargement, n recopies ...) et bien ... je pourrai m'en passer très bien.
Il y fort à parier que ce soit plus un moyen de ne pas livrer un jeu sur 10 disquettes bourrées de graphs de niveau, en répétant les tiles du décor, qu'un véritable 'trick' soft.
Que tu te perdes dans des conjectures au travers de ton filtre d'analyse Amiga, c'est clair je m'en tape.
Et non je ne désassemblerai pas Scorpius, mon plaisir c'est de trouver par moi-même les solutions.
Je sais que sur Amiga ou ST vous procédiez ainsi, mais je n'en vois aucunement l'intérêt.

Au fait : on est bien d'accord : mes optimisations n'ont rien d'extraordinaire, puisque j'ai un Archimedes sous la main, pour produire ce genre de résultats.
Ce qui est fou c'est que si peu de codeurs soient arrivés aux mêmes routines.
Faut juste être un peu malin.
C'est, par analogie, le même raisonnement que j'ai tenu pour ce que vous m'avez montré sur l'Amiga : franchement ça n'a rien d'extraordinaire, d'ailleurs j'ai donné les solutions et les grosses ficelles, grâce au copert etc ... et comment refaire ça sur Archie.
Mais ça hou la la, surtout je n'aurais jamais dû le dire, j'ai touché la corde ultrasensible du fanatique pro Amiga, persuadé que SA machine a quelquechose d'unique, qui la place loin devant le reste. La bonne blague.
Celui qui fond d'émotion devant des bobsprites par centaines, ou une petite anim 'sprite' d'une toute petite anim' 3D, recopiée n fois à l'écran, me fait me tordre de rires.
Surtout quand comme le toutcon ou le petit Mickey il lance rageur 'tiens regarde ça ton Archie en serait bien incapable'.

Y a pas à dire, quelle bécane, l'Amiga. Quel talent, j'en suis sur le luc.
Amen.

Je t'ai répondu sur le code 68000 : relis les posts et donne moi un vrai algo de traitement de données et je le converti.

Tu pourrais t'en passer de l'astuce de scorpius si tu fais un scroll horizontal ? Oui je vois la "technique" : tu spécifie un décalage de pixel de 0 a 3 puis tu ajoutes 4 à l'adresse écran. une question : les 4 pixels qui étaient le plus à droite de l'écran. Ils se retrouvent ou quand tu changes l'adresse ?
ça y est ? tu commences à comprendre le problème ?...

T'es même pas capable de comprendre un scroll horizontal...
Et même en vertical : Scorpius a 2 layer. Comment tu t'en sors avec tes registres ?

Ah oui, c'est vrai : tu vises un scroll vertical avec 1 seul layer pour démontrer que ça sera plus fort que le mig...

Un filtre Amiga ? Il n'empeche que moi j'ai compris quelque juste à la vue de la vidéo. Toi tu connais le jeu depuis 20 ans et t'as aucune idée de la méthode (c'est pas 1 lecture pour n recopies l'astuce...)

Ah bon ? t'as donné des solutions toi ? Tu peux me citer UN post ou tu as donné une explication aussi détaillée que les miennes et pas un truc vague du genre : "suffit d'utiliser le timer" (dont tu te rendais même pas compte que sa valeur de 2Mhz est pourrie...)

tu me fais rire : t'as carrément parlé de synchroniser ton code avec le balayage vidéo pour tracer des lignes (donc au pixel près). jamais rien vu de plus ridicule...

Au moins tu reconnais ne pas avoir compris l'astuce dans Scorpius : encore un sujet que tu va éviter maintenant.

Et des 'regarde ça ton Archie en serait bien incapable', je peux t'en envoyer des tonnes :
LionHeart, Kid chaos, soccer kid, Brian the lion, M. Nutz, SOTB, etc...

Et là il s'agit de vrais jeux INFAISABLES sur ta machine...

[Invité]

tu me fais rire : t'as carrément parlé de
synchroniser ton code avec le balayage vidéo pour tracer des lignes
(donc au pixel près). jamais rien vu de plus ridicule...

Bah avec ses 2 timers, c'est fingers in the noze .
Surtout que pour faire un truc comme ça il faut au moins une interruption raster stable, donc avec ses timers, il peut se lever de trèèèèès bonne heure .

[stapha92]

tu me fais rire : t'as carrément parlé de
synchroniser ton code avec le balayage vidéo pour tracer des lignes
(donc au pixel près). jamais rien vu de plus ridicule...

Bah avec ses 2 timers, c'est fingers in the noze .

[ArchieForEver]

tu me fais rire : t'as carrément parlé de
synchroniser ton code avec le balayage vidéo pour tracer des lignes
(donc au pixel près). jamais rien vu de plus ridicule...

Bah avec ses 2 timers, c'est fingers in the noze .

Bien bien bien.
Chers lecteurs, je vous invite à lire ce que j'ai écrit en page 2, savoir :
'J'ajouterai qu'à mon avis l'Archie peut faire du
remplissage de face partiellement sous DMA, en changeant le pointeur
video grâce au Timer1 de l'IOC, et ça à mon avis personne n'y a jamais
pensé. C'est un des prochains points que je veux étudier.
'

Comme ça n'a rien à voir avec les propos qui me sont attribués par les 2 burnes, je me mets en congé de ce forum d'abrutis pour 2 semaines.

Vous pourrez ainsi continuer entre grands 'spécialistes', sans moi qui suis le seul à bien connaître l'Archimedes.

Si dans 15 jours vous avez envie de reprendre un débat constructif, faites moi signe.
Je ne peux décemment pas continuer à perdre mon temps ainsi avec des cons.

[Invité]

A+ l'élu, et bons vents

J'ajouterai qu'à mon avis l'Archie peut faire du
remplissage de face partiellement sous DMA, en changeant le pointeur
video grâce au Timer1 de l'IOC, et ça à mon avis personne n'y a jamais
pensé

Et tu t'es jamais demandé pourquoi ???
Tu verras bien en faisant tes tests .

Les lecteurs pourront voir ça aussi :
https://www.youtube.com/all_comments?v=TjVeZ9c9fLM

Faut lire les coms du pauvre archiforever .

[Philou]

Je dois dire que je n'y connais rien du tout en termes de programmation, je ne saurais donc dire qui a raison et qui a tort. Il est juste dommage qu'il y ait autant d'hostilités, juste pour défendre deux ou trois machines, alors que la guerre est finie depuis plus de vingt ans (à noter tout de même que les défenseurs du ST n'étaient pas présents pour défendre leur propre machine, c'est peut-être mieux ainsi car le pugilat, déjà violent ici se serait transformé en bain de sang !)... D'ailleurs, j'estime qu'il n'y en a jamais vraiment eu, puisque apparemment, Accorn ne le positionnait pas sur le même marché que les ST et Amiga. Enfin bref, toujours est-il que je suis tout à fait persuadé que l'Archimèdes est une excellente machine, un peu comme les BBC l'étaient en leur temps (effectivement, il est très dommage de ne jamais voir de sujets à propos de ces machines, et de ce que l'on peut faire avec, sans tomber dans la guéguerre par rapport aux autres machines huit bits)

Enfin bref... J'ose néanmoins espérer, Archi, que tu nous montreras les résultats que donnera ton shoot en 2D, je suis très curieux de voir ce que ça donne, et peut-être qu'il nous montrera ce que peut vraiment donner un Archimèdes en 2D. En attendant, à bientôt.

[stapha92]

tu me fais rire : t'as carrément parlé de
synchroniser ton code avec le balayage vidéo pour tracer des lignes
(donc au pixel près). jamais rien vu de plus ridicule...

Bah avec ses 2 timers, c'est fingers in the noze .

Bien bien bien.
Chers lecteurs, je vous invite à lire ce que j'ai écrit en page 2, savoir :
'J'ajouterai qu'à mon avis l'Archie peut faire du
remplissage de face partiellement sous DMA, en changeant le pointeur
video grâce au Timer1 de l'IOC, et ça à mon avis personne n'y a jamais
pensé. C'est un des prochains points que je veux étudier.
'

Comme ça n'a rien à voir avec les propos qui me sont attribués par les 2 burnes, je me mets en congé de ce forum d'abrutis pour 2 semaines.

Vous pourrez ainsi continuer entre grands 'spécialistes', sans moi qui suis le seul à bien connaître l'Archimedes.

Si dans 15 jours vous avez envie de reprendre un débat constructif, faites moi signe.
Je ne peux décemment pas continuer à perdre mon temps ainsi avec des cons.

C'est bien de te citer : tu confirmes exactement ce que l'on dit.

Tu veux changer le pointeur vidéo pour faire du remplissage : ça veut dire que tu veux mettre l'adresse d'une zone qui est de la couleur de la ligne a afficher à chaque fois qu'il y a changement de couleur. Et c'est débile :

- D'abord le circuit vidéo lit les données 32 bits à la fois. Donc 4 pixel en 256 couleurs et 8 en 16 couleurs. Donc au mieux tu aurais une résolution de 320/4=80 pixels de large (ou 40 en 16 couleurs.). On oublie...

- Ensuite, il faut de la vitesse : il faut pouvoir traiter 7,14 millions de changement de pointeur pour pouvoir avoir une résolution d'un pixel. Non seulement le proc n'est pas assez rapide (et un 68000 encore moins, rassure toi), mais t'as même pas de timer assez rapide. On oublie...

- C'est idiot : il vaut mieux travailler avec la palette : on ouvre un écran de 2 couleur seulement qu'on remplit avec la couleur 1 dont on change la valeur dans la palette. Non seulement l'écran de ce type permet d'économiser de la bande passante mais comme tu travailleras sur la palette, tu auras accès à 4096 couleur. Et la palette c'est 16 bits à modifier là ou une adresse c'est 32. Ne te fatigue pas : meme en travaillant sur la palette, ça reste complètement impossible. Regarde la difficulté à faire un raster sur l'archimedes alors que là c'est un seul changement par ligne (15 Khz vs 7,14 Mhz). On oublie...

Tu vois : tu proposes quelque chose de complètement iréalisable mais si on met de coté ce fait, ta solution est nulle : résolution pourrie, bande passante gaspillée et traitement plus lourd (32 bits vs 16) : même dans l'irréalisable t'es mauvais...

Tu vois pour le problème du nombre de pixels traités en même temps : moi je vois le souci tout de suite, toi t'en serais rendu compte au bout de plusieurs années d'essais...

T'es tellement imbu de ta personne que quand on t'explique que tu es à coté de la plaque, tu n'imagines pas qu'on ait pu te comprendre et qu'on ne triche pas...

"C'est un des prochains points que je veux étudier" : ça me fait pitié de voir à quel point tu es à coté de la plaque... Pauvre garçon...