Programmazione per Game Boy Advance

evilespeon · 12 luglio, 2024

4 minuti fa, Diamaxus ha scritto:

Prego

Grazieeee again

LucarioGoldragon · 26 luglio, 2024

XD

Diamaxus · 3 settembre, 2025

Ehilà! Sono consapevole che è passato parecchio dall'ultima volta, ma ho finalmente trovato il tempo di terminare anche questo capitolo, se volete rivedere quello scorso lo trovate qui.

Regular Sprites

Con sprite si indica una (piccola) immagine generalmente bidimensionale che può muoversi in modo indipendente rispetto allo sfondo.

Gli sprite sono un po’ più difficili da usare rispetto alle immagini bitmap, poiché devono essere raggruppati in tile di 8x8 pixel.

Far apparire gli sprite sullo schermo richiede 3 passaggi:

Caricare l’immagine e la palette nell’Object VRAM (OVRAM) e nell’Object palette.
Impostare gli attributi nell’Object Attribute Memory (OAM) per usare i tile appropriati e per impostare correttamente la dimensione.
Abilitare gli oggetti nel REG_DISPCNT e impostare la modalità corretta.

Ora, i tile sono di due tipi: 4bpp (single-tile, lunghi 32 bytes) e 8bpp (double-tile, lunghi 64 bytes). I tile disponibili per gli sprite sono conservati nella OVRAM, che ha dimensione 32 KB ed è mappata dagli ultimi due charblocks di tile_mem, detti anche lower (block 4, indirizzo 0601:0020h) e higher (block 5, indirizzo 0601:4000h) sprite-blocks. Il conteggio inizia sempre al lower sprite-block ed è sempre fatto con passo di 32 byte, quindi il primo tile sarà sempre all’indirizzo 0601:0020h. In ogni charblock ci sono 512 tiles, per un totale di 1024 tiles.

Nella demo la memoria è già stata mappata, quindi se ad es. vi serve il tile 123 vi potete accedere facendo tile_mem[4][123].

Inoltre, gli sprite hanno la propria palette che inizia all’indirizzo 0500:0200h.

Sprite mapping mode

Gli sprite hanno due mapping modes: 1D e 2D. Di default usano la modalità 2D ma è possibile selezionare l’altra impostando il sesto bit di REG_DISPCNT.

Facciamo un esempio. L’immagine seguente mostra lo sprite di un metroid diviso in tile. Nella modalità 2D, interpretate i charblock dello sprite come una bitmap di 256x256 pixel e lo sprite è un rettangolo di quella bitmap. Tuttavia, potreste anche considerare i charblock come una sequenza (vettore) di tile.

I numeri rossi seguono la numerazione 1D, quelli blu quella 2D.

Dal punto di vista della programmazione, la modalità 1D è più semplice perché non bisogna preoccuparsi del passo di 32 Bytes quando inseriamo in memoria gli sprite. Tuttavia, mostrare lo sprite sullo schermo è più comodo in 2D.

Per convertire le immagini si usa grit dalla shell. Supponendo che foo.bmp è una bitmap con quattro oggetti 64x16 pixel, si converte in in una bitmap di 8x8 4bpp tile in questo modo:

grit foo.bmp -gB4

Per calcolare il numero di tile che compongono uno sprite si divide il numero di pixel per 8, ad esempio 64x64 pixel = 8x8 tile.

Object Attribute Memory

Per disegnare gli sprite sullo schermo si usa l’OAM, che inizia all’indirizzo 0700:0000h ed è lunga 1024 byte. L’OAM è costituita da due struct: la OBJ_ATTR per gli attributi degli sprite regular e la OBJ_AFFINE per gli attributi che riguardano rotazione, distorsione e scala dello sprite.

typedef struct tagOBJ_ATTR {

    u16 attr0;

    u16 attr1;

    u16 attr2;

    s16 fill;

} ALIGN4 OBJ_ATTR;

 

typedef struct OBJ_AFFINE {

    u16 fill0[3];

    s16 pa;

    u16 fill1[3];

    s16 pb;

    u16 fill2[3];

    s16 pc;

    u16 fill3[3];

    s16 pd;

} ALIGN4 OBJ_AFFINE;

ALIGN4 sta per la macro

