Re: MEGA DRIVE vs SUPER NINTENDO : Fight !

[Agathon]

Salut stef,
ça me fait toujours plaisir de te lire, surtout pour celui qui a fait GENS (je ne me trompe n'est ce pas c'est bien toi?)
J'avais beaucoup aimé ton explications des capacités sonore de la MD que tu m'avais fourni sur msn y a assez longtemps de ça...

A ce touko, il cherche toujours a avoir raison, comme d'hab quoi...

[lessthantod]

A ce touko, il cherche toujours a avoir raison, comme d'hab quoi...

Normal vu qu'il a effectivement raison!

[Agathon]

Donc Dun cote on a un mec qui a develloppe un émulateur et de l'autre on a mec qui a fait quoi déjà?
Mummm TOUKO sort de ce corps lol

[lessthantod]

Donc Dun cote on a un mec qui a develloppe un émulateur et de l'autre on a mec qui a fait quoi déjà?
Mummm TOUKO sort de ce corps lol

C'était juste pour provoquer un peu, ne te mets pas sur la défensive! Moi j'en ai rien à foutre de tout ce blabla technique, je juge le jeu pad en main. Et là la SNES prend le dessus sur la MD de par un son plus net, une palette de couleurs bien plus étendue, et le non moins négligeable mode 7!
De toute façon ce sujet est débattu depuis une 20aine d'année et le sera encore pdt lontemps!

[Agathon]

moi j'aime bien les debats technique, c'est quand meme interressants.
Je le prend pas mal t'inquiete, j'ai bien compris ton second degres...
n'empeche que la personne qui récite le wiki c'est celui qui dit...lol

J'ai ecouté la music de timetrax sur MD OMG impresionnant, la version snes ressemble à rien à coté...

[Invité]

Soit la doc est fausse ou soit comme je te disais plus haut tu as confondu avec le nombre d'intensité de chaque composante RGB : 32 *32 * 32 = 32768.

Non ,et de plus ce que tu sors est complètement faux .
La snes à un encodage des couleurs RGB sur 15 bits soit 5 bits par composante, et ça fait 32768 couleurs possible soit 2^15.

Mais je rien modifié ! Et la preuve c'est que ma phrase n'aurait eu aucuns sens :

<Sur SNES tu as 8 palettes de 16 couleurs pour les background et 8 palettes pour les sprites soit 256 couleurs.>>

Si j'avais dit 16 palettes + 16 palettes on aurait eu 512 couleurs et on sait que c'est 256 couleurs le nombre simultanées à l'écran de la SNES. Je suis là pour descendre la SNES moi, pas l'inverse :p
Non enfin je suis là surtout pour donner plus de détails sur les specs de chaque machine parce qu'on trop tendance à mettre des chiffres qui avantage la SNES comparé à la MD.

Bah ton erreur je te l'ai faite remarquée dessuite après le post ou tu les mettais (en te disans que c'était les specs de la PCE), mais bon tu vas encore dire que je mens .
Et je ne critique pas la MD sur ces capacité d'animation qui sont très bonne, mais sur ces specs générale qui sont ultras banales, ce qui pour moi ne lui permet pas d'avoir ce petit quelque chose qui m'attire, contrairement à la SNES ou la PCE .
Et puis les pros MD aiment aussi bien mettre des chiffres qui veulent rien dire ,mais tant qua ça peut avantager la Md, c'est tout bon.

C'est la même chose, un tile, un cell...
sur SNES on peut faire la distinction car les tiles des BG sont dans un zone mémoire différentes de ceux des sprites, mais ça reste un bloc de 8x8 pixels.
Quand tu affiches des sprites, tu dois souvent modifier les tiles (ou cell comme tu préfères) des sprites car la VRAM ne peut pas contenir l'intégralité des animations des sprites, et ça, en performance c'est importante car la quantité de données que tu peux transferer en VRAM par frame est assez limité (et plus sur SNES que sur MD).

Trop fort, des tiles = des cells
Une tiles (en hardware) est un carré de 8*8, un cell est un carré de 16*16, et que je sache l'organisation des tiles en VRAM est complètement différente de celle des sprites, elle est entrelacée.
Donc tu ne peux pas utiliser des données de sprites directement comme des tiles, et inversement.
Dire qu'un sprite est composé de tiles, est un abus de langage.

