.: GBArl.it :. News sulle Console Nintendo - Emulazione - Flash Cards

Lor

Friday 24 July 2009 - 09:43

E' un' ora che cerco un topic di discussioni sulle libnds ma non ho trovato nulla, quindi mi chiesto se avessi dovuto aprirlo io...
Detto fatto!
Qui possiamo discutere o fare domande sull'uso delle libnds (o problemi con il DevkitPro, perchè no).
Linko intanto le 3 guide che mi sono prefissato di seguire:

http://patater.com/files/projects/manual/manual.html
la guida di Patater, in inglese, spazia dagli esordi dell'hacking DS fino alla visualizzazione di sfondi, sprites e l'esecuzione di suoni.

http://www.dev-scene.com/NDS/Tutorials
devo ancora guardarla ma mi sembra già buona cosa

.

nospamplease by geneprio
la guida in costruzione di aurelio, esauriente ma forse difficile da capire per chi non mastica troppo bene la programmazione.

inseriscosemidateilvia:D
una guida in italiano per le basi del 2D, forse però alcuni passaggi del codice sono dati per scontati e quindi privi di spiegazione, ma c'è questo topic apposta

Di seguito la scheda delle specifiche del DS, grazie batblaster!:
http://nocash.emubase.de/gbatek.htm

Aggiungo la non meno importante (anzi!) documentazione delle libnds:
http://libnds.devkitpro.org/

Concludo con le domande:

-dove posso trovare tutti i vari valori assumibili da VRAM_*lettera*_TYPE? nella documentazione non li trovo (è più semplice che sia io in botta che loro abbiano dimenticato la cosa cmq...); neppure le guide spiegano nulla... ho capito che puoi impostare la frazione di vram in base a ciò che ci devi fare, ma non trovo la lista dei tipi impostabili... (VRAM_A_MAIN_BG_0x06000000, VRAM_C_SUB_BG_0x06200000, VRAM_D_LCD,...)

-a voi funziona il devkitpro updater? a me dice che la connessione non è attiva o una cosa del genere...

Geneprio

Friday 24 July 2009 - 09:47

ti ho rimosso il link al sito italiano in quanto possibile spam. sento in staff se puoi reinserirlo
spostato topic nell'apposita sezione

Alessandro Big

Friday 24 July 2009 - 09:49

Per la prima non ti so rispondere, io mi accontento soltanto del testo e di qualche bg o sprite messì lì, con un codice imparato ormai a memoria.
Per la seconda penso che sia inutile chiederti se sei connesso ad internet , quindi controlla il firewall, magari quello del tuo antivirus, dato che a me quello di windows non da problemi senza che io abbia toccato nulla.

Aurelio

Friday 24 July 2009 - 09:54

Per la prima vedi nel file devkitPro\libnds\include\nds\arm9\video.h
Per la seconda, spesso succede anche a me, ma basta premere continua o riprova, non ricordo

Lor

Friday 24 July 2009 - 12:22

ops scusate per il link, non era per spam, era solamente la guida a riguardo creata da aurelio... penso si potrà rimettere

@aurelio: mm adesso vedo

@staff: eh con le sezioni non capisco nulla scusate XD
qui c'era pure la guida per gli homebrew quindi pensavo fosse il posto giusto

edit: ma quanti makefile ci sono? ne trovo da 1kB,5kB,6kB,7kB...
quello del manuale di patater non funziona, l'ho sostituito con quello degli esempi nel devkitpro...
strano

Aurelio

Friday 24 July 2009 - 12:27

CITAZIONE (Lor @ Friday 24 July 2009 - 13:22)

ops scusate per il link, non era per spam, era solamente la guida a riguardo creata da aurelio... penso si potrà rimettere

@aurelio: mm adesso vedo

@staff: eh con le sezioni non capisco nulla scusate XD
qui c'era pure la guida per gli homebrew quindi fosse il posto giusto
edit: ma quanti makefile ci sono? ne trovo da 1kB,5kB,6kB,7kB...
quello del manuale di patater non funziona, l'ho sostituito con quello degli esempi nel devkitpro...
strano

Il makefile non è una cosa unica

, nel makefile vanno settato tutte le opzioni di compilazione, le librerie da includere ecc.

Lor

Friday 24 July 2009 - 12:34

mm ok tanto l'importante è che mi funga eheh

Lor

Saturday 25 July 2009 - 08:27

typedef enum {
VRAM_A_LCD = 0,
VRAM_A_MAIN_BG = 1,
VRAM_A_MAIN_BG_0x06000000 = 1 | VRAM_OFFSET(0),
VRAM_A_MAIN_BG_0x06020000 = 1 | VRAM_OFFSET(1),
VRAM_A_MAIN_BG_0x06040000 = 1 | VRAM_OFFSET(2),
VRAM_A_MAIN_BG_0x06060000 = 1 | VRAM_OFFSET(3),
VRAM_A_MAIN_SPRITE = 2,
VRAM_A_MAIN_SPRITE_0x06400000 = 2,
VRAM_A_MAIN_SPRITE_0x06420000 = 2 | VRAM_OFFSET(1),
VRAM_A_TEXTURE = 3,
VRAM_A_TEXTURE_SLOT0 = 3 | VRAM_OFFSET(0),
VRAM_A_TEXTURE_SLOT1 = 3 | VRAM_OFFSET(1),
VRAM_A_TEXTURE_SLOT2 = 3 | VRAM_OFFSET(2),
VRAM_A_TEXTURE_SLOT3 = 3 | VRAM_OFFSET(3)
} VRAM_A_TYPE;

come faccio a discriminare una variabile dall'altra?
quali devo usare in quali situazioni? edit: capito

non mi è chiara soprattutto la differenza tra queste:
VRAM_A_MAIN_BG_0x06000000 = 1 | VRAM_OFFSET(0),
VRAM_A_MAIN_BG_0x06020000 = 1 | VRAM_OFFSET(1),
VRAM_A_MAIN_BG_0x06040000 = 1 | VRAM_OFFSET(2),
VRAM_A_MAIN_BG_0x06060000 = 1 | VRAM_OFFSET(3),
mi pare di aver capito che la memoria totale (per i primi 4 bank) sia 512 e posso assegnare l'A, il B, il C o il D in locazioni interne a questi 512 kbytes...
è così?

scegliendo la variabile che non riporta la locazione di memoria si arrangia lui invece? (es: VRAM_A_MAIN_BG al posto di VRAM_A_MAIN_BG_0x06040000)

scrivendo qui forse sto già capendo (+ o meno dovrei esserci no?)
è un paradosso! è come se mi spiegassi da solo XD

facendo due conti
VRAM_A_MAIN_BG = 1 e VRAM_A_MAIN_BG_0x06000000 = 1 | VRAM_OFFSET(0) dovrebbero valere sempre 1 no?
(dato che VRAM_OFFSET(n) è (n<<3))

mm editando aggiungo domande...

posso montare più background sullo stesso banco?
cioè inizializzare il VRAM_A_MAIN_BG
e poi fare videoSetMode(MODE_5_2D | DISPLAY_BG2_ACTIVE | DISPLAY_BG3_ACTIVE); ?
ho provato a compilare e sembra funzionare, ma quando occuperò quello spazio ci starà tutto?
secondo i miei conti no °_°

non sono vere e proprie domande, ma sono comunque cosette che gradirei consolidare

Papero

Saturday 25 July 2009 - 14:35

CITAZIONE (Lor @ Saturday 25 July 2009 - 09:27)

non mi è chiara soprattutto la differenza tra queste:
VRAM_A_MAIN_BG_0x06000000 = 1 | VRAM_OFFSET(0),
VRAM_A_MAIN_BG_0x06020000 = 1 | VRAM_OFFSET(1),
VRAM_A_MAIN_BG_0x06040000 = 1 | VRAM_OFFSET(2),
VRAM_A_MAIN_BG_0x06060000 = 1 | VRAM_OFFSET(3),
mi pare di aver capito che la memoria totale (per i primi 4 bank) sia 512 e posso assegnare l'A, il B, il C o il D in locazioni interne a questi 512 kbytes...
è così?

Sì

CITAZIONE

scegliendo la variabile che non riporta la locazione di memoria si arrangia lui invece? (es: VRAM_A_MAIN_BG al posto di VRAM_A_MAIN_BG_0x06040000)

scrivendo qui forse sto già capendo (+ o meno dovrei esserci no?)
è un paradosso! è come se mi spiegassi da solo XD

