Re: Mr ToutLeMonde et la programmation NES...

[Stef]

Ouais mais si tu lisais tout tu verrais que les quotes que tu prends viennent de gars comme toi qui en restent au rapport instruction / cycle et qui ne veulent pas comprendre... Tu verras les réponses qui tentent de leur expliquer en quoi ils se plantent, tout comme je fais avec toi en ce moment mais vraiment c'est du temps de perdu. On a déjà eu exactement la même conversation et tu es borné de chez borné ou simplement je te surestimais :p

[Invité]

Bah le mec à codé un émulateur pcengine, c'est pas un fanboy pris au hasard, il sait un peu de quoi il parle  .
Et le fichier profile, vient d'un mec qui à crée lui un emulateur Md, et qui n'est pas non plus un fanboy de base,et qui sait surement aussi de quoi il parle .

On a déjà eu exactement la même conversation et tu es borné de chez borné ou simplement je te surestimais :p

Venant d'un mec qui pratique en masse l'hopital qui se fou de la charité, ça me choque pas du tout 

ce lien que tu as posté :
http://www.brutaldeluxe.fr/products/crossdevtools/mrspritetech/

J'ai l'impression que tu l'as même pas lu, alors que le mec dis exactement ce que je dis depuis le début,et entre autre un gain d'optimisation énorme quand tu sais ce que tu fais ..

We also provide a comparison between the number of cycles used by the Mr Sprite coding (2570 cycles) and the number of cycles used by the classic algorithm (19968 cycles).

de 19968 cycles pour afficher un sprite ,il passe à 2570,rien de plus à ajouter,à part le "mais vraiment pour une fois essai de lire et comprendre ce qui s'y dit :p", essayes de l'appliquer avant de le conseiller aux autres, tu verras tu comprendras mieux 

[Stef]

Mais si justement, j'ai bien tout lu, et si tu avais bien tout lu aussi tu aurais vu que malgré son amour pour cette machine (et qu'il prouve vu comment il s'est acharné sur sa routine de sprite) il répète souvent ô combien le 68000 est plus performant que les 65816...

19968 cycles pour afficher un sprite ,il passe à 2570

Et.. ? En quoi c'est surprenant ? C'est de l'optimisation de code et ça marche avec tout les CPU. Là il a vraiment été loin (génération de code pour chaque sprite) et je pense sincèrement qu'il est difficile de faire mieux sur 65816, mais sur 68000 je suis certain que tu peux aller plus loin.

[Invité]

et il répète souvent ô combien le 68000 est plus performant que les 65816

La mauvaise foi, il parles du 68000 des ST/AMIGA qui tournent plus de 3x plus vite, c'est normal,pas du CPU en général à la même vitesse,et il le dit qu'une foi, eh oh c'est moi le marseillais, c'est pas à toi d'exagérer 

Even if their 68000 at 7/8 Mhz is much more powerful than our 65c816 at 2.5 Mhz,

C'est assez parlant non ??

Et ça encore plus,il parle de l'avantage du 65816 à utiliser le mode 8 bit par rapport au 68000

 The 65816 doesn't have issues with addressing ODD addresses so no need for a weird memory organisation to provide EVEN addresses only. 

Et.. ? En quoi c'est surprenant ? C'est de l'optimisation de code et ça marche avec tout les CPU. Là il a vraiment été loin (génération de code pour chaque sprite) et je pense sincèrement qu'il est difficile de faire mieux sur 65816, mais sur 68000 je suis certain que tu peux aller plus loin.

Mais bien sur, c'est pour ça que sur St j'ai jamais vu un jeu avec des sprites de la même taille que sword of sodan sur 2GS, même avec son 68000 à 8mhz ,là il atteint du 3,5 cycles/pixels avec le sprite de barbarian, ça m'étonnerai fort que le 68000 fasse aussi bien  ..
Et en plus le 2 gs se tape les 128 premiers ko qui le force à tourner à 1mhz.

Donc au final un 65816 bien codé se débrouille vachement bien par rapport à un 68000 presque 3x plus rapide, j'ose à peine imaginer façe à un 65816 qui tournerai réellement à 5mhz 


