Homebrew So why was PALib so bad?

  • Thread starter Thread starter Boy12
  • Start date Start date
  • Views Views 4,776
  • Replies Replies 4

Boy12

NOT a new member!
Member
Joined
Mar 8, 2012
Messages
536
Reaction score
135
Trophies
0
Location
Purmerend
XP
479
Country
Netherlands
Just out of curiosity, I checked out some old DS homebrew but some people in the Comments said that the creator was using PALib, and that he should avoid it.

Why was it so bad, and why where there still so many homebrew games/apps made with it?
 
http://devkitpro.org/wiki/PAlib
If you're just getting started with NDS homebrew development then you should avoid PAlib, PAlib users and PAlib tutorials at all costs. They will give you bad advice and teach you programming methodologies which will hinder your progress and ensure that your projects are plagued with problems that will be nigh on impossible to fix.

In the early days of Nintendo DS development, while libnds was still building the low level support code, a library appeared with the goal of making things easier for novice programmers. This library, called PAlib ( standing for Programmer's Arsenal ), set out to provide a comprehensive set of wrapper functions which would allow someone with only the most basic knowledge of programming to get the skeleton of a DS game up and running quickly.

Making the tools used for homebrew programming more accessible to a wider range of skillsets is a laudable goal - one that is shared wholeheartedly by devkitPro. Unfortunately PAlib was badly designed, made use of internal functions never intended for user code and didn't keep pace with development which has fixed several very nasty bugs over the years. It might seem easier to get up and running but problems are still being reported with SD card corruption, odd issues with flashcards and wifi connection problems that have all been resolved by not using PAlib wrappers for libnds code.

For this reason devkitPro will not provide support to users attempting to get PAlib working. If you have followed the instructions given on the PAlib site and other sites whose tools depend on PAlib then uninstall completely and start over from scratch without replacing the PAlib parts. This is the only way to avoid issues that have been long fixed.

At the time of writing we have plans to further improve the accessibility of the tools and libraries we release. Unfortunately it will not be possible to ensure that 3rd party releases remain compatible with our tools and the integrity of those tools will be placed in question if you install anything not released by devkitPro inside, or make modifications to, the file system provided by the automated installer.

The maintainer was a cool dude.
 
It was easy to use and beginner-friendly. As a result, many cool things were made with it.

That doesn't matter to real programmers though, if you don't use libnds or assembly, you're a n00b.
 
It was easy to use and beginner-friendly. As a result, many cool things were made with it.

That doesn't matter to real programmers though, if you don't use libnds or assembly, you're a n00b.
The first point is true. The second point is not true. The reason it was recommended to avoid palib was because it was not kept up to date with changes to libnds and it caused a lot of problems to be reported to devkitarm support. Palib did allow you to get something running quickly but it got more difficult from there.
 
  • Like
Reactions: DanTheManMS
Exactly. If PALib had managed to keep up-to-date with each new release of libnds, proactively retiring any "hacked-together" functions in favor of the "official" libnds replacements with each and every release, then there wouldn't have been any drama whatsoever. The problem is, that is much easier said than done. It proved to be too difficult for the PAlib maintainers, who are only human with regular jobs just like the rest of us, so PAlib ended up being kinda stuck in a rather specific configuration of DevKitARM tools/compilers/whatever.

Anyway this is a complete side note, but there is one PAlib-based homebrew game that I would highly suggest everyone try out in no$gba or your favorite DS emulator of choice. It's a Zelda fangame by a fellow named Lupidan, and the reason it can only be played off of slot-2 devices or an emulator is because the game's audio files are packaged into the rom itself using a system called "PAFS", or "PAlib File System", or "It's GBFS by Tepples renamed"
 
  • Like
Reactions: Coto

Site & Scene News

Popular threads in this forum