Re: Amiga/st vs Archimede

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

[Invité]

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.

Absolument pas l'archimedes ne peut que scroller horizontalement sur 2 octets (soit 2 pixels en 256 couleurs, et 4 en 16), sans un tric du memc ..
Et encore le tric ne permet que du 1 octet, donc 1 pixel en 256 couleurs, et 2 en 16, l'ecroc ici c'est toi ..
Faudra que tu m'explique, où es ce que j'ai faux lol, tu repètes exactement ce que je venais de dire.

d'ailleurs je suis quasiment sur que c'est un peu pour ça que ton shoot sera en scroll vertical ..
Ensuite, tu choisis la facilité, en vertical tu rafraîchis 1 ligne continue de 320 octets, facile sans te faire chier tu fais ça par DMA, alors que sur un scroll horizontal, le DMA te sert à rien, et tu es obligé de le faire au CPU ..

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.

La preuve que sorti de ton archimedes (que tu maitrise pas en plus), tes connaissances des autres machines sont au ras les paquerettes mon ptit archi ..
Les pixels seront pas plus fin, il y en aura plus à l'écran, et comme sur pce le chip video est prevu pour faire des scrolls en 512*256 à 60 fps, je vois pas ou est le prob ..
Comme d'hab tu parles sans connaitre quoi que ce soit de la pce .

Le changement de res ,n'affecte pas les sprites, qui sont hard, dois je te le rappeler ??

[65c02]

Franchement archi, après avoir péroré pendant 22 pages, faut vraiment que tu nous ponde une démo qui calme.
T'es monté tellement haut dans le mépris et l'auto statisfaction que ça me ferait chier que tu ne sois pas un vrai emmerdeur génial :)

[ArchieForEver]

Là, c'est du basique 256x224, mais on peut faire du 320x224 ou du 512x224 .

Alors finalement cette démo Touko, quelle est sa vraie résolution ?
Car quand tu parles de la merdouille que tu as déjà produite, tu ne parles pas de mode graphique 256x256 pour ta PCE.
Bizarre, bizarre, non ?

[ArchieForEver]

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.

Absolument pas l'archimedes ne peut que scroller horizontalement sur 2 octets (soit 2 pixels en 256 couleurs, et 4 en 16), sans un tric du memc ..

N'importe quoi.
T'es vraiment une pauvre tache.

[ArchieForEver]

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.

Absolument pas l'archimedes ne peut que scroller horizontalement sur 2 octets (soit 2 pixels en 256 couleurs, et 4 en 16), sans un tric du memc ..
Et encore le tric ne permet que du 1 octet, donc 1 pixel en 256 couleurs, et 2 en 16, l'ecroc ici c'est toi ..
Faudra que tu m'explique, où es ce que j'ai faux lol, tu repètes exactement ce que je venais de dire.

Tu ne sais pas lire ou tu ne comprends rien.(je retiendrai cette dernière possibilité, car c'est une constante depuis le début de nos échanges : t'es une burne en logique et en programmation).
- Il y a une méthode qui donne un scroll hardware horizontal de 1 octet => on se sert de celle là pour les modes 256 couleurs (1 octet définit 1 pixel)
- Il y a une autre méthode qui elle fonctionne pour tous les modes graphiques où l'on obtient un scroll hardware horizontal de 2 pixels. (quel que soit le mode graphique, je le répète).

T'es vraiment juste bon qu'à épauler Stapha pour déblatérer n'importe quoi sur ce forum.
C'est extraordinaire d'avoir face à moi, qui connais cette machine et la programme encore aujourd'hui, des imbéciles prétentieux qui me contredisent, sans rien n'y connaître, sans n'avoir jamais touché une bille en programmation ARM dessus.
Au-delà c'est le Soleil !

[ArchieForEver]

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.

Absolument pas l'archimedes ne peut que scroller horizontalement sur 2 octets (soit 2 pixels en 256 couleurs, et 4 en 16), sans un tric du memc ..
Et encore le tric ne permet que du 1 octet, donc 1 pixel en 256 couleurs, et 2 en 16, l'ecroc ici c'est toi ..
Faudra que tu m'explique, où es ce que j'ai faux lol, tu repètes exactement ce que je venais de dire.

d'ailleurs je suis quasiment sur que c'est un peu pour ça que ton shhot sera en scroll vertical ..
Ensuite, tu choisis la facilité, en vertical tu rafraîchis 1 ligne continue de 320 octes, facile sans te faire chier tu fais ça par DMA, alors que sur un scroll horizontal, le DMA te sert à rien, et tu es obligé de le faire au CPU ..

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.

La preuve que sorti de ton archimedes (que tu maitrise pas en plus), tes connaissances des autres machines sont au ras les paquerettes mon ptit archi ..
Les pixels seront pas plus fin, il y en aura plus à l'écran, et comme sur pce le chip video est prevu pour faire des scrolls en 512*256 à 60 fps, je vois pas ou est le prob ..
Comme d'hab tu parles sans connaitre quoi que ce soit de la pce .

Le changement de res ,n'affecte pas les sprites, qui sont hard, dois je te le rappeler ??

Ah ? OK je vois : alors les sprites sont toujours hyper moches dans une résolution hyper basse, même si on monte en résolution écran ?
C'est bien ce qu'on voit sur ta démo : des sprites laidement composés de gros carrés colorés (lol : pixel=gros carré sur PCE).
De 2 choses l'une :
- soit la réso des sprites est fixe, donc c'est toujours moche, style gros pâtés Amstrad vomitifs.
- soit la réso des sprites suit la résolution de modes, et donc comme je le disais, tu auras besoin de nettement plus de sprites hard pour constituer les 3 sprites que tu animes à l'écran.(logique : si les pixels sont plus fins, il faut en afficher plus pour constituer un sprite final de grande taille).

Il semblerait donc que pour l'affichage de sprites bruts ta PCE c'est de la pure daube par rapport à mon Archie où j'évolue avec tellement moins de contraintes, et dans des résolutions tellement supérieures.

Je comprends mieux pourquoi le rendu visuel sur PCE est absolument immonde en toute occasion.

Ta démo ne vaut pas tripette par rapport à ce que j'ai produit sur Archie.

Une fois de plus on constate les limites de toutes les petites machines équipées de copros limités.
En gros la PCE est bien équipée pour une taille d'écran gameboy, mais certainement pas pour une télé traditionnelle.
L'horreur !
Merci Touko d'amener toute l'eau nécessaire à mon moulin.

PS : Ton explication sur le scroll hard vertical / horizontal, et le DMA est tout bonnement à se pisser de rire tellement tu racontes n'importe quoi.
Tu ne piges RIEN au fonctionnement d'un Archimedes, avec ton filtre de lecture PCE ou Amiga, ou plutôt devrais-je dire tes peaux de saucissons.

En tout cas merci de l'avoir écrit, ça fera rire beaucoup de lecteurs anglophones quand je vais les inviter à venir lire la file pour se marrer comme des baleines.

J'espère que Oiseaudeproie repassera par là, il aura l'occasion de bien se bidonner avec tes nouvelles touconneries.


Je te ferai un scroll horizontal pixel par pixel sur Archie, et toi et ton comique et incompétent comparse Stapha (avec ses propos débiles sur les modulos, et tous les autres propos apparmment techniques et bien argumentés, qui ne sont que des sophismes trolliens amigagaens) vous pourrez aller ravaler votre suffisance basée sur le néant neuronal.

Pour info, et malheureusement je vais devoir l'écrire en gros car ça n'est jamais bien rentré dans vos crânes : SI J'UTILISE UN SCROLL HARD VERTICAL C'EST PARCEQUE JE VEUX PRODUIRE UN SWIV OU BATTLE SQUADRON A LA MESURE DE L'ARCHIMEDES.
C'est bon, là ? Capito ?

Si un jour je veux faire un remake de Scorpius ou Nevryon, j'utiliserai une routine de scroll hard horizontal... oô^^oôô^^oo^ce sera terriblement compliqué, j'en rirais presque aux larmes si votre connerie et votre incompétence cumulées à tous 2 n'étaient pas si grave.

[Lesarthois]

Une fois de plus on constate les limites de toutes les petites machines équipées de copros limités.

Et une fois encore l'on constate les limites d'une énorme tête équipée d'une matière grise limitée

[Invité]

Tu ne sais pas lire ou tu ne comprends rien.(je retiendrai cette dernière possibilité, car c'est une constante depuis le début de nos échanges : t'es une burne en logique et en programmation).
- Il y a une méthode qui donne un scroll hardware horizontal de 1 octet => on se sert de celle là pour les modes 256 couleurs (1 octet définit 1 pixel)
- Il y a une autre méthode qui elle fonctionne pour tous les modes graphiques où l'on obtient un scroll hardware horizontal de 2 pixels. (quel que soit le mode graphique, je le répète).

