Re: MEGADRIVE vs SUPER NINTENDO : Fight !

[Nikeleos]

changer la couleur de fond avant et après ta routine, c'est pas précis, mais ça permet d'avoir un rapide aperçu pour la charge CPU

Euh... Qu'est-ce que c'est censé montrer ???

[Invité]

Et bien la charge CPU pour la routine/partie que tu veux tester,ce sera peut être plus explicite avec ça:

à droite les couleurs indiquent le CPU utilisé pour les fonctions/parties du moteur,le calcul se fait en lignes raster consommées,donc si tu sais combien de cycles CPU tu as par ligne de raster, tu arrives à connaitre la charge CPU .

[Nikeleos]

Ah... C'est comme des balises qu'on placerait avant et après chaque fonction ! Du coup quand ces balises de couleur bougent, on sait que telle ou telle fonction a mis plus de temps à passer.

[Tryphon]

Exactement. Ça prend peu de temps donc ça fausse peu les mesures.

[Invité]

Non mais je trouve cette techniquement complètement nulle

Je suis désolé mais un % CPU sera toujours plus parlant :




(Oui j'adore les shmup ).

Là on sait combien ça prend de % CPU , 50% ,22% c'est des choses parlant
Le SGDK intègre un % CPU maintenant (mais je dois avoir du code asm pour megadrive pour connaître le %CPU).

La RAM si tu codes en ASM, tu connais la ram utilisée vu que tu alloues toi mêmes la mémoire, sinon souvent le SDK peut avoir une fonction te donnant l'info .

Exact , mon SDK pour la Neo Geo t'indique la RAM restant (c'est facile à connaître , c'est entre la dernière variable global ou malloc que tu fais est le stack  ).
En asm , sauf si tu code comme un porc techniquement  tu sais combien il te reste

[Invité]

Et les gars on va par faire un VS sur la charge du CPU qd même ?? si ? 
Plus sérieusement oui la technique de kannagi est surement meilleure, celle de la couleur et la plus simple à faire, mais donne une approximation .

[Tryphon]

Comment tu peux connaître un % CPU précisément ?

[Invité]

Je dirais en incrémentant un compteur en attendant le vblank, tu connais les cycles que prend l'incrément donc tu peux en déduire le nb de cycles qu'il reste dans la frame en fonction du nb d'incréments fait .

Ou avec un timer si la machine en a un .

[Tryphon]

Oui, mais tu peux pas distinguer quelle routine prend quel %

[Invité]

Non, du moins je sais pas faire pour faire ça .

[Invité]

Comment tu peux connaître un % CPU précisément ?

Pour la SNES ,MD et NG , tu as une I/O qui t'indique où se trouve l'affichage donc tu le fais juste avant d'attendre le VBlank et tu as un % CPU assez précis

Sinon si cette I/O n'existe pas (ce qui peut arriver) , il faut faire une boucle d'incrémentation pendant l'attende du Vblank , et donc comparé la charge "pleine" et la "charge à vide" , la méthode peut être assez précise si on fait quelque test pour bien ajuster la valeur(entre la charge vide et pleine j'entends )

Et les gars on va par faire un VS sur la charge du CPU qd même ?? si ?

ça manque de VS en ce moment

[Tryphon]

Oui mais du coup comme je demandais à Touko, tu peux pas forcément savoir quelle partie de ton code prend du temps ?

[Invité]

ça manque de Vs en ce moment 

[Invité]

Oui mais du coup comme je demandais à Touko, tu peux pas forcément savoir quelle partie de ton code prend du temps ?

Tu as deux façon soit en lisant l'I/O avant et après l'appel de la partie du code que tu veux voir.

Soit en l'enlevant et la comparant avec la charge pleine , si t'es as 25% et que t’enlève la fonction X ,et que tu tombe à 20% , ça va pas être trop dur pour savoir combien elle prend
(c'est la méthode que j'utilise le plus souvent vu que ça prend 5seconde ,de mettre en commentaire une fonction et de relancer ta rom)

[Invité]

ça manque de Vs en ce moment 

