gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Recent PAlib updates explained

#172931 - fincs - Thu Mar 11, 2010 10:19 pm

(Note: this was supposed to be a reply to a help post in this forum that had to do with PAlib)

Recently there has been some effort put into PAlib to make it less "evil" and compatible with the latest versions of devkitARM and libnds.

This is PAlib's recent story:
First of all, Mollusk went MIA around a year ago or so. Some community builds appeared at the time. Afterwards libnds 1.3.0 was released and WinterMute showed up in the (old) PAlib forums to make us think about the situation.
After understanding that PAlib was now a community project, I and n00bey started to adapt PAlib to the latest toolchain and libraries. Lots of beta versions were released at the time, each one fixing known bad practice problems and removing unused/deprecated/useless/unclean stuff. This includes the removal of the (rather shoddy) FatLoading, Video (wtf?) and GIF to tiles (wtf?!?!) modules and the deprecation of the #include data.c method and lots of token pasting macros.

At the time of writing PAlib is fully compatible with the latest versions of everything (albeit needing a recompilation to solve vramSetBankXX problems). The only problem with PAlib now is its clunkiness.

The reason that PAlib has so many wrappers around libnds/etc is actually historical. Mollusk said that PAlib began as a libnds replacement (with its own interrupt/etc system). libnds continued evolving, and it was clear that PAlib had to somehow adapt to the situation. Mollusk then decided to change PAlib to be based on libnds (with many incompatibilities), and this brought all the maintenance problems the devkitPro team has had to deal with.

The future of PAlib will probably consist on a complete rewrite. This new "PAlib" would have a completely different approach. It would be a series of wrappers around libnds that would manage the "hard" part of the equation (VRAM managing), and possibly some sugar here and there, but never an all-in-one DS homebrew library.

Go to the new PAlib homepage for updated information.

Last edited by fincs on Fri Mar 12, 2010 9:24 pm; edited 2 times in total

#172935 - wintermute - Fri Mar 12, 2010 12:18 am

No version of PALib will *ever* be supported by devkitPro given the major issues that it and it's users have caused us.

Quote:

Mollusk then decided to change PAlib to be based on libnds (with many incompatibilities), and this brought all the maintenance problems the devkitPro team has had to deal with.


That's a complete lie. The PALib installer deliberately overwrote libraries and broke the toolchain. Even now I'm *still* seeing problems from that.

The single best thing you could possibly do for the homebrew community is leave PALib to die instead of attempting to resurrect a decomposing corpse.

Even now, there is zero contact with the toolchain and library maintainers. No advice is being sought on how best to ensure that your code, examples and tutorials don't break the tools they depend on.

Wrappers and sugar for libnds would be far better contributed to libnds and you'd be much better off talking to us on IRC.

Here's some code I was looking at earlier :-

The libnds code
Code:

int soundPlayPSG(DutyCycle cycle, u16 freq, u8 volume, u8 pan){
   FifoMessage msg;

   msg.type = SOUND_PSG_MESSAGE;
   msg.SoundPsg.dutyCycle = cycle;
   msg.SoundPsg.freq = freq;
   msg.SoundPsg.volume = volume;
   msg.SoundPsg.pan = pan;

   fifoSendDatamsg(FIFO_SOUND, sizeof(msg), (u8*)&msg);

   while(!fifoCheckValue32(FIFO_SOUND));

   return (int)fifoGetValue32(FIFO_SOUND);
}


Some code recently added to PALib
Code:

void PA_PlayPSG(u8 chan, u8 vol, u8 pan, u32 freq, u8 duty) {
   PA_FifoMsg msg;
   msg.type = PA_MSG_PSG;
   msg.PSGMsg.freq = freq << 1; // a bug that fixes a bug.
   msg.PSGMsg.chan = (chan & 7) | 8; // clip it to a valid PSG channel
   msg.PSGMsg.vol = vol & 0x7F;
   msg.PSGMsg.pan = pan & 0x7F;
   msg.PSGMsg.duty = duty & 7;
   PA_SendFifoMsg(msg);
}


What exactly was the point of that? Why didn't you come and suggest libnds should work this way?

There are other source files in there that have basically been lifted from libnds with renamed functions.

Do you have permission to distribute no$gba?

Why are you still using templates from 4 years ago? Didn't you learn anything from PALib templates failing when we moved from arm-elf to arm-eabi? People using the standard devkitPro supplied templates didn't even notice.

