devkitPro

tom34 wrote:- Using 2 TEV stages on a polygon seems to take as much fillrate as drawing that polygon twice. Is it normal? Is it the same with any number of TEV stages?

Do both the TEV stages require a texture fetch? And is the vertex cost low? Then I assume it must be nearly the same.

Just be aware that each active light adds to the transform cost for each vertex! That's the same in DirectX and OpenGL or when you do your lighting in a vertex shader. In a professional game, even on next gen platforms like Xbox 360 or PS3, you try to have as few active lights as possible. If the li...

In general: you don't want to do that. If you want to draw sprites or glyphs for text it is much more efficient to store them as texture and draw screen-aligned quads. If you want to draw the result of some software rendering process it may still be more efficient to render into a texture and draw a...

I wrote a bit of code like that a while ago on GameCube. The problem is that a DOL file is not relocatable, and that the GC doesn't do any memory remapping (under normal circumstances). So you've got three choices: when making the second DOL make sure the memory regions don't overlap with the first ...

Maybe because xpos is not reset to 0 for each row? I assume ypos is initialised to 0.

The GX functions are a very thin wrapper around the GameCube 3D hardware. So you'll have to look through the hardware documentation to see if you can do something before it can be added to the GX library.

The reason I was asking is, the VtxDesc contains which elements of a vertex are present, and if they're direct, or if they use an 8 or 16 bit index. So if you've got different shaders it would be something you're changing very frequently. On the other hand I can see myself settling for only a handfu...

Interesting. Is it possible that not the test itself is the problem, but that the extra code moves some data or other stuff to trigger a crash? Does it crash on that instruction? Did you have a look at the assembler output, if the compiler does anything weird? Did you try without optimisations?

Based on yagcd the font is a compressed I4 texture. And looking at libogc/system.c I'd say SYS_InitFont decompresses the font and fills in the font header with the information how to render text. SYS_GetFontTexture seems to just return the texture address and glyph position, if you want to render it...

I'm a bit confused by vertex formats and vertex descriptions in libogc, for example: GX_ClearVtxDesc(); GX_SetVtxDesc(GX_VA_POS, GX_DIRECT); GX_SetVtxDesc(GX_VA_NBT, GX_DIRECT); GX_SetVtxDesc(GX_VA_TEX0, GX_DIRECT); GX_SetVtxAttrFmt(GX_VTXFMT0, GX_VA_POS, GX_POS_XYZ, GX_F32, 0); GX_SetVtxAttrFmt(GX_...