On peut faire un SNES/MD Vs Archimèdes si vous êtes tant en manque

[Invité]

nah, on va pas foutre la merde ici, c'est déjà le bordel sur la partie micros .

[Invité]

Quand je lis ça ,c'est là que je me dis , "J'aime pas les marmottes ! "

nah, on va pas foutre la merde ici, c'est déjà le bordel sur la partie micros .

ah bon ?
bon c'est vrai ça parle de l'archimedes partout même quand y'en as pas

[Invité]

nah, on va pas foutre la merde ici, c'est déjà le bordel sur la partie micros .

Avoue que tu rêve d'un débat Archiforever Vs Lémurien, pour la science

[Nikeleos]

Non mais je trouve cette techniquement complètement nulle

Je suis désolé mais un % CPU sera toujours plus parlant :




(Oui j'adore les shmup    ).

Là on sait combien ça prend de % CPU , 50% ,22% c'est des choses parlant
Le SGDK intègre un % CPU maintenant (mais je dois avoir du code asm pour megadrive pour connaître le %CPU).

La RAM si tu codes en ASM, tu connais la ram utilisée vu que tu alloues toi mêmes la mémoire, sinon souvent le SDK peut avoir une fonction te donnant l'info .

Exact , mon SDK pour la Neo Geo t'indique la RAM restant (c'est facile à connaître , c'est entre la dernière variable global ou malloc que tu fais est le stack  ).
En asm , sauf si tu code comme un porc techniquement  tu sais combien il te reste

C'est ta tentative de Manic Shooter dont tu parlais ?

[Tryphon]

Oui mais du coup comme je demandais à Touko, tu peux pas forcément savoir quelle partie de ton code prend du temps ?

Tu as deux façon soit en lisant l'I/O avant et après l'appel de la partie du code que tu veux voir.

Soit en l'enlevant et la comparant avec la charge pleine , si t'es as 25% et que t’enlève la fonction X ,et que tu tombe à 20% , ça va pas être trop dur pour savoir combien elle prend
(c'est la méthode que j'utilise le plus souvent vu que ça prend 5seconde ,de mettre en commentaire une fonction et de relancer ta rom)

Ça me paraît quand même pas très pratique. Plein de fonctions X ont des conséquences sur le temps d'exécution d'une fonction Y...

[Invité]

C'est ta tentative de Manic Shooter dont tu parlais ?

Oui c'est ça sur SNES (le second et un test rapide sur Neo Geo , on voit la dif je pense ).

Ça me paraît quand même pas très pratique. Plein de fonctions X ont des conséquences sur le temps d'exécution d'une fonction Y...

Cela peut arriver oui , Mais une approximation me suffit en général , si tu veux effectivement connaître de façon plus exact , ben go la solution numéro 1 (vu que t'es sur MD et donc le hardware t'indique où se trouve l'affichage quand tu veux )

[Nikeleos]

Et sinon, pour les maitres du hardware, j'ai lu pas mal de choses concernant la comparaison entre le proc de la MD et celui de la SNES. Apparemment le 65816 pourrait "pusher" plus d'opérations en moins de temps mais serait handicapé par son bus 8 bits et que parallemement le 68k serait plus puissant pour certaines opérations plus complexes...
Quelqu'un pourrait apporter la lumière sur ce problème avec des mots simples, genre si vous aviez Dumb et Dumber en face de vous ?

[Invité]

En gros ce que tu dis c'est :
le 65816 les instructions prenne pas beaucoup de cycle , les lectures RAM en 16 bits prenne 1 cycle de plus que leur version 8 bits.
Le M68000 est effectivement un processeur bien plus complet et donc oui , certaine opération seront bien plus facile/optimisable sur le M68000 (et les lecture 8/16 bits prenne le même taux de cycle).

Mais on ayant codé sur les deux (65816 et M68000) ce n'est pas ça la dif entre la MD et la SNES  niveau CPU.
La dif c'est surtout ben que le processeur de la MD est plus rapide et plus facile à codé.

J'ai montré sur ma démo que c'est tout à fait possible de faire un shmup optimisé sur SNES avec 100 bullets et plus de 200 test de hitbox par frame donc le proc on a sous le capot

Mais la grosse dif que j'ai senti entre les deux c'est clairement , pour optimiser les bullet dans un shmup , ben sur le M68000 cela m'a pris quoi , un aprem pour coder ça de façon optimisé ? (en asm )
Que t'as un excellent compilo qui te permet pas de tout codé en asm.

Sur SNES cela m'a pris plusieurs semaine pour avoir les optimisation au max . et tu dois tout gérer en asm pour garder des perfs correct

[Invité]

Si tu veux vraiment connaître la dif entre la MD et la SNES , je l'ai deja répondu ici , mais je le reposte parce que le CPU ça reste pour moi une petite partie de la dif :

On général on considère que la MD à une puissance de 1,33 MIPS et la SNES 1,1MIPS ( pour moi elle est à 1 MIPS ).
MIPS pour Millions instruction par seconde , en gros la MD c'est 30-35% plus rapide qu'une SNES (sans la difficulté de prog derrière) , parce que oui le 65816 + le hard de la SNES rend la dif plus grande (40-45% ? ).
Bien sur en FastRom la dif est bien moindre (on gagne 15% de vitesse comparé en SlowRom sur SNES ).

On a sur MD 4 palettes sur 512 couleurs disponibles.
(il y'a une astuce pour changer de la palette en cours , donc qui augmente le nombre de couleur à l'affichage, mais c'est une astuce assez limité).
Sur SNES tu as 16 palettes de 32768 couleurs.

La SNES à un BG supplémentaire comparé à la MD.
La gestion des Sprites sur MD est plus modulaire et rapide que la SNES.
(gérer beaucoup de Sprites sur SNES à un gros coût CPU + que le CPU de base est moins puissant).

La limite de sprite sur SNES et MD sont différent :
la SNES c'est 272 pixel/ligne ou 30 sprite par ligne.
la MD c'est 320 pixel/ligne ou 20 sprite par ligne

La MD à un gros avantage sur les SFX , vu que tu peux jouer des SFX de la taille que tu veux , sur SNES , tu sera tjs limité par la RAM du SPC700 soit 64ko (et dans les fait bien moins vu que c'est une RAM partagé ).
ce qui permet à la MD d'avoir des SFX de meilleurs qualité que la SNES (et bien plus nombreux aussi).

Sur SNES tu as plein d'effet hard disponible , le mode7/HDMA , la transparence entre autre.
Tu as aussi plus de RAM disponible sur SNES  (128 ko de RAM contre 64 ko sur MD ) qui peut aider pour la décompression des données.

Tu aura un peu plus de VRAM sur SNES que la MD (qui en profitera principalement sur le BG).
La MD n'a aucune limite pour les sprites en VRAM , donc tu peux avantagé les sprites affichable au détriment du BG , ce qui est impossible sur SNES vu que les sprites sont limité à 16ko en VRAM.

Voilà de tête les grosse dif MD/SNES.

[Invité]

Et la supergrafx(je voulais mettre l'archimedes mais j'ai pas osé) est là pour les diriger toutes !! 

[Nikeleos]

Kannagi, je te remercie pour ces précisions. J'en prends bonne note.

[Invité]

Au moins tu n'auras pas d'infos biaisées de fanboys 
Et pour des infos plus poussées n'hésites pas non plus .

[Invité]

Au moins tu n'auras pas d'infos biaisées de fanboys 

cette perche

[Invité]

Nah je suis de bonne foi  ,tu imagines si il fait son éducation sur le site sega-retro ??

[Tryphon]

La limite de sprite sur SNES et MD sont différent :
la SNES c'est 272 pixel/ligne ou 30 sprite par ligne.
la MD c'est 320 pixel/ligne ou 20 sprite par ligne

Ça veut quand même dire que la SNES peut afficher plus de sprites que n'en contient sa ligne. Ça donne quoi en mode haute résolution (512) ?

[Invité]

Les sprites en Hi-res restent en low res, donc je pense que la limite ne change pas .