devkitPro

At a first glance, that seems normal, pFmt.start and pFmt.end are never initialized and they would hold zero by default, hence the result is 0. You probably need to initialize these fields to -1 before calling LoadPCMWav, in order to get the whole sound length. I'd advise you to first learn how to u...

As I understand the quote you posted, the bug is within the application code, not libogc. In short, they wrote bugged code to fix an earlier bug in libogc (and if I remember well, it was EURGB60 that was bugged, i.e 480i on PAL Wii, not 480p ). The bug was fixed in libogc long time ago but the dirty...

You should first learn how pointer are working in C. here, pFmt is NOT allocated, it will crash as soon as a function try to access the memory address returned by the pointer (NULL by default). here is a more correct code: PCMWAVFmt pFmt; int wavPlay(const char* file) { void *buf = LoadPCMWav(file, ...

A short note to the FP context switch: In case there was no thread context switch, ie same thread keeps running after exception, there won't be a FP context switch. In thread_dispatch_fp (lwp_threads.c) i check the executing context against the currently used FP context. And only if thread context ...

So if i'm not totally wrong this instruction should get executed then. I just verified in the official documentation and you are off course right , the value saved in SRR0 by the CPU when FPU unavailable exception occurs is the address of the floating-point instruction causing the exception so it i...

My situation is a little bit different since I only use one thread (the main application thread). Now, from what I've read about PPC exception, the FPU is generally disabled during the IRQ handler then restored when returning from exception, by saving MSR initial bits value in SRR1 then clearing the...

No I didn't. Disabling interrupt during this loop indeed seems to fix the random incorrect values. Does it mean the FP registers are somehow not saved/restored properly when the pow() function is interrupted ? Or maybe something within FPU ? In all cases, my issue appears to be fixed by this workaro...

Hi, I've been facing a random bug in genesis plus gx and I finally managed to figure it was caused by some corrupted table initialisation in my code, which surprisingly does not behave in a deterministic way (as it should) and will sometime end computing wrong value. This particular code: for (x=0; ...

Seems like the following code did the job, not really sure why though, I tried this out of luck. Still didn't get GX_REPEAT to work properly however. void DrawTextureRepeat(png_texture *texture, int x, int y, int w, int h) { if (texture->data) { /* load texture object */ GXTexObj texObj; GX_InitTexO...

Hi I would like to render a 16x16 textured tile over the whole framebuffer (640x480), mainly to use as background texture I was thinking about using GX_REPEAT mode but it does not seems to work properly (the texture is still "stretched" instead of being "repeated") Here's the cod...