Re: MEGADRIVE vs SUPER NINTENDO : Fight !

[Invité]

en meme temps les gens on est ok que l'interet d'un jeu ne se calcule pas en fonction du nombre de sprites à afficher en 10 couleurs en 3 nano secondes, non ? (rassurez moi, parce que dans ce cas la ca voudrait dire que les jeux XBOX360 sont 1000000 fois mieux en interet que les jeux MD et SNES ... et c'est loin d'etre le cas :))

[Invité]

en meme temps les gens on est ok que l'interet d'un jeu ne se calcule pas en fonction du nombre de sprites à afficher en 10 couleurs en 3 nano secondes, non ? (rassurez moi, parce que dans ce cas la ca voudrait dire que les jeux XBOX360 sont 1000000 fois mieux en interet que les jeux MD et SNES ... et c'est loin d'etre le cas :))

Pour le pro-MD si, le seul truc qui importe c'est la vitesse. :lol:

[Invité]

en meme temps les gens on est ok que l'interet d'un jeu ne se calcule pas en fonction du nombre de sprites à afficher en 10 couleurs en 3 nano secondes, non ? (rassurez moi, parce que dans ce cas la ca voudrait dire que les jeux XBOX360 sont 1000000 fois mieux en interet que les jeux MD et SNES ... et c'est loin d'etre le cas :))

Pour le pro-MD si, le seul truc qui importe c'est la vitesse. :lol:

