Re: MEGADRIVE vs SUPER NINTENDO : Fight !

par Invité Dim 3 Fév 2019 - 9:51

marmotjoy a écrit:J'ai banni de mon vocabulaire les termes de type " audio" ici, ne me lance pas

Je parle de datas, et non d'audio au sens propre .

par Invité Dim 3 Fév 2019 - 9:57

Vous ne m'aurez pas Mr. Green

Très bien ton morceau Kaot thumleft

par Invité Dim 3 Fév 2019 - 9:59

Merci c cool afro

par Invité Dim 3 Fév 2019 - 10:14

Pareil, j'aime bien aussi thumleft

par jeff buckley Dim 3 Fév 2019 - 11:49

Il sera dans Papirium.

par ace76 Dim 3 Fév 2019 - 15:18

kaot a écrit:

Coucou marmotjoy.

Cette compo me rappele"acceptable in the eighties"de Calvin Harris"

par ace76 Dim 3 Fév 2019 - 15:20

wiiwii007 a écrit:Genre comme dans Gaiares où on attend une plombe avant chaque phase d'action ?

.Campagne de désinformation.

par Invité Dim 3 Fév 2019 - 15:29

@ace76 : j'irai voir
Edit : ah oui

J'étais parti sur un remake ghetto de Fossil Funk de ceephax mais c'est pile poil le même délire. Bien vu.

par Invité Dim 3 Fév 2019 - 16:34

Histoire de casser le préjugé sur le CPU de la snes au niveau du nombre de sprites dans les BTU.

Voici task force sur 2GS:

Comme on peut le voir il y a bien plus que 4 sprites à l'écran sur une machine qui n'a aucune assistance hardware, je veux dire que tout ici est fait au CPU,un CPU @ 2.5/2.8mhz .

Ici sur le vrai hard(mode 2 joueurs en prime):

par upsilandre Dim 3 Fév 2019 - 16:58

Bon par contre c'est du 10fps Razz

par Invité Dim 3 Fév 2019 - 17:01

upsilandre a écrit:Bon par contre c'est du 10fps

T'abuses un peu .
N'oublies pas que tout est géré par le CPU , sprites, scrolling(et pas de changement de pointeur vidéo ici,la page graphique est figée), et pas de DMA ou ce genre de trucs.
La page graphique est accèssible @1mhz(compatibilité apple 2) ou entre 2 et 2.5 mhz en utilisant une page shadow .

par Stef Lun 4 Fév 2019 - 22:49

Ben il a raison, le frame rate est quand même très bas donc bon c'est pas une performance même pour du 100% soft (et il y a pas mal de tearing du coup). Surtout que le 2GS est quand même super bien branlé sur les modes graphique (320x200 en linéaire 4bpp voire 8bpp) ce qui aide pas mal.
En fait il faut reconnaitre que l'apple 2GS est quand même pas mal, malheureusement ils ont eu la mauvaise idée de foutre un 65C816 dessus... avec un 68000 ça aurait fait une super bonne machine (et qui aurait probablement mieux marché) :)

par **Tryphon** Mar 5 Fév 2019 - 7:13

Une question : comment ça marche le scrolling en 10 fps ?

Sur MO6 (1 MHz, page fixe), j'avais tenté d'en faire (à l'époque, j'avais 12 ans Razz

), en décalant les bits et les octets dans la mémoire écran, et ça prenait de toutes façons (beaucoup) plus d'1/50ème de seconde pour rafraîchir l'écran. Ça faisait du gros tearing.

Y'a moyen de "figer l'affichage" pendant qu'on met à jour la mémoire écran ?

par Stef Mar 5 Fév 2019 - 9:56

Tryphon a écrit:Une question : comment ça marche le scrolling en 10 fps ?

Sur MO6 (1 MHz, page fixe), j'avais tenté d'en faire (à l'époque, j'avais 12 ans ), en décalant les bits et les octets dans la mémoire écran, et ça prenait de toutes façons (beaucoup) plus d'1/50ème de seconde pour rafraîchir l'écran. Ça faisait du gros tearing.

