Unable to display more than 130 sprites

[Reinhart]

I want to display a map. Let's say a dungeon for an hypothetic rpg.

I use sprite because I don't know how to use tile. I hoped it would have work the same ...

(I'm using SGL as usual).

So, I register 3 16x16 sprites (1 for the ground ,1 for the wall and 1 for a character).

SPR_ATTR attr[] = {

	SPR_ATTRIBUTE(0,No_Palet,No_Gouraud,CL32KRGB|ECdis,sprNoflip),	//ground1

	SPR_ATTRIBUTE(1,No_Palet,No_Gouraud,CL32KRGB|ECdis,sprNoflip),	//wall1

	SPR_ATTRIBUTE(2,No_Palet,No_Gouraud,CL32KRGB|ECdis,sprNoflip),	//face1

};

ANGLE angz[] = {

	DEGtoANG( 0),	

};

TEXTURE tex_spr[] = {

	TEXDEF(16,16,0),	//ground1

	TEXDEF(16,32,256),	//wall1

	TEXDEF(16,27,768),	//face1

};

PICTURE pic_spr[] = {

	PICDEF(0,COL_32K,ground1),

	PICDEF(1,COL_32K,wall1),

	PICDEF(2,COL_32K,face1),

};

And define multiple position for that sprite.

FIXED playerpos[][XYZS] = {

	{toFIXED( 0),toFIXED(100),toFIXED(168),toFIXED(1.0)},

};

FIXED wallpos[][XYZS] = {

	{toFIXED(-32),toFIXED( 29),toFIXED(169),toFIXED(1.0)}, // 1

	{toFIXED(-16),toFIXED( 29),toFIXED(169),toFIXED(1.0)}, //2

 .....

	{toFIXED( 48),toFIXED(-68),toFIXED(169),toFIXED(1.0)}, //12

};

FIXED groundpos[][XYZS] = {

	{toFIXED( 0),toFIXED(100),toFIXED(169),toFIXED(1.0)}, //1	{toFIXED(-16),toFIXED(100),toFIXED(169),toFIXED(1.0)}, //2

 .........

	{toFIXED(-32),toFIXED(100),toFIXED(169),toFIXED(1.0)}, //130

};

Then in my main file, I try to display all defined sprites.

But not all the sprites are not displayed, and I can't really see why.

I'm sure a clipping procedure will improve (but don't solve ?) this problem.

I believed that the Saturn could display unlimited sprites ...

What do you think about that ??

Source code + binary in the attachement.

 

[ExCyber]

Well, it's not really unlimited, but rather not a fixed limit like the old shift register / FIFO type of sprite engines. There are two limiting factors in the Saturn hardware:

1) Fill rate - VDP1 can only make so many memory accesses in a given period of time, which limits the number of pixels that can be drawn.

2) VDP1 command list limits - VDP1 renders based on a command list stored in VRAM, and there are various limitations imposed by the way that VDP1 processes the list.

What you're describing sounds like an SGL limitation, though. 130 sprites is a rather small number for VDP1 to be dealing with (cf. Don Pachi ). I'll dig through the reference manual and see what I can find out...

edit: are the sprites that are displayed in the locations you expected?

 

[Reinhart]

Originally posted by ExCyber@Mar 19, 2004 @ 07:54 PM

edit: are the sprites that are displayed in the locations you expected?

Well sort of ... the origine doesn't seem to be in the upper left corner

I dsiplay the first sprite randomly and then add the others followinf that position.

The wall was displayed about 8 pixels above the desired position.

(I have to look closer at this by trying to display a wall and a ground at the same position).

Don't forget that this problem can be due to my lack of programming skills.And the purpose of the post is more to discuss of the problem than solve my problem ...

 

[vbt]

I don't know if it can help you but I had a small sprite limit when I tried to display sprites with the SBL 6 and I had to move the initial sprite adress to be able to display more sprites. I don't know if you can do the same with the SGL. The code looked like that, I only changed the charAddr position.

  for (i=0;i<64;i++)

  {

    smsSprite[i].control  = (JUMP_NEXT | FUNC_NORMALSP);

    smsSprite[i].link    = 0;    

    smsSprite[i].drawMode  = (ECDSPD_DISABLE | COLOR_5 | COMPO_REP);        

    smsSprite[i].color   = 0;        

    smsSprite[i].charAddr  = 0x100+0x0010*i;

    smsSprite[i].charSize  = 0x0108; /* x*y = 8*16 : 0x0110  x*y = 8*8 : 0x0108 */

    smsSprite[i].ax     = 0;

    smsSprite[i].ay     = 0;

    smsSprite[i].bx     = 0;

    smsSprite[i].by     = 0;

    smsSprite[i].cx     = 0;

    smsSprite[i].cy     = 0;

    smsSprite[i].dx     = 0;

    smsSprite[i].dy     = 0;

    smsSprite[i].grshAddr  = 0;

    smsSprite[i].dummy   = 0;

  }

Also I remember there was a workarea for the SGL and it was used to allocate/limit polygons, sprites buffer, etc .. Maybe you need to customize it ?

 

[antime]

If there's some hard-coded limit you can always draw sprites in smaller batches. That also means VDP1 spends less time idling and thus increases the total number of sprites you can display.

 

[Sonikusan]

I don't know anything about programming, but are you utilizing both chips with your program?

 

[Reinhart]

I assume you mean the 2 video cpu, VDP1 and VDP2.

If I understand everything right :

VDP1 is used for all sprite related things, sprite transformations like rotation and scaling.

VDP2 is used for background (up to 5 simultaneously).

So in this case, only the VDP1 is used.

(more sample in the Saturn Dev section )

If you mean the 2 main processor (BTW, is it 2 SH2 or 1 SH1 and 1 SH2 ?), I can't really answer.

The SGL is a high level library and things work without you deal with the hardware.

Hope what I wrote is comprehensive ?

Anyone, fell free to correct inacurate info

PS.

Fun fact : The Hitachi milling center we have at work also have SH1 and SH2 inside ...

 

[IBarracudaI]

The main processors are SH2's (@28.6MHz), there is also a SH1 inside though , on the cdboard.