Programmazione del GBA

[Diamaxus]

Ho risolto quel problemino che avevo, quindi tra domani e dopodomani (il tempo di scrivere il prossimo paragrafo) si riprende.

Stay tuned!

 

tag: @evilespeon @ZedeFire @VincyDarkHeart @Macca

[evilespeon]

13 minuti fa, Diamaxus ha scritto:

Ho risolto quel problemino che avevo, quindi tra domani e dopodomani (il tempo di scrivere il prossimo paragrafo) si riprende.

Stay tuned!

 

tag: @evilespeon @ZedeFire @VincyDarkHeart @Macca

Yeeeeee felicissima che hai risolto kohai ottimo dai allora aspetti domani o dopodomani,fa con calma 

[Diamaxus]

3 minuti fa, evilespeon ha scritto:

Yeeeeee felicissima che hai risolto kohai ottimo dai allora aspetti domani o dopodomani,fa con calma 

Grazie senpai

[evilespeon]

2 minuti fa, Diamaxus ha scritto:

Grazie senpai

Di nullaaaa kohai 

[Diamaxus]

I Tasti

 

Iniziamo a vedere qualcosa di più pratico. Come immagino sapete il GBA ha 10 tasti (A,B, sinistra, destra, su, giù, L, R, Start, Select).

Lo stato (premuto, rilasciato) è salvato nei primi 10 bit (da destra) del registro di input REG_KEYINPUT che si trova all’indirizzo 0400:0130h.

 

 

Controllare se un tasto è stato premuto o meno, sarebbe ovvio se non fosse per un piccolo dettaglio: i bit sono impostati a 0 quando il tasto è premuto e ad 1 quando non è premuto. Quindi il valore di default del registro è 03FF e non 0.

 

Oltre al registro di input dei tasti, ne esiste un’altro praticamente identico al primo detto registro di controllo dei tasti (REG_KEYCNT) che serve a controllare le interrupt hardware (che vedremo più avanti). L’unica differenza rispetto al primo registro è che gli ultimi 2 bit (F ed E) servono a controllare le interrupt.

 

 

‘F’ rappresenta un operatore booleano: se è impostato a 0 usa un OR (fa partire l’interrupt se un tasto qualsiasi è stato premuto) altrimenti se impostato a 1 è un AND (fa partire l’interrupt solo se sono premuti tutti i tasti).

‘E’ abilita l’interrupt.

 

Vediamo nella pratica come controllare lo stato dei tasti.

 

Quello che andiamo a fare è leggere lo stato del registro ad esempio all’inizio del frame ed usarlo come riferimento per tutto il frame. Quindi avremo due variabili: una per controllare lo stato attuale, una per salvare lo stato precedente. Ed infine una funzione che le aggiorna.

 

extern u16 __key_curr, __key_prev;

#define KEY_MASK 0x03FF

 

inline void key_poll() { __key_prev= __key_curr; __key_curr= ~REG_KEYINPUT & KEY_MASK; }

 

La funzione key_poll inverte i bit del registro in modo che noi consideriamo i tasti premuti quando i bit valgono 1, in questo modo è più intuitivo.

Se volete andare più nel dettaglio, vi spiego qui l’operazione che va a fare:

Spoiler

il registro ha come valore di default 03FF (in esadecimale) ossia 0000001111111111 in binario. L’operatore ~ (NOT) dove trova 1 mette 0 e viceversa quindi ~REG_KEYINPUT diventa 1111110000000000. L’operatore &(AND) dà come risultato 1 quando i due bit sono uguali, 0 altrimenti. Quindi ~REG_KEYINPUT & KEY_MASK dà come risultato:

 

0000001111111111 &

1111110000000000 =

---------------------------

0000000000000000

 

in questo modo quando premiamo il tasto, il bit corrispondente diventa 1.

 

Quindi alla fine ci basterà solo controllare lo stato di __key_curr e __key_prev con il tasto che abbiamo premuto.

Ad esempio se vogliamo verificare se un tasto viene tenuto premuto per più tempo basta fare:

(__key_curr & __key_prev) & key; (verifica che lo stato attuale del tasto  è uguale al precedente ed è relativo al tasto che sto premendo).

 

Se vogliamo verificare che il tasto è stato rilasciato:

( __key_prev & ~__key_curr ) & key; (verifica che lo stato precedente del tasto è diverso da quello attuale ed è relativo al tasto che sto rilasciando).

 

E così via, possiamo controllare tutti i casi che vogliamo in questo modo.

 