Je t'assure qu'en réalité c'est jamais utilisé, sur mon émulateur MD, ne pas émuler le sprite collision ne nuit pas à la compatibilité avec les roms (sauf pour barbie super model :o).
Pourquoi ? parce que ça ne fournit aucune infos sur les sprites qui sont entrés en collision.
Le test par bounding box, ça devient vite gourmand dans un shoot :
Tu prends Gynoug sur MD, quand ton tir est au maximum tu balances bien un bon 20/25 boulettes à l'écran. Déjà faut calculer le coordonnée pour chaque, ensuite pour chaque tir tu fais la bounding box avec tout les ennemis. Il suffit d'avoir 20 ennemis à l'écran (genre dans cette vidéo à 2:10 https://www.youtube.com/watch?v=GXxEWzfWL1w ). Tu arrives déjà à 20 * 20 = 400 bounding box par frame juste pour gérer la collision des tirs avec les ennemis (reste les collisions inverses) soit au total pas loin de 500 collisions / frame à gérer. Crois moi sur les CPU de l'époque c'est beaucoup !
D'ailleurs sur SNES tu verras jamais ça
Et tu ne peux pas calculer la collision que sur la frame où elle arrive (en utilisant le flag de collision), t'imagines si ton code ne rentre pas dans la "frame" (temps CPU pour une frame) t'aurais un ralentissement quand y'a des collisions et ça serait fluide le reste du temps, tu peux pas désigner ton jeu comme ça... A moi d'etre les codeurs de Barbie Super Model (et dieu sait à quel point ils étaient mauvais) on fait jamais ça X'D
Sur SMS et NES ou y'a peu de sprites pk pas, sur MD et SNES c'est fini...

Ok, donc la détection est presque aussi pourrie que sur PCe alors .
Ensuite le bouding boxes, est la technique qui prend le moins de ressources CPU tout en étant suffisante, surtout si tu évites de la faire quand c'est pas necéssaire en utilisant la détection hard.
Et 500 collisions par frame , si c'était le cas, même pas la neo geo pourrait les traiter .
tu as max 20 sprites à l'écran, sachant que tous n'ont pas à avoir de collisions entre eux, tu dois dépenser en étant très large 600/700 cycles, pas de quoi s'affoler .
Les devs mettent en place des algos de trie des sprites pour ne pas avoir a faire des tests inutiles
Donc au final tu ne fait pas tes tests sur tout les sprites.

Oui mais c'est assez lié au final, tout le choix CPU, architecture slow / fast rom c'était pour assurer une retro compatibilité (qui n'a jamais existé au final) et aussi pour des raisons de couts très très discutables (surtout pour cette époque).

Je suis d'accord, mais sur la snes, c'est pas CPU qui est en cause (tout en étant d'accord qu'il est loin de casser la baraque)

Ben non tu vois je lis et réponds correctement toi non seulement tu ne vois pas tout ce que j'écris (je te parlais des différents modes depuis belle lurette) mais en plus tu déformes :p
Mais bon on va pas s'énerver hein X'D

Si je te confirme que tu lis en diagonale .
Mais bon on va s'arrêter, on polue un peut le topic là, malgré un echange de point de vue intéressant .

[Agathon]

Touko, juste une question, c'est vrai que tu m'impressionnes quand tu sors toutes ces données technique, comment les as tu appris?
Les as tu pratiqués, testé?
(ne vois aucune mechanceté dans ma question, je suis sérieux, c'est parceque j'aime bien te lire quand meme hein...meme si je ne suis pas toujours d'accord avec toi).

Et n'arretez pas votre debat technique c'est hyper interressant...

[Invité]

Bon perso je développe sur PCE (pc-engine), donc tu en bouffes de la doc ..

L'avantage c'est que ce que tu apprends pour une machine, tu peux réutiliser quasiment tout pour d'autres bécanes .

Après tu peux aller sur des forums de dev pour chaque machine et lire les docs techniques (incomplètes, et des fois erronées),en essayant de comprendre comment ça marche .
Mais c'est très intéressant, et des fois imbitable (comme celles de la SNES par exemple).

[Agathon]

ok, je comprend mieux maintenant...Tu as fait un emu ou autre? demo?
J'adore au passage la pce, c'est une machine qui toujours impressionné, meme si je lui prefere la megadrive, mais bon ça ta deviné...

Par contre la ou je rejoins stef, c'est au noiveau de la qualité de SORTIE de la megadrive, supérieur à celle de la snes.

Ne confondez pas qualité musicale et qualité de sortie, c'est deux choses totalement différents...

[Invité]

Non jeux, pour l'association retrotaku ..
Les démos sur console c'est la galère car tu testes bcp avec des emulateurs (et c'est pas génial).

ok, je comprend mieux maintenant...Tu as fait un emu ou autre? demo?
J'adore au passage la pce, c'est une machine qui toujours impressionné, meme si je lui prefere la megadrive, mais bon ça ta deviné...

Personne n'est parfait

Par contre la ou je rejoins stef, c'est au noiveau de la qualité de SORTIE de la megadrive, supérieur à celle de la snes.

C'est à dire ??

[Agathon]

Bah tu sais on a tous nos faiblesses c humains après tout.


Pour le son je veux dire que le filtre de la sortie son de la megadrive est vraiment d'exelldnte qualité. Aussi la qualité de la sortie casque de la md1 est assez stupéfiante avec de très bon composant et superbement bien filtrée. A cote, la snes fait vraiment cheap

[Stef]

Soit la doc est fausse ou soit comme je te disais plus haut tu as confondu avec le nombre d'intensité de chaque composante RGB : 32 *32 * 32 = 32768.

Non ,et de plus ce que tu sors est complètement faux .
La snes à un encodage des couleurs RGB sur 15 bits soit 5 bits par composante, et ça fait 32768 couleurs possible soit 2^15.

Tu vois t'es incroyable quand même ! Tu répètes exactement ce que je dis et tu me dis que j'ai complètement faux

Bah ton erreur je te l'ai faite remarquée dessuite après le post ou tu les mettais (en te disans que c'était les specs de la PCE), mais bon tu vas encore dire que je mens .

