Limitations liées au Dual Screen

[Michoko]

Bonjour !

Je pense utiliser µlib pour mon prochain projet, en association avec ASLib, l'idée étant de ne pas monter un usine à gaz µlib + PALib (bien que j'adore PALib ! :)), mais de rester léger.

Je compte donc utiliser la µlib à 30 FPS (ca devrait suffire dans mon cas) mais en regardant la documentation, j'ai vu qu'on perdait l'affichage 18bits pour se limiter à du 15bits. J'avoue ne pas trop comprendre ce bit supplémentaire pour chacune des composantes RGB... Est-ce une sorte de bit alpha ou bien on peut vraiment coder chaque composante RGB sur 6 bits au lieu des 5 habituels ? Et surtout, pourquoi perd-on cette fonctionnalité en mode 2 écrans ?

Merci aux âmes charitables qui voudront bien m'éclairer :)

Michoko

[Foxy]

La technique d'affiche double3D sur DS utilise la capture d'ecran hardware et l'affichage en sprite de la 2eme frame.
Le rendu 3D se fait en 565 alors que le rendu sprite ne se fait qu'en 555, donc en fait on perd un bit de precision sur une composante, d'ailleurs, c'est visible sur les programmes utilisant cette technique, il y a ce qu'on appel du flickering (oscillation d'intensité/scintillement) du à la différence de rendu.

[Michoko]

Merci Foxy pour ta réponse ! :)

Mais donc si je comprends bien, la µlib fait un rendu du premier écran, le capture, et disons le met dans l'écran du haut. Ensuite elle fait un rendu de l'écran du bas ?

Si c'est le cas, ça veut dire qu'au moins un des 2 écrans est en 18bits, et l'autre à 15 ? Ou bien les 2 écrans sont-ils le résultat d'une capture, et dans ce cas à 15bits tous les 2 ?

[Foxy]

C'est pas du 18, c'est du 16 tout les 2, mais le "15 bits", en fait utilise le bit de poids fort pour la transparence.
Sinon, oui le principe c'est de faire un rendu 3D sur l'ecran principal, faire une capture pour le transformer en sprite et la frame suivante swapper les ecrans pour faire le rendu sur l'autre ecran et afficher les sprites sur l'ancien. Ca donne l'illusion d'avoir un rendu 3D sur les 2 ecrans en même temps.

[Ludo6431]

J'en reviens pas qu'on puisse quand même avoir du 30 fps sur les deux écrans avec tout ça à faire en 1 seconde...

[Michoko]

Ok merci ! :)

En fait, j'en suis toujours à me creuser la tête pour savoir si pour mon nouveau projet, je devrais plutôt utiliser la µlib seule ou avec la PAlib. J'ai un temps libre très limité pour coder mes homebrews, et j'aimerais partir immédiatement sur la solution la plus adaptée, histoire de ne pas me retrouver plus tard dans une impasse

Ce projet sera en fait un RPG, où l'écran de jeu sera en bas, et l'inventaire en haut. Par exemple les icônes des objets sont susceptibles d'apparaître sur les 2 écrans en même temps.

Donc soit je pars sur la µlib pure et :
- je passe à 30 images par secondes (ce qui n'est pas gênant dans mon cas)
- j'ai éventuellement des problèmes de scintillement
- je perds les banques C et D
- mais je n'ai qu'une gestion des ressources graphiques et une seule approche au niveau du code

Soit je pars sur la µlib + palib et :
- j'ai 60 FPS
- je n'ai plus de pbs de scintillement
- mais je dois stocker mes graphs d'objets en double dans 2 formats différents, vu que les 2 libs ne les exploitent pas de la même façon (la galère)
- avoir deux approches de programmation différentes pour chaque écran
- au niveau mémoire je suppose que c'est kif kif, vu que du coup les banques C et D sont dispo pour la PALib ?

Bref, c'est le casse-tête. Je serais tenté par l'approche Dual Screen de la µlib, mais ces histoires de scintillement ou de désynchro si on est en dessous de la VBL (comme vu dans un autre topic) me font un peu peur...

Peut-être que des utilisateurs plus expérimentés de la µlib pourraient de donner leur sentiment sur la question, en fonction des galères qu'ils ont déjà pu rencontrer avec l'une ou l'autre de ces solutions ? Ce serait vraiment sympa de partager votre expérience sur le sujet ! :)

Merci beaucoup pour vos lumières ! :)
Michoko

[Foxy]

Bref, c'est le casse-tête. Je serais tenté par l'approche Dual Screen de la µlib, mais ces histoires de scintillement ou de désynchro si on est en dessous de la VBL (comme vu dans un autre topic) me font un peu peur...

Même si ton programme demande plus d'une frame pour les calculs, etc... tu n'aura pas de probleme de desynchro, au pire il tournera à moins de 30fps, mais ca ne changera rien a l'affichage. Si tu es plus rapide, de toute facon, la synchro VBL te limitera à 30fps maxi, donc aucun soucis là non plus.

Concernant le scintillement, c'est vraiment pour les puristes, c'est a peine perceptible. :)

Actuellement je travaille sur un projet professionnel qui utilise cette technique et ca ne pose aucun probleme, il nous arrive même de tourner qu'à 15 fps sans que cela soit genant.

[Michoko]

Bon ben allez, c'est décidé, ce sera full µlib :)

Un grand merci Foxy pour tes conseils éclairés !! :wub:

Je viens d'aller sur ton site: Cannon Fodder sur Wii ??? :blink:

[Foxy]

Je viens de lire le thread parlant de la desynchro, je ne sais pas comment Brunni gere sont flipping ecran.
Peut etre que le probleme est lié à la µlib alors. Moi je n'ai jamais eu ce genre de probleme avec mon code.