T'es vraiment juste bon qu'à épauler Stapha pour déblatérer n'importe quoi sur ce forum.
C'est extraordinaire d'avoir face à moi, qui connais cette machine et la programme encore aujourd'hui, des imbéciles prétentieux qui me contredisent, sans rien n'y connaître, sans n'avoir jamais touché une bille en programmation ARM dessus.
Au-delà c'est le Soleil !

Non mais tu es grave toi, qu'es ce que je te dis depuis le début ???
Tu lis au moins ???
Je dis que de base ça marche comme ça,horizontalement l'archie ne scrolle que de 2 octets, et il faut une bidouille du memc pour le faire à l'octet, donc au pixel en mode 256 couleurs, mais ça reste à 2 pixel en mode 16 couleurs(sinon sans c'est 4) ..
y'a pas besoin de faire de l'ASM arm pour comprendre une doc technique ou il est bien dit que l'archimedes ne fait que du scrolling horizontal sur 2 octets, le reste je l'ai trouvé (la bidouille du memc) sur un site de dev qui explique la bidouille ..
Et après tu vas soutenir, que les trics sur archie, y 'en a pas ..

Ensuite ne parles pas de mec qui comprend rien, puisque tu viens me parler de la pce, et me dire que j'ai tord sur la reso, et ses perfs, alors que tu sais même pas comment ça marche ..

Si je te dis dot clock tu connais ??
Et bien le VDC (le circuit graphique de la pce) lorsqu'on change de résolution cela modifie son dot clock, CAD sa fréquence de fonctionnement, elle est de 5 mhz en 256, 7 en 320, et 10 en 512, tu comprends là, où il faut faire un dessin ???

La masse de données est un facteur important pour ton ARM qui se coltine plus de pixels à bouger avec toujour la même BP, donc le même fillrate, alors que moi (et comme toutes les consoles), le circuit graphique adapte son fillrate et sa BP à la résolution pour garder les même perfs(grâce au dot clock) .
Donc scroller un écran en 256,320 ou 512 ne change absolument rien .
tu risque juste d'avoir besoin de plus de rom/vram, 10 ecrans 512 ne represente pas le même nombre de données que 10 en 256, sauf si tu utilises en 512, les mêmes tiles qu'en 256 .

Et ne cherches pas à descendre ma demo, qui fou une raclée à tes routines de la mort, alors que tout le monde ici s'est rendu compte que ta demo c'est un gros flan au pâté .

Et quand je pense qu'il me reste encore 95% de CPU, et que tu te pavanne avec tes 15% sur ton ARM suprapuissant qui tourne à presque 1mhz de plus, en 32 bit, c'est trop ..

Argumentation archiottes :

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.

Absolument pas l'archimedes ne peut que scroller horizontalement sur 2 octets (soit 2 pixels en 256 couleurs, et 4 en 16), sans un tric du memc ..

N'importe quoi.
T'es vraiment une pauvre tache.

Evidemment insultes (comme tout les mecs qui savent pas quoi dire de technique).

Et après :

Tu ne sais pas lire ou tu ne comprends rien.(je retiendrai cette dernière possibilité, car c'est une constante depuis le début de nos échanges : t'es une burne en logique et en programmation).
- Il y a une méthode qui donne un scroll hardware horizontal de 1 octet => on se sert de celle là pour les modes 256 couleurs (1 octet définit 1 pixel)
- Il y a une autre méthode qui elle fonctionne pour tous les modes graphiques où l'on obtient un scroll hardware horizontal de 2 pixels. (quel que soit le mode graphique, je le répète).

La vache il me ressort exactement ce que je dis,après m'avoir insulté, et tente de se reccrocher aux branches ou en jouant sur le peu de mots de son vocabulaire (pas trop quand même, son vocabulaire est plus fourni en insultes que tout le reste), pour avoir l'air moins con ..
:thumright: , trop fort l'ami ..

Ah ? OK je vois : alors les sprites sont toujours hyper moches dans une résolution hyper basse, même si on monte en résolution écran ?
C'est bien ce qu'on voit sur ta démo : des sprites laidement composés de gros carrés colorés (lol : pixel=gros carré sur PCE).

Abbrutis, si tu veux augmenter le nombre de pixels sur les sprites rien t'en empêche, la preuve le plus gros fait 96*192, aucun des tiens ne fait cette taille .
Un sprite qui fait 16*16 pixels, peut importe la réso, il fera toujours 16*16 pixels ..
Et on peut demander l'avis des gens qui lisent ..
Es ce que ma demo parait plus moche que celle d'archi avec ses pseudos 256 couleurs ???

J'espère que Oiseaudeproie repassera par là, il aura l'occasion de bien se bidonner avec tes nouvelles touconneries.

Qu'il vienne, mais à mon avis il prendra plus le risque de te soutenir vu les conneries que tu débites.
Et ça me ferai bien marrer ça tient .

De toutes façons maintenant à part les insultes il te reste plus rien, tu ne sais même plus sur quoi argumenter ..
Techniquement ça fait un bail que tout le monde ici sait que t'y connais pas grand chose.

Stapha t'a même expliqué comment programmer ta machine, c'est un comble ça .
Maintenant si tu veux continuer le débat, prends au moins le soin de te renseigner techniquement sur les machines que tu critiques, après on pourra discuter .

Alors finalement cette démo Touko, quelle est sa vraie résolution ?
Car quand tu parles de la merdouille que tu as déjà produite, tu ne parles pas de mode graphique 256x256 pour ta PCE.
Bizarre, bizarre, non ?

Non les 256 verticaux c'est de l'overscan bananne, donc dans un scroll horizontal, tu ne vois quasiment que 224 pixels(240 pour être exact) ..
donc que tu mettes 1 pixel ou 256, la console fait du scroll sur 256 pixels .
Puisque ses résos sont 256*256,320*256,512*256 ..

D'autres précisions ???

Quand tu verras ma version 2 en 384 x 288 voire 416 x 288, on va rire.

Ah bon si ça peut te faire plaisir, je ferai tourner la mienne en 512*256 ..
Et effectivement on va rire, car ça va me prendre 1h pour retravailler le fond, et un peu le code .
Et j'aurai toujours 95% de CPU de libre, et à 60 fps ..
Toi ta machine elle va tirer la gueule dis donc .
Mais bon une leçon de plus risque de mettre à mal le peu de crédibilité qu'il te reste .

Un mec que certains doivent connaitre, à fait un jeu sur pce, avec plusieur centaines de couleurs à l'ecran, des zooms, etcc ..., et surtout tourne à 512*256 .
Ce mec est largement plus balaise que moi(et c'est pas le seul dans la scène pce).

Il s'appelle chris covell ..
Voilà son jeu :

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.

Ah oui dsl, j'avais oublié qu'il fallait pas que j'utilise le hardware à dispo de la console, c'est presque à se demander si pour faire tourner la demo, j'avais le droit d'allumer la console, ou je devais me démerder pour qu'elle tourne console éteinte !!

sinon tu voulais quoi que je joue un mod sur la console ???
Ton son DMA est sensé consommer très peu aussi comme sur l'amiga (mais c'est pas le cas il me semble).
Et puis avec tes 4 mips CPU ( ), que tu nous balances à longueur de temps, c'est no problèmo non ..
Une musique via le PSG (le générateur de son), consomme quasi rien, et tu penses c'est pas les 5% de moins sur mes ressources qui vont changer grand chose, j'aurai toujours 90% de libre, pour botter ton ptit derrière prétentieu .

Rien que mon effet de feu pour mon jeu, tourne en temps réel à 60 fps, et consomme quasi rien en CPU,je peux sans soucis animer des sprites dessus et donc m'en servir ingame..
Je l'intégrerai surement dans un niveau de BB ..
Et ça tu peux te grater pour le faire sur ta machine révolutionnaire .

[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 :)

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.

Tout ce que je peux te dire, c'est que tu as promis de montrer ta démo méga optimisée dans 3 semaines maintenant (un mois moins une semaine).

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.

Alors, je suis pas du tout d'accord avec toi la dessus.
Stapha a participé à de nombreuses discussions ici au sujet de l'Amiga et tout ce qu'il a dit au sujet de la machine m'a paru tout à fait conforme à mon souvenir d'utilisateur et à mes recherches sur son histoire et ses capacités. Il a même dit, comme la majorité des connaisseurs de l'Amiga, que le chipset AGA était une mise à jour au rabais du chipset et que ce n'était pas du tout au niveau de ce qu'on aurait pu attendre de la part de Commodore. J'en avais parlé ici, quand tu expliquais que le 1200 était le seul Amiga valable pour toi. Mais en plus, Stapha dans les sujets dont je parle apporte, bien sur, le coté technique et programmation plus poussé. Je peux t'assurer qu'on sent bien qu'il connait l'Amiga et même très bien au même titre que tu connais ta machine favorite.
Pour moi, le problème est que tu veux démontrer qu'un processeur SEUL peut égaler ou surpasser une machine équipée de copros. Et ça, de l'avis général ici, c'est peu probable. Vois ce qu'une PC engine peut faire, sans vouloir t'offenser, c'est plus beau (tout le monde le dit ici) que la démo que tu as montré.
Mais, il s'agit d'une preview de test, tu l'as déjà expliqué. Tout le monde ici attend de voir la version finale optimisée et, là, on verra si l'Archimèdes peut vraiment laminer un Amiga en 2D, comme tu l'as dit.

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.

La je dirais que tu est de mauvaise foi, depuis le début c'est ce que tu n'arrêtes pas de sous entendre (sinon plus). C'est de bonne guerre pour défendre sa machine, mais même dans les fight Amiga/ST chacun admettait que la machine concurrente avait un tant soi peu de qualités, on te demande juste d'avoir une attitude plus "ouverte".
Moi aussi je me suis énervé sur les sujets Amiga, mais c'est pas pour ça que je méprise le ST. Finalement je lui ais trouvé certain avantages, notamment le ASCI d'origine, le MIDI et le mode monochrome bien pratique pour la bureautique par son confort. Toi, en dehors de l'Archimèdes, point de salut, c'est un peu dommage.

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.

Je comprends mieux pourquoi le rendu visuel sur PCE est absolument immonde en toute occasion.
Ta démo ne vaut pas tripette par rapport à ce que j'ai produit sur Archie.

Une fois de plus on constate les limites de toutes les petites machines équipées de copros limités.
En gros la PCE est bien équipée pour une taille d'écran gameboy, mais certainement pas pour une télé traditionnelle.
L'horreur !
Merci Touko d'amener toute l'eau nécessaire à mon moulin.

Mais, à part ça, tu ne sous entend pas qu'en dehors de l'Archimède tout est nul :)
Par ailleurs le 256x256 ou 320x256 ça fait pas une grosse différence, c'est de la basse résolution, donc pixelisé. C'était le standard du jeu de l'époque. Et en plus, personnellement je trouve pas ça "immonde" comme tu dis. Sans vouloir te vexer, ta démo est graphiquement bien moins jolie pour rester correct.
Mais, tout le monde n'a pas non plus un don pour le graphisme, même toi :)

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.