Ben oui c'est toi qui a parlé de specs PCE mais parce-que tu as mal lu et/ou tout simplement parce que tu ne connaissais pas les specs de la SNES !
Je reprends mon post auquel tu as répondu ça :

Quand je dis 16 couleurs, je parle du nombre de couleurs par tile (bloc de 8x8), les plans sont composés de tiles pour former les arrières plans. Chaque tile pointe sur une des palettes 16 couleurs disponibles donc sur un même plan tu peux avoir 64 couleurs sur MD (car 4 palettes différentes) et 128 couleurs sur SNES (car 8 palettes pour les plans).

C'est pas ma faute si tu t'exprimes mal ..
Et puis je sais très bien comment cela fonctionne de plus la remarque d'un mec qui me donne les specs de la PCe pour celles de la SNES, c'est mal placé Cool ..
D'ailleurs il s'agit de 8 palettes de 32 couleurs et non de 16, les palettes des sprites ne sont pas dissociées de celle des tiles .

Et voilà, et derrière tu sors la mega connerie des palettes de 32 couleurs sur SNES.

Et je ne critique pas la MD sur ces capacité d'animation qui sont très bonne, mais sur ces specs générale qui sont ultras banales, ce qui pour moi ne lui permet pas d'avoir ce petit quelque chose qui m'attire, contrairement à la SNES ou la PCE .
Et puis les pros MD aiment aussi bien mettre des chiffres qui veulent rien dire ,mais tant qua ça peut avantager la Md, c'est tout bon.

La MD pour une console sorti 2 ans avant la SNES (et 2 ans en techno c'est énorme) s'en sort plus que bien face à cette dernière. Certes graphiquement elle est un peu à la traine, sur le son je trouve ça plus subjectif même si le chip SNES est sans contexte plus moderne. Mais le fait que la SNES ai si peu de puissance de traitement c'est quand même scandaleux pour une machine de cette époque.

Trop fort, des tiles = des cells
Une tiles (en hardware) est un carré de 8*8, un cell est un carré de 16*16, et que je sache l'organisation des tiles en VRAM est complètement différente de celle des sprites, elle est entrelacée.
Donc tu ne peux pas utiliser des données de sprites directement comme des tiles, et inversement.
Dire qu'un sprite est composé de tiles, est un abus de langage.

Là encore tu te plantes, tet que sur PCE tu fais la distinction cell/tiles etc.. mais sur MD les tiles sont communs comme je t'ai déjà dis, et on les appelle cell dans certaines docs. Et même sur SNES les tiles qui composent les sprites sont en 8x8, et heureusement sinon tu ne pourrais pas avoir de sprites de petites tailles (8x8). Donc oui ce sont des tiles :p

Ok, donc la détection est presque aussi pourrie que sur PCe alors .
Ensuite le bouding boxes, est la technique qui prend le moins de ressources CPU tout en étant suffisante, surtout si tu évites de la faire quand c'est pas necéssaire en utilisant la détection hard.
Et 500 collisions par frame , si c'était le cas, même pas la neo geo pourrait les traiter .
tu as max 20 sprites à l'écran, sachant que tous n'ont pas à avoir de collisions entre eux, tu dois dépenser en étant très large 600/700 cycles, pas de quoi s'affoler .
Les devs mettent en place des algos de trie des sprites pour ne pas avoir a faire des tests inutiles
Donc au final tu ne fait pas tes tests sur tout les sprites.

Bien sur que ça s'optimise et tu n'as pas le choix. 500 collisions par frame c'est quand même un cas extrême mais ça se fait (je l'ai déjà fait sur MD) et on est largement au dessus des 600/700 cycles (plutot 40000 dans mon cas mais ça tenait dans la frame)

