You are not logged in.
the right subjet.. is
A little modification.. that I did for the Willander..
I gave a new chance to GRRLIB, for the Wiilander game.. to make it works.. a I just added this little code to the GRRLIB, on the GRRLIB_Init() function:
SCR_WIDTH=rmode->fbWidth;
SCR_HEIGHT=rmode->efbHeight;
It help me to know the SCR width and height.. very useful for a vector game.. and also, due the number of lines that I have to draw, the function GRRLIB_Line, wasn't efficient for Wiilander.. maybe GRRLIB_NGone will do the work, but I haven't tried it.. instead I attack directly the GX with the following code:
GX_Begin(GX_LINES, GX_VTXFMT0, lineas_mapa*2); // dibuja mapa for(n=0;n<lineas_mapa;n++) { Line_x1=Mapa[n][0]; Line_y1=Mapa[n][1]; Line_x2=Mapa[n][2]; Line_y2=Mapa[n][3]; GX_Position3f32(Line_x1, Line_y1, 0.0f); GX_Color1u32(GRRLIB_BLUE); GX_Position3f32(Line_x2, Line_y2, 0.0f); GX_Color1u32(GRRLIB_BLUE); } GX_End();
Best regards, and thanks for the GRRLIB lib
Manny
Last edited by manny2008 (2009-03-08 22:40:51)
Offline
Hi Manny,
If you hardcode the variable into GRRLIB_Init(), you should better name those variables GRRLIB_SCR_WIDTH and GRRLIB_SCR_HEIGHT.
And looking at GRRLIB_Line() code you will see that it calls GRRLIB_NGone(), so probably you will not gain much performance.
Offline
I'm not a GX guru - but I am confused as to why the GRRLIB line algorithm should be slow ...If you decode what is actually compiled you get:
int i; guVector v[] = {{x1,y1,0.0f}, {x2,y2,0.0f}}; u32 ncolor[] = {color,color}; GX_Begin(GX_LINESTRIP, GX_VTXFMT0, n); for (i = 0; i < n; i++) { GX_Position3f32(v[i].x, v[i].y, v[i].z); GX_Color1u32(color[i]); } GX_End();
You could argue that the loop will slow things down, but it will be /very/ trivial
There may also be an argument about placing things in the vector struct, but that would be no more intense than the two-dimentional array you are using
I have no idea how LINES differs from LINESTRIP
My conclusion is this:
Function inlining has not worked until v4.1.0 ...and, to be honest, I have *not* decompiled a program to confirm that function inlining is working now
BUT, presuming function inlining now works, there are THREE function calls which no longer happen ...that is THREE PER LINE
Please try again with v4.1.0 and let us know if things are faster now
BC
Offline
Before of writting any more: I am not trying to say that anybody has done something wrong in grrLib. The quality of your demos and the number of projects in wiibrew using grrLib does matter much more than my opinion.
What a said is that manny2008 won't probably gain performance by using GRRLIB_NGone instead od GRRLIB_Line. The reason is clear... everyone is using GRRLIB_NGone today due to it implementation.
Also, I have not decompiled a grrlib program, but I have done before with gcc code (which is the compiler used in devkitppc). My impression is that gcc does a good work in inlinning code, but sometimes you can do even better by hand...
Now I will try to analyze the 4.1 grrlib trunk code
1. void GRRLIB_Line const f32 x1, const f32 y1, const f32 x2, const f32 y2, const u32 color)
1.1 guVector v[] = {{x1,y1,0.0f}, {x2,y2,0.0f}};
1.2 u32 ncolor[] = {color,color};
1.3 GRRLIB_NGone(v, ncolor, 2);
2. GRRLIB_NGone (const guVector v[], const u32 color[], const long n)
2.1 GRRLIB_GXEngine(v, color, n, GX_LINESTRIP);
3. void GRRLIB_GXEngine (const guVector v[], const u32 color[], const long n, const u8 fmt)
3.1 int i;
3.2 GX_Begin(fmt, GX_VTXFMT0, n);
3.3 for (i = 0; i < n; i++) {
3.4 GX_Position3f32(v[i].x, v[i].y, v[i].z);
3.5 GX_Color1u32(color[i]);
3.6 GX_End();
The overhead will come from the deep recursion (which will not be much due to inlinning) and also from the construction
of data structures as (1.1 and 1.2) that later must be deconstructed. This will be a SMALL overhead, as you stated, but if
you call GRRLIB_Line() inside a loop you will get a sum of small overheads and also an use of registers that may be not optimus.
So, as yourself have decoded your code in this post. Why not use?
void GRRLIB_Line const f32 x1, const f32 y1, const f32 x2, const f32 y2, const u32 color) { GX_Begin(GX_LINES, GX_VTXFMT0, 2); GX_Position3f32(x1, y1, 0); GX_Color1u32(color); GX_Position3f32(x2, y2, 0); GX_Color1u32(color); GX_End(); }
Edit: This code is tested and working !!!
And I am not sure if you can do even better
void GRRLIB_Line const f32 x1, const f32 y1, const f32 x2, const f32 y2, const u32 color) { GX_Begin(GX_LINES, GX_VTXFMT0, 2); EDIT: OOOOPS. THIS CODE DOES NOT WORK! GX_Color1u32(color); GX_Position3f32(x1, y1, 0); GX_Position3f32(x2, y2, 0); GX_End(); }
Edit: This code is tested and crashed my wii
Same applies to GRRLIB_Plot(), but it is possible to do even better using the framebuffer (but you need to do that strange color conversion from RGBA to YUYUV)
Last edited by jespa (2009-08-19 17:51:51)
Offline
And here is the optimized (and tested) version of GRRLIB_Plot.
/** * Draw a dot. * @param x Specifies the x-coordinate of the dot. * @param y Specifies the y-coordinate of the dot. * @param color The color of the dot in RGBA format. */ INLINE void GRRLIB_Plot (const f32 x, const f32 y, const u32 color) { /* JESPA Optimizations guVector v[] = {{x,y,0.0f}}; u32 ncolor[] = {color}; GRRLIB_NPlot(v, ncolor, 1); */ GX_Begin(GX_POINTS, GX_VTXFMT0, 1); GX_Position3f32(x, y, 0); GX_Color1u32(color); GX_End(); }
PD: Manny siento el offtopic que he montado en tu post
Last edited by jespa (2009-08-19 18:15:00)
Offline
Hey JESPA,
First, I'd like to take a brief moment to address your opening comment:
Before of writting any more: I am not trying to say that anybody has done something wrong in grrLib. The quality of your demos and the number of projects in wiibrew using grrLib does matter much more than my opinion.
As the newest member of the GRRLIB Team, I feel I am best placed to say that everyone here is friendly, open minded, and without false ego. We enjoy the chance to see old things in new ways - your opinion does matter
Secondly. Your code breakdown...
There seems to be only one way to answer:
Yes. You're right. Thank You. Your changes are now in SVN with your name in the credits & doxygen headers.
BC
Offline
Oh thanks....
In exchange I will send you the fullscreen - plasma based - asphyxia inspired - extremely hot fire demo I used to test both functions.
Just give a couple of days to clean the code and write commentaries (yes, It takes more time to clean code than to write it )
Offline
jespa : another soon new GRRLIB team member ??
What about a little intro or demo in cooperation with motivated ppl ?
Offline
NoNameNo wrote:
What about a little intro or demo in cooperation with motivated ppl ?
The demo could be downloaded from http://wiibrew.org/wiki/User:Jespa/firewii
Hopefully the source code will come soon...
Offline
In fact, while was writing the page on wiibrew to prepare the release I found that somebody had modified my page just 3 minutes after my last change... and had deleted my download section!
When I looked for the Bad Mother Fucker that deleted it... I saw that he is our B.M.F. on here. And my download section is not missed, it was just moved to a cool box on the right of the page. Thanks for your help Crayon
Of course, the source code is going to be released. I am just studying the best option. Project on code.google? A firewii.src.rar file at wiibrew? Not sure yet, but I wanted to publish the code in this forum before, just to have the ability to receive comments and suggestions about it.
I suppose that if GRRLIB accept it as a demo, the best publication method is just a link to GRRLIB subversion.
And please, move to this post to further talking about firewii. This is the manny2008 post, not mine.
Offline