Y'a moyen de "figer l'affichage" pendant qu'on met à jour la mémoire écran ?

Non, il faut un double buffer (tu génères une image dans un buffer pendant que l'autre est affichée) avec un moyen de déplacer le pointeur du tampon video et sur beaucoup de machine d'époque c'était pas possible, soit par manque de mémoire vidéo, soit à cause du pointeur tampon fixé (ou les 2 souvent MDR

).
Quand tu es en 4bpp avec un affichage linéaire, tu vas préférer faire un scroll sur 2 pixels à la fois, histoire d'éviter un décalage de bit (ce qui serait terriblement lent), certains processeur vidéo autorisaient juste de faire un offset de 1 pixel dans ce cas pour pouvoir faire un scrolling au pixel plus facilement.

par Stef Mar 5 Fév 2019 - 9:58

kaot a écrit:

Coucou marmotjoy.

Excellent

J'aime beaucoup :)

par **Tryphon** Mar 5 Fév 2019 - 11:12

Stef a écrit:
Tryphon a écrit:Une question : comment ça marche le scrolling en 10 fps ?

Sur MO6 (1 MHz, page fixe), j'avais tenté d'en faire (à l'époque, j'avais 12 ans ), en décalant les bits et les octets dans la mémoire écran, et ça prenait de toutes façons (beaucoup) plus d'1/50ème de seconde pour rafraîchir l'écran. Ça faisait du gros tearing.

Y'a moyen de "figer l'affichage" pendant qu'on met à jour la mémoire écran ?