Je suis d'accord, mais sur la snes, c'est pas CPU qui est en cause (tout en étant d'accord qu'il est loin de casser la baraque)

Le problème est qu'avec la slow ROM il peut être amené à fonctionner à 1.7 Mhz et dans ce cas, si, le CPU est vraiment anémique. En fait à part en RAM le CPU tourne rarement à 3.5 Mhz, c'est d'ailleurs la raison pour laquelle la SNES a le double de RAM centrale par rapport à la mégadrive (64 ko c'était déjà largement suffisant dans la MD), ça lui permet de déplacer du code en RAM pour pouvoir exploiter le CPU à fond.

[Invité]

oh la miss-quote 8)


Edit : a été editée

[Stef]

Si tu parles de la mienne je me loupe souvent au premier coup :p

[Invité]

Pour le son je veux dire que le filtre de la sortie son de la megadrive est vraiment d'exelldnte qualité. Aussi la qualité de la sortie casque de la md1 est assez stupéfiante avec de très bon composant et superbement bien filtrée. A cote, la snes fait vraiment cheap

Ah ok, c'est ce que j'ai pu lire effectivement, le soucis c'est que sa sortie mono je la trouve pas géniale .

Et j'ai pas testé avec un casque, après faut voir aussi la qualité du casque.

Là encore tu te plantes, tet que sur PCE tu fais la distinction cell/tiles etc.. mais sur MD les tiles sont communs comme je t'ai déjà dis, et on les appelle cell dans certaines docs. Et même sur SNES les tiles qui composent les sprites sont en 8x8, et heureusement sinon tu ne pourrais pas avoir de sprites de petites tailles (8x8). Donc oui ce sont des tiles :p

Bah c'est ce que je te dis, c'est un abus de langage .
On appelle tiles, les composantes d'un bckgnd
Et cell pour les sprites qui peuvent aussi être de 8*8 minimum dans les cas de la snes, MD je sais pas, PCE c'est 16*16 mini.

On différencie les 2 car leur gestion et leur organisation en RAM vidéo est complètement différente.

Bien sur que ça s'optimise et tu n'as pas le choix. 500 collisions par frame c'est quand même un cas extrême mais ça se fait (je l'ai déjà fait sur MD) et on est largement au dessus des 600/700 cycles (plutot 40000 dans mon cas mais ça tenait dans la frame)

