You are not logged in.

#1 2008-06-23 07:25:37

Crayon
Bad Mother Fucker

Hardcoded values for Height and Width in GRRLIB_Printf

Hi, in the function GRRLIB_Printf values for Height and Width are hardcoded to 8. Some peoples may want to use a different size!

Code:

GRRLIB_DrawChar(xpos+i*8*zoom, ypos, 8, 8, data, 0, zoom, zoom, c,128, col );

Personally I don't think the maxframe value should be hardcoded to 128, peoples may want to have 256 chars. Tu devrais comprendre pour le fran├žais wink

Thanks

Offline

 

#2 2008-06-23 08:35:29

NoNameNo
Administrator

Re: Hardcoded values for Height and Width in GRRLIB_Printf

what about writting a My_own_drawchar_for_my_personal_need() function wink

Offline

 

#3 2008-06-23 16:49:01

Crayon
Bad Mother Fucker

Re: Hardcoded values for Height and Width in GRRLIB_Printf

I thought it would be a lot easier to do it on your side.

When the texture is loaded you just need to store two global variables:

Code:

Width = imgProp.imgWidth;
Height = imgProp.imgHeight;

And after you use them in GRRLIB_Printf

Code:

    int CharWidth = Width / 128;
    for(i=0;i<strlen(tmp);i++){
        u8 c = tmp[i];
        GRRLIB_DrawChar(xpos+i*CharWidth*zoom, ypos, CharWidth, Height, data, 0, zoom, zoom, c, 128, col );
    }

I think if you do that on your side, I wont have to change my GRRLIB file each time an update comes out.

I did not test it, but I think that's how it's supposed to work!

Offline

 

#4 2008-06-23 17:05:32

NoNameNo
Administrator

Re: Hardcoded values for Height and Width in GRRLIB_Printf

Or, since drawchar and drawtile is based on the near same code, we can define that after raw2c a font or a tileset, we will have to hand add in the h/c files  :

mypic_width =
mypic_width =
mypic_tile_width =
mypic_tile_height =

and all will be ok, for tile and font (used by printf), i will be able to calculate all the needed value.

in the same time you will be able to port your old converter to GRRLIB 3.0 to fit this need.

What do you think about this ?

Offline

 

#5 2008-06-23 17:26:08

Crayon
Bad Mother Fucker

Re: Hardcoded values for Height and Width in GRRLIB_Printf

It's a good idea, but I don't think we really need all those value:

mypic_width =
mypic_height =
mypic_tile_width =
mypic_tile_height =

Since GRRLIB_LoadTexture is getting the values for:
mypic_width = imgProp.imgWidth;
mypic_height = imgProp.imgHeight;

And mypic_tile_height is always equal to mypic_height since the tiles are store horizontally.

So the only important variable is mypic_tile_width, maybe it should be rename something like mypic_tile_count

It's just an idea, your the chief!

It's going to be easy for me to replace raw2c with my Converter to add the proper values.

Let me know what is your final decision...

Offline

 

#6 2008-06-23 20:18:32

RedShade
Member

Re: Hardcoded values for Height and Width in GRRLIB_Printf

My thought on the topic had been placing the textures into a struct, sort of like:

Code:

struct{
gxTexObj * frames;
u8 frameCount;
u8 curFrame;

//scaling
Mtx scale;
f32 scaleX;
f32 scaleY;

//rotates
Mtx rotate;
f32 rotX;
f32 rotY;
f32 rotZ;

//tint and alpha
GXColor tint;

u16 width;
u16 height;
}

It would place a limit on the size of sprites, since they'd have to be multiples of 4 (which they aren't technically now), but to load a sprite, you'd use a vertical strip.

Allocate the gxTexObj array to the frame count to begin with, and itterate through the sprite going by:

Code:

//PSUEDO:
for(i=0;i<frameCount;i++)
loadTexture( &frames[i], textureData+(i*(bytes_per_pixel)*height*width));

That way you have no restriction on sizes, tiles, and makes the sprite strips cleaner. I had another thought on making fonts and stuff, but I think this is probably the more practical of the two.