Moi ce qui m'interpèle, c'est plutôt qu'une machine avec un processeur 8 bit et des copros fasse mieux qu'un Archimèdes avec un processeur 32 bits SEUL. Je dirais que ça démontre plutôt l'inverse de ton propos, un système à coprocesseur est toujours meilleur qu'une machine sans, même si la machine sans est plus puissante.
Bien sur, il faut rester relatif. C'est sur que si la machine est 200 ou 300 fois plus puissante c'est plus valable. Mais, l'Archimèdes n'avait pas un tel ratio à l'époque, si je me trompe pas.
A toi de prouver avec ta démo ou ton jeu que c'est une idée fausse.

Je te ferai un scroll horizontal pixel
par pixel sur Archie, et toi et ton comique et incompétent comparse
Stapha (avec ses propos débiles sur les modulos, et tous les autres
propos apparmment techniques et bien argumentés, qui ne sont que des
sophismes trolliens amigagaens) vous pourrez aller ravaler votre
suffisance basée sur le néant neuronal.

Incroyable, tu crois pas que s'il y a quelqu'un de suffisant ici, c'est toi ?
J'en reviens pas de lire ça !
Mettons ça sur le thème de ce sujet, le "fight", pour rester serein :)

Pour info, et
malheureusement je vais devoir l'écrire en gros car ça n'est jamais bien
rentré dans vos crânes : SI J'UTILISE UN SCROLL HARD VERTICAL C'EST
PARCEQUE JE VEUX PRODUIRE UN SWIV OU BATTLE SQUADRON A LA MESURE DE
L'ARCHIMEDES.
C'est bon, là ? Capito ?

Swiv, c'était pas trop mon jeu de référence. Par contre, Battle Squadron lui était mon shoot préféré sur Amiga.
Tu parles de scroll vertical pour ton jeu, Mais Battle Squadron avait aussi un scroll horizontal. Donc, si tu veux montrer que l'Archimèdes peut égaler l'Amiga, il te faut les deux types de scroll dans ton jeu. En prenant Battle Squadron comme référence, je pense que tu as placé la barre assez haut.
Donc si ton jeu est aussi bon, là, mes respects !
Plus que trois semaines pour voir ça.

[ArchieForEver]

Tu ne sais pas lire ou tu ne comprends rien.(je retiendrai cette dernière possibilité, car c'est une constante depuis le début de nos échanges : t'es une burne en logique et en programmation).
- Il y a une méthode qui donne un scroll hardware horizontal de 1 octet => on se sert de celle là pour les modes 256 couleurs (1 octet définit 1 pixel)
- Il y a une autre méthode qui elle fonctionne pour tous les modes graphiques où l'on obtient un scroll hardware horizontal de 2 pixels. (quel que soit le mode graphique, je le répète).

T'es vraiment juste bon qu'à épauler Stapha pour déblatérer n'importe quoi sur ce forum.
C'est extraordinaire d'avoir face à moi, qui connais cette machine et la programme encore aujourd'hui, des imbéciles prétentieux qui me contredisent, sans rien n'y connaître, sans n'avoir jamais touché une bille en programmation ARM dessus.
Au-delà c'est le Soleil !

Non mais tu es grave toi, qu'es ce que je te dis depuis le début ???
Tu lis au moins ???
Je dis que de base ça marche comme ça,horizontalement l'archie ne scrolle que de 2 octets, et il faut une bidouille du memc pour le faire à l'octet, donc au pixel en mode 256 couleurs, mais ça reste à 2 pixel en mode 16 couleurs(sinon sans c'est 4) ..
y'a pas besoin de faire de l'ASM arm pour comprendre une doc technique ou il est bien dit que l'archimedes ne fait que du scrolling horizontal sur 2 octets, le reste je l'ai trouvé (la bidouille du memc) sur un site de dev qui explique la bidouille ..
Et après tu vas soutenir, que les trics sur archie, y 'en a pas ..

T'es bien juste à nouveau à côté de tes pompes : de base, l'Archie fait du scroll hardware horizontal de 2 PIXELS, et non pas 2 OCTETS.
Lis bien :
P comme Patate
I comme Imbécile
X comme eXtrêmiste
E comme Ecoute donc ce qu'on te dit
L comme Lamentable.
Et encore, cette formulation 'de base' ne veut rien dire sans précision complémentaire.
T'as dû la lire vachement bien la doc pour me parler d'octet quand il s'agit de pixel.

Vas vite lire ce que d'autres ont écrit pour tenter de te raccrocher aux branches, rigolo, va.
Mais essaie de ramener les propos de ceux qui n'écrivent pas n'importe quoi.
Je sais : ce sera forcément très dur pour toi, car à part les wikis ou les interprétations pré mâchées que d'autres ont produit, tu ne risques pas de sortir quoi que ce soit d'intelligent par toi-même.

J'arrêterai là pour ce week end.
Echanger avec des burnes qui ne connaissent pas la machine, n'en ont jamais possédé une, et encore moins programmé, ça devient ridicule.

Tu n'as toujours rien compris à la différence à faire en regardant les démos pour apprécier ce qui plussoit une machine, ou plussoit des astuces visuelles à 2 balles.

Et je n'ai jamais soutenu qu'il n'y avait pas de trics sur Archie, la preuve : je m'en sers.
Par contre c'est sûr afficher une multitude de bobs avec la technique de mémoire de trames, ou bien une séquence d'anim 3D en 32x32 recopié N fois, ça j'aurais honte de le produire.
C'est juste bon pour épater les gogos qui ne pigent rien en programmation.
Tsss....

[stapha92]

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.

Et qu'est-ce qui te permet de l'affirmer ? Ta connaissance du mig ? Chaque fois que tu as abordé un point technique sur le mig, tu t'es lamentablement planté, tout le monde l'a vu...

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.

Ne parle pas de ce que tu ne connais pas : l'explication que tu as donnée pour les frames multiples n'est pas bonne du tout. Et si ça marchait comme tu le dis, faudrait que tu expliques comment faire pour supprimer des bobs qui peuvent se trouver devant et/ou derrière des bobs à conserver. Tu devrais essayer d'appliquer ta méthode sur ta machine qu'on rigole...
Ah tu n'y avais pas pensé ? Ou, pire, tu ne comprends pas ? ça m'étonne pas de toi : tu ne vois que la surface des choses. D'ailleurs t'es tellement nul que tu passes ton temps à te gargariser d'être un codeur, voire un developpeur. Mais tu fais ça sur un site de jeu : pourquoi ne pas allez dans des forums de dev ? Peur d'affronter la réalité ?
Developpeur de quoi d'ailleurs ? d'une pauvre démo avec un sinus scroll raté ? (alors que les VRAIS codeurs savent tous que c'est beaucoup plus facile à faire avec un affichage chunky...)

Je ne discuterai pas avec un type de mauvaise foi qui mélange vérités et contre vérités.

Oui c'est ça. Dis plutot avec un type qui te mouche à chaque fois.
Besoin de quelques piqures de rappel ? Ok :
- t'as sorti des énormités sur le blitter. Quand je t'ai détaillé ses capacités, t'as plus osé abordé le sujet.
- t'en as sorti des aussi grosses sur le copper. Idem : t'ose plus en parler
- t'en as sorti sur les 680x0. Et quand je t'ai corrigé, t'as jamais osé admettre que tu avais tort.

Et même si on parle de ta machine :
- t'as laissé croire que tu avais une palette de 256 couleurs alors que tu savais que ce n'était pas le cas
- Moi,un amigaiste, j'ai été obligé de t'expliquer comment fonctionnaient les couleurs sur la machine que tu as depuis près de 25 ans.
- tu as expliqué le plus naturellement du monde qu'on pouvait obtenir 20-25 mips avec une mémoire de 8Mhz (va dire rien que ça dans un forum de codeurs qu'on rigole). Alors que la RAM n'atteint cette vitesse qu'en mode séquentiel au sein d'une même page et qu'une partie de cette bande passante est consommée par les autres circuits.
- tu as expliqué que tu pouvais faire du placage de texture en lisant les pixels à appliquer 4 par 4 alors que AUCUNE MACHINE AU MONDE N'EN EST CAPABLE ! Ni l'archi, ni le mig, ni même les derniers cartes 3d nvidia ou ati...

J'arrete là : je pourrai en sortir des pages des conneries que tu as pu sortir...

Quand j'ai l'intention d'optimiser une routine je me penche dessus et bizarrement, j'y arrive sans aide.

Si, tu as eu besoin d'aide : il t'a fallu des années et plusieurs Mo pour déplacer 3 sprites...
Et il a fallu que quelqu'un d'autre que toi ponde un player de mod plus rapide pour que tu puisses récupérer quelques % de cpu : t'es pas capable d'en faire un tout seul on dirait...
Franchement, tes optimisations feraient rire tous les vrais codeurs qui oeuvrent sur ta machine. Et si t'es si fort, pourquoi est-ce que tu n'as pas été capable de proposer quelque chose sur le layer de fond de Scorpius ?

Réponse : parce que tu en es incapable...

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.

Tu peux citer le post ou j'ai dit ça ? Alors ferme là. Je peux te dire que le mig a des défauts (je t'en cite un que l'archimedes n'a pas : le mig ne dispose pas de mode chunky et sur l'AGA, c'est une grosse erreur). Le plus drole : t'as expliqué que l'AGA, à l'inverse de l'ECS, tenait la route. Ce qui est, une fois de plus débile : tous les connaisseurs considèrent les premiers Amiga comme des machines révolutionnaires à leur sortie alors que l'AGA a déçu la plupart des amateurs de cette machine. Même quand tu dis du bien du mig, tu es à coté de la plaque...

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.