Dans quel cas tu l'as fait sur MD ??? un demo ???, parce que faire 500 collisions par frame c'est sur que tu dépasses les 700 cycle, moi je parle en ne testant que ce qui doit être tester (ce qui est normal, les tirs du joueurs, ou des ennemis ne font pas de collisions entre eux déjà.
Dans un jeu normal, cela m'étonnerai fort qu'on en soit à ce niveau des 500, parce que dans une frame il te reste plus grand chose en CPU surtout dans un shoot ..

[Invité]

Si tu parles de la mienne je me loupe souvent au premier coup :p

yep , c'etait quand tu te répondais a toi meme qui etait touko en fait

c'est toujours comme ca quand on fait un gros code, un petit if mal {} au debut peut te fout' tes 1000 lignes de code dans le cul

[Stef]

Par contre la ou je rejoins stef, c'est au noiveau de la qualité de SORTIE de la megadrive, supérieur à celle de la snes.

C'est à dire ??

Fais un test d'écoute avec un bon casque sur la prise casque de la MD1.
Fais la même chose avec la SNES (sauf que pour la SNES, faudra prendre la sortie de la péritel, pas le choix).

[Stef]

yep , c'etait quand tu te répondais a toi meme qui etait touko en fait

c'est toujours comme ca quand on fait un gros code, un petit if mal {} au debut peut te fout' tes 1000 lignes de code dans le cul

Oui puis j'ai tendance à poster direct sans tester voir si ça apparait correctement :p

[Agathon]

Perso j'utilise 2 GRADO pour l'écoute au casque.

En fait la sortie casque de la md1 est tellement bonne quelle me drive mon sr325is réputé hyper difficile a driver.

Effectivement TOUKO, la sortie peritel de la md1 est étrangement mono, mais y a moyen de la shunter avec la sortie casque et de la rendre stéréo comme celle de la neogeo. Du coup, on se retrouve avec qualité stéréo sur peritel quisiment la meilleur du marché...

[Stef]

Salut stef,
ça me fait toujours plaisir de te lire, surtout pour celui qui a fait GENS (je ne me trompe n'est ce pas c'est bien toi?)
J'avais beaucoup aimé ton explications des capacités sonore de la MD que tu m'avais fourni sur msn y a assez longtemps de ça...

Salut Agathon,

Oui c'est bien moi, merci pour ton sympathique commentaire :)
je dois admettre ne plus trop me souvenir de notre conversation sur MSN mais bon depuis le temps ça m'étonne pas, j'ai mauvaise mémoire :p
La MD est réputé pour avoir un son pourri, je toruve ça un peu restrictif, je comprend qu'on puisse ne pas aimer son don MIDI métallique mais je trouve qu'elle a une très bonne qualité d'écoute si peu qu'on met un casque et qu'on choisi les bons jeux (du SOR2 au casque c'est toujours aussi jouissif). Je me souviens la première fois que j'ai branché un casque sur la sortie prévue à cette effet sur ma MD1, j'ai ressorti tout mes jeux et je les ai simplement redécouvert
Sur SNES j'avais fort heureusement une TV stéréo donc je pouvais déjà profiter de la stéréo par la TV, sur la MD1 le son péritel passe en mono, obligé d'utiliser le casque pour la stéréo.

[Stef]

Bah c'est ce que je te dis, c'est un abus de langage .
On appelle tiles, les composantes d'un bckgnd
Et cell pour les sprites qui peuvent aussi être de 8*8 minimum dans les cas de la snes, MD je sais pas, PCE c'est 16*16 mini.

On différencie les 2 car leur gestion et leur organisation en RAM vidéo est complètement différente.

