Meilleurs algo d'un test par bouding box

Parce que c'est du 6502 donc moins de cycles que moi, et aussi parce que tu fais pas tout les tests j'ai l'impression .

tu dois tester x1 avec x2 et X'2, x'1 avec x2 et X'2 et pareil pour Y  donc 4 test 16 bit par coordonnée et pas 2    .
je pense que tu peux multiplier tes 98 cycles x2 ..

C'était exactement ça ! Sauf que effectivement au début c'était faux cette comparaison 8 bits signé mais je l'ai vite corrigé. Maintenant ça doit prendre le 16 bits signé correctement en compte.

Si je te le dis, vu que je me suis fait bezouille aussi  

TOUKO a écrit:Oui mais pas que, quand tu overclocke la master clock c'est tout le système que tu booste, c'est probable que le VDC n'aime pas .
A moins que tu puisses juste ovck le CPU sans toucher la MC ..

C'est le cas, tu peux overclocker le 68000 tout seul, c'est un mod assez classique sur MD d'ailleurs...

Exact, je connais pas le Z80, mais perso mis à part certains trucs chiant le 65xx est vraiment simple, mais comme tu viens du 68000 je comprends que ca soit pénible, mais pourtant ça l'est pas du tout ..
Perso j'adore sa simplicité, et à part de rares cas (du moins sur 6280) une instruction prend tant de cycles et puis basta, c'est hyper simple à calculer .
Avec l'habitude c'est un CPU très plaisant,simple et efficace, mais pas parfait   
Youki qui code sur les 2, n'aime pas du tout le Z80 ..

Je ne suis pas un grand fan du Z80 non plus, je trouve son instruction set assez inefficace en fait, malgré tout, pour un CPU 8 bits il est assez avancé, beaucoup de registres, des opérations 16 bits de base... donc assez facile à utiliser. Mais à côté le 68000 est tellement plaisant et simple... Et quand tu parles de cycles, c'est encore plus simple sur 68000, tout est d'une logique imparable, en gros tu comptes un accès mémoire = 4 cycles et à partir de là tu déduis la plupart des cycles des instructions.

Ok alors faut utiliser le même nom ou faire
player_posx_low
player_posx_high

player_posy_low
player_posy_high
tu fais pareil pour ennemi .
Donc on est d'accord avec ça,CAD tu scindes tes valeurs en octets  .

ldx #1

lda player_posx_low , x
lda player_posx_high , x

etc ..
pour passer à la valeur suivante, un simple inx suffit ..

Non non tu es bloqué dans ta logique 6502, ce n'est pas ce que je veux faire X'D
En gros j'ai ma structure box :

struct box
{
   int xmin;
   int xmax;
   int ymin;
   int ymax;
};

où chaque paramètre est un 16 bits. Et ensuite j'ai mon tableau de box :
struct box enemies[];

donc au début X = 0 et enemies pointe sur le début du tableau enemies.
en faisant:
enemies.xmin_low c'est comme si je faisais $enemies + 0
enemies.xmin_high c'est comme si je faisais $enemies + 1
enemies.xmax_low c'est comme si je faisais $enemies + 2
et ainsi de suite...
et X me sert d'indice pour l'ennemi en cours... c'est aussi simple que cela.
Donc quand j'ai terminé un test, je veux juste passer à l'ennemi suivant donc X = X + 8.
Que ma syntaxe assembleur soit pas bonne ok mais tu comprends ce que je veux faire et si j'ai compris le système d'adressage du 6502 c'est possible avec les cycles que j'ai indiqué il me semble. J'ai l'impression que tu penses toujours en structure unique et statique alors que je pense en tableau.

Il est super ton lien vers le simulateur 6502, TOUKO !

Par contre je ne comprends pas, je fais :

Code:

lda #12
cmp #12

résultat: C=1 !?

Est-ce que la Carry qu'on obtient est inversée (comme pour un "sbc") ou bien ? 

TOUKO a écrit:Parce que c'est du 6502 donc moins de cycles que moi, et aussi parce que tu fais pas tout les tests j'ai l'impression .

tu dois tester x1 avec x2 et X'2, x'1 avec x2 et X'2 et pareil pour Y  donc 4 test 16 bit par coordonnée et pas 2    .
je pense que tu peux multiplier tes 98 cycles x2 ..

