Need some more help with some graphics code

Discuss the development of new homebrew software, tools and libraries.

Moderators: cheriff, TyRaNiD

Post Reply
jason867
Posts: 78
Joined: Sun Jul 24, 2005 1:58 am
Contact:

Need some more help with some graphics code

Post by jason867 »

First off, here is my code for setting up the video mode and what not.

Code: Select all

void InitializeGraphics(int mode)
{
    sceDisplayGetFrameBuf((void**)&VRAM32, &BUF_WIDTH, &PIXEL_FORMAT, &UNKNOWN);
    VRAM16 = (u16*) VRAM32;
    sceDisplaySetMode(mode,SCR_WIDTH,SCR_HEIGHT); // Sets the display mode.
    if(mode==PSP_DISPLAY_PIXEL_FORMAT_8888)
    {
      sceDisplaySetFrameBuf(VRAM32,BUF_WIDTH,mode,PSP_DISPLAY_SETBUF_NEXTFRAME); // Sets the address of the frame buffer.
    }
    else
    {
      sceDisplaySetFrameBuf(VRAM16,BUF_WIDTH,mode,PSP_DISPLAY_SETBUF_NEXTFRAME); // Sets the address of the frame buffer.
    }
    sceDisplayGetFrameBuf((void**)&VRAM32, &BUF_WIDTH, &PIXEL_FORMAT, &UNKNOWN);
}
Is there anything wrong about this piece of code? Or anything that needs to be changed? I barely have the faintest clue about what I'm doing here.

Here is my code for plotting 5551 format pixels

Code: Select all

int color=&#40;&#40;b>>3&#41;<<10&#41; | &#40;&#40;g>>3&#41;<<5&#41; | &#40;r>>3&#41; | 0x8000; // Creates and stores color.
    u16 *address=VRAM+&#40;&#40;&#40;&#40;512&#41;*PIXEL_SIZE&#41;*y&#41;+x&#41;; // Caculates address of pixel.
    *address=color; // Writes color code into address of the pixel.
I know for a fact this works (I however have not used it in conjunction with the video mode code noted above.)

What I would like to know is, how do I translate this over to the different video modes? Most importantly, to the 32bit 8888 video mode.

I looked at the screenshot code shine put on here earlier, and worked off that, but I didn't get anything going.

Also, in 5551 pixel format mode, the rgb color values range from 0-255, what is the range in 8888 pixel format mode?

Thanks for everyone's help.
Ask not for whom the bell tolls, it tolls for thee, besides, I'm playing my PSP, tee hee!
------------------------------------------------------
Visit my website for my PSP Homebrew!
LuMo
Posts: 410
Joined: Sun Aug 21, 2005 2:45 am
Location: Austria
Contact:

Re: Need some more help with some graphics code

Post by LuMo »

jason867 wrote:Also, in 5551 pixel format mode, the rgb color values range from 0-255, what is the range in 8888 pixel format mode?
the color values in 1555 images are not 0..255 its 0x1F (32 steps)

greets
lumo
"Good artists copy, great artists steal."
Pablo Picasso
go2lumo.com
Ryu
Posts: 19
Joined: Mon Oct 17, 2005 8:36 pm

Post by Ryu »

the range is always 0 => (2^n)-1

so

1 : 0 => 1
5 : 0 => 31
8 : 0 => 255
jason867
Posts: 78
Joined: Sun Jul 24, 2005 1:58 am
Contact:

Post by jason867 »

Someone else (from here) told me that it was 255 in 5551 mode, and it's been working fine all along...
Ask not for whom the bell tolls, it tolls for thee, besides, I'm playing my PSP, tee hee!
------------------------------------------------------
Visit my website for my PSP Homebrew!
jason867
Posts: 78
Joined: Sun Jul 24, 2005 1:58 am
Contact:

Post by jason867 »

so does anyone know what exactly is wrong with the code above?
Ask not for whom the bell tolls, it tolls for thee, besides, I'm playing my PSP, tee hee!
------------------------------------------------------
Visit my website for my PSP Homebrew!
Ryu
Posts: 19
Joined: Mon Oct 17, 2005 8:36 pm

Post by Ryu »

jason867 wrote:Someone else (from here) told me that it was 255 in 5551 mode, and it's been working fine all along...
that's wrong, even your code proves it:

