If the moving (background) image is bigger than the visible are why not using the hardware scrolling capabilities of GP32?? That would like take few CPU cycles to move 640x480 image around...
Is it possible to use these capabilities in pure C? or do we need to code it in assembler?
And what is the bigest image size you could scroll that way?
I must admit I'm very interested in these type of tricks but I don't want to have to learn ARM for the moment.
Sure it is possible in C.. there some 2 years old example C source in my site, which moves 640x480 16bits background using hw scrolling.. mummu.c something.
If I'm not mistaken the memcpy is directly written in asm, so it's obviously faster than any c routine. Your c code inside the loop can be reduced to one line, and it won't make the compiler use ldms, nor copy 32 bit chunks.
Again, I disagree, obviously faster is entirely dependant on the compiler and the asm it generates after optimisation. Codewarrior for example doesn't compile that function to use ldms, it generates the following:
>Using this method I get 7fps
>gp_drawPixel16(px+xx,py+yy, (u16)canvas->data[doff++], framebuffer);
Calling a putpixel function for each pixel, that definitelly draws down the speed..
Also, I don't know how fast memcpy is but someone could easilly do a nice and smooth blitting function if he took care of memory allocations.
I think also, the GP32 just crashed when I tried to read from a struct I made with unalligned ints and words. What happens with writes? I hope I am not loosing speed with writes in my current codes cause I don't have an idea of how the compiler handles my variables allignment (If I had still crashes, I would know for sure but possibly this doesn't happen with writes. I haven't checked..) . This sucks ;P
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.