New user intro / question(s) about Parallax and sprites

[Roukan]

Hi All

Newly registered user reporting in:

Name: Jim
Age: 50
Location: Lancashire (UK)

Never programmed the Dreamcast before and my C knowledge is beginner level.

I have been reading the forums for a couple of weeks now to start learning about Dreamcast programming using C & KOS/PARALLAX libraries.

At first I was drawing to the display direct using the VRAM buffer with success but soon realised that I should start working with the PVR as it is so much faster.

I've got my head around the PVR display list and managed to display some sprites.

So here I am with a couple of questions for the resident experts:

Sprite Sheet
------------
At the moment I'm loading each sprite individually from a .PNG file.

Is this the normal way you would go about things or do you use one big image eg: 256x256 containing 64 32x32 sprites and reference their specific area within the image?

If so how do you approach this (a simple example would be nice) ?

Sprite Size
-----------
I read here in the forum that the sprite dimensions must be powers of 2 and be the same otherwise they will not display: I tried a 16x16 sprite and it would not display?


I apologize in advance if these questions have been asked/answered before, though I have had a look through the forum and couldn't find a clear answer.

*NB* I am using LxDream emulator to test my code and accept that things not working could be a fault with the emulator and not my code - I do have an SD card reader on it's way from the U.S.A. which will help me eliminate this type of problem by testing on my Dreamcast.


Many thanks


Roukan / Jim

[BlueCrab]

You can use either a sprite sheet or individual textures. I don't recall ever seeing any performance benefit to one over the other, so it is more a matter of how you want to deal with your data. If you wish to use sprite sheets, then you'll need to manipulate the U and V coordinates of the vertices you submit to the hardware. I don't have a canned example of how you'd do this with libparallax, but it shouldn't be all that difficult to figure out. Basically, U goes from 0.0 to 1.0 as you go from the left side of your texture to the right, likewise for V from the top to the bottom. So, if you had a 256x256 pixel sprite sheet, and you wanted to draw the sprite that starts at (32, 64) to (64, 96), you'd have U coordinates of 0.125 (for the top left/bottom left) and 0.250 (for the top right/bottom right), and V coordinates of 0.250 (top left and top right) and 0.375 (bottom left and bottom right).

