Re: Snes - megadrive - pc engine vs Neo geo

[Invité]

tu prends toujours plaisir a jouer a la néo surtout a deux car les jeux ont trop de punch comparé a toutes les consoles de salon au début des années 90 et comme tu le dis tu en prends pleins les yeux et les oreilles (faut pas oublier car la md...)

Je suis pas d'accord ,avec la Md aussi tu en prends plein les oreilles

[MikeeMike_2008]

c'est le barde qui a travailler sur copro sonore de la md

[Invité]

c'est le barde qui a travailler sur copro sonore de la md

Elle est excellente :thumright:

[Stef]

Je ne parlais pas du rideau qui s'elève mais de la tete de chat en rotation derrière, un peu comme le bateau après...

Mais j'avais bien compris, et c'est de ça que je te parlais .

Benc'est exactement le meme effet que le bateau pourtant... y'a le scroll vertical qui est utilisé pour la rotation et l'animation "molle" du visage.

Je vais pas me mettre à faire ça maintenant (a moins que tu fasse mon effet de feu ).

Hehe si tu veux je pourrais te le faire... une fois que j'aurais terminé ma démo.

Mais il me semble que dans le jeu cotton sur PCE, le premier boss fait ça ..
https://youtu.be/7eWWmKRYFGY?t=4m6s

Effectivementils ont essayé de simuler l'effet mais on fait que c'est fait à la main... Les parties supérieurs sont des sprites et ne suivent pas bien le sol qui utilise le plan avec des tiles dynamique. Mais on peut saluer l'effort quand même.
Le jeu est vraiment bien foutu, il simule souvent un 2eme plan avec les sprites, techniquement il est très interessant pour de la NEC, honnêtement plus que le jeu dont tu me parlais (rien que pour avoir
simuler cet effet déjà).

Sur PCE (et je pense sur MD aussi), c'est la couleur 0 qui est souvent changée sans soucis, par contre je suis sur qu'avec le timer on peu faire plus de choses .

Sur MD ce que font les jeux souvent c'est qu'il lance un DMA en CRAM à chaque scanline, donc tu peux modifier plus que ça. Mickey Mania va plus loin, il étend la zone HBlank pour augmenter le transfert par scanline.
Il doit modifier une palette complete plus la valeur de V Scroll pendant un seul H Blank, c'est sur cette phase :

https://www.youtube.com/watch?feature=player_detailpage&v=6JFYN7dvz3k#t=116s

En étendant la zone de HBlank le VDP n'a pas tout le temps nécessaire pour pré parser les sprites du coup ça diminue le nombre de sprites affichages par ligne à 10 mais ce n'est pas un soucis ici.

Euh non, justement il demande le taux de transfert du DMA de la MD, et on lui répond que c'est sur un autre topic, en lui disant bonne chance pour le trouver .
Là il revient avec le chiffre de 176 ko/s, et demande si le DMA de la SNES peut transférer à cette vitesse, et on lui dit que non ..
D'ailleurs même toi sur le chiffre de 176 ko, tu dis que sa te semble peu ,mais sans plus ..

Lis la suite, je dis qu'en effet 176 ko/s ça me semble faible pour de la SNES, et ensuite d'autre réponde que rien que pendant le VBlank tu peux transférer 800 Ko/s sur megadrive..

Oui je le fais pour mon jeu de karaté , l'intro de BB (ou j'utilise les 2 ),rien d'étonnant sur PCE.
Non du tout, ça pénalise rien, sauf les interruptions (qui sont bloquées pendant le transfert) si tu fais pas gaffe.
Donc dans un jeu je peux pas non plus transférer trop d'un coup si j'utilises les interruptions.
En moyenne c'est plusieurs fois des paquets de 100 ou 200 mots/frame..
Regardes les jeux PCE, t'as bcp de changement de patterns de sprites, de tiles à la volées.

Oui mais ces changements de tiles se font pendant le vblank je pense, après tu peux continuer en zone active mais ça doit être plus lent...
D'ailleurs en lisant quelques docs techniques de la PCE ça confirme ce que je pensais.
sur le VDC t'as un status register et comme sur MD t'as un busy flag pour dire que le VDC est occupé à traiter ta donnée en prédiode active :

http://cgfm2.emuviews.com/txt/pcetech.txt

Ca signifie bien que le VDC ne peut pas être écrit à pleine vitesse pendant la période active...

et j’apprends des choses interessantes avec ces docs
Déjà la taille des sprites est moins flexible que sur MD (par bloc de 16 pixels plutot que 8 pixels) et aussi que la limitation de 16 sprites par ligne fonctionne sur des sprites de 16 pixels de largeur uniquement, pour des sprites de 32 px on arrive à 8 sprites par ligne... Ca peut se comprendre car avec 8 sprites de 32px tu arrives déjà à 256 pixels... mais ça signifie que quelque soit la résolution, tu conserves cette limitation également, et ça pourquoi tant de jeux utilisent le 256 plutot que le 320 :)

Pareil, c'est le but d'un DMA, mais moi je peux compléter en plus vian le CPU hors vblank ..
Mais
bon tout dépend aussi de la complexité du jeu, si tu utilises fortement
les interruptions (timer Hsync), tu limites le taux de transfert ..

Oui sur 68000 puisque ce n'est pas une instruction de transfert tu évites ce problème :p

Sur et certain,tu as 3 resos, 256,320,et 512 ..
Mon premier essai de jeu,un remix de galaxian,est en 320 ..
https://youtu.be/pYE-UR1w3aI

En effet je viens de voir les docs qui confirment mais faut admettre que la plupart des jeux utilisent le 256 pixels, ce qui est dommage, le 320 c'est quand même plus fin, sympathique d'ailleurs ton petit galaxian :)

