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.

Graphics > problems!

#16744 - darknet - Tue Feb 24, 2004 7:10 am

I know this question has been asked numerous times across the forums, and I have read every answer that I believe is available so here goes:

I want a splash screen for my project. A background along with 2 sprites; 1 for 'Start new game' and the other for 'load new game'

I am in mode 4 and have initalized everything properly. However, no matter what I do I cannot get the sprites to be transparent over the background. Here is a checklist of things I have done:

-Checked the entry at the beginning of all the palettes were black, created a .pcx file with a black background + white text

-Have all the proper dimensions and bits set correctly for both the sprite and the background image.

-Started the sprite at 512 since mode 4 uses 0-511

Any help would be greatly, greatly appreciated. Below is a snipet of my code:

Code:

 setMode(OBJ_MAP_1D | MODE_4 | OBJ_ENABLE | BG2_ENABLE);
 
  //Load the sprites palette
 int loop = 0;
 for(loop = 0; loop<256; loop++) {
    SpritePal[loop] = startNewPalette[loop];

 }
 
 initalizeSprites();

 unsigned char attrs = 0; //0 is the first set of attrs
 
 sprites[attrs].attr0 = COLOR_256 | TALL | y;
 sprites[attrs].attr1 = SIZE_64 | x;;
 sprites[attrs].attr2 = 512;
 
 //now that its setup, copy the sprite data to char memory
 int x_loop = 0;
 
 //now copy in the sprites bitmap.
 for(x_loop = 8192; x_loop < 8320; x_loop++) {
   SpriteData[x_loop] = startNewData[x_loop-8192];
}

for(int n = 0; n<256; n++) {
    BGPaletteMem[n] = splash_Palette[n];
}

    memcpy(videoBuffer, splash_Bitmap, 38400);

while(1) {

    getInput();
    moveSprite(&sprites[0], x,y);
    waitVSync();
    updateSpriteMemory();
   
}
 
 return 0;
}

#16748 - sajiimori - Tue Feb 24, 2004 7:47 am

If the sprites appear at all, then your code is not the problem. When you open VBA's tile viewer and find your sprite tiles, you will see that your intended background pixels are not color 0 (though they may be black). You must fix your data so the background uses color 0.

#16750 - darknet - Tue Feb 24, 2004 8:15 am

First off thank you very much for the quick reply.

Its good to hear that my code is not the problem =)

However, I apologize for my ignorance, but how would I go about following your suggestion? I am using photoshop 7.0 to create my sprites + backgrounds, and I'm coverting the background with gfx2gba and the sprite with pcx2sprites (pcx2gba).

So in short, how would I go about with that fix?

Thanks again,
-Mike

#16758 - tepples - Tue Feb 24, 2004 4:20 pm

You need to use an image editor that can control which color ends up as color 0. Such image editors include at least GIMP and Graphics Gale. For example, in GIMP, color 0 is the color of the pixel in the upper-left corner when you convert an image to indexed mode.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#16763 - ScottLininger - Tue Feb 24, 2004 6:14 pm

Photoshop's palette manipulation is one of its few weak points, but the idea of learning GIMP or anything else if you're already comfortable in Photoshop is kind of a pain.

Here's the only way I have found to reliably get Photoshop to dump your "transparent" pixels out as palette entry 0:

1. Build your sprite in RGB with Photoshop transparency (not black!) where you want the sprite transparency. Make sure that your pixels are either 100% transparent or 100% solid.

2. Convert the sprite image to indexed color (IMAGE > MODE > INDEXED COLOR) with the following settings:

PALETTE: Local Adaptive
COLORS: 256 colors
FORCED: None
TRANSPARENCY: Checked
MATTE: None
DITHER: Whatever you want

3. Save as a .PCX and convert using your tools