Textures must be powers of two between 8 and 1024 to be usable by the hardware. They do not have to be square, but both dimensions must be powers of two*. 16x16 should work fine on the real hardware (I've used that size before in my code without trouble).

* - Technically, there is a way to make neither dimension a power of two. For the horizontal, you can use one strided size per frame, which allows you to use a non-power-of-two dimension for that texture. You only get to set the size once per frame, so all strided textures used in a frame must have the same horizontal resolution. You still treat the texture as power-of-two sized for all other purposes though (including with U/V coordinates). For the vertical direction, you can specify a larger texture size than you're actually using without much trouble, as long as your V coordinates don't go out of range for what you're actually submitting. So, you could combine strided textures with the vertical resolution "trick" I mentioned and have neither size be a power of two, but there's probably not much use in doing that.

[Roukan]

Thanks for the very quick reply BlueCrab

You can use either a sprite sheet or individual textures. I don't recall ever seeing any performance benefit to one over the other, so it is more a matter of how you want to deal with your data. If you wish to use sprite sheets, then you'll need to manipulate the U and V coordinates of the vertices you submit to the hardware. I don't have a canned example of how you'd do this with libparallax, but it shouldn't be all that difficult to figure out. Basically, U goes from 0.0 to 1.0 as you go from the left side of your texture to the right, likewise for V from the top to the bottom. So, if you had a 256x256 pixel sprite sheet, and you wanted to draw the sprite that starts at (32, 64) to (64, 96), you'd have U coordinates of 0.125 (for the top left/bottom left) and 0.250 (for the top right/bottom right), and V coordinates of 0.250 (top left and top right) and 0.375 (bottom left and bottom right).

I shall have a play around with this and hopefully have some success, which will give me options on which way I want to approach things.

Textures must be powers of two between 8 and 1024 to be usable by the hardware. They do not have to be square, but both dimensions must be powers of two*. 16x16 should work fine on the real hardware (I've used that size before in my code without trouble).

This nice to hear that these sizes are supported.

I knew the emulation testing was going to be a major pitfall at times - the Parallax font example displayed garbage - inspired me to write my own so I could use any bitmap font and that worked fine which was a good learning exercise for me - though I have since abandoned it as it was writing direct to the VRAM buffer and I'm trying to master the PVR route

* - Technically, there is a way to make neither dimension a power of two. For the horizontal, you can use one strided size per frame, which allows you to use a non-power-of-two dimension for that texture. You only get to set the size once per frame, so all strided textures used in a frame must have the same horizontal resolution. You still treat the texture as power-of-two sized for all other purposes though (including with U/V coordinates). For the vertical direction, you can specify a larger texture size than you're actually using without much trouble, as long as your V coordinates don't go out of range for what you're actually submitting. So, you could combine strided textures with the vertical resolution "trick" I mentioned and have neither size be a power of two, but there's probably not much use in doing that.

On first read this went totally over the top of my head, but I didn't feel so bad when I saw the "but there's probably not much use in doing that" at the end


Many thanks

Roukan / Jim

[patbier]

* - Technically, there is a way to make neither dimension a power of two. For the horizontal, you can use one strided size per frame, which allows you to use a non-power-of-two dimension for that texture. You only get to set the size once per frame, so all strided textures used in a frame must have the same horizontal resolution. You still treat the texture as power-of-two sized for all other purposes though (including with U/V coordinates). For the vertical direction, you can specify a larger texture size than you're actually using without much trouble, as long as your V coordinates don't go out of range for what you're actually submitting. So, you could combine strided textures with the vertical resolution "trick" I mentioned and have neither size be a power of two, but there's probably not much use in doing that.

Hello BlueCrab, this is very interesting. Can you explain more ? Thanks !

[BlueCrab]

* - Technically, there is a way to make neither dimension a power of two. For the horizontal, you can use one strided size per frame, which allows you to use a non-power-of-two dimension for that texture. You only get to set the size once per frame, so all strided textures used in a frame must have the same horizontal resolution. You still treat the texture as power-of-two sized for all other purposes though (including with U/V coordinates). For the vertical direction, you can specify a larger texture size than you're actually using without much trouble, as long as your V coordinates don't go out of range for what you're actually submitting. So, you could combine strided textures with the vertical resolution "trick" I mentioned and have neither size be a power of two, but there's probably not much use in doing that.

Hello BlueCrab, this is very interesting. Can you explain more ? Thanks !

There's really not all that much left to explain there. If you want to use a non-power-of-two size horizontally, just use a strided texture. That should be relatively straightforward (although KOS doesn't directly support doing so, it still shouldn't be hard to figure out).

If you want to use a non-power-of-two size vertically, allocate less than you actually specify in the polygon header. So, for instance, if you want a texture that is 24 pixels tall, allocate the space accordingly with pvr_mem_malloc() for that 24 pixel tall texture, but when you send the parameters to the PVR, tell it you're actually using a 32 pixel tall texture (the next power of two size up from 24). Just be sure to not use a V coordinate greater than 24.0 / 32.0 = 0.75, or you'll probably pick up uninitialized memory or another texture as part of what you draw.

[Tvspelsfreak]

If you want to use a non-power-of-two size vertically, allocate less than you actually specify in the polygon header. So, for instance, if you want a texture that is 24 pixels tall, allocate the space accordingly with pvr_mem_malloc() for that 24 pixel tall texture, but when you send the parameters to the PVR, tell it you're actually using a 32 pixel tall texture (the next power of two size up from 24). Just be sure to not use a V coordinate greater than 24.0 / 32.0 = 0.75, or you'll probably pick up uninitialized memory or another texture as part of what you draw.

And make sure your texture is stored in scan order. It won't work for twiddled textures.

[patbier]

Thanks for answer, but what is a "strided texture" ?

[BlueCrab]

A strided texture is simply one that doesn't have a power-of-two size horizontally. You specify the row-stride (number of pixels/bytes) between each row vertically in a specific PVR register, then when the strided flag is set in a polygon header, it uses the information in that register to determine the actual data from the texture to use, rather than calculating the row-stride from the U size in the polygon header.

The U size from the polygon header is still used in deriving the U coordinates, hence why you need to make sure you don't go out of range with that. So, if you wanted to use a texture that's 640 pixels wide and draw it across the whole screen, you'd set the value in the stride register corresponding to that size, and when you wanted to draw it, you'd specify the U size on the texture as the next power of two (so 1024), and the U coordinates on the right hand side of the screen would be 640.0 / 1024.0.

[Roukan]

I don't know if BlueCrab is still following this thread (or maybe someone else can help).

I've ran the attached code below on lxDream emulator and everything display on screen as I would expect it to, but as I received my SD card adapter yesterday I tried the code on my Dreamcast and got very different results.

I understand that code may not run as expected under emulation and the opposite can happen where things seem fine but on the real thing it's broken - probably due to low level hardware feature not implemented correctly on the emulator.

As I have no way of taking a screenshot from my Dreamcast I will try and describe the problem - maybe I will have to upload the elf/bin file somewhere so you can try it for yourself.

The code draws playing cards - each card is built from 4 plx_texture_t sprites:
1) 128x128 for the card itself (card_front in the code)
2) 64x64 for large suit symbol (card_suits[1][n] in the code)
3) 32x32 for small suit symbol (card_suits[0][n] in the code)
4) 32x32 for card rank (card_ranks[0][n] BLACK / card_ranks[1][n] RED in the code)

