#1 2007-05-28 20:21:00

Moby Disk

Member

Registered: 2007-04-16

Posts: 8

irqInit bug in desmume?

I have several homebrew apps that ran horribly on desmume but ran fine on no$gba.  I tracked the problem down to a missing call to LibNDS irqInit() my homebrew apps.  Adding this called fixed things.

This is definitely a bug in my homebrew app.  But is it also a bug in desmume?

01torres

Member

Registered: 2007-03-19

Posts: 41

Re: irqInit bug in desmume?

It might help if you gives us some links to these "apps" so we can have a look at them and see if it has a problem with desmume and if we need to do anything about it.

Last edited by 01torres (2007-05-28 20:32:03)

---

The pen is mighter than the sword.
(Final Fanatasy VIII)

Moby Disk

Member

Registered: 2007-04-16

Posts: 8

Re: irqInit bug in desmume?

The following .cpp demonstrates the problem:

////////////////////////////////////////////////////////////////////////////////
// desmume bug (???) sample application
//
// This demonstrates a performance-related bug in desmume
////////////////////////////////////////////////////////////////////////////////

#include <nds.h>
#include <stdio.h>

int main()
{   
    // Turn on everything
    powerON(POWER_ALL);

   // An application SHOULD call this routine.  Failure to do so causes
   // desmume to run horrendously slowly.
   //irqInit();

   irqSet(IRQ_VBLANK, 0);
    irqEnable(IRQ_VBLANK);   

   while(1)
   {
        // wait for the screen to refresh
        swiWaitForVBlank();
    }
   
    return 0;
}

Just run it and watch the frame counter.  Ony my Athlon 3400+, the fps counter drops from 180fps to 23fps.  But in reality, I think the frame counter is wrong and actuality is closer to <5 fps.  Something really wacky happens if irqInit is not called.  Since most well-behaved applications should be calling this, but I noticed that several sample applications that come with libnds aren't calling it.  (The nehe 3D demos, for example)

Moby Disk

Member

Registered: 2007-04-16

Posts: 8

Re: irqInit bug in desmume?

Should I submit a bug fix to the nehe demos to address this (not sure who owns those), or is this a desmume bug?  It would be a shame for the homebrew developers to get the impression that desmume is really slow when it really isn't (I initially used no$gba because desumume wasn't running those demos very well)