Once you've done it to your first sprite, all subsequent sprites should be converted using IMAGE > MODE > INDEXED COLOR, with PALETTE set to "Previous," which will apply the palette Photoshop calculated from your first sprite. Of course, this means that your first sprite needs to contain a complete range of colors from ALL of your subsequent sprites.

I always build one large image that is a collage of all sprites to convert first. That way you get the best color range across all of them.

#16764 - johnny_north - Tue Feb 24, 2004 6:17 pm

I hope these instructions will help you (ps 6.0 but should work for ps 7.0)

Open your sprites in ps.
Both should be using indexed color.
Inspect the color table for both images.
Make sure that each sprite's palette has the same RGB value in the palette's 0 position (this can be RGB(0,0,0) but any color will work as long as all of your sprites are using the same color in palette position 0).
Quote:
For example, in GIMP, color 0 is the color of the pixel in the upper-left corner when you convert an image to indexed mode.


I believe this is what ps does as well, because it usually seems to pick the correct transparent color for your image.

Convert the sprite temporarily to an RGB image.
Convert the sprite back to an indexed color image.
A dialog box will open with color selection options.
In the dialog box, select to convert the image using the LOCAL ADAPTIVE option.
You may optionally reduce the number of colors in your final image here.
Under forced colors, select CUSTOM.
In the CUSTOM palette, set palette 0 to the RGB you want to be transparent in your sprite.
All of the rest of the entries should be blank (greyed out - no selected color).
Apply the changes to the CUSTOM palette.
Apply the conversion to your sprite.
Repeat for each sprite.

Now re-inspect the indexed palette, especially entry 0 for each sprite.
Each indexed colored sprite should have the same RGB color in palette entry 0.
If not repeat the above process.
Save the sprites as .bmp files. gfx2gba 1.13 will take both .pcx and .bmp, but I have experienced problems with .pcx files

Use gfx2gba 1.3 by markus (there are 2 different gfx2gba by different authors) to convert the sprites. Options in the readme, but here's a sample:

gfx2gba -fsrc -m -pbasepal.pal -t8 sprite1.bmp sprite2.bmp >>bgfxlog.txt

gfx2gba will optimize and collect all of your colors into a single basepal.

Note: If all of your sprites contain more that 256 unique colors, gfx2gba will fail.

I admit that some of these step may not be necessary, but following them all should help.

#16765 - ScottLininger - Tue Feb 24, 2004 6:22 pm

Oh, then there's the quick and dirty fix...

You can always open your header files and replace whatever color photoshop has dumped out with 00. You just need to find the palette entry number that photoshop chose.

So for example, if your image array looks like...