C'est ce que je te dis depuis le début, tu fais trop de test j'ai l'impression.
Dans le cas classique de la collision par bounding box c'est 4 tests ! Pas plus...
Toi ensuite pour gérer les valeurs 16 bits (et signé) ça complique un peu les choses mais y'a moyen d'avoir moins de code que ta version. Si tu peux essai de tester ma version pour voir...
Je pense qu'elle est fonctionnelle, le seul truc c'est qu'il faut initialisé les box avec min et max+1 (car il manque un fichu test sur le 6502 :p)

C'est le cas, tu peux overclocker le 68000 tout seul, c'est un mod assez classique sur MD d'ailleurs...

ah là effectivement  ..

Je ne suis pas un grand fan du Z80 non plus, je trouve son instruction set assez inefficace en fait, malgré tout, pour un CPU 8 bits il est assez avancé, beaucoup de registres, des opérations 16 bits de base... donc assez facile à utiliser. Mais à côté le 68000 est tellement plaisant et simple... Et quand tu parles de cycles, c'est encore plus simple sur 68000, tout est d'une logique imparable, en gros tu comptes un accès mémoire = 4 cycles et à partir de là tu déduis la plupart des cycles des instructions.

Pour moi tout les CPU ont leur charme, le plus chiant dans tout ça se sont les habitudes, c'est elles qui nous font chier en fait .
Ce que j'aime pas sur le 68000 c'est le calcul des cycles qui est complexe je trouve, et le fait que les op 8 ne te font rien gagner, mais tout ça c'est par rapport au CPU de la nec, car j'ai pris une habitude avec, et je me pose plus trop de questions, je sais comment il faut que je code tel ou tel truc pour que ça aille le plus vite possible, dans les limites de mes connaissances bien sur .
Toi c'est pareil, tu es habitué au confort et à la façon de coder du 68K et changer te semble un effort surnaturel des que c'est plus pareil .

Non non tu es bloqué dans ta logique 6502, ce n'est pas ce que je veux faire X'D
En gros j'ai ma structure box :

struct box
{
   int xmin;
   int xmax;
   int ymin;
   int ymax;
};

ah ok , d'où le +8 ..
Vu que directement tu ne peux qu'utiliser le nom de la struct
tu peux faire


de struct box , X à struct box + 1, X = xmin
de struct box + 2 , X à struct box + 3, X = xmax

etc ...

Dans le cas classique de la collision par bounding box c'est 4 tests ! Pas plus...

Comment ça 4 tests ??
je vois pas comment faire que 4 tests..
Putin ca serait marrant que j'en fasse trop lol ..
c'est possible qu'algorithmiquement je me sois planté  

Stef a écrit:C'est ce que je te dis depuis le début, tu fais trop de test j'ai l'impression.
Dans le cas classique de la collision par bounding box c'est 4 tests ! Pas plus...

+1

ah ok , d'où le +8 ..
Vu que directement tu ne peux qu'utiliser le nom de la struct
tu peux faire


de struct box , X à struct box + 1, X = xmin
de struct box + 2 , X à struct box + 3, X = xmax

etc ...

Et ben voilà, c'est ça que je voulais faire depuis le début, je t'ai dit, j'ai retranscrit mon algo tel quel. Et honnêtement je ne vois pas en quoi il est moins bon ainsi. Je pense que les 98 cycles que j'ai par loop sont corrects, tu devrais être content, c'est très proche de ce que j'ai avec le 68000

Pour moi tout les CPU ont leur charme, le plus chiant dans tout ça se sont les habitudes, c'est elles qui nous font chier en fait .
Ce que j'aime pas sur le 68000 c'est le calcul des cycles qui est complexe je trouve, et le fait que les op 8 ne te font rien gagner, mais tout ça c'est par rapport au CPU de la nec, car j'ai pris une habitude avec, et je me pose plus trop de questions, je sais comment il faut que je code tel ou tel truc pour que ça aille le plus vite possible, dans les limites de mes connaissances bien sur .
Toi c'est pareil, tu es habitué au confort et à la façon de coder du 68K et changer te semble un effort surnaturel des que c'est plus pareil .

Je suis convaincu que si tu goutais un peu plus au 68000 tu aurais du mal à revenir sur le 6280, enfin je pense :p   Le 68000, pour être rapide y'a pas de miracles, tu bosses avec les registres quand tu peux

Naaaaaaaaaaaaan, je me suis cassé le fion depuis le début avec plus de tests que vous ??,
Si c'est le cas, ça va vous faire mal au cul les gars  