facendo due conti
VRAM_A_MAIN_BG = 1 e VRAM_A_MAIN_BG_0x06000000 = 1 | VRAM_OFFSET(0) dovrebbero valere sempre 1 no?
(dato che VRAM_OFFSET(n) è (n<<3))

0<<3 è sempre 0; 1 | 0 è 1, quindi:

CODICE

VRAM_A_MAIN_BG_0x06000000 = 1 | VRAM_OFFSET(0) = 1 | (0 << 3) = 1 | 0 = 1 = VRAM_A_MAIN_BG

Comunque non si arrangia da solo: le costanti sono impostate in modo da non creare problemi se si assegnano banchi di memoria consecutivi per lo stesso scopo:

CODICE

VRAM_A_MAIN_BG_0x06000000 = VRAM_A_MAIN_BG
VRAM_B_MAIN_BG_0x06020000 = VRAM_B_MAIN_BG
VRAM_C_MAIN_BG_0x06040000 = VRAM_C_MAIN_BG
VRAM_D_MAIN_BG_0x06060000 = VRAM_D_MAIN_BG

CITAZIONE

mm editando aggiungo domande...

posso montare più background sullo stesso banco?
cioè inizializzare il VRAM_A_MAIN_BG
e poi fare videoSetMode(MODE_5_2D | DISPLAY_BG2_ACTIVE | DISPLAY_BG3_ACTIVE); ?
ho provato a compilare e sembra funzionare, ma quando occuperò quello spazio ci starà tutto?
secondo i miei conti no °_°

non sono vere e proprie domande, ma sono comunque cosette che gradirei consolidare

Sì, come hai capito, basta avere spazio sufficiente

Comunque, utilizzando le modalità a tiles (e, ovviamente, non esagerando con il numero di tiles!), c'è spazio a sufficienza per far entrare tutto quello che ti serve. Male che vada, puoi sempre aggiungere qualche banco per aumentare lo spazio a disposizione

Lor

Sunday 26 July 2009 - 09:26

grazie mille mi hai risolto tutto

Lor

Sunday 26 July 2009 - 20:19

1) se ho un background a 32768 colori ogni pixel occuperà 15 bit, giusto?
ma l'ultimo bit della word (2 byte se non ricordo male) viene utilizzato?
secondo me dev'essere utilizzato, perchè ho trovato scritto che il background BG_BMP16_512x512 richiede 512KB di memoria video.

512x512=262144 pixel;
262144x2(i 2 byte dei colori)=524288 byte, non ci sta °_°

se invece faccio

262144x15=3932160 bit
3932160:8=491520 byte, ci sta!

a questo punto sorge finalmente il mio dilemma:
quel bit di avanzo nella word come diamine fa a venire utilizzato per il pixel successivo?

edit:

2) ...il MAIN engine ha ancora una modalità grafica nella quale i 4 background distinti spariscono e rimane un unico background in modo bitmap (chiamato Mode 6 o anche large bitmap mode) che consente bitmap di dimensioni 1024x512 pixel oppure 512x1024 pixel a 256 colori (8 bpp). Il modo in questione è definito in libnds come MODE_6_2D e le bitmap, controllabili attraverso il registro del background 2, REG_BG2CNT, sono definite come segue:

BG_BMP8_1024x512 (richiede 512KB di memoria video)
BG_BMP8_512x1024 (richiede 512KB di memoria video)...

questo è un pezzo di una guida che non linko per motivi di spam (se posso la metto, anzi è ben fatta ed in ita).
mi sorge un dubbio!
questi background sono controllabili attraverso il registro del bg 2 dice, ma dalla tabella
______________________________
|Mode | BG0 | BG1 | BG2 |BG3 | T = Text
| 0 | T | T | T | T | R = Rotation
| 1 | T | T | T | R | E = Extended Rotation
| 2 | T | T | R | R | L = Large Bitmap background
| 3 | T | T | T | E |
| 4 | T | T | R | E |
| 5 | T | T | E | E |
| 6 | | L | | |
-----------------------------

sembra che siano controllati da bg1...

3) background.h è quasi vuoto, ci sono solo una ventina di define.
dove vengono specificati tutti i tipi di bg e tutte le funzioni relative che ci sono nella documentazione???

background.h:

» Clicca per leggere lo Spoiler! «

documentazione di background.h:

» Clicca per leggere lo Spoiler! «

background.h File Reference
nds background defines and functionality. More...

#include <nds/ndstypes.h>
#include <nds/arm9/video.h>
#include <nds/arm9/sassert.h>
#include <nds/memory.h>
#include <nds/dma.h>

Data Structures
struct bg_attribute
register overlay for background attribute registers More...
struct bg_scroll
register overlay for scroll registers More...
struct bg_transform
register overlay for affine matrix registers More...