const u16 SpriteData[] = {
0x5353, 0x3453, 0xAAA0, 0x54AB, 0x654A, ...

And you know that your first pixel is supposed to be a transparent one, do a text search and replace for "0x53" and replace it with "0x00" then do a search and replace for "53," with "00,".

You need to do 2 search and replaces because each 16-bit number in the array is actually 2 pixels. Also, if your gfx2sprite tool dumps the palette into the same header file, be careful NOT to do the search across the palette array, or you may garble up some of your colors.

#16766 - johnny_north - Tue Feb 24, 2004 6:27 pm

Quote:
You can always open your header files and replace whatever color photoshop has dumped out with 00. You just need to find the palette entry number that photoshop chose.


Aye, gfx2gba seems to dump the wrong color 0 if you're converting with .pcx files, or not using the LOCAL ADAPTIVE option in conversion.

#16798 - darknet - Wed Feb 25, 2004 4:27 am

Thank you all for your words of wisdom but..

I have followed all of your instructions and still I am seeing a small black sprite on top of my background image.

-I have ran checks for the 0th position in the palette in 3 or 4 different graphics programs, still shows it being 0x0000, but black still shows up in my image,

I have tried using different background images, and that did not work either. The same goes for creating new sprites in every which way

I have ran this on two emulators (VBA / Boycott) and hardware, and the same thing results each time.

The only thing I can think of now is that it may be a problem with my loop through the palette? Here's my sprite loading code again...
Code:

int main() {

 setMode(OBJ_MAP_1D | MODE_4 | OBJ_ENABLE | BG2_ENABLE);
 
  //Load the sprites palette
 int loop = 0;
 for(loop = 0; loop<256; loop++) {
    SpritePal[loop] = loadPalette[loop];
 }
 
 initalizeSprites();

 unsigned char attrs = 0;
 
 unsigned short char_number = 512;
 
 sprites[attrs].attr0 = COLOR_256 | SQUARE | y;
 sprites[attrs].attr1 = SIZE_64 | x;;
 sprites[attrs].attr2 = char_number;
 
 int x_loop = 0;
 
 for(x_loop = 8192; x_loop < 8320; x_loop++) {
   SpriteData[x_loop] = loadData[x_loop-8192];
}

for(int n = 0; n<256; n++) {
    BGPaletteMem[n] = splash_Palette[n];
}
 memcpy(videoBuffer, splash_Bitmap, 38400);

while(1) {

    getInput();
    moveSprite(&sprites[0], x,y);
    waitVSync();
    updateSpriteMemory();
   
}
 
 return 0;
}

#16799 - tepples - Wed Feb 25, 2004 4:47 am

Run your program in VisualBoyAdvance and use its tools:
  1. Palette Viewer, to make sure the palette gets loaded
  2. Tile Viewer, to make sure the sprite cels get loaded at the locations where you expect
  3. OAM Viewer, to make sure the right sprite cel gets placed with the right palette at the right location

_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#16804 - darknet - Wed Feb 25, 2004 5:13 am

Thanks very much for the quick reply, here's the results of your inqueries.

1. In the palatte Viewer, the proper palette is being loaded!

2. In the OAM Viewer, the correct positon of the sprite is showing up, however all that comes up in the palette is black, hence why its all black.

3. In looking at the tile viewer, I assume that my sprite should be loading up in VRAM at location 0x600200 (since I am in mode 4 and its starting at position 512 which is +200 away in VRAM in hex correct?), and once again, it is not. Instead, the background is being painted at that location.

So I do see the errors and why its coming up the way it is. However, the palette is loaded, that much is certain. How would I go about figuring out why everything else is not loading properly in the right places?

Any response is appreciated-Thanks a lot,
-Mike

#16809 - zerosynapse - Wed Feb 25, 2004 10:17 am

Why not simply use a package such as DPaint or its Windows "updated" equivalent such as Promotion? This will give you 256 colour images to work with and obviously full control of the palette.

Zer0 - Industry Artist
_________________
GALLERY Section here - www.putang.co.uk

#16825 - johnny_north - Wed Feb 25, 2004 4:47 pm

Alright Mike, I'll give it one more shot:

Please post the following:

A small section of one of your sprite's source - starting from the first line including the delaration and definition of the array.

The address of SpritePal.

Hopfully we'll be able to rule out a couple of things, because your last post is somewhat ambiguous in that:

The palette viewer contains 2 palettes, and you did not specify which palette the colors were being loaded into. We're all assuming it's the sprite but, hey you can't take certain things for granted in a debug situation.

You refer to the palette in the OAM viewer, but of course you're only getting palette info indirectly by looking at the colors of the tiles.

"Instead, the background is being painted at that location." Assume you mean that a background tile (bitmap) data exists at the address of your first sprite tile. We're missing some info somewhere.

#16922 - darknet - Fri Feb 27, 2004 3:36 am

Thanks so very much johnny_north for all your help on this issue...Here are all the specifics I left out before:

The important sprite defines:

Code:

#define SpriteMem ((unsigned short*)0x7000000) //OAM state address
#define SpriteData ((unsigned short*)0x6010000) //OAM image address
#define SpritePal ((unsigned short*)0x5000200) //OAM palette address


Here's a snippet of my header file:


Code:

const unsigned short loadData[] = {
                    0xFDFD, 0xFDFD, 0xFDFD, 0xFDFD, 0xFDFD, 0xFDFD, 0xFDFD, 0xFDFD, 0xFDFD, 0xFDFD,
                    0xFDFD, 0xFDFD, 0xFDFD, 0xFDFD, 0xFDFD, 0xFDFD, 0xFDFD, 0xFDFD, 0xFDFD, 0xFDFD,
                    0xFDFD, 0xFDFD, 0xFDFD, 0xFDFD, 0xFDFD, 0xFDFD, 0xFDFD, 0xFDFD, 0xFDFD, 0xFDFD,
                    0xFDFD, 0xFDFD, 0xFDFD, 0xFDFD, 0xFDFD, 0xFDFD,
                                              .
                                              .
                                              .
const unsigned short loadPalette[] = {
                    0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
                    0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
                    0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
                    0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
                    0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
                                           .
                                           .
                                           .
                    0x0000, 0x0000, 0x0000, 0x0000, 0x13E0, 0x0000,};


The actual picture that is supposed to display is the word 'Load' in green text over the black background that I am trying to make transparent.

And to answer your question, in VBA's palette viewer the background image is being properly loaded in the background palette and the sprite is being properly loaded in the sprite palette. The problems aforementioned before still apply though ( the OAM viewer shows the right position information for the sprite but only displays all black in the palette).

The only thing I can at this point think of is that my loop through the palette or OAM is messed up. However, my code is a direct translation from the Pern Project with my custom images being the only real difference. i even use his pcx2gba tool!

In any case, with the code displayed below I hope i have gathered together enough information for a diagnosis.

Thanks again to anyone reading this post and even thinking about a response =)

-Mike

#16924 - poslundc - Fri Feb 27, 2004 4:48 am

Your data for the sprite seems to be using colour #253 of your palette (0xFD). It is unclear whether entry #253 of your palette is green or not (since you didn't include the whole palette, we can't tell), but it looks like it might actually be entry #254 that is green, and NOT entry #253 - depending on how your conversion program outputs its palettes.

(This would be consistent with you having the correct OAM values and the correct palette, but apparent blackness in the tile data.)

To correct it, you can change the entry in the palette before the occurrence of 0x13F0 so that it is also 0x13F0.

I could be wrong; it is impossible to know for sure.

Dan.

#16936 - ScottLininger - Fri Feb 27, 2004 5:24 pm

I still think it's a problem with your conversion tool outputting the wrong palette entry for the transparent pixels. Each element of your loadData array describes two pixels with a palette entry between 0 and 255.

Palette entry #0 is transparent regardless of the actual color that is stored in loadPalette[0]. Every other palette entry will display as a solid color, even if that color is Ox0000 (black).

Like poslundc pointed out, all of those 0xFDFD entries are referencing palette #253, which is black in your palette.
Code:

const unsigned short loadPalette[] = {
                    0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
                    0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
                    0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
                    0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
                    0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
                                           .
                                           .
                                           .
                    0x0000, 0x0000, 0x0000, 0x0000, 0x13E0, 0x0000,};


counting backwards from the end of your array...

255 (last entry) contains 0x0000 (black)
254 contains 0x13E0 (green)
253 contains black

All of those 'FD' entries (hexadecimal for 253) in your loadData are telling the GBA to display color #253. Which is black. Only #0 will be transparent.

What you want to see is...

Code:

const unsigned short loadData[] = {
                    0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, etc


See the examples above for how to fix it.

Cheers,

Scott

#16945 - johnny_north - Fri Feb 27, 2004 8:06 pm

I agree with both Scott and Dan. The conversion tool you're using is suspect (this might also result from the bitmap being the wrong depth). Also, I think that if your conversion tool actually created the part of the loadData[] you posted:

Quote:
0x0000, 0x0000, 0x0000, 0x0000, 0x13E0, 0x0000,};


Then there is definitely a problems because of the trailing comma within the curly braces - although this my be your own edit.

If you decide to use gfx2gba by marcus, I would be able to walk you through the command line options to get exactly what you want.

#16983 - darknet - Sat Feb 28, 2004 6:33 am

Thanks again everyone for your time...

The conversion program I was using was PCX2GBA. It seems pretty popular around these parts but since I have tried marcus' gfx2gba...heres the results:

The good news: I finally got the graphic to show up transparent!!!! YES!!

The bad news: now the image comes out rather mangled looking.

To ENSURE it was not my code that was the problem, I took someone elses graphic array and plugged it in to my project and it worked fine. So the problem DOES LIE in me actually converting the graphic files or actually creating the graphic files.

Here's the command I use for gfx2gba with my image being a 32x16 bitmap still w/black as the transparency (which is ok now..)

gfx2gba -D -fsrc -pstart.pal -t8 start.bmp

Here's a small snippet of what it outputs...


Code:

const unsigned char start_Bitmap[512] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x00, 0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x00,
0x00, 0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00,
0x01, 0x01, 0x01, 0x01, 0x00, 0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x00, 0x00, 0x01, 0x01,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x01, 0x01, 0x00, 0x00, 0x00, 0x01, 0x01, 0x00, 0x00, 0x01, 0x01, 0x00, 0x00, 0x01, 0x01, 0x01,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x01, 0x00, 0x00, 0x00,
0x01, 0x00, 0x01, 0x01, 0x01, 0x01, 0x00, 0x00, 0x01, 0x00, 0x01, 0x01, 0x01, 0x01, 0x00, 0x00,
0x00, 0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x01, 0x00,
0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x00, 0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x01, 0x00, 0x00, 0x00, 0x01, 0x01,
0x00, 0x01, 0x01, 0x01, 0x00, 0x00, 0x01, 0x01, 0x00, 0x01, 0x01, 0x01, 0x00, 0x00, 0x01, 0x01,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x01, 0x01, 0x01, 0x00, 0x00, 0x01, 0x01, 0x00, 0x00, 0x01, 0x01, 0x00, 0x00, 0x01, 0x01, 0x00,
0x00, 0x01, 0x01, 0x00, 0x00, 0x01, 0x01, 0x00, 0x01, 0x01, 0x01, 0x00, 0x00, 0x01, 0x01, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x01, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x01, 0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x01, 0x01, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
};