ah bah non ... ou alors mon jeu préféré ne serait pas Landstalker ou Splatter House (dans les 2 cas, je crois qu'il y a meme pas 3 sprites simulatanés par écran haha) :)

Après si Thunder Force III avait autant ramé sur MD que sur la SNES, je pense pas que je l'aurais trouvé culte ! :)

[Invité]

Final Fight CD: jusqu'à preuve du contraire et tant que je n'aurais pas vu une petite démo du jeu qui tourne à l'identique sur une cartouche MD, je ne pourrais pas te croire.

Déjà on a quasiment, si ce n'est aucun beat them all MD qui peut concurrencer FF CD au niveau de la taille des sprites, sachant que FF CD a les deux, des sprites en nombre et de grande taille.

Et si c'était tellement simple de sortir FF sur cartouche mais pourquoi ils se sont embêté avec une extension hors de prix, tu me dis que les 2 68000 peuvent fonctionner de concert, c'est bien ce que je pensais depuis le début. Je suppose que tu as anaysé le code de FF pour affirmer qu'il n'a pas besoin du 68000 du Mega cd ? pas besoin le blast processing à 7,5Mhz de la MD suffit amplement pour ce "petit" jeu, pas besoin non plus de la ram video supplémentaire du MCD.

Tu peux vérifier facilement (enfin normalement), en faisant tourner le jeu sous emulateur, et en désactivant des fonctionnalités du MCD en cours de partie ..
Tu verras ce que ca donne ..

[Stef]

Tu déconnes j'espère ??
Alimenter en quoi ??
en voyant large, pour un scroll vertical c'est 128 octets toutes les 8 frames, et en horizontal,ça change rien ..
en délayant on passe à 16 octets/frame, ça demande pas des perfs démoniaques.

les tiles en vram(si tu dois en changer), tu peux les mettre petits a petit en vram durant ces 8 frames, via le DMA ça pose aucun soucis .
Là aussi en horizontal ça change rien par rapport au H32 .

ca prend surtout pas mal de place en rom, ça oui ...

Je ne parle pas forcément des scroll mais plutot des sprites, forcement tu dois fournir plus de pixels de sprite pour alimenter une resolution plus haute.
Et même pour les scrolling, à scrolling équivalent de la base résolution tu vas devoir mettre à jour 4x plus de tiles ! c'est loin d'être négligeable.
Puis la haute résolution est limité en terme de plan, 1 plan 16 couleurs avec scroll ou 1 plan 16 + 1 plan 4 couleurs sans scroll. Ce qui explique surement pourquoi 1 seul jeu l'utilise in game.

Sur MD tu as 2 ou 3 jeux qui utilisent le mode 320x448/480 (dont Sonic 2 en mode 2 joueurs).

[Stef]

Final Fight CD: jusqu'à preuve du contraire et tant que je n'aurais pas vu une petite démo du jeu qui tourne à l'identique sur une cartouche MD, je ne pourrais pas te croire.

Déjà on a quasiment, si ce n'est aucun beat them all MD qui peut concurrencer FF CD au niveau de la taille des sprites, sachant que FF CD a les deux, des sprites en nombre et de grande taille.

Et si c'était tellement simple de sortir FF sur cartouche mais pourquoi ils se sont embêté avec une extension hors de prix, tu me dis que les 2 68000 peuvent fonctionner de concert, c'est bien ce que je pensais depuis le début. Je suppose que tu as anaysé le code de FF pour affirmer qu'il n'a pas besoin du 68000 du Mega cd ? pas besoin le blast processing à 7,5Mhz de la MD suffit amplement pour ce "petit" jeu, pas besoin non plus de la ram video supplémentaire du MCD.

Il faut que tu saches quelque chose à propos du Mega CD, il utilise le processeur vidéo de la megadrive. C'est à dire que tout ce qui s'affiche quand tu joues à un jeu MegaCD garde les mêmes contraintes que le processeur video de la MD, ce qui explique, par exemple, pourquoi on ne peut pas avoir de rotation en plein écran à 60 FPS malgré la préence de la puce vectorielle (manque de bande passante sur le VDP MD).
Donc tout les gros sprites de Final Fight sont affichés par le VDP de la MD...
Y'a pas de RAM video dans le MegaCD, y'a de la word RAM, principalement utilisée par la puce vectorielle (non utilisée dans ce jeu)... d'ailleurs si tu ouvres un debugger dans un émulateur tu remarqueras que la word ram contient encore les logos du BIOS une fois le jeu lancé ce qui montre qu'elle n'est clairement pas utilisée.
Le support CD a permis probablement de faire rentrer plus facilement tout les frames d'animation (même si ça rentrerait assez facilement avec une ROM de 3 ou 4 Mo) et surtout d'ajouter les cinématiques et les musiques CD.
Final Fight CD a été développé par Sega, c'était clairement pour faire vendre son MegaCD que Sega a décidé de le sortir sur ce support. D'ailleurs le jeu sur arcade fonctionne à partir d'un hardware similaire à la megadrive (CPS-1) si on met la partie vidéo de côté...
Et oui j'ai analysé le code de Final Fight CD, j'ai du pas mal débuggé ce jeu pour développer mon émulateur MegaCD, je voulais à tout prix faire marcher ce jeu donc j'ai du pas mal analyser son code...

Pour BC Racers, justement on a des gars qui ont fait Soul Star, qui connaissent le Mega CD, qui savent l'exploiter et ils nous pondent ça : un mode 2 joueurs en coop, il y a un soucis et je ne déconne pas pour le mode 2 joueurs de la version 32x, on est sur du mode 7 Snes ni plus, ni moins vu qu'ils ont virés tous les bâtiments.
Pour le mode 1 joueur, ça ne se discute pas, il y a un paquet de
bâtiments qui sont autant de sprites zoomés, je sais bien que la Snes ne
pourrait pas gérer ça mais le mode 2 joueurs, c'est du mode 7 Snes, en
tout cas c'est vraiment l'impression que ça me donne.

Je viens de tester et faut pas exagérer, en mode 2 joueurs certes il manque certains éléments de décor (comme les batiments) mais il te reste tout le reste (arbre, panneau...), on est quand même loin du mode 7.

Enfin qu'apporte la version 32x ? Le jeu est identique à la version MCD, sauf peut être un poil plus fluide et avec le mode 2 joueurs appauvri visuellement.

A l'inverse du MegaCD le 32X fait tout en soft via la puissance de ses CPU, le MegaCD a une assistance hardware pour déformer (zoom, rotation...) des objets.
Donc pour ce type de jeu le MegaCD s'en sort assez bien, par contre il reste bridé au perf du VDP megadrive, soit du 15 FPS max pour rafraichir tout l'écran.
Le 32X a beaucoup de puissance brute mais du coup le résultat est très dépendant de l'effort de développement, il faut savoir qu'une grosse partie des productions 32X n'utilise qu'un seul des 2 CPU centraux ou souvent le 2e n'est utilisé que pour la musique (ce qui est un gachi total). Bien utilisé le 32X aurait vraiment pu faire de belles choses... mais bon c'est une machine qui n'avait aucun avenir dans son contexte.
Je pense que Sega aurait plutot du en faire une machine en standalone, comme une console 32 bits du "pauvre", son architecture est très interessante pour les developpeurs (peu d'assistance mais beaucoup de puissance brute).

[Alucardark]

D'ailleurs le jeu sur arcade fonctionne à partir d'un hardware similaire à la megadrive (CPS-1) si on met la partie vidéo de côté...

Hmmmm...J'viens de faire un tour sur le wiki us et effectivement le CPS-1 a un processeur central Motorola 68k et un Z80 (même le niveau de leur fréquence est proche de la Megadrive, j'apprends quelque-chose là ). Ce qui me fait dire que les adaptations foiré des hits de Capcom sur Megadrive tels que Ghouls'n Ghost et Forgotten Worlds, sont vraiment dus à une bande d'incapables.

Sinon question bête, mais quels sont les jeux justement utilisant pleinement les 2 CPU de la 32X?

[Invité]

Hé oui, comme quoi tout n'est pas affaire de processeur central, n'en déplaise aux amis de la MD...

[Invité]

Je ne parle pas forcément des scroll mais plutot des sprites, forcement tu dois fournir plus de pixels de sprite pour alimenter une resolution plus haute.
Et même pour les scrolling, à scrolling équivalent de la base résolution tu vas devoir mettre à jour 4x plus de tiles ! c'est loin d'être négligeable.
Puis la haute résolution est limité en terme de plan, 1 plan 16 couleurs avec scroll ou 1 plan 16 + 1 plan 4 couleurs sans scroll. Ce qui explique surement pourquoi 1 seul jeu l'utilise in game.

Sur MD tu as 2 ou 3 jeux qui utilisent le mode 320x448/480 (dont Sonic 2 en mode 2 joueurs).

Oui bien sur il faut meubler tout ça, le chip video de la snes est sensé pouvoir de toutes façons ..
Oui la limite de plan rajoute en plus une limite, mais même avec un plan on aurai pu avoir une ou 2 jeux sympa ..

A ce niveau la SGX fait mieux, vu qu'elle peut faire du 512 en conservant ses 2 plans ..
Pour les maj de tiles, tu pars avec une ligne/colonne d'avance, et tu mets à jour toutes les frames un peu de données, rien de difficile .
Bcp de jeux font ça, ils mettent jamais un écran complet .

[Invité]

Hmmmm...J'viens de faire un tour sur le wiki us et effectivement le CPS-1 a un processeur central Motorola 68k et un Z80 (même le niveau de leur fréquence est proche de la Megadrive, j'apprends quelque-chose là ). Ce qui me fait dire que les adaptations foiré des hits de Capcom sur Megadrive tels que Ghouls'n Ghost et Forgotten Worlds, sont vraiment dus à une bande d'incapables.

