La vérité sur les sprites de la Lynx ? - Page 1

Hi, je voulais savoir précisément ce qu'il en était pour la lynx au niveau des lutins :

- nombre de sprites affichables SIMULTANEMENT à l'écran
- taille de ceux ci
- possibilité d'éviter de ramer avec listes chainées ou non ?

J'ai vu sur internet plusieurs versions concernant ces infos, si quelqu'un pouvait donner du contenu "approuvé", ça serait cool.

Cimer

Il y a pas de limite pour le nb de sprites, t'es juste limitée par la RAM.
Pour la taille:
- Sprites have unlimited vertical size.
- A sprites horizontal size is limited by a maximum of 254 bytes of source data. This is approximately 508 pixels unscaled.

Bref ça explose une Neogeo ou une Saturn et c'est pourtant sortie avant

J’ai lu que le nombre et la taille (comme les zoom d’ailleur) n’était que limité par la mémoire… C’est bien probable, il suffit de regarder le travail des codeurs sur les tunnels du jeu stunt runner…ils ont utilisés des tonnes de sprites zoommés pour faire cet effet!!! La gba est incapable de réaliser ça ! J’en ai fait l’amère expérience…

Xerus :
Il y a pas de limite pour le nb de sprites, t'es juste limitée par la RAM.

On peut afficher 50000 sprites a 60 fps ?

avec une bonne extension mémoire, oui ! Et en 75 fps qui plus est !

./4 Non car même si tu faisais des sprites de 1x1 tu pourrais pas tous les caser sur l'écran

4> ouah, a ce moment-la je suis sur qu'on doit pouvoir détourner le chip graphique pour faire des vrais calculs, si ca a une bande passante aussi impressionnante

Xerus> bah le hardware demande pas que les sprites soit 2 a 2 disjoints, non ? tu peux bien pouvoir mettre plein de sprites 64x64 les uns sur les autres, et il doit bien y avoir une limite au nb de sprites pour que ca reste fluide ^^

Vu la taille de la zone écran et la puissance du copro en question (il mouline à 16MHz le bestiau) tu peux remplir l'écran aisément . Il y a des jeux sur Lynx qui ont plusieurs plans différentiels et en fait ce sont des sprites gigantesques sans pour autant que ça rame
La Lynx c'est typique de la console américaine (comme la jag), pas limitation à la con comme les consoles japonaises au niveau des sprites !

d'un autre coté c'est pas parce qu'il y a pas de limite explicite que y a pas de limite (sur TI par exemple, y a évidemment pas de limite, mais c'est difficile d'afficher plus de 100 sprites 16x16 niveaux de gris a 30 fps)
vous avez pas ne serait-ce qu'un ordre de grandeur du nb de sprites ?

ouais d'abord ? un ordre de grandeur ?

Alors ça c'est une bonne question !
J'en sais fichtre rien, faudrait faire par exemple des captures des shoots sur Lynx mais il y a en où la zone écran est totalement remplie avec des décors animés !
Sans me mouiller je dirais que l'ordre de grandeur est suffisante pour tous les besoins avec en sus des effets spéciaux dessus

Il y a déjà une cinquantaine de sprites zoomés sur stun runner pour simuler le tunnel, ces sprites dépassent une hauteur de 160 pixels de hauts lorsqu’ils sont au bord de l’écran et, s’il n’y avait pas ces sons digit de merde pour ralentir le jeu de temps en temps, il devrait toujours tourner (a vue d’œil) en 1 ou 2 trames !

bref c'est très impressssionnant ! Sur GBA un sprite zommé ne peut pas dépasser 128 pixels de haut !

Tout est sprite sur la Lynx, y compris le fond d'écran (sauf à taper sauvagement dans le buffer écran comme Vince l'a fait dans une de ses démos).
Par exemple : la fonction DrawFBox du kit BLL, c'est un sprite 1x1 zoomé pour être à la bonne taille.
Bon, maintenant, je n'ai pas vraiment de réponse "approuvée et validée" à tes questions coopy par ce que :
1- je ne suis pas encore arrivé aux limites proprement (j'y suis avec Space Dance, mais c'est très spécial : monde virtuel tès très en hauteur...)
2- quand j'y suis arrivé, c'était parce que c'était mal programmé (pas de liste chainée, trop de code annexe autour, possibilité de faire mieux...)

Une chose est sure : il faut au maximum utiliser les listes chainées.
De plus, même si la console gère le clipping automatique, il vaut mieux désactiver soit même certains sprites (= non affichable) quand le monde est trop grand, voire changer son sprite de départ.

En fait, le gros problème de la Lynx, c'est la ram : tu peux chainer une tonne de sprites, mais pas différents, car tu n'auras pas la place en mémoire.
En effet : il y a certes 64ko de RAM, mais il faut enlever 8ko pour le buffer physique, 8ko pour le logique et éventuellement 8ko pour le buffer de collision, ce qui te laisse juste 48 ou 40ko au mieux.
Pour info : un fond 160x102, c'est 2ko si c'est moi qui le fait (tout simple avec des applats), mais ça peut monter à plus de 7ko pour les graphs de tempi que tu connais (tramage...). La compression doit être du type PC1 je pense.

Oké. Merci pour toutes ces réponses. Le meilleur est de tester, en fonction de mes besoins quoi, avec listes chainees. Mais on ne peut pas tirer de règle générale...

Voilà, on est limité par la fréquence de la ram et par sa taille, c'est tout (le proco central étant plus rapide que la ram) le bus ne pose pas de problèmes de ce coté là...

Pour ce qui est du copro, il peut servir de copro arithméthique, y'a même les registres et les fonctions nécessaires à l'intérieur. (ou comment faire une opération sur un float aussi rapidement qu'une simple addition de deux word avec le proco standard)

Coopy, je ne pense pas que tu arrives aux limites du système si facilement.
Sauf à gérer un monde virtuel de x000 par x000 avec une tonne de sprites qui se déplacent en permanence et à vouloir des scrolls hyper rapides... (et encore, avec le clipping et le positionnement virtuel, on ne sait jamais)

oké

Enfin, note bien également qu'en plus de ton objet, ta liste chainée prend 28 + 11 x nombre de sprite chainés octets en mémoire (si tu parametres bien ton SCB, sinon c'est 28 * nombre de sprites)
Ensuite, au niveau de la rapidité d'affichage, les différents modes (opaque, transparence...) ne sont pas égaux (cf doc). et si tu gères les collisions hard, c'est un peu plus lent encore.