gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > shifting al pixels to the left in framebuffer mode

#155072 - TheMagnitude - Thu Apr 24, 2008 7:16 pm

Below shows my shiftpixels function which doesnt seem to work. In the function it copies the buffer into copy, then it puts copy (x+shift) back into the buffer. But i get wierd results, and i think its to do with the dmaCopy part.
Code:
void shiftHorPixels(int s, uint16* buffer)
{
   uint16 copy[256*192];
   dmaCopy(buffer,copy,256*192*sizeof(uint16));
   if (s>=0)
      for (int y = 0; y < 192; y ++)
         for (int x = s; x < 256; x ++)
            *(buffer + (y << 8) + x) = copy[(y << 8) + x - s];
}

#155075 - Maxxie - Thu Apr 24, 2008 7:46 pm

- You are pushing a 98kB block onto the stack which should be bigger then the memory region used for the stack (16k if it's in the dtcm)
- DMA can not access the dtcm

#155076 - Lazy1 - Thu Apr 24, 2008 7:53 pm

Why not use a bitmap mode and use the hardware to scroll pixels?

#155077 - DiscoStew - Thu Apr 24, 2008 7:59 pm

Just like Maxxie said, the DMA hardware can't transfer in this manner, and that is quite a big block you are copying. You'd have to make an array in Main RAM for this to work.

In addition, from what I see you trying to do, you're going the opposite way with shifting pixels, because you are starting *s* number of pixels to the right from the left-most pixel, and then copying from that left-most, and placing it into the ones at the right. This can lead to repeating pixels. This can be fixed simply by changing that last line to this...

Code:
*(buffer + (y << 8) + x - s) = copy[(y << 8) + x]

_________________
DS - It's all about DiscoStew

#155079 - TheMagnitude - Thu Apr 24, 2008 8:10 pm

Ah, sorry Im new to DS programming so I dont know what dtcm or bitmap mode is :(

I also dont know how to place a array in the main ram, do i just do this?:

Code:
uint16 array[256*192];

#155080 - silent_code - Thu Apr 24, 2008 8:11 pm

if you mean to put that outside any function, yes, that's a way you can go. :^)

i'm not quite sure (about the heap), but i think static variables get allocated in the heap (i *am* sure not the stack), so that may be a solution to your problem as well. :^)

btw: allocation on the heap is also used with malloc/new. ;^)

#155100 - TheMagnitude - Fri Apr 25, 2008 12:28 am

Thanks for everyones help, ive managed to sort it out :)

#155102 - Maxxie - Fri Apr 25, 2008 12:39 am

silent_code wrote:

i'm not quite sure (about the heap), but i think static variables get allocated in the heap (i *am* sure not the stack), so that may be a solution to your problem as well. :^)


Named data objects defined outside functions are created in .rodata or .data except explicity told otherwise (like .dtcm)
Named data objects defined inside functions are created on the stack
Anonymous data objects (created via malloc/new) are taken from the heap

#155103 - Dwedit - Fri Apr 25, 2008 12:50 am

Couldn't you use memmove?
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

#155109 - silent_code - Fri Apr 25, 2008 2:13 am

@ Maxxie: could you phrase this a bit "beginner friendly"?

#155111 - tepples - Fri Apr 25, 2008 2:36 am

The object 'copy' is on the stack because you defined it inside a function.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#155136 - silent_code - Fri Apr 25, 2008 12:34 pm

gnu says:
Quote:
The C language supports two kinds of memory allocation through the variables in C programs:

* Static allocation is what happens when you declare a static or global variable. Each static or global variable defines one block of space, of a fixed size. The space is allocated once, when your program is started (part of the exec operation), and is never freed.


so? also my reference tells me that static function variables don't get allocated on the stack. doesn't make sense to me and in asm, i'd put such a variable into .data or, if possible, make it "lokal". (ok, it's been a while since last time i asm'ed.)... but i'm always willing to learn (and obviously too lazy to just check out how gcc generates asm for static function variables). :^D

also, there seems to be a difference between initialized (.data) and uninitialized (.data?) statics (the first get allocated and initialized on program startup, iirc), although i haven't used statics in asm, yet, and just googled that out of curiosity.


Last edited by silent_code on Fri Apr 25, 2008 1:22 pm; edited 1 time in total

#155141 - tepples - Fri Apr 25, 2008 1:15 pm

silent_code wrote:
also my reference tells me that static function variables doesn't get allocated on the stack.

True, but this variable isn't marked static. If the program doesn't specify a storage class for a variable defined in the scope of a function, the compiler assumes auto.

Quote:
also, there seems to be a difference between initialized (.data) and uninitialized (.data?) statics (the first get allocated and initialized on program startup, iirc)

At file scope, devkitARM puts uninitialized variables with static allocation in .bss. I haven't tried the same with such variables at function scope.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#155142 - silent_code - Fri Apr 25, 2008 1:20 pm

thanks.