Upcoming changes

[sumiguchi]

I would like to see some of the details about upcoming changes to devkitarm, libnds, and dswifi

I am a palib user myself, and while my participation in the development/support of palib is limited mostly to helping out on the forums, knowing some of the changes in advance could help reduce compatibility issues for new releases. (ie. Release 21 - btw: I hear a maintenance release of palib is coming soon to resolve this).

You are doing good work and it is very much appreciated!

[WinterMute]

It's difficult to know how to approach the PAlib problem being honest. Had they not started including random versions of devkitPro supplied libraries within their installer then the most recent linking issues would not have happened. Even back when devkitARM switched over to arm-eabi most of their problems would have been avoided if they had used the build system and templates provided with the toolchain in release 18 instead of sticking with their own outdated versions of the makefile templates.

For me personally, it's very difficult to even attempt to find potential PAlib issues because their installer leaves me with an installation that just doesn't work. Even when they weren't embedding old library versions none of their example code compiled for me and I didn't have the time or motivation to fix it.

Unfortunately the issues with PAlib are only likely to get worse as libnds advances towards a feature complete mid level library and devkitARM gets updated accordingly. They provide several shoddy implementations of features that are planned for future libnds releases which will further destroy compatibility.

Ultimately something like PAlib may seem desirable for a novice coder but has the unfortunate side effect of insulating them from the knowledge they need to move beyond it.

[sumiguchi]

Ugghh. I am not really interested in getting into a discussion about why I use palib, but I must say that you telling me that I am a novice coder is a bit offensive. DS games are my hobby and its my choice to use palib and my goal was just to try and help fill the gap when new releases come out not to start a flame war about using palib.

[dopefish]

WinterMute wasn't calling you a novice coder, he was just pointing out that PAlib aims to help novice coders. In fact he didn't say anything about you at all.
The problems with PAlib after a new release of devkitARM or libnds generally are due to the poor design of PAlib itself, not because upcoming changes to DKA or libnds "sneak up" on the PAlib maintainers.

[sumiguchi]

ok...did I take that too personally? Sorry...

I guess the answer is no...which is fine - it was just my suggestion.

[WinterMute]

Well, firstly I wasn't calling you a novice coder, it was actually a comment on the philosophy behind something like PAlib. We've seen many people write games for the GBA using things like HAMlib and SGADE only to find themselves completely lost when it comes to DS programming despite the two systems having almost identical 2D hardware. I completely understand why people want to use these libraries - the instant gratification keeps motivation high when you don't have a lot of time to spend on something that may only be a hobby. Unfortunately those of us who work on the toolchain and associated libraries come from a long tradition of low level coding and we're much more comfortable working closer to the hardware. It's difficult to find a good middle ground between such different mindsets but I do think we've done a good job of making homebrew programming much more accessible to a wider range of people.

The biggest difficulty I have with PAlib is that the compatibility problems on toolchain and library releases are largely of their own making and could have been avoided with a little more thought. The project templates should have been updated to match closer with the templates supplied by devkitPro rather than simply changing a few variables in the templates they had. The libraries supplied by devkitPro should never have been distributed within the PAlib tarballs - this one is almost guaranteed to cause more serious issues in the future.

This is meant to be constructive criticism not a flame war. If those two issues were dealt with then it would go a long way towards reducing compatibilty problems.

[sumiguchi]

Wintermute - I find your second post to me much more constructive than your first! (but maybe I'm just "sensitive" )

So it sounds like there are some fundamental issues to be addressed around the project template. Not sure the feasibility of changes but at least I know that's a good starting point.

[Quirky]

Going a bit off-topic, but what would be the ideal way for something like PAlib to install itself? Provide a Makefile with an "install" target that placed everything in $DEVKITPRO/palib? Can't say I've used PAlib, but it does seem like a good idea if it were done right. I have similar problems with 3rd party libs (zlib, libpng, etc.) and end up just bunging them in $DEVKITPRO/libnds to save myself headaches. Something of a hack, but this standard in the DS scene really seems like the equivalent of C:\Windows or /usr/lib.

As for upcoming stuff... you could always take a peak at devkitPro's CVS every once in a while. I saw the RTC changes coming and prepared my code to make use of them before they were released. It took me longer to debug my own mistakes in other places mind

[eitje]

I think the general suggestion of producing feature set targets for each release is a good idea. Given a small enough change-set in each release, a checklist would not be too dauntingly long, and would be a "free" changelist (once the release is completed).

However, something like that can also kill the creativity & fun involved with things like this, too. So...