Et vu que tu semble savoir mieux que tout le monde ,les choix hardware des constructeurs, dis moi pk alors si la solution de nec etait si chère, pk il ont pas mi un 68008/Z80 à 10 mhz ou plus plutot ??

[Stef]

La mauvaise foi, il parles du 68000 des ST/AMIGA qui tournent plus de 3x plus vite, c'est normal,pas du CPU en général à la même vitesse,et il le dit qu'une foi, eh oh c'est moi le marseillais, c'est pas à toi d'exagérer 
...
Even if their 68000 at 7/8 Mhz is much more powerful than our 65c816 at 2.5 Mhz,

Bah oui justement... c'est le problème du 65816, là où tu as un 65816 à 2.5 Mhz tu pourrais avoir un 68000 à 8 Mhz.
Et il dit bien que le 68000 à 7/8 Mhz is much more powerful.

Mais bien sur, c'est pour ça que sur St j'ai jamais vu un jeu avec des sprites de la même taille que sword of sodan sur 2GS, même avec son 68000 à 8mhz ,là il atteint du 3,5 cycles/pixels avec le sprite de barbarian, ça m'étonnerai fort que le 68000 fasse aussi bien  ..

Comment tu peux comparer 2 machines avec des modes videos si différents La grosse force de l'apple 2 GS c'est son mode video très performant : 4BPP en linéaire.
A côté tu as ça :

Even if their 68000 at 7/8 Mhz is much more powerful than our 65c816 at 2.5 Mhz, their graphic page organisation consumes a lot of power. For the Amiga (7 Mhz, 40 KB graphic page), the graphic page is divided into 5 different areas, each coding 1 of the 5 bit plan. With 32 colors on the screen, you need 5 bitmap area of 320x200 bit each (8 KB). So, if you want to display 1 pixel using color 1F, you have to update in 5 different memory locations, the 5 bits. Because you have a 68000, you must use the .B (BYTE) adressing mode because the other ones (.W and .L) don't want to write to ODD address. To summerize, you need 5 read / write to memory to switch on 1 pixel. On the Apple IIgs, you need juste 1 (LDA / [ORA] / STA). On the Atari ST (8 Mhz, 32 KB graphic page), they did not separate the bit plan into several areas but they mixed them together with an interleave of 1 WORD. So once again, if you want to display a pixel using color F (Atari ST has 16 colors), you have to update 4 consecutive WORD (4 read / write) : the 4 bits of 1 pixel is coded in 4 consecutive Words.

Donc forcément avec des organisations mémoires aussi foireuses il est très compliqué de faire de l'affichage de sprite en software.
Au final c'est la Megadrive qui se rapproche le plus du mode graphique du 2 GS, sauf que c'est du tile et non du bitmap.
Il suffit de voir le port de Wolfenstein 3D sur megadrive pour voir que le 68000 en plus dans le ventre même pour l'affichage de sprites en software.

Donc au final un 65816 bien codé se débrouille vachement bien par rapport à un 68000 presque 3x plus rapide, j'ose à peine imaginer façe à un 65816 qui tournerai réellement à 5mhz 

Le calcul est simple tu sais, quand tu regardes son algo, plus le sprite est gros et plus le rapport devient interessant et va tendre vers 1 pixel rendu pour 1.25 cycle (ou 1 cycle avec un sprite mono couleur :p) dans le meilleur des cas grâce au stack pointer et au 16 bits.
Donc en utilisant le CPU de manière optimale tu affiches 4 pixels colorés en 5 cycles et 4 pixels couleurs fixées en 4 cycles.
Sur 68000 dans le cas optimal tu affiches 8 pixels colorés en 8 cycles et 4 pixels couleurs fixées en 4 cycles.

Du coup on voit quoi, on voit que le 65816 à 5 Mhz irait aussi vite qu'un 68000 à 8 Mhz dans le cas de sprites très colorés.
Dans le cas de sprites peu colorés, il faut un 65816 à 8 Mhz pour également le 68000 à 8 Mhz.

Est-ce que tu comprends enfin pourquoi je dis tout le temps que les cpu type 65xx sont tout pourris ? :p
Même à 5 Mhz le 65815 n'égalera pas toujours le 68000 a cause de son instruction set plus limité, sans compter qu'il était impossible d'avoir un 65816 à 5 Mhz à l'époque de la SNES ou du 2 GS.

