2007-12-14

PALib-Be-Gone

I’ve applied Steven’s patch to the codebase. It needs a little tinkering to make it follow the rest of Woopsi’s coding style, but it’s a fantastic bit of code. Woopsi is now completely independent of PALib.

The question now, of course, is how I publicise it. Posting on the PALib forum is an easy way to get into the news pages of all the major DS homebrew sites. It’s not really appropriate to post it there any more…

Latest sources in SVN; looks like the patch has shaved 60K off the .nds binary file.

Comments

Jeff on 2007-12-14 at 02:36 said:

Now that PALib support is removed, put it back

But optionally, so that those who don’t want it don’t have to have it, but those who do want to use the PA_Wifi support, the PA_Sound support, can still use it.

It shouldn’t be so hard since all access to PALib would now be via Woopsi base methods rather than directly from individual gadgets…

Jeff on 2007-12-14 at 02:41 said:

… but first, add woopsifuncs.* to sourceforge

ant on 2007-12-14 at 07:59 said:

Done.

Jeff on 2007-12-14 at 08:00 said:

Muchos Gracias

Jeff on 2007-12-14 at 08:07 said:

Ok, that wasn’t too painful to upgrade to.

I’m somewhat surprised at the woopsie vs woopsi spelling but I suspect you’ll clean that up sometime.

ant on 2007-12-14 at 08:29 said:

Yep, that needs fixing, PALib support needs to go back in as an option, and I need to work out why the stylus release co-ords are wrong 10% of the time.

Jeff on 2007-12-14 at 09:08 said:

Can I respectfully suggest again pushing a tiny bit more back into the Woopsi class, to cut down on what needs to be in main.cpp

Heres my current main.cpp:


#include "dsorg.h"

// need to instantiate this - would be nicer if it was in a woopsi.cpp, but
// there ya go...
WoopsiApplication *WoopsiApplication::singleton = NULL;

int main()
{
        // Create woopsi application
        OrganizerApplication theApp;
        theApp.Startup();               // start it up
        theApp.draw();                  // ensure physical screen is up to date
        theApp.RunLoop();               // let the event loop run
        theApp.Shutdown();              // and we are done

        return 0;
}

And even that draw() call looks a bit gnarly - I’d prefer it if that were inside RunLoop(). The WoopsiApplication class just wraps a few more helpers around Woopsi. Its completely inline at the moment because a) it can be and b) because I hope its methods migrate back into woopsi.h


#pragma once
#include
#include

class WoopsiApplication :
        public Woopsi
{
public:
        static WoopsiApplication *singleton;

        // object construction
        inline WoopsiApplication()
        {
                initWoopsieGrfxMode();
                singleton = this;
        }

        virtual inline ~WoopsiApplication()
        {
                singleton = NULL;
        }

        // called once at application startup
        virtual inline void Startup(void) {}

        // main application loop - runs forever, or until somethinng
        // makes it stop
        virtual inline void RunLoop(void) {
                // Infinite loop to keep the program running
                while (1) {
                        ProcessOneVBL();
                }
        }

        // single event loop - allows modal screens to pump messages without
        // giving up complete control
        virtual inline void ProcessOneVBL(void) {
                this->play();
                woopsieWaitVBL();
        }

        // called once at application shutdown
        virtual inline void Shutdown(void)
        {
        }
};

#define woopsiApplication (WoopsiApplication::singleton)

The main benefit from this is that my fileselector.cpp which wants to run a MODAL screen, can do:


        FileSelector *fs;
        fs = new FileSelector();
        if (fs) {
                fs->RunLoop();
                delete fs;
        }
        return NULL;

where FileSelector::RunLoop() looks like this:


void FileSelector::RunLoop()
{
        _looping = true;
        while (_looping) {
                woopsiApplication->ProcessOneVBL();
        }
}

Still no knowledge of whether its PAlib or libnds directly under the covers.

I do think the name of Woopsi::play() is a bit odd as well, it being clearly derived from a game at some point in its past…

Jeff on 2007-12-14 at 09:12 said:

I should also point out that I wasn’t kidding about wifi support - the main reason for my apps existance was so that it would sync with iCal and AddressBook on my wifes MacMini. Removing the PA_Http() support from Woopsi has been a step backwards for me.

The major drag being that there are secret things you need to do to get wifi support working in the arm7 - the PA arm7 already did them, whereas the default libnds one doesn’t. Hmmm, I wonder whether I actually have the default arm7 binary any more - I think installing PAlib meant replacing the R21 libnds with the R20/PALib one. I may well have a botched developer environment. Bugger…

ant on 2007-12-14 at 09:41 said:

Don’t worry, getting PALib back in is top of the to-do list.