*NB* 32x32 ones above should be 16x16 - but don't work on the emulator so I went with 32x32 for time being which do work.

Item 1) PNG file has transparency except for any WHITE or GREY (card outline) pixel.
Items 2),3),4) PNG files have transparency except for any BLACK or RED pixel.

The problem is some pixels are just not being drawn and the pattern is always the same ie: All pixels missing from "K" are missing from all "K" etc. On item 1) the WHITE pixels all appear to be drawn but some of the GREY ones are not.

Now if I fill a WHITE area around the BLACK/RED pixels on items 2),3),4) then all the RED/BLACK pixels do appear to be drawn (this I can live with in this instance but this cannot be applied to item 1) as it must stay transparent so cards be drawn overlapping etc.)

I apologize in advance for any poor code I may have written (still a novice and have probably done something really stupid) but also much appreciate any time taken to help me out as I'm sure you have more important things to spend your time on.


Many thanks

Roukan / Jim


The code:

Code: Select all

/****************************************
 *	      Library Dependencies			*
 ****************************************/
#include <stdlib.h>
#include <time.h>

#include <kos.h>
#include <plx/font.h>
#include <plx/sprite.h>
#include <plx/list.h>
#include <plx/dr.h>
#include <plx/color.h>

#include "card.c"

/****************************************
 *	Defines								*
 ****************************************/

/****************************************
 *			Type declarations			*
 ****************************************/

/****************************************
 *			File-level variables		*
 ****************************************/
static pvr_init_params_t pvr_params = {
    /* Enable Opaque, Translucent, and Punchthru lists */
    { PVR_BINSIZE_16, PVR_BINSIZE_0, PVR_BINSIZE_16, PVR_BINSIZE_0,
      PVR_BINSIZE_16 },
    512 * 1024, /* 512 KB of vertex buffer space */
    0, /* Vertex DMA disabled */
    0  /* "FSAA" off */
};