[vingazole]

Vous devriez peut-être créer un topic "TOUKO vs Stef : Fight !"...

[Stef]

ouais on a encore pourri un topic :-/

[Invité]

ouais on a encore pourri un topic :-/

Et il dit bien que le 68000 à 7/8 Mhz is much more powerful.

A 3x la vitesse encore heureux ..
J'ai jamais dis qu'avec cet écart le 65816 battait le 68000.

Comment tu peux comparer 2 machines avec des modes videos si différents La grosse force de l'apple 2 GS c'est son mode video très performant : 4BPP en linéaire.

 
Tu es gonflé quand même, c'est pas toi qui vantait la 3D,et les zoom de sprites sur Md par rapport à la snes et la PCE alors que c'est exactement la même chose que le 2gs vs ST, un mode bitplan pur (ST,snes,pce) contre un packed pixel (2gs,MD) ..
Ah oui mais là ça compte pas, ça donne l'avantage au 65816 .. 

Donc forcément avec des organisations mémoires aussi foireuses il est très compliqué de faire de l'affichage de sprite en software.
Au final c'est la Megadrive qui se rapproche le plus du mode graphique du 2 GS, sauf que c'est du tile et non du bitmap.
Il suffit de voir le port de Wolfenstein 3D sur megadrive pour voir que le 68000 en plus dans le ventre même pour l'affichage de sprites en software.

C'est ce que je te dis à chaque fois quand tu parles de 3D sur MD, de wolf3D, ou de zoom de sprites, même combat, pas le CPU mais le bitplan qui prends 4x plus de temps que sur du packed pour changer 1 pixel   
Et n'oublies pas non plus qu'il parle aussi de la facilité qu'a le 65816 par rapport au 68000 à gérer le 8 bit, et aussi bien sur les adresse .

Même à 5 Mhz le 65815 n'égalera pas toujours le 68000 a cause de son instruction set plus limité, sans compter qu'il était impossible d'avoir un 65816 à 5 Mhz à l'époque de la SNES ou du 2 GS.

J'aime bien comme tu es sur d'avoir raison .
Quand le 2 gs est sortie WDC avait un CPU rapide (8 ou 10 je crois).
apple à choisi cette fréquence pour des raisons commerciales, pour pas qu'une machine apple grand public, fasse mieux que ses modeles pros, je vois pas ce qui te gène là dedans,dans ton interview de wozniak, il parlait bien d'un 65816 à 8 mhz qu'apple voulait,et WDC l'avait ..
Apple pouvait sans problème mettre un CPU à 5mhz, sans soucis, et nintendo encore plus,mais bon vu que tu aimes croire le contraire ..

tient, ce document date de 1990 :
http://members.iinet.net.au/~kalandi/apple/AUG/1990/07%20JUL.AUG/HWARE.SPEED.html

En 90 WDC avait des 65816 à 10 et 14 mhz, et une autre société pouvait en faire de 18 à 24 mhz .. 
Et ça :
http://www.hackzapple.com/ORG1/M2/ACCEL/XLSPEEDEMON.HTM
Une speed demon, carte accélératrice avec un 6502 à 4 mhz et de la ram 100 ns, sortie en  ........ 1984 

Ca:
http://www.hackzapple.com/ORG1/M2/ACCEL/XLTWGS15.HTM
la transwarp pour 2GS sortie en 89 avec un 65816 à 7 mhz qui pouvait facilement monter à plus de 10 mhz rien qu'en changeant l'oscilateur 
Donc c'est sur en 90 la snes pouvait pas avoir de 65816 à 5 mhz, c'était impossible 

Même à 5 Mhz le 65815 n'égalera pas toujours le 68000 a cause de son instruction set plus limité,

C'est à se demander comment pendant une décennie les processeurs risc ont dominé les cisc si ça dépendait juste du nombre d'instructions qu'un CPU a 

[vincent2105]

Salut à tous,

Après quelques mois d'abstinence je m'y suis remis il y a 15 jours.

J'ai mis de coté le jeu de tennis et suis désormais sur un jeu de course. Je code plus proprement qu'au début, je vais donc beaucoup plus vite en repartant de zéro qu'en essayant de rattraper mon vieux code.

