Re: MEGADRIVE vs SUPER NINTENDO : Fight !

par upsilandre Mer 3 Juin 2015 - 23:10

TOUKO a écrit:Et ils ont fait comment sur MD ???
ils ont utilisé des tiles ..

Oui grace a un poteau de guillotine simplifié avec des contours droit sans transparence, du coup c'est facile ils ont besoin d'une seul version des tiles du poteau du fond pour l'intégrer dans le background.
La version sgx reproduit les graphismes arcade.

par upsilandre Mer 3 Juin 2015 - 23:18

TOUKO a écrit:Non mais sérieux, t'es gonflé, je te dis la même chose depuis le début,que tout est sur le même VDC sur ce passage, et tu me soutenais que non, en me parlant de zombies, moi je t'ai toujours dit la même chose, joueur, guillotines, oiseaux de l'arbre même VDC=clignotements, rien de plus .
Si tu as voulu comprendre autre chose, c'est pas de ma faute .

bon je suis obligé de te quoter.

TOUKO a écrit:
Je me suis refais encore une partie (je l'ai peut etre pas dit ici mais je suis gros fan des Makaimura, c'est mon jeu d'arcade préféré) et a titre indicatif la guillotine est dans le VDC2, alors oui c'est la que se trouve le sprite du joueur mais dans le VDC1
Les premières oui, mais pas celle après l'arbre où sont les oiseaux et qui clignotent
Là tu as le joueur, les tirs, les oiseaux et les guillotines sur le même VDC

2 erreurs en 2 lignes.
Tu affirmes que les guillotines dont tu parles sont pas dans le meme VDC que celle d'avant: Faux (ce qui m'a envoyer ailleurs)
Ensuite tu affirmes que les tirs (la plus grosse charge du jeu) sont dans ce meme VDC: Faux.

Le message suivant du réitere en affirmant que tout est dans le meme VDC ce qui est culoté quand les 2 grosses charges, tires et zombie sont dans l'autre (+ un bout de hud genant) qui est donc deja bien occupé et que j'ai meme accompagné mon propos de chiffre concret (j'ai fais l'effort)
Je pense que tu réalise pas que t'es compliqué a suivre.

par Invité Mer 3 Juin 2015 - 23:28

Ils pouvait même déporter la partie poteau foregnd (peut être la lame aussi) sur le VDC0 (ou 1 si tu préfères), et laisser le reste sur le VDC1 (ou 2) .

Donc y'a toujours des solutions .

2 erreurs en 2 lignes.
Tu affirmes que les guillotines dont tu parles sont pas dans le meme VDC que celle d'avant: Faux (ce qui m'a envoyer ailleurs)

Mais arrêtes de chercher la petite bête pour essayer de retomber sur tes pâtes, ce qui nous concerne c'est la partie ou ça clignote non ??
Donc au niveau de l'arbre avec tout les oiseaux, et les guillotines je me requote encore :

LE JOUEUR + LES GUILLOTINES + LES OISEAUX QUI SONT TOUS DANS L'ARBRE SONT SUR LE MEME VDC, c'est pour ça que ça clignote, ce qui clignote ce sont justement les sprites de ce VDC.

Voilà le problème, que le reste soit sur l'un ou l'autre ou inversement on s'en fou, ça clignote pas .
Donc y'avait plein de solutions pour remédier au problème, mais voilà ça clignote peu donc ça passe, fin de l'histoire .

par upsilandre Mer 3 Juin 2015 - 23:46