extern uint8 romdisk[];
KOS_INIT_FLAGS(INIT_DEFAULT | INIT_MALLOCSTATS);
KOS_INIT_ROMDISK(romdisk);

plx_dr_state_t dr_state;      /* Direct Render State */

/* controller stuffs, only port 1 */
cont_state_t * cont1;
maple_device_t * c1add;

plx_texture_t * card_front;
plx_texture_t * card_back;
plx_texture_t * card_suits[2][4]; 
plx_texture_t * card_ranks[2][13];

/****************************************
 *	Function declarations				*
 ****************************************/
void load_sprites(void);
void draw_card(float x, float y, card_t card);

/****************************************
 *	Function definitions				*
 ****************************************/
int main(void) {
	int i, j;
	card_t deck[DECK_SIZE];

/* Set up the PVR, and the DR */
	pvr_init(&pvr_params);
	pvr_set_bg_color(0.2f, 0.0f, 0.4f);
	plx_dr_init(&dr_state);

/* Init the first controller */
	c1add = maple_enum_type(0, MAPLE_FUNC_CONTROLLER);

	float x = 40.0f;
	float y = 56.0f;

	float a = 360.0f;

	pvr_wait_ready();

	srand (time(NULL));
	init_deck(deck, DECK_SIZE);

	load_sprites();

	while(1) {

		cont1 = maple_dev_status(c1add);

		if(cont1->buttons & CONT_START)
			break;
         
		if(cont1->buttons & CONT_DPAD_DOWN) 
			y += 4.0f;
      	
		if(cont1->buttons & CONT_DPAD_UP)
			y -= 4.0f;
         
		if(cont1->buttons & CONT_DPAD_LEFT) {
			x -= 4.0f;
			a -= 4.0f;
		}
         
		if(cont1->buttons & CONT_DPAD_RIGHT) {
			x += 4.0f;
			a += 4.0f;
		}

		plx_scene_begin();

		plx_list_begin(PLX_LIST_OP_POLY);


		plx_list_begin(PLX_LIST_PT_POLY);

		init_deck(deck, DECK_SIZE);

		for (i = 0;	i < 4; i++) {
			for (j = 0; j < 13; j++) {
				draw_card(x+j * 20, y+i * 120, deck[(i * 13) + j]);
			}
		}

		shuffle(deck, DECK_SIZE);

		for (i = 0;	i < 4; i++) {
			for (j = 0; j < 13; j++) {
				draw_card(a+j * 20, y+i * 120, deck[(i * 13) + j]);
			}
		}

		/*draw_card(x, y, deck[9]);
		draw_card(x+88, y, deck[10]);
		draw_card(x+176, y, deck[11]);
		draw_card(x+264, y, deck[12]);
		draw_card(x+352, y, deck[0]);

		draw_card(x, y+120, deck[9+13]);
		draw_card(x+88, y+120, deck[10+13]);
		draw_card(x+176, y+120, deck[11+13]);
		draw_card(x+264, y+120, deck[12+13]);
		draw_card(x+352, y+120, deck[0+13]);

		draw_card(x, y+240, deck[9+26]);
		draw_card(x+88, y+240, deck[10+26]);
		draw_card(x+176, y+240, deck[11+26]);
		draw_card(x+264, y+240, deck[12+26]);
		draw_card(x+352, y+240, deck[0+26]);

		draw_card(x, y+360, deck[9+39]);
		draw_card(x+88, y+360, deck[10+39]);
		draw_card(x+176, y+360, deck[11+39]);
		draw_card(x+264, y+360, deck[12+39]);
		draw_card(x+352, y+360, deck[0+39]);*/

		plx_list_begin(PLX_LIST_TR_POLY);

		plx_scene_end();

	}

	plx_txr_destroy(card_front);
	plx_txr_destroy(card_back);

	return 0;
}