Non, il faut un double buffer (tu génères une image dans un buffer pendant que l'autre est affichée) avec un moyen de déplacer le pointeur du tampon video et sur beaucoup de machine d'époque c'était pas possible, soit par manque de mémoire vidéo, soit à cause du pointeur tampon fixé (ou les 2 souvent ).
Quand tu es en 4bpp avec un affichage linéaire, tu vas préférer faire un scroll sur 2 pixels à la fois, histoire d'éviter un décalage de bit (ce qui serait terriblement lent), certains processeur vidéo autorisait juste de faire un offset de 1 pixel dans ce cas pour pouvoir faire un scrolling au pixel plus facilement.

Mais le rafraichissement de l'écran prenait plus d'1/50ème de seconde. Cela dit, je crois qu'aucun jeu MO6 n'a un scrolling fluide. Y'a peut-être une raison Razz

par **TotOOntHeMooN** Mar 5 Fév 2019 - 11:20

Tryphon a écrit:Cela dit, je crois qu'aucun jeu MO6 n'a un scrolling fluide. Y'a peut-être une raison

C'est quoi un M06 ?
Haaaaa, c'était un O cette fois-ci ! Mr. Green

par Invité Mar 5 Fév 2019 - 12:03

Surtout que le 2GS est quand même super bien branlé sur les modes graphique (320x200 en linéaire 4bpp voire 8bpp) ce qui aide pas mal.

Ca aide en quoi ??
Il n'y a pas de mode bp sur 2 GS,seulement du 4bits chunky paletisé comme sur MD mais avec 16 palettes .
Les sprites softs tu copies des blocs avec un masque, donc la seule chose que tu peux faire, ce sont des sprites compilés avec du code auto généré,mais ça toutes les machines peuvent le faire ..

Si tu supprimes le scrolling+les sprites (ce qui consomme le plus,et vu que la snes le fait en hard), je pense qu'il doit qd même rester bcp de CPU pour gérer tout le reste sans soucis à 60 fps .
Surtout qu'en plus il y a non seulement bcp plus de sprites qu'un BTU, et donc bcp plus de collisions à gérer ici.
Donc si on supprime le surplus on libère encore pas mal de CPU .
Je trouve que c'est pas mal pour un CPU @2.5 mhz, j'ai pas vu mieux sur ST qui peut jouer sur ses bp séparés pour faciliter le plot bckgnd/sprites .

par **Tryphon** Mar 5 Fév 2019 - 12:56

Qu'appelles-tu des sprites compilés avec code auto généré ?

par Stef Mar 5 Fév 2019 - 13:43

Ben plutot que de représenter un sprite avec une image composé de pixels avec des intensités et un mask, tu compiles ton image directement sous forme de code type :

mov 0(mem),$67
mov 1(mem),$A1
mov 267(mem),$28
....

C'est extrêmement bourrin, ton image prend un peu plus de place mais c'est une manière 'optimale' pour la dessiner (on fait ça surtout pour les sprites car du coup ça gère le masking aussi).

Touko a écrit:Ca aide en quoi ??
Il n'y a pas de mode bp sur 2 GS,seulement du 4bits chunky paletisé comme sur MD mais avec 16 palettes .
Les sprites softs tu copies des blocs avec un masque, donc la seule chose que tu peux faire, ce sont des sprites compilés avec du code auto généré,mais ça toutes les machines peuvent le faire ..

Si tu supprimes le scrolling+les sprites (ce qui consomme le plus,et vu que la snes le fait en hard), je pense qu'il doit qd même rester bcp de CPU pour gérer tout le reste sans soucis à 60 fps .
Surtoutlus de sprites qu'un BTU, et d qu'en plus il y a non seulement bcp ponc bcp plus de collisions à gérer ici.
Donc si on supprime le surplus on libère encore pas mal de CPU .
Je trouve que c'est pas mal pour un CPU @2.5 mhz, j'ai pas vu mieux sur ST qui peut jouer sur ses bp séparés pour faciliter le plot bckgnd/sprites .

Ben justement c'est du chunky et pas du bitplan Wink

Et contrairement à la MD c'est un frame buffer linéaire donc c'est quand même un mode d'affichage super pratique pour faire de l'opération au pixel. Bien sûr le fait de tout faire un soft c'est super costaud, mais avec un background simple et des sprites compilés y'a moyen de faire des trucs sympas. Tu dis que c'est pas mal pour un CPU à 2.5 Mhz mais ramené à la fréquence de la mémoire c'est pas non plus un miracle (ce que je veux dire par là c'est qu'on ferait mieux avec un 68000 à 8 Mhz).

par Invité Mar 5 Fév 2019 - 14:31

Ben justement c'est du chunky et pas du bitplan Et contrairement à la MD c'est un frame buffer linéaire donc c'est quand même un mode d'affichage super pratique pour faire de l'opération au pixel.

Justement en 2D le bp est bien plus avantageux pour ce genre d'opérations, tu travailles pas au pixels, et souvent tu utilisais les bp à ton avantage .
les 2 premiers bp sont réservés au bckngd et les 2 autres aux sprites, ça permet de travailler bien plus vite, au détriment des couleurs bien sur .
De plus contrairement au ST, sur 2GS la page graphique est fixe,donc pas de double buffer, et plus tu n'y écris pas en full speed contrairement au ST .
Donc pas comparable .

Ben plutot que de représenter un sprite avec une image composé de pixels avec des intensités et un mask, tu compiles ton image directement sous forme de code

C'est ça, et tu as du code pour chaque type de sprite au lieu d'avoir un code générique pour tout les sprites, c'est donc optimisé et rapide, mais ça consomme pas mal de RAM .
Pour l'autogénéré, le code est généré à la volée avant d'être exécuté, cela permet de mieux gérer l'utilisation de la RAM .
C'est une technique qui peut être utilisée sur PCE, tu gagnes ~40% de débit en plus,au détriment de la taille bien sur . .

par **Tryphon** Mar 5 Fév 2019 - 16:48

OK, je vois. Merci :)

C'est effectivement plus rapide qu'un move (x+), (y+), mais sur PCE, le DMA n'est pas plus rapide ?

par Invité Mar 5 Fév 2019 - 17:07

Tryphon a écrit:OK, je vois. Merci :)

C'est effectivement plus rapide qu'un move (x+), (y+), mais sur PCE, le DMA n'est pas plus rapide ?