Et ben voilà, c'est ça que je voulais faire depuis le début, je t'ai dit, j'ai retranscrit mon algo tel quel. Et honnêtement je ne vois pas en quoi il est moins bon ainsi. Je pense que les 98 cycles que j'ai par loop sont corrects, tu devrais être content, c'est très proche de ce que j'ai avec le 68000

Oui j'ai pigé maintenant, mais comme tu utilisais les noms comme dans une structure, j'arrivais pas à suivre .
Mais c'est pas grave, le tout est d'y arriver ..

Je suis convaincu que si tu goutais un peu plus au 68000 tu aurais du mal à revenir sur le 6280, enfin je pense :p   Le 68000, pour être rapide y'a pas de miracles, tu bosses avec les registres quand tu peux

Bien sur, mon ressentis n'est qu'a première vue, j'ai pas dis que j'aimerais pas .
C'est clair que dés que tu restes dans les registres ça pousse bien, et je pense que ce doit pas être évident au début ..


Bon les gars vous m'expliquez le bouding box, parce que j'ai toujours vu 4 tests/coordonnée
x1 sup ou egal à x2
x1 inf ou égal à x'2
ou
x'1 sup ou egal à x2
x'1 inf ou égal à x'2

pareil pour y, vue que la box c'est 2X et 2Y

Vous me faites marcher là ???

AAAAAAAAAAAAAAAAAAAAAAH je viens de comprendre      
Si spr1_x_max < spr2_min
ou
 spr1_x_min > spr2_max
on sort, et pareil pour Y ..

TOUKO a écrit:
Bon les gars vous m'expliquez le bouding box, parce que j'ai toujours vu 4 tests/coordonnée
x1 sup ou egal à x2
x1 inf ou égal à x'2
ou
x'1 sup ou egal à x2
x'1 inf ou égal à x'2

pareil pour y, vue que la box c'est 2X et 2Y

Vous me faites marcher là ???

AAAAAAAAAAAAAAAAAAAAAAH je viens de comprendre      
Si spr1_x_max < spr2_min
ou
 spr1_x_min > spr2_max
on sort, et pareil pour Y ..

Ben ouais, c'est quoi ton algo foireux    Mais en plus dés le début je te l'ai dit que je comprenais pas ton algo et que normalement c'était plus simple (j'ai d'ailleurs posté le mien bien commenté donc tu aurais du le voir :p )
Bon après, je vois le temps que j'ai mis avec le 6502 et en gros c'est à peu près ce à quoi je m'attendais : malgré que le CPU prenne moins de cycle sur ces instructions à la base, pour faire la même chose que le 68000 tu dois faire plus d'opérations et au final tu finis au moins avec le même nombre de cycles si ce n'est plus.

TOUKO a écrit:Bon les gars vous m'expliquez le bouding box, parce que j'ai toujours vu 4 tests/coordonnée
x1 sup ou egal à x2
x1 inf ou égal à x'2
ou
x'1 sup ou egal à x2
x'1 inf ou égal à x'2

pareil pour y, vue que la box c'est 2X et 2Y

Vous me faites marcher là ???

AAAAAAAAAAAAAAAAAAAAAAH je viens de comprendre      
Si spr1_x_max < spr2_min
ou
 spr1_x_min > spr2_max
on sort, et pareil pour Y ..

On a bien fait d'aborder le sujet  

avec toutes ces collisions, vous pouvez pas nous pondre un jeu d'auto-tamponeuses  

Plus sérieusement, vous n'imaginez même pas ma frustration de ne pas pouvoir participer a vos tests...

programmer en asm, un vieux rêve, en tout cas bravo les gars 

LOL bande d'enf... vous auriez pu me faire un dessin ..
Putin j'étais tellement tête dans le guidon ..   

Ben ouais, c'est quoi ton algo foireux    Mais en plus dés le début je te l'ai dit que je comprenais pas ton algo et que normalement c'était plus simple (j'ai d'ailleurs posté le mien bien commenté donc tu aurais du le voir :p )

En fait j'étais dans mon trip, et j'ai pas percuté .

Bon bah merci quand même, je gagne pas mal là   

Bon je vais dormir ..