Tu sais la MD n'a pas été la seule console touchée par ce type de problème ..
Quand tu vois strider sur PCE, qui est plus que pitoyable, et en plus il utilise le CD+arcade card ..

[Stef]

Hmmmm...J'viens de faire un tour sur le wiki us et effectivement le CPS-1 a un processeur central Motorola 68k et un Z80 (même le niveau de leur fréquence est proche de la Megadrive, j'apprends quelque-chose là ). Ce qui me fait dire que les adaptations foiré des hits de Capcom sur Megadrive tels que Ghouls'n Ghost et Forgotten Worlds, sont vraiment dus à une bande d'incapables.

Au début tu pouvais encore leur trouver l'excuse de la taille de la ROM (512 KB c'est qd même peu) mais après avec les roms de 2, 3 et 4 Mo c'est beaucoup plus surprenant... la MD était capable de refaire des transcriptions fidèles des hits d'arcade. Son processeur vidéo est quand même plus limité que ceux des systèmes d'arcade de l'époque mais quand tu vois Final Fight CD tu vois bien qu'il était quand même capable de bien mieux que ce qu'on a pu voir en général.
Par exemple Street Fighter 2 ne fait pas honneur à la MD, on voit bien que Capcom s'est basé sur la version SNES et qu'il n'a pas cherché à exploiter les capacités la MD (on aurait pu avoir du 320 en resolution horizontal et des sprites un peu plus grand).

Sinon question bête, mais quels sont les jeux justement utilisant pleinement les 2 CPU de la 32X?