Defines
#define BACKGROUND (*((bg_attribute *)0x04000008))
Overlay for main screen background attributes. Setting the properties of this struct directly sets background registers.
#define BACKGROUND_SUB (*((bg_attribute *)0x04001008))
Overlay for sub screen background attributes. Setting the properties of this struct directly sets background registers.
#define BG_BMP_BASE(base) ((base) << MAP_BASE_SHIFT)
Macro to set the graphics base in background control.
#define BG_BMP_RAM(base) ((u16*)(((base)*0x4000) + 0x06000000))
A macro which returns a u16* pointer to background graphics memory ram (Main Engine).
#define BG_BMP_RAM_SUB(base) ((u16*)(((base)*0x4000) + 0x06200000))
A macro which returns a u16* pointer to background graphics ram (Sub Engine).
#define BG_MAP_BASE(base) ((base) << MAP_BASE_SHIFT)
Macro to set the map base in background control.
#define BG_MAP_RAM(base) ((u16*)(((base)*0x800) + 0x06000000))
A macro which returns a u16* pointer to background map ram (Main Engine).
#define BG_MAP_RAM_SUB(base) ((u16*)(((base)*0x800) + 0x06200000))
A macro which returns a u16* pointer to background map ram (Sub Engine).
#define BG_OFFSET ((bg_scroll *)(0x04000010))
Overlay for main screen background scroll registers. Setting the properties of this struct directly sets background registers.
#define BG_OFFSET_SUB ((bg_scroll *)(0x04001010))
Overlay for sub screen background scroll registers. Setting the properties of this struct directly sets background registers.
#define BG_PRIORITY(n) (n)
Macro to set the priority in background control.
#define BG_TILE_BASE(base) ((base) << TILE_BASE_SHIFT)
Macro to set the tile base in background control.
#define BG_TILE_RAM(base) ((u16*)(((base)*0x4000) + 0x06000000))
A macro which returns a u16* pointer to background tile ram (Main Engine).
#define BG_TILE_RAM_SUB(base) ((u16*)(((base)*0x4000) + 0x06200000))
A macro which returns a u16* pointer to background tile ram (Sub Engine).
#define BGCTRL ( (vu16*)0x4000008)
Access to all Main screen background control registers via: BGCTRL[x] GBATEK Reference.
#define BGCTRL_SUB ( (vu16*)0x4001008)
Access to all Sub screen background control registers via: BGCTRL[x] GBATEK Reference.
#define CHAR_BASE_BLOCK(n) (((n)*0x4000)+ 0x06000000)
A macro which returns a u16* pointer to background tile ram (Main Engine).
#define CHAR_BASE_BLOCK_SUB(n) (((n)*0x4000)+ 0x06200000)
A macro which returns a u16* pointer to background tile ram (Sub Engine).
#define MAP_BASE_SHIFT 8
The shift to apply to map base when storing it in a background control register.
#define REG_BG0CNT (*(vu16*)0x4000008)
Background 0 Control register (main engine) GBATEK Reference.
#define REG_BG0CNT_SUB (*(vu16*)0x4001008)
Background 0 Control register (sub engine) GBATEK Reference.
#define REG_BG0HOFS (*(vu16*)0x4000010)
Background 0 horizontal scroll register (main engine).
#define REG_BG0HOFS_SUB (*(vu16*)0x4001010)
Background 0 horizontal scroll register (sub engine).
#define REG_BG0VOFS (*(vu16*)0x4000012)
Background 0 vertical scroll register (main engine).
#define REG_BG0VOFS_SUB (*(vu16*)0x4001012)
Background 0 vertical scroll register (sub engine).
#define REG_BG1CNT (*(vu16*)0x400000A)
Background 1 Control register (main engine) GBATEK Reference.
#define REG_BG1CNT_SUB (*(vu16*)0x400100A)
Background 1 Control register (sub engine) GBATEK Reference.
#define REG_BG1HOFS (*(vu16*)0x4000014)
Background 1 horizontal scroll register (main engine).
#define REG_BG1HOFS_SUB (*(vu16*)0x4001014)
Background 1 horizontal scroll register (sub engine).
#define REG_BG1VOFS (*(vu16*)0x4000016)
Background 1 vertical scroll register (main engine).
#define REG_BG1VOFS_SUB (*(vu16*)0x4001016)
Background 1 vertical scroll register (sub engine).
#define REG_BG2CNT (*(vu16*)0x400000C)
Background 2 Control register (main engine) GBATEK Reference.
#define REG_BG2CNT_SUB (*(vu16*)0x400100C)
Background 2 Control register (sub engine) GBATEK Reference.
#define REG_BG2HOFS (*(vu16*)0x4000018)
Background 2 horizontal scroll register (main engine).
#define REG_BG2HOFS_SUB (*(vu16*)0x4001018)
Background 2 horizontal scroll register (sub engine).
#define REG_BG2PA (*(vs16*)0x4000020)
Background 2 Affine transform (main engine).
#define REG_BG2PA_SUB (*(vs16*)0x4001020)
Background 2 Affine transform (sub engine).
#define REG_BG2PB (*(vs16*)0x4000022)
Background 2 Affine transform (main engine).
#define REG_BG2PB_SUB (*(vs16*)0x4001022)
Background 2 Affine transform (sub engine).
#define REG_BG2PC (*(vs16*)0x4000024)
Background 2 Affine transform (main engine).
#define REG_BG2PC_SUB (*(vs16*)0x4001024)
Background 2 Affine transform (sub engine).
#define REG_BG2PD (*(vs16*)0x4000026)
Background 2 Affine transform (main engine).
#define REG_BG2PD_SUB (*(vs16*)0x4001026)
Background 2 Affine transform (sub engine).
#define REG_BG2VOFS (*(vu16*)0x400001A)
Background 2 vertical scroll register (main engine).
#define REG_BG2VOFS_SUB (*(vu16*)0x400101A)
Background 2 vertical scroll register (sub engine).
#define REG_BG2X (*(vs32*)0x4000028)
Background 2 Screen Offset (main engine).
#define REG_BG2X_SUB (*(vs32*)0x4001028)
Background 2 Screen Offset (sub engine).
#define REG_BG2Y (*(vs32*)0x400002C)
Background 2 Screen Offset (main engine).
#define REG_BG2Y_SUB (*(vs32*)0x400102C)
Background 2 Screen Offset (sub engine).
#define REG_BG3CNT (*(vu16*)0x400000E)
Background 3 Control register (main engine) GBATEK Reference.
#define REG_BG3CNT_SUB (*(vu16*)0x400100E)
Background 3 Control register (sub engine) GBATEK Reference.
#define REG_BG3HOFS (*(vu16*)0x400001C)
Background 3 horizontal scroll register (main engine).
#define REG_BG3HOFS_SUB (*(vu16*)0x400101C)
Background 3 horizontal scroll register (sub engine).
#define REG_BG3PA (*(vs16*)0x4000030)
Background 3 Affine transform (main engine).
#define REG_BG3PA_SUB (*(vs16*)0x4001030)
Background 3 Affine transform (sub engine).
#define REG_BG3PB (*(vs16*)0x4000032)
Background 3 Affine transform (main engine).
#define REG_BG3PB_SUB (*(vs16*)0x4001032)
Background 3 Affine transform (sub engine).
#define REG_BG3PC (*(vs16*)0x4000034)
Background 3 Affine transform (main engine).
#define REG_BG3PC_SUB (*(vs16*)0x4001034)
Background 3 Affine transform (sub engine).
#define REG_BG3PD (*(vs16*)0x4000036)
Background 3 Affine transform (main engine).
#define REG_BG3PD_SUB (*(vs16*)0x4001036)
Background 3 Affine transform (sub engine).
#define REG_BG3VOFS (*(vu16*)0x400001E)
Background 3 vertical scroll register (main engine).
#define REG_BG3VOFS_SUB (*(vu16*)0x400101E)
Background 3 vertical scroll register (sub engine).
#define REG_BG3X (*(vs32*)0x4000038)
Background 3 Screen Offset (main engine).
#define REG_BG3X_SUB (*(vs32*)0x4001038)
Background 3 Screen Offset (sub engine).
#define REG_BG3Y (*(vs32*)0x400003C)
Background 3 Screen Offset (main engine).
#define REG_BG3Y_SUB (*(vs32*)0x400103C)
Background 3 Screen Offset (sub engine).
#define SCREEN_BASE_BLOCK(n) (((n)*0x800) + 0x06000000)
A macro which returns a u16* pointer to background Map ram (Main Engine).
#define SCREEN_BASE_BLOCK_SUB(n) (((n)*0x800) + 0x06200000)
A macro which returns a u16* pointer to background Map ram (Sub Engine).
#define TILE_BASE_SHIFT 2
The shift to apply to tile base when storing it in a background control register.
#define TILE_FLIP_H BIT(10)
The horizontal flip bit for a 16 bit tile index.
#define TILE_FLIP_V BIT(11)
The vertical flip bit for a 16 bit tile index.
#define TILE_PALETTE(n) ((n)<<12)
Macro to set the palette entry of a 16 bit tile index.

Enumerations
enum BackgroundControl {
BG_32x32 = (0 << 14),
BG_64x32 = (1 << 14),
BG_32x64 = (2 << 14),
BG_64x64 = (3 << 14),
BG_RS_16x16 = (0 << 14),
BG_RS_32x32 = (1 << 14),
BG_RS_64x64 = (2 << 14),
BG_RS_128x128 = (3 << 14),
BG_BMP8_128x128 = ((0 << 14) | BIT(7)),
BG_BMP8_256x256 = ((1 << 14) | BIT(7)),
BG_BMP8_512x256 = ((2 << 14) | BIT(7)),
BG_BMP8_512x512 = ((3 << 14) | BIT(7)),
BG_BMP8_1024x512 = BIT(14),
BG_BMP8_512x1024 = 0,
BG_BMP16_128x128 = ((0 << 14) | BIT(7) | BIT(2)),
BG_BMP16_256x256 = ((1 << 14) | BIT(7) | BIT(2)),
BG_BMP16_512x256 = ((2 << 14) | BIT(7) | BIT(2)),
BG_BMP16_512x512 = ((3 << 14) | BIT(7) | BIT(2)),
BG_MOSAIC_ON = (BIT(6)),
BG_MOSAIC_OFF = (0),
BG_PRIORITY_0 = (0),
BG_PRIORITY_1 = (1),
BG_PRIORITY_2 = (2),
BG_PRIORITY_3 = (3),
BG_WRAP_OFF = (0),
BG_WRAP_ON = (1 << 13),
BG_PALETTE_SLOT0 = 0,
BG_PALETTE_SLOT1 = 0,
BG_PALETTE_SLOT2 = BIT(13),
BG_PALETTE_SLOT3 = BIT(13),
BG_COLOR_256 = 0x80,
BG_COLOR_16 = 0x00
}
Bit defines for the background control registers. More...
enum BgSize {
BgSize_R_128x128 = (0 << 14),
BgSize_R_256x256 = (1 << 14),
BgSize_R_512x512 = (2 << 14),
BgSize_R_1024x1024 = (3 << 14),
BgSize_T_256x256 = (0 << 14) | (1 << 16),
BgSize_T_512x256 = (1 << 14) | (1 << 16),
BgSize_T_256x512 = (2 << 14) | (1 << 16),
BgSize_T_512x512 = (3 << 14) | (1 << 16),
BgSize_ER_128x128 = (0 << 14) | (2 << 16),
BgSize_ER_256x256 = (1 << 14) | (2 << 16),
BgSize_ER_512x512 = (2 << 14) | (2 << 16),
BgSize_ER_1024x1024 = (3 << 14) | (2 << 16),
BgSize_B8_128x128 = ((0 << 14) | BIT(7) | (3 << 16)),
BgSize_B8_256x256 = ((1 << 14) | BIT(7) | (3 << 16)),
BgSize_B8_512x256 = ((2 << 14) | BIT(7) | (3 << 16)),
BgSize_B8_512x512 = ((3 << 14) | BIT(7) | (3 << 16)),
BgSize_B8_1024x512 = (1 << 14) | (3 << 16),
BgSize_B8_512x1024 = (0) | (3 << 16),
BgSize_B16_128x128 = ((0 << 14) | BIT(7) | BIT(2) | (4 << 16)),
BgSize_B16_256x256 = ((1 << 14) | BIT(7) | BIT(2) | (4 << 16)),
BgSize_B16_512x256 = ((2 << 14) | BIT(7) | BIT(2) | (4 << 16)),
BgSize_B16_512x512 = ((3 << 14) | BIT(7) | BIT(2) | (4 << 16))
}
Allowed background Sizes The lower 16 bits of these defines can be used directly to set the background control register bits. More...
enum BgType {
BgType_Text8bpp,
BgType_Text4bpp,
BgType_Rotation,
BgType_ExRotation,
BgType_Bmp8,
BgType_Bmp16
}
Allowed background types, used in bgInitMain and bgInitSub. More...