Concept ultra simple : aller le plus vite en évitant les autres véhicules. Il y a 3 voies, et seulement 3 positions possibles gauche, milieu, droite. L'écran est splitté ce qui permettra d'avoir 2 modes de jeu principaux (1 joueur vs cpu ou 2 joueurs).
J'utilise des sprites de "bandes blanches" pour créer une illusion de scrolling.  
J'utilise des sprites de taille 8x16 (horizontal x vertical)au lieu des 8x8 habituellement utilisés. Je double donc la surface des objets affichés. Avec 6 véhicules simultanément, l'écran est bien rempli.
La priorité des sprites entre eux étant liée à leur adresse, j'ai déclaré les "bandes blanches" après les véhicules. Cela permet de minimiser la perception de clignotements lorsque plus de 8 sprites se retrouvent sur la même ligne.
J'ai ajouté des curseurs sur une piste en haut de l'écran. Ils se déplacent en fonction de la vitesse de chaque voiture. Les collisions sont gérées (pour l'instant la voiture du joueur devient orange le temps de la collision).
Tout fonctionne sur NES. Je continue...




Ah oui... les voitures, c'est les rectangles bleus pour l'instant

[Invité]

Génial !!
Tu pourras l'enrichir en faisant varier la vitesse des voitures, ajouter des flaques d'huile à éviter, etc ...

Cela part d'une super base en tout cas !

[Invité]

Cool que tu reprennes le coding, comme tu vois on s'est bien occupé de ton topic en ton absence 

[vingazole]

comme tu vois on s'est bien occupé de ton topic en ton absence 

Les sagouins !


Bon courage pour la suite, vincent2105

[vincent2105]

Merci à vous pour votre soutien ! (même au sagouin)

Tu pourras l'enrichir en faisant varier la vitesse des voitures, ajouter des flaques d'huile à éviter, etc ...

L'idée des flaques d'huiles, des herses et tout autre obstacle fixe me trottait dans la tête, mais j'ai essayé et vu la vitesse de la voiture ils sont tout simplement inévitables . Je tiens à conserver cette vitesse, il faudra que je me contente d'obstacles lents comme des camions etc. Dommage. Par contre je pense inclure quelques powerup.

[pckid]

Genial bravo !

Ton jeu me fait penser à un jeu master system : action fighter.

Le jeu a un bon principe avec arme, changement de modèle de voiture

version master system.


version amiga


version arcade

[vincent2105]

@pckid, merci pour tes encouragements Bon, mon jeu sera beaucoup plus simple, d'ailleurs il n'y aura même pas de camion (vu qu'il n'apporte rien de plus qu'une voiture qui roule à la même vitesse).

Sinon, ça avance

Ce qui est fait :

- un sprite de voiture. En modifiant son attribut à chaque fois qu'une voiture apparait, j'obtiens une voiture de couleur différente (4).
- un chronomètre. Pour cela je l'incrémente de 2 centièmes de secondes par frame. 
- une routine qui permet d'éviter automatiquement les voitures. Je l'utilise principalement pour l'adversaire "CPU", mais aussi lorsqu'une course est terminée afin de garder les bolides en mouvements pendant l'affichage du message "winner"
- pas mal de bidouilles : impossibilité de se faire rentrer dans le derrière si on est en phase d'accélération, une seule voiture concurrente sur la même voie etc...
Hier au cours de mes tests, femme et enfants se sont joints à moi pour une dizaine de courses. C'était bien sympa !

A+

[Invité]

Que de progrès depuis tes débuts en ASM !! :)
On peut y jouer à deux, puisque je vois un split screen ?

[Invité]

Sympa comme jeu, et comme le souligne vetea on voit les progrès 

[vincent2105]

Merci les amis

On peut y jouer à deux, puisque je vois un split screen ?

 En effet. Les 2 parties de l'écran sont "indépendantes" (les routes défilent en fonction de la vitesse de chaque voiture)... D'ailleurs l' écran est splitté que ce soit à 1 ou 2 joueurs. Dans le premier cas, le joueur défie une voiture contrôlée par le cpu.

Il me reste beaucoup à faire (powerups, un menu, des ajustements etc) mais j'ai envie de nouveauté alors je vais étudier l'APU (Audio Processing Unit), toujours avec les tutos "nerdy nights sound" http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=7155
 

[vincent2105]

Bonjour à tous, me revoilà ! 

J'entre dans le vif : depuis mes débuts, je ne m'occupais aucunement de la taille de mon programme une fois assemblé. Depuis un petit moment, je me demande comment "la calculer"...

J'ai bien trouvé la liste des opcodes du 6502 ainsi que "leur taille" qui varie selon le mode d'adressage utilisé (de 1 à 3 octets).  http://www.6502.org/tutorials/6502opcodes.html

Question : s'agit il de la taille de l'opcode seul, ou de l'opcode + valeur associée ? Après un test rapide sur cet émulateur https://skilldrick.github.io/easy6502/ , je pense qu'il s'agit de la seconde possibilité, mais dans ce cas, j'aurais une ou deux questions... Merci par avance :)