void load_sprites(void) {
	card_front = plx_txr_load("/rd/gfx/card_front.png", 1, PVR_TXRLOAD_16BPP);	/* 128x128 PNG Image */
	card_back = plx_txr_load("/rd/gfx/card_back.png", 1, PVR_TXRLOAD_16BPP);	/* 128x128 PNG Image */

	card_suits[0][0] = plx_txr_load("/rd/gfx/spade_sml.png", 1, PVR_TXRLOAD_16BPP);
	card_suits[1][0] = plx_txr_load("/rd/gfx/spade_big.png", 1, PVR_TXRLOAD_16BPP);
	card_suits[0][1] = plx_txr_load("/rd/gfx/club_sml.png", 1, PVR_TXRLOAD_16BPP);
	card_suits[1][1] = plx_txr_load("/rd/gfx/club_big.png", 1, PVR_TXRLOAD_16BPP);
	card_suits[0][2] = plx_txr_load("/rd/gfx/heart_sml.png", 1, PVR_TXRLOAD_16BPP);
	card_suits[1][2] = plx_txr_load("/rd/gfx/heart_big.png", 1, PVR_TXRLOAD_16BPP);
	card_suits[0][3] = plx_txr_load("/rd/gfx/diamond_sml.png", 1, PVR_TXRLOAD_16BPP);
	card_suits[1][3] = plx_txr_load("/rd/gfx/diamond_big.png", 1, PVR_TXRLOAD_16BPP);

	card_ranks[0][0] = plx_txr_load("/rd/gfx/black_01.png", 1, PVR_TXRLOAD_16BPP);
	card_ranks[1][0] = plx_txr_load("/rd/gfx/red_01.png", 1, PVR_TXRLOAD_16BPP);
	card_ranks[0][1] = plx_txr_load("/rd/gfx/black_02.png", 1, PVR_TXRLOAD_16BPP);
	card_ranks[1][1] = plx_txr_load("/rd/gfx/red_02.png", 1, PVR_TXRLOAD_16BPP);
	card_ranks[0][2] = plx_txr_load("/rd/gfx/black_03.png", 1, PVR_TXRLOAD_16BPP);
	card_ranks[1][2] = plx_txr_load("/rd/gfx/red_03.png", 1, PVR_TXRLOAD_16BPP);
	card_ranks[0][3] = plx_txr_load("/rd/gfx/black_04.png", 1, PVR_TXRLOAD_16BPP);
	card_ranks[1][3] = plx_txr_load("/rd/gfx/red_04.png", 1, PVR_TXRLOAD_16BPP);
	card_ranks[0][4] = plx_txr_load("/rd/gfx/black_05.png", 1, PVR_TXRLOAD_16BPP);
	card_ranks[1][4] = plx_txr_load("/rd/gfx/red_05.png", 1, PVR_TXRLOAD_16BPP);
	card_ranks[0][5] = plx_txr_load("/rd/gfx/black_06.png", 1, PVR_TXRLOAD_16BPP);
	card_ranks[1][5] = plx_txr_load("/rd/gfx/red_06.png", 1, PVR_TXRLOAD_16BPP);
	card_ranks[0][6] = plx_txr_load("/rd/gfx/black_07.png", 1, PVR_TXRLOAD_16BPP);
	card_ranks[1][6] = plx_txr_load("/rd/gfx/red_07.png", 1, PVR_TXRLOAD_16BPP);
	card_ranks[0][7] = plx_txr_load("/rd/gfx/black_08.png", 1, PVR_TXRLOAD_16BPP);
	card_ranks[1][7] = plx_txr_load("/rd/gfx/red_08.png", 1, PVR_TXRLOAD_16BPP);
	card_ranks[0][8] = plx_txr_load("/rd/gfx/black_09.png", 1, PVR_TXRLOAD_16BPP);
	card_ranks[1][8] = plx_txr_load("/rd/gfx/red_09.png", 1, PVR_TXRLOAD_16BPP);
	card_ranks[0][9] = plx_txr_load("/rd/gfx/black_10.png", 1, PVR_TXRLOAD_16BPP);
	card_ranks[1][9] = plx_txr_load("/rd/gfx/red_10.png", 1, PVR_TXRLOAD_16BPP);
	card_ranks[0][10] = plx_txr_load("/rd/gfx/black_11.png", 1, PVR_TXRLOAD_16BPP);
	card_ranks[1][10] = plx_txr_load("/rd/gfx/red_11.png", 1, PVR_TXRLOAD_16BPP);
	card_ranks[0][11] = plx_txr_load("/rd/gfx/black_12.png", 1, PVR_TXRLOAD_16BPP);
	card_ranks[1][11] = plx_txr_load("/rd/gfx/red_12.png", 1, PVR_TXRLOAD_16BPP);
	card_ranks[0][12] = plx_txr_load("/rd/gfx/black_13.png", 1, PVR_TXRLOAD_16BPP);
	card_ranks[1][12] = plx_txr_load("/rd/gfx/red_13.png", 1, PVR_TXRLOAD_16BPP);

}