Oui ben voilà, je me doutais que tu faisais allusion à la PCE, les structures des autres machines ressemblent mais ne sont pas identiques. Sur megadrive tu as 64 Ko de RAM vidéo et 4 palettes de 16 couleurs, tu peux tout mettre dedans comme bon te semble car tout est partagé et les adresses des tilemap et autres sprites list sont configurables. Sur SNES (et pas mal d'autres machines) tu as quelques contraintes, les tiles des background sont différenciés de ceux des sprites, idem pour les palettes, de même souvent les adresses des tilemaps et sprite list sont fixés.
Celà s'explique surement par le fait que les background et les sprites doivent être traités "en parallèle" par les processeurs vidéos. Sur MD le processeur vidéo a 2 BUS (un parallèle et un série) pour accéder à sa mémoire ce qui permet d'accéder à 2 zones différentes à la fois ce qui n'est pas le cas sur beaucoup d'autres machines.

Dans quel cas tu l'as fait sur MD ??? un demo ???, parce que faire 500 collisions par frame c'est sur que tu dépasses les 700 cycle, moi je parle en ne testant que ce qui doit être tester (ce qui est normal, les tirs du joueurs, ou des ennemis ne font pas de collisions entre eux déjà.
Dans un jeu normal, cela m'étonnerai fort qu'on en soit à ce niveau des 500, parce que dans une frame il te reste plus grand chose en CPU surtout dans un shoot ..

C'est pour faire un sample exemple que je fournis avec mon petit kit de développement MD, un mini jeu de shoot en quelque sorte (jamais fini donc jamais releasé)...
Avec 40000 cycles bouffés par la collision il t'en reste encore pas loin de 90000 pour le reste de la frame, c'est largement suffisant

[Invité]

Oui ben voilà, je me doutais que tu faisais allusion à la PCE, les structures des autres machines ressemblent mais ne sont pas identiques. Sur megadrive tu as 64 Ko de RAM vidéo et 4 palettes de 16 couleurs, tu peux tout mettre dedans comme bon te semble car tout est partagé et les adresses des tilemap et autres sprites list sont configurables. Sur SNES (et pas mal d'autres machines) tu as quelques contraintes, les tiles des background sont différenciés de ceux des sprites, idem pour les palettes, de même souvent les adresses des tilemaps et sprite list sont fixés.
Celà s'explique surement par le fait que les background et les sprites doivent être traités "en parallèle" par les processeurs vidéos. Sur MD le processeur vidéo a 2 BUS (un parallèle et un série) pour accéder à sa mémoire ce qui permet d'accéder à 2 zones différentes à la fois ce qui n'est pas le cas sur beaucoup d'autres machines.

Peut être comme toi tu penses MD
Par contre que ce soit sur PCE ou snes, il n'y a pas de sprites list mais une SAT (sprites attribute table) ou OAM sur la snes, mais c'est pareil, je pense que cela doit être du kif la bourique.
Tu entends quoi par adresses fixées ???

C'est pour faire un sample exemple que je fournis avec mon petit kit de développement MD, un mini jeu de shoot en quelque sorte (jamais fini donc jamais releasé)...
Avec 40000 cycles bouffés par la collision il t'en reste encore pas loin de 90000 pour le reste de la frame, c'est largement suffisant

Oui Donc une demo, parce que 90.000 pour tout le reste du jeu ça suffit pas ..
Du moins dans un jeu style gynoug par exemple ..
C'est énorme 40.000 cycle rien qu'en collisions, et je peux te garantir, qu'avec une telle conso tu vas pas loin.
Je suis sur qu'en utilisant les collisions hard+un algo de trie tu peux réduire drastiquement ce chiffre, a moins que ton écran soit bourré de sprites qui rebondissent partout et entre en collision.
Sans être mechant mais tester tout les sprites à chaque fois, c'est la methode bourrain

[Stef]

Peut être comme toi tu penses MD
Par contre que ce soit sur PCE ou snes, il n'y a pas de sprites list mais une SAT (sprites attribute table) ou OAM sur la snes, mais c'est pareil, je pense que cela doit être du kif la bourique.
Tu entends quoi par adresses fixées ???

J ai appelé sprite list par simplication, c est effectivement la meme chose sur les 3 machines en fait :p
Par adresse fixe j entends que la position de la SAT (pour te faire plaisir) est fixé en VRAM, sur certaines machines y a une zone mémoire dédiée. Sur MD tu la met ou tu veux en VRAM et tu configures sa position via un registre du VDP. Ca peut etre pratique pour switcher rapidement de liste en mid frame par ex.Ca se trouve c est pareil sur PCE, je la connais pas boen cette machine.

Oui Donc une demo, parce que 90.000 pour tout le reste du jeu ça suffit pas ..
Du moins dans un jeu style gynoug par exemple ..
C'est énorme 40.000 cycle rien qu'en collisions, et je peux te garantir, qu'avec une telle conso tu vas pas loin.
Je suis sur qu'en utilisant les collisions hard+un algo de trie tu peux réduire drastiquement ce chiffre, a moins que ton écran soit bourré de sprites qui rebondissent partout et entre en collision.
Sans être mechant mais tester tout les sprites à chaque fois, c'est la methode bourrain

90000 pas suffisant pour le reste de la frame ??? Tu rigoles ? Tet que sur PCE tu as besoin de bcp pour le reste mais sur MD le reste ne prend pas tant (le son est géré par le z80).
Bon nombre de jeux MD doivent utiliser meme pas 50% du cpu et 90000 cycles ca en fait encore pas loin de 70% ! Bien sur j ai utilisé la méthode bourrin mais parce que je peux le faire... Tant que ça ne ralenti pas, je me casse pas. Enfin tout ca est un autre débat...

[Invité]

J ai appelé sprite list par simplication, c est effectivement la meme chose sur les 3 machines en fait :p
Par adresse fixe j entends que la position de la SAT (pour te faire plaisir) est fixé en VRAM, sur certaines machines y a une zone mémoire dédiée. Sur MD tu la met ou tu veux en VRAM et tu configures sa position via un registre du VDP. Ca peut etre pratique pour switcher rapidement de liste en mid frame par ex.Ca se trouve c est pareil sur PCE, je la connais pas boen cette machine.

Sur PCE ça fonctionne pas vraiment comme ça, tu as une zone mémoire interne au VDC ou est stockée la SAT, elle n'est pas accessible directement par l'utilisateur, donc on a une SAT virtuelle en VRAM, que tu positionnes ou tu veux,la maj de la SAT du VDC se fait via un canal DMA, à chaque vsync de facon automatique (débrayable) .
Donc impossible (à mon avis de faire du multiplexage de sprites par exemple).

! Bien sur j ai utilisé la méthode bourrin mais parce que je peux le faire... Tant que ça ne ralenti pas, je me casse pas..

Ok, tout à fait, mais je suis quand même perplexe sur les 90.000 suffisant. ,cela dépend vraiment du type de jeu .

[Stef]

Sur PCE ça fonctionne pas vraiment comme ça, tu as une zone mémoire interne au VDC ou est stockée la SAT, elle n'est pas accessible directement par l'utilisateur, donc on a une SAT virtuelle en VRAM, que tu positionnes ou tu veux,la maj de la SAT du VDC se fait via un canal DMA, à chaque vsync de facon automatique (débrayable) .
Donc impossible (à mon avis de faire du multiplexage de sprites par exemple).

Ok donc sur PCE ça ressemble à beaucoup d'autres système ou la position de la SAT est fixée dans une zone mémoire spéciale. Sur MD si tu modifies les données de la SAT (n'importe où en VRAM donc) pendant la frame l'info est prise en compte immédiatement. En fait c'est pas si simple car y'a un cache de certaines données de la SAT dans le VDP et un bug fait que certaines informations ne sont pas correctement refetchées depuis la SAT dans certains cas particuliers (un jeu exploite ce bug d'ailleurs, coriace à émuler correctement).

Ok, tout à fait, mais je suis quand même perplexe sur les 90.000 suffisant. ,cela dépend vraiment du type de jeu .

90000 cycles par frame c'est déjà beaucoup, c'est comme si tu avais un 68000 à 5Mhz et pour la majorité des jeux MD ça serait bien suffisant... la plupart des jeux MD font rentrer tout leur process dans le vblank, ça fait bien moins que 90000 cycles.

[Invité]

Ok donc sur PCE ça ressemble à beaucoup d'autres système ou la position de la SAT est fixée dans une zone mémoire spéciale. Sur MD si tu modifies les données de la SAT (n'importe où en VRAM donc) pendant la frame l'info est prise en compte immédiatement. En fait c'est pas si simple car y'a un cache de certaines données de la SAT dans le VDP et un bug fait que certaines informations ne sont pas correctement refetchées depuis la SAT dans certains cas particuliers (un jeu exploite ce bug d'ailleurs, coriace à émuler correctement).