Non, car comment tu fais pour les faire exploser dans tout les sens sinon ??

Tu convertis le bloc en sprite au moment de l'explosion, ça se fait souvent pour faire un décor destructible, genre dans R-Type sur master system on la voyait déjà...

Bien sur c'est faisable en combinant tiles.sprites, mais tu alourdis fortement ton code pour gérer ça .

C'est le genre de détail ou tu vois les bons développeurs et les flemmards :p

Je pesne que les devs, on fait au plus simple, ça arrive jamais sur MD ??

Ca arrive mais dans ce cas pour moi le jeu n'est certainement pas une vitrine pour la machine. Cotton est plus interessant sur ce point. Comme je l'ai dit plusieurs fois, je le trouve pas si impression ton shoot :p Y'a de gros sprites, mais en quantité limité et parfois ça clignote ou rame... bref, c'est mal fini pour moi.

C'est impossible ce chiffre, tu me donnes les mêmes résultat que ton DMA, avec le 68000 .
Et je suis désolé mais ta fonction prend plus que 128 cycles ..
128 cycles c'est juste un movem de 60 octets sans compter l'init, les boucles ,etc ...
Surtout avec tes inits de 20 cycle tout les 60 octets + les boucles ..
Ta fonction je la fais comme suit sur le 6280

Code:


st0    #0      ( 4 cycles)
st1   #$00      ( 4 cycles)   
st2   #$00        ( 4 cycles)   
st0   #2      ( 4 cycles)   
st1   #$00      ( 4 cycles)
st2   #$00        ( 4 cycles)

tia  $0000,$0001,$100    ( 700 cycles)
Total = 724 cycles .


Donc j'initialise le VDC 1 seule fois ,puis le tia qui fait le transfert de blocs (ici de 100 octets), pas de boucles, rien de plus ..
Et c'est encore plus rapide en RAM, car j'aurai alors que le tia et 1 cycle en moins /octet .
Je doute fort que la fonction ClearBitmap plus haut fasse aussi bien,avec des boucles et en multipliant les movem.x à tours de bras ..
Car si j'ai bien compris pour faire tes 60 octets, tu boucles sur un movem.l non ??
Donc faut aussi prendre en compte les boucles, et pas seulement ce que prend movem.l * 100/4 !!
surtout que ca movem.l d0-d7/a0-a6, -(a7), j'aimerai bien savoir combien il prend ??
L'instaruction ne transfère que 30 octets non ?? (de d0 à d7, et A0 à A6, A7 est l'adresse de destination post décrémentée) c'est ça ??
Et je me demande comment tu fais pour trouver 128 cycles/60 octets !!!
Donc la fonction complète doit pas être loin des 900 cycles/100 octets (voire plus),car je suppose que les 68000 à des pénalités en écriture de VRAM ?? .

Chui pas convaincu ..

Mais bien sur car je compte en burst ! plus le fill sera grand et plus tu t'approcheras de ce débit, c'est toujours comme ça que l'on compte : en perf brute.
On s'en fout des fill de 4 octets, dans ce cas tu le fais en une seule instruction.
Là en gros, sur le bitmap en question on est proche de ce débit, je te détail le calcul :

Code:


    move.l  a7, usp  // 4
   
    moveq  #0, d0  // 4 * 15
    moveq  #0, d1
    moveq  #0, d2
    moveq  #0, d3
    moveq  #0, d4
    moveq  #0, d5
    moveq  #0, d6
    moveq  #0, d7
    move.l  d0, a0
    move.l  d0, a1
    move.l  d0, a2
    move.l  d0, a3
    move.l  d0, a4
    move.l  d0, a5
    move.l  d0, a6
   
    lea    (Bitmap+12288), a7  // 12

    rept    48
    movem.l d0-d7/a0-a6, -(a7)  // 8 + 8*15
    endr

    movem.l d0-d7/a0-a3, -(a7) // 8 + 8*12
   
    move.l  usp, a7 // 4


Alors on a : 4 + 60 + 4 pour l'init et finalization soit 68 cycles !
ensuite on a ((8+(8*15)) * 48) + (8+(8*12)) = 6144 + 104 = 6248 cycles pour le transfert soit en tout 6316 cycles.
Et combien on a fillé avec ça ? (15 * 4 * 48) + 12 octets soit 2892 octets.
on calcul le débit : 2892 octets pour 6316 cycles ça nous fait du 3 511 975 octets / s !
Et non tu ne rêves pas ! Sur un simple 68000... donc il n'est pas si faible ce CPU.
Et bien plus rapide que ton 6820 pour ce genre d'opérations.
et c'est normal qu'en copie tu ailles 2 fois moins vite...
Le DMA du VDP ne va pas plus vite pour copier et filler, étant donné qu'il utilise 2 BUS pour la copie contre un seul pour le fill.
On s'en fout de l'init, c'est comme toi, sur ton 6820 je vais compter un débit avec 6 cycles octets soit environ 1.19 Mo/s et puis c'est tout. La seule différence c'est que t'es obligé d'utiliser ton instruction de transfert pour faire ton fill donc tu n'augmentes pas les perfs pour un simple fill comparé à la copie alors que sur le 68000 ça va 2 fois plus vite forcément...

Le truc c'est que sur le 6820, tu n'as pas trop de voies d'optimisations, tu utilises l'instruction de transfert, c'est rapide et c'est bien. Sur 68000 c'est vrai qu'un mauvais codeur pourrait te faire du code bien lent en utilisant une boucle avec un transfert de byte... mais c'est là que le 68000 est génial, y'a toujours moyen de trouver des astuces pour accélérer ton code :)

[Invité]