De mémoire je me souviens surtout des jeux en full 3D comme Virtua Racing, Virtua Fighter, Star wars... ce qui m'avait pas mal surpris car je les trouvais pas si impressionnants. Doom était particulièrement foireux, déjà parce-qu'il n'utilise qu'un CPU mais en plus il execute une bonne partie de son code directement depuis la ROM ce qui est terrible sur 32X car la ROM ajoute plein de wait state (il faut placer le code critique dans la RAM du 32X pour qu'il puisse l'executer plus rapidement). Enfin le 32X est de toute manière assez chiant à utiliser en général, il est bridé par la taille de la rom, par la taille de la RAM... bref du beau gachi

[Stef]

Hé oui, comme quoi tout n'est pas affaire de processeur central, n'en déplaise aux amis de la MD...

Au contraire, ça montre surtout à quel point la MD n'a pas été exploitée

[Stef]

Oui bien sur il faut meubler tout ça, le chip video de la snes est sensé pouvoir de toutes façons ..

Pas vraiment puisque les capacités de sprites restent inchangé par exemple. Comme la bande passante en général.

Pour les maj de tiles, tu pars avec une ligne/colonne d'avance, et tu mets à jour toutes les frames un peu de données, rien de difficile .
Bcp de jeux font ça, ils mettent jamais un écran complet .

Comme je disais pour un scroll lent et uni directionnel c'est faisable, pour un jeu comme sonic où tu scrolles dans n'importe quel sens, rapidement et avec des structures complexes c'est juste impensable :p

[Invité]

Comme je disais pour un scroll lent et uni directionnel c'est faisable, pour un jeu comme sonic où tu scrolles dans n'importe quel sens, rapidement et avec des structures complexes c'est juste impensable :p

C'est vrai que des jeux au scrolling rapide et multidirectionnel y'a que ca comme jeux ..
La majorité des jeux, même les shoots, font presque que du unidirectionnel V ou H, et même du bi, c'est à la frame, voire 2 frames, donc je vois pas ou est le problème .
En envoyant peu de données / frame c'est largement faisable avec le DMA,et ou le HDMA .
Surtout si tu choisis la réso 512*224.
Pour les sprites à l'écran, un moteur comme celui de RR/SA suffirait largement .
Et d'ailleurs la doc officielle fait mention d'une technique pour passer outre la limitation par ligne, surement utilisée par RR .

@philipp :Je viens aussi de voir que la snes fait du flip de tile H/V donc, finalement c'est la meilleure pour gérer les backgrounds, surtout avec son mode 256/16 couleurs / tiles en 2 playfield .

Des fonctions hardware de multiplications/divisions très rapides ..

Pour ceux que ça intéresse la doc officielle SNES : http://www.romhacking.net/documents/226/

[Alucardark]

Tu sais la MD n'a pas été la seule console touchée par ce type de problème ..
Quand tu vois strider sur PCE, qui est plus que pitoyable, et en plus il utilise le CD+arcade card ..

Ouais pitoyable est quand même un bien grand mot pour cette version, je dirais plus décevante surtout au niveau de l'attente suscité pour la version SGX.

Au début tu pouvais encore leur trouver l'excuse de la taille de la ROM (512 KB c'est qd même peu) mais après avec les roms de 2, 3 et 4 Mo c'est beaucoup plus surprenant... la MD était capable de refaire des transcriptions fidèles des hits d'arcade. Son processeur vidéo est quand même plus limité que ceux des systèmes d'arcade de l'époque mais quand tu vois Final Fight CD tu vois bien qu'il était quand même capable de bien mieux que ce qu'on a pu voir en général.
Par exemple Street Fighter 2 ne fait pas honneur à la MD, on voit bien que Capcom s'est basé sur la version SNES et qu'il n'a pas cherché à exploiter les capacités la MD (on aurait pu avoir du 320 en resolution horizontal et des sprites un peu plus grand).

C'est vrai que les premières cartouches embarquaient peu de places (enfin à l'époque c'était quand même pas mal de place). Mais si ils avaient attendu 1 an de plus ils auraient pu sortir une version un peu plus réussie du hit de Capcom. D'ailleurs j'avais tenté de reproduire le premier niveau avec SonED2 (un éditeur de niveaux de Sonic 2) et franchement au niveau couleur c'est faisable, en plus ça donne bien avec la réso de la Megadrive. Bon après n'étant pas programmeur je me suis arrêté à peine au début du stage, donc je ne saurai jamais si ça aurait été faisable à 100%.

