GP32 Colors Colors Colors

[Akuma no Houkon]

Using 8bpp is a pain. I am no artist and I have serious trouble trying to juggle an entire games worth of images into a single palette. Its not feasable, so the only option is to create a separate palette for each "graphic set" maintaining the commonly used colors (for cursors, etc..) in each set. Now, each set needs to include the colors for all sprites that can possibly exist in that area, the common system colors, the colors for extras like "faces" (which take _alot_ of colors) and lastly the colors for the actual areas graphics.

Thats _alot_ of graphics to fit into 256 color and you end up making lower quality images because you need the palette room. How do you manage that? How can you have a decent sized game with decent graphics and juggle palettes like that? Is there some magic trick to it that I havent learned?

I tried looking into the GpSetMode function to see about setting it to 16bpp (to solve all my problems) but, as always, the documents are in korean. I try to issue the commad at the begining of my initalization function, and I get my normal screen, squished and drawn 4 times like tiles. Not to mention it makes my existing palettes go awry and just...not work right.

Does anyone know how to setup 16bpp? What changes do I need to make to my images and palettes. How do I stop it from tweeking my screen? Will it have a significant impact on performace using 16bpp?

Gah too many questions not enough answers

 

[VirtuaLeech]

There is no other way to work in 8bpp then to "juggle" all the colors the way you describe. When you want to use 16bpp you also have to link in the 16bit libs.

This is the info I collected from various posts when I started 16bit. Hope it helps. Else search the board for "16 bit graphics"

Bits taken from gp32x.de concerning the GP32 16bits mode with GCCadvance

from what i remember...
edit C:\devkitadv\gp32.mk (this is for Rico's devkitadvance!)
where its says:
GPLIBS=-lgpsdk -lgpgraphic -lgpmem -lgpos -lgpstdlib -lgpstdio -lgpsound -lgpfont -lgpg_ex01
add -lgpgraphic16 and -lgpfont16 to the list
then extract the .a to:
C:\devkitadv\arm-agb-elf\lib
and yes, extract the .h and .c to:
C:\devkitadv\arm-agb-elf\include\gp32
the last bit if i remember correctly, you have to 'make' the MakeFile:
C:\devkitadv\arm-agb-elf\lib\gpsdk\MakeFile

basically you need to do a batch file, or type in a cmd line something like this:
C:\devkitadv\bin\make C:\devkitadv\arm-agb-elf\lib\gpsdk\Make
this should make 'C:\devkitadv\arm-agb-elf\lib\gpsdk\gpstart\gpstart.c'
which has the line 'GpFontInit16 (&mInfo);' which i think is important for getting 16bit fonts working!

to re-make all the gcc gamepark libs just make sure you are in the 'C:\devkitadv\arm-agb-elf\lib\gpsdk\'
folder and then run 'C:\devkitadv\bin\make'

actually, for me I had to edit the makefile a bit. inside the makefile, i had to add the following line
to the very top:
export CCBASE=c:/devkitadv
then I was able to make from the directory itself. Hopefully that helps.
Edit:
Actually, what Feeblez said is better. But the make file in the gpsdk folder needs to be edited a little.
Everywhere it says 'make', change it to $(MAKE)
hope that helps.

did u add to your gplib directory : libgpfont16.a ?
Did you try : GpTextOut16(NULL, &gpDraw[0], 10, 10, (char*)"some test text...", 0);
the gpfont16.h must be with all the other gp include file.
Have you modify your makefile to compile the libgpfont16.a ?
like this :
LDBASEFLAGS = -Tlnkscript -lgpfont -lgpfont16 -lm -lgpstdlib -lgpos -lgpgraphic -lgpgraphic16 -lgpstdio -lgpsound -lgpmem

yep... done all that...
libgpfont16 is installed.
gpfont16.h is in the same dir as gpgraphic16 (which i can use no probs).
Yep, my libgpfont16 is in my gp32.mk file.

and what about your makefile ?
You added the lgpfont16 ?

C:\devkitadv\bin\make C:\devkitadv\arm-agb-elf\lib\gpsdk\MakeFile
should remake everything that's new from the 16bit zip
you should overwrite C:\devkitadv\arm-agb-elf\lib\gpsdk\gpstart\gpstart.c with the new one that has the line:
GpFontInit16 (&mInfo);

to re-make all the gcc gamepark libs just make sure you are in the
'C:\devkitadv\arm-agb-elf\lib\gpsdk\' folder and then run 'C:\devkitadv\bin\make'

 

[Arnout]

In my opinion 256 colors should always be enough to create games for limited screen sizes like on the GP32.

If you use some painting tool like PaintShop Pro then it's quite easy to let the tool create a 256 color pallete for you.

You can do this by placing all needed graphics in a big picture in 24bits mode.
Then reduce the number of colors to 256 and use the same palette for all graphics.

If you have multiple levels like in Giana's Return you can have a palette per level.

 

[RobertJ]

I would just use 16bit if you need the colours. The only thing that should impact performance in this mode is colour swapping routines (where obviously with 8bit you can just change the colour table), and memory usage is clearly going to be twice as much for storing images in memory and on the SMC.

The ARM cpu is 32bit, it should be just as quick to shift around 16bits or even 32bits of data, as 8bits.

 

[Daz_Genetic]

If you really want to use an 8bit display, you really don't need to create your own 8bit palette. The default GP32 palette is designed to be used as a color look up table. The first 3 bits represent the Red channel, the next 3bits represent the Green channel, and the Last 2 bits represent the Blue.

| 111 | 111 | 11 | <- 8bit number
| red | green | blue |

You can convert a 24bit color into an 8bit palette entry with a simple macro.

#define GP_RGB8(r,g,b) ((((r>>5)&0x07)<<5)|(((g>>5)&0x07)<<2)|(((b>>6)&0x03)<<0))

Just call it like this. Using 8bit per channel values.

unsigned char color = GP_RGB8(255,128,64);

This will result in an index into your palette, which will be a close approximation to the the color you are looking for.

This means that you can work with 24bit colors behind the scenes, and only convert them to 8bit when the time comes to blit them. Or you could do this stage at the loading step if you have no need to change the colors during play or want to save some memory in yout surfaces.

 

[MojoJojo]

I would just use 16bit if you need the colours. The only thing that should impact performance in this mode is colour swapping routines (where obviously with 8bit you can just change the colour table), and memory usage is clearly going to be twice as much for storing images in memory and on the SMC.

The ARM cpu is 32bit, it should be just as quick to shift around 16bits or even 32bits of data, as 8bits.

I was going to say that the writeback buffer would join two 8bit writes into one 16bit write... but the writeback is disabled on the framebuffers.

However, a 32bit write is definately slower than an 8 or 16 bit write. While the ARM is 32bit, the data bus is only 16 bits wide, so it takes TWO cycles to write a 32 bit value to memory. Of course, the writeback complicates this sort of thing no end, in areas where it is turned on.