const unsigned short start_Palette[256] = {
0x0000, 0x001f, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000
};
//note the rest of the palette is 0x0000


The image is a black background with 'start' typed in RED. The output turns out to be a vertical red block of nothing....

Is the command I am using the proper one for gfx2gba?

Thanks again for all of your time,
-Mike

#16984 - yaustar - Sat Feb 28, 2004 9:00 am

This was from your last code snippet where you forgot to delcare it WIDE although this was in your first post in this thread
Code:
sprites[attrs].attr0 = COLOR_256 | SQUARE | y;
 sprites[attrs].attr1 = SIZE_64 | x;;
 sprites[attrs].attr2 = char_number;
to
Code:
sprites[attrs].attr0 = COLOR_256 | SQUARE | y | WIDE;
 sprites[attrs].attr1 = SIZE_64 | x;;
 sprites[attrs].attr2 = char_number;

_________________
[Blog] [Portfolio]

#16985 - josath - Sat Feb 28, 2004 10:11 am

Woah there, I don't think you want square and wide at the same time!

try this for attribute 0:
Code:
sprites[attrs].attr0 = COLOR_256 | WIDE | y;

#16986 - darknet - Sat Feb 28, 2004 10:41 am

All the attribuite stuff is just fine. I plugged in other people's graphics into my project and they worked. I however, for my project need to be able to create and convert properly. From what i see (and what this thread discusses), I am not doing anything wrong..