Benc'est exactement le meme effet que le bateau pourtant... y'a le scroll vertical qui est utilisé pour la rotation et l'animation "molle" du visage.

Bah l'effet de bateau me semble un simple hsync, avec une sinus table, je suis sur qu'on verrait pas la différence .
Le chat, je disais que justement c'est un effet plus difficile, mais je pense y arriver facilement avec des tiles dynamiques + effet hsync, car l'effet est juste sur la tête, et pas sur tout le décors .

Hehe si tu veux je pourrais te le faire... une fois que j'aurais terminé ma démo.

Pas de soucis, aurais tu compris comment il est fait ??

Effectivementils ont essayé de simuler l'effet mais on fait que c'est fait à la main... Les parties supérieurs sont des sprites et ne suivent pas bien le sol qui utilise le plan avec des tiles dynamique. Mais on peut saluer l'effort quand même.
Le jeu est vraiment bien foutu, il simule souvent un 2eme plan avec les sprites, techniquement il est très interessant pour de la NEC, honnêtement plus que le jeu dont tu me parlais (rien que pour avoir
simuler cet effet déjà).

LOL, t'es pas difficile à contenter, mais effectivement cotton est un beau jeu nec, ça bouge bien, et tu peux y voir bcp de changement de patterns de sprites à la volée .

[quote]
Sur MD ce que font les jeux souvent c'est qu'il lance un DMA en CRAM à chaque scanline, donc tu peux modifier plus que ça. Mickey Mania va plus loin, il étend la zone HBlank pour augmenter le transfert par scanline.
Il doit modifier une palette complete plus la valeur de V Scroll pendant un seul H Blank, c'est sur cette phase :

https://www.youtube.com/watch?feature=player_detailpage&v=6JFYN7dvz3k#t=116s

En étendant la zone de HBlank le VDP n'a pas tout le temps nécessaire pour pré parser les sprites du coup ça diminue le nombre de sprites affichages par ligne à 10 mais ce n'est pas un soucis ici.[quote]
Technique intéressante, mais vu que la PCE n'a pas trop de soucis de couleurs, le changement de la couleur 0 est plus que suffisante pour faire la majorité des effets ..
Mais par contre faire des trics sur une palette complète est impossible, sauf en utilisant le timer (assez délicat je te l'accorde) .

Lis la suite, je dis qu'en effet 176 ko/s ça me semble faible pour de la SNES, et ensuite d'autre réponde que rien que pendant le VBlank tu peux transférer 800 Ko/s sur megadrive..

Ok, je vais voir ça de plus près, mais 800 ko c'est loin des presque 4 mo

Oui mais ces changements de tiles se font pendant le vblank je pense, après tu peux continuer en zone active mais ça doit être plus lent...
D'ailleurs en lisant quelques docs techniques de la PCE ça confirme ce que je pensais.
sur le VDC t'as un status register et comme sur MD t'as un busy flag pour dire que le VDC est occupé à traiter ta donnée en prédiode active :

Oui, mais contrairement à la MD, les transferts se font forcement ralentits mais se font ..
J'aurai jamais assez de puissance CPU, ni DMA pour faire ça que sur du VLANK, et il me semble que le busy flag concerne que les transferts DMA (qui n'ont lieu eux que pendant le VBLANK)

Déjà la taille des sprites est moins flexible que sur MD (par bloc de 16 pixels plutot que 8 pixels) et aussi que la limitation de 16 sprites par ligne fonctionne sur des sprites de 16 pixels de largeur uniquement, pour des sprites de 32 px on arrive à 8 sprites par ligne... Ca peut se comprendre car avec 8 sprites de 32px tu arrives déjà à 256 pixels... mais ça signifie que quelque soit la résolution, tu conserves cette limitation également, et ça pourquoi tant de jeux utilisent le 256 plutot que le 320 :)

Oui elle est moins flexible, bcp moins je dirai même, c'est pour ça que tu as de gros clignotement quand l'ecran est sur-chagé, du fait de ne pas avoir de sprites de 8*8 .
Pour la réso, je sais pas comment la MD fonctionne lors des scrolling, mais sur PCE tu dois définir un écran virtuel au VDC,sur X et Y, cela va définir la limite ou ton écran va boucler ..
cet écran virtuel se fait par pas de 32 tiles (soit 256 pixel), tu comprends vite que c'est plus chiant à gérer sur un écran de 320 pixels .

Oui sur 68000 puisque ce n'est pas une instruction de transfert tu évites ce problème :p

C'est pas dramatique non plus, dans la majorité des cas ce sont des pas de 32 octets .
Tout dépend de ton jeu/niveau,occupation de ta VRAM etc .. c'est au cas par cas .

En effet je viens de voir les docs qui confirment mais faut admettre que la plupart des jeux utilisent le 256 pixels, ce qui est dommage, le 320 c'est quand même plus fin, sympathique d'ailleurs ton petit galaxian :)

Par contre faut pas voir le code C à l'intérieur, ultra dégeu .

C'est le genre de détail ou tu vois les bons développeurs et les flemmards :p

On est d'accord, cependant aucune machine n'est épargnée par ça ..

Ca arrive mais dans ce cas pour moi le jeu n'est certainement pas une vitrine pour la machine. Cotton est plus interessant sur ce point. Comme je l'ai dit plusieurs fois, je le trouve pas si impression ton shoot :p Y'a de gros sprites, mais en quantité limité et parfois ça clignote ou rame... bref, c'est mal fini pour moi.

Raaah les goûts et les couleurs, mais moi pas plus que ça non plus, mais bien plus que gynoug

