Shmup SNES vs MD

[Kannagi]

Je pense pas que le jeu d'arcade gère les sprites dynamiquement. Les bornes d'arcade en général c'est plutôt bourré de VRAM. Rien que le premier R-Type, c'est 256 ko de graphismes (ce qui n'est pas mal pour l'époque).

Bah c'était pas seulement mon avis, mais celui de Stef aussi.

Je ne parle pas de la VRAM , mais de l'OAM (me souvient plus du nom pour la MD ) ou si tu préfère le "sprite engine hardware".
Parce que Super Rtype est bien foutu niveau code , si on omet les ralentissement.
Et gérer les sprites dynamiquement , je n'ai pas compris pourquoi ils ont fait ça, sauf s'ils ont déjà pris un code déjà fait quelque part
Et sur arcade j'aurais bien vu ce genre de système justement (déjà parce que ça évite de harcoder chaque élément du jeu ).

Ça serait plus marquant si tu faisais un niveau complet

Ce qui sera "en dessous" de mes test ,je rappel que je fais un test avec 12 ennemis , 100 bullets , soit le max, sur un niveau complet, je doute qu'on verra souvent ce cas de figure.
C'est un peu idiot , forcément in game, ça sera toujours "moins gourmand" qu'un test qui gère tout les paramètres en même temps , cas souvent improbable.

[retroactionman]

Les shmups, c'est bien le seul domaine dans lequel la md bat la snes... Mais moi ça m'en touche une sans faire bouger l'autre, n'étant pas fan du genre x)

Les shoots et les RPG !!

► Afficher le texte

[Tryphon]

Je pense pas que le jeu d'arcade gère les sprites dynamiquement. Les bornes d'arcade en général c'est plutôt bourré de VRAM. Rien que le premier R-Type, c'est 256 ko de graphismes (ce qui n'est pas mal pour l'époque).

Bah c'était pas seulement mon avis, mais celui de Stef aussi.