Per concludere, (per chi vuole vedere il codice) vi faccio vedere il programma che ho fatto, che cambia colore allo schermo finché tengo premuto A.

Spoiler

il file tasti.h è uguale a quello della volta scorsa, l'unica cosa che ho aggiunto è:

		

		#define REG_KEYINPUT *(volatile u16*)0x04000130		

		#define KEY_A 0x0001		

		#define KEY_B 0x0002		

		#define KEY_SELECT 0x0004		

		#define KEY_START 0x0008		

		#define KEY_RIGHT 0x0010		

		#define KEY_LEFT 0x0020		

		#define KEY_UP 0x0040		

		#define KEY_DOWN 0x0080		

		#define KEY_R 0x0100		

		#define KEY_L 0x0200		

		#define KEY_MASK 0x03FF		

		#define MAX_KEY 10		

		 		

		// variabili globali.		

		extern u16 __key_curr, __key_prev;		

		 		

		// Funzione di controllo dei tasti.		

		// Salva il tasto attualmente premuto nella variabile "tasto prececedente"		

		// il tasto corrente diventa quello letto dal registro.		

		inline void key_poll(void)		

		{		

		__key_prev= __key_curr;		

		__key_curr= ~REG_KEYINPUT & KEY_MASK;		

		}		

		 		

		// verifica se un certo tasto è stato tenuto premuto per più tempo.		

		inline u32 key_held(u32 key)		

		{ return (__key_curr & __key_prev) & key; }		

		 		

		// funzione che inizializza la palette di colori con un solo colore.		

		inline void palette_init(color colore) {		

		for (int i = 0; i < 255; i++) {		

		COLOR_PAL[i] = colore;		

		}		

		}		

		

 

Il file tasti.c invece è questo:

 

		

		#include "tasti.h"		

		 		

		// definizione delle variabili globali.		

		u16 __key_curr=0, __key_prev=0;		

		 		

		int main(void) {		

		// inizializzo la palette sul nero.		

		color nero = RGB15(0, 0, 0);		

		color verde = RGB15(0, 31, 0);		

		palette_init(nero);		

		u32 btn = KEY_A; // ho deciso di verificare ad es. se sto premendo 'A'		

		int frame = 0; // contatore dei frame.		

		REG_DISPCNT = DCNT_MODE4 | DCNT_BG2; // imposto la modalità 4.		

		while(1) {		

		vsync(); // attendo il vertical sync		

		// attendo 7 frame prima di fargli controllare i tasti,		

		// altrimenti non riusciremmo a vedere che lo schermo cambia colore.		

		if((frame & 7) == 0){		

		key_poll();		

		}		

		 		

		if (key_held(btn)) { // se tengo premuto 'A'		

		palette_init(verde); // colora lo schermo di verde		

		}		

		else { // altrimenti colora lo schermo di nero		

		palette_init(nero);		

		}		

		frame++; // incrementa di 1 il frame		

		}		

		 		

		return 0;		

		}		

		

 

 

Ho fatto anche una gif per farvi vedere cosa succede:

 

 

Questo è tutto per oggi. Come sempre se avete dubbi o domande sono a vostra disposizione.

La prossima volta iniziamo a vedere le modalità grafiche utili per i giochi.

 

fonte: https://gbadev.net/tonc/keys.html

 

Tag: @evilespeon @ZedeFire @VincyDarkHeart @Macca

 

Clicca qui per andare al prossimo capitolo

Modificato 12 luglio da Diamaxus
aggiunto link per il prossimo capitolo

[evilespeon]

2 ore fa, Diamaxus ha scritto:

I Tasti

 

Iniziamo a vedere qualcosa di più pratico. Come immagino sapete il GBA ha 10 tasti (A,B, sinistra, destra, su, giù, L, R, Start, Select).

Lo stato (premuto, rilasciato) è salvato nei primi 10 bit (da destra) del registro di input REG_KEYINPUT che si trova all’indirizzo 0400:0130h.

 

 

Controllare se un tasto è stato premuto o meno, sarebbe ovvio se non fosse per un piccolo dettaglio: i bit sono impostati a 0 quando il tasto è premuto e ad 1 quando non è premuto. Quindi il valore di default del registro è 03FF e non 0.

 

Oltre al registro di input dei tasti, ne esiste un’altro praticamente identico al primo detto registro di controllo dei tasti (REG_KEYCNT) che serve a controllare le interrupt hardware (che vedremo più avanti). L’unica differenza rispetto al primo registro è che gli ultimi 2 bit (F ed E) servono a controllare le interrupt.

 

 