Mais bien sur car je compte en burst ! plus le fill sera grand et plus tu t'approcheras de ce débit, c'est toujours comme ça que l'on compte : en perf brute.
On s'en fout des fill de 4 octets, dans ce cas tu le fais en une seule instruction.
Là en gros, sur le bitmap en question on est proche de ce débit, je te détail le calcul :

Code:


    move.l  a7, usp  // 4
   
    moveq  #0, d0  // 4 * 15
    moveq  #0, d1
    moveq  #0, d2
    moveq  #0, d3
    moveq  #0, d4
    moveq  #0, d5
    moveq  #0, d6
    moveq  #0, d7
    move.l  d0, a0
    move.l  d0, a1
    move.l  d0, a2
    move.l  d0, a3
    move.l  d0, a4
    move.l  d0, a5
    move.l  d0, a6
   
    lea    (Bitmap+12288), a7  // 12

    rept    48
    movem.l d0-d7/a0-a6, -(a7)  // 8 + 8*15
    endr

    movem.l d0-d7/a0-a3, -(a7) // 8 + 8*12
   
    move.l  usp, a7 // 4


Alors on a : 4 + 60 + 4 pour l'init et finalization soit 68 cycles !
ensuite on a ((8+(8*15)) * 48) + (8+(8*12)) = 6144 + 104 = 6248 cycles pour le transfert soit en tout 6316 cycles.
Et combien on a fillé avec ça ? (15 * 4 * 48) + 12 octets soit 2892 octets.
on calcul le débit : 2892 octets pour 6316 cycles ça nous fait du 3 511 975 octets / s !
Et non tu ne rêves pas ! Sur un simple 68000... donc il n'est pas si faible ce CPU.
Et bien plus rapide que ton 6820 pour ce genre d'opérations.
et c'est normal qu'en copie tu ailles 2 fois moins vite...
Le DMA du VDP ne va pas plus vite pour copier et filler, étant donné qu'il utilise 2 BUS pour la copie contre un seul pour le fill.
On s'en fout de l'init, c'est comme toi, sur ton 6820 je vais compter un débit avec 6 cycles octets soit environ 1.19 Mo/s et puis c'est tout. La seule différence c'est que t'es obligé d'utiliser ton instruction de transfert pour faire ton fill donc tu n'augmentes pas les perfs pour un simple fill comparé à la copie alors que sur le 68000 ça va 2 fois plus vite forcément...

Comme là j'ai pas le temps de répondre je ferais ça tout à l'heure (je me réserve le meilleurs pour la fin ) ..
Ca m'intéresse d'essayer de comprendre un peu le 68000 .
C'est impressionnant comment ces 2 CPU sont radicalement différent .

[MikeeMike_2008]

bon quand je lis les critiques sur la supergraphx sur son line up de 5 jeux

alors on va le comparé au line up de la megadrive on va voir si la md nous propose du 1941, aldyness, gng, grandzort, battle ace (enfin ceui-ci il doit y avoir moyen :lol: )

alors regardons celui de la fabuleuse megadrive

- zoom ! (réalisable sur nes et ca ne vaut même pas un beball pce)

- altered beast (pas mal je trouve pour ce jeu mais bon la sgx peut faire bien mieux sans problème)