There's so much more insanity in PALib that I wouldn't even know where to begin fixing it.

And pull that wiki, half of it reads like a manual on how to turn yourself into the worst programmer ever.

Please, for the good of DS Homebrew, let it die.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#172946 - sverx - Fri Mar 12, 2010 10:34 am

fincs wrote:
a series of wrappers around libnds that would manage the "hard" part of the equation (VRAM managing), and possibly some sugar here and there


I guess wrappers could become contributions to libnds? I've read in this forum somebody's already doing something similar...

#172962 - fincs - Fri Mar 12, 2010 9:40 pm

wintermute wrote:

Quote:

Mollusk then decided to change PAlib to be based on libnds (with many incompatibilities), and this brought all the maintenance problems the devkitPro team has had to deal with.


That's a complete lie. The PAlib installer deliberately overwrote libraries and broke the toolchain. Even now I'm *still* seeing problems from that.

Guess I kind of smoothed up too much that part...
The beginning of what I said is right (Mollusk "adapted" PAlib to be based off libnds), but as libnds changed (and thus breaking PAlib) Mollusk (dumbly) decided to bundle old versions of libnds with it, causing the maintenance problems you have had.

wintermute wrote:

The single best thing you could possibly do for the homebrew community is leave PAlib to die instead of attempting to resurrect a decomposing corpse.

You're right (myself I don't use PAlib anymore), but remember that there are still many people depending on PAlib. The least I can do is to try to maintain this "corpse" until better wrappers/tutorials are written for libnds (patater's uses floats!!!!).

wintermute wrote:

Here's some code I was looking at earlier :-

The libnds code
(snip)

Some code recently added to PALib
(snip)

What exactly was the point of that? Why didn't you come and suggest libnds should work this way?

In order to deliver battery, temperature and microphone "volume" (btw why wasn't that added to libnds?) to the ARM9 a FIFO channel had to be allocated. I decided to use FIFO_SOUND since there already are sound solutions that work with PAlib (Maxmod and *shudder* ASlib). Now you've made me think...

wintermute wrote:

There are other source files in there that have basically been lifted from libnds with renamed functions.

Do you have permission to distribute no$gba?

Those are things that I haven't touched.

wintermute wrote:

Why are you still using templates from 4 years ago? Didn't you learn anything from PALib templates failing when we moved from arm-elf to arm-eabi? People using the standard devkitPro supplied templates didn't even notice.

The makefile was updated to be more recent/newbie-friendly in the latest PAlib version.

wintermute wrote:

There's so much more insanity in PALib that I wouldn't even know where to begin fixing it.

You're soo right... (recalls cleaning up PAlib source code files)

wintermute wrote:

And pull that wiki, half of it reads like a manual on how to turn yourself into the worst programmer ever.

Again, I'm not responsible of that.

wintermute wrote:

Please, for the good of DS Homebrew, let it die.

Well, it will die when better wrappers are built for libnds. And the upcoming PAlib release will be the last, I promise.

#172970 - wintermute - Sat Mar 13, 2010 1:04 pm

fincs wrote:
wintermute wrote:

wintermute wrote:

The single best thing you could possibly do for the homebrew community is leave PAlib to die instead of attempting to resurrect a decomposing corpse.

You're right (myself I don't use PAlib anymore), but remember that there are still many people depending on PAlib. The least I can do is to try to maintain this "corpse" until better wrappers/tutorials are written for libnds (patater's uses floats!!!!).


No, the least you could do is co-operate with the toolchain maintainers and help provide those wrappers and tutorials.

Quote:

In order to deliver battery, temperature and microphone "volume" (btw why wasn't that added to libnds?) to the ARM9 a FIFO channel had to be allocated. I decided to use FIFO_SOUND since there already are sound solutions that work with PAlib (Maxmod and *shudder* ASlib). Now you've made me think...


It wasn't added to libnds because no-one got round to it yet - mainly because we keep getting distracted by broken tools caused by PALib installs.


Quote:

wintermute wrote:

Please, for the good of DS Homebrew, let it die.

Well, it will die when better wrappers are built for libnds. And the upcoming PAlib release will be the last, I promise.



There's an easy answer to that ... help us to help you. i.e. start being part of the solution and stop being part of the problem.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#172971 - fincs - Sat Mar 13, 2010 1:17 pm

Well, in fact I'm (supposed to be) making a wrapper library, but it still doesn't have anything since it was started then left over...