Bon après, je vois le temps que j'ai mis avec le 6502 et en gros c'est à peu près ce à quoi je m'attendais : malgré que le CPU prenne moins de cycle sur ces instructions à la base, pour faire la même chose que le 68000 tu dois faire plus d'opérations et au final tu finis au moins avec le même nombre de cycles si ce n'est plus.

C'est je jeu, des fois c'est bien des fois moins, ça dépend des cas, des données ,des traitements .
demain je posterais la nouvelle routine, là j'ai trop de fumée dans les yeux .

@MD2B: l'ASM c'est sympa, enfin si tu aimes le sudoku  

Vous emmerdez pas avec avec nombres signés, considérez que vous clippez à 100 voire plus pour être sur de ne pas avoir de négatif   

@fano: sur une réso de plus de 256 sur X, t'as pas le choix .

Oui , je dis ça à postériori car après réflexion il me semble qu'il y a un souci auquel je n'avais pas pensé avec les chiffres négatifs sur 16bits.Je dois avouer que j'ai pas envie de me prendre la tête à vérifier donc vaut mieux travailler qu'en positif (habituellement je n'ai pas ce souci car je travaille en 8:3 ce qui peut sembler contre productif mais ce qui est très efficace pour adresser les tableaux de tiles)

fanoplusplus64K a écrit:Oui , je dis ça à postériori car après réflexion il me semble qu'il y a un souci auquel je n'avais pas pensé avec les chiffres négatifs sur 16bits.Je dois avouer que j'ai pas envie de me prendre la tête à vérifier donc vaut mieux travailler qu'en positif (habituellement je n'ai pas ce souci car je travaille en 8:3 ce qui peut sembler contre productif mais ce qui est très efficace pour adresser les tableaux de tiles)

Si tu considères du non signé là par contre tu es obligé de passer en 16 bits.
Une solution pour vos CPU 8 bits c'est d'utiliser du non signé 16 bits pour le X (avec un offset de +128 par ex) et du signé 8 bits pour le Y, je pense que ça serait le plus efficace. Je vais convertir le code 6502 pour ça, à mon avis on va commencer à s'approcher d'un code assez optimal   Après j'aurais toujours la limite de 32 sprites max à tester dans la loop, si y'a plus de 32 sprites faut passer par plusieurs fonctions qui pointent sur les différents tableaux de box ennemies.

Ce qui est cool avec le 68000 c'est que tu n'es jamais embêté avec ce genre de détail, la taille des registres et la capacité d'adressage va au delà des capacités du CPU en quelque sorte

Finalement je reste en 16 bits car je trouve le 8 bits pour le Y un peu trop contraignant quand même (ça limite la taille du sprite à 16 pixels ce qui est un peu faible).
Par contre les bounding box sont précalculées avec un offset histoire de pouvoir faire le test en positif uniquement  (plus rapide    )

Code:

3     ldy <numEnemies
2     ldx #0
5

.loop

// TEST on X coordinates

3     lda   <player.xmax_low
4     cmp   <enemies.xmin_low,X
3     lda   <player.xmax_high
4     sbc   <enemies.xmin_high,X
2     bcc   .no_collid_cc
16

3     lda   <player.xmin_low
4     cmp   <enemies.xmax_low,X
3     lda   <player.xmin_high
4     sbc   <enemies.xmax_high,X
2     bcs   .no_collid_cs
16

// TEST on Y coordinates

3     lda   <player.ymax_low
4     cmp   <enemies.ymin_low,X
3     lda   <player.ymax_high
4     sbc   <enemies.ymin_high,X
2     bcc   .no_collid_cc
16

3     lda   <player.ymin_low
4     cmp   <enemies.ymax_low,X
3     lda   <player.ymin_high
4     sbc   <enemies.ymax_high,X
2     bcs   .no_collid_cs
16

.collid
2     lda  #1
7     rts
9

.no_collid_cs
2+1   txa
2     adc #7
2     tax
2     dey
3     bne .loop
12

.no_collid_cc
2+1  txa
2    adc #8
2    tax
2    dey
3    bne .loop
12

2-1   lda  #0
7     rts
8

Cycles per loop: 76
Je pense que ça va être difficile de faire mieux même avec le 68000 X'D
Je me tire une balle dans le pied  

LOL, mais n'oublions pas non plus que le calcul des box existe toujours, il est déporté, mais toujours là .

Perso dans l'immédiat, j'essaye de faire la routine la plus rapide certe, mais aussi en même temps la moins contraignante, à l'utilisation la plus large possible .
La difficulté est de trouver le bon compromis .

Dans ta loop stef, tu as la chance d'avoir Y de dispo pour comptabiliser les loops, ce qui te fait gagner 4 cycles/loop .

16 cycles par test 16bits , impressionnant !

Le pire c'est qu'il y prend goûts   

Après ça il va se dire "putin il se traine le 68000"  

par contre ça :

Code:

3     lda   <player.xmax_low
4     cmp   <enemies.xmin_low,X
3     lda   <player.xmax_high
4     sbc   <enemies.xmin_high,X
2     bcc   .no_collid
16

Je suis pas sur que ça marche à tout les coups   

EDIT: Bien vu, ça semble marcher correctement  

TOUKO a écrit:LOL, mais n'oublions pas non plus que le calcul des box existe toujours, il est déporté, mais toujours là .

Perso dans l'immédiat, j'essaye de faire la routine la plus rapide certe, mais aussi en même temps la moins contraignante, à l'utilisation la plus large possible .
La difficulté est de trouver le bon compromis .

Dans ta loop stef, tu as la chance d'avoir Y de dispo pour comptabiliser les loops, ce qui te fait gagner 4 cycles/loop .

Ah bah j'ai fait en sorte d'utiliser le peu de registres dispo au mieux, j'ai toujours cette logique d'utiliser les registres même quand y'en a pas X'D

Ah mais tout à fait, mais avec le 65xx, tu es vite à court, j'essaye aussi de maximiser leur utilisation,avec 2 cycles vs 4 minimum, c'est vite vu .

C'est là qu'un CPU comme l'ARM2 dégomme, il a la vitesse du 65xx (voire même plus), et les registres du 68000 ..

fanoplusplus64K a écrit:16 cycles par test 16bits , impressionnant !

Il faut reconnaitre que le 6502 se défend bien quand même, ses accés indexé (très important)  sont très rapide. Dommage par contre qu'ils soient limité à 8 bits !

D'où le 65816  

je me sens tout petit moi qui ne siat pas programmer en assembleur  

Parce que t'as jamais essayé de t'y mettre vraiment, je savais pas vraiment non plus avant de m'y mettre .

La logique reste la même, des variables, des tests,des boucles,des appels de fonctions ..

oui je sais, ca doit meme etre de plus en plus logique, vu qu'on se rapproche du "langage machine".

je ne pense pas avoir la volontée ni le temps pour apprendre 

Touko, en combien de temps tu as appris à maitriser l'assembleur ?

TOUKO a écrit:D'où le 65816  

Ouais mais le 65816 est très chiant dans son genre, les bascules entre mode 16 bits et 8 bits sont problématiques. En cas d'interruption par exemple. J'ai lu que beaucoup de dev SNES reste quasi tout le temps en mode 8 bits, pour éviter ce genre de problème et aussi parce que le mode 8 bits est plus rapide. Un truc interessant qu'ajoute le 65816, c'est le registre DP pour faire du page zero configurable.

Sinon pour résumer un peu, le code que j'ai fait pour le 6502 est tout de même un cas assez avantageux pour le 6502 (avec beaucoup de branchement et d'indexation gratuite) et je pense qu'il est assez optimisé aussi (je ne pense pas qu'on puisse faire plus rapide). Je peux surement optimiser un peu mon code 68000, peut être que je ne serais pas plus rapide mais je vais encore me rapprocher... Enfin tu vois l'idée, même dans un cas qui n'est pas forcément favorable le 68000 n'est pas aussi lent qu'il y parait    et dans un cas favorable, il aura un avantage certain :)