This is just a general idea for drawing animation strips/font. Font itself might want some structure so that you could more easily rotate the font as a whole to make it draw at angles (which  isn't that hard, but this is trying to store everything in a variable instead of sending all the parameters every function)

It also leaves a bit of room for adding TLUT's to the font/sprites in the future (for easier palette swapping), so you could actually have more complex multi-color fonts (like outline and such)

Last edited by RedShade (2008-06-23 20:21:26)

Offline

 

#7 2008-06-24 01:51:07

grillo
Member

Re: Hardcoded values for Height and Width in GRRLIB_Printf

A little recomendation for the font.png, you should make it squared instead of linear (16 rows of 16 characters each instead of one row of 128 or 256 characters), thats because (AFAIK) the Wii can't render things larger than 1024 * 1024, and if you try to render a font that it's size is 8x8 per character it will go nuts with the width of 2024 (happened to me when i was making a little text printing extension for wiilibsprite). I don't know if this is usefull, but here is the code i wrote for it (http://www.filedropper.com/texttar_2) hope that this was helpfull

Offline

 

#8 2008-06-26 19:41:00

RedShade
Member

Re: Hardcoded values for Height and Width in GRRLIB_Printf

I think it would sort of sad if the limit of textures in Wii was actually 1024x1024, since that's the hardware limit on the nintendo DS :-P

I'd need to look up if it's actually loading the entire texture to cache, or if it's just loading the texels you need though :-/...

An interesting test would be to make an indirect texture that is 4,096 x 4096, since the data to do that just requires a 128x128 IA4 map texture and 32x32 tiles for the palette texture :D... so with 8 tiles x 8 tiles, that is just a 128x128 IA4 and a 256x256 RGBA, both well within limits.

Last edited by RedShade (2008-06-26 19:57:09)

Offline

 

#9 2008-07-16 08:16:56

Crayon
Bad Mother Fucker

Re: Hardcoded values for Height and Width in GRRLIB_Printf

grillo wrote:

A little recomendation for the font.png, you should make it squared instead of linear (16 rows of 16 characters each instead of one row of 128 or 256 characters)

It would be nice, like that font image could compatible with TextClass for libwiisprite.

It's good to share things...

Offline

 

#10 2008-07-16 08:18:31

NoNameNo
Administrator

Re: Hardcoded values for Height and Width in GRRLIB_Printf

i already coded it, i just need to release it wink

Offline

 

#11 2008-07-16 08:19:48

Crayon
Bad Mother Fucker

Re: Hardcoded values for Height and Width in GRRLIB_Printf

If I'm a good boy could I have it now big_smile

Offline

 

#12 2008-07-29 21:16:30

JustWoody
Member

Re: Hardcoded values for Height and Width in GRRLIB_Printf

Crayon wrote:

Hi, in the function GRRLIB_Printf values for Height and Width are hardcoded to 8. Some peoples may want to use a different size!

Code:

GRRLIB_DrawChar(xpos+i*8*zoom, ypos, 8, 8, data, 0, zoom, zoom, c,128, col );

Personally I don't think the maxframe value should be hardcoded to 128, peoples may want to have 256 chars. Tu devrais comprendre pour le fran├žais wink

Thanks

Crayon I posted a version on the contributions a while ago that allows different sizes of font + and characters that may fit your requirements. I currently use it in my MahJongg Wii game.

Here is the link to that post:
http://grrlib.santo.fr/forum/viewtopic.php?id=33

At the time nobody commented so I assumed no one was interested in that sort of thing tongue

Last edited by JustWoody (2008-07-29 21:17:55)

Offline

 

#13 2008-07-29 22:51:40

Crayon
Bad Mother Fucker

Re: Hardcoded values for Height and Width in GRRLIB_Printf

JustWoody wrote:

Crayon I posted a version on the contributions a while ago that allows different sizes of font + and characters that may fit your requirements. I currently use it in my MahJongg Wii game.

Here is the link to that post:
http://grrlib.santo.fr/forum/viewtopic.php?id=33

Yes I notice that, it's just that I prefer to wait for the official release by NoNameNo. When it's out, I'm going to update my font generator.

Offline

 

Board footer

Powered by FluxBB