‘F’ rappresenta un operatore booleano: se è impostato a 0 usa un OR (fa partire l’interrupt se un tasto qualsiasi è stato premuto) altrimenti se impostato a 1 è un AND (fa partire l’interrupt solo se sono premuti tutti i tasti).

‘E’ abilita l’interrupt.

 

Vediamo nella pratica come controllare lo stato dei tasti.

 

Quello che andiamo a fare è leggere lo stato del registro ad esempio all’inizio del frame ed usarlo come riferimento per tutto il frame. Quindi avremo due variabili: una per controllare lo stato attuale, una per salvare lo stato precedente. Ed infine una funzione che le aggiorna.

 

extern u16 __key_curr, __key_prev;

#define KEY_MASK 0x03FF

 

inline void key_poll() { __key_prev= __key_curr; __key_curr= ~REG_KEYINPUT & KEY_MASK; }

 

La funzione key_poll inverte i bit del registro in modo che noi consideriamo i tasti premuti quando i bit valgono 1, in questo modo è più intuitivo.

Se volete andare più nel dettaglio, vi spiego qui l’operazione che va a fare:

  Apri contenuto nascosto

il registro ha come valore di default 03FF (in esadecimale) ossia 0000001111111111 in binario. L’operatore ~ (NOT) dove trova 1 mette 0 e viceversa quindi ~REG_KEYINPUT diventa 1111110000000000. L’operatore &(AND) dà come risultato 1 quando i due bit sono uguali, 0 altrimenti. Quindi ~REG_KEYINPUT & KEY_MASK dà come risultato:

 

0000001111111111 &

1111110000000000 =

---------------------------

0000000000000000

 

in questo modo quando premiamo il tasto, il bit corrispondente diventa 1.

 

Quindi alla fine ci basterà solo controllare lo stato di __key_curr e __key_prev con il tasto che abbiamo premuto.

Ad esempio se vogliamo verificare se un tasto viene tenuto premuto per più tempo basta fare:

(__key_curr & __key_prev) & key; (verifica che lo stato attuale del tasto  è uguale al precedente ed è relativo al tasto che sto premendo).

 

Se vogliamo verificare che il tasto è stato rilasciato:

( __key_prev & ~__key_curr ) & key; (verifica che lo stato precedente del tasto è diverso da quello attuale ed è relativo al tasto che sto rilasciando).

 

E così via, possiamo controllare tutti i casi che vogliamo in questo modo.

 

Per concludere, (per chi vuole vedere il codice) vi faccio vedere il programma che ho fatto, che cambia colore allo schermo finché tengo premuto A.

  Apri contenuto nascosto

il file tasti.h è uguale a quello della volta scorsa, l'unica cosa che ho aggiunto è:

		

		#define REG_KEYINPUT *(volatile u16*)0x04000130		

		#define KEY_A 0x0001		

		#define KEY_B 0x0002		

		#define KEY_SELECT 0x0004		

		#define KEY_START 0x0008		

		#define KEY_RIGHT 0x0010		

		#define KEY_LEFT 0x0020		

		#define KEY_UP 0x0040		

		#define KEY_DOWN 0x0080		

		#define KEY_R 0x0100		

		#define KEY_L 0x0200		

		#define KEY_MASK 0x03FF		

		#define MAX_KEY 10		

		 		

		// variabili globali.		

		extern u16 __key_curr, __key_prev;		

		 		

		// Funzione di controllo dei tasti.		

		// Salva il tasto attualmente premuto nella variabile "tasto prececedente"		

		// il tasto corrente diventa quello letto dal registro.		

		inline void key_poll(void)		

		{		

		__key_prev= __key_curr;		

		__key_curr= ~REG_KEYINPUT & KEY_MASK;		

		}		

		 		

		// verifica se un certo tasto è stato tenuto premuto per più tempo.		

		inline u32 key_held(u32 key)		

		{ return (__key_curr & __key_prev) & key; }		

		 		

		// funzione che inizializza la palette di colori con un solo colore.		

		inline void palette_init(color colore) {		

		for (int i = 0; i < 255; i++) {		

		COLOR_PAL[i] = colore;		

		}		

		}		

		

 