Je parle de la borne d'arcade, pas du jeu SNES. Oui c'est très possible que la version SNES utilise des sprites dynamiques (c'est facile à vérifier, suffit de regarder la VRAM dans un émulateur en cours de jeu). Auquel cas en effet, c'est un peu con-con, d'une part parce que le jeu est pas très demandant en étapes d'animation, d'autre part parce que bon, hein, la SNES elle a 128 Ko de VRAM, autant s'en servir. À moins qu'il y ait quelque chose dans la gestion des sprites de la SNES que j'ai pas compris, c'est assez incompréhensible comme choix.

Et gérer les sprites dynamiquement , je n'ai pas compris pourquoi ils ont fait ça, sauf s'ils ont déjà pris un code déjà fait quelque part
Et sur arcade j'aurais bien vu ce genre de système justement (déjà parce que ça évite de harcoder chaque élément du jeu ).

Je regarderai si tu veux, mais je peux t'assurer que sur le R-Type originel arcade, c'est du tout statique.

Ce qui sera "en dessous" de mes test ,je rappel que je fais un test avec 12 ennemis , 100 bullets , soit le max, sur un niveau complet, je doute qu'on verra souvent ce cas de figure.
C'est un peu idiot , forcément in game, ça sera toujours "moins gourmand" qu'un test qui gère tout les paramètres en même temps , cas souvent improbable.

Tut ! Tut ! Botte pas en touche, fais-le, en plus je te promets que j'y jouerai (mais le fais pas trop dur)

[Kannagi]

Je parle de la borne d'arcade, pas du jeu SNES. Oui c'est très possible que la version SNES utilise des sprites dynamiques (c'est facile à vérifier, suffit de regarder la VRAM dans un émulateur en cours de jeu). Auquel cas en effet, c'est un peu con-con, d'une part parce que le jeu est pas très demandant en étapes d'animation, d'autre part parce que bon, hein, la SNES elle a 128 Ko de VRAM, autant s'en servir. À moins qu'il y ait quelque chose dans la gestion des sprites de la SNES que j'ai pas compris, c'est assez incompréhensible comme choix.

Je regarderai si tu veux, mais je peux t'assurer que sur le R-Type originel arcade, c'est du tout statique.

Alors je ne parle pas de ça , c'est pas un soucis de faire ça (que ça soit sur SNES ou MD).
Surtout que ça risque pas de prendre des temps de calcul ,vu que tu ne peux le faire que pendant le VBlank.
Si tu dépasse , non seulement tu risque d'avoir des glitch graphique , mais en plus si tu force le VBlank plus longtemps on aurait eu des ligne noires donc une réso plus petite, ce qui n'est pas le cas de Super R-type.

En gros je parle de ceci :
https://wiki.megadrive.org/index.php?title=VDP_Sprites

Et donc je me répète , la gestion du VDP Sprite sur Super R-type est utilisé dynamiquement.
Et comme tu le sais probablement , la SNES et la gestion des sprite ça fait deux, ils aurait gagner énormément en terme de perf de le faire statiquement.

Et je me le répète, la version arcade doit les gérer dynamiquement , parce que c'est bien plus pratique d'avoir un truc modulaire pour gérer les sprites (ce que fait le SGDK) ,que de hardcoder chaque truc, surtout que ça t'oblige de réfléchir à l'avance quel élément max de sprite tu assigne , mais surtout de "sous évaluer" , le nombre de sprite max , si tu fais ça , parce que si tu dis "40" sprite pour les explosions, ben tu aura 40 réservé pour ça.
ça à l'avantage d'etre rapide en terme de calcul , mais en terme de prog , c'est vraiment relou :p

Ps: Pour ça que je n'aime pas débattre sur les choses technique, c'est relou ,et désolé mais tu dis pas mal de choses fausse, ça devrait de faire tiquer normalement , les transfert en VRAM ne ralentit pas la machine ,vu qu’elle sont limité (7 ko pour la MD et 5ko pour la SNES si mes souvenir sont bon ).
Et c'est le truc qu'on dit depuis des années en plus...

[Tryphon]

Je parle de la borne d'arcade, pas du jeu SNES. Oui c'est très possible que la version SNES utilise des sprites dynamiques (c'est facile à vérifier, suffit de regarder la VRAM dans un émulateur en cours de jeu). Auquel cas en effet, c'est un peu con-con, d'une part parce que le jeu est pas très demandant en étapes d'animation, d'autre part parce que bon, hein, la SNES elle a 128 Ko de VRAM, autant s'en servir. À moins qu'il y ait quelque chose dans la gestion des sprites de la SNES que j'ai pas compris, c'est assez incompréhensible comme choix.

Je regarderai si tu veux, mais je peux t'assurer que sur le R-Type originel arcade, c'est du tout statique.

Alors je ne parle pas de ça , c'est pas un soucis de faire ça (que ça soit sur SNES ou MD).
Surtout que ça risque pas de prendre des temps de calcul ,vu que tu ne peux le faire que pendant le VBlank.
Si tu dépasse , non seulement tu risque d'avoir des glitch graphique , mais en plus si tu force le VBlank plus longtemps on aurait eu des ligne noires donc une réso plus petite, ce qui n'est pas le cas de Super R-type.

En gros je parle de ceci :
https://wiki.megadrive.org/index.php?title=VDP_Sprites

Et donc je me répète , la gestion du VDP Sprite sur Super R-type est utilisé dynamiquement.
Et comme tu le sais probablement , la SNES et la gestion des sprite ça fait deux, ils aurait gagner énormément en terme de perf de le faire statiquement.

OK, pour moi un sprite dynamique, c'est lorsque tu charges les données graphiques à la volée (les tiles qui le composent). Toi tu parles juste de la SAT ? Comment tu définis l'ordre d'affichage des sprites sur SNES ? Y'a un équivalent du link de la MD ?

Et je me le répète, la version arcade doit les gérer dynamiquement , parce que c'est bien plus pratique d'avoir un truc modulaire pour gérer les sprites (ce que fait le SGDK) ,que de hardcoder chaque truc, surtout que ça t'oblige de réfléchir à l'avance quel élément max de sprite tu assigne , mais surtout de "sous évaluer" , le nombre de sprite max , si tu fais ça , parce que si tu dis "40" sprite pour les explosions, ben tu aura 40 réservé pour ça.

Oui, OK, ça fait sens avec ta définition de sprite dynamique. C'est juste que sur MD, tous les jeux sont dynamiques (ou presque, des jeux sur lesquels j'ai bossé je n'ai qu'un contre-exemple).

Ps: Pour ça que je n'aime pas débattre sur les choses technique, c'est relou ,et désolé mais tu dis pas mal de choses fausse, ça devrait de faire tiquer normalement , les transfert en VRAM ne ralentit pas la machine ,vu qu’elle sont limité (7 ko pour la MD et 5ko pour la SNES si mes souvenir sont bon ).

Le transfert en VRAM non, mais la gestion d'un sprite dynamique dans mon sens, c'est plus lourd qu'un statique côté CPU. Y'a une allocation de la VRAM à gérer à chaque frame. C'est pas absurdement lourd, mais quand même. C'est pas pour rien que la plupart des jeux dans lesquels j'ai farfouillé, seul le sprite du joueur est dynamique (dans mon sens, pas dans le tien).

[Kannagi]

Toi tu parles juste de la SAT ? Comment tu définis l'ordre d'affichage des sprites sur SNES ? Y'a un équivalent du link de la MD ?

Oui ,y'a pas d'équivalent du link de la MD , mais comme tu le sais (et que tu as souvent entendu parler) le SAT de la SNES étant mal foutu , faut mieux éviter de le gérer dynamiquement.

mais la gestion d'un sprite dynamique dans mon sens, c'est plus lourd qu'un statique côté CPU. Y'a une allocation de la VRAM à gérer à chaque frame. C'est pas absurdement lourd, mais quand même. C'est pas pour rien que la plupart des jeux dans lesquels j'ai farfouillé, seul le sprite du joueur est dynamique (dans mon sens, pas dans le tien).

Chez moi , ça consomme quasi rien , et pourtant j'ai fait un système assez "lourd" pour le gérer.
Dans le sens ou mon engine est assez intelligent pour mettre en attende , si y'a trop de sprite qui ont besoin d'upload en VRAM.

Je pense que si c'est gérer souvent statiquement ,c'est plus pour des raisons de facilité , si tu veux le gérer dynamiquement , tu dois mettre un système bien plus complexe , (mais pas forcément gourmand en CPU).

Par contre gérer le SAT de façon "dynamique" sur SNES est lourd, pour ça que j'ai mis dans mon engine qu'une gestion statique (mais en proposant du code prefait ).
D'ailleurs pour mon shmup je gère les sprites tout dynamiquement en VRAM.
Je trouve que le code est bien plus propre de cette façon aussi

[Captain_Eraclés]

J'apporte ma pierre à l'édifice : "Les Shmup" c'est de la mer**

Si vous me cherchez, je ne suis plus là

[marmotplay]

J'apporte ma pierre à l'édifice : "Les Shmup" c'est de la mer**

Si vous me cherchez, je ne suis plus là

Reste, c'est la seule intervention compréhensible d'aujourd'hui