- michael jackson (techniquement c'est du 8 bits)

- rambo 3 (la pce fait mieux avec du bloody wolf)

- golden axe (pas mal aussi celui-ci mais toujours rien d'infaisable sur sgx)

- forgotten worlds (bon comparé a aldyness :lol: )

- super hang on (bon il est déjà mieux que bari bari densetsu sur pce quand même encore que de pas beaucoup surtout lorsque l'on regarde taito motorbike racing sur pce !!)

- super thunderblade (je préfère la version pce)

- space harrier 2 (inférieure a la version de space harrier 1 sur pce)

- last battle (magnifique du même niveau que kung fu sur pce sorti 3 ans avant)

- world shampionship soccer (bien moins bon que formation soccer sur pce)

- mystic defender (là c'est déjà ce qui a de mieux dans le line up mais sur pce il y a du ninja spirit, tiger road .... allez on va dire que ca vaut une pce)

- thunderforce 2 (download sur nec et même aéroblaster sont déjà mieux...)

- gouls'n ghost (la moins bonne de toutes les versions même si elle est bien réalisée)

au même moment sur cd rom nec (8bits) voici ce qu'il y a

valis 2, side arms special, red alerte, the ancient ys vanished..... du coup la md est très loin derrière sans compter la logithèque pce déjà disponible

[chaberlo]

mikeemike tu es d'une mauvaise foi ahurrissante pour démolir la megadrive comme tu le fais, essaye de faire sortir des jeux à effets comme alien soldier ou batman et robin sur pc engine on en reparlera. Tu dois bien mal connaitre la megadrive pour la défoncer à ce point (tu n'y a pas joué à mon avis....) et pourtant j'adore la nec et la neo geo.

Et désolé mais conçernant les beats sur neo geo ils sont un peu mou et fades (meme si ils sont bien graphiquements) comparé à bare knuckle 2. (encore une fois tu n'as pas du y jouer)

[Stef]

Bah l'effet de bateau me semble un simple hsync, avec une sinus table, je suis sur qu'on verrait pas la différence .

Haha sisi tu vois la différence, les bords ne remontent pas, le bateau ne fait que se pencher, je le sais car lorsque j'ai développé mon émulateur megadrive, au début je n'avais pas implémenté le scroll vertical par cell (qui est chiant comme la mort à implémenter) du coup je voyais les jeux qui l'utilisait, ça faisait des effets tout foireux.

Je le remarquais bien sur ce jeu que je testais souvent (car pas mal d'effets) :

https://www.youtube.com/watch?v=-9YFtbCb3y0#t=168s

Le chat, je disais que justement c'est un effet plus difficile, mais je pense y arriver facilement avec des tiles dynamiques + effet hsync, car l'effet est juste sur la tête, et pas sur tout le décors .

Je suis impatient de voir ça :)

Pas de soucis, aurais tu compris comment il est fait ??

Je pense oui, j'ai regardé vite fait mais j'ai l'impression qu'il fait juste varier le scroll horizontal à chaque ligne mais derrière t'as une image de flamme fixe.
Le scroll vertical peut être modifié sur le scanline aussi pour dédoubler certaines lignes par exemple (pour faire monter doucement la flamme).

Technique intéressante, mais vu que la PCE n'a pas trop de soucis de couleurs, le changement de la couleur 0 est plus que suffisante pour faire la majorité des effets ..
Mais par contre faire des trics sur une palette complète est impossible, sauf en utilisant le timer (assez délicat je te l'accorde) .

Dans le cas de mickey mania le changement de palette n'est même pas là pour ajouter des couleurs car comme tu peux le voir c'est pas hyper coloré dans cette phase

Ok, je vais voir ça de plus près, mais 800 ko c'est loin des presque 4 mo

Le gars indique bien 800 ko/s en utilisant que la période blank.

Oui, mais contrairement à la MD, les transferts se font forcement ralentits mais se font ..
J'aurai jamais assez de puissance CPU, ni DMA pour faire ça que sur du VLANK, et il me semble que le busy flag concerne que les transferts DMA (qui n'ont lieu eux que pendant le VBLANK)

Sur MD le blank (qui fait 38 lignes en NTSC et 88 ou 72 en PAL) te permet de transférer pas mal déjà, il vaut mieux utiliser l'actif pour faire les calculs de la prochaine frame, tu peux faire un peu de transfert mais c'est clairement plus lent. Au pire tu étends un peu le blank...

Oui elle est moins flexible, bcp moins je dirai même, c'est pour ça que tu as de gros clignotement quand l'ecran est sur-chagé, du fait de ne pas avoir de sprites de 8*8.

Et voilà

Pour la réso, je sais pas comment la MD fonctionne lors des scrolling, mais sur PCE tu dois définir un écran virtuel au VDC,sur X et Y, cela va définir la limite ou ton écran va boucler ..
cet écran virtuel se fait par pas de 32 tiles (soit 256 pixel), tu comprends vite que c'est plus chiant à gérer sur un écran de 320 pixels .

C'est pareil sur MD mais réellement à partir du moment ou l'écran virtuel est bien plus grand que l'écran réel, ce n'est pas un problème... tu utilises l'écran virtuel comme un cache.

Par contre faut pas voir le code C à l'intérieur, ultra dégeu .

Le résultat est là c'est l'important et tant que ça tourne à bonne vitesse.

Comme là j'ai pas le temps de répondre je ferais ça tout à l'heure (je me réserve le meilleurs pour la fin ) ..
Ca m'intéresse d'essayer de comprendre un peu le 68000 .
C'est impressionnant comment ces 2 CPU sont radicalement différent .

Ahah ok bon j'attends de voir ça :)

[MikeeMike_2008]

regarde un peu au dessus touko nous montre une preview de alien soldier sur pce

je la connais très bien sinon je ne me lancerais pas sur le sujet

dans ce cas appel moi si tu trouves quelques shoot md qui rivalise avec une 8 bits ...
avec cette 8 bits on se rapproche le plus de la neo côté shoot....

comparé à bare knuckle 2. (encore une fois tu n'as pas du y jouer)

allez rien que sengoku 1 l'explose in the noze

[chaberlo]

sengoku 1 est nul à chier.... il a hyper vieillit et on s'emmerde ferme dans ce jeu... mou et chiant, aucun rythme, raide comme un piquet (2,5 coups par perso...) c'est à se demander si tu as aussi joué à celui la...:lol:

[chaberlo]

un autre exemple, final fight mega-cd est infaisable sur nec, et explose sans aucun mal tout beat neo geo en matiere de gameplay/rythme.

Si tu as ratté les beats megadrive tu a simplement fais l'impasse sur les meilleurs beats de la génération 16 bits. (ça en fait des bits)

[Cpt.Tractor]

La Neogeo, c'est un équilibre entre un hardware puissant et des cartouches à très grande capacité pour pouvoir exploiter ce hardware.

Amen

[Invité]

Haha sisi tu vois la différence, les bords ne remontent pas, le bateau ne fait que se pencher, je le sais car lorsque j'ai développé mon émulateur megadrive, au début je n'avais pas implémenté le scroll vertical par cell (qui est chiant comme la mort à implémenter) du coup je voyais les jeux qui l'utilisait, ça faisait des effets tout foireux.

Je le remarquais bien sur ce jeu que je testais souvent (car pas mal d'effets) :

https://www.youtube.com/watch?v=-9YFtbCb3y0#t=168s

Bah visuellement je trouve que ça parait moins que le chat, le bateau ..
Dans contra, le boss est un layer ??

Je suis impatient de voir ça :)

Tu l'as bien vu dans cotton c'est pas loin, en m'appliquant je pense y arriver ..
Quand, j'aurai un peu de temps, je regarderai ça, c'est un effet intéressant .

Je pense oui, j'ai regardé vite fait mais j'ai l'impression qu'il fait juste varier le scroll horizontal à chaque ligne mais derrière t'as une image de flamme fixe.
Le scroll vertical peut être modifié sur le scanline aussi pour dédoubler certaines lignes par exemple (pour faire monter doucement la flamme).

eheh pas mal, mais si tu crois que ça va suffire, mais je dis quand même :thumright: ..
L'effet est ultra simple en fait, mais donne un très bon rendu je trouve, et le top, c'est que ça consomme quasi rien en CPU ..

Le gars indique bien 800 ko/s en utilisant que la période blank.

Oui mais hors vblanc tu disais que tu pouvais pas faire bcp de transfert,voire pas du tout ..

Et voilà

Ah mais toujours dis que sur ce point, la flexibilité des sprites, la MD est top ..

C'est pareil sur MD mais réellement à partir du moment ou l'écran virtuel est bien plus grand que l'écran réel, ce n'est pas un problème... tu utilises l'écran virtuel comme un cache.

Oui, mais c'est plus simple quand tout est multiple de 256, sinon à part ça et le fait que ça prend plus de vram, car si tes écrans ont bcp de tiles différentes, c'est plus lourds sur des écrans de 40 tiles de larges que 32 ..
Et l'écran virtuel consomme aussi de la VRAM,et il est pas infini non plus lol ..
Et puis en 256, tu peux actualiser tes tiles dans l'overscan, sans avoir à toucher ton écran virtuel ..

Le résultat est là c'est l'important et tant que ça tourne à bonne vitesse.

Ahah ok bon j'attends de voir ça :)

Bon si je comprends bien je vais devoir te le dire ?? ou j'ai droit au jocker sur ce coup ??

[Invité]

un autre exemple, final fight mega-cd est infaisable sur nec, et explose sans aucun mal tout beat neo geo en matiere de gameplay/rythme.

Ah bon pourquoi il est infaisable ???
il tourne bien sur SNES !!

[chaberlo]

un autre exemple, final fight mega-cd est infaisable sur nec, et explose sans aucun mal tout beat neo geo en matiere de gameplay/rythme.

Ah bon pourquoi il est infaisable ???
il tourne bien sur SNES !!

...oui mais sur super nes il est ignoble... (mou du genou, 3 sprites,5 affichables... jouable à 1 seul :lol: )

d'ailleurs c'est quoi le jeu se rapprochant le plus sur nec? crest of wolf? :lol: :lol: JE RIS.

[Invité]

Ok, mais ça me dit pas en quoi le PCE peut pas faire FF !!

[chaberlo]

Ok, mais ça me dit pas en quoi le PCE peut pas faire FF !!

il y a tout simplement de trop gros sprites affichés simultanément, sans ralentissements et nerveux. je ne vois pas de jeux nec équivalent. (rien qu'a voir la maigre tentative sur nec de faire des beats....) elle est devant cependant pour les shoots, c'est sur.

[Stef]

Dans contra, le boss est un layer ??

T'imagines le cout s'il fallait animer de cette manière (en 60 FPS) un aussi gros sprite ??
Et surtout à la fin quand ça explose, ça clignoterait à mort si ct un sprite.

Tu l'as bien vu dans cotton c'est pas loin, en m'appliquant je pense y arriver ..
Quand, j'aurai un peu de temps, je regarderai ça, c'est un effet intéressant .

Et même si je dis ok, pk pas, là c'est cablé, c'est un avantage sûr, comme le mode 7 peut l'être sur SNES.

eheh pas mal, mais si tu crois que ça va suffire, mais je dis quand même :thumright: ..
L'effet est ultra simple en fait, mais donne un très bon rendu je trouve, et le top, c'est que ça consomme quasi rien en CPU ..

Ce qui confirme ma théorie, je vois pas ce qui peut manquer d'autre, enfin à tester...

Oui mais hors vblanc tu disais que tu pouvais pas faire bcp de transfert,voire pas du tout ..

Oui mais tu auras la meme contrainte sur beaucoup de machines, quand t'es pas en blank, tes transfert vers la VRAM / VDC ou VDP sont ralentis.
Après vu que le VDC est 16 bits comparé au CPU 8 bits, j'imagine que les wait states sont moindres que sur MD mais tu dois avoir des pénalités quand même.
Sur MD la pénalité est assez importante donc il vaut mieux envoyer pendant le blank avec le DMA.

Oui, mais c'est plus simple quand tout est multiple de 256, sinon à part ça et le fait que ça prend plus de vram, car si tes écrans ont bcp de tiles différentes, c'est plus lourds sur des écrans de 40 tiles de larges que 32 ..
Et l'écran virtuel consomme aussi de la VRAM,et il est pas infini non plus lol ..
Et puis en 256, tu peux actualiser tes tiles dans l'overscan, sans avoir à toucher ton écran virtuel ..

Oui ça consomme un peu plus mais le système d'affichage par tile permet de bien optimiser l'espace, surtout que sur MD les tiles peuvent être flippés (comme les sprites), ça permet encore de gagner de la place.

Bon si je comprends bien je vais devoir te le dire ?? ou j'ai droit au jocker sur ce coup ??

[Invité]

Donc pas de soucis pour les jeux nerveux,et gros sprites ..
Je viens de regarder la version MD, c'est vrai qu'il est balaise ..

Au fait, elle fait combien de sprites/ligne la MD ??

[Stef]

Donc pas de soucis pour les jeux nerveux,et gros sprites ..
Je viens de regarder la version MD, c'est vrai qu'il est balaise ..

Au fait, elle fait combien de sprites/ligne la MD ??

Quoi ?? parce que tu n'avais jamais regardé la version MD ??? et c'est bien toi qui m'a saoulé avec la version SNES sur le topic SNES vs MD pour me dire qu'elle était trop bien alors que j'arrêtaits pas de te dire que la version MCD était incomparable...
Et ce jeu était le preuve que la MD peut faire de gros sprites sans problèmes.

La limite de sprite par ligne sur MD (en mode 320) c'est soit :
- 20 sprites / ligne
- 320 pixels / ligne
selon la contrainte qui arrive en premier.

T'as à peu près les mêmes limites sur SNES et PCE, c'est pas forcément là le problème.

[Invité]

T'imagines le cout s'il fallait animer de cette manière (en 60 FPS) un aussi gros sprite ??
Et surtout à la fin quand ça explose, ça clignoterait à mort si ct un sprite.

Oui bien sur, mais l'effet est bien fait ..

Et même si je dis ok, pk pas, là c'est cablé, c'est un avantage sûr, comme le mode 7 peut l'être sur SNES.

Oui, bien sur c'est un avantage indéniable, mais je veux voir jusqu'à quel point, j'arriverai (ou pas), a faire cet effet en soft ..
Et surtout son impact .

Ce qui confirme ma théorie, je vois pas ce qui peut manquer d'autre, enfin à tester...

Oui si un jour tu essaies, tu verras bien ..

Oui mais tu auras la meme contrainte sur beaucoup de machines, quand t'es pas en blank, tes transfert vers la VRAM / VDC ou VDP sont ralentis.
Après vu que le VDC est 16 bits comparé au CPU 8 bits, j'imagine que les wait states sont moindres que sur MD mais tu dois avoir des pénalités quand même.
Sur MD la pénalité est assez importante donc il vaut mieux envoyer pendant le blank avec le DMA.

Oui et vu sa flexibilité ce serai dommage de pas l'utiliser au max ..

Oui ça consomme un peu plus mais le système d'affichage par tile permet de bien optimiser l'espace, surtout que sur MD les tiles peuvent être flippés (comme les sprites), ça permet encore de gagner de la place.

Je sais, mais si tu veux bcp de diversité dans tes niveau, en 320 tu vas forcement consommer plus, et donc avoir moins de VRAM dispo pour tes sprites .
Surtout que toi sur Md tu as 2 layer à alimenter avec 64 ko de VRAM ..

Raah la vache tu laches rien ..
Bon j'avoue que pour les transferts le 68000 est balaise, bien plus que le 6280 ..
Mais .... (ça c'est pour me laisser le temps de trouver une pirouette )

[chaberlo]

Donc pas de soucis pour les jeux nerveux,et gros sprites ..
Je viens de regarder la version MD, c'est vrai qu'il est balaise ..

Au fait, elle fait combien de sprites/ligne la MD ??

non mais faut arreter, entre afficher des gros sprites sans animes ou qui stagnent en 2 frames (comme beaucoups de shoots nec), et afficher des sprites énormes bien animés de multiples frames c'est autre chose.

la nec ne pourrait sortir des jeux comme final fight cd ou bare knuckle 2, c'est impossible (et ne l'a d'ailleurs jamais fait)... crest of wolf?????:lol: :lol: :lol:

[Invité]

Quoi ?? parce que tu n'avais jamais regardé la version MD ??? et c'est bien toi qui m'a saoulé avec la version SNES sur le topic SNES vs MD pour me dire qu'elle était trop bien alors que j'arrêtaits pas de te dire que la version MCD était incomparable...
Et ce jeu était le preuve que la MD peut faire de gros sprites sans problèmes.

Eh, oh, en mode mauvaise fois, ca compte pas !!! ..

La limite de sprite par ligne sur MD (en mode 320) c'est soit :
- 20 sprites / ligne
- 320 pixels / ligne
selon la contrainte qui arrive en premier.

T'as à peu près les mêmes limites sur SNES et PCE, c'est pas forcément là le problème.

ok merci pour l'info ..

[Stef]

La limite de sprite par ligne sur MD (en mode 320) c'est soit :
- 20 sprites / ligne
- 320 pixels / ligne
selon la contrainte qui arrive en premier.

T'as à peu près les mêmes limites sur SNES et PCE, c'est pas forcément là le problème.

ok merci pour l'info ..

Ouais mais comme le souligne chaberlo, y'a une différence entre animé les sprites une frame sur 5, et les animer chaque frame comme sur FF CD.

Ici t'as une vidéo d'un play a 2 joueurs :
https://www.youtube.com/watch?v=rxdNs_DFEQ8

On voit bien qu'il n'y a jamais plus de 6 persos à l'écran (sauf contre les boss exceptionnellement), mais vu la taille ça se comprend, déjà avec 6 tu as qq clignotements... et puis avec les tonneaux et autres éléments du décor ça commence à consommer sur le 68000 de la MD (car c lui qui alimente le jeu, le 68000 côté CD est là juste pour récupérer les data du CD et gérer les bruitages aussi).

[Invité]

non mais faut arreter, entre afficher des gros sprites sans animes ou qui stagnent en 2 frames (comme beaucoups de shoots nec), et afficher des sprites énormes bien animés de multiples frames c'est autre chose.

la nec ne pourrait sortir des jeux comme final fight cd ou bare knuckle 2, c'est impossible (et ne l'a d'ailleurs jamais fait)... crest of wolf?????:lol: :lol: :lol:

Huum c'est vrai que dans les shoots Md ,elle affiches des sprites enormes ...
Et lire que la nec affiche des sprites qui stagnent, c'est n'importe quoi ..
Les shoot nec sont bien plus vif, et animé que ceux sur MD, compares ceux qui existent sur les 2 machines, tu verra bien que la nec fait mieux ..
Et si on compare la MD à la SGX, là c'est même plus la peine ...

décor ça commence à consommer sur le 68000 de la
MD (car c lui qui alimente le jeu, le 68000 côté CD est là juste pour
récupérer les data du CD et gérer les bruitages aussi).

Donc ça confirme que sans le MCd, le jeu n'aurai jamais vu le jour sur cartouche, ou pas de ce niveau ..
Car mine de rien, là, la Md n'a aucune musique à gérer, ni aucun son ..

[Stef]

Oui, bien sur c'est un avantage indéniable, mais je veux voir jusqu'à quel point, j'arriverai (ou pas), a faire cet effet en soft ..
Et surtout son impact .

Bon courage, à 60 FPS ça doit pas etre évident !

Oui si un jour tu essaies, tu verras bien ..

Bah j'essaierai, je sais qu'il n'y a pas de vrai algo de blur, bien trop couteux sur ces vieux cpu :p

Je sais, mais si tu veux bcp de diversité dans tes niveau, en 320 tu vas forcement consommer plus, et donc avoir moins de VRAM dispo pour tes sprites .
Surtout que toi sur Md tu as 2 layer à alimenter avec 64 ko de VRAM ..

Oui honnêtement je me suis jamais senti à l'étroit au niveau de la VRAM.
Sur PCE l'avantage d'avoir autant de mémoire c'est de cacher un max de tile.

Raah la vache tu laches rien ..
Bon j'avoue que pour les transferts le 68000 est balaise, bien plus que le 6280 ..

et bah voilà, tu vois ça va mieux maintenant

Mais .... (ça c'est pour me laisser le temps de trouver une pirouette )

J'en doute pas

[Invité]

Bon courage, à 60 FPS ça doit pas etre évident !

Je sais pas si j'arriverai à faire quelque chose de correct, mais faut essayer ..

Bah j'essaierai, je sais qu'il n'y a pas de vrai algo de blur, bien trop couteux sur ces vieux cpu :p

Oui, j'allais pas essayer d'imiter les algos pc, impossible à faire ..
Et puis j'aurai plus aucune ressources ..

Oui honnêtement je me suis jamais senti à l'étroit au niveau de la VRAM.
Sur PCE l'avantage d'avoir autant de mémoire c'est de cacher un max de tile.

Tiles ou pattern de sprites, moins tu touches à la VRAM mieux c'est ..

et bah voilà, tu vois ça va mieux maintenant

j'en doute pas

Lol, bah quand y'a rien à dire y'a rien à dire ..

[Stef]

Huum c'est vrai que dans les shoots Md ,elle affiches des sprites enormes ...
Et lire que la nec affiche des sprites qui stagnent, c'est n'importe quoi ..
Les shoot nec sont bien plus vif, et animé que ceux sur MD, compares ceux qui existent sur les 2 machines, tu verra bien que la nec fait mieux ..
Et si on compare la MD à la SGX, là c'est même plus la peine ...

Sur MD tu as des shoots avec des gros sprites mais ça les rend pas forcément meilleurs.
Y'a Sol Deace qui affiche souvent de gros sprites (pour les boss surtout), il est assez méconnu et pas trop mal mais graphiquement un peu douteux :

https://www.youtube.com/watch?v=ccN9n18JpEE

Donc ça confirme que sans le MCd, le jeu n'aurai jamais vu le jour sur cartouche, ou pas de ce niveau ..
Car mine de rien, là, la Md n'a aucune musique à gérer, ni aucun son ..

Ah oui mais c'est pas grave car habituellement c'est le Z80 qui s'en charge :)
Les musiques n'auraient pas été de cette qualité c'est sur (FM vs CDDA), les voix non plus (quoique avec un bon driver, les voix auraient pu être assez proches).

[Invité]

Sur MD tu as des shoots avec des gros sprites mais ça les rend pas forcément meilleurs.
Y'a Sol Deace qui affiche souvent de gros sprites (pour les boss surtout), il est assez méconnu et pas trop mal mais graphiquement un peu douteux :

https://www.youtube.com/watch?v=ccN9n18JpEE

Oui sur ça on est d'accord, mais quand t'as un bon jeu avec de gros sprites, c'est mieux, comme c'est souvent le cas sur les shoots PCE ..
effectivement sol deace n'est pas génial, les sprites sont pauvres malgré la taille de ceux des jeux pce ..

Ah oui mais c'est pas grave car habituellement c'est le Z80 qui s'en charge :)
Les musiques n'auraient pas été de cette qualité c'est sur (FM vs CDDA), les voix non plus (quoique avec un bon driver, les voix auraient pu être assez proches).

Ouai, mais là si les devs utilisent le 68000, c'est que le Z80 y suit pas, notamment pour jouer les samples qui composent les bruitages ..
Et je suppose que le CPU du MCD, n'utilise pas le bus de la MD,et qu'il a sa propre RAM ??

[Stef]

Ouai, mais là si les devs utilisent le 68000, c'est que le Z80 y suit pas, notamment pour jouer les samples qui composent les bruitages ..
Et je suppose que le CPU du MCD, n'utilise pas le bus de la MD,et qu'il a sa propre RAM ??

C'est surtout qu'ils peuvent utilisent les capacités sonores du mega CD qui ajoutent 8 voix PCM 16 bits ! Pourquoi utiliser le YM2612 quand on a du CDDA et 8 voix PCM ??
Oui le CPU du MCD a son propre BUS, tout comme le Z80 a le sien aussi.
C'est sur qu'avec le Z80 le son ne sera pas aussi classe...

[pckid]

Je voudrais appuyer sur la pce , le magnifique travail d'hudson pour la version street fighter qui vraiment de très bonne qualité par rapport à la megadrive et à la snes (1er SF2) après ils l'ont amlioré pour le Super SF2.

Mais surtout que la pce , possède plutôt un style de jeu à part et que l'on ne peut pas comparer à la MD ni à la SNES et NEO GEO.

Chaque machine apporte sa touche personnel, et si on si attarde une neo geo ne peut pas etre comparer à la pce , ni à la md ni à la snes. Il faut gouter au meilleur jeu de chacun pour comprendre que si l'on peut, il faut posséder les 4 consoles !