Trying to make a Dreamcast Mappy playback library

[BB Hood]

I know there already exists a dreamcast port of SDLMappy by Will Sams (http://www.storm-studios.net/DCsamples.aspx) but I took on this little project because I hear SDL isn't all that great for dreamcast and I wanted experience dealing with the PVR and graphic data. I've gone as far as I can by myself and now I need help.

The problem I have is dealing with the graphic data. I haven't converted all the drawing functions (MapDrawBG, MapDrawBGT, MapDrawFG, etc) but I created a little function to draw one graphic block(tile) to see if I am decoding the raw graphics data in the mappy file (test.fmp) correctly. Here is my graphics decoding function:

Code: Select all

int DCMappy::MapDecodeBGFX (void) {
    int           i;
    char        *rawimagedata = NULL; // The raw graphics in whatever format the map is in [8bit;16bit]
    pvr_ptr_t  mapblockgfxpt = NULL; 
    
    // Allocated raw image data memory(one block at a time) depending on the mapdepth[8:1, 16:2] 
    if(mapdepth == 8) {
        rawimagedata = (char *)malloc(mapblockwidth*mapblockheight);
    } else if(mapdepth == 16) {
        rawimagedata = (char *)malloc(mapblockwidth*mapblockheight*2);
    }  
    if (rawimagedata == NULL) { maperror = MER_OUTOFMEM; return -1; }
    
    // One block at a time filling up maplpDDSTiles
    for(i = 0; i < mapnumblockgfx; i++) {
        
         // Allocated PVR Memory(one block at a time) depending on the mapdepth 
        if(mapdepth == 8) {
            fread(rawimagedata, mapblockwidth*mapblockheight, 1, mapfilept);        
            mapblockgfxpt = pvr_mem_malloc(mapblockwidth*mapblockheight);
            if(mapblockgfxpt==NULL) { maperror = MER_OUTOFMEM; return -1; }
            pvr_txr_load_ex((void *)rawimagedata, mapblockgfxpt, mapblockwidth, mapblockheight, PVR_TXRLOAD_8BPP);
        } else if(mapdepth == 16) {
            fread(rawimagedata, mapblockwidth*mapblockheight*2, 1, mapfilept);   
            mapblockgfxpt = pvr_mem_malloc(mapblockwidth*mapblockheight*2);
            if(mapblockgfxpt==NULL) { maperror = MER_OUTOFMEM; return -1; }
            pvr_txr_load_ex((void *)rawimagedata, mapblockgfxpt, mapblockwidth, mapblockheight, PVR_TXRLOAD_16BPP);
        }  
        
        // Setup a KOS Platform independent image struct to hold each gfx block
        maplpDDSTiles[i] = (kos_img_t *)malloc(sizeof(kos_img_t));  
        maplpDDSTiles[i]->w = mapblockwidth;   
        maplpDDSTiles[i]->h = mapblockheight;
        maplpDDSTiles[i]->data = (void *)mapblockgfxpt;

        if(mapdepth == 8) {
            maplpDDSTiles[i]->fmt = PVR_TXRFMT_PAL8BPP;
            maplpDDSTiles[i]->byte_count = mapblockwidth*mapblockheight;
        } else if(mapdepth == 16) {
            maplpDDSTiles[i]->fmt = PVR_TXRFMT_RGB565;
            maplpDDSTiles[i]->byte_count = mapblockwidth*mapblockheight*2;
        }  
    
        mapblockgfxpt = NULL;
    } // End of mapnumblockgfx
    free(rawimagedata);
	return 0;
}

I know the code for mapdepth = 8 is incorrect but I am taking baby steps since palettes would be too much for me to handle right now so concentrate on the mapdepth = 16.

So when I test this code on a map that contains graphics I imported I get some wrong colors but the design does come out(the colors are just different than they should be). When I test it with the one that comes with Will Sams's SDLMappy Version I get some funky colors and no design at all. The graphics are both 16 bits. I couldn't understand why it would work with one image but not the other. So I just changed PVR_TXRFMT_RGB565 -> PVR_TXRFMT_ARGB4444 which still gave me the right design and wrong colors for my graphic but the same thing still happened with the other graphic. Then I changed PVR_TXRFMT_ARGB4444 -> PVR_TXRFMT_ARGB1555 and I kinda of got the right colors and right design for my graphic but the same wrong thing still happens for the other. As I said before, both are 16bit images but one is not working. I do not know how to tell from raw image data (when the graphic in *.fmp is 16bit) if it is RGB565, ARGB4444, or ARGB1555.

According to this (Scroll down to "The FMP file format" and look at BGFX) documentation all 16 bit are RGB565 format if I am not mistaken.

Here is my drawing function:

Code: Select all

void DCMappy::DrawBlock(void) {
    
    pvr_poly_cxt_t cxt;
    pvr_poly_hdr_t hdr;
    pvr_vertex_t vert;

    pvr_poly_cxt_txr(&cxt, PVR_LIST_OP_POLY, maplpDDSTiles[3]->fmt, maplpDDSTiles[3]->w, maplpDDSTiles[3]->h, (pvr_ptr_t)maplpDDSTiles[3]->data, PVR_FILTER_BILINEAR);
    pvr_poly_compile(&hdr, &cxt);
    pvr_prim(&hdr, sizeof(hdr));

    vert.argb = PVR_PACK_COLOR(1.0f, 1.0f, 1.0f, 1.0f);    
    vert.oargb = 0;
    vert.flags = PVR_CMD_VERTEX;
    
    vert.x = 1;
    vert.y = 1;
    vert.z = 1;
    vert.u = 0.0;
    vert.v = 0.0;
    pvr_prim(&vert, sizeof(vert));
    
    vert.x = 32;
    vert.y = 1;
    vert.z = 1;
    vert.u = 1.0;
    vert.v = 0.0;
    pvr_prim(&vert, sizeof(vert));
    
    vert.x = 1;
    vert.y = 32;
    vert.z = 1;
    vert.u = 0.0;
    vert.v = 1.0;
    pvr_prim(&vert, sizeof(vert));
    
    vert.x = 32;
    vert.y = 32;
    vert.z = 1;
    vert.u = 1.0;
    vert.v = 1.0;
    vert.flags = PVR_CMD_VERTEX_EOL;
    pvr_prim(&vert, sizeof(vert));
}

I've included all the source on the bottom of this post so you guys can take a look at it (including both graphics outside of *.fmp format).

http://www.tilemap.co.uk/mappy.php So you can test out the maps yourself

[OneThirty8]

I know there already exists a dreamcast port of SDLMappy by OneThirty8 (http://www.storm-studios.net/DCsamples.aspx)

That was actually ported by Will Sams. My projects are hosted on his site, but most (or all?) of the SDL examples there were ported by Will.

[BB Hood]

My mistake. Initial post fixed.

[Quzar]

You could speed it up a bit by making the header only compile into a context if the values change, and by having the vertices be static values (since... they are). Good job!

[BB Hood]

Thanks. I'll keep that in mind when I am drawing stuff with the PVR in the future. Anybody know why I am getting messed up colors?

[Guaripolo]

i think that if you use PVR_TXRFMT_ARGB4444 you should draw transparent polygons, not opaque (PVR_LIST_TR_POLY). Am i wrong?

[BlueCrab]

i think that if you use PVR_TXRFMT_ARGB4444 you should draw transparent polygons, not opaque (PVR_LIST_TR_POLY). Am i wrong?

As long as the texture format is set right in the polygon header, it doesn't matter what list you draw them to. Granted, you won't have transparency in the opaque list, but the textures should still have the right colors.

[BB Hood]

What really stomps me is that it works for the map that I made but not the map that came with SDLMappy even though both have 16 bit graphics. I am gonna have to experiment more...

[Quzar]

For 8-bit graphics, you also use PAL8BPP mode, which is just... not what you want to do. Paletted textures require a lot more work. You're almost better off converting 8bpp images to 16 instead of twiddling them. I also don't remember if this is required or assumed, but when I use TXR_FMT_RGB565 I always OR on PVR_TXRFMT_NONTWIDDLED.

[BB Hood]

Thanks for the advice. So 16 bit images aren't supposed to be twiddled before sending them to the PVR? I think I remember reading that. Only 8 bit and 4 bit have to be twiddled correct? I'll give OR'ing a try.

EDIT:

Didn't work. It just messed up the graphics.

[BlueCrab]

Since you're using pvr_txr_load_ex, it usually does the twiddling for you. You can switch that on or off, but for what you're doing, it probably doesn't matter much.

[BB Hood]

Yea. I saw that. I basically went through image loaders like pcx to see how to submit raw data into the PVR and applied it to what I was doing. Maybe the code isn't the problem. Maybe it is how the graphics data is stored in the file. I need to check how Mappy loads and saves graphics into its files (*.fmp)'s.

EDIT: Maybe showing you guys the SDLMappy code might help you guys help me:

Code: Select all

// ---------------------------------------------------------------------------------
// ---------------------------------------------------------------------------------
int SDLMappy::MapDecodeBGFX (void)
{
	unsigned long int i, size;
	unsigned long int temp;
	
	size=Mapbyteswapl(mapgenheader.headsize);
	if (mapdepth == 8) size *= 3;	//convert 8bit to 24bit
	mapblockgfxpt = (char *) malloc (size);
	if (mapblockgfxpt==NULL) { maperror = MER_OUTOFMEM; return -1; }
	switch(mapdepth)
	{
		case 8:
//			printf("maps en 8 bits non supportees pour l'instant...\n");
//			return -1;
//			fread (mapblockgfxpt, size, 1, mapfilept);
			for (i=0; i<size; i+=3)
			{
				fread (&temp, 1, 1, mapfilept);
				mapblockgfxpt[i]=mapcmappt[(temp&0XFF)*3+2];
				mapblockgfxpt[i+1]=mapcmappt[(temp&0XFF)*3+1];
				mapblockgfxpt[i+2]=mapcmappt[(temp&0XFF)*3];
			}
			break;
		case 16:
			for (i=0; i<size; i+=2)
			{
				fread (&temp, 2, 1, mapfilept);
				mapblockgfxpt[i+1]=temp&0XFF;
				temp>>=8;
				mapblockgfxpt[i]=temp&0XFF;
			}
			break;
		case 24:
			for (i=0; i<size; i+=3)
			{
				fread (&temp, 3, 1, mapfilept);
				mapblockgfxpt[i+2]=temp&0XFF;
				temp>>=8;
				mapblockgfxpt[i+1]=temp&0XFF;
				temp>>=8;
				mapblockgfxpt[i]=temp&0XFF;
			}
			break;
		case 32:
			for (i=0; i<size; i+=4)
			{
				fread (&temp, 4, 1, mapfilept);
				mapblockgfxpt[i+3]=temp&0XFF;
				temp>>=8;
				mapblockgfxpt[i+2]=temp&0XFF;
				temp>>=8;
				mapblockgfxpt[i+1]=temp&0XFF;
				temp>>=8;
				mapblockgfxpt[i]=temp&0XFF;
			}
			break;
		default:
			return -1;
			break;
	}

	return 0;
}

and here is another function filling tiles(maplpDDSTiles). I combined the ideas behind these two functions in my one MapDecodeBGFX();

Code: Select all

int SDLMappy::MapRelocate(void)
{
	int i, deplct;
	
	for(i=0; i<mapnumblockstr; i++) {
		((BLKSTR *) mapblockstrpt)[i].bgoff /= (mapblockwidth*mapblockheight*((mapdepth+1)/8));
		((BLKSTR *) mapblockstrpt)[i].fgoff /= (mapblockwidth*mapblockheight*((mapdepth+1)/8));
		((BLKSTR *) mapblockstrpt)[i].fgoff2 /= (mapblockwidth*mapblockheight*((mapdepth+1)/8));
		((BLKSTR *) mapblockstrpt)[i].fgoff3 /= (mapblockwidth*mapblockheight*((mapdepth+1)/8));
//		printf ("B%d: %d,%d,%d,%d\n", i, ((BLKSTR *) mapblockstrpt)[i].bgoff,((BLKSTR *) mapblockstrpt)[i].fgoff,((BLKSTR *) mapblockstrpt)[i].fgoff2 ,((BLKSTR *) mapblockstrpt)[i].fgoff3 );
	}

	if (mapdepth == 8) mapdepth = 24;

	switch(mapdepth)
	{
		case 8:
			deplct=mapblockwidth*mapblockheight;
			for(i=0; i<mapnumblockgfx; i++)
			{
				maplpDDSTiles[i] = SDL_CreateRGBSurfaceFrom (mapblockgfxpt+(deplct)*i,
						mapblockwidth, mapblockheight, mapdepth, mapblockwidth, 0, 0, 0, 0);			
				SDL_SetColors(maplpDDSTiles[i], mappept, 0, 256);
			}
			break;
		case 16:
			deplct=mapblockwidth*mapblockheight*2;
			for(i=0; i<mapnumblockgfx; i++)
				maplpDDSTiles[i] = SDL_CreateRGBSurfaceFrom (mapblockgfxpt+(deplct)*i,
						mapblockwidth, mapblockheight, mapdepth, mapblockwidth*2, 0XF800, 0X7E0, 0x1F, 0);			
			break;
		case 24:
			deplct=mapblockwidth*mapblockheight*3;
			for(i=0; i<mapnumblockgfx; i++)
				maplpDDSTiles[i] = SDL_CreateRGBSurfaceFrom (mapblockgfxpt+(deplct)*i,
					mapblockwidth, mapblockheight, mapdepth, mapblockwidth*3, 0XFF0000, 0XFF00, 0xFF, 0);			
			break;
		case 32:
			deplct=mapblockwidth*mapblockheight*4;
			for(i=0; i<mapnumblockgfx; i++)
				maplpDDSTiles[i] = SDL_CreateRGBSurfaceFrom (mapblockgfxpt+(deplct)*i,
					mapblockwidth, mapblockheight, mapdepth, mapblockwidth*4, 0XFF0000, 0XFF00, 0xFF, 0);			
			break;
		default:
			return -1;
			break;
	}

	return 0;
}

EDIT:

SDLMappy's *.fmp example works now but with funky colors. Before I only test tiles that where hard to make out with wrong colors. Now I can see that it works with both *.fmp's but the colors are messed up. Haven't looked at Mappy source yet.

[BlueCrab]

The only thing I can think of is that maybe the graphic data is stored in big endian format. From a quick read-through of the SDLMappy code, that's what it seems like is the problem. The colors are definitely RGB565, from looking at SDLMappy's code (when they're in 16-bit mode), but it looks like they're big endian.

[BB Hood]

I never had to deal with little endian or big endian so I will have to do some research on that. When I looked at the outputed graphics (I use NullDC) I noticed that the dimensions of the outputted graphic was only 31x31 when it is supposed to be 32x32...could the 'endian' problem cause this?

[BlueCrab]

I never had to deal with little endian or big endian so I will have to do some research on that. When I looked at the outputed graphics (I use NullDC) I noticed that the dimensions of the outputted graphic was only 31x31 when it is supposed to be 32x32...could the 'endian' problem cause this?

That has nothing to do with the endianness issue, that's probably something to do with the geometry data you're sending. try using a starting coordinate of (0, 0) and an ending one of (32, 32).

Here's a quick idea of how to fix the endianness issue though, basically use this function instead of pvr_txr_load_ex, it'll work pretty similarly.

Code: Select all

void swap_and_load(uint8 *src, pvr_ptr_t dst, int width, int height) {
    int bytes = width * height * 2, i;

    for(i = 0; i < bytes; i += 2) {
        dst[i] = src[i + 1];
        dst[i + 1] = src[i];
    }
}

Note that this will only work for 16-bit textures and it doesn't use the store queues (as pvr_txr_load_ex does, I believe). It may be a bit slower than pvr_txr_load_ex, but hopefully you're not trying to load a map file every frame. There are other ways to speed it up, but that I just threw together pretty quickly... Hopefully this will work for you though.

[BB Hood]

compiler error. pvr_ptr_t is basically a typedefe'd void* and I can't use arithmetic with those.

[OneThirty8]

compiler error. pvr_ptr_t is basically a typedefe'd void* and I can't use arithmetic with those.

I think you can fix it by doing something like...

Code: Select all

void swap_and_load(uint8 *src, pvr_ptr_t dst, int width, int height) {
    int bytes = width * height * 2, i;
    uint8 *dest = (uint8 *)dst;

    for(i = 0; i < bytes; i += 2) {
        dest[i] = src[i + 1];
        dest[i + 1] = src[i];
    }
}

[BB Hood]

Thanks. Well it fixed the colors but messed up what the image is supposed to look like. The function shows no twiddling. Maybe that is the problem?


EDIT: I finally(!) got it to work. Twiddling was needed. Here is the code:

Code: Select all

void swap_and_load(uint8 *src, uint8 *dst, int width, int height) {
    int bytes = width * height * 2, i;

    for(i = 0; i < bytes; i += 2) {
        dst[i] = src[i + 1];
        dst[i + 1] = src[i];
    }
}

int DCMappy::MapDecodeBGFX (void)
{
    int                i;
    char              *rawimagedata = NULL; // The raw graphics in whatever format the map is in [8bit;16bit]
    uint8             *test = NULL;  
    pvr_ptr_t       mapblockgfxpt = NULL; 
    
    // Allocated raw image data memory(one block at a time) depending on the mapdepth[8:1, 16:2] 
    if(mapdepth == 8) {
        rawimagedata = (char *)malloc(mapblockwidth*mapblockheight);
    } else if(mapdepth == 16) {
        rawimagedata = (char *)malloc(mapblockwidth*mapblockheight*2);
        test = (uint8 *)malloc(mapblockwidth*mapblockheight*2);
    }  
    if (rawimagedata == NULL) { maperror = MER_OUTOFMEM; return -1; }
    
    // One block at a time filling up maplpDDSTiles
    for(i = 0; i < mapnumblockgfx; i++) {
        
         // Allocated PVR Memory(one block at a time) depending on the mapdepth 
        if(mapdepth == 8) {
            fread(rawimagedata, mapblockwidth*mapblockheight, 1, mapfilept);      
            mapblockgfxpt = pvr_mem_malloc(mapblockwidth*mapblockheight);
            if(mapblockgfxpt==NULL) { maperror = MER_OUTOFMEM; return -1; }
            //swap_and_load(rawimagedata, test, mapblockwidth, mapblockheight);
            //pvr_txr_load_ex((void *)rawimagedata, mapblockgfxpt, mapblockwidth, mapblockheight, PVR_TXRLOAD_8BPP);
        } else if(mapdepth == 16) {
            fread(rawimagedata, mapblockwidth*mapblockheight*2, 1, mapfilept); 
            mapblockgfxpt = pvr_mem_malloc(mapblockwidth*mapblockheight*2);
            if(mapblockgfxpt==NULL) { maperror = MER_OUTOFMEM; return -1; }
            swap_and_load((uint8 *)rawimagedata, test, mapblockwidth, mapblockheight);
            pvr_txr_load_ex((void *)test, mapblockgfxpt, mapblockwidth, mapblockheight, PVR_TXRLOAD_16BPP);
        }  
        
        // Setup a KOS Platform independent image struct to hold each gfx block
        maplpDDSTiles[i] = (kos_img_t *)malloc(sizeof(kos_img_t));  
        maplpDDSTiles[i]->w = mapblockwidth;   
        maplpDDSTiles[i]->h = mapblockheight;
        maplpDDSTiles[i]->data = (void *)mapblockgfxpt;


        // PVR_TXRFMT_ARGB1555, PVR_TXRFMT_RGB565, PVR_TXRFMT_ARGB4444
        if(mapdepth == 8) {
            maplpDDSTiles[i]->fmt = PVR_TXRFMT_PAL8BPP;
            maplpDDSTiles[i]->byte_count = mapblockwidth*mapblockheight;
        } else if(mapdepth == 16) {
            maplpDDSTiles[i]->fmt = PVR_TXRFMT_RGB565; 
            maplpDDSTiles[i]->byte_count = mapblockwidth*mapblockheight*2;
        }  
        mapblockgfxpt = NULL;
    } // End of mapnumblockgfx
    free(rawimagedata);

	return 0;
}

void DCMappy::DrawBlock(void) {
    
    pvr_poly_cxt_t cxt;
    pvr_poly_hdr_t hdr;
    pvr_vertex_t vert;

    pvr_poly_cxt_txr(&cxt, PVR_LIST_OP_POLY, maplpDDSTiles[4]->fmt, maplpDDSTiles[4]->w, maplpDDSTiles[4]->h, (pvr_ptr_t)maplpDDSTiles[4]->data, PVR_FILTER_NEAREST);
    pvr_poly_compile(&hdr, &cxt);
    pvr_prim(&hdr, sizeof(hdr));

    vert.argb = PVR_PACK_COLOR(1.0f, 1.0f, 1.0f, 1.0f);    
    vert.oargb = 0;
    vert.flags = PVR_CMD_VERTEX;
    
    vert.x = 0;
    vert.y = 0;
    vert.z = 1;
    vert.u = 0.0;
    vert.v = 0.0;
    pvr_prim(&vert, sizeof(vert));
    
    vert.x = 32;
    vert.u = 1.0;
    pvr_prim(&vert, sizeof(vert));
    
    vert.x = 0;
    vert.y = 32;
    vert.u = 0.0;
    vert.v = 1.0;
    pvr_prim(&vert, sizeof(vert));
    
    vert.x = 32;
    vert.u = 1.0;
    vert.flags = PVR_CMD_VERTEX_EOL;
    pvr_prim(&vert, sizeof(vert));
}

There are probably better ways of doing it but getting it to work first is main priority.
Thanks BlueCrab & OneThirty8!

[BlueCrab]

Thanks. Well it fixed the colors but messed up what the image is supposed to look like. The function shows no twiddling. Maybe that is the problem?

Yeah, I certainly don't do any twiddling in there. Make sure to use the non-twiddled texture format (or it with the RGB565 part). I forgot to mention that, as I was actually running out the door right after I posted last...

[BB Hood]

Take a look at the first post to see it working.

So far there is no transparency support but searching through the forums I found this thread. Anybody know the route Quzar took?( Quzar are you there?). I can't tell looking from NeoDC 2.3 source code .

Also from the C:\cygwin\usr\local\dc\kos\kos\include directory I found endian.h which had these macros:

Code: Select all

#define __byte_swap_long(x) \
__extension__ ({ register u_long __X = (x); \
   __asm ("bswap %0" \
	: "=r" (__X) \
	: "0" (__X)); \
   __X; })
#else

#define __byte_swap_long(x) \
__extension__ ({ register u_long __X = (x); \
   __asm ("xchgb %h1, %b1\n\trorl $16, %1\n\txchgb %h1, %b1" \
	: "=q" (__X) \
	: "0" (__X)); \
   __X; })
#endif

#define __byte_swap_word(x) \
__extension__ ({ register u_short __X = (x); \
   __asm ("xchgb %h1, %b1" \
	: "=q" (__X) \
	: "0" (__X)); \
   __X; })

Can I use any of these to make the byte swap faster? (specifically __byte_swap_word(x) in my case?)


Also Dreamcast SDLMappy port setups SDL the screen like:

Code: Select all

/* Set the video mode */
	screen = SDL_SetVideoMode(Screen_w, Screen_h, Screen_bpp, SDL_HWSURFACE&SDL_DOUBLEBUF|SDL_HWPALETTE);

SDL_HWSURFACE means 'Create the video surface in video memory'. Does that mean the PVR? If it does then when color keying is used

Code: Select all

SDL_SetColorKey(maplpDDSTiles[i], SDL_SRCCOLORKEY,
						*(Uint16 *)maplpDDSTiles[TRANSPBLOCK]->pixels);

How does it work? Since the PVR doesn't support color keying.