int color=((b>>3)<<10) | ((g>>3)<<5) | (r>>3) | 0x8000; // Creates and stores color.
u16 *address=VRAM+((((512)*PIXEL_SIZE)*y)+x); // Caculates address of pixel.
*address=color; // Writes color code into address of the pixel.

see the b>>3, g>>3 and r>>3? that means b/8, g/8, r/8, so it means the r,g,b that you enter can go from 0 to 255 but they're divided by 8, meaning they actually go from 0 to 31.
jason867
Posts: 78
Joined: Sun Jul 24, 2005 1:58 am
Contact:

Post by jason867 »

Ok, I understand that. What's the use of dividing rgb by 8 in that code? Why not leave that out and only use values from 0-31? Can someone explain why it was decided to have it divide by 8 and use 255 values?
Ask not for whom the bell tolls, it tolls for thee, besides, I'm playing my PSP, tee hee!
------------------------------------------------------
Visit my website for my PSP Homebrew!
Ryu
Posts: 19
Joined: Mon Oct 17, 2005 8:36 pm

Post by Ryu »

jason867 wrote:Ok, I understand that. What's the use of dividing rgb by 8 in that code? Why not leave that out and only use values from 0-31? Can someone explain why it was decided to have it divide by 8 and use 255 values?
it's because 0-255 is used in the 32bit format 8888 and is widely used, at least if you want to use 8888 you won't have to change the color values everywhere in your code, it's just for convenience then...
jason867
Posts: 78
Joined: Sun Jul 24, 2005 1:58 am
Contact:

Post by jason867 »

ok, cool

so, how exactly do I change the bit shifting to for use in 8888? Also, does the starting address of vram change any? I just can't double buffer in 8888 right?
Ask not for whom the bell tolls, it tolls for thee, besides, I'm playing my PSP, tee hee!
------------------------------------------------------
Visit my website for my PSP Homebrew!
Paco
Posts: 54
Joined: Sun Oct 09, 2005 6:53 pm

Post by Paco »

Yes you can double buffer fine in 8888. The PSP keeps a "visible" framebuffer, but you can change the address to a different address in VideoRAM after you're done drawing your stuff there. Check the samples to see how they do it.
Paco
jason867
Posts: 78
Joined: Sun Jul 24, 2005 1:58 am
Contact:

Post by jason867 »

so can anyone explain to me the bit shifting I would need to do in 8888 mode?
Ask not for whom the bell tolls, it tolls for thee, besides, I'm playing my PSP, tee hee!
------------------------------------------------------
Visit my website for my PSP Homebrew!
jason867
Posts: 78
Joined: Sun Jul 24, 2005 1:58 am
Contact:

Post by jason867 »

don't everybody reply at the same time now...
Ask not for whom the bell tolls, it tolls for thee, besides, I'm playing my PSP, tee hee!
------------------------------------------------------
Visit my website for my PSP Homebrew!
Arwin
Posts: 426
Joined: Tue Jul 12, 2005 7:00 pm

Post by Arwin »

jason867 wrote:don't everybody reply at the same time now...
I never did anything myself with this, but just from reading this thread I gather that when people tell you this:

see the b>>3, g>>3 and r>>3? that means b/8, g/8, r/8, so it means the r,g,b that you enter can go from 0 to 255 but they're divided by 8, meaning they actually go from 0 to 31.

you should be able to figure out that if you leave out the >>3 part, you keep values that are suitable for 8888 mode.
sandberg
Posts: 90
Joined: Wed Oct 05, 2005 1:25 am
Location: Denmark

Post by sandberg »

In 8888 mode you don't have to shift anything. Each color value (R,GB) has each own byte, and then 1 for the alpha channel. So a single pixel in 8888 mode is 32 bit wide.


Remove the shifting of the individual components. You only have to shift them into the right place for the 32 bit value. And change your pointer to VRAM to a 32 bit pointer. That should do it. If you don't need the alpha component, just set it to zero.

Modified from your own code :

Code: Select all

u32 color=&#40;&#40;a&#41; << 24&#41; | &#40;&#40;b&#41;<<16&#41; | &#40;&#40;g&#41;<<8&#41; | &#40;r&#41; ; // Creates and stores color.
    u32 *address=VRAM+&#40;&#40;&#40;&#40;512&#41;*PIXEL_SIZE&#41;*y&#41;+x&#41;; // Caculates address of pixel.
    *address=color; // Writes color code into address of the pixel.
The above asumes that VRAM is also a 32 bit pointer, otherwise add a typecast.
Br, Sandberg
Post Reply