Mais je reconnais que le 6502 (et dérivé) peut-etre bien efficace malgré son architecture simple

oui je sais, ca doit meme etre de plus en plus logique, vu qu'on se rapproche du "langage machine".

je ne pense pas avoir la volontée ni le temps pour apprendre 

Touko, en combien de temps tu as appris à maitriser l'assembleur ?

La progression est très rapide, j'ai commencé à remplacé certaines choses lentes en C, en ASM, après c'était les fonctions, je les écrivaient en C, et dés qu'elles marchaient je les convertissaient .
Et à force de remplacer, tu codes tout en ASM, ça va plus vite, car tu optimises quasiment dans la foulée .
Une foi que tu comprends comment ça marche, c'est pas plus dur que le basic .
La difficulté en ASM, c'est de faire un truc de A à Z en écrivant tout, pas si tu as déjà une osature, style un compilateur qui te permet de mettre des lignes asm dedans .
Evidemment pour moi c'est valable sur des consoles/micros 8/16 bit, sur pc ça sert à rien .

Ouais mais le 65816 est très chiant dans son genre, les bascules entre mode 16 bits et 8 bits sont problématiques. En cas d'interruption par exemple. J'ai lu que beaucoup de dev SNES reste quasi tout le temps en mode 8 bits, pour éviter ce genre de problème et aussi parce que le mode 8 bits est plus rapide. Un truc interessant qu'ajoute le 65816, c'est le registre DP pour faire du page zero configurable.