Ok, je pense que ça doit permettre quelques effets sympa sur les sprites .
C'est ce qui fait les bons emulateurs, avoir les même bugs que le vrai hard.

[Invité]

bon le débat technique ça va 5min , on pourrait revenir à de la bonne mauvaise foi à l'ancienne ?

la vitesse de sonic c'est pour cacher la misère ? ghouls'n ghost peut il tourner sur coleco ? altered beast est il le shaqfu de la snes ?

[Invité]

bon le débat technique ça va 5min , on pourrait revenir à de la bonne mauvaise foi à l'ancienne ?

En mode rétro ! :)

Altered beast est une bouse immonde.

[Invité]

T'as bien raison, c'est clair que la Md pue face à la snes et ses effets cablés (mode 7 ,transparences etc ...) ..

Et puis sonic faut pas déconner, surtout avec DKC 2 en face .
Tu rajoutes FF en face de cette merde de SOR.

Et oui la vitesse c'est pour cacher la misère ,décors pauvres, aussi bien en couleurs qu'en détails, sprites rikikis etc ...

Putin le troll des fois y'a que ca de vrai

[Invité]

Un jour il faudra évoquer le mode 7, honnêtement je trouve pas ça atroce (moins qu'une palette criarde de Golden Axe 1 ou 2), et il y a une sorte de rejet de principe. Pourquoi ne pas utiliser une routine hardware, puisqu'elle est là, après tout ?
Les astuces de programmation, c'est très bien, mais utiliser le hardware en somme précâblé, je ne vois pas le problème.

[Agathon]

bah c'est sur que de diriger un plombier moche et gros sans charisme fister des tuyaux au lieu d'une meuf aussi belle que martine aubry c'est beaucoup plus sexy... :lol: