#171386 - MichaelMossman - Tue Nov 17, 2009 5:59 pm
Sorry to be a bit slow but I still can't get my head around the difference between normal background modes and framebuffer.
Why is it that I can address VRAM_A directly if using FB0 but not with BG0, using MODE_5_2D for example.
P.s. I really have read all the tutorials I can lay my hand on but maybe this is so basic that nobody thinks it needs explaining ?
Thanks, Mike
#171387 - DiscoStew - Tue Nov 17, 2009 7:03 pm
http://nocash.emubase.de/gbatek.htm#dsmemorycontrolvram
The reason why you can address the VRAM in such a way is because of how the bank is being mapped. When using a framebuffer mode, in order for it to be displayed, the bank must be set to LCD mode, and that maps it to a specific address (like VRAM_A is at 6800000h). When using a background mode, the bank for which it uses must be set as a MAIN_BG (or SUB_BG for the sub screen), and that has a different mapped address to it (which starts at 6000000h for the main, or 6200000h for the sub). That doesn't necessarily mean that the banks in order A-D will start from there, as each bank can be reorganized, like bank D can start at 6000000h instead of bank A. It's all dependent on how you set it.
I hope that is what you were asking about.
_________________
DS - It's all about DiscoStew
#171389 - mukunda - Wed Nov 18, 2009 5:20 am
Advantage of using a BG is you can still mix other graphics with it, and also apply affine transformations to the image.
Advantage of using a framebuffer is that you can display things from the VRAM in LCDC mode. Display capturing writes to VRAM banks in LCDC mode, so you can display a captured block instantly. You can also capture the normal main engine's graphics while displaying something else in framebuffer mode, or even make a blur effect by capture-blending the graphics to the LCDC block you are currently displaying.
#171399 - MichaelMossman - Wed Nov 18, 2009 12:39 pm
Sorry, let me be a little bit more specific.
I started with the simple Starts demo at :-
http//:www.dev-scene.com/NDS/Tutorials_Day_3 (Page 15 if you print it out or Frame Buffer 101 from the menu)
This compiled and ran beautifully. I then removed the lines at :-
videoSetMode(MODE_FB0);
vramSetBankA(VRAM_A_LCD);
and replaced them with :-
videoSetMode(MODE_5_2D | DISPLAY_BG0_ACTIVE);
vramSetBankA(VRAM_A_MAIN_BG_0x06000000);
Surely, this should now point VRAM_A to 0x0600:0000 ?
(VRAM_A is where the Stars function writes to)
Anyway, this compiled without error but gave me a blank screen.
Is my logic still missing something vital ?
#171401 - sverx - Wed Nov 18, 2009 12:54 pm
BGs can be of different types (and should be set accordingly), maybe you want a bitmap one to replace a FrameBuffer. Then you should use BG2 or BG3 in MODE_5_2D (BG0 can't be a bitmap one).
You can try the 2nd example in my Nintendo DS 2D tutorial (which is in Italian but you can just read the code there...)
Hope this helps
#171402 - Cearn - Wed Nov 18, 2009 1:05 pm
VRAM_A doesn't actually point to what bank A is linked to. In video.h, it is defined like this:
| Code: |
#define VRAM_A ((u16*)0x6800000)/*!< \brief pointer to vram bank A mapped as LCD*/
|
Note the comment. What VRAM_A actually point to is the location of the bank when mapped as LCD. The memory locations are linked to the graphics type (Frame buffer, main/sub BG, main/sub OBJ), not the banks. I suppose a better name might have been VRAM_LCD_A to avoid the confusion.
This is how I try to look at the VRAM mapping.
The banks are more like memory modules than memory slots. There are a number of different capabilities(*) that VRAM can be used for: Frame buffer, main/sub BG/OBJ gfx/pal, texture gfx/pal or ARM7 RAM. These are the slots. The memory banks are memory modules that you can put into the slots, so that that capability can have memory to use. Some, but not all, of these slots have addressed attached, like 0600:0000 for main BG. When you're dealing with addressless capabilities, like textures, you insert the module into a slot that does have an address, write to it. You then disconnect the module and plug it back into where data to be used for.
EDIT:
In case I misread the question and you're asking why the simple replacement doesn't work: backgrounds and frame buffers are completely different beasts. BGs need a little more work to set up. You need to set the video mode and banks, and enable the background, set-up the BG in REG_BGnCNT (and probably the affine/scrolling registers too). And, of course, fill the tile/map/bmp buffers with something. This is all covered later in Day 3.
(*) term pending ...
#171406 - MichaelMossman - Wed Nov 18, 2009 2:04 pm
Thank you, Cearn, that really helps.
You are correct in your last assumption. All I was trying to do was modify the demo so that I could actually write something to a background without getting all tied up with importing bitmaps.
I just want to be able to create something on the screen, as a background, but do it by actually using drawing functions and not importing something else.
I need it to be a background and not a framebuffer as I then want to put something else into a different background, so as to go on top.
As I am still in the early stages of experimenting with simple steps, I thought that modifying an existing demo might be a sensible way to go forward but I just don't seem to be able to find a SIMPLE demo, which writes directly to a background without importing a bitmap.
#171407 - sverx - Wed Nov 18, 2009 2:08 pm
| MichaelMossman wrote: |
| I just don't seem to be able to find a SIMPLE demo, which writes directly to a background without importing a bitmap. |
| Code: |
#include <nds.h>
int main(void) {
vramSetBankC (VRAM_C_SUB_BG);
videoSetModeSub (MODE_4_2D | DISPLAY_BG3_ACTIVE);
REG_BG3CNT_SUB = BG_BMP16_256x256 | BG_BMP_BASE(0);
REG_BG3PA_SUB = 1 << 8;
REG_BG3PB_SUB = 0;
REG_BG3PC_SUB = 0;
REG_BG3PD_SUB = 1 << 8;
lcdMainOnTop ();
while(1) {
scanKeys();
if (keysHeld() & KEY_TOUCH) {
touchPosition touch; touchRead(&touch);
BG_GFX_SUB [touch.py * SCREEN_WIDTH + touch.px] = RGB5(31,31,31) | BIT (15);
}
swiWaitForVBlank();
}
} |
#171410 - mukunda - Wed Nov 18, 2009 2:47 pm
Take note of the "| BIT(15)" part. framebuffer mode doesn't have this 'alpha' bit, which controls transparency in 16bit bitmap BG modes.
#171413 - MichaelMossman - Wed Nov 18, 2009 4:15 pm
Thank you, sverx.
Google has translated your text for me. The demo works fine. You're a star !
mukunda, your little postscript is much appreciated.
#171415 - sverx - Wed Nov 18, 2009 4:32 pm
| MichaelMossman wrote: |
| Google has translated your text for me. |
Can't believe it's possible to understand any sentence in that translation! Ok, my English IS bad, but that translation is a joke! :D
#171416 - MichaelMossman - Wed Nov 18, 2009 6:03 pm
Maybe not perfect, but good enough for me to get the general gist.
My basic questions have now been answered. Thank you very much.
Onwards and upwards, Mike