[vingazole]

Question : s'agit il de la taille de l'opcode seul, ou de l'opcode + valeur associée ? Après un test rapide sur cet émulateur https://skilldrick.github.io/easy6502/ , je pense qu'il s'agit de la seconde possibilité

Oui, c'est bien la taille de l'opcode + celle de la valeur associée.

[vincent2105]

Ok, mais je passe à côté de quelquechose :/  
Dans le cas d'un adressage absolu indexé ( $aaaa, Y ), je ne comprends pas comment ce qui suit l'opcode tienne sur 2 octets seulement après avoir été assemblé. 
J'espère me faire comprendre...

[vingazole]

C'est seulement la valeur $aaaa qui est codée sur les 2 octets (en little endian) : l'opcode implique que tu indexes avec le registre Y (il y a vraisemblablement un champ de bits dans l'opcode pour indiquer que c'est X ou Y qui est utilisé).

[vincent2105]

Merci Vingazole, tes explications sont toujours aussi claires   et une fois qu'on a compris, on se sent bien bête

[vincent2105]

Salut,
 
Dans ma routine "ROUTINE_ChoixSpriteaCharger", je tente en vain de  remplacer "liste_metasprites_0", par un pointeur qui me permettrait de choisir une liste de metasprites au sein de "LISTE_LISTES_METASPRITES"... Après avoir pas mal réfléchi, j'en viens à me demander si c'est faisable...
Merci par avance

Spoiler:

[Invité]

Alors les pointeurs sont obligatoirement des variables en zero page .

.zp 
   pointeur_vers_table:     .ds 2        ; On réserve 2 octets pour un pointeur

; On l'initialise le pointeur avec l'adresse du tableau
lda #LOW( liste_metasprites_0 )
sta <pointeur_vers_table
lda #HIGH( liste_metasprites_0 )
sta <pointeur_vers_table +1

; pour lire le contenu de ton tableau via ton pointeur
ldy #00
lda [ pointeur_vers_table ] , Y  ; On récupère le contenu de l'adresse stockée dans pointeur_vers_table, indexé par Y

; tu incrémentes ensuite Y pour lire la suite de ton tableau

Comme je connais pas la syntaxe de ton assembleur donc faudra adapter.
< = variable en zero page
#LOW() = récupère l'adresse low de ta variable entre crochets
#HIGH() = récupère l'adresse high de ta variable entre crochets

Attention c'est différent de liste_metasprites_0 et liste_metasprites_0 + 1 .


C'est d'ailleurs pour ça que ça ne marche pas ici  :

lda  liste_metasprites_0 , X               
  sta  PTR_sprite_a_charger
  lda  liste_metasprites_0 + 1 , X
  sta  PTR_sprite_a_charger + 1 

ici tu prends la valeur du tableau liste_metasprites_0 indéxée par X, et non l'adresse du tableau .


Si liste_metasprites_0 est initialisé comme ça par exemple:
liste_metasprites_0:   .db 40,10,5,6,17,33,42

Alors 
lda  liste_metasprites_0 , X    ; On suppose que X=0

le REG A aura comme valeur 40 et non la partie LOW de l'adresse de ton tableau .

[vincent2105]

Là, je ne comprends plus, j'ai peut-être mal exposé mon problème aussi ... 
En fait ma question pourrait directement suivre celle que j'avais posée il y a un moment (choisir une palette de couleur au sein d'une liste de palettes de couleur)...
Voici la réponse de Vingazole avec laquelle tu étais d'accord (page 4, 30 octobre 2014)  