T'as pas dit 'idéales' mais tu as dit 'parfaitement conçue' : c'est encore pire. Alors qu'en fait, ta machine c'est de l'esbrouffe : 256 couleurs qui sont une arnaque, cpu capable d'accéder à la RAM à chaque cycle et aucune RAM dédiée au cpu pour ne pas être ralenti par les autres accès DMA, cpu très bien conçu et peu cher à produire mais dans une machine qui coutait une fortune, 8 canaux sonores qui, au final, reproduisent des mods moins bien que le mig et en utilisant bien plus de cpu, os multitache mais coopératif, 4 mips affichés dans les pubs mais qui ne sont atteints qu'avec un dma allégé (petite résolution, peu de couleurs et pas de son...) et qui ne peuvent pas se comparer avec 4 mips CISC, etc...

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.

Les indices de quoi ? t'as pas compris que tes optimisations n'en sont pas ? Et si le retour que je t'ai fait était si loin de la vérité, pourquoi as-tu cru que j'avais désassemblé ton code ?

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.
...
Si en plus vous prenez les commentaires Youtube de trolls pro Amiga pour argent comptant, c'est le pompon.

Tout le monde a vu que quand tu essaies de me moucher je te réponds sans problème et que quand je te mouche sur un sujet, tu ne l'abordes plus...
Et je n'ai pas dit que Scorpius ne tournait pas en 50 i/s, j'ai dit qu'un AMATEUR D'ARCHIMEDES te l'avait fait remarqué : t'es tellement obsédé que tu l'accuses d'être un pro-amiga...
Et je n'ai pas dit que Scorpius n'était pas en 256 couleurs. J'ai dit au contraire que, malgré le fait qu'il soit en 256 couleurs, il parait moins coloré que les jeux sur le mig : on voit l'effet de ton mode 256 couleurs qui est vraiment une merde...

Tu ne sais pas lire ou tu ne comprends rien.(je retiendrai cette dernière possibilité, car c'est une constante depuis le début de nos échanges : t'es une burne en logique et en programmation).
- Il y a une méthode qui donne un scroll hardware horizontal de 1 octet => on se sert de celle là pour les modes 256 couleurs (1 octet définit 1 pixel)
- Il y a une autre méthode qui elle fonctionne pour tous les modes graphiques où l'on obtient un scroll hardware horizontal de 2 pixels. (quel que soit le mode graphique, je le répète).

T'es vraiment juste bon qu'à épauler Stapha pour déblatérer n'importe quoi sur ce forum.
C'est extraordinaire d'avoir face à moi, qui connais cette machine et la programme encore aujourd'hui, des imbéciles prétentieux qui me contredisent, sans rien n'y connaître, sans n'avoir jamais touché une bille en programmation ARM dessus.

Oui c'est sur que je n'y connais rien : tout le monde l'a vu ici...
Et même si j'ai jamais programmé sur ARM, n'ai-je pas sortie tout un tas de choses sur ta machine que tu n'as pas été en mesure de contredire ? L'inverse ne s'est jamais produit bizarrement...
Et demande à Babsimov : mon optimisation utilise des tas de choses spécifiques à l'ARM. Et tu es incapable de la trouver alors que des vrais codeurs sur Archie (ceux que tu insultes sans arret...) trouveront sans doute bien mieux que ce que j'ai proposé.

Et si tu étais au 10ième du niveau que tu crois être, tu aurais répondu à Touko qu'avec des affichage en bitmap, un scroll hardware sur 2 pixel suffit à faire un scrolling sur 1 pixel (Touko a l'habitude de travailler avec des tiles).

Evidemment tu ne sais pas comment (sinon tu te serais dépeché de le rétorquer)... C'est toi le pauvre type.

Allez cadeau : tu utilises un double buffer ou les 2 fonds sont décalés de 1 pixels. ça t'obligera à gérer des décalages de tiles d'un pixel mais vu le nombre de tiles à appliquer à chaque frame, ça passera sans problème. Surtout en mode 256 couleurs et en utilisant les tiles dédoublés : même pas besoin de faire ces décalages, quelques accès en 8 bits pour l'un des 2 écrans et le tour est joué.

Et comme, à priori, ta machine ne dispose pas de modulos entre les lignes (sinon j'espère que tu saurais ce que c'est) tu ne pourrais pas préparer les tiles en avance autrement que dans un buffer séparé et copier 1 colonne de 2 pixels à chaque fois (en fait 2 mais tu ne dois pas comprendre tout ce que je dis : je détaille donc pas). Ce qui fait que le décalage n'aurait aucun surcout en taille ou en temps cpu (tu comprendras peut-être le jour ou tu découvriras pourquoi un scroll horizontal est plus couteux qu'un vertical sur ta machine).

Et après ? Facile : le fait de passer de l'écran "normal" à celui "décalé" te fera scroller d'un pixel. Donc avant de revenir sur le premier, il faudra bien lui appliquer un scroll hardware de 2 pixels. Et ainsi de suite...

Tu as sorti des tonnes de posts sur le net entier ou tu parles des scrolls sans jamais parler de cette méthode (qui est du B.A.BA de coding pourtant...) : ça montre que tu ne vaut vraiment pas grand chose...

Encore une fois, un Amigaiste t'a appris quelque chose sur TA machine...

ça montre bien ton problème : tu es tellement imbu de toi que tu penses avoir atteint le nirvana du coding. Du coup, ça fait 20 ans que tu ne progresses plus...