De mémoire je me souviens surtout des jeux en full 3D comme Virtua Racing, Virtua Fighter, Star wars... ce qui m'avait pas mal surpris car je les trouvais pas si impressionnants. Doom était particulièrement foireux, déjà parce-qu'il n'utilise qu'un CPU mais en plus il execute une bonne partie de son code directement depuis la ROM ce qui est terrible sur 32X car la ROM ajoute plein de wait state (il faut placer le code critique dans la RAM du 32X pour qu'il puisse l'executer plus rapidement). Enfin le 32X est de toute manière assez chiant à utiliser en général, il est bridé par la taille de la rom, par la taille de la RAM... bref du beau gachi

Donc en fait la 32X n'a jamais été réellement utilisé de manière optimale...effectivement c'est du beau gâchis.

P.S. : Dans un de tes posts tu disais que Final Fight était faisable en utilisant uniquement la Megadrive...t'avais pas vraiment tort.
https://www.youtube.com/watch?v=1XsFYSnPBSo

[Invité]

P.S. : Dans un de tes posts tu disais que Final Fight était faisable en utilisant uniquement la Megadrive...t'avais pas vraiment tort.
https://www.youtube.com/watch?v=1XsFYSnPBSo

Pffff, depuis quand d'artagnan il connait quelque chose à FF ??
J'étais pété de rire, je l'imaginais, mais alors pas du tout comme ça fonzie .

[Stef]

C'est vrai que des jeux au scrolling rapide et multidirectionnel y'a que ca comme jeux ..
La majorité des jeux, même les shoots, font presque que du unidirectionnel V ou H, et même du bi, c'est à la frame, voire 2 frames, donc je vois pas ou est le problème .