Functions
void bgClearControlBits (int id, u16 bits)
Clears the specified bits from the backgrounds control register.
u16 * bgGetGfxPtr (int id)
Gets a pointer to the background graphics.
int bgGetMapBase (int id)
Gets the current map base for the supplied background.
u16 * bgGetMapPtr (int id)
Gets a pointer to the background map.
int bgGetPriority (int id)
Gets the background priority.
int bgGetTileBase (int id)
Gets the background tile base.
void bgHide (int id)
Hides the current background via the display control register.
int bgInit (int layer, BgType type, BgSize size, int mapBase, int tileBase)
Initializes a background on the main display Sets up background control register with specified settings and defaults to 256 color mode for tiled backgrounds. Sets the rotation/scale attributes for rot/ex rot backgrounds to 1:1 scale and 0 angle of rotation.
int bgInitSub (int layer, BgType type, BgSize size, int mapBase, int tileBase)
Initializes a background on the sub display Sets up background control register with specified settings and defaults to 256 color mode for tiled backgrounds. Sets the rotation/scale attributes for rot/ex rot backgrounds to 1:1 scale and 0 angle of rotation.
void bgMosaicDisable (int id)
Disables mosaic on the specified background.
void bgMosaicEnable (int id)
Enables mosaic on the specified background.
void bgRotate (int id, int angle)
Rotates the background counter clockwise by the specified angle. (this rotation is cumulative).
void bgScroll (int id, int dx, int dy)
Scrolls the background by the specified relative values.
void bgScrollf (int id, s32 dx, s32 dy)
Scrolls the background by the specified relative values (fixed point).
void bgSet (int id, int angle, s32 sx, s32 sy, s32 scrollX, s32 scrollY, s32 rotCenterX, s32 rotCenterY)
Sets the rotation and scale of the background and update background control registers.
void bgSetCenter (int id, int x, int y)
Sets the center of rotation for the supplied background.
void bgSetCenterf (int id, s32 x, s32 y)
Sets the center of rotation for the supplied background (fixed point).
vuint16 * bgSetControlBits (int id, u16 bits)
allows direct access to background control for the chosen layer, returns a pointer to the current control bits
void bgSetMapBase (int id, unsigned int base)
Sets the background map base.
void bgSetMosaic (unsigned int dx, unsigned int dy)
Sets the horizontal and vertical mosaic values for all backgrounds.
void bgSetMosaicSub (unsigned int dx, unsigned int dy)
Sets the horizontal and vertical mosaic values for all backgrounds (Sub Display).
void bgSetPriority (int id, unsigned int priority)
Sets the background priority.
void bgSetRotate (int id, int angle)
Sets the rotation angle of the specified background and updates the transform matrix.
void bgSetRotateScale (int id, int angle, s32 sx, s32 sy)
Sets the rotation and scale of the background and update background control registers.
void bgSetScale (int id, s32 sx, s32 sy)
Sets the scale of the specified background.
void bgSetScroll (int id, int x, int y)
Sets the scroll hardware to the specified location.
void bgSetScrollf (int id, s32 x, s32 y)
Sets the scroll hardware to the specified location (fixed point).
void bgSetTileBase (int id, unsigned int base)
Sets the background map base.
void bgShow (int id)
Shows the current background via the display control register.
void bgUpdate (void)
Must be called once per frame to update scroll/scale/and rotation of backgrounds.
Detailed Description
nds background defines and functionality.

Background control is provided via an API or Direct register access. Usually these methods can be mixed. However, scrolling, scaling, and rotation will have unexpected results if API and Direct Register access is mixed. Effort is being directed at ensuring the API can access all hardware features without limitation.

* API Components
* Register Access Components

The DS contains two separate hardware 2D cores responsible for rendering 2D backgrounds. The definitions below outline the libnds api for utilizing these backgrounds.

The background engine provides basic initialization and management of the 8 2D backgrounds available on the DS. Other than initialization and hardware limitations background control is identical on both main and sub screens.

The following modes of operation are allowed:

Main 2D engine
______________________________
|Mode | BG0 | BG1 | BG2 |BG3 | T = Text
| 0 | T | T | T | T | R = Rotation
| 1 | T | T | T | R | E = Extended Rotation
| 2 | T | T | R | R | L = Large Bitmap background
| 3 | T | T | T | E |
| 4 | T | T | R | E |
| 5 | T | T | E | E |
| 6 | | L | | |
-----------------------------

Sub 2D engine
______________________________
|Mode | BG0 | BG1 | BG2 |BG3 |
| 0 | T | T | T | T |
| 1 | T | T | T | R |
| 2 | T | T | R | R |
| 3 | T | T | T | E |
| 4 | T | T | R | E |
| 5 | T | T | E | E |
-----------------------------

On the main engine BG0 can be uses as a 3D rendering surface.

Papero

Sunday 26 July 2009 - 23:36

CITAZIONE (Lor @ Sunday 26 July 2009 - 21:19)

1) se ho un background a 32768 colori ogni pixel occuperà 15 bit, giusto?
ma l'ultimo bit della word (2 byte se non ricordo male) viene utilizzato?
secondo me dev'essere utilizzato, perchè ho trovato scritto che il background BG_BMP16_512x512 richiede 512KB di memoria video.

512x512=262144 pixel;
262144x2(i 2 byte dei colori)=524288 byte, non ci sta °_°

se invece faccio

262144x15=3932160 bit
3932160:8=491520 byte, ci sta!

a questo punto sorge finalmente il mio dilemma:
quel bit di avanzo nella word come diamine fa a venire utilizzato per il pixel successivo?

Ogni pixel occupa sì 15 bit, ma il 16° fa comunque parte dello spazio occupato dal valore dei colori del singolo pixel (A1B5G5R5). Quel bit A1 serve ad indicare se il pixel è trasparente (bit A1 = 0) o opaco (bit A1 = 1)

Poi se consideri che, facendo una conversione da byte a kilobyte:

524288 bytes : 1024 = 512 KiloBytes

ti accorgerai che il bg ci entra giusto giusto

CITAZIONE

edit:

2) ...il MAIN engine ha ancora una modalità grafica nella quale i 4 background distinti spariscono e rimane un unico background in modo bitmap (chiamato Mode 6 o anche large bitmap mode) che consente bitmap di dimensioni 1024x512 pixel oppure 512x1024 pixel a 256 colori (8 bpp). Il modo in questione è definito in libnds come MODE_6_2D e le bitmap, controllabili attraverso il registro del background 2, REG_BG2CNT, sono definite come segue:

BG_BMP8_1024x512 (richiede 512KB di memoria video)
BG_BMP8_512x1024 (richiede 512KB di memoria video)...

questo è un pezzo di una guida che non linko per motivi di spam (se posso la metto, anzi è ben fatta ed in ita).
mi sorge un dubbio!
questi background sono controllabili attraverso il registro del bg 2 dice, ma dalla tabella
______________________________
|Mode | BG0 | BG1 | BG2 |BG3 | T = Text
| 0 | T | T | T | T | R = Rotation
| 1 | T | T | T | R | E = Extended Rotation
| 2 | T | T | R | R | L = Large Bitmap background
| 3 | T | T | T | E |
| 4 | T | T | R | E |
| 5 | T | T | E | E |
| 6 | | L | | |
-----------------------------

sembra che siano controllati da bg1...

Deve essere un errore nella documentazione, perché l'unico background attivo in Mode 6 è il bg2. Se provi a fare:

CODICE

  videoSetMode(MODE_6_2D);
  vramSetBankA(VRAM_A_MAIN_BG);
  vramSetBankB(VRAM_B_MAIN_BG);
  vramSetBankC(VRAM_C_MAIN_BG);
  vramSetBankD(VRAM_D_MAIN_BG);
  int bg = bgInit(1, BgType_Bmp8, BgSize_B8_1024x512,0,0);
//---------------^^^

ottieni un messaggio di assert che dice che in quella modalità il background 1 non è disponibile.