Tu n'as pas de DMA RAM->VRAM seulement des instructions de transfert de blocs @6 cycles/octets, donc bien plus lent qu'un DMA,mais heureusement tu peux transférer pendant l'affichage .
En faisant des sprites compilés, tu peux utiliser les instructions d'accès direct au VDC ST0/1/2,avec tu transfères 1 octet/4 cycles,mais tu doubles la tailles de tes données, bon aujourd'hui avec la taille des cartouches c'est plus trop un souci .

par **Tryphon** Mar 5 Fév 2019 - 17:12

Je crois que tu me l'avais dit. Ca devait être bien chiant à l'époque, déjà que le Hucard étaient petites...

par Stef Mar 5 Fév 2019 - 17:31

Touko a écrit:
Ben justement c'est du chunky et pas du bitplan Et contrairement à la MD c'est un frame buffer linéaire donc c'est quand même un mode d'affichage super pratique pour faire de l'opération au pixel.
Justement en 2D le bp est bien plus avantageux pour ce genre d'opérations, tu travailles pas au pixels, et souvent tu utilisais les bp à ton avantage .
les 2 premiers bp sont réservés au bckngd et les 2 autres aux sprites, ça permet de travailler bien plus vite, au détriment des couleurs bien sur .
De plus contrairement au ST, sur 2GS la page graphique est fixe,donc pas de double buffer, et plus tu n'y écris pas en full speed contrairement au ST .
Donc pas comparable .

Le BP a juste l'avantage matériel de l'écriture en parallèle au niveau de la mémoire (c'est pour ça qu'on le retrouvait beaucoup au début de la micro informatique), ça permet aussi de bidouiller des effets pour les démos (type fausse transparence ou shadow) mais pour les jeux le mode chunky est bien plus pratique / rapide. Pour avoir pas mal taté du mode X à l'époque, je peux te dire que c'était vraiment une plaie pour faire un affichage rapide de BG et de sprites comparé au mode $13 de base. Et vraiment sans ce double buffering (qui n'existait pas en mode $13) je ne l'aurai jamais utilisé tant c'était plus lent et pénible...
Sinon tu dis que tu n'écris pas en VRAM en fullspeed sur le 2GS, c'est pas très étonnant... c'est déjà bien pratique d'avoir la VRAM directement mappé sur le BUS CPU (ce qui n'est pas le cas sur MD par ex), du coup j'imagine que le chip video et le CPU se partage les accés mémoire et tu peux pas faire de miracle (surtout avec un CPU qui "taxe" autant en mémoire).

par Invité Mar 5 Fév 2019 - 17:55

Tryphon a écrit:Je crois que tu me l'avais dit. Ca devait être bien chiant à l'époque, déjà que le Hucard étaient petites...

Oui a l'époque c'était impossible d'utiliser ça .

par cact88 Mer 6 Fév 2019 - 8:37

J'avais bien aimé x-kaliber 2097 (sans parler de tuerie non plus) en action plateforme. En bonne plateforme, y a les deux OCEAN où exploit, ils se sont sorti les doigts pour une fois: Mr Nutz et Adam's Family.

x-Kaliber 2097 !! ce jeu est pas très connu mais j'y jouer dans mon enfance ,je l'est chercher et finalement j'ai telecharger le rom pour mettre sur ma snes mini .. faut que je le refasse c'est sur pour moi c'est un très bon jeux quand même , je me souvenait encore de la musique après toute ces années Cool

par Invité Mer 6 Fév 2019 - 11:22

J'ai souvenir d'une musique assez techno Wink

par Invité Jeu 7 Fév 2019 - 9:43

Ca semble pas si mal, je sais pas de quel jeu vient ce mod, mais ça semble pas mal foutu,juste un peu lent qd même .

par Stef Jeu 7 Fév 2019 - 17:18

C'est un jeu pirate chinois non officiel.
Des graphismes moyens, une animation pourrie, de la musique de merde et des digits pas terribles non plus... sachant que tout est plus ou moins repompés à droite et à gauche... Non franchement c'est quand même pas terrible (même si ça fait un pseudo versus fighting quand même) :-/
Y'a des jeux pirates bien meilleurs que celui-ci.

par **TotOOntHeMooN** Jeu 7 Fév 2019 - 17:27

Oui, c'est plutôt dégueu...