Choix de mode graphique

[Bobby Sixkilla]

Avant de me lancer sur DS, je vais faire mon projet sur GBA (une version simplifiée)... Du coups, je me demande quel mode graphique choisir.

Ce que je dois afficher à l'écran :
- un background principal, une grille (240x160)
- un carré au contours blancs (8x8) qui se déplacera sur les intersections de la grille
- un curseur (8x8) qui se déplace horizontalement au dessus de la grille
- un point (8x8) qui se placera aux intersections de la grille (soit au max, 192 points à afficher... bien plus que la limite de sprites affichables, c'est ça mon gros problème :snif2:).
- un peu de texte pour indiquer le tempo, la bank et le pattern en haut à gauche de la grille (des chiffres et 4 lettres, avec une hauteur de 8 pixels)

Choisir un mode tile serait-il opportun? Si oui, quel mode tile choisir?

PS : J'utilise très peu de couleurs (seulement 4 dont la couleur de transparence).

[Foxy]

Pour tes points vu qu'ils se placent en decalés sur ta grille, tu devrais utiliser un BG en scrollant de 4 en X et Y et ca te decallera tes points mis en tiles :)

[Yodajr]

Je suis loin d'etre un expert mais à priori, je te conseille le mode 0 qui te permet beaucoup de libertés (par exemple faire sauter la limite des 128 sprites en utilisant des tiles à la place)

Cela dit, si tu n'as pas d'animations, y'a aussi le mode 3 utilisé par djp pour son Sudoku Micro (http://www.playeradvance.org/forum/showthread.php?t=1228) avec lequel t'as encore plus de libertés d'un certain point de vue ;)

[Bobby Sixkilla]

Merci pour le tuyau. ^^

Et je pourrais en afficher autant que j'en veux? :)

[Foxy]

Ben si tu utilise des tiles au lieu des sprites, oui tu n'es plus limité par le nombre.

[DJP]

Je pense que tu n'es, comme moi, pas un gros bourrin du code, hardware ASM etc... donc je vais te dire mes conclusions PERSO. Pour Picross Advance (et sudoku micro d'une autre façon) j'ai été limité par le mode tile (8x8 pour les 15 cases + 7 indication en chiffre = 22, soit 2 tiles de trop en hauteur). Resultat, obligé de passer par le mode 3. Si tu n'a pas besoin de tout réécrire a chaque fois ça devrai pas te posser de problème, bien que certaines fonction du mode Tiles font parfois défaut...
La solution intermédiaire, mais bouffe beaucoup de tiles "pour rien" c'est de faire du 50/50. Tu définis une série de tiles uniques que tu utilises pour "recouvrir" la zone qui nécéssite le mode3 et tu plot directement dans la tiles...
Je ne suis peut etre pas très clair, mais je je speed pour voir me kamelott ;)
Au cas ou j'essairai d'etre plus clair tout a l'heure...

[Ass-Itch]

Je ne suis peut etre pas très clair, mais je je speed pour voir me kamelott ;)

:lol: Et j'étais moi en train de me demander ce que je foutais encore sur PA alors que ça commence dans 5 minutes :D

[Alekmaul]

Perso, s'il y a peu d'anim à l'écran, moi je tenterais le coup en mode 4.
Du bon vieux mode bitmap, bien simple à utiliser donc qui sera maléable pour tes points 8x8 ;)

[Bobby Sixkilla]

Il n'y aura aucune animation (le curseur se déplacera, mais je ne sais pas si on peut appeler ça de l'animation). ^^ Et puis, il y aura surtout plus de 128 sprites. :S

[MIKEGBA]

Moi, je te fais la meme réponse qu'Alekmaul, le mode 4 te permettra sans soucis de réaliser ton projet, ça te régle ton soucis de la limite des sprites, et même des animations devraient passer sans probleme dans ce mode.:thumb_yel

[Bobby Sixkilla]

Moi, je te fais la meme réponse qu'Alekmaul, le mode 4 te permettra sans soucis de réaliser ton projet, ça te régle ton soucis de la limite des sprites, et même des animations devraient passer sans probleme dans ce mode.:thumb_yel

Il n'y a pas la limite des 128 sprites affichables à la fois avec le mode 4? :blink:

[Alekmaul]

Si bien entendu mais tu n'utilises pas les sprites de la GBA, tu "plot" directement dessus les points. Si tu as peu d'anims, tu peux te permettre de faire un refresh global de l'écran (ou une partie) pour afficher / enlever les points (en gardant le fond commun à tout dans un buffer par exemple).

[Brunni]

+1, dans ton cas je pense que c'est mieux d'utiliser le mode 4. Et pour certaines choses il reste possible d'utiliser des sprites (pour plus de vitesse). Pour les autres (tes points, qui dépasseraient la limite) tu peux plotter directement sur le fond (bitmap).

[Bobby Sixkilla]

Ok. Je prend le mode 4 alors. ^^ Mais je vais vous harceler sur msn quand je bloquerai! :D

[Nesgba]