Ce a quoi j'avais deja repondu dès le debut avant meme que tu t’emmêles les pinceaux, y a rien d'illogique a cette répartition, l'autre VDC a aussi son boulot.
Alors toi tu fais une fixation sur cette scene (sans considérer qu'ils prennent tout le level en compte) donc idéalement c'est les oiseaux qu'il aurait fallu repartir sur 2 VDC (car a eux seuls ils font saturer un VDC avec leur plume quand ils meurent, la guillotine n'y change rien, suffit de faire l'experience sur la grosse) mais le vautour c'est le plus gros pool VRAM ce qui est un gros probleme pour le dupliquer (d'autant que dans l'autre y a les zombies, l'autre gros consomateur de VRAM avec le vautour car tres bien animé aussi).
Donc il aurait vraiment fallu se casser la tete au niveau VRAM ou animation de tile juste pour cette scene de 3 metres. Ils vont pas se casse la tete au cas par cas sur chaque metre du jeu, idéalement ca serait bien mais par sur un petit jeu de lancement comme ca. Ils ont deja fait pas mal d'effort, plus que je l'imaginais avant de me pencher dessus (et ce que tu dis illustre bien la galère de ces layers de sprite)

par Invité Mer 3 Juin 2015 - 23:48

Bon ok laisses tomber ..

par upsilandre Mer 3 Juin 2015 - 23:51

Je crois surtout qu'on a floodé comme des porcs. Merci les congés study

par Invité Mer 3 Juin 2015 - 23:57

Bah si on peut plus débattre alors mince Wink

par upsilandre Jeu 4 Juin 2015 - 0:02

Seul la modération a la légitimité pour trancher.
Alors fessé ou pas fessé? MEGADRIVE vs SUPER NINTENDO : Fight ! - Page 16 Icon48

par Invité Jeu 4 Juin 2015 - 0:05

lol,ici tant que les discussions restent entre personnes respectueuses de l'autre y'a pas de soucis .

par Stef Jeu 4 Juin 2015 - 0:06

Sans vouloir te contrarier Touko je comprends pas trop pourquoi tu le prends ainsi... J'ai suivi la conversation depuis le début il a effectivement dit (depuis le début) que les guillotines, les oiseaux et le perso principaux étaient rendu via un même VDC... et il a expliqué pourquoi : l'autre VDC gère les zombie et les tirs ce qui représente aussi une charge importante.
Il est évident qu'ils ne vont pas changer la balance des VDC juste pour un endroit précis surtout que c'est probablement pas vraiment possible (limitation en VRAM). Du coup je ne vois pas en quoi tu n'es pas d'accord avec ces arguments qui sont, au contraire, plutot convainquant non ?
Toi tu te contentes de dire que ça clignote parce-que y'a tels type de sprite rendu par un même VDC... certes, mais dans ce cas dis-nous comment techniquement et de manière réaliste tu aurais équilibré les VDC pour que ça ne clignote pas ?

par Invité Jeu 4 Juin 2015 - 0:13

les oiseaux et le perso principaux étaient rendu via un même VDC... par contre il a expliqué pourquoi ! L'autre VDC gère les zombie et les tirs ce qui représente aussi une charge importante.

Juste que j'explique simplement comment y remédier,et j'ai l'impression de parler à un mur, mais bon je dois pas savoir de quoi je parle .
Je fais qu'expliquer aussi que si ils sont dans cette situation,c'est aussi un problème de design au niveau de la répartition des sprites dés le départ, donc je discute plus sur ce point .

Donc vous voulez que GnG sur SGX soit optimal et que les clignotements ne pouvaient pas être évités parce que 512 pixels sprites c'est peu en fait,128ko de VRAM c'est trop juste, ok je discute pas, vous êtes les pros de cette machine après tout,et vous savez comment optimiser ou pas tout ça .

certes, mais dans ce cas dis-nous comment techniquement et de manière réaliste tu aurais équilibré les VDC pour que ça ne clignote pas ?

Rien que de passer le poteau de la guillotine qui doit être devant le joueur sur le VDC0 suffit .
Stef va te trouver toutes les optimisations possibles si on parlait de la Md, mais sur SGX, c'est clair on pouvait pas faire autrement . Razz

par upsilandre Jeu 4 Juin 2015 - 0:13

Zut, on y etait presque, on avait réussit a passer a autre chose What a Face

Je pense que ca reste le bon moment (pour passer a autre chose), j'ai la foi, j'y crois sunglass

par upsilandre Jeu 4 Juin 2015 - 0:22

D'ailleurs j'ai des questions sur la SNES.
j'ai du mal a comprendre les switch de fréquence, mode normal 2.68mhz, mode highspeed 3.58mhz en fonction du type de mémoire.
Apparemment ca switch automatique selon la plage mémoire adressé? mais en interne ca se passe comment? quand on utilise des instructions cpu qui ne font pas appelle a une mémoire ca tourne a 3.58mhz ou ca depend du dernier acces mémoire?
Et le 2.68mhz ca concerne la RAM, le DMA et certaine ROM? (dans quelle proprtion a peu pret, y a beaucoup de jeu qui utilisent des ROM low frequence ou c'est anecdotique?)
En gros est ce que le 3.58mhz est tres peu présent a l'usage ou est ce qu'il est tres présent?

par Invité Jeu 4 Juin 2015 - 0:28

Oui, le cpu fonctionne @3,58 pour les accès ROM si c'est de la fastrom, mais les accès à la ram sont toujours à 2,6, peut importe la vitesse de la rom .
Le DMA c'est toujours 8 master cycles / octets copiés, donc toujours à 2,6 mhz,même pour des transferts à partir de fastrom .

En gros est ce que le 3.58mhz est tres peu présent a l'usage ou est ce qu'il est tres présent?

Oui juste pour les accès à la rom si c'est de la fastrom .
Ce qui fait qu'avec de la fast rom le CPU tourne en moyenne à 3mhz .

par upsilandre Jeu 4 Juin 2015 - 0:34

Ok, ca c'est plutot la partie que j'avais assimilé, j'aimerais surtout savoir si on sait comment ca se passe en interne (pour les instructions sans acces mémoire, c'est highspeed par defaut ou plutot la fréquence du dernier acces mémoire?) et si on a une idée de la proportion de jeu qui ont de la fast ROM? (parce que j'ai vraiment aucune idée, je sais pas si c'est 5% 20% 50% 80% 98%)

par Invité Jeu 4 Juin 2015 - 0:38

Oui, si tu touches pas à la ram c'est fullspeed .
Par contre la proprotion de jeux en fast je la connais pas, faudrait que tu ailles sur le site nesdev, ils te renseigneront :
http://forums.nesdev.com/viewforum.php?f=12

par upsilandre Jeu 4 Juin 2015 - 0:38

Ok merci

par Invité Jeu 4 Juin 2015 - 0:39

upsilandre a écrit:Ok merci

De rien, tu pourras leurs poser des questions techniques plus poussées sur la snes,si tu veux vraiment savoir ce qui est faisable ou pas .

par upsilandre Jeu 4 Juin 2015 - 0:40

J'ai du mal a imaginer comment le CPU switch d'une instruction a l'autre.

par Invité Jeu 4 Juin 2015 - 0:46

Là je sais pas, peut être via des waits states .

par upsilandre Jeu 4 Juin 2015 - 0:48

ouai doit y avoir la master clock derrière qui permet ca.

par Invité Jeu 4 Juin 2015 - 0:50

je sais que le type de rom est dans l'entête en début de programme .

par upsilandre Jeu 4 Juin 2015 - 1:07

Tu parles de header pour l'emulation? (facon NES, je connais par coeur le header des fichiers NES, ca me permet en un clic de savoir quelle est le type de mapper et la répartition entre PGR-ROM et CHR-ROM) ou c'est un header qui fait vraiment partie de la cartouche? (car je crois pas qu'il y a de header pour l'emulation?)

par Invité Jeu 4 Juin 2015 - 1:21

Non du header de chaque programme dans les roms snes .

par Invité Jeu 4 Juin 2015 - 7:46

upsilandre a écrit:Seul la modération a la légitimité pour trancher.
Alors fessé ou pas fessé?

$I don\'t want that$

par Stef Jeu 4 Juin 2015 - 8:58

Touko>Franchement je tape assez rarement sur les développeurs et quand je le fait c'est qu'il y a de bonnes raisons (genre sf2 sur MD).
Je sais a quel point il y a une différence entre faire une démo concept et un jeu complet... Au début tu disais que GnG exploitait très mal la SGX, au point qu'il s'agissait presque d'une version programmee pour une PCE. Au final on se rend compte que le jeu tire bien partie des capacités de la SGX même si y'a toujours moyen de faire mieux.
Pour le CPU de la Snes, j'imagine que sa clock est directement "relié" au bus qu'il exploite a un moment T:
un fetch en Fast rom = clock Fast = master / 6
une lecture / écriture wram = clock wram = master / 8

par Invité Jeu 4 Juin 2015 - 9:19

Stef, j'ai pas dit qu'ils étaient mauvais ou un truc du genre, la conversion est bonne, mais les clignotements peuvent être évités .
Y'a un gaspillage de BP évident .

Tu as largement de la place en VRAM sur le VDC0 pour y mettre une partie de la guillotine, c'est un fait, sans chercher plus loin si l'organisation des données est bonne ou pas .

Quand tu sais que tu dois avoir plein d'éléments sur la même ligne, tu réparties les sprites, c'est comme ça que ça marche, dire qu'ils n'auraient pas pu faire mieux, c'est n'importe quoi, ou alors ça veut aussi dire que la version MD n'aurait jamais pu éviter des clignotements plus important que la SGX si la version avait été du même niveau,et aurait été impossible à faire, si la VRAM de la SGX est bien utilisée, la Md avec ses 64 ko aurait été à l'étroit .

Au final on se rend compte que le jeu tire bien partie des capacités de la SGX même si y'a toujours moyen de faire mieux.

Oui et je confirme, avec plus de place une version arcade perfect était parfaitement possible .
Et je suis sur que si le jeu avait été développé entièrement sur PCE, les devs auraient maximisé l'utilisation des sprites et de la VRAM, là ils ont utilisé la console mais en faisant le minimum syndical et en gâchant pas mal de ressources.
Je pense pour bcp le manque de temps, et parce qu'il fallait sortir un premier vrai jeu au plus vite, battle ace ne cassait pas des briques .
De plus les codeurs de GnG (nec avenue) ne sont pas réputé pour la qualité de leur code, ils ont apparemment pas une bonne réputation chez les fans de la nec .

par upsilandre Jeu 4 Juin 2015 - 12:05

Toujours pas d'accord avec tes propos que je trouve toujours dans une forme d'exagération de principe

.
Non ils ont pas fait le minimum syndical, ca se voit sur plein de petits détails de gestion que j'ai evoqué et que tu occultes mais qui montre quand meme une vrai réflexion et optimisation (plus que sur 1941) meme si c'est un travail plus globale que tu ne le voudrais (pas sur chaque metre du jeu).
Et non tu peux pas faire une version arcade perfect, le boss du nuage qui est bien optimisé sur sgx le démontre, on peut meme faire un bete calcule ca passe pas meme en théorie. Y a certain passage arcade qui sont trop lourd en spps (normal vu le potentiel du CPS1 bien au dessus) t'es obligé de faire des petits downgrades (meme si discret).
mais bon de toute facon est ce qu'on peut parler de arcade perfect si la résolution est pas la meme? (moi je dirais oui pourquoi pas si on a tous les pixels, c'est juste qu'on a une sorte de zoom horizontal et qu'on perd un bout du champ visuel sur les cotés)

par upsilandre Jeu 4 Juin 2015 - 12:15

Stef a écrit:Touko>Franchement je tape assez rarement sur les développeurs et quand je le fait c'est qu'il y a de bonnes raisons (genre sf2 sur MD).
Je sais a quel point il y a une différence entre faire une démo concept et un jeu complet... Au début tu disais que GnG exploitait très mal la SGX, au point qu'il s'agissait presque d'une version programmee pour une PCE. Au final on se rend compte que le jeu tire bien partie des capacités de la SGX même si y'a toujours moyen de faire mieux.
Pour le CPU de la Snes, j'imagine que sa clock est directement "relié" au bus qu'il exploite a un moment T:
un fetch en Fast rom = clock Fast = master / 6
une lecture / écriture wram = clock wram = master / 8

on est d'accord.

par Invité Jeu 4 Juin 2015 - 15:52

Une petite trouvaille argonaut avait fait une petite demo de jeu 3D sur snes avant de faire le sfx .

C'est l'adaptation d'un jeu prévu pour la nes .

par upsilandre Jeu 4 Juin 2015 - 16:07

Je me souviens de cette histoire, il s'etait fait repérer en faisant de la 3D sur gameboy, je me souviens de la video gameboy mais je ne sais plus si j'avais deja vu cette demo SNES
Dommage on comprend rien. C'etait deja un proto de chip pour la SNES ou juste une demo software?
Vu la resolution et le framerate j'imagine software mais c'est pas mal pour de la SNES.