void draw_card(float x, float y, card_t card) {
	plx_txr_send_hdr(card_front, PLX_LIST_PT_POLY, 0);
	plx_spr_fnd(&dr_state, 128.0f, 128.0f, x, y, 5.0f, 1.0f, 1, 1, 1);

	plx_txr_send_hdr(card_ranks[card.colour][card.rank], PLX_LIST_PT_POLY, 0);
	plx_spr_fnd(&dr_state, 32.0f, 32.0f, x-24, y-40, 5.0f, 1.0f, 1, 1, 1);

	plx_txr_send_hdr(card_suits[0][card.suit], PLX_LIST_PT_POLY, 0);
	plx_spr_fnd(&dr_state, 32.0f, 32.0f, x-24, y-20, 5.0f, 1.0f, 1, 1, 1);

	plx_txr_send_hdr(card_suits[1][card.suit], PLX_LIST_PT_POLY, 0);
	plx_spr_fnd(&dr_state, 64.0f, 64.0f, x, y+24, 5.0f, 1.0f, 1, 1, 1);

}

[Tvspelsfreak]

You might have some Z fighting going on. Try giving the sprites that should appear on top of the card a larger Z value.

[Roukan]

You might have some Z fighting going on. Try giving the sprites that should appear on top of the card a larger Z value.

Thanks very much for the reply:

I increased the z value by 1.0 for items 2),3),4) but this made no difference

[Tvspelsfreak]

Do you get the same issues if you draw everything in the PLX_LIST_TR_POLY list?

[Roukan]

Do you get the same issues if you draw everything in the PLX_LIST_TR_POLY list?

Just tried this now - everything appears to display correctly

[Tvspelsfreak]

plx_txr_load loads pngs with either PNG_NO_ALPHA or PNG_FULL_ALPHA depending on its alpha parameter (full alpha in your case). The PT poly list only allows for 1-bit alpha (fully opaque or fully translucent).

I'm guessing the missing pixels aren't fully opaque and aren't rendered because their alpha values are below the PT alpha threshold, and hence are regarded as fully translucent.

If you use the png loader directly, you can use PNG_MASK_ALPHA to load a texture with 1-bit alpha. I don't see any support for it in libparallax though.

[Roukan]

plx_txr_load loads pngs with either PNG_NO_ALPHA or PNG_FULL_ALPHA depending on its alpha parameter (full alpha in your case). The PT poly list only allows for 1-bit alpha (fully opaque or fully translucent).

I'm guessing the missing pixels aren't fully opaque and aren't rendered because their alpha values are below the PT alpha threshold, and hence are regarded as fully translucent.

If you use the png loader directly, you can use PNG_MASK_ALPHA to load a texture with 1-bit alpha. I don't see any support for it in libparallax though.

Thanks for your help / feedback on this - I'll look into the "PNG loader" at some point - at least I can move forward by using the TR list for now.