vous n'avez pas l'impression de l'envoyer au casse pipe la ? :huh:, le sudoku de phantom l'a deja prouvé, pour ton jeu le mode 3 suffit tres largement, et au moin tu t'embettera pas avec les décalages + AND/ORR entre la source et la destination.

mais si tes points sont toujours fixes et alignés sur 8, le mode 0 s'impose ^^

[Bobby Sixkilla]

Vous pouvez pas vous mettre d'accord! :D

Mes points seront bien alignés toujours de la même façon, avec un écart de 11 pixels (j'ai prévu 3 pixels de vide entre chaque point pour que ce soit plus lisible). ^^

En fait, en pratique, l'utilisateur dépassera rarement 128 points affichés... mais bon, je préfère prévoir le truc. ^^

[Nesgba]

Vous pouvez pas vous mettre d'accord! :D

Mes points seront bien alignés toujours de la même façon, avec un écart de 11 pixels (j'ai prévu 3 pixels de vide entre chaque point pour que ce soit plus lisible). ^^


ah ben bravo, tu es completement désaligné :fouetdjp:

:p

[Bobby Sixkilla]

C'est grave docteur? :D

[Nesgba]

C'est grave docteur? :D

bien sur que non :).

en fait cela depend du mode graphique que tu utilise

en mode tile(mode 0,1,2):
le gpu2D de la gba (comme celui de beaucoup d'autres consoles), ne sais afficher qu'une grille de sprites de taille 8*8, donc imagine que tu mette dans chaque carré un de tes sprites il faudrai qu'il y ai 8 pixels vide entre chaque pour correctement les afficher, toi tu as un ecart de 11 pixels entre chaque, donc pas possible :snif2:

en mode 4:
le probleme de l'ecran gba c'est que tu ne peut pas y acceder en 8 bits, tu est forcé de faire un acces en ecriture en 16 ou 32 bits pour ecrire 1 pixel de 8 bits, donc tu dois mettre ton pixel 8 bits dans un conteneur 16 bits (decaler les 8 bits vers la gauche si tu n'est pas aligné sur l'ecran) et ensuite l'ecrire, mais ce conteneur 16 bits as gardé 8 bits vide, donc si tu l'ecrit tel quel ca te ferra un joli point noir a coté de ton pixel :/
donc tu est forcé préalable de faire une lecture de l'ecran de mettre cette lecture dans ton conteneur (il faut la décaler elle aussi).

bon bref comme tu as du le comprendre c'est pas forcement le plus simple quand tu débute >_<

en mode 3:
aucun soucis :)



tien un exemple pour ecrire un seul pixel pour te donner une idée


mode 3 en C et ASM

// acces normal 16 bits
void DrawPixel16(int x, int y, unsigned short src16, unsigned short *pdst16){
pdst16[(y*240)+x] = src16 ;
}

.ARM
.ALIGN 4
.GLOBAL ASM_DrawPixel16
ASM_DrawPixel16:
add r3,r3,r1,lsl #9 @ r2 += y*512
sub r3,r3,r1,lsl #5 @ r2 -= y*32
add r3,r3,r0,lsl #1 @ r2 += x*2
strh r2,[r3] @ ecrit 16 bits sur l'adresse recue
bx lr




mode 4 en C et ASM

// acces 16 bits
void DrawPixel8_16(int x, int y , unsigned char src8, unsigned short *pdst16){
pdst16 += ((y*240)+x)>>1 ; // ((240*y)+x)/2
x = (x&1)<<4 ; // x = décalage a appliquer
*pdst16 = *pdst16&~(0xff<<x) | (src8<<x) ;
}

.ARM
.ALIGN 4
.GLOBAL ASM_DrawPixel8_32
ASM_DrawPixel8_32:
stmfd sp!,{r4} @ enregistre la valeur du registre sur la pile
add r3,r3,r1,lsl #8 @ VideoMem += y*256 ajoute l'offset y
sub r3,r3,r1,lsl #4 @ VideoMem -= y*16
and r1,r0,#3 @ dec = x&3
sub r0,r0,r1 @ x -= dec on arrondie x au double-word inferieur
add r3,r3,r0 @ VideoMem += x ajoute l'offset aligné sur 4 octets de x
mov r1,r1,lsl #3 @ dec*8 multiplie le décalage par 8 pour établir le décalage de bits sur 4 octets
ldr r4,[r3] @ tmpVideoMem = &VideoMem stoque 32 bits d'adresse de destination dans un registre
mov r0,#0x000000ff @ mask = 0x000000ff masque pré-inversé (impossible de décaler autre chose qu'un registre :( )
bic r4,r4,r0,lsl r1 @ tmpVideoMem &= ~(mask<<dec) applique le masque décalé sur la destination
orr r4,r4,r2,lsl r1 @ tmpVideoMem |= (indexColor<<dec) applique un OU de l'index palette sur la destination
str r4,[r3] @ *VideoMem = tmpVideoMem ecrit les 32 bits modifiés
ldmfd sp!,{r4} @ restaure le registre avec son ancienne valeur
bx lr @ retour





fais ton choix ^^