Je te ferai un scroll horizontal pixel par pixel sur Archie, et toi et ton comique et incompétent comparse Stapha (avec ses propos débiles sur les modulos, et tous les autres propos apparmment techniques et bien argumentés, qui ne sont que des sophismes trolliens amigagaens) vous pourrez aller ravaler votre suffisance basée sur le néant neuronal.

oui bien argumentés. tellement que tu n'as jamais été en mesure de les contredire... La vérité est que tu ignorais l'existence des modulos. Tout comme, au bout de 20 ans, tu penses qu'il faut 3 buffer pour faire un scrolling...
Si ton scroll vertical est du niveau de celui de ta démo, inutile de perdre du temps. Quand tu auras fait un scroll sur plusieurs layers avec du parallaxe, des sprites et des detection de collision, là on pourra parler. Parce que le mig fait tout ça et même plus dans des jeux.

Pour info, et malheureusement je vais devoir l'écrire en gros car ça n'est jamais bien rentré dans vos crânes : SI J'UTILISE UN SCROLL HARD VERTICAL C'EST PARCEQUE JE VEUX PRODUIRE UN SWIV OU BATTLE SQUADRON A LA MESURE DE L'ARCHIMEDES.
C'est bon, là ? Capito ?

Euh... Battle squadron utilises un scroll vertical ET un scroll horizontal en même temps...
T'as critiqué la version Archimedes de SWIV en la traitant de "grosse mouise" (encore une insulte envers les codeurs...) alors qu'un jeu de ce type en 16 couleurs est bien plus difficile à faire que ta démo en 256...
Le pire, c'est que SWIV sur ta machine est pas mal du tout : ok il n'a que 16 couleurs mais le jeu est fluide. On peut surement faire mieux (et je pense qu'on peut le faire avec "256" couleurs...) mais de là à le traiter de "mouise...
T'es vraiment qu'un crétin imbu de sa personne...

Si un jour je veux faire un remake de Scorpius ou Nevryon, j'utiliserai une routine de scroll hard horizontal... oô^^oôô^^oo^ce sera terriblement compliqué, j'en rirais presque aux larmes si votre connerie et votre incompétence cumulées à tous 2 n'étaient pas si grave

Si un jour tu essaies je ne rirais même pas : j'aurai juste pitié de toi. Comme quand tu expliques "étudier la question du changement de pointeur vidéo pour faire du remplissage partiel"...

Juste une précision : Scorpius utilise 2 layers. Comment tu t'en sors avec ton scroll hardware ? Le seul moyen serait d'utiliser le scroll hardware sur celui du fond et de unplotter et replotter celui de devant. Ce qui serait plus couteux que de dessiner les 2 en entier...

T'es même pas capable de te rendre compte, encore une fois, de l'énormité que tu viens de dire. Allez montre nous : va expliquer ça (et les autres énormités de tes innombrables posts) sur un forum de dev sur archimedes et donne nous le lien qu'on rigole...

Tu veux pas ? C'est vrai que tu préfères rester ici et sur YouTube : c'est moins risqué...

Je t'explique : Scorpius redessine tout l'ecran à chaque fois. Et c'est pour ça qu'il utilise un pattern répété 10 fois pour le fond et qu'il restreint celui de devant à la moitié de l'écran : au final, ça représente moins de données à copier à chaque frame qu'un seul écran complet (pour info : le blitter du mig peut transférer le contenu de 2 écrans complet en 1 seule frame tout en y appliquant certaines opérations...). Et comme ça dispense d'unplotter les sprites, ça lui permet de récupérer du cpu ailleurs. Et ça rend l'utilisation des tracés de lignes pour les tirs très interressante (aucune données à copier).

Je t'ai d'ailleurs déjà expliqué que tu pouvais pas t'en sortir avec ton registre scroll hardware s'il y a 2 layers. Mais tu vas encore mettre 20 ans à comprendre.

Tu critiques mes affirmations mais tu ne les comprends même pas : ça fait plusieurs fois que tu refais les mêmes erreurs...

Encore une fois je ne critiques pas Scorpius qui est très bien fait. Je dis juste que si les codeurs (et ceux là, tu les a qualifié de "bons" dans ta grande mansuétude...) avaient consenti ces sacrifices, c'est que la machine les y obligeait...

[ArchieForEver]

@babsimov, et je ne perdrai plus mon temps à te répondre désormais.

Tu écris :
'Par ailleurs le 256x256 ou 320x256 ça fait pas
une grosse différence, c'est de la basse résolution, donc pixelisé.
C'était le standard du jeu de l'époque. Et en plus, personnellement je
trouve pas ça "immonde" comme tu dis. Sans vouloir te vexer, ta démo est
graphiquement bien moins jolie pour rester correct.
Mais, tout le monde n'a pas non plus un don pour le graphisme, même toi :)
'
si pour toi 256x256 c'est grosso modo comme du 320x256, que veux-tu que je te dise ? Si tout est dans tout, et tout se vaut ...
En plus une fois de plus tu lis en travers ce que j'ai écrit (comme pour la V-RAM, que pour le RISC PC) puisque ma démo tourne en 384x240.
Et j'ai bien précisé une différence de 40% entre le nombre de pixels de la démo du Toukon et la mienne.
Alors si pour toi 40% de différence c'est kiff kiff, tu sors du nombre de mes interlocuteurs possibles.
Et pour Battle Squadron et son scroll horizontal TRES limité, c'est bien évidemment prévu.
PS : Pour la beauté des rendus des démos, c'est sûr je filme une télé avec une webcam, mais bon, là encore, ré expliquer l'intérêt d'une preview de démo uniquement technique, j'abandonne.

[ArchieForEver]

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.

Et qu'est-ce qui te permet de l'affirmer ? Ta connaissance du mig ? Chaque fois que tu as abordé un point technique sur le mig, tu t'es lamentablement planté, tout le monde l'a vu...

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.

Ne parle pas de ce que tu ne connais pas : l'explication que tu as donnée pour les frames multiples n'est pas bonne du tout. Et si ça marchait comme tu le dis, faudrait que tu expliques comment faire pour supprimer des bobs qui peuvent se trouver devant et/ou derrière des bobs à conserver. Tu devrais essayer d'appliquer ta méthode sur ta machine qu'on rigole...
Ah tu n'y avais pas pensé ? Ou, pire, tu ne comprends pas ? ça m'étonne pas de toi : tu ne vois que la surface des choses. D'ailleurs t'es tellement nul que tu passes ton temps à te gargariser d'être un codeur, voire un developpeur. Mais tu fais ça sur un site de jeu : pourquoi ne pas allez dans des forums de dev ? Peur d'affronter la réalité ?
Developpeur de quoi d'ailleurs ? d'une pauvre démo avec un sinus scroll raté ? (alors que les VRAIS codeurs savent tous que c'est beaucoup plus facile à faire avec un affichage chunky...)

Je ne discuterai pas avec un type de mauvaise foi qui mélange vérités et contre vérités.

Oui c'est ça. Dis plutot avec un type qui te mouche à chaque fois.
Besoin de quelques piqures de rappel ? Ok :
- t'as sorti des énormités sur le blitter. Quand je t'ai détaillé ses capacités, t'as plus osé abordé le sujet.
- t'en as sorti des aussi grosses sur le copper. Idem : t'ose plus en parler
- t'en as sorti sur les 680x0. Et quand je t'ai corrigé, t'as jamais osé admettre que tu avais tort.

Et même si on parle de ta machine :
- t'as laissé croire que tu avais une palette de 256 couleurs alors que tu savais que ce n'était pas le cas
- Moi,un amigaiste, j'ai été obligé de t'expliquer comment fonctionnaient les couleurs sur la machine que tu as depuis près de 25 ans.
- tu as expliqué le plus naturellement du monde qu'on pouvait obtenir 20-25 mips avec une mémoire de 8Mhz (va dire rien que ça dans un forum de codeurs qu'on rigole). Alors que la RAM n'atteint cette vitesse qu'en mode séquentiel au sein d'une même page et qu'une partie de cette bande passante est consommée par les autres circuits.
- tu as expliqué que tu pouvais faire du placage de texture en lisant les pixels à appliquer 4 par 4 alors que AUCUNE MACHINE AU MONDE N'EN EST CAPABLE ! Ni l'archi, ni le mig, ni même les derniers cartes 3d nvidia ou ati...

J'arrete là : je pourrai en sortir des pages des conneries que tu as pu sortir...

Quand j'ai l'intention d'optimiser une routine je me penche dessus et bizarrement, j'y arrive sans aide.

Si, tu as eu besoin d'aide : il t'a fallu des années et plusieurs Mo pour déplacer 3 sprites...
Et il a fallu que quelqu'un d'autre que toi ponde un player de mod plus rapide pour que tu puisses récupérer quelques % de cpu : t'es pas capable d'en faire un tout seul on dirait...
Franchement, tes optimisations feraient rire tous les vrais codeurs qui oeuvrent sur ta machine. Et si t'es si fort, pourquoi est-ce que tu n'as pas été capable de proposer quelque chose sur le layer de fond de Scorpius ?

Réponse : parce que tu en es incapable...

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.

Tu peux citer le post ou j'ai dit ça ? Alors ferme là. Je peux te dire que le mig a des défauts (je t'en cite un que l'archimedes n'a pas : le mig ne dispose pas de mode chunky et sur l'AGA, c'est une grosse erreur). Le plus drole : t'as expliqué que l'AGA, à l'inverse de l'ECS, tenait la route. Ce qui est, une fois de plus débile : tous les connaisseurs considèrent les premiers Amiga comme des machines révolutionnaires à leur sortie alors que l'AGA a déçu la plupart des amateurs de cette machine. Même quand tu dis du bien du mig, tu es à coté de la plaque...

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.

T'as pas dit 'idéales' mais tu as dit 'parfaitement conçue' : c'est encore pire. Alors qu'en fait, ta machine c'est de l'esbrouffe : 256 couleurs qui sont une arnaque, cpu capable d'accéder à la RAM à chaque cycle et aucune RAM dédiée au cpu pour ne pas être ralenti par les autres accès DMA, cpu très bien conçu et peu cher à produire mais dans une machine qui coutait une fortune, 8 canaux sonores qui, au final, reproduisent des mods moins bien que le mig et en utilisant bien plus de cpu, os multitache mais coopératif, 4 mips affichés dans les pubs mais qui ne sont atteints qu'avec un dma allégé (petite résolution, peu de couleurs et pas de son...) et qui ne peuvent pas se comparer avec 4 mips CISC, etc...

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.

Les indices de quoi ? t'as pas compris que tes optimisations n'en sont pas ? Et si le retour que je t'ai fait était si loin de la vérité, pourquoi as-tu cru que j'avais désassemblé ton code ?

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.
...
Si en plus vous prenez les commentaires Youtube de trolls pro Amiga pour argent comptant, c'est le pompon.

Tout le monde a vu que quand tu essaies de me moucher je te réponds sans problème et que quand je te mouche sur un sujet, tu ne l'abordes plus...
Et je n'ai pas dit que Scorpius ne tournait pas en 50 i/s, j'ai dit qu'un AMATEUR D'ARCHIMEDES te l'avait fait remarqué : t'es tellement obsédé que tu l'accuses d'être un pro-amiga...
Et je n'ai pas dit que Scorpius n'était pas en 256 couleurs. J'ai dit au contraire que, malgré le fait qu'il soit en 256 couleurs, il parait moins coloré que les jeux sur le mig : on voit l'effet de ton mode 256 couleurs qui est vraiment une merde...

Tu ne sais pas lire ou tu ne comprends rien.(je retiendrai cette dernière possibilité, car c'est une constante depuis le début de nos échanges : t'es une burne en logique et en programmation).
- Il y a une méthode qui donne un scroll hardware horizontal de 1 octet => on se sert de celle là pour les modes 256 couleurs (1 octet définit 1 pixel)
- Il y a une autre méthode qui elle fonctionne pour tous les modes graphiques où l'on obtient un scroll hardware horizontal de 2 pixels. (quel que soit le mode graphique, je le répète).

T'es vraiment juste bon qu'à épauler Stapha pour déblatérer n'importe quoi sur ce forum.
C'est extraordinaire d'avoir face à moi, qui connais cette machine et la programme encore aujourd'hui, des imbéciles prétentieux qui me contredisent, sans rien n'y connaître, sans n'avoir jamais touché une bille en programmation ARM dessus.

Oui c'est sur que je n'y connais rien : tout le monde l'a vu ici...
Et même si j'ai jamais programmé sur ARM, n'ai-je pas sortie tout un tas de choses sur ta machine que tu n'as pas été en mesure de contredire ? L'inverse ne s'est jamais produit bizarrement...
Et demande à Babsimov : mon optimisation utilise des tas de choses spécifiques à l'ARM. Et tu es incapable de la trouver alors que des vrais codeurs sur Archie (ceux que tu insultes sans arret...) trouveront sans doute bien mieux que ce que j'ai proposé.

Et si tu étais au 10ième du niveau que tu crois être, tu aurais répondu à Touko qu'avec des affichage en bitmap, un scroll hardware sur 2 pixel suffit à faire un scrolling sur 1 pixel (Touko a l'habitude de travailler avec des tiles).

Evidemment tu ne sais pas comment (sinon tu te serais dépeché de le rétorquer)... C'est toi le pauvre type.

Allez cadeau : tu utilises un double buffer ou les 2 fonds sont décalés de 1 pixels. ça t'obligera à gérer des décalages de tiles d'un pixel mais vu le nombre de tiles à appliquer à chaque frame, ça passera sans problème. Surtout en mode 256 couleurs et en utilisant les tiles dédoublés : même pas besoin de faire ces décalages, quelques accès en 8 bits pour l'un des 2 écrans et le tour est joué.

Et comme, à priori, ta machine ne dispose pas de modulos entre les lignes (sinon j'espère que tu saurais ce que c'est) tu ne pourrais pas préparer les tiles en avance autrement que dans un buffer séparé et copier 1 colonne de 2 pixels à chaque fois (en fait 2 mais tu ne dois pas comprendre tout ce que je dis : je détaille donc pas). Ce qui fait que le décalage n'aurait aucun surcout en taille ou en temps cpu (tu comprendras peut-être le jour ou tu découvriras pourquoi un scroll horizontal est plus couteux qu'un vertical sur ta machine).

Et après ? Facile : le fait de passer de l'écran "normal" à celui "décalé" te fera scroller d'un pixel. Donc avant de revenir sur le premier, il faudra bien lui appliquer un scroll hardware de 2 pixels. Et ainsi de suite...

Tu as sorti des tonnes de posts sur le net entier ou tu parles des scrolls sans jamais parler de cette méthode (qui est du B.A.BA de coding pourtant...) : ça montre que tu ne vaut vraiment pas grand chose...

Encore une fois, un Amigaiste t'a appris quelque chose sur TA machine...

ça montre bien ton problème : tu es tellement imbu de toi que tu penses avoir atteint le nirvana du coding. Du coup, ça fait 20 ans que tu ne progresses plus...

Je te ferai un scroll horizontal pixel par pixel sur Archie, et toi et ton comique et incompétent comparse Stapha (avec ses propos débiles sur les modulos, et tous les autres propos apparmment techniques et bien argumentés, qui ne sont que des sophismes trolliens amigagaens) vous pourrez aller ravaler votre suffisance basée sur le néant neuronal.

oui bien argumentés. tellement que tu n'as jamais été en mesure de les contredire... La vérité est que tu ignorais l'existence des modulos. Tout comme, au bout de 20 ans, tu penses qu'il faut 3 buffer pour faire un scrolling...
Si ton scroll vertical est du niveau de celui de ta démo, inutile de perdre du temps. Quand tu auras fait un scroll sur plusieurs layers avec du parallaxe, des sprites et des detection de collision, là on pourra parler. Parce que le mig fait tout ça et même plus dans des jeux.

Pour info, et malheureusement je vais devoir l'écrire en gros car ça n'est jamais bien rentré dans vos crânes : SI J'UTILISE UN SCROLL HARD VERTICAL C'EST PARCEQUE JE VEUX PRODUIRE UN SWIV OU BATTLE SQUADRON A LA MESURE DE L'ARCHIMEDES.
C'est bon, là ? Capito ?

Euh... Battle squadron utilises un scroll vertical ET un scroll horizontal en même temps...
T'as critiqué la version Archimedes de SWIV en la traitant de "grosse mouise" (encore une insulte envers les codeurs...) alors qu'un jeu de ce type en 16 couleurs est bien plus difficile à faire que ta démo en 256...
Le pire, c'est que SWIV sur ta machine est pas mal du tout : ok il n'a que 16 couleurs mais le jeu est fluide. On peut surement faire mieux (et je pense qu'on peut le faire avec "256" couleurs...) mais de là à le traiter de "mouise...
T'es vraiment qu'un crétin imbu de sa personne...

Si un jour je veux faire un remake de Scorpius ou Nevryon, j'utiliserai une routine de scroll hard horizontal... oô^^oôô^^oo^ce sera terriblement compliqué, j'en rirais presque aux larmes si votre connerie et votre incompétence cumulées à tous 2 n'étaient pas si grave

Si un jour tu essaies je ne rirais même pas : j'aurai juste pitié de toi. Comme quand tu expliques "étudier la question du changement de pointeur vidéo pour faire du remplissage partiel"...

Juste une précision : Scorpius utilise 2 layers. Comment tu t'en sors avec ton scroll hardware ? Le seul moyen serait d'utiliser le scroll hardware sur celui du fond et de unplotter et replotter celui de devant. Ce qui serait plus couteux que de dessiner les 2 en entier...

T'es même pas capable de te rendre compte, encore une fois, de l'énormité que tu viens de dire. Allez montre nous : va expliquer ça (et les autres énormités de tes innombrables posts) sur un forum de dev sur archimedes et donne nous le lien qu'on rigole...

Tu veux pas ? C'est vrai que tu préfères rester ici et sur YouTube : c'est moins risqué...

Je t'explique : Scorpius redessine tout l'ecran à chaque fois. Et c'est pour ça qu'il utilise un pattern répété 10 fois pour le fond et qu'il restreint celui de devant à la moitié de l'écran : au final, ça représente moins de données à copier à chaque frame qu'un seul écran complet (pour info : le blitter du mig peut transférer le contenu de 2 écrans complet en 1 seule frame tout en y appliquant certaines opérations...). Et comme ça dispense d'unplotter les sprites, ça lui permet de récupérer du cpu ailleurs. Et ça rend l'utilisation des tracés de lignes pour les tirs très interressante (aucune données à copier).

Je t'ai d'ailleurs déjà expliqué que tu pouvais pas t'en sortir avec ton registre scroll hardware s'il y a 2 layers. Mais tu vas encore mettre 20 ans à comprendre.

Tu critiques mes affirmations mais tu ne les comprends même pas : ça fait plusieurs fois que tu refais les mêmes erreurs...

Encore une fois je ne critiques pas Scorpius qui est très bien fait. Je dis juste que si les codeurs (et ceux là, tu les a qualifié de "bons" dans ta grande mansuétude...) avaient consenti ces sacrifices, c'est que la machine les y obligeait...

Je viens d'en lire assez en diagonale pour te répondre que tu n'es vraiment pas malin car les problèmes que tu cites n'en sont pas.
Je t'ai déjà répondu que tes pseudos idées d'optimisations d'affichage sur Archie sont de la mouise en barre, et je te le reconfirme.
Oui SWIV est bien un pauvre jeu par rapport à ce qu'il est possible de faire sur Archie.
Tu vois, Scorpius c'est le minimum syndical pour une machine comme l'Archie, et c'est bien ce que vous n'arriverez jamais à comprendre, avec votre biais de lecture Amiga.
Et non : crois bien que je ne te donnerai ABSOLUMENT AUCUNE explication pour faire quoi que ce soit sur Archie.
Monte une équipe de recherche avec Touko pour faire le tour d'Internet.
Te voir t'embourber dans tes constats de problèmes et les lamentables solutions que tu fournis me fait trop rire.

A un moment faut vraiment réfléchir et agir, et ne jamais se polluer l'esprit avec les solutions des autres.
Je suis toujours parti d'une feuille vierge.

Si tu ne vois même pas la solution pour l'histoire des N mémoires de trame, c'est sûr, t'as un sacré boulot de rattrapage devant toi.
Sans rire, c'est navrant.

[MikeeMike_2008]

bon tu nous la montre ta seconde preview-demo... (ce sera quand la bonne !!!)

pour l'instant tous ce que tu dis impossible sur le mig l'est en fait donc tu ne connais rien a rien au mig et même st

la seule chose que je constate c'est que toutes les démos comme les jeux de l'archimèdes sont a l'ouest total par rapport aux équivalences (de 88/89 max 90) du mig et du st après ce n'est même plus la peine de comparer car l'archimèdes se prend un trempe

sauf la 3D mais bon c'est faisable sur le mig et st aussi mais beaucoup moins fluide c'est tout mais c'est faisable donc tous ce que tu peux montrer sur l'archi a déjà été fait sur st et amiga et rien aucun effets n'est en aucun cas infaisable sur le mig tandisque l'inverse ..... pauvre archimèdes !!!!!

[Lesarthois]

Oui.
C'est navrant de voir une telle idiotie.

Tu te prétends codeur, mais tu ne veut rien révéler de tes astuces?
GENIAL!!
Si tous les Archimédistes sont comme toi, pas étonnant que cette casserole ne soit pas connue, vu que les "secrets" de programmations sont gardés jalousement.

Heureusement je pense que tu es seul dans ton coin, petit trou du cul tellement persuadé d'être un génie incompris que tu t'arroges le droit non seulement de mépriser ceux qui te contredisent mais aussi ceux qui viennent pour démontrer que l'Archimedes était une bonne machine.

[philip_mortimer]

J e me marre bien devant la mauvaise foi d'ArchieForEver.

Même en ayant un niveau on ne peut plus basique en programmation, ça se voit comme le nez au milieu de la figure que tu as tort et que tu ne connais même pas la machine que tu vénères..
C'est dommage, car l'Archimedes est une machine méconnue et sûrement sous estimée.

[MacDeath]

rhola, arrétez de recopier/multiquoter des messages entiers eux même multi-quote.

Au final ça devient illisible.

rien ne vous empêche de citer seulement les parties interessantes et arguments clefs...
Pour le reste il nous suffit de faire défiler l'écran/le sujet quelques postes plus haut...

[stapha92]

Je viens d'en lire assez en diagonale pour te répondre que tu n'es vraiment pas malin car les problèmes que tu cites n'en sont pas.
Je t'ai déjà répondu que tes pseudos idées d'optimisations d'affichage sur Archie sont de la mouise en barre, et je te le reconfirme.
Oui SWIV est bien un pauvre jeu par rapport à ce qu'il est possible de faire sur Archie.
Tu vois, Scorpius c'est le minimum syndical pour une machine comme l'Archie, et c'est bien ce que vous n'arriverez jamais à comprendre, avec votre biais de lecture Amiga.
Et non : crois bien que je ne te donnerai ABSOLUMENT AUCUNE explication pour faire quoi que ce soit sur Archie.
Monte une équipe de recherche avec Touko pour faire le tour d'Internet.
Te voir t'embourber dans tes constats de problèmes et les lamentables solutions que tu fournis me fait trop rire.

A un moment faut vraiment réfléchir et agir, et ne jamais se polluer l'esprit avec les solutions des autres.
Je suis toujours parti d'une feuille vierge.

Si tu ne vois même pas la solution pour l'histoire des N mémoires de trame, c'est sûr, t'as un sacré boulot de rattrapage devant toi.
Sans rire, c'est navrant.

Alors... à quoi oses tu encore répondre... Ah ben il ne reste plus grand chose : pour quelqu'un qui alignait les post sans arret avant que je viennes le remettre en place.
Et ne fais pas croire que tu lis en diagonale : tu le prétends parce que tu es à court d'argument sur presque tout. Normal : même toi, malgré ton idiotie, tu finis par réaliser que ce que tu disais ne collait pas sur pleins de points que tu abordais...
Et puis ça te permet d'occulter le fait que je t'ai ENCORE appris quelque chose sur TA machine (le scrolling au pixel près avec un scroll hardware sur 2 pixels)

Ah ? Scorpius le minimum syndicale ? C'est pas le meilleur jeu de l'Archie ? Celui qui devait éclater l'Amiga ? tu te contredis tout seul maintenant ?

Quelles pseudos idées ? Tu es une grande gueule qui parle sans savoir : tu ne sais pas du tout ce que sont mes idées. Comment peux tu les juger ?

Je ne t'ai rien demandé, j'ai pas besoin de toi. Petit rappel : tu bosses depuis 20 ans sur des optimisations ((bourrées de pré-calc : lol !). J'ai cité ce que je pensais etre tes optimisations car je me rendais bien compte que ça n'allait pas très loin et tu m'as accusé d'avoir récupéré et désassemblé ton code...

Alors mes "lamentables solutions" semblent être celles que tu emploies : ta réaction de parano imbu l'a prouvée...

Et si tu ne veux donner aucune explication, c'est que t'en as aucune. point barre. t'avais même pas remarqué les limites de Scorpius Et maintenant que je te les ai énumérées ce dernier est passé de "tuerie infaisable sur le mig" à "minimum syndical".

Tu sors vraiment de sales excuses : une feuille vierge ? Et le player que t'as pas été capable d'optimiser et/ou de réécrire ? Il a fallu qu'un autre le fasse pour toi. Et tu ne sais même pas comment ça marche, sinon t'aurais pas donné des explications foireuses pour expliquer la qualité du son. Moi j'ai expliqué pourquoi le son était meilleur sur le mig, donc moi je sais très bien ce que doit faire un player sur ta machine contrairement à toi (et je l'ai expliqué au cas ou tu aurais raté ça aussi)...

Et tu devrais l'effacer ta feuille vierge et recommencer car quand on :
- croit qu'un scrolling a besoin de 3 buffers.
- ne connait pas l'utilité des modulos pour un scroll horizontal
- ne sait pas qu'un scroll hardware sur 2 pixels suffit à faire un scrolling au pixel près
- croit qu'on peut faire un scroll sur 2 layer avec 1 seul registre d'adresse
- etc...
Alors qu'on bosse sur les scrollings depuis plusieurs années, c'est qu'on est nul. Et vraiment nul...

Moi dans mes posts, j'argument, j'explique, je détaille. Toi tu fesais ça en disant n'importe quoi jusqu'à ce que je viennes te remettre en place. Maintenant tout ce que tu sais dire c'est que tu rigoles à me voir m'embourber et plein de blabla dans le genre...

Non seulement ça ne tient pas debout (m'accuser d'avoir désassemblé ton code de merde : j'en reviens toujours pas...) mais qui parle de faire un shoot qui va exploser tout ce qui se fait sur le mig depuis plusieurs années et en est à faire bouger 2 sprites avec 2 Mo de RAM ?

Qui est embourbé ?

[stapha92]

rhola, arrétez de recopier/multiquoter des messages entiers eux même multi-quote.

Au final ça devient illisible.

rien ne vous empêche de citer seulement les parties interessantes et arguments clefs...
Pourl er este il nous suffit de faire défiller l'écran/le sujet quelques postes plus haut...

Ah oui, ArchieForEver fait ça. Faut pas lui en vouloir : au bout de 246 messages (avec ce pseudo, bien plus avec tous les autres...) il n'a toujours pas compris comment fonctionnent les balises dans les messages. Du coup il est obligé de tout remettre ou de citer "à la main".

Mais à part ça c'est un génie de la programation : on voit l'esprit d'analyse et de déduction ainsi que les facultés d'abstraction...

T'inquiètes pas, les balises c'est plus facile qu'un scrolling : d'ici 2/3 ans il devrait y arriver...

[Invité]

Moi ce que j adore chez archiottes,c est qu il certifie que le scroll est sur 2 pixels et pas sur 2 octets,mais en mode 256 couleurs,ça fait combien 2 pixels ???
Bah merde 2 octets,c est ballot ça
Et c est clair que quand il ne sait plus quoi dire,il feint de passer à autre chose.

Pour scorpius,il suffit de le comparer à disposable hero,pour vite voir ses limites,et sa seule force.

Eh stapha t as pas honte de désassembler son code ???

[babsimov]

@babsimov, et je ne perdrai plus mon temps à te répondre désormais.

Libre à toi bien sur. En ce qui me concerne je continuerai à te lire et à attendre de voir ton jeu en action.

si pour toi 256x256 c'est grosso modo comme du 320x256, que veux-tu que je te dise ? Si tout est dans tout, et tout se vaut ...
Et j'ai bien précisé une différence de 40% entre le nombre de pixels de la démo du Toukon et la mienne. Ma démo tourne en 384x240.
Alors si pour toi 40% de différence c'est kiff kiff, tu sors du nombre de mes interlocuteurs possibles.

Tu vas quand même pas me dire que 384x240 c'est de la haute résolution non ? Mais comme tu répondras pas. En plus Touko t'as déjà répondu que la PC engine pouvait afficher 512x240 et que même à cette résolution la démo serait aussi fluide.
En plus, il t'a dit qu'il allait adapter sa démo en 512x256. J'ai tendance à le croire, je sais pas pourquoi ?
J'ai l'impression que tu chipotes pour une broutille. T'aurait dit que ta démo était en 640x512, là c'était pas pareil.
Au niveau des interlocuteurs, j'ai l'impression que ta liste ici se rapproche de zéro, puisque dès qu'on te contredit ou qu'on émet un doute ou une remarque, on est forcément un "ennemi" à abattre. Dommage.

En plus une fois de plus tu lis en travers ce que j'ai écrit (comme pour la V-RAM, que pour le RISC PC)

J'ai fait un mea culpa pour ça, tu n'as pas du le lire. En plus, c'est Stapha qui a le premier indiqué que tu avais précisé ce point et donc que j'avais mal lu.
Excuse moi de ne pas être parfait, contrairement à toi :)

Et pour Battle Squadron et son scroll horizontal TRES limité, c'est bien évidemment prévu.

Tu as raison que le scrolling horizontal est limité, mais il est là en même temps que le vertical. Mais, je vois que tu as mis ça dans ton jeu, reste plus que trois semaines pour voir ça. Comme je l'ai dit, si tu nous fait un truc du niveau de Battle Squadron, alors, mes respects.

Tu vois, Scorpius c'est le minimum syndical pour une machine comme
l'Archie, et c'est bien ce que vous n'arriverez jamais à comprendre,
avec votre biais de lecture Amiga.

Faudrait savoir, un jour Scorpius c'est le top de ce qu'on fait sur Archimèdes et le lendemain c'est le minimum syndical. Du simple au double de la part de quelqu'un qui me reproche "Si tout est dans tout, et tout se vaut ..." c'est gonflé !

Puisque je ne suis plus un interlocuteur "valable", j'imagine aussi que tu ne demanderas pas à voir les suggestions d'optimisation que Stapha m'a envoyé par mail, comme il l'a indiqué ici et comme il te propose de le faire.
A propos, de notre divergence de vue concernant le "gouffre" de résolution entre ta démo et celle de Touko ne serait elle pas un "prétexte" ? La réelle raison de ma "disqualification" comme interlocuteur "valable" n'aurait pas plus à voir avec le fait que je sois cité comme témoin par Stapha ?
Quoi qu'il en soit, il ne tient qu'à toi de démontrer que tous ici nous avons tord en terminant ton jeu et surtout en le montrant ici dans toute sa gloire.
C'est tout ce que je te souhaite.

PS : MacDeath, j'espère ne pas avoir fait trop de quotes. Il semble bien que je n'aurais plus l'occasion de le faire avec ArchieForEver :)

[Invité]

Babsimov tu es trop gentil,tu es reste plus que courtois dans vos échanges malgré son mépris,chapeau !!

Et puisque je suis un bouffon en prog, j attends sa réponse sur l effet de feu, en code bien sur

[MacDeath]

Dans un future lointain, les Neo-humains (cyborgs dès la naissance) exhumeront ce thread parmis les archéo-couches de la protomatrice et s'étonneront de notre barbarie, nous qui nous entretuions pour un concept religieux et philosophique majeur appelé Scrolling.

[Invité]

Lol macdeath

Je viens de lire l astuce de stapha pour le scroll horizontal sur la machine d archie, effectivement c est pas con :thumright:

Son décalage de tiles,il peut même le faire en 32 bit,en gérant facilement le débordement avec la retenue .
Bien sur il. Faut un minimum savoir coder ...

[babsimov]

Dans un future lointain, les Neo-humains (cyborgs dès la naissance) exhumeront ce thread parmis les archéo-couches de la protomatrice et s'étonneront de notre barbarie, nous qui nous entretuions pour un concept religieux et philosophique majeur appelé Scrolling.

Bravo, MacDeath.

[Snafu]

Ha ..il est revenu le codeur infaillible à la bouche aussi grande que celle de Grace Jones de la pub pour la Citroën CX. (Fallait bien trouver un élément de comparaison à la hauteur...des chaussettes du personnage). Je commençais à ne plus rire. Chose réparée.

[babsimov]

Babsimov tu es trop gentil,tu es reste plus que courtois dans vos échanges malgré son mépris,chapeau !!

N'étant pas programmeur, je lui laisse le bénéfice du doute malgré tout. On verra au résultat s'il le méritait ou non.

[MacDeath]

Car oui le grand schisme religieux a eut lieux en cette époque lointaine, obscure et oubliée... entre les fidèles du Hard et les Adeptes du Soft.

Cela eut lieux avant que la secte de la grande accélératrix 3D n'envahisse le monde, profitant de la haine sans limite que se vouaient les religions de la première époque... dite l'âge du pré-CMS, avant même l’avènement du Gigahertz... aussi appelé l'an Zéro-point-Un.

Une époque barbare où le langage ancien ASCII était encore pratiqué, obligeant les Archéo-Emulateurs à bien des études de tables de caratères retrouvées dans des mémoires mortes anciennes et de nombreuses routines d’analyses probabilistes.


(hey, ça pourrais faire un superbe roman ça, au moins une nouvelle...)


"Après si vous pouviez baisser d'un cran les noms d'oiseaux... vous faites honte à notre civilization auprès de nos descendants lointain..." dit un jour MacDeath le clairvoyant, grand visionnaire en 4-2-1bpp overscan rasterisé.

[babsimov]

Je suis d'accord, MacDeath, encore bravo et ça détend bien en plus. Merci.

[babsimov]

Je viens de lire l astuce de stapha pour le scroll horizontal sur la machine d archie, effectivement c est pas con :thumright:

"Mode émulation Archimèdes"
Ne dit pas ça malheureux, tu n'y connais rien en Archimèdes et t'a surement pas le niveau pour comprendre !
"Fin du mode émulation Archimèdes"

Faut bien rigoler un peu