Any suggestions would be great.

-Mike

#16994 - yaustar - Sat Feb 28, 2004 2:31 pm

Is this what your sprite looks like at the moment?
http://madsims.net/~yaustarc/misc/gbaev.gif

If it is then the data for the sprites has gone wrong.
_________________
[Blog] [Portfolio]

#17016 - darknet - Sat Feb 28, 2004 11:21 pm

...except that its transparent, but the mangled image is EXACTLY what is happening.

The natural question is then, how is the data becoming corrupted and how to fix it? Both of the popular tools (gfx2gba + pcx2gba-but the latter has that black background attached as well) have been giving me these results.

Funny thing though--just for kicks I wrote a small amount of HAM lib code to display the sprite and it displays fine.....??!? I checked all of the parameters and made sure they matched up with my code...which they do.

But thats a side note I suppose. Thanks a lot for the reply, any further detail would be greatly appreciated.

-Mike

#17020 - dagamer34 - Sun Feb 29, 2004 12:19 am

Just so you know, I was only able to get pcx2gba working when I used Paint Shop Pro 8. I think it also works with Adobe PhotoShop 7.0 and the GIMP. Try one of those if you aren't using them already.
_________________
Little kids and Playstation 2's don't mix. :(

#17031 - darknet - Sun Feb 29, 2004 8:50 am

nothing. The sprites still come out mangled EXACTLY the way yaustar shows they do. The data is going wrong

Regardless of the graphics program I use (i've used em' all), that is what happens.

I thank everyone again for my continual questioning on this subject, but If i can't draw sprites, then I will not have a game, so this is important to me.

Any help on yaustar's comment or anything else anyone has experienced on this matter is greatly appreciated.

Thanks in advance,
-Mike

#17033 - tepples - Sun Feb 29, 2004 8:59 am

Have you tried using a direct tile data editor such as this one? Have you tried manually coding sprite data and then, from what you learned, writing your own converter?

Looks like you could be using your converter in "linear" mode when you should be using it in "tile" mode.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#17048 - yaustar - Sun Feb 29, 2004 2:19 pm

Can you email the actual image file you are using?

yaustar_8p@NOSPAMyahoo.co.uk - remove no spam (PS try lowering the colour palette to 8bit (256 colours)
_________________
[Blog] [Portfolio]

#17099 - darknet - Mon Mar 01, 2004 2:22 am

I sent over the image...and a correction to the text in the e-mail's body --i meant vertical and not horizontal..

Thanks,
-Mike

#17101 - yaustar - Mon Mar 01, 2004 3:35 am

I notice it is a 32x8 sprite. Gba cannot do this size. resize the image to 32x16 and write
Code:
sprites[attrs].attr0 = COLOR_256 | WIDE | y;
 sprites[attrs].attr1 = SIZE_32 | x;
 sprites[attrs].attr2 = char_number;
//32x16 I think

_________________
[Blog] [Portfolio]

#17105 - tepples - Mon Mar 01, 2004 5:01 am

GBA sprite hardware can handle a 32x8 pixel sprite (wide, size 1). It just can't handle 64x8, 64x16, 8x64, or 16x64 without splitting the sprite into two or more.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#17108 - darknet - Mon Mar 01, 2004 9:37 am

After working forever and taking all of your comments into heavy consideration, I finally got proper transparent sprites!

Long story short, I create a photoshop a certain way and then make sure that palette index 0 is black in paint shop pro. Any attempt and doing something else for me seems to fail, so thats the method i will be using =)

Thanks very much everyone, you all helped me quite a bit.

-Mike

#17110 - yaustar - Mon Mar 01, 2004 1:38 pm

tepples wrote:
GBA sprite hardware can handle a 32x8 pixel sprite (wide, size 1). It just can't handle 64x8, 64x16, 8x64, or 16x64 without splitting the sprite into two or more.


*Reading Cowbite Spec again*
oh ****. So it does.... :(
_________________
[Blog] [Portfolio]