Ouais enfin tu sembles quand même assez optimiste sur la manière de gérer un scrolling. Si le scrolling est uni directionnel et assez lent pas de soucis. Si déjà tu peux retourner en arrière ça complique pas mal les choses (gestion d'un cache) et si c'est comme dans un sonic (H & V avec retour arrière) ça devient carrément compliqué, surtout si tu veux pouvoir te déplacer rapidement dans des architectures complexes (et donc avec des tilemap compressés). Enfin juste pour dire que dans la pratique la gestion d'un scrolling est un peu plus complexe qu'il ne parait
Je ne parle pas d'un problème de bande passante mais plus de charge cpu.

Pour les sprites à l'écran, un moteur comme celui de RR/SA suffirait largement .
Et d'ailleurs la doc officielle fait mention d'une technique pour passer outre la limitation par ligne, surement utilisée par RR .

Alors là je serais curieux de voir ça, si tu retrouves des infos là dessus je suis preneur ! Sur MD il n'y a, à ma connaissance, aucun moyen d'outre passer cette limite (qui est la seule qui s'applique au final quand on parle des capacités de sprites sur la MD)

[Stef]

P.S. : Dans un de tes posts tu disais que Final Fight était faisable en utilisant uniquement la Megadrive...t'avais pas vraiment tort.
https://www.youtube.com/watch?v=1XsFYSnPBSo

Pffff, depuis quand d'artagnan il connait quelque chose à FF ??
J'étais pété de rire, je l'imaginais, mais alors pas du tout comme ça fonzie .

Il n'a pas toujours eu la moustache...
Mais bon en meme temps c'est normal que tu puisses le reproduire sur MD. Final Fight CD est surtout impressionnant sur la taille et l'animation de ses sprites et cette partie doit de toute manière passer par la megadrive, tu n'as pas le choix donc c'est *forcément* reproductible.

[tbp]

Rendering ranger se fait enterrer par Doom Troopers

Ben c' est vrai que les megaman X, le 7, les street fighters et cie, starfox, super metroid, sunset riders, wild guns,
r-type, turtles in time, rushing beat, ninja wariors, super turican 2, et d'autres que j' oublie, se sont tout sauf des jeux d' action.
Pour moi, y' a pas photo. Si shinobi 3, gunstar heroes et sonic sont bons, ils font pas le poids face à tout ce qui se passe en sur la concurrente.

Konami avec Turtles in time a réalisé la prouesse technique d'afficher plus de 3 ennemis à l'écran en simultané sur SNES dans un beat. Le Rushing beat 3 est bien, mais les 2 premiers ne sont pas terribles et sont loins d'être de bons exemples dans le genre.
Je préfère Shinobi 3 ou Revenge of Shinobi à Hagane. De bons effets techniques d'esbrouffe ne font pas la valeur ludique d'un jeu. Cela peut même contribuer à dissimuler les faiblesses moins évidentes ou moins immédiates à déceler d'un jeu.

[philip]

@touko. Je connais, à mon petit niveau, la lynx et la MD, mais surtout la md grâce à stef, j'ai aussi exploré d'autres consoles (NES et pc-engine) mais j'aimerai bien que stef ce penche sur le berceau de la neogeo, pour un sngdk (un vrai phantasme pour moi).

Mais je n'ose pas lui demander (par timidité).

[Alucardark]

Mais bon en meme temps c'est normal que tu puisses le reproduire sur MD. Final Fight CD est surtout impressionnant sur la taille et l'animation de ses sprites et cette partie doit de toute manière passer par la megadrive, tu n'as pas le choix donc c'est *forcément* reproductible.

J'ai toujours pensé que les jeux Mega CD passaient par le processeur du Mega CD et non de la Megadrive, d'où mon étonnement.

[Stef]

J'ai toujours pensé que les jeux Mega CD passaient par le processeur du Mega CD et non de la Megadrive, d'où mon étonnement.

Pas pour l'affichage... je me souviens que dans les magasines à l'époque on lisait souvent que le MegaCD pouvait afficher 128 couleurs là ou la MD en affichait 64, c'était totalement ridicule. Le processeur central du Mega CD est plus lié à la gestion des données CD, alimentation de la puce vectorielle et chip sonore PCM du MegaCD mais il ne peut pas accéder directement au VDP de la megadrive (qui est côté CPU MD).

[Stef]

@touko. Je connais, à mon petit niveau, la lynx et la MD, mais surtout la md grâce à stef, j'ai aussi exploré d'autres consoles (NES et pc-engine) mais j'aimerai bien que stef ce penche sur le berceau de la neogeo, pour un sngdk (un vrai phantasme pour moi).

Mais je n'ose pas lui demander (par timidité).

Hélas vu déjà comment que j'ai bien peu de temps à consacrer à la MD en ce moment je vois mal comment je pourrais faire aussi de la NeoGeo (que je connais quasiment pas). Il y a une raison pour laquelle j'ai fait SGDK (donc pour la MD), c'est que je connais bien la machine Ca me prendrais *beaucoup* plus de temps de faire ça sur une autre machine que je connais moins voire pas du tout :-/

[Alucardark]

Pas pour l'affichage... je me souviens que dans les magasines à l'époque on lisait souvent que le MegaCD pouvait afficher 128 couleurs là ou la MD en affichait 64, c'était totalement ridicule. Le processeur central du Mega CD est plus lié à la gestion des données CD, alimentation de la puce vectorielle et chip sonore PCM du MegaCD mais il ne peut pas accéder directement au VDP de la megadrive (qui est côté CPU MD).

Bizarre comme architecture, mais ça aurait pas été mieux de faire comme pour l'extension CD de la PC Engine en utilisant le processeur de la console quitte à virer tout les artifices?

[Invité]

Mais je n'ose pas lui demander (par timidité).

LOL, bah là c'est fait au moins
Mais y'a déjà un kit pour NG il me semble ..

Ouais enfin tu sembles quand même assez optimiste
sur la manière de gérer un scrolling. Si le scrolling est uni
directionnel et assez lent pas de soucis. Si déjà tu peux retourner en
arrière ça complique pas mal les choses (gestion d'un cache) et si c'est
comme dans un sonic (H & V avec retour arrière) ça devient
carrément compliqué, surtout si tu veux pouvoir te déplacer rapidement
dans des architectures complexes (et donc avec des tilemap compressés).
Enfin juste pour dire que dans la pratique la gestion d'un scrolling est
un peu plus complexe qu'il ne parait
Je ne parle pas d'un problème de bande passante mais plus de charge cpu.

Je suis pas optimiste, c'est pas la première fois que je fais un scrolling de ce type, j'ai utilisé ce système déjà sur PCE, tout au CPU, en C, et pas optimisé du tout(dans mes premiers mois de dev PCE) ..
Ca consomme que dalle, surtout avec le DMA de la SNES, et si tu rajoutes le h-DMA en plus ..
Faut arrêter de croire que la moindre chose sur snes est impossible juste par envie de casser du nintendo,et t'as pas forcement toutes les tiles à balancer en VRAM si ton tileset y est déjà,donc juste la BAT à mettre à jour,c'est fait pour ça il me semble, non !! ..

C'est toi qui compliques pour chercher la petite bête, pourquoi prévoir des trucs improbables (des trucs que tu vois quasiment jamais) histoire de vouloir avoir raison,comme si tout les jeux faisaient ça ..
T'en vois bcp des shoots comme ça sur MD ??,ca m'étonnerai fort .

Donc tout ce qui ne fait pas comme sonic, est forcement pourri ,c'est ça ??

Alors là je serais curieux de voir ça, si tu retrouves
des infos là dessus je suis preneur ! Sur MD il n'y a, à ma
connaissance, aucun moyen d'outre passer cette limite (qui est la seule
qui s'applique au final quand on parle des capacités de sprites sur la
MD)

Bon je suis pas arrivé à faire un copier/collé du pdf, donc je met une image ..



Je pense qu' il s'agit d'un multiplexage .

[Stef]

Je suis pas optimiste, c'est pas la première fois que je fais un scrolling de ce type, j'ai utilisé ce système déjà sur PCE, tout au CPU, en C, et pas optimisé du tout(dans mes premiers mois de dev PCE) ..
Ca consomme que dalle, surtout avec le DMA de la SNES, et si tu rajoutes le h-DMA en plus ..
Faut arrêter de croire que la moindre chose sur snes est impossible juste par envie de casser du nintendo,et t'as pas forcement toutes les tiles à balancer en VRAM si ton tileset y est déjà,donc juste la BAT à mettre à jour,c'est fait pour ça il me semble, non !! ..

Pas la peine de t'emballer, puis osef du dma ici, le tilemap (ou bat) ne represente rien en data, c juste la gestion de sa mise a jour qui peut demander un peu de temps. Dans la plupart des jeux ca represente pas grand chose mais a t'entendre c'est negligeable alors que c'est tres dependant du type du jeu c'est tout...
Dans un jeu comme sonic ca coute tres cher, dans un bete shoot ca coutera rien ou presque.

C'est toi qui compliques pour chercher la petite bête, pourquoi prévoir des trucs improbables (des trucs que tu vois quasiment jamais) histoire de vouloir avoir raison,comme si tout les jeux faisaient ça ..
T'en vois bcp des shoots comme ça sur MD ??,ca m'étonnerai fort .

Tu sais qu'il y a d'autres type de jeux ?? je sais que t'es pas habitué avec la pce mais quand meme :p

Pour la doc sur les sprites je n'ai rien vu qui laisse entendre qu'on passe la limite par ligne. J'ai juste l'impression qu'il parle de la limite de 128 sprites mais bon celle la elle est beaucoup moins genante, surtout sur snes...

[Invité]

Pas la peine de t'emballer, puis osef du dma ici, le tilemap (ou bat) ne represente rien en data, c juste la gestion de sa mise a jour qui peut demander un peu de temps. Dans la plupart des jeux ca represente pas grand chose mais a t'entendre c'est negligeable alors que c'est tres dependant du type du jeu c'est tout...
Dans un jeu comme sonic ca coute tres cher, dans un bete shoot ca coutera rien ou presque.

Je m'emballe pas, je te parle de DMA pour pas que tu me sortes que le CPU est trop lent pour les transferts ..

Et vu qu'en général tu as plutôt tendance à modifier la bat que les tiles en vram, car ta map est en rom ,donc avec l'auto-incrementation de la vram, c'est finger in the noze à faire
tu pointes sur le bon offset en rom, et tu transfères en VRAM ..
Aucun intérêt à raffraichir les tiles en vram si tu peux t'en passer,ou si c'est plus rapide que de modifier la BAT .

Donc c'est ce je te dis, si ton tileset tient en vram, tu modifies que la BAT ..
Tu uploades que quand nécessaire, ou de façon différée,par chunk de données .
Pour un écran 512*224 en scroll multidirectionnel, tu dois transférer 2944 octets toutes les 8 frames, donc / frame ,368 octets(480 en 512*448), pas de quoi mettre à genoux quoi que ce soit ..

Tu sais qu'il y a d'autres type de jeux ?? je sais que t'es pas habitué avec la pce mais quand meme :p

Ah bon ???, on m'aurai menti alors ???
Mais bon quand tu prends un exemple qui concerne 1 jeu sur 100 faut pas pousser quand même ..

Pour la doc sur les sprites je n'ai rien vu qui laisse entendre qu'on passe la limite par ligne. J'ai juste l'impression qu'il parle de la limite de 128 sprites mais bon celle la elle est beaucoup moins genante, surtout sur snes...

Bon, faut que je traduise alors ???

Comme mentionné au dessus, un nombre limité d'objet peuvent être affichés sur une ligne, blablabla
Cependant,quelques fois les objets ont besoin d'être affichés au delà de cette limite

Rien de plus explicite je pense
Et je pense pas qu'avec 128 sprites dispos/frame, tu ais besoin de multiplexage

[Invité]

vous etes tarés les mecs :)

pourquoi ne developpez vous pas une demo sur chacune de vos consoles favorites : ca serait mieux que vos concours de zezettes de DMA CPU tiles :)