Il file tasti.c invece è questo:

 

		

		#include "tasti.h"		

		 		

		// definizione delle variabili globali.		

		u16 __key_curr=0, __key_prev=0;		

		 		

		int main(void) {		

		// inizializzo la palette sul nero.		

		color nero = RGB15(0, 0, 0);		

		color verde = RGB15(0, 255, 0);		

		palette_init(nero);		

		u32 btn = KEY_A; // ho deciso di verificare ad es. se sto premendo 'A'		

		int frame = 0; // contatore dei frame.		

		REG_DISPCNT = DCNT_MODE4 | DCNT_BG2; // imposto la modalità 4.		

		while(1) {		

		vsync(); // attendo il vertical sync		

		// attendo 7 frame prima di fargli controllare i tasti,		

		// altrimenti non riusciremmo a vedere che lo schermo cambia colore.		

		if((frame & 7) == 0){		

		key_poll();		

		}		

		 		

		if (key_held(btn)) { // se tengo premuto 'A'		

		palette_init(verde); // colora lo schermo di verde		

		}		

		else { // altrimenti colora lo schermo di nero		

		palette_init(nero);		

		}		

		frame++; // incrementa di 1 il frame		

		}		

		 		

		return 0;		

		}		

		

 

 

Ho fatto anche una gif per farvi vedere cosa succede:

 

 

Questo è tutto per oggi. Come sempre se avete dubbi o domande sono a vostra disposizione.

La prossima volta iniziamo a vedere le modalità grafiche utili per i giochi.

 

fonte: https://www.coranac.com/tonc/text/keys.htm

 

Tag: @evilespeon @ZedeFire @VincyDarkHeart @Macca

 

Ah ah io sapevo tutto fino a qui : Come immagino sapete il GBA ha 10 tasti (A,B, sinistra, destra, su, giù, L, R, Start, Select). XD 

comunque davvero interessante kohai 

[Diamaxus]

6 minuti fa, evilespeon ha scritto:

Ah ah io sapevo tutto fino a qui : Come immagino sapete il GBA ha 10 tasti (A,B, sinistra, destra, su, giù, L, R, Start, Select). XD 

comunque davvero interessante kohai 

Penso un po' tutti senpai XD

Grazie

[evilespeon]

8 minuti fa, Diamaxus ha scritto:

Penso un po' tutti senpai XD

Grazie

Spero di no er tutti XD 

Di nullaaaaa

[Diamaxus]

Bentrovati! È passato un po' di tempo dall'ultima volta ma a mia discolpa sono stato impegnato con un po' di cose. XD

Oggi parliamo degli sprite.  

 

Introduzione sugli sprite e i background pt. 1

 

Sebbene sia possibile creare giochi basati esclusivamente sulle modalità bitmap, ce ne sono davvero pochi che lo fanno (come ad esempio Wolfenstein e Doom).

La ragione è semplice: tutta la grafica, in questo caso, sarà renderizzata via software. Non importa quanto sia pulito il vostro codice, sarà sempre un processo lento.

 

La stragrande maggioranza dei giochi usa la grafica hardware, che troviamo nella forma di sprite e tiled backgrounds.

 

Un tiled background è una matrice di tiles ognuno dei quali contiene un indice per una bitmap di 8x8 pixel, detto tile.

Ci sono quattro tipi di background con grandezza compresa tra i 128x128 pixel (32x32 tile) fino a 1024x1024 pixel (128x128 tile).

Gli sprite sono oggetti più piccoli di grandezza compresa tra 8x8 e 64x64 pixel. Ce ne sono 128 e possono muoversi in modo indipendente l’uno dall’altro. Anche gli sprite sono costituiti da tile.

 

Ci sono tre step base che bisogna considerare: il controllo, il mapping e il dato dell’immagine.

 

Lo scopo di questo capitolo è quello di dare un infarinatura generale di quello che vedremo nei prossimi due capitoletti. Non preoccupatevi se non capite ora i concetti che tratteremo, perché alcuni concetti li vedremo nel dettaglio più avanti.

 

Controllo degli sprite e del background

 

Il primo step è il controllo.

Il controllo riguarda tutto ciò che agisce sugli sprite o sui background nella loro totalità, come ad esempio se usare 16 o 256 tile colorati e alcuni effetti.

Prima di tutto bisogna decidere se si vuole usarli o meno.

Questo si fa settando i bit giusti nel display control register REG_DISPCNT. Fatto ciò ci sono altri control register per i background: il REG_BGxCNT (indirizzi 0400:0008h – 0400:000Fh).

Per gli sprite c’è la Object Attribute Memory (OAM) che si trova all’indirizzo 0700:000h.

Ciascuno dei 128 sprite ha tre attributi che riguardano gli aspetti del controllo e del mapping degli sprite.

 