__attribute__((aligned(4))

che serve per la copia nel buffer.

Della struct OBJ_AFFINE parleremo più avanti, quando tratteremo la rotazione degli sprite. Concentriamoci per ora su OBJ_ATTR.

Le tabelle seguenti illustrano la funzione dei campi di ogni attributo (3 da 16 bit l’uno).

ATTR0

Spoiler

ATTR1

Spoiler

ATTR2

Spoiler

ATTR3

È usato solo in OBJ_AFFINE, ne parleremo più avanti.

LA DEMO

Questa volta ho usato un approccio differente. Siccome il tutorial consisteva in un progetto di 10-15 file, al posto di riscriverlo da zero, ho ripreso alcune delle funzioni originali e ho riscritto la funzione main per cercare di capire come funzionasse il caricamento dello sprite in memoria. Vi allego sia la spiegazione che i file, quindi se volete potete modificarla ulteriormente per aggiungere il movimento come visto nei capitoli precedenti o per specchiare lo sprite ad esempio. In ogni caso questa demo consiste nel far apparire un metroid a schermo.

Spoiler

File sprite_demo.c

		

		#include <string.h>		

		#include "../include/toolbox.h"		

		#include "../include/all_gfx.h"		

		 		

		OBJ_ATTR obj_buffer[128]; //128 sprite max.		

		 		

		void mostra_sprite() {		

		int x = 100, y = 50;		

		u32 tid = 0, pb = 0; // primo tile, prima palette. (3)		

		OBJ_ATTR *sprite_ptr = &obj_buffer[0]; // punta al primo tile del buffer.		

		 		

		// Imposta gli attributi dello sprite		

		obj_set_attr(sprite_ptr,		

		ATTR0_SQUARE, // Sprite quadrato, regular		

		ATTR1_SIZE_64, // 64x64 px		

		ATTR2_PALBANK(pb) | tid); // sub palette 0, tile id 0		

		 		

		// imposta la posizione dello sprite.		

		obj_set_pos(sprite_ptr, x, y);		

		void vid_vsync();		

		oam_copy(oam_mem, obj_buffer, 1); //Aggiorna 1 volta.		

		}		

		 		

		int main() {		

		 		

		// Posiziona gli elementi dello sprite di un metroid riquadrato 4bpp. (1)		

		// nella LOW obj memory (cbb == 4)		

		memcpy(&tile_mem[4][0], metrTiles, metrTilesLen); // copia i tile nella tile memory.		

		// copia la palette dello sprite nella palette memory degli sprite.		

		memcpy(pal_obj_mem, metrPal, metrPalLen);		

		 		

		// Inizializza la object attribute memory (nasconde tutti gli sprite). (2)		

		// Senza questo vedresti 128 copie del tile 0 nell'angolo in alto a sx.		

		oam_init(obj_buffer, 128);		

		// Abilita il rendering degli sprite usando il mapping 1D (tile consecutivi).		

		REG_DISPCNT = DCNT_OBJ | DCNT_OBJ_1D;		

		 		

		mostra_sprite();		

		 		

		while(1);		

		 		

		return 0;		

		 		

		}

Come detto, dobbiamo fare 3 cose (non necessariamente in questo ordine):

copiare la grafica nella VRAM
impostare l'OAM in modo che usi la grafica
abilitare gli sprite nel display control register REG_DISPCNT

Abilitiamo gli sprite impostando il bit 12 del REG_DISPCNT (punto 2 nel codice in spoiler).

La funzione oam_init() nasconde tutti gli sprite in modo da partire in uno stato noto.

Nel punto 1 del codice carichiamo lo sprite nella object VRAM.

Infine nel punto 3 impostiamo OBJ_ATTR in modo che usi i tile del metroid attraverso la funzione obj_set_attr(...) e impostiamo la posizione.

Dopo esservi posizionati nella cartella del progetto attraverso la shell e aver fatto make il risultato dovrebbe essere:

Spoiler

grit percorso/a/metr.png -fts

metr.s

Archiving into libgfx.a

Creating master header: all_gfx.h

rm metr.s

sprite_demo.c

toolbox.c

libgfx.a

linking cartridge

built ... sprite_demo.gba

ROM fixed!

Il risultato sull'emulatore è questo:

Spoiler

Vi allego anche la cartella del progetto così potete provare: sprite_demo.zip

Nel prossimo capitolo vedremo come far apparire gli sfondi, si tratta anche dell'ultimo capitolo della sezione sulle basi della programmazione per GBA.

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

Tag: @evilespeon @ZedeFire @VincyDarkHeart @Macca

Modificato 2 ore fa da Diamaxus
Corretto errore di scrittura

evilespeon · 3 settembre, 2025

3 minuti fa, Diamaxus ha scritto:
Ehilà! Sono consapevole che è passato parecchio dall'ultima volta, ma ho finalmente trovato il tempo di terminare anche questo capitolo, se volete rivedere quello scorso lo trovate qui.

Regular Sprites

Con sprite si indica una (piccola) immagine generalmente bidimensionale che può muoversi in modo indipendente rispetto allo sfondo.

Gli sprite sono un po’ più difficili da usare rispetto alle immagini bitmap, poiché devono essere raggruppati in tile di 8x8 pixel.

Far apparire gli sprite sullo schermo richiede 3 passaggi:

Caricare l’immagine e la palette nell’Object VRAM (OVRAM) e nell’Object palette.

Impostare gli attributi nell’Object Attribute Memory (OAM) per usare i tile appropriati e per impostare correttamente la dimensione.

Abilitare gli oggetti nel REG_DISPCNT e impostare la modalità corretta.

Ora, i tile sono di due tipi: 4bpp (single-tile, lunghi 32 bytes) e 8bpp (double-tile, lunghi 64 bytes). I tile disponibili per gli sprite sono conservati nella OVRAM, che ha dimensione 32 KB ed è mappata dagli ultimi due charblocks di tile_mem, detti anche lower (block 4, indirizzo 0601:0020h) e higher (block 5, indirizzo 0601:4000h) sprite-blocks. Il conteggio inizia sempre al lower sprite-block ed è sempre fatto con passo di 32 byte, quindi il primo tile sarà sempre all’indirizzo 0601:0020h. In ogni charblock ci sono 512 tiles, per un totale di 1024 tiles.

Nella demo la memoria è già stata mappata, quindi se ad es. vi serve il tile 123 vi potete accedere facendo tile_mem[4][123].

Inoltre, gli sprite hanno la propria palette che inizia all’indirizzo 0500:0200h.

Sprite mapping mode

Gli sprite hanno due mapping modes: 1D e 2D. Di default usano la modalità 2D ma è possibile selezionare l’altra impostando il sesto bit di REG_DISPCNT.

Facciamo un esempio. L’immagine seguente mostra lo sprite di un metroid diviso in tile. Nella modalità 2D, interpretate i charblock dello sprite come una bitmap di 256x256 pixel e lo sprite è un rettangolo di quella bitmap. Tuttavia, potreste anche considerare i charblock come una sequenza (vettore) di tile.

I numeri rossi seguono la numerazione 1D, quelli blu quella 2D.

Dal punto di vista della programmazione, la modalità 1D è più semplice perché non bisogna preoccuparsi del passo di 32 Bytes quando inseriamo in memoria gli sprite. Tuttavia, mostrare lo sprite sullo schermo è più comodo in 2D.

Per convertire le immagini si usa grit dalla shell. Supponendo che foo.bmp è una bitmap con quattro oggetti 64x16 pixel, si converte in in una bitmap di 8x8 4bpp tile in questo modo:
grit foo.bmp -gB4
Per calcolare il numero di tile che compongono uno sprite si divide il numero di pixel per 8, ad esempio 64x64 pixel = 8x8 tile.

Object Attribute Memory

Per disegnare gli sprite sullo schermo si usa l’OAM, che inizia all’indirizzo 0700:0000h ed è lunga 1024 byte. L’OAM è costituita da due struct: la OBJ_ATTR per gli attributi degli sprite regular e la OBJ_AFFINE per gli attributi che riguardano rotazione, distorsione e scala dello sprite.
typedef struct tagOBJ_ATTR {

    u16 attr0;

    u16 attr1;

    u16 attr2;

    s16 fill;

} ALIGN4 OBJ_ATTR;

 

typedef struct OBJ_AFFINE {

    u16 fill0[3];

    s16 pa;

    u16 fill1[3];

    s16 pb;

    u16 fill2[3];

    s16 pc;

    u16 fill3[3];

    s16 pd;

} ALIGN4 OBJ_AFFINE;
ALIGN4 sta per la macro
__attribute__((aligned(4))
che serve per la copia nel buffer.

Della struct OBJ_AFFINE parleremo più avanti, quando tratteremo la rotazione degli sprite. Concentriamoci per ora su OBJ_ATTR.

Le tabelle seguenti illustrano la funzione dei campi di ogni attributo (3 da 16 bit l’uno).

ATTR0

Nascondi contenuto

ATTR1

Nascondi contenuto

ATTR2

Apri contenuto nascosto

ATTR3

È usato solo in OBJ_AFFINE, ne parleremo più avanti.

LA DEMO

Questa volta ho usato un approccio differente. Siccome il tutorial consisteva in un progetto di 10-15 file, al posto di riscriverlo da 0 ripreso alcune delle funzioni originali e ho riscritto la funzione main per cercare di capire come funzionasse il caricamento dello sprite in memoria. Vi allego sia la spiegazione che i file, quindi se volete potete modificarla ulteriormente per aggiungere il movimento come visto nei capitoli precedenti o per specchiare lo sprite ad esempio. In ogni caso questa demo consiste nel far apparire un metroid a schermo.
Nascondi contenuto
File sprite_demo.c
		

		#include <string.h>		

		#include "../include/toolbox.h"		

		#include "../include/all_gfx.h"		

		 		

		OBJ_ATTR obj_buffer[128]; //128 sprite max.		

		 		

		void mostra_sprite() {		

		int x = 100, y = 50;		

		u32 tid = 0, pb = 0; // primo tile, prima palette. (3)		

		OBJ_ATTR *sprite_ptr = &obj_buffer[0]; // punta al primo tile del buffer.		

		 		

		// Imposta gli attributi dello sprite		

		obj_set_attr(sprite_ptr,		

		ATTR0_SQUARE, // Sprite quadrato, regular		

		ATTR1_SIZE_64, // 64x64 px		

		ATTR2_PALBANK(pb) | tid); // sub palette 0, tile id 0		

		 		

		// imposta la posizione dello sprite.		

		obj_set_pos(sprite_ptr, x, y);		

		void vid_vsync();		

		oam_copy(oam_mem, obj_buffer, 1); //Aggiorna 1 volta.		

		}		

		 		

		int main() {		

		 		

		// Posiziona gli elementi dello sprite di un metroid riquadrato 4bpp. (1)		

		// nella LOW obj memory (cbb == 4)		

		memcpy(&tile_mem[4][0], metrTiles, metrTilesLen); // copia i tile nella tile memory.		

		// copia la palette dello sprite nella palette memory degli sprite.		

		memcpy(pal_obj_mem, metrPal, metrPalLen);		

		 		

		// Inizializza la object attribute memory (nasconde tutti gli sprite). (2)		

		// Senza questo vedresti 128 copie del tile 0 nell'angolo in alto a sx.		

		oam_init(obj_buffer, 128);		

		// Abilita il rendering degli sprite usando il mapping 1D (tile consecutivi).		

		REG_DISPCNT = DCNT_OBJ | DCNT_OBJ_1D;		

		 		

		mostra_sprite();		

		 		

		while(1);		

		 		

		return 0;		

		 		

		}		

		
Come detto, dobbiamo fare 3 cose (non necessariamente in questo ordine):

copiare la grafica nella VRAM

impostare l'OAM in modo che usi la grafica

abilitare gli sprite nel display control register REG_DISPCNT

Abilitiamo gli sprite impostando il bit 12 del REG_DISPCNT (punto 2 nel codice in spoiler).

La funzione oam_init() nasconde tutti gli sprite in modo da partire in uno stato noto.

Nel punto 1 del codice carichiamo lo sprite nella object VRAM.

Infine nel punto 3 impostiamo OBJ_ATTR in modo che usi i tile del metroid attraverso la funzione obj_set_attr(...) e impostiamo la posizione.

Dopo esservi posizionati nella cartella del progetto attraverso la shell e aver fatto make il risultato dovrebbe essere:

Nascondi contenuto

grit percorso/a/metr.png -fts

metr.s

Archiving into libgfx.a

Creating master header: all_gfx.h

rm metr.s

sprite_demo.c

toolbox.c

libgfx.a

linking cartridge

built ... sprite_demo.gba

ROM fixed!

Il risultato sull'emulatore è questo:

Nascondi contenuto

Vi allego anche la cartella del progetto così potete provare: sprite_demo.zip

Nel prossimo capitolo vedremo come far apparire gli sfondi, si tratta anche dell'ultimo capitolo della sezione sulle basi della programmazione per GBA.

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

Tag: @evilespeon @ZedeFire @VincyDarkHeart @Macca

Parecchio complicato sto capitolo ma molto interessante kohai ,poi me lo rileggero' per bene con calma

Diamaxus · 3 settembre, 2025

2 minuti fa, evilespeon ha scritto:

Parecchio complicato sto capitolo ma molto interessante kohai ,poi me lo rileggero' per bene con calma

Purtroppo sì, pure a me ci è voluto un po' per capire come funzionasse. Non ti preoccupare senpai, prendila con calma

evilespeon · 3 settembre, 2025

4 minuti fa, Diamaxus ha scritto:

Purtroppo sì, pure a me ci è voluto un po' per capire come funzionasse. Non ti preoccupare senpai, prendila con calma

Ma si è molto interessante so faccio con calma tanto sono curiosa di capirci di più

Diamaxus · 3 settembre, 2025

1 minuto fa, evilespeon ha scritto:

Ma si è molto interessante so faccio con calma tanto sono curiosa di capirci di più

Che bello senpai

evilespeon · 3 settembre, 2025

Adesso, Diamaxus ha scritto:

Che bello senpai

Grandeee kohai

Diamaxus · 3 settembre, 2025

4 minuti fa, evilespeon ha scritto:

Grandeee kohai

Grazieee

evilespeon · 4 settembre, 2025

7 ore fa, Diamaxus ha scritto:

Grazieee

Di nullaaaa

Diamaxus · 2 ore fa

Rieccomi, sono riuscito a preparare anche questo capitolo XD

Oggi parliamo dei tiled background :eveeplz:

Regular tiled background

Le tilemap sono utilizzate dalla maggior parte dei giochi per gba, il motivo è che richiedono molto meno spazio in memoria rispetto alla grafica bitmap.

Prendete l’immagine 9.1 a, noterete che ci sono parti ripetute. Questi sono i tile. L’elenco di tile unici è il tileset (figura 9.1 b) , ogni elemento dell’immagine ha un indice di tile che indica quale tile deve essere renderizzato (figura 9.1 c). Sostanzialmente è così che funzionano le tilemap, non disegniamo l’intera immagine ma raggruppiamo i pixel in tile e usiamo questi per comporre l’immagine.

Spoiler

Ora nel gba abbiamo tre modalità tile (0,1 e 2). È possibile avere fino a 4 sfondi che usano le tilemap. Le dimensioni delle tilemap sono definite dai registri di controllo e sono dai 128x128 ai 1024x1024 pixel. Ogni tile deve essere 8x8 pixel.

Sia i tile che la tilemap si trovano nella VRAM, che è suddivisa in charblocks e screenblocks. Il tileset si trova nei charblock e la tilemap negli screenblock. Poiché la parola tile si usa sia per i tile grafici che per gli elementi della tilemap, chiameremo Screen Entry (SE) gli oggetti che si trovano negli screenblock e tile quelli del tileset.

Per le tilemap abbiamo a disposizione 64KB di VRAM (indirizzi 0600:0000h – 0600:FFFFh), che sono utilizzati per gli screenblock e i charblock. Possiamo scegliere quali dei due utilizzare attraverso i registri di controllo ma, dato che condividono la stessa area in memoria, dobbiamo fare attenzione a non scrivere i charblock e gli screenblock agli stessi indirizzi (vedi tabella 9.1).
Ogni screenblock è lungo 2048 byte, ossia 32 screenblock totali. Mentre ogni charblock è lungo 16KB, cioè 4 blocchi totali.

Ora, ci sono quattro passaggi necessari a impostare un tiled background:

1. carica la grafica: i tile nei charblock e i colori nella background palette

2. carica una mappa in uno o più screenblock

3. imposta la modalità corretta in REG_DISPCNT e attiva un background

4. Inizializza il registro di controllo dei background per usare i Character Base Block, Screen Base Block e bitdepth corretti

Tipi di background

Come per gli sprite, ci sono due tipi di tiled background: regular e affine. Il tipo dipende dalla modalità video (tabella 9.2). Essenzialmente funzionano allo stesso modo, ma quelli affine usano più registri e le mappe sono formattate diversamente. Per ora vediamo solo i regular.

Tutti i background hanno tre registri di controllo fondamentali. Il primo è il REG_BGxCNT dove alla x dovete sostituire 0,1,2 o 3. Qui indichiamo qual è la dimensione della tilemap e quali charblock e screenblock usa.

Gli altri due registri fondamentali sono i registri di scrolling, REG_BGxHOFS (quello di scroll orizzontale) e REG_BGxVOFS (scroll verticale).

Ciascuno di questi registri è da 16bit. REG_BG0CNT si trova all’indirizzo 0400:0008h, seguito dagli altri. Gli offset sono accoppiati con i background, formando coppie di coordinate. Che iniziano da 0400:0010h (tabella 9.3)

Nella tabella seguente è spiegato a cosa serve ciascun bit del registro e le dimensioni supportati dai due tipi di background:

Spoiler

Ci sono due cose da tenere a mente per quanto riguarda i registri di scrolling:

1. Sono registri di SOLA SCRITTURA, il che significa che non è possibile leggere i valori che contengono purtroppo, ad esempio REG_BG0HOFS++ non funziona.

2. cosa indicano: la posizione dello schermo sulla mappa, cioè non la posizione della mappa sullo schermo (che è come funzionano gli sprite).

La tabella seguente invece mostra cosa fanno i bit degli screen entry:

Spoiler

Layout della mappa

L'indice di screenblock impostato in REG_BGxCNT è lo screen base block, cioè il blocco da cui inizia la tilemap.

Supponiamo di avere una mappa grande tw×th tile. Trattandosi di una matrice, vi aspettereste di trovare lo screen entry alla posizione (tx, ty) con la formula n = tx + ty*tw, come funziona di solito con le matrici. E in effetti funziona… ma solo all'interno di un singolo screenblock.

Il problema è che i background più grandi di 32×32 tile non si limitano a usare più screenblock in modo lineare: vengono trattati come quattro mappe separate (vedi tabella 9.5). Ogni blocco numerato è un blocco consecutivo in memoria, quindi per trovare l'indice di uno screen entry dovete prima capire in quale screenblock vi trovate, e poi calcolare la posizione dello SE all'interno di quello screenblock.

È più semplice di quanto sembri, perché sappiamo che ogni screenblock contiene 32×32 tile. Procediamo così:

Trovare lo screenblock. Dividiamo le coordinate del tile per 32 per ottenere le coordinate dello screenblock:
sbx = tx/32 e sby = ty/32
Poi convertiamo questa coppia in un numero singolo con la solita formula, ricordando che qui la larghezza va espressa in screenblock (tw/32), non in tile:
screen base block = sbx + sby*(tw/32)

Trovare lo SE dentro lo screenblock. Calcoliamo il resto della divisione per avere le coordinate locali (tx%32 e ty%32) e riusiamo la stessa formula di conversione coppia → numero. Dato che ogni riga dello screenblock è larga 32 tile:
se_locale = (tx%32) + (ty%32)*32

Combinare i due. L'indice finale è la SE locale, spostata in avanti di tanti screenblock interi quanti ne precedono. Ogni screenblock contiene 1024 SE (32×32), quindi:
n = sbb*1024 + se_locale

Momento Demo:

A differenza delle altre volte, qui sono proprio una serie di passaggi da seguire, quindi non ho preparato una mia demo. Userò la demo del tutorial che seguo. La demo completa se siete interessati a provarla la trovate qui.

Questi sono i passaggi che ho elencato prima per caricare la mappa:

1. carica la grafica: i tile nei charblock e i colori nella background palette

2. carica una mappa in uno o più screenblock

3. imposta la modalità corretta in REG_DISPCNT e attiva un background

4. Inizializza il registro di controllo dei background per usare i Character Base Block, Screen Base Block e bitdepth corretti

ma fatti direttamente in C:

Spoiler

		

		#include <string.h>		

		#include "toolbox.h"
		#include "input.h"
		#include "brin.h"		

		int main()
		{
		    // Carica la palette
		    memcpy(pal_bg_mem, brinPal, brinPalLen);
		    // Carica i tiles nel Character Base Block 0
		    memcpy(&tile_mem[0][0], brinTiles, brinTilesLen);
		    // Carica la mappa nello Screen Base Block 30
		    memcpy(&se_mem[30][0], brinMap, brinMapLen);		

		    // imposta BG0 per una mappa a 4bpp 64x32t
		    //   usando charblock 0 e screenblock 31
		    REG_BG0CNT= BG_CBB(0) | BG_SBB(30) | BG_4BPP | BG_REG_64x32;
		    REG_DISPCNT= DCNT_MODE0 | DCNT_BG0;		

		    // Scrolling (non fondamentale le prime volte, concentratevi sui passaggi precedenti)
		    int x= 192, y= 64;
		    while(1)
		    {
		        vid_vsync();
		        key_poll();		

		        x += key_tri_horz();
		        y += key_tri_vert();		

		        REG_BG0HOFS= x;
		        REG_BG0VOFS= y;
		    }		

		    return 0;
		}

nota: se provate a caricare i tile e la mappa nella stessa posizione in memoria, vedrete una cosa del genere:

Spoiler

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

Con questo abbiamo finito il tutorial base :eveeplz: Se siete riusciti a seguire tutto, questi vi danno le basi per fare un gioco per gba (per ora senza audio).

Seguendo i capitoli fatti finora e mettendo tutto assieme, ho fatto Pong :pawmi: se volete esplorare un po' il codice o semplicemente provare il giochino, ve lo lascio qui

pong.zip

Se siete interessati, c'è un'altra sezione che tocca questi argomenti (alcuni più brevi di altri, quelli dov'è scritto affine sono un po' più complicati: contengono matematica un po' avanzata):

GBA Extended

10. The affine transformation matrix

11. Affine sprites

12. Affine tiled backgrounds

13. Graphic effects

14. Direct Memory Access

15. Timers

16. Hardware interrupts

17. BIOS calls

18. Beep! GBA sound introduction

Fatemi sapere se volete vedere anche questi :pawmi: @ZedeFire @VincyDarkHeart @evilespeon @Macca

Modificato 2 ore fa da Diamaxus

Macca · 2 ore fa

L'immagine 9.1a è Metroid :popplio_yes: , bene ora so programmare per il GBA

Diamaxus · 2 ore fa

1 minuto fa, Macca ha scritto:

L'immagine 9.1a è Metroid , bene ora so programmare per il GBA

sì esatto è metroid XD

IndigoTrainer · 1 ora fa

1 ora fa, Diamaxus ha scritto:
Rieccomi, sono riuscito a preparare anche questo capitolo XD

Oggi parliamo dei tiled background

Regular tiled background

Le tilemap sono utilizzate dalla maggior parte dei giochi per gba, il motivo è che richiedono molto meno spazio in memoria rispetto alla grafica bitmap.

Prendete l’immagine 9.1 a, noterete che ci sono parti ripetute. Questi sono i tile. L’elenco di tile unici è il tileset (figura 9.1 b) , ogni elemento dell’immagine ha un indice di tile che indica quale tile deve essere renderizzato (figura 9.1 c). Sostanzialmente è così che funzionano le tilemap, non disegniamo l’intera immagine ma raggruppiamo i pixel in tile e usiamo questi per comporre l’immagine.

Apri contenuto nascosto

Ora nel gba abbiamo tre modalità tile (0,1 e 2). È possibile avere fino a 4 sfondi che usano le tilemap. Le dimensioni delle tilemap sono definite dai registri di controllo e sono dai 128x128 ai 1024x1024 pixel. Ogni tile deve essere 8x8 pixel.

Sia i tile che la tilemap si trovano nella VRAM, che è suddivisa in charblocks e screenblocks. Il tileset si trova nei charblock e la tilemap negli screenblock. Poiché la parola tile si usa sia per i tile grafici che per gli elementi della tilemap, chiameremo Screen Entry (SE) gli oggetti che si trovano negli screenblock e tile quelli del tileset.

Per le tilemap abbiamo a disposizione 64KB di VRAM (indirizzi 0600:0000h – 0600:FFFFh), che sono utilizzati per gli screenblock e i charblock. Possiamo scegliere quali dei due utilizzare attraverso i registri di controllo ma, dato che condividono la stessa area in memoria, dobbiamo fare attenzione a non scrivere i charblock e gli screenblock agli stessi indirizzi (vedi tabella 9.1).
Ogni screenblock è lungo 2048 byte, ossia 32 screenblock totali. Mentre ogni charblock è lungo 16KB, cioè 4 blocchi totali.

Ora, ci sono quattro passaggi necessari a impostare un tiled background:

1. carica la grafica: i tile nei charblock e i colori nella background palette

2. carica una mappa in uno o più screenblock

3. imposta la modalità corretta in REG_DISPCNT e attiva un background

4. Inizializza il registro di controllo dei background per usare i Character Base Block, Screen Base Block e bitdepth corretti

Tipi di background

Come per gli sprite, ci sono due tipi di tiled background: regular e affine. Il tipo dipende dalla modalità video (tabella 9.2). Essenzialmente funzionano allo stesso modo, ma quelli affine usano più registri e le mappe sono formattate diversamente. Per ora vediamo solo i regular.

Tutti i background hanno tre registri di controllo fondamentali. Il primo è il REG_BGxCNT dove alla x dovete sostituire 0,1,2 o 3. Qui indichiamo qual è la dimensione della tilemap e quali charblock e screenblock usa.

Gli altri due registri fondamentali sono i registri di scrolling, REG_BGxHOFS (quello di scroll orizzontale) e REG_BGxVOFS (scroll verticale).

Ciascuno di questi registri è da 16bit. REG_BG0CNT si trova all’indirizzo 0400:0008h, seguito dagli altri. Gli offset sono accoppiati con i background, formando coppie di coordinate. Che iniziano da 0400:0010h (tabella 9.3)

Nella tabella seguente è spiegato a cosa serve ciascun bit del registro e le dimensioni supportati dai due tipi di background:

Apri contenuto nascosto

Ci sono due cose da tenere a mente per quanto riguarda i registri di scrolling:

1. Sono registri di SOLA SCRITTURA, il che significa che non è possibile leggere i valori che contengono purtroppo, ad esempio REG_BG0HOFS++ non funziona.

2. cosa indicano: la posizione dello schermo sulla mappa, cioè non la posizione della mappa sullo schermo (che è come funzionano gli sprite).

La tabella seguente invece mostra cosa fanno i bit degli screen entry:

Apri contenuto nascosto

Layout della mappa

L'indice di screenblock impostato in REG_BGxCNT è lo screen base block, cioè il blocco da cui inizia la tilemap.

Supponiamo di avere una mappa grande tw×th tile. Trattandosi di una matrice, vi aspettereste di trovare lo screen entry alla posizione (tx, ty) con la formula n = tx + ty*tw, come funziona di solito con le matrici. E in effetti funziona… ma solo all'interno di un singolo screenblock.

Il problema è che i background più grandi di 32×32 tile non si limitano a usare più screenblock in modo lineare: vengono trattati come quattro mappe separate (vedi tabella 9.5). Ogni blocco numerato è un blocco consecutivo in memoria, quindi per trovare l'indice di uno screen entry dovete prima capire in quale screenblock vi trovate, e poi calcolare la posizione dello SE all'interno di quello screenblock.

È più semplice di quanto sembri, perché sappiamo che ogni screenblock contiene 32×32 tile. Procediamo così:

Trovare lo screenblock. Dividiamo le coordinate del tile per 32 per ottenere le coordinate dello screenblock:
sbx = tx/32 e sby = ty/32
Poi convertiamo questa coppia in un numero singolo con la solita formula, ricordando che qui la larghezza va espressa in screenblock (tw/32), non in tile:
screen base block = sbx + sby*(tw/32)

Trovare lo SE dentro lo screenblock. Calcoliamo il resto della divisione per avere le coordinate locali (tx%32 e ty%32) e riusiamo la stessa formula di conversione coppia → numero. Dato che ogni riga dello screenblock è larga 32 tile:
se_locale = (tx%32) + (ty%32)*32

Combinare i due. L'indice finale è la SE locale, spostata in avanti di tanti screenblock interi quanti ne precedono. Ogni screenblock contiene 1024 SE (32×32), quindi:
n = sbb*1024 + se_locale

Momento Demo:

A differenza delle altre volte, qui sono proprio una serie di passaggi da seguire, quindi non ho preparato una mia demo. Userò la demo del tutorial che seguo. La demo completa se siete interessati a provarla la trovate qui.

Questi sono i passaggi che ho elencato prima per caricare la mappa:

1. carica la grafica: i tile nei charblock e i colori nella background palette

2. carica una mappa in uno o più screenblock

3. imposta la modalità corretta in REG_DISPCNT e attiva un background

4. Inizializza il registro di controllo dei background per usare i Character Base Block, Screen Base Block e bitdepth corretti

ma fatti direttamente in C:
Apri contenuto nascosto
		

		#include <string.h>		

		#include "toolbox.h"
		#include "input.h"
		#include "brin.h"		

		int main()
		{
		    // Carica la palette
		    memcpy(pal_bg_mem, brinPal, brinPalLen);
		    // Carica i tiles nel Character Base Block 0
		    memcpy(&tile_mem[0][0], brinTiles, brinTilesLen);
		    // Carica la mappa nello Screen Base Block 30
		    memcpy(&se_mem[30][0], brinMap, brinMapLen);		

		    // imposta BG0 per una mappa a 4bpp 64x32t
		    //   usando charblock 0 e screenblock 31
		    REG_BG0CNT= BG_CBB(0) | BG_SBB(30) | BG_4BPP | BG_REG_64x32;
		    REG_DISPCNT= DCNT_MODE0 | DCNT_BG0;		

		    // Scrolling (non fondamentale le prime volte, concentratevi sui passaggi precedenti)
		    int x= 192, y= 64;
		    while(1)
		    {
		        vid_vsync();
		        key_poll();		

		        x += key_tri_horz();
		        y += key_tri_vert();		

		        REG_BG0HOFS= x;
		        REG_BG0VOFS= y;
		    }		

		    return 0;
		}
		 		

		
nota: se provate a caricare i tile e la mappa nella stessa posizione in memoria, vedrete una cosa del genere:

Apri contenuto nascosto

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

Con questo abbiamo finito il tutorial base Se siete riusciti a seguire tutto, questi vi danno le basi per fare un gioco per gba (per ora senza audio).

Seguendo i capitoli fatti finora e mettendo tutto assieme, ho fatto Pong se volete esplorare un po' il codice o semplicemente provare il giochino, ve lo lascio qui

pong.zip 62.4 kB · 0 downloads

Se siete interessati, c'è un'altra sezione che tocca questi argomenti (alcuni più brevi di altri, quelli dov'è scritto affine sono un po' più complicati: contengono matematica un po' avanzata):

GBA Extended

10. The affine transformation matrix

11. Affine sprites

12. Affine tiled backgrounds

13. Graphic effects

14. Direct Memory Access

15. Timers

16. Hardware interrupts

17. BIOS calls

18. Beep! GBA sound introduction

Fatemi sapere se volete vedere anche questi @ZedeFire @VincyDarkHeart @evilespeon @Macca

Guida molto costruttiva e dettagliata, complimenti. Tra l'altro questo hobby può essere molto formativo per un appassionato GBA che vuole apprendere da solo i rudimenti dell'informatica (non solo al fine di sviluppare giochi), perché molte di queste nozioni (ad es. base+offset di memoria) sono alla base del funzionamento di ogni architettura informatica moderna.

evilespeon · 1 ora fa

1 ora fa, Diamaxus ha scritto:
Rieccomi, sono riuscito a preparare anche questo capitolo XD

Oggi parliamo dei tiled background

Regular tiled background

Le tilemap sono utilizzate dalla maggior parte dei giochi per gba, il motivo è che richiedono molto meno spazio in memoria rispetto alla grafica bitmap.

Prendete l’immagine 9.1 a, noterete che ci sono parti ripetute. Questi sono i tile. L’elenco di tile unici è il tileset (figura 9.1 b) , ogni elemento dell’immagine ha un indice di tile che indica quale tile deve essere renderizzato (figura 9.1 c). Sostanzialmente è così che funzionano le tilemap, non disegniamo l’intera immagine ma raggruppiamo i pixel in tile e usiamo questi per comporre l’immagine.

Nascondi contenuto

Ora nel gba abbiamo tre modalità tile (0,1 e 2). È possibile avere fino a 4 sfondi che usano le tilemap. Le dimensioni delle tilemap sono definite dai registri di controllo e sono dai 128x128 ai 1024x1024 pixel. Ogni tile deve essere 8x8 pixel.

Sia i tile che la tilemap si trovano nella VRAM, che è suddivisa in charblocks e screenblocks. Il tileset si trova nei charblock e la tilemap negli screenblock. Poiché la parola tile si usa sia per i tile grafici che per gli elementi della tilemap, chiameremo Screen Entry (SE) gli oggetti che si trovano negli screenblock e tile quelli del tileset.

Per le tilemap abbiamo a disposizione 64KB di VRAM (indirizzi 0600:0000h – 0600:FFFFh), che sono utilizzati per gli screenblock e i charblock. Possiamo scegliere quali dei due utilizzare attraverso i registri di controllo ma, dato che condividono la stessa area in memoria, dobbiamo fare attenzione a non scrivere i charblock e gli screenblock agli stessi indirizzi (vedi tabella 9.1).
Ogni screenblock è lungo 2048 byte, ossia 32 screenblock totali. Mentre ogni charblock è lungo 16KB, cioè 4 blocchi totali.

Ora, ci sono quattro passaggi necessari a impostare un tiled background:

1. carica la grafica: i tile nei charblock e i colori nella background palette

2. carica una mappa in uno o più screenblock

3. imposta la modalità corretta in REG_DISPCNT e attiva un background

4. Inizializza il registro di controllo dei background per usare i Character Base Block, Screen Base Block e bitdepth corretti

Tipi di background

Come per gli sprite, ci sono due tipi di tiled background: regular e affine. Il tipo dipende dalla modalità video (tabella 9.2). Essenzialmente funzionano allo stesso modo, ma quelli affine usano più registri e le mappe sono formattate diversamente. Per ora vediamo solo i regular.

Tutti i background hanno tre registri di controllo fondamentali. Il primo è il REG_BGxCNT dove alla x dovete sostituire 0,1,2 o 3. Qui indichiamo qual è la dimensione della tilemap e quali charblock e screenblock usa.

Gli altri due registri fondamentali sono i registri di scrolling, REG_BGxHOFS (quello di scroll orizzontale) e REG_BGxVOFS (scroll verticale).

Ciascuno di questi registri è da 16bit. REG_BG0CNT si trova all’indirizzo 0400:0008h, seguito dagli altri. Gli offset sono accoppiati con i background, formando coppie di coordinate. Che iniziano da 0400:0010h (tabella 9.3)

Nella tabella seguente è spiegato a cosa serve ciascun bit del registro e le dimensioni supportati dai due tipi di background:

Apri contenuto nascosto

Ci sono due cose da tenere a mente per quanto riguarda i registri di scrolling:

1. Sono registri di SOLA SCRITTURA, il che significa che non è possibile leggere i valori che contengono purtroppo, ad esempio REG_BG0HOFS++ non funziona.

2. cosa indicano: la posizione dello schermo sulla mappa, cioè non la posizione della mappa sullo schermo (che è come funzionano gli sprite).

La tabella seguente invece mostra cosa fanno i bit degli screen entry:

Apri contenuto nascosto

Layout della mappa

L'indice di screenblock impostato in REG_BGxCNT è lo screen base block, cioè il blocco da cui inizia la tilemap.

Supponiamo di avere una mappa grande tw×th tile. Trattandosi di una matrice, vi aspettereste di trovare lo screen entry alla posizione (tx, ty) con la formula n = tx + ty*tw, come funziona di solito con le matrici. E in effetti funziona… ma solo all'interno di un singolo screenblock.

Il problema è che i background più grandi di 32×32 tile non si limitano a usare più screenblock in modo lineare: vengono trattati come quattro mappe separate (vedi tabella 9.5). Ogni blocco numerato è un blocco consecutivo in memoria, quindi per trovare l'indice di uno screen entry dovete prima capire in quale screenblock vi trovate, e poi calcolare la posizione dello SE all'interno di quello screenblock.

È più semplice di quanto sembri, perché sappiamo che ogni screenblock contiene 32×32 tile. Procediamo così:

Trovare lo screenblock. Dividiamo le coordinate del tile per 32 per ottenere le coordinate dello screenblock:
sbx = tx/32 e sby = ty/32
Poi convertiamo questa coppia in un numero singolo con la solita formula, ricordando che qui la larghezza va espressa in screenblock (tw/32), non in tile:
screen base block = sbx + sby*(tw/32)

Trovare lo SE dentro lo screenblock. Calcoliamo il resto della divisione per avere le coordinate locali (tx%32 e ty%32) e riusiamo la stessa formula di conversione coppia → numero. Dato che ogni riga dello screenblock è larga 32 tile:
se_locale = (tx%32) + (ty%32)*32

Combinare i due. L'indice finale è la SE locale, spostata in avanti di tanti screenblock interi quanti ne precedono. Ogni screenblock contiene 1024 SE (32×32), quindi:
n = sbb*1024 + se_locale

Momento Demo:

A differenza delle altre volte, qui sono proprio una serie di passaggi da seguire, quindi non ho preparato una mia demo. Userò la demo del tutorial che seguo. La demo completa se siete interessati a provarla la trovate qui.

Questi sono i passaggi che ho elencato prima per caricare la mappa:

1. carica la grafica: i tile nei charblock e i colori nella background palette

2. carica una mappa in uno o più screenblock

3. imposta la modalità corretta in REG_DISPCNT e attiva un background

4. Inizializza il registro di controllo dei background per usare i Character Base Block, Screen Base Block e bitdepth corretti

ma fatti direttamente in C:
Apri contenuto nascosto
		

		#include <string.h>		

		#include "toolbox.h"
		#include "input.h"
		#include "brin.h"		

		int main()
		{
		    // Carica la palette
		    memcpy(pal_bg_mem, brinPal, brinPalLen);
		    // Carica i tiles nel Character Base Block 0
		    memcpy(&tile_mem[0][0], brinTiles, brinTilesLen);
		    // Carica la mappa nello Screen Base Block 30
		    memcpy(&se_mem[30][0], brinMap, brinMapLen);		

		    // imposta BG0 per una mappa a 4bpp 64x32t
		    //   usando charblock 0 e screenblock 31
		    REG_BG0CNT= BG_CBB(0) | BG_SBB(30) | BG_4BPP | BG_REG_64x32;
		    REG_DISPCNT= DCNT_MODE0 | DCNT_BG0;		

		    // Scrolling (non fondamentale le prime volte, concentratevi sui passaggi precedenti)
		    int x= 192, y= 64;
		    while(1)
		    {
		        vid_vsync();
		        key_poll();		

		        x += key_tri_horz();
		        y += key_tri_vert();		

		        REG_BG0HOFS= x;
		        REG_BG0VOFS= y;
		    }		

		    return 0;
		}
		 		

		
nota: se provate a caricare i tile e la mappa nella stessa posizione in memoria, vedrete una cosa del genere:

Apri contenuto nascosto

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

Con questo abbiamo finito il tutorial base Se siete riusciti a seguire tutto, questi vi danno le basi per fare un gioco per gba (per ora senza audio).

Seguendo i capitoli fatti finora e mettendo tutto assieme, ho fatto Pong se volete esplorare un po' il codice o semplicemente provare il giochino, ve lo lascio qui

pong.zip 62.4 kB · 0 downloads

Se siete interessati, c'è un'altra sezione che tocca questi argomenti (alcuni più brevi di altri, quelli dov'è scritto affine sono un po' più complicati: contengono matematica un po' avanzata):

GBA Extended

10. The affine transformation matrix

11. Affine sprites

12. Affine tiled backgrounds

13. Graphic effects

14. Direct Memory Access

15. Timers

16. Hardware interrupts

17. BIOS calls

18. Beep! GBA sound introduction

Fatemi sapere se volete vedere anche questi @ZedeFire @VincyDarkHeart @evilespeon @Macca

Al solito mi sa dovrò rileggere un po di volte per capirci tutto XD ma ottimooo lavoro kohai sempre molto interessante

Diamaxus · 1 ora fa

5 minuti fa, IndigoTrainer ha scritto:

Guida molto costruttiva e dettagliata, complimenti. Tra l'altro questo hobby può essere molto formativo per un appassionato GBA che vuole apprendere da solo i rudimenti dell'informatica (non solo al fine di sviluppare giochi), perché molte di queste nozioni (ad es. base+offset di memoria) sono alla base del funzionamento di ogni architettura informatica moderna.

Grazie mille!

Vero, assolutamente. Potrebbe essere un modo divertente per approfondire questo tipo di cose. :smile1:

Grazie del complimento :smile2:

8 minuti fa, evilespeon ha scritto:

Al solito mi sa dovrò rileggere un po di volte per capirci tutto XD ma ottimooo lavoro kohai sempre molto interessante

Ci sta senpai, non è semplice XD Grazieeeee :pawmi:

evilespeon · 1 ora fa

3 minuti fa, Diamaxus ha scritto:

Grazie mille!

Vero, assolutamente. Potrebbe essere un modo divertente per approfondire questo tipo di cose.

Grazie del complimento

Ci sta senpai, non è semplice XD Grazieeeee

Ah ah si direi di si per me che ne capisco poco di ste cose ma vabbe rileggendo si capisce bene tranquillo

Di nullaaaa

Diamaxus · 1 ora fa

4 minuti fa, evilespeon ha scritto:

Ah ah si direi di si per me che ne capisco poco di ste cose ma vabbe rileggendo si capisce bene tranquillo

Di nullaaaa

spero di aver spiegato in modo abbastanza semplice, a volte è difficile semplificare cose che uno ha interiorizzato troppo XD davvero? mi fa un sacco piacere :pawmi:

evilespeon · 1 ora fa

4 minuti fa, Diamaxus ha scritto:

spero di aver spiegato in modo abbastanza semplice, a volte è difficile semplificare cose che uno ha interiorizzato troppo XD davvero? mi fa un sacco piacere

Ma si tranquillo quando rileggo poi capisco bene tutto so spieghi molto bene e poi so non è easy XD che belloooo

Diamaxus · 44 minuti fa

23 minuti fa, evilespeon ha scritto:

Ma si tranquillo quando rileggo poi capisco bene tutto so spieghi molto bene e poi so non è easy XD che belloooo

Sono contento :pawmi: grazieee senpai

Accedi

Programmazione per Game Boy Advance

Post raccomandati

evilespeon

LucarioGoldragon

Diamaxus

evilespeon

Diamaxus

evilespeon

Diamaxus

evilespeon

Diamaxus

evilespeon

Diamaxus

Macca

Diamaxus

IndigoTrainer

evilespeon

Diamaxus

evilespeon

Diamaxus

evilespeon

Diamaxus

Crea un account o accedi per commentare

Crea adesso un account

Accedi

Contenuto Simile

hack roms [Fire Red] Pokémon Climax - Beta 3.0 1 2 3

[GUIDA] Come modificare gli sprites dei personaggi nei giochi di 3a generazione

guida [Download] Emulatori

[CERCO] Pokémon BOX R&Z e Pokémon Pinball R&Z

hack rom Progetto Hack Rom

Utenti nella discussione 0 utenti

Millennium

PokéPoints Store

Iniziative

Premium Member

PokéClubs

Attività

Attività personalizzate