CITAZIONE

3) background.h è quasi vuoto, ci sono solo una ventina di define.
dove vengono specificati tutti i tipi di bg e tutte le funzioni relative che ci sono nella documentazione???

Uhm... che versione hai di libnds? Quel file background.h sembra preso da una versione di almeno 2 anni fa. Nell'ultima il file background.h è questo

Aurelio

Monday 27 July 2009 - 08:50

Non capisco una cosa: perchè usare un background a 16bit 512*512, quando uno a 16bit 256*256 copre tranquillamente tutto lo schermo?
Se è per lo scroll, basta caricare il tutto in un buffer dichiarato come u16*(ram permettendo) e poi mostrare soltanto 256*192 pixel partendo da coordinate predefinite.
Poi per evitare dei glitch grafici basta usare una funzione di flip

Io per il DsOS sto facendo così e funziona abbastanza bene

Lor

Tuesday 28 July 2009 - 12:00

[quote]Poi se consideri che, facendo una conversione da byte a kilobyte:

524288 bytes : 1024 = 512 KiloBytes[\quote]

ma 1kbyte non sono 1000 byte???
io faccio di solito :1000 mica :1024 °_____________°
sono scandalizzato perchè ho sempre fatto così °_°

@aurelio: e la che hai pensato tu (buffer flip ecc) non è una versione "fatta in casa" di scroll?

Papero

Tuesday 28 July 2009 - 12:37

CITAZIONE

ma 1kbyte non sono 1000 byte???
io faccio di solito :1000 mica :1024 °_____________°
sono scandalizzato perchè ho sempre fatto così °_°

Hai sempre sbagliato

Aurelio

Tuesday 28 July 2009 - 14:25

CITAZIONE

@aurelio: e la che hai pensato tu (buffer flip ecc) non è una versione "fatta in casa" di scroll?

Beh sì, ma come la metti se vuoi mostrare un'immagine maggiore di 512x512 pixel?
Inoltre una funzione di flip permette di mostrare immagini a 16bit in modo rapido e senza glitch

Certo, se tu poi non necessiti di mostrare immagini aggiornandole ad ogni frame, non ti conviene usare il flip

The Lemon Man

Tuesday 28 July 2009 - 16:25

CITAZIONE (Aurelio @ Tuesday 28 July 2009 - 15:25)

Beh sì, ma come la metti se vuoi mostrare un'immagine maggiore di 512x512 pixel?
Inoltre una funzione di flip permette di mostrare immagini a 16bit in modo rapido e senza glitch

Certo, se tu poi non necessiti di mostrare immagini aggiornandole ad ogni frame, non ti conviene usare il flip

La solita buona e vecchia tecnica dei due framebuffer ?

Aurelio

Tuesday 28 July 2009 - 16:31

CITAZIONE (The Lemon Man @ Tuesday 28 July 2009 - 17:25)

La solita buona e vecchia tecnica dei due framebuffer ?

Si esatto

The Lemon Man

Tuesday 28 July 2009 - 16:33

CITAZIONE (Aurelio @ Tuesday 28 July 2009 - 17:31)

Si esatto

double o quad buffering?

Aurelio

Tuesday 28 July 2009 - 17:11

CITAZIONE (The Lemon Man @ Tuesday 28 July 2009 - 17:33)

double o quad buffering?

double, o meglio, ho un buffer che poi viene copiato ad ogni ciclo nella VRAM.

Lor

Wednesday 29 July 2009 - 19:19

CITAZIONE (Aurelio @ Monday 27 July 2009 - 09:50)

Non capisco una cosa: perchè usare un background a 16bit 512*512, quando uno a 16bit 256*256 copre tranquillamente tutto lo schermo?

CITAZIONE (Aurelio @ Tuesday 28 July 2009 - 15:25)

Beh sì, ma come la metti se vuoi mostrare un'immagine maggiore di 512x512 pixel?

Deciditi ragazzo XD

@Papero: sono scandalizzato °_°
8bit=1byte;
999byte+1=1000byte=?1kbyte? °_____________°

Papero

Wednesday 29 July 2009 - 19:36

CITAZIONE (Lor @ Wednesday 29 July 2009 - 20:19)

Deciditi ragazzo XD

@Papero: sono scandalizzato °_°
8bit=1byte;
999byte+1=1000byte=?1kbyte? °_____________°

999byte+1=1000 byte = 0,9765625 kilobyte

1 kilobyte = 2^10 byte

Aurelio

Wednesday 29 July 2009 - 19:50

CITAZIONE (Lor @ Wednesday 29 July 2009 - 20:19)

Deciditi ragazzo XD

Mi riferivo all' impossibilità di scrollare un' immagine maggiore di 512*512 pixel usando uno scroll hardware

Lor

Thursday 30 July 2009 - 08:06

CITAZIONE (Papero @ Wednesday 29 July 2009 - 20:36)

999byte+1=1000 byte = 0,9765625 kilobyte

1 kilobyte = 2^10 byte

tremendo, grazie comunque per l'illuminazione
per oggi ti chiamerò enel

mm 1Mbyte=1024kbyte immagino e così via

CITAZIONE (Aurelio @ Wednesday 29 July 2009 - 20:50)

Mi riferivo all' impossibilità di scrollare un' immagine maggiore di 512*512 pixel usando uno scroll hardware

ma non ci sono i background large o al limite i framebuffer?

accidenti ci sono molte cose che non trovo nelle documentazioni... dove dovrei guardare altrimenti?
ad esempio BG_GFX[] dove trovo spiegato cosa fa?
mi par di capire che sia l'array con tutti i pixel del bg... ma le specifiche?
e la funzione BIT(n)? dove si trova? che fa?

swiCopy ( const void * source,
void * dest,
int flags
)

Parameters:
source pointer to transfer source
dest dest = pointer to transfer destination
flags copy mode and size flags(26) = transfer width (0: halfwords, 1: words) flags(24) = transfer mode (0: copy, 1: fill) flags(20..0) = transfer count (always in words)

chiaro, copia della grafica in memoria.
ma quel parametro flags cosa fa?
non capisco dagli esempi...

per curiosità: per cosa sta quel "swi" nei nomi di queste funzioni?

Lor

Saturday 1 August 2009 - 20:03

Diamine non si possono cancellare i messaggi...

Papero

Saturday 1 August 2009 - 21:01

CITAZIONE (Lor @ Thursday 30 July 2009 - 09:06)

accidenti ci sono molte cose che non trovo nelle documentazioni... dove dovrei guardare altrimenti?
ad esempio BG_GFX[] dove trovo spiegato cosa fa?
mi par di capire che sia l'array con tutti i pixel del bg... ma le specifiche?
e la funzione BIT(n)? dove si trova? che fa?

BG_GFX punta all'indirizzo di memoria dove il DS memorizza il bg del main engine. Credo che sia utile solo se utilizzi sfondi bmp, ma non ci metto la mano sul fuoco. Nei casi i cui la documentazione manca, la cosa migliore da fare è cercare sul forum.gbadev.org, oppure su www.google.com/codesearch.

La macro BIT(n) invece è definita in jtypes (o ndstypes) e serve ad impostare il bit n a 1, quindi:

CODICE

BIT(0) = 1 << 0 = 0b00000001
BIT(1) = 1 << 1 = 0b00000010
BIT(2) = 1 << 2 = 0b00000100
BIT(3) = 1 << 3 = 0b00001000
BIT(4) = 1 << 4 = 0000010000
BIT(5) = 1 << 5 = 0b00100000
...

CITAZIONE

swiCopy ( const void * source,
void * dest,
int flags
)

Parameters:
source pointer to transfer source
dest dest = pointer to transfer destination
flags copy mode and size flags(26) = transfer width (0: halfwords, 1: words) flags(24) = transfer mode (0: copy, 1: fill) flags(20..0) = transfer count (always in words)

chiaro, copia della grafica in memoria.
ma quel parametro flags cosa fa?
non capisco dagli esempi...

per curiosità: per cosa sta quel "swi" nei nomi di queste funzioni?

SWI sta per SoftWare Interrupt.
Anche in questo caso, una ricerca sul codice già scritto ti chiarisce le idee. In linea di massima, il terzo parametro indica la dimensione dei dati da copiare. Tramite i bit 24 e 26 modifichi la modalità di trasferimento e la copia dei dati, in halfword o in word.

Aurelio

Saturday 1 August 2009 - 21:09

CITAZIONE (Papero @ Saturday 1 August 2009 - 22:01)