[Stef]

Et vu qu'en général tu as plutôt tendance à modifier la bat que les tiles en vram, car ta map est en rom ,donc avec l'auto-incrementation de la vram, c'est finger in the noze à faire
tu pointes sur le bon offset en rom, et tu transfères en VRAM ..

C'est loin d'être tjs aussi simple...

Donc c'est ce je te dis, si ton tileset tient en vram, tu modifies que la BAT ..
Tu uploades que quand nécessaire, ou de façon différée,par chunk de données .
Pour un écran 512*224 en scroll multidirectionnel, tu dois transférer 2944 octets toutes les 8 frames, donc / frame ,368 octets(480 en 512*448), pas de quoi mettre à genoux quoi que ce soit ..

Comment tu arrives à ce chiffre O_o ??
Et puis le problème comme j'ai dit ce n'est pas tant la taille des données que l'organisation...
Quand tu as un scroll multidirectionnel tu ne vas rafraichir que des parties de ton tilemap. Sur MD avec un tilemap de 64x64 (ca prend dejà 8ko de vram) tu dois faire en sorte de rafraichir les parties non visibles du tilemap sur lequel tu "tournes". Par exemple tu vas rafraichir les colonnes 50 à 60 et les lignes 30 à 40. Mais bon ce genre de cas arrive que dans les jeux à scroll multi directionnel à vitesse variable. Il est sur que dans un shoot ou le scrolling est à vitesse stable et uni directionnel y'a aucun problème :p

