Petite preview de Atomic 0.20

[mioux]

Tu oublis juste la profondeur d'un pixel dans ton calcul 

La profondeur d'un pixel??   Faut que tu m'explique là...

Ben 1 pixel sur C64, tu manipule 1 octet pour 16 couleurs sur 5 bits, alors que toi tu manipule des pixels sur 4 octets complets (RGBA)

Et je ne pense pas qiue le calcul en z soit compliqué : z=0

PS : Je voit que tu as fais ca pour utiliser les vieilles techniques oubliées mais en fait, tu dois perdre du temps, parce que le jeu d'instruction du C64 est complettement différent du jeu d'instructions d'un i686, surtout s'il a les primitives SSE et/ou MMX

En gros, le cycle de calcul pour faire la rotation est peut être plus long sur ton C64 que sur ton i686 (en terme de nombre cycles bien entendu ), de plus tu ne prends pas en compte le nombre de registre de chaque processeur (qui peut réduire considérablement le nombre de cycle (par exemple j'ai 2 registres sur le C64 et 256 sur un Athlon Thunderbird (purement théorique, je connais pas les valeurs exactes ), et on suppose 1 instruction pour une addition (ADD @r1 @r2 avec @rx un emplacement mémoire), faire 128 additions d'affilées prendroint donc pour les 2 processeurs le temps de 128 opérations... Seulement, sur le C64, il va faloir reremplir les registres à chaque opérations (soit 254 MOV @x @rx en supposant que les valeurs sont déjà en registre quand tu commence tes additions et que tu ne souhaite pas conserver le résultat (auquel cas, il faut rajouter 127 MOV @rx @x pour restocker les valeurs en mémoire), seulement ton athlon lui, n'aura pas besoin (au meilleur des cas) de faire ces 254 déplacements mémoire (à supposer que toutes les valeurs sont déja en registre ou alors il en fera 256 si il n'y en a aucune, mais ca c'est comme le C64) et pour conserver les valeurs, pas besoin de repasser immédiatement par la mémoire, vu que le résultat est stocké dans un registre qui ne sera pas utilisé...

En gros, pour faire 256 additions tu mettra au mieux le temps de 254 + 127 MOV et 128 ADD et au pire 256 + 127 MOV et 128 ADD
Pour l'athlon, en revanche, tu mettra au mieux 128 ADD, et au pire 256 MOV + 128 ADD. Sachant qu'après il te faut compter 1 cycle pour une addition et 3 cycles pour un déplacement de registre (ce sont des valeurs probables (bien que je ne connaisse pas les valeurs exactes)) il te faut donc entre 1271 et 1277 cycles sur le C64 et entre 128 et 896 cycles sur l'Athlon.

Sachant que la vitesse du processeur correspond au nombre de cycles par seconde, même en se basant uniquement sur le nombre de cycles, tu ne peux pas comparer un C64 à un I686 (sans compter que si tu prends en compte la mémoire cache, tu gagne en nombre de cycles pendant les opérations MOV et là je les ai pas prises en compte )

Et puis si tu demande au processeur graphique de faire les calculs au lieu de passer par le processeur central, tu jouis d'un jeu d'instruction spécialisé qui permet encore de réduire le nombre de cycles pour les calculs de position de pixels.

Et puis ton compilo ou l'interpretation de ton code (suivant si tu es sur un C64 ou sur un Athlon) peut optimiser ou au contraire pourrir les calculs en augmentant le nombre de cycles en utilisant un jeu d'instructions non adaptées (généralement ils sont bons optimisateurs... genre un "if (true)" est purement supprimé lors de la compilation vu qu'il est toujours vrai (ou un "if false { .... }" qui va retirer tout le bloc inutile))

Et puis je suppose que pour des rotations tu as des additions ou des divisions à faire... c'est très mauvais ca pour un processeur s'il n'a pas d'instructions spécifiques pour ces opérations... Une division c'est long à faire quand tu n'as que l'instruction ADD (mais c'est possible)

Bon j'arrete là, sinon demain j'y suis encore et j'ai un train à prendre à 13h moi

[youki]

  Mioux, ca se voit que tu n'a jamais codé de Demo sur c64.  Et encore moins fait de Rotozoom...

Quand a la profondeur de pixel tel que tu la presente, elle est prise en compte dans mon calcul.

Mon "stupide" calcul compare juste, grosso modo, le temps qu'il faut a un C64 et a un PC pour "blitter" une image complete full screen. 

L'image du PC que je considere est : 640x480x16bit par pixel , soit 2 bytes pas pixel.  (Atomic fonctionne en 16bit/pixel pas en 24 ni 32 , ce qui , contrairement a ce que certain peuvent croire , ne m'empeche pas de faire de l'aphablending (la aussi par soft!) ) , soit 80000000 qui represente la taille de la memoire video necessaire.

Sur C64, j'ai pris en compte la memoire video total soit 8000 bytes , quelque soit le nombre de bit par pixel. En plus, meme en mode graphique 16 couleurs le C64 n'utiliser pas 4 bits/pixel (encore moins 5!!!) , il en utiliser que 2 ! (oui, a cette epoque on etait plus econome!!  )

enfin de toute maniere, les programmeurs d'aujourd'hui ne savent plus programmer si il ont pas tout ce qui est fait a leur place derriere  et ont besoin des accelerations hardware pas possible.  La où il suffirait juste d'un peu d'optimization et de reflechir un peu.  Mais de nos jour, plus personne reflechis ou optimize....

Franchement , je pense que quand tu regarde le jeu 3d actuel qui necessite des machines a 3 ghz avec dual core... je pense que si on "optimisait" comme à l'epoque ,  ils tounera à l'identique sur des machines à 800mhz.

Mais bon...faut faire du fric..faut vendre des machines,  faut sortir le produit vite ...et tout et tout... ducoup.. ca arrange tout le monde , de ne plus se fatiguer!

#edit:

J'avais pas noté ca :

PS : Je voit que tu as fais ca pour utiliser les vieilles techniques oubliées 

Non, j'ai pas fait ca pour ca.  J'ai fait ca pour que Atomic fonctionne sur n'importe quel type de hardware avec le minimum de software installer.
Atomic , là, tu dois pouvoir le faire tourner sur une vielle carte Trident SVGA du debut des annees 90 , ca doit marcher.
Et il ne demande que DirectX 7.0  , qui est installer par defaut sous XP et 2k et millenium et qui fonctionne aussi sous win95 et 98.

[papinball]

Je suis le seul a n avoir rien compris  :stupidking:

[mioux]

Oui bon j'avoue, les 5 bits par pixels j'ai un peu craqué j'ai oublié de compter le 0

Et si les couleurs sont codées sur 2 bits, ca veut dire que tu as une palette de 4 couleurs parmis 16 (chose dont je n'ai pas tenu compte car je ne saviat pas comment étaient codées les couleurs sur ce type de machine)

N'empeche que tu comare quand même des choses qui ne le sont pas, vu que les cycles d'accès et de calcul ne sont pas les mêmes et que tu fais une comparaison en taille/Hz..., moi je te propose de faire une comparaison en nombre d'opérations élémentaires de ton processeur (c'est à dire, si on garde les même jeux d'instructions sur chaque processeur mais qu'on les mets à la même cadence, lequel mettra le moins de temps pour traiter son image ? C'est vrai tu as un avantage sur le C64, tu peux traiter 2x plus de pixels en même temps si tu te débrouille bien (4 d'un coup sur 8 bits contre 2 sur un processeur 32 bits) seulement le nombre de cycle pour faire tes calculs sur le C64 est à mon humble avis supérieur que pour le faire sur le processeur à 32 bits (toujours en terme de cycle processeur)...

Et puis les accélérations hardware sont là pour réduire d'autant le nombre de cycles pour faire un calcul dans un domaine donné... Tu n'utilise pas un tank pour creuser un trou dans le sol quand même...

Et puis la remarque sur les devs qui utilisent ce que d'autres ont fait, je suis plutot partisant du partageons nos capacités... Il vaut mieux avoir dans ton équipe un mec qui gére à 100% la transformée de Fourier et un qui gère à fondles effets sur les sons, que 2 mecs qui galèrent dans les 2 sujets.

Et puis aujourd'hui, on fais toujours des économies de mémoire... imagine toi travailler avec des textures décompressées sur un jeu dans le style de Assassin's Creed... c'est plus 9Go qu'il va faire le jeu... mais beaucoup plus (en plus avec les textures compressées on peut diminuer les temps de calcul des images). En revanche, en bureautique, c'est vrai qu'on ne se préoccupe plus des ressources dont on a besoin...

En tout cas, à mon avis tu fais une comparaison qui n'a pas lieu d'être.

Bon trève de polémique... il sort quand ce Atomic que je fasse un test sous linux

[youki]

Je suis le seul a n avoir rien compris  :stupidking:

Non, apparement Mioux , non plus!     Ah , ces petits jeunes... comprenne rien!

A moins que ce soit de famille! 

[youki]

Et si les couleurs sont codées sur 2 bits, ca veut dire que tu as une palette de 4 couleurs parmis 16

Non plus,... essaye encore! 

Et puis la remarque sur les devs qui utilisent ce que d'autres ont fait, je suis plutot partisant du partageons nos capacités... Il vaut mieux avoir dans ton équipe un mec qui gére à 100% la transformée de Fourier et un qui gère à fondles effets sur les sons, que 2 mecs qui galèrent dans les 2 sujets.

Resultat, tu empile couche sur couche ,  et parmis ces couches , tu te sert peut etre de 10% de possibilité de la couche en question.   Je suis tout a fait d'accord que ca peut faire gagner du temps (au developpeur) de pas reinventer la roue a chaque fois.  Mais au bout du compte au bout de quelque annee tu te retrouve avec un empillement de couche et plus personne maitrise plus rien , et plus personne ose toucher les couches inferieurs.  On se retrouve a des donnes d'interface et de verru pour adapter les couches toutefaite a tes vrai besoins.
Et au final, tu perd de la performance et du temps  et si tu vis de ca, de l'argent.  Et en plus ca devient tres vite in-maintenable.  La reutilisation oui, mais intelligement , le pb, c'est que dans le metier les decideurs ne le sont jamais vraiment en ce qui concerne le coté technique...

Enfin, tu comprendra de quoi je parle quand tu auras deja quelque annee d'experience... là tu es encore tout frais ...et tu crois encore les grand theorie  ce que l'on t'a dit à l'ecole!  ......  moi aussi, j'etais plein de certitude quand j'ai fini mes etudes et commencer a bosser... 16 ans apres...j'ai plus trop d'illusion.

[mioux]

Et si les couleurs sont codées sur 2 bits, ca veut dire que tu as une palette de 4 couleurs parmis 16

Non plus,... essaye encore! 

Ben je suis pas con quand même... sur 2 bits on code tous les chiffres de 0 à 3
00
01
10
11
ca fait bien 4 couleurs ?!? et y en a 16 dispos, donc 4 parmis 16 ?!?

[youki]

J'ai pas dit que 2 bit ne faisait pas 4 combinaison.

Je dis juste qu'il y a un mode du C64 qui affiche 16 couleurs et que chaque pixel est codé sur 2 bits.

oui... à l'epoque on était ingenieux...     

héhé... tu veux que je poste ca dans le topic des egnimes? 

[Disciple]

    eh eh ce topic devient passionnant !! 
.....ca me rapelle ma jeunesse tiens...

[Persecutor]

Ha nos amis les nerds...
C'est pour ca que l'on est oblige de vous installer des serveurs quadri dual core avec 64 gigas de memoire et une connexion au reseau gigabit 

et que malgrès tout on nous dit le serveur y rammmeeeeeuuuuuu 

He bien je dit 

:stupidking: :stupidking: :stupidking:

[youki]

C'est pour ca que l'on est oblige de vous installer des serveurs quadri dual core avec 64 gigas de memoire et une connexion au reseau gigabit 

Alors qu'un bon vieux commodore 64 ferait largement l' affaire!! 

Bon apparement, Mioux, cale sur l'egnime...  ah ces jeunes...   aucune imagination...    Ca pour les charades et les enigmes du type "quel etait la couleur du cheval blanc d'henri IV?"  ya du monde... mais des qu'il s'agit d'un petit probleme informatique tout betes ya plus personne! 

[mioux]

Je vois vraiment pas comment tu peux faire 16 couleurs avec 4 bits, à moins de le répéter 2x

[youki]

Je vois vraiment pas comment tu peux faire 16 couleurs avec 4 bits, à moins de le répéter 2x

heu..16 couleurs avec 4 bits , c'est facile...    le C64, lui c'est avec 2 bit qu'il fait ca! 



Alors je t'explique :

Le mode dont je parle est le mode dit "Multicolor" du commodore 64. qui est 160x200 en 16 couleurs.
La memoire video du C64 etant de 8000 bytes (un peu moins de 8k)  , ca donne 160x200x2bits .
donc 2 bit par pixel.

A l'époque (et jusqu'a qu'il n'y a pas si longtemps) les microordinateurs avait 2 mode separés :

un mode texte et un mode graphique.

pour me mode texte, le c64 avait une zone memoire où il stocké la couleur de chaque caractere : couleur fond et couleur avant plan. le C64 afficher 40x25 caractere , ce qui donne 1000 bytes  pour stocker les informations des couleurs (je rappelle 16couleur, donc 4 bits par couleur, ce qui veut dire que sur un byte tu peux stocker la couleur d'avant et d'arriere plan).

Sur le C64, il y avait aussi 2 bytes en memoire qui servait pour stocker la couleur du bord de l'ecran , et celle du fond , independant de la couleur des caracteres.

Quand le C64 etait en mode graphique haute resolution : 320x200  en 2 couleurs parmis 16. dans ce mode la c'etait 1 bit par pixel.  ... et tu vois malgres un seul bit par pixel, tu pouvais choisir tes 2 couleur parmis les 16.
En fait, si le bit etait à "1" , il allait chercher la couleur dans le registre de couleur d'avant plan, si il etait à 0 , il allait chercher la couleur dans le regisre d'arriere plan.

Quand le C64 etait en mode multicolor 160x200 en 16 couleur , avec 2 bit par pixel, il utilisait la meme methode sauf que la :

Si c'etait :   00  , il va chercher la couleur dans le registre d'arriere plan
                   01, , il va chercher la couleur dans le registre d'avant plan
                   10,   il va chercher dans la zone memoire du mode texte, la couleur d'arriere plan qu'aurait un caractere la où se trouve le pixel.
                   11,  il va chercher dans la zone memoire du mode texte, la couleur d'avant plan qu'aurait un caractere la où se trouve le pixel.

De cette maniere , tu pouvais afficher 16 couleurs à l'ecran. avec neanmoins une limitation, tu ne pouvais avoir que 4 couleurs differente par bloc de 8x8 pixels.

Grace a ce mecanisme, il te fallait seulement 8000+1000 + 2 = 9002 bytes pour afficher du 160x200x16 couleurs alors qu'en theorie il t'aurais fallu  160x200x4bits = 16000 Bytes.  => 6998 bytes de gagner! A l'epoque c'etait enorme!

Tu as peut etre connu les ordinateurs avec les couleurs qui "bavent" , tres typique notament des Thomson MO5 et TO7.  C'etait  dû a ce type de méthode.

Et voila, maintenant tu pourra frimer dans la salon parisien ou devant tes copines! 

[Turk182]

Je me sens completement inculte quand je lis des trucs comme ca....vous êtes vraiment des bêtes les gars !!!

[youki]

non..non..

Mioux est bete  ,  et moi je suis une bete!    Faut pas confondre!

...et voila comment on se fait bannier d'un forum...