Sprite e background mapping

 

Il mapping riguarda tutto ciò che i tile usano e dove sono posizionati.

Dovrete dire al GBA quali tile “blittare” e in che posizione.

 

Il background usa una tile-map che è una matrice di screenblock entries (SE) (che contengono gli indici dei tile) al posto dei pixel (che contengono gli indici del colore).

 

Per gli sprite è un po’ diverso, darete un solo indice dei tile per l’intero sprite e il GBA si occuperà di trovare gli altri tile guardando la forma e la grandezza dello sprite e la sprite mapping-mode (che può essere 1D o 2D in base al sesto bit del REG_DISPCNT).

 

Del mapping fa anche parte la matrice di trasformazione, grazie alla quale è possibile ruotare, scalare o stirare gli sprite e gli sfondi.

 

Dati immagine di sprite e background

 

Il dato dell’immagine è ciò che il GBA usa per produrre un’immagine.

 

Tiles

 

Gli sprite e i background sono costituiti da una matrice di bitmap più piccole dette tile. Il tile base è una bitmap 8x8. I tile posso essere di 4 bit per pixel (bpp)  (16 colori / 16 palette) oppure 8bpp (256 colori / 1 palette).

 

Li chiameremo s-tile (single size tile) e d-tile (double size tile) rispettivamente.

Un s-tile è di 32 byte (o 20h), un d-tile è di 64 byte (o 40h). Il tile di default è il s-tile.

 

Nelle modalità tiled la VRAM è un insieme di bitmap 8x8.

Mentre nella modalità bitmap il dato che si trova dopo i primi 8 pixel contiene i successivi 8 pixel della stessa scanline, nelle modalità tiled la scanline successiva si trova immediatamente dopo quella corrente.

 

Come in tutte le bitmap è responsabilità del programmatore (cioè vostra) controllare che la bit-depth dei tile corrisponda a quella che si trova nella VRAM. Se così non fosse vi troverete un’immagine distorta, come nell’immagine seguente.

 

 

Per ora credo possa bastare, nella seconda parte parleremo dei charblocks, terminando così l’introduzione agli sprite. Alla prossima!  

 

Fonte: https://gbadev.net/tonc/objbg.html

 

Tag: @evilespeon @ZedeFire @VincyDarkHeart @Macca

Modificato 12 luglio da Diamaxus
aggiunto link al prossimo capitolo

[evilespeon]

1 minuto fa, Diamaxus ha scritto:

 

Bentrovati! È passato un po' di tempo dall'ultima volta ma a mia discolpa sono stato impegnato con un po' di cose. XD

Oggi parliamo degli sprite.  

 

Introduzione sugli sprite e i background pt. 1

 

Sebbene sia possibile creare giochi basati esclusivamente sulle modalità bitmap, ce ne sono davvero pochi che lo fanno (come ad esempio Wolfenstein e Doom).

La ragione è semplice: tutta la grafica, in questo caso, sarà renderizzata via software. Non importa quanto sia pulito il vostro codice, sarà sempre un processo lento.

 

La stragrande maggioranza dei giochi usa la grafica hardware, che troviamo nella forma di sprite e tiled backgrounds.

 

Un tiled background è una matrice di tiles ognuno dei quali contiene un indice per una bitmap di 8x8 pixel, detto tile.

Ci sono quattro tipi di background con grandezza compresa tra i 128x128 pixel (32x32 tile) fino a 1024x1024 pixel (128x128 tile).

Gli sprite sono oggetti più piccoli di grandezza compresa tra 8x8 e 64x64 pixel. Ce ne sono 128 e possono muoversi in modo indipendente l’uno dall’altro. Anche gli sprite sono costituiti da tile.

 

Ci sono tre step base che bisogna considerare: il controllo, il mapping e il dato dell’immagine.

 

Lo scopo di questo capitolo è quello di dare un infarinatura generale di quello che vedremo nei prossimi due capitoletti. Non preoccupatevi se non capite ora i concetti che tratteremo, perché alcuni concetti li vedremo nel dettaglio più avanti.

 

Controllo degli sprite e del background

 

Il primo step è il controllo.

Il controllo riguarda tutto ciò che agisce sugli sprite o sui background nella loro totalità, come ad esempio se usare 16 o 256 tile colorati e alcuni effetti.

Prima di tutto bisogna decidere se si vuole usarli o meno.

Questo si fa settando i bit giusti nel display control register REG_DISPCNT. Fatto ciò ci sono altri control register per i background: il REG_BGxCNT (indirizzi 0400:0008h – 0400:000Fh).

Per gli sprite c’è la Object Attribute Memory (OAM) che si trova all’indirizzo 0700:000h.

Ciascuno dei 128 sprite ha tre attributi che riguardano gli aspetti del controllo e del mapping degli sprite.

 

Sprite e background mapping

 

Il mapping riguarda tutto ciò che i tile usano e dove sono posizionati.

Dovrete dire al GBA quali tile “blittare” e in che posizione.

 

Il background usa una tile-map che è una matrice di screenblock entries (SE) (che contengono gli indici dei tile) al posto dei pixel (che contengono gli indici del colore).

 

Per gli sprite è un po’ diverso, darete un solo indice dei tile per l’intero sprite e il GBA si occuperà di trovare gli altri tile guardando la forma e la grandezza dello sprite e la sprite mapping-mode (che può essere 1D o 2D in base al sesto bit del REG_DISPCNT).

 

Del mapping fa anche parte la matrice di trasformazione, grazie alla quale è possibile ruotare, scalare o stirare gli sprite e gli sfondi.

 

Dati immagine di sprite e background

 

Il dato dell’immagine è ciò che il GBA usa per produrre un’immagine.

 

Tiles

 

Gli sprite e i background sono costituiti da una matrice di bitmap più piccole dette tile. Il tile base è una bitmap 8x8. I tile posso essere di 4 bit per pixel (bpp)  (16 colori / 16 palette) oppure 8bpp (256 colori / 1 palette).

 

Li chiameremo s-tile (single size tile) e d-tile (double size tile) rispettivamente.

Un s-tile è di 32 byte (o 20h), un d-tile è di 64 byte (o 40h). Il tile di default è il s-tile.

 

Nelle modalità tiled la VRAM è un insieme di bitmap 8x8.

Mentre nella modalità bitmap il dato che si trova dopo i primi 8 pixel contiene i successivi 8 pixel della stessa scanline, nelle modalità tiled la scanline successiva si trova immediatamente dopo quella corrente.

 

Come in tutte le bitmap è responsabilità del programmatore (cioè vostra) controllare che la bit-depth dei tile corrisponda a quella che si trova nella VRAM. Se così non fosse vi troverete un’immagine distorta, come nell’immagine seguente.

 

 

Per ora credo possa bastare, nella seconda parte parleremo dei charblocks, terminando così l’introduzione agli sprite. Alla prossima!  

 

Fonte: https://gbadev.net/tonc/objbg.html

 

Tag: @evilespeon @ZedeFire @VincyDarkHeart @Macca

Molto interezsante kohai e aiuta motlo che evidenzi le parti più importanti...anche se lo fai in giallo republica gialla XD

[Diamaxus]

Adesso, evilespeon ha scritto:

Molto interezsante kohai e aiuta motlo che evidenzi le parti più importanti...anche se lo fai in giallo republica gialla XD

Grazie senpai, vero anche io lo trovo un bel argomento.

Se vuoi lo evidenzio in viola XD

tanto il gba era di quel colore XD

[evilespeon]

2 minuti fa, Diamaxus ha scritto:

Grazie senpai, vero anche io lo trovo un bel argomento.

Se vuoi lo evidenzio in viola XD

Di nullaaaa kohai si lo è molto

Ah ah no no scherzavo in giallo si capisce bene tranquillo XD

[Diamaxus]

1 minuto fa, evilespeon ha scritto:

Di nullaaaa kohai si lo è molto

Ah ah no no scherzavo in giallo si capisce bene tranquillo XD

Tanto il gba è viola, ci starebbe pure  

Va bene senpai XD

[evilespeon]

3 minuti fa, Diamaxus ha scritto:

Tanto il gba è viola, ci starebbe pure  

Va bene senpai XD

Però forse si vede meno bene XD 

Ma si no prob XD 

[Diamaxus]

Adesso, evilespeon ha scritto:

Però forse si vede meno bene XD 

Ma si no prob XD 

Forse sì... sarebbe da provare XD

Va bene va bene XD

[evilespeon]

5 minuti fa, Diamaxus ha scritto:

Forse sì... sarebbe da provare XD

Va bene va bene XD

Ah ah si mi sa che in viola si fa più difficoltà XD vabbe basta che hai zeria in the heart XD 

 Bravo bravo XD 

[Diamaxus]

15 minuti fa, evilespeon ha scritto:

Ah ah si mi sa che in viola si fa più difficoltà XD vabbe basta che hai zeria in the heart XD 

 Bravo bravo XD 

Ovvio che ho zeria in the heart u.u

Grazie XD

Modificato 9 luglio da Diamaxus

[evilespeon]

29 minuti fa, Diamaxus ha scritto:

Ovvio che ho zeria in the heart u.u

Grazie XD

Btavo bravo u.u 

Di nullaaa XD 

[Diamaxus]

Introduzione sugli sprite e i background pt. 2

 

Proseguiamo con la parte finale dell’introduzione e, come accennato nella scorsa parte, parliamo dei charblocks.

 

Charblocks

 

Tutti i tile sono contenuti nei charblocks.

Ogni charblock è grande 16 kb (4000h) quindi c’è spazio per 512 s-tile (4000/20h) o 256 d-tile (4000h/40h).

Potete anche considerare i charblock come matrici di tile; 32x16 s-tile, 16x16 (o 32x8) d-tile.

I 96 kb di VRAM possono essere visti come 6 charblock: 4 per i background (0 – 3) e 2 per gli sprite (4 – 5).

Per i tiled backgrounds, il conteggio dei tile parte da un character base block fissato (in breve: CBB), che è indicato dal 2° e 3° bit del REG_BGxCNT.

L’indicizzazione dei tile degli sprite parte sempre dallo sprite block inferiore (il blocco 4, che inizia all’indirizzo 0601:0000h).

 

Purtroppo l’indicizzazione dei tile dei background e degli sprite non funziona allo stesso modo.

Per gli sprite, la numerazione segue sempre quella degli s-tile (offset di 20h) anche per i d-tile.

Per i background, l’offset è di 20h in modalità 4bpp e di 40h se la modalità è in 8bpp.

 

Sia i background che gli sprite regolari hanno 10 bit disponibili per gli indici dei tile. Cioè 1024 indici disponibili.

Poiché ogni charblock contiene 512 s-tile, potete accedere non solo al CBB ma anche a quello successivo. E se il vostro background usa i d-tile potete accedere a un totale di 4 blocchi!

 

Inoltre in una delle modalità bitmap, le bitmap si estendono fino allo sprite block inferiore. Per questo motivo, è possibile usare solo lo sprite block superiore (che contiene i tile dal 512 al 1023) in questo caso.

 

Palette e colore dei tile

 

Gli sprite e i background hanno palette separate.

La background palette si trova all’indirizzo 0500:0000h, seguita dalla sprite palette all’indirizzo 0500:0200h.

Entrambe le palette contengono 256 elementi di colori a 15 bit.

 

In modalità 8 bit, il valore del pixel nei tile è l’indice della palette per quel pixel.

In modalità 4 bit, il valore del pixel contiene il nybble inferiore dell’indice della palette; il nybble superiore è l’indice della palbank, che può essere trovato sia negli attributi degli sprite che nel nybble superiore dei tile.

Se il valore del pixel è 0 allora quel pixel sarà trasparente.

 

A causa della questione dei colore a 16 bit e la trasparenza, è essenziale che il programma che usate per la grafica lasci la palette intatta. Programmi popolari a tale scopo sono Gimp e Aseprite.

 

Tabella riassuntiva

 

Vi lascio anche una tabella riassuntiva degli attributi che vedremo nel dettaglio più avanti.

Come ho detto nella prima parte, non è importante capire tutto subito perché vedremo nel dettaglio come funzionano i background e gli sprite, nei prossimi capitoli.

 

Con questo capitoletto si conclude l’introduzione. Nel prossimo capitolo, vedremo gli sprite più nel dettaglio. Alla prossima!  

 

Fonte: https://gbadev.net/tonc/objbg.html

 

Tag: @evilespeon @ZedeFire @VincyDarkHeart @Macca

[evilespeon]

10 ore fa, Diamaxus ha scritto:

Introduzione sugli sprite e i background pt. 2

 

Proseguiamo con la parte finale dell’introduzione e, come accennato nella scorsa parte, parliamo dei charblocks.

 

Charblocks

 

Tutti i tile sono contenuti nei charblocks.

Ogni charblock è grande 16 kb (4000h) quindi c’è spazio per 512 s-tile (4000/20h) o 256 d-tile (4000h/40h).

Potete anche considerare i charblock come matrici di tile; 32x16 s-tile, 16x16 (o 32x8) d-tile.

I 96 kb di VRAM possono essere visti come 6 charblock: 4 per i background (0 – 3) e 2 per gli sprite (4 – 5).

Per i tiled backgrounds, il conteggio dei tile parte da un character base block fissato (in breve: CBB), che è indicato dal 2° e 3° bit del REG_BGxCNT.

L’indicizzazione dei tile degli sprite parte sempre dallo sprite block inferiore (il blocco 4, che inizia all’indirizzo 0601:0000h).

 

Purtroppo l’indicizzazione dei tile dei background e degli sprite non funziona allo stesso modo.

Per gli sprite, la numerazione segue sempre quella degli s-tile (offset di 20h) anche per i d-tile.

Per i background, l’offset è di 20h in modalità 4bpp e di 40h se la modalità è in 8bpp.

 

Sia i background che gli sprite regolari hanno 10 bit disponibili per gli indici dei tile. Cioè 1024 indici disponibili.

Poiché ogni charblock contiene 512 s-tile, potete accedere non solo al CBB ma anche a quello successivo. E se il vostro background usa i d-tile potete accedere a un totale di 4 blocchi!

 

Inoltre in una delle modalità bitmap, le bitmap si estendono fino allo sprite block inferiore. Per questo motivo, è possibile usare solo lo sprite block superiore (che contiene i tile dal 512 al 1023) in questo caso.

 

Palette e colore dei tile

 

Gli sprite e i background hanno palette separate.

La background palette si trova all’indirizzo 0500:0000h, seguita dalla sprite palette all’indirizzo 0500:0200h.

Entrambe le palette contengono 256 elementi di colori a 15 bit.

 

In modalità 8 bit, il valore del pixel nei tile è l’indice della palette per quel pixel.

In modalità 4 bit, il valore del pixel contiene il nybble inferiore dell’indice della palette; il nybble superiore è l’indice della palbank, che può essere trovato sia negli attributi degli sprite che nel nybble superiore dei tile.

Se il valore del pixel è 0 allora quel pixel sarà trasparente.

 

A causa della questione dei colore a 16 bit e la trasparenza, è essenziale che il programma che usate per la grafica lasci la palette intatta. Programmi popolari a tale scopo sono Gimp e Aseprite.

 

Tabella riassuntiva

 

Vi lascio anche una tabella riassuntiva degli attributi che vedremo nel dettaglio più avanti.

Come ho detto nella prima parte, non è importante capire tutto subito perché vedremo nel dettaglio come funzionano i background e gli sprite, nei prossimi capitoli.

 

Con questo capitoletto si conclude l’introduzione. Nel prossimo capitolo, vedremo gli sprite più nel dettaglio. Alla prossima!  

 

Fonte: https://gbadev.net/tonc/objbg.html

 

Tag: @evilespeon @ZedeFire @VincyDarkHeart @Macca

Un po complicato questo per me dovrei rileggere bene ma interessante 

[Diamaxus]

4 minuti fa, evilespeon ha scritto:

Un po complicato questo per me dovrei rileggere bene ma interessante 

È un po' più tecnico e meno discorsivo, ci sta se non lo capisci bene. Si basa comunque su un po' di cose dette in quello precedenza.

Ma comunque dovremmo vederlo nella pratica con i prossimi capitoli.

Se però mi dici che parte non hai capito posso provare a spiegartela, anche in mp se preferisci

[evilespeon]

8 minuti fa, Diamaxus ha scritto:

È un po' più tecnico e meno discorsivo, ci sta se non lo capisci bene. Si basa comunque su un po' di cose dette in quello precedenza.

Ma comunque dovremmo vederlo nella pratica con i prossimi capitoli.

Se però mi dici che parte non hai capito posso provare a spiegartela, anche in mp se preferisci

Si ho notato vabbevedrai che se lo rileggo un po lo capisco tranquillo

Ottimo dai sono curiosa 

Mi sa non ho capito tante parti tranquillo provo a rileggerlo poi nel caso ti dico 

[Diamaxus]

1 minuto fa, evilespeon ha scritto:

Si ho notato vabbevedrai che se lo rileggo un po lo capisco tranquillo

Ottimo dai sono curiosa 

Mi sa non ho capito tante parti tranquillo provo a rileggerlo poi nel caso ti dico 

Ah ok, allora con calma prova a rileggerlo e poi se hai ancora dubbi ti spiego

[evilespeon]

1 minuto fa, Diamaxus ha scritto:

Ah ok, allora con calma prova a rileggerlo e poi se hai ancora dubbi ti spiego

Si ok,grazieeee milleeee

[Diamaxus]

6 minuti fa, evilespeon ha scritto:

Si ok,grazieeee milleeee

Prego