BG_GFX punta all'indirizzo di memoria dove il DS memorizza il bg del main engine. Credo che sia utile solo se utilizzi sfondi bmp, ma non ci metto la mano sul fuoco.

Si esatto, è un semplice array da utilizzare in questo modo:

CODICE

BG_GFX[x+y*256] = ARGB16(1, r, g, b);

x ed y sono le coordinate del pixel da colorare.
256 è la larghezza del background.
Dove r, g, b inidicano i valori di rosso, verde e blu e hanno un range che va da 0 a 31.
Il numero 1, sta invece ad indicare che il pixel è visibile.
Per utilizzare BG_GFX in questo modo, il background va inizializzato come BMP a 16 bit

Lor

Saturday 1 August 2009 - 21:58

ora mi è chiaro

CODICE

BG_GFX_SUB [touch.py * SCREEN_WIDTH + touch.px] = RGB5(31,31,31) | BIT (15);

praticamente quel BIT(15) imposta il bit + significativo della word a 1 per mostrare il pixel! non mi tornava solo il BIT(15) il resto c'ero arrivato grazie ugualmente

CITAZIONE

Per utilizzare BG_GFX in questo modo, il background va inizializzato come BMP a 16 bit

ma BG_GFX posso usarlo anche a 8 bit però, con un colore a 8 bit, no?

non mi è ancora chiara però la storia del 24 e 26, dello swicopy...

ultima cosa: una word sono 2byte e una double word sono 4 byte o sbaglio? °___°
non mi torna però la half word che quindi dovrebbe essere 1 byte...
strano da ciò che mi ricordo di scuola una word erano 2 byte...

!!! non sapevo nulla della ricerca sorgenti di google grazie 1000!!!

Papero

Saturday 1 August 2009 - 23:27

CITAZIONE (Lor @ Saturday 1 August 2009 - 22:58)

ora mi è chiaro

CODICE

BG_GFX_SUB [touch.py * SCREEN_WIDTH + touch.px] = RGB5(31,31,31) | BIT (15);

praticamente quel BIT(15) imposta il bit + significativo della word a 1 per mostrare il pixel! non mi tornava solo il BIT(15) il resto c'ero arrivato grazie ugualmente

ma BG_GFX posso usarlo anche a 8 bit però, con un colore a 8 bit, no?

Sì, stando però attento a come scrivi i pixel. Ad 8 bit vanno scritti 2 pixel per volta, quindi il codice qui sopra non funzionerà. Prova a dare un'occhiata qui, ad esempio

CITAZIONE

non mi è ancora chiara però la storia del 24 e 26, dello swicopy...

Allora, il terzo parametro di swiCopy è un int, quindi ha 32 bit. Di questi 32 bit, i primi 21 (da 0 a 20) sono occupati dalla dimensione dei dati da copiare (21 bit consentono un valore massimo di circa 256kb, che dovrebbe essere la quantità massima di dati trasferibile); gli altri bit rappresentano proprio quei "flag" di cui parla la documentazione. Questi flag possono essere attivati tramite BIT(n) o tramite dei defines presenti in libnds. Ad esempio:

CODICE

swiCopy(source, dest, size | BIT(26) | BIT(24));
// oppure
swiCopy(source, dest, size | COPY_MODE_WORD | COPY_MODE_FILL);

// infatti, in bios.h:
#define COPY_MODE_HWORD  (0)
#define COPY_MODE_WORD  (1<<26)  // oppure BIT(26)
#define COPY_MODE_COPY  (0)
#define COPY_MODE_FILL  (1<<24) // oppure BIT(24)

C'è però da dire che sia la funzione swiCopy che la funzione swiFastCopy sono affette da un bug presente nel BIOS del DS. In pratica vengono copiati velocemente solo i primi 3/4 dei dati, mentre il restante 1/4 viene copiato molto lentamente. Al riguardo c'è un topic interessante su gbadev

CITAZIONE

ultima cosa: una word sono 2byte e una double word sono 4 byte o sbaglio? °___°
non mi torna però la half word che quindi dovrebbe essere 1 byte...
strano da ciò che mi ricordo di scuola una word erano 2 byte...

In effetti dipende dalla CPU. Nel caso del DS una word è composta da 4 byte, quindi una halfword è composta da 2 byte.

CITAZIONE

!!! non sapevo nulla della ricerca sorgenti di google grazie 1000!!!

Se impari a usare bene la sintassi del motore, trovi veramente delle perle!

Lor

Sunday 2 August 2009 - 12:28

CITAZIONE (Papero @ Sunday 2 August 2009 - 00:27)

Sì, stando però attento a come scrivi i pixel. Ad 8 bit vanno scritti 2 pixel per volta, quindi il codice qui sopra non funzionerà. Prova a dare un'occhiata qui, ad esempio

mm quindi per vedere se ho capito:
sono in un background a profondità 16 bpp;
mi voglio riferire al 3000° pixel dell'array BG_GFX (che punterà in qualche posto in mezzo allo schermo, è un esempio);
scrivo BG_GFX[3000]=*qui cambierò il colore, ho capito*

sono in un background a profondità 8 bpp;
mi voglio riferire al 3000° pixel;
se scrivo BG_GFX[3000] = *colore (nella giusta modalità a 8 bpp)* andrò a scrivere nei 6000esimo e 6001esimo pixel!
quindi dovrò riferirmi a BG_GFX[1500] e scegliere se sovrascrivere il 3000esimo (primo byte) o il 3001esimo (secondo byte)

ditemi che ho capito

e poi:
#define BG_GFX ((u16*)0x6000000)

u16 forza la costante a venire inserita in 2byte (casting)
ma l'asterisco a cosa serve? c'entra con i puntatori?

Aurelio

Monday 3 August 2009 - 08:28

CITAZIONE (Lor @ Sunday 2 August 2009 - 13:28)

mm quindi per vedere se ho capito:
sono in un background a profondità 16 bpp;
mi voglio riferire al 3000° pixel dell'array BG_GFX (che punterà in qualche posto in mezzo allo schermo, è un esempio);
scrivo BG_GFX[3000]=*qui cambierò il colore, ho capito*

sono in un background a profondità 8 bpp;
mi voglio riferire al 3000° pixel;
se scrivo BG_GFX[3000] = *colore (nella giusta modalità a 8 bpp)* andrò a scrivere nei 6000esimo e 6001esimo pixel!
quindi dovrò riferirmi a BG_GFX[1500] e scegliere se sovrascrivere il 3000esimo (primo byte) o il 3001esimo (secondo byte)

ditemi che ho capito

e poi:
#define BG_GFX ((u16*)0x6000000)

u16 forza la costante a venire inserita in 2byte (casting)
ma l'asterisco a cosa serve? c'entra con i puntatori?

Uhm si dovrebbe essere corretto

BG_GFX è un puntatore con indirizzo = 0x6000000

Lor

Monday 3 August 2009 - 18:05

si ma per definire un puntatore l'asterisco non lo metto nel casting °_°
è quello che non mi torna...
e poi come diamine ci stanno 7 cifre hex in 2 byte?
per scrivere 0x06000000 mi ci vogliono 4 byte °_°

Aurelio

Monday 3 August 2009 - 18:25

CITAZIONE (Lor @ Monday 3 August 2009 - 19:05)

si ma per definire un puntatore l'asterisco non lo metto nel casting °_°
è quello che non mi torna...
e poi come diamine ci stanno 7 cifre hex in 2 byte?
per scrivere 0x06000000 mi ci vogliono 4 byte °_°

0x06000000 non è il valore della variabile, ma il suo indirizzo in memoria

Lor

Monday 3 August 2009 - 18:28

BG_GFX è un puntatore;
il puntatore contiene l'indirizzo a cui punta;
il puntatore deve poter contenere l'indirizzo :S
ma quel u16* è riferito al valore o all'indirizzo?
e poi che ci sta a fare l'asterisco nel casting?
grazie aurelio

Aurelio

Monday 3 August 2009 - 18:39

CITAZIONE (Lor @ Monday 3 August 2009 - 19:28)

BG_GFX è un puntatore;
il puntatore contiene l'indirizzo a cui punta;
il puntatore deve poter contenere l'indirizzo :S
ma quel u16* è riferito al valore o all'indirizzo?
e poi che ci sta a fare l'asterisco nel casting?
grazie aurelio

L'asterisco ci sta apposta per far capire che è un puntatore. Quell' u16* serve a far capire che la variabile BG_GFX è definita come unsigned a 16 bit e ha quell'indirizzo di partenza

Lor

Tuesday 4 August 2009 - 07:16

adesso mi maledici

continuo perchè non ho ancora capito