Spoiler:

A présent, je ne souhaite plus choisir ma palette dans une unique liste de palettes mais au sein d'une liste de palettes elle même comprise dans une liste du genre :

Spoiler:

Autrement dit, je souhaite pouvoir choisir une liste dans "LISTE_listes_palettes", puis, choisir une palette au sein de la liste choisie... 
Je sais pas si je me fais comprendre...

PS : dans mon précédent message le label "liste_metasprite_0" précédait des .dw et non des .db , mais peut-être était-ce juste pour l'exemple que tu as utilisé des .db ? J'avoue que je m'embrouille un peu 

[Invité]

être était-ce juste pour l'exemple que tu as utilisé des .db ? J'avoue que je m'embrouille un peu  

Oui c'était pour l'exemple, dsl si je t'ai embrouillé 

Sinon effectivement, en regardant de plus prêt ton code, ça semble correct ..

Le seul souci qu'il me semble voir c'est que:
.dw sprite_ennemi_0 ne te renvoie pas l'adresse du tableau sprite_ennemi_0 , ou que  metasprite_index ait une valeur pourrie qui te fasse pointer n'importe où. 

As tu un fichier assemblé intermédiaire qui te donne plus d'infos ??

PS: Ce que tu demandes de faire et tout à fait faisable et classique comme démarche, le 6502 sait très bien gérer les pointeurs, et même des pointeurs indexés,le tout est de savoir comment ton compilateur interprète des trucs style:
.dw mon_tableau (par exemple).

[vincent2105]

Merci pour ton aide Touko
Qu'on soit bien d'accord, le bout de code de Vingazole fait ce qu'on attend de lui...
Si je l'utilise pour charger un metasprite parmi une liste de metasprites, il n'y a aucun problème

Spoiler:

Pour ne pas polluer le code de bidouillages, je l'avais laissé tel quel en demandant juste comment procéder pour choisir parmi une liste de listes...
J'ai donc créé plusieurs listes de metasprites et une "liste de listes"
J'imaginais la solution suivante, mais ça ne me retourne pas le resultat escompté (en bleu les modifications apportées au code de Vingazole) :

Spoiler:

[Invité]

Ah ok, je comprends .
Pour que ça marche, après

Code:

LDA  ZPPTR_liste_listes_sprite , X                 [size=14][/size]
  STA  ZPPTR_liste_sprite                     [size=14][/size]
  LDA  ZPPTR_liste_listes_sprite + 1 , X             [size=14][/size]
  STA  ZPPTR_liste_sprite + 1    

il faut faire

Code:

LDA  [ ZPPTR_liste_listes_sprite ]                 [size=14][/size]
  STA  ZPPTR_liste_sprite                     [size=14][/size]
  LDA  [ ZPPTR_liste_listes_sprite + 1 ]            [size=14][/size]
  STA  ZPPTR_liste_sprite + 1    

Si je me suis pas trompé, tu vas récupérer l'adresse d'une de tes listes de sprites   

Donc là tu devrais récuperer les bonnes valeurs avec
lda [ ZPPTR_liste_sprite ] , X

[vingazole]

Pas sûr que son assembleur accepte les balises [size]...

[vincent2105]

Pour que ça marche, après
CODE:

Code:

LDA  ZPPTR_liste_listes_sprite , X                 
  STA  ZPPTR_liste_sprite                     
  LDA  ZPPTR_liste_listes_sprite + 1 , X             
  STA  ZPPTR_liste_sprite + 1    

il faut faire
CODE:

Code:

LDA  [ ZPPTR_liste_listes_sprite ]                 
  STA  ZPPTR_liste_sprite                     
  LDA  [ ZPPTR_liste_listes_sprite + 1 ]            
  STA  ZPPTR_liste_sprite + 1    

Tu voulais pas plutôt dire : "au lieu de" ? 

Sinon, j'ai eut le message "incorrect adressing mode", j'ai donc remplacé les crochets par des parenthèses, mais je n'obtiens toujours pas ce que j'attends... 
Si c'est correct, j'ai lu que la seule instruction à utiliser l'adressage indirect absolu ($aaaa) était JMP.

Désolé de t'avoir embarqué dans ma galère