Prizm Useful Routines -- post here!

[Eiyeron]

Ok thanks. Should add a name in the credits for the help?
Eww, why some functions asks char, and elses asks shorts?

[calc84maniac]

Feel free to add credits if you want. Also, shorts are used because the Prizm has 16-bit color. What functions want char?

[Eiyeron]

CopySprite, and all thats use the Sprite Coder tool

[z80man]

CopySprite, and all thats use the Sprite Coder tool

I believe those are Kerm's old routines. The reason why he used chars was because they are guaranteed to be 1 byte on every C compiler while a short, though almost always 16 bits, is up to the implementation and we weren't sure yet what size gcc used for shorts yet on the SuperH. Now that shorts have been confirmed to be 2 bytes in memory it is safe to convert those routines from chars. It is also possible to use 32 bit int's or long's for a speed optimization at the cost of size. The reason why the size increases is because the code has to check for 32 bit alignment and if that condition is not met shorts must be used for the leading and/or trailing pixels. Plus if the sprites are small using int's or longs would result in a slower speed due to the alignment checking code. Because of this the only area where you would want to use 32 bit VRAM writes is if you can be guaranteed that the sprite is drawn in alignment (for example if you're drawing a background image) otherwise shorts are perfect for almost all drawing operations.

[Eiyeron]

So, We must now convert theses functions, and change the sprites, right?

[z80man]

So, We must now convert theses functions, and change the sprites, right?

It's easier than you would think. The routines would stay mostly the same and the sprites can be kept the way they are. All you need to do is have a (short*) cast on the char sprite array and it can be used with short based routines. For example if const char test[8450] is your sprite, to convert to a short use short * newtest = (short*)test;

[Eiyeron]

Code: Select All | Copy To Clipboard

1

I saw that, and I made that on alpha_clip...
So... Maybe tell with cemetech to change Source Coder?

Test with copysprite

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9

void CopySprite(short* data, int x, int y, int width, int height) {    short* VRAM = (short*)0xA8000000;    VRAM += (LCD_WIDTH_PX*y + x);  // what should I do?    for(int j=y; j<y+height; j++) {       memcpy(VRAM,data,width); // and here?       VRAM += LCD_WIDTH_PX;       data += width;    } }

Is is right? I can't now test

[Eiyeron]

I've got a suggestion to do:
Zommed sprites!
Z_sprite(spr, x, y, int factor)

[z80man]

Do you mean to say zoomed as in a scaled sprite? That is doable but I think you would want to change that function to say Z_sprite(short * spr, int x, int y, int width, int height, float factor)
It is better to use a float there because the factor is often not an integer value especially if you want to shrink a sprite.

[Eiyeron]

Maybe with a float, bout would see just *1, *2, io know that would be a quite heavy, but that will us gain size, and raam: WHy stock a 32*32 sprite, when we can just stock the same sprite, in 1:1 dimension, in a 16*16 tile?

[z80man]

The size of float based routines is really quite negligible and they don't use any extra ram because the entire executable is stored in flash. You could use a fixed point float in this situation but I would advise against them in this situation as the best way to write them out would be to use pre-defined macros such as TWO_POINT_FIVE which would be 0x00028000 in a 32 bit fixed point notation. The other alternative here is to specify when calling the function what size you would like to scale it to instead of providing a scale factor. Perhaps in this situation 2 different functions ought to be developed. One for rather straightforward scales that can be easily implemented such as x.5, x2, x4 and so on. This would be called as 2 raised to the x power. For example passing 0 as the scale will result in a sprite with no change in size while 1 will be x2, 2 as x4, 3 as x8, and so on. That would also mean that -1 would be .5, -2 as .25 and so on. The second routine would require much more overhead and be called with either a float factor or specify the new image size. If this sounds good I can start work on the first routine and have that out in not too long.

[Eiyeron]

I try to understand: for me, flaot system is imprecise, and more cpu-eater than prefixe coeffs.
THe system with power of 2 sounds good to me.

[Eiyeron]

Set colors to a short? Useful for paint-like things (that i want to make...)

Code: Select All | Copy To Clipboard

1 2	short setColors(unsigned char red, unsigned char green, unsigned char blue) return ((red & 0x1F) << 11 ) | ((green & 0x3F) << 5 ) | ((blue & 0x1F));

ANyone to optimize this?

Damn, double post... What would i do?

[calc84maniac]

Set colors to a short? Useful for paint-like things (that i want to make...)

Code: Select All | Copy To Clipboard

1 2	void setColors(unsigned char red, unsigned char green, unsigned char blue) return ((red & 0x1F) << 11 ) | ((green & 0x3F) << 5 ) | ((blue & 0x1F));

ANyone to optimize this?

Damn, double post... What would i do?

Actually, that function should return short or unsigned short, not void. And it's hard to tell how to optimize simple C code like this when it all depends on how the assembler generates the code.

[Eiyeron]

Yeah! Forgotten that!