int ciao* = &salve;

ciao è un puntatore a 32 bit (è un int) che punta all'indirizzo di salve.
in base a questo io farei

#define BG_GFX* (&salve); (o metto "&salve" direttamente, cioè l'indirizzo di una variabile già salvata in memoria, o metto il suo indirizzo direttamente suppongo)

non mi torna il casting dato che con i define non devi dichiarare il tipo °_°

Aurelio

Tuesday 4 August 2009 - 07:51

CITAZIONE (Lor @ Tuesday 4 August 2009 - 08:16)

adesso mi maledici

continuo perchè non ho ancora capito

int ciao* = salve;

ciao è un puntatore a 32 bit (è un int) che punta all'indirizzo di salve.
in base a questo io farei

#define BG_GFX* (salve); (o metto "salve" direttamente, cioè una variabile già salvata in memoria, o metto il suo indirizzo, immagino faccia lo stesso...)

ahhh ho capito il tuo dubbio. Beh semplicemente per definire un puntatore utilizzando #define si fa in questo modo:

CODICE

#define variabile (tipo*)indirizzo

Lor

Tuesday 4 August 2009 - 08:01

mm ok

e il tipo sarebbe della variabile immagino
torniamo al dubbio iniziale, non capisco come ci stia quell'indirizzo in una variabile così piccola

dovrebbe essere un u32 allora ci starebbe!

Aurelio

Tuesday 4 August 2009 - 08:08

I puntatori non è che si riferiscono ad un indirizzo nel limite del proprio tipo.
Il tipo serve solo a definire quanti byte occupa la singola variabile.
Prova a leggerti qualche guida sui puntatori

Papero

Tuesday 4 August 2009 - 08:32

CITAZIONE (Lor @ Tuesday 4 August 2009 - 08:16)

adesso mi maledici

continuo perchè non ho ancora capito

int ciao* = salve;

ciao è un puntatore a 32 bit (è un int) che punta all'indirizzo di salve.
in base a questo io farei

#define BG_GFX* (salve); (o metto "salve" direttamente, cioè una variabile già salvata in memoria, o metto il suo indirizzo, immagino faccia lo stesso...)

Che confusione! Quello che hai scritto equivale più o meno a
int ciao = ciao * salve;
e di puntatori non ne vedo

CODICE

int* ciao; // ciao è un puntatore a un int

int x=ciao; // assegna a x l'indirizzo di ciao
int x=*ciao; // assegna a x il contenuto di ciao

ciao = &x; // assegna a ciao l'indirizzo di x
*ciao = 1243; // assegna a ciao un valore

Invece

CODICE

#define BG_GFX ( (u16*) 0x6000000 )

definisce BG_GFX, in modo tale che possiamo usarla al posto di (u16*)0x6000000. (u16*)0x6000000 è un puntatore all'indirizzo di memoria 0x6000000, dove sono immagazzinati dati di tipo u16. Come hai già visto può essere usato come un array.

A questo punto occorrerebbe conoscere cosa sono gli array e come vengono gestiti in c. A livello molto "bovino", dichiarando un array è come dichiarare un puntatore, ma con alcune aggiunte:

CODICE

int * mioArray; // viene allocata memoria solo per il puntatore
int altroArray[10]; // viene allocata memoria per il puntatore E per 10 valori di tipo int

Ora ti chiederai: ma come mai posso usare BG_GFX come se fosse un array, se poi non è stato allocato spazio per i dati che contiene? La risposta è che il DS è una macchina particolare, e alcune aree di memoria sono assegnate ad un solo compito ed hanno una grandezza e un indirizzo predefiniti e invariabili. E' il caso proprio di 0x6000000; in questi casi possiamo evitare di allocare memoria per l'array perché, appunto, non corriamo il rischio che il compilatore sovrascriva quella zona di memoria con altri dati.

Tornando al tuo dubbio, il tipo u16 non è riferito all'indirizzo, ma ai dati che contiene

Lor

Tuesday 4 August 2009 - 09:00

CITAZIONE (Papero @ Tuesday 4 August 2009 - 09:32)

Che confusione! Quello che hai scritto equivale più o meno a
int ciao = ciao * salve;
e di puntatori non ne vedo

mm scusa ho spostato l'asterisco a destra e non mi sono ricordato il &... è molto che non uso i puntatori ma ho il concetto anche se non sembra fidati sulla parola XD

CITAZIONE

CODICE

int* ciao; // ciao è un puntatore a un int

int x=ciao; // assegna a x l'indirizzo di ciao
int x=*ciao; // assegna a x il contenuto di ciao

ciao = &x; // assegna a ciao l'indirizzo di x
*ciao = 1243; // assegna a ciao un valore

ok si

CITAZIONE

Invece

CODICE

#define BG_GFX ( (u16*) 0x6000000 )

definisce BG_GFX, in modo tale che possiamo usarla al posto di (u16*)0x6000000. (u16*)0x6000000 è un puntatore all'indirizzo di memoria 0x6000000, dove sono immagazzinati dati di tipo u16. Come hai già visto può essere usato come un array.

ADESSO ci sono

quel u16 è il tipo delle CELLE che partono dalla 0x06000000!
non capivo perchè pensavo fosse un casting dell'indirizzo!
della serie

CODICE

u8 variabile8bit = (u8)0xFFFF

non ci può stare!

CITAZIONE

A questo punto occorrerebbe conoscere cosa sono gli array e come vengono gestiti in c. A livello molto "bovino", dichiarando un array è come dichiarare un puntatore, ma con alcune aggiunte:

CODICE

int * mioArray; // viene allocata memoria solo per il puntatore
int altroArray[10]; // viene allocata memoria per il puntatore E per 10 valori di tipo int

ok

CITAZIONE

Ora ti chiederai: ma come mai posso usare BG_GFX come se fosse un array, se poi non è stato allocato spazio per i dati che contiene? La risposta è che il DS è una macchina particolare, e alcune aree di memoria sono assegnate ad un solo compito ed hanno una grandezza e un indirizzo predefiniti e invariabili. E' il caso proprio di 0x6000000; in questi casi possiamo evitare di allocare memoria per l'array perché, appunto, non corriamo il rischio che il compilatore sovrascriva quella zona di memoria con altri dati.
Tornando al tuo dubbio, il tipo u16 non è riferito all'indirizzo, ma ai dati che contiene

questa non la sapevo, grazie

BENE!
chiudo l'argomento (non bastava dire fin da subito "u16 è il tipo delle celle dell'array!" e capivo? XDDD) ringraziando Aurelio e Papero, ma soprattutto la loro duratura e sovrumana pazienza, dato che qualsiasi altra persona a questo punto mi avrebbe già mandato da un pezzo dove mi meriterei di stare

Alla prossima question eheh

Aurelio

Tuesday 4 August 2009 - 09:21

CITAZIONE (Lor @ Tuesday 4 August 2009 - 10:00)

BENE!
chiudo l'argomento (non bastava dire fin da subito "u16 è il tipo delle celle dell'array!" e capivo? XDDD)

No, perchè un puntatore non è un array di sua natura.
Che poi si può usare come array spostandosi all'indirizzo successivo è un altro discorso

CITAZIONE (Lor @ Tuesday 4 August 2009 - 10:00)

Alla prossima question eheh

Speriamo che non sia così incasinata

Felice di averti aiutato

Lor

Friday 7 August 2009 - 09:03

ultimo edit del post, lo metto qui in alto per ottimi motivi XD
mi son posto delle domande e mi son risposto da solo dopo un po' di tempo, se volete confermare che ho fatto giusto leggete pure, altrimenti ignorate il post

ah, il quesito alla fine del post rimane aperto!

CITAZIONE

rieccomi all'attacco
(mi sa che questa è facile però)

sono alle prese con:
BG_TILE_RAM(base) ((u16*)(((base)*0x4000) + 0x06000000))
e
BG_BMP_RAM(base) ((u16*)(((base)*0x4000) + 0x06000000))

due locazioni utilizzate rispettivamente per memorizzare in RAM le tessere per un bg tiled o una bitmap
mi sorge il dubbio della base;
ok. u16* mi dice che da quella locazione in poi i dati vanno presi a una halfword alla volta

ma quando voglio caricare ad esempio 2 bg bitmap e 2 tessere, come mi comporto?
su una guida c'è questo esempio:

CODICE

swiCopy(TesseraVuota, BG_TILE_RAM(1), 32);
swiCopy(TesseraQuadratino, (u8*)BG_TILE_RAM(1) + 32, 32);