Comme mentionné au dessus, un nombre limité d'objet peuvent être affichés sur une ligne, blablabla
Cependant,quelques fois les objets ont besoin d'être affichés au delà de cette limite

Ah merci beaucoup pour ta participation
Moi ce qui m'interesse c'est la méthode pour outre passer cette limite et dans ce qu'ils racontent il n'y a rien qui laisse entrevoir la possibilité de...
Et très honnêtement vu comment la processeur vidéo de la SNES fonctionne (un peu comme celui de la MD) je ne vois pas comment tu pourrais faire.
Je t'en avais déjà parlé d'ailleurs, ça fonctionne par nombre de slot dispo et donc tu as une limite hard impossible à franchir normalement :-/

Rien de plus explicite je pense
Et je pense pas qu'avec 128 sprites dispos/frame, tu ais besoin de multiplexage

Sur SNES effectivement, déjà 128 c'est beaucoup vu la resolution, puis la SNES aurait probablement du mal à arriver à ce chiffre (sauf peut être dans une démo).
Mais je pense malgré tout que c'est de ce chiffre 128 auquel il faisait référence...
Car à la base, la limite est bien par ligne (même pour ce chiffre). Si ça marche comme sur MD, pendant le HBlank le VDP trie les sprites parmis les 80 (128 sur SNES donc) pour savoir lesquels seront affichés sur le prochain scanline... Donc on peut dire que la limite s'applique au scanline à la base. D'ailleurs sur MD c'est d'autant plus vrai que tu peux modifier la SAT pendant une frame.

[Stef]

vous etes tarés les mecs :)

pourquoi ne developpez vous pas une demo sur chacune de vos consoles favorites : ca serait mieux que vos concours de zezettes de DMA CPU tiles :)

Perso j'en ai déjà fait une petite et j'attends toujours les versions SNES et PCE

https://www.youtube.com/watch?v=2vPe452cegU

J'ai aussi commencé à m'interesser à faire un peu de 3D sur MD, c'est très alpha mais j'aimerai pousser le concept un peu plus loin (y'a moyen de faire mieux) :

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

[Invité]

putain mec tu es giga creatif ! quel sens du rythme, de la mise en scene, des changements de plan dynamique ... serieusement, j'espere pour toi que tu fais du clip animé, si ce n'est pas le cas, tu es trop con :)

putain, comme quoi un bon codeur avec une becane vieille de 20 ans ...

clap clap.