c'est vrai, mais j'ai un peu regardé les opcode pour ce CPU, et tu perds pas grand chose à traiter sur 16 bit plutôt que 8 (style 1 ou 2 cycles la plupart du temps)
Tu peux faire les X en 16, et passer en 8 pour Y par exemple, sans oublier les modes d'adressage supplémentaires + instructions par rapport au 6502 .

Sinon pour résumer un peu, le code que j'ai fait pour le 6502 est tout de même un cas assez avantageux pour le 6502 (avec beaucoup de branchement et d'indexation gratuite) et je pense qu'il est assez optimisé aussi (je ne pense pas qu'on puisse faire plus rapide). Je peux surement optimiser un peu mon code 68000, peut être que je ne serais pas plus rapide mais je vais encore me rapprocher... Enfin tu vois l'idée, même dans un cas qui n'est pas forcément favorable le 68000 n'est pas aussi lent qu'il y parait    et dans un cas favorable, il aura un avantage certain :)

Je reconnais que là c'était pas mal, mais si tu regardes juste les additions 16 bit, le 68000 est bien devant, il perd son avantage sur autre chose.
Et j'ai pas dis qu'il était lent, juste que le 6280 faisait jeu égal dans nos consoles ..  
Et que le 65816, malgrè l'implémentation pourrie de nintendo, n'était pas si nul,sans être byzance non plus faut avouer ..

Mais je reconnais que le 6502 (et dérivé) peut-etre bien efficace malgré son architecture simple 

Oui c'est vrai, mais tu peux le voir, c'est pas tout rose non plus, et on est pas tombé sur un cas de merde style faire des rotations/decalages de bit sur des 16 bit, ça c'est assez pourri sur 65xx .
Ce qui est sympa sur des instructions simples, c'est que par exemple tu peux optimiser en cours de traitement, par exemple ton add.w est plus rapide que moi pour faire une addition 16 bit, mais tu gagnes rien en faisant la même chose sur 8,elle est figée, que moi je peux et c'est sur ça qu'il faut jouer .
Si on avait fait de la 3d, là le 68000 aurait fait mal .

drfloyd a écrit:oui je sais, ca doit meme etre de plus en plus logique, vu qu'on se rapproche du "langage machine".

je ne pense pas avoir la volontée ni le temps pour apprendre

C'est dommage car tu rates quelque chose
L'asm est assez simple en soi c'est comme d'autres languages sauf que c'est très décomposé.Le plus chiant étant d'avoir en tête la syntaxe et les opcodes d'un processeur, au début tu as ta doc à coté de toi mais au bout de quelques semaines elle ne te sert quasiment plus.

La progression est très rapide, j'ai commencé à remplacé certaines choses lentes en C, en ASM, après c'était les fonctions, je les écrivaient en C, et dés qu'elles marchaient je les convertissaient .
Et à force de remplacer, tu codes tout en ASM, ça va plus vite, car tu optimises quasiment dans la foulée .
Une foi que tu comprends comment ça marche, c'est pas plus dur que le basic .
La difficulté en ASM, c'est de faire un truc de A à Z en écrivant tout, pas si tu as déjà une osature, style un compilateur qui te permet de mettre des lignes asm dedans .
Evidemment pour moi c'est valable sur des consoles/micros 8/16 bit, sur pc ça sert à rien .

Y'a quand même un truc très galère avec l'assembleur... Ca prend quand même nettement plus de temps à écrire que du C. Et surtout quand tu as optimisé une fonction en assembleur et que tu dois faire un changement dedans, parfois (même souvent) tu dois modifier une bonne partie de la fonction pour garder un bon niveau d'optimisation. Pour ça en général je préfère rester en C et passer en assembleur uniquement au tout dernier moment quand je sais que mon code ne bougera plus.