quindi io posso caricare tessere usando come base 1 (potrei benissimo utilizzare anche 0...no?) finchè non mi si riempiono le prime 0x4000 locazioni di memoria e poi devo passare al 2 da me?
se fosse così, non sarebbe stato + facile senza la base, mettendo una cosa dietro l'altra?
e poi: perchè BG_TILE_RAM e BG_BMP_RAM sono sovrapposte?
forse tutto questo discorso della base è perchè posso assegnare base 1, 2 e 3 alle tessere e 4, 5 e 6 alle bmp?

mi rispondo da solo

BG_TILE_RAM, BG_BMP_RAM e BG_MAP_RAM (o magari anche altre, non so) puntano tutte a 0x06000000, poi sta al programmatore sezionare la memoria (tramite il sistema delle basi) per inserire mappe, tessere o bitmap come più gli aggrada.

CITAZIONE

edit:
perchè la destinazione della TesseraQuadratino è in locazioni da 8 bit??
qui le tessere sono da 32 byte...
io non avrei specificato quel u8*, non ne trovo il senso.
e perchè non prima anche?

ho provato senza u8* vien fuori uno sghiribisso e con u8* riesce giusto °_°
probabilmente dipende dall'ultimo parametro dello swicopy che non ho ancora capito, spiegatemi XD

mi rispondo da solo

quando faccio il +32 lui interpreta +32 pezzi da 8bit, cioè 32 byte.
stessa cosa per la mappa, che va a passi da 16 bit.
posso benissimo mettere per quest'ultima (u8*) e raddoppiare i passi quando devo riferirmi alla memoria!
mi par di capire che se punto ad una locazione di memoria devo specificare (tipo*) per definire il passo, se punto ad un array questo non mi serve perchè il passo si conosce già dal tipo dell'array!

altra cosa:
probabilmente è un errore della guida, ho fatto i conti °_°
http://dev-scene.com/NDS/Tutorials_Day_4#B...VRAM_Management
guardate la parte sinistra della tabella, riferita allo spazio per le tiles.
in totale ce ne stanno fino a 512kB, non 256 come c'è scritto sotto!
non ho ragione?

Papero

Saturday 8 August 2009 - 11:58

CITAZIONE (Lor @ Friday 7 August 2009 - 10:03)

ultimo edit del post, lo metto qui in alto per ottimi motivi XD
mi son posto delle domande e mi son risposto da solo dopo un po' di tempo, se volete confermare che ho fatto giusto leggete pure, altrimenti ignorate il post

ah, il quesito alla fine del post rimane aperto!
mi rispondo da solo

BG_TILE_RAM, BG_BMP_RAM e BG_MAP_RAM (o magari anche altre, non so) puntano tutte a 0x06000000, poi sta al programmatore sezionare la memoria (tramite il sistema delle basi) per inserire mappe, tessere o bitmap come più gli aggrada.
mi rispondo da solo

quando faccio il +32 lui interpreta +32 pezzi da 8bit, cioè 32 byte.
stessa cosa per la mappa, che va a passi da 16 bit.
posso benissimo mettere per quest'ultima (u8*) e raddoppiare i passi quando devo riferirmi alla memoria!
mi par di capire che se punto ad una locazione di memoria devo specificare (tipo*) per definire il passo, se punto ad un array questo non mi serve perchè il passo si conosce già dal tipo dell'array!

Sì e sì

CITAZIONE

altra cosa:
probabilmente è un errore della guida, ho fatto i conti °_°
http://dev-scene.com/NDS/Tutorials_Day_4#B...VRAM_Management
guardate la parte sinistra della tabella, riferita allo spazio per le tiles.
in totale ce ne stanno fino a 512kB, non 256 come c'è scritto sotto!
non ho ragione?

Probabilmente è un errore, perché i blocchi di tiles (tile base o char base) a disposizione sono solo 16, da 16 kb l'uno, per un totale di 256 kb. Se controlli nel codice di libnds, scoprirai che, nel file background.h, la funzione bgInit effettua una serie di controlli sui parametri:

CODICE

int bgInit(int layer, BgType type, BgSize size, int mapBase, int tileBase)
{
    sassert(layer >= 0 && layer <= 3, "Only layers 0 - 3 are supported");
    sassert(tileBase >= 0 && tileBase <= 15, "Background tile base is out of range");
    sassert(mapBase >=0 && mapBase <= 31, "Background Map Base is out of range");
   ...

Quindi, i layer disponibili sono 4 (0-3), le map base sono 32 (0-31) e le tile base sono 16 (0-15). Occhio che le map base occupano lo stesso spazio in memoria delle prime 4 tile base!

Lor

Saturday 8 August 2009 - 12:18

CITAZIONE (Papero @ Saturday 8 August 2009 - 12:58)

Sì e sì

CITAZIONE

Probabilmente è un errore, perché i blocchi di tiles (tile base o char base) a disposizione sono solo 16, da 16 kb l'uno, per un totale di 256 kb. Se controlli nel codice di libnds, scoprirai che, nel file background.h, la funzione bgInit effettua una serie di controlli sui parametri:

CODICE

int bgInit(int layer, BgType type, BgSize size, int mapBase, int tileBase)
{
    sassert(layer >= 0 && layer <= 3, "Only layers 0 - 3 are supported");
    sassert(tileBase >= 0 && tileBase <= 15, "Background tile base is out of range");
    sassert(mapBase >=0 && mapBase <= 31, "Background Map Base is out of range");
   ...

Quindi, i layer disponibili sono 4 (0-3), le map base sono 32 (0-31) e le tile base sono 16 (0-15).

che sia il caso di segnalarlo?

CITAZIONE

Occhio che le map base occupano lo stesso spazio in memoria delle prime 4 tile base!

ci sono cascato e l'ho scoperto

grazie!

Lor

Monday 10 August 2009 - 18:49

ho ancora problemi a capire la storia del flags con lo swicopy...
ma l'ultimo parametro non è la grandezza in byte dell'elemento da passare? °_°
tutto quel

CITAZIONE

flags copy mode and size flags(26) = transfer width (0: halfwords, 1: words) flags(24) = transfer mode (0: copy, 1: fill) flags(20..0) = transfer count (always in words)

che diamine vuol dire?
e soprattutto "(20..0)" quei due punti come si interpretano?
grazie

Aurelio

Monday 10 August 2009 - 19:31

CITAZIONE (Lor @ Monday 10 August 2009 - 19:49)

ho ancora problemi a capire la storia del flags con lo swicopy...
ma l'ultimo parametro non è la grandezza in byte dell'elemento da passare? °_°
tutto quel

che diamine vuol dire?
e soprattutto "(20..0)" quei due punti come si interpretano?
grazie

allora, i primi 21 bit(dal bit 0 fino al bit 20, ecco quel 20..0), il bit 26 indica come copiare i dati(words o halfwords), il bit 25 indica la modalità(copy/fill)

Lor

Monday 10 August 2009 - 20:55

CITAZIONE

allora, i primi 21 bit(dal bit 0 fino al bit 20, ecco quel 20..0), il bit 26 indica come copiare i dati(words o halfwords), il bit 25 indica la modalità(copy/fill)

manca il verbo su "i primi 21 bit" XD immagino siano la grandezza della roba da passare...
se uso la modalità fill riempie tutto lo spazio con l'elemento passato?

PS: non c'entra minimamente, ma è un evento! ho appena trovato un pichu shiny al Giardino Trofeo XDDDDD

Papero

Tuesday 11 August 2009 - 00:31

CITAZIONE (Lor @ Monday 10 August 2009 - 21:55)

manca il verbo su "i primi 21 bit" XD immagino siano la grandezza della roba da passare...
se uso la modalità fill riempie tutto lo spazio con l'elemento passato?

PS: non c'entra minimamente, ma è un evento! ho appena trovato un pichu shiny al Giardino Trofeo XDDDDD

Quotandomi da qualche post fa:

CITAZIONE (Papero @ Sunday 2 August 2009 - 00:27)

Allora, il terzo parametro di swiCopy è un int, quindi ha 32 bit. Di questi 32 bit, i primi 21 (da 0 a 20) sono occupati dalla dimensione dei dati da copiare (21 bit consentono un valore massimo di circa 256kb, che dovrebbe essere la quantità massima di dati trasferibile)

Lor

Tuesday 11 August 2009 - 08:18

ecco perchè lo immaginavo

fill riempie lo spazio (dato dai bit 20..0) con l'elemento passato finchè non si esaurisce?
in asm era tipo così...
e poi a me cosa interessa specificare se voglio copiare in word o halfword?