gbadev.org forum archive

Mod note: split from "Trouble with PAlib" thread

ThomasS wrote:

Yes, I'm one of those who extended the latest "official" version. Our new beta wasn't released with an installer yet (only in archive form), so the version you're referring to is the old version which was still solely developed by Mollusk. When we release a new installer, we certainly won't include any DevkitARM files anymore.

I just looked at the mess you're distributing, we're going to have even more serious issues in the future. Currently I don't know how, or even if, we're likely to be able to resolve that.

Currently I'm in the process of sorting out some minor issues with what will become the officially recommended DS sound library. This will surpass and obsolete all of the libraries you're distributing. Why would you actually distribute several incompatible & in some cases poorly written sound libraries anyway. In particular, mp3 is not now, nor will it ever be a suitable format for game audio on the DS.

We're moving towards a default arm7 core that will support most functions a homebrewer would require in a bid to do something about the horribly inefficient and unstable nonsense people are putting in their arm7 cores.

Why does PAlib wrapper libnds functions with PA_ anyway?
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

Last edited by wintermute on Tue Mar 11, 2008 8:05 pm; edited 1 time in total

Quote:

Currently I'm in the process of sorting out some minor issues with what will become the officially recommended DS sound library. This will surpass and obsolete all of the libraries you're distributing.

Out of interest: what format(s) will this library support for background music?

Quote:

Why would you actually distribute several incompatible & in some cases poorly written sound libraries anyway.

To give the users the most possibilities to choose from.

Quote:

In particular, mp3 is not now, nor will it ever be a suitable format for game audio on the DS.

Why? By using Noda's as_lib, the decoding can be done on the arm7, so there is no time wasted on the arm9 (except for streaming the mp3 files).
Of course this doesn't match with your concept of one arm7 binary because then you won't be able to fit dsWifi and liblobby also into it.

Quote:

Why does PAlib wrapper libnds functions with PA_ anyway?

The problem with libnds is that it's so low-level and that it's hard to learn.
1) low-level:
Most programmers would regard code like setting lots of registers in order to setup a background as ugly and hard to understand. Why not use a specialized function call?
Look at the poll results in this thread.

2) hard to learn:
Of course gbatek is an excellent reference, but it doesn't replace some sort of tutorial - all which exist are incomplete and some also outdated.

Combined, this makes it completely unusable for beginners, and it takes much time to become familiar with it. This is why there is PAlib. It doesn't just prefix libnds functions with PA_, it makes it a lot easier to program for the DS. It's a high level alternative to libnds and thus has it's right of existence.

That being said, I'm also not completely happy with PAlib. For example, the code is a mess, and it's sad that the VRAM layout is mostly fixed.

It would be better if this pro/contra PAlib battle could be resolved. Even if the libnds concepts (official sound library without mp3 support, default arm7 core) don't match with the PAlib ones, there doesn't have to be this hostile attitude. We're not deliberately trying to break devkitARM.
_________________
<dsFont> <Game Collection>

So, [risks flame war] what is it that's wrong with the PAlib distro? I don't mean what's wrong with the actual code/messiness/OOness/whatever: if I install PAlib, how will it mess up my DKA installation?
I'd really like to have a go with it, but there seems to be a lot of stick aimed that way which sort of puts me off. I would like something that wraps up the 2D system of the DS, as I find that pretty tricky to work with. But if PAlib is also incompatible with whatever I want to roll with libnds then it's sort of worthless to me...
_________________
Big thanks to everyone who donated for Quake2

ThomasS wrote:

Quote:

Currently I'm in the process of sorting out some minor issues with what will become the officially recommended DS sound library. This will surpass and obsolete all of the libraries you're distributing.

Out of interest: what format(s) will this library support for background music?

mod, xm, it, s3m and a few other related tracker formats.

Quote:

Why would you actually distribute several incompatible & in some cases poorly written sound libraries anyway.

To give the users the most possibilities to choose from.

Quote:

In particular, mp3 is not now, nor will it ever be a suitable format for game audio on the DS.

Why? By using Noda's as_lib, the decoding can be done on the arm7, so there is no time wasted on the arm9 (except for streaming the mp3 files).
Of course this doesn't match with your concept of one arm7 binary because then you won't be able to fit dsWifi and liblobby also into it.

The idea that running mp3 playback on the ARM7 has minimal impact on the ARM9 is rather misleading. As you've mentioned, the audio streaming needs to take place on the 9 but further to that, any accesses the arm7 makes to the shared memory have a large impact on the other processor. You also have to consider the speed of the various FAT devices and their effect on processor time. The DS audio hardware also outputs it's final mix stage at 32KHz which reduces any quality gains from a purely streamed audio system. A sequenced format such as the trackers mentioned above is eminently more suited to a resource limited device like the DS.

There are applications where mp3 playback is a good choice - video players and mp3 players spring to mind, but not in a DS game.

Quote:

Why does PAlib wrapper libnds functions with PA_ anyway?

The problem with libnds is that it's so low-level and that it's hard to learn.
1) low-level:

I was referring more to things like PA_WaitVBL, PA_ScanKeys etc - as far as I could determine these functions were pure wrappers for the underlying libnds functions.

Quote:

Most programmers would regard code like setting lots of registers in order to setup a background as ugly and hard to understand. Why not use a specialized function call?
Look at the poll results in this thread.

This part we do agree on, thus the poll and the move towards higher level APIs in libnds itself. For my part, the primary motivation behind doing this would be to make it easier for users to choose libnds and never have to install PAlib.

Quote:

2) hard to learn:
Of course gbatek is an excellent reference, but it doesn't replace some sort of tutorial - all which exist are incomplete and some also outdated.

There is some work in progress to address that particular issue. As I've mentioned in other places, most people who write tutorials are utterly clueless about good coding practices and have a limited knowlege of the subjects they purport to teach to others.

Quote:

It's a high level alternative to libnds and thus has it's right of existence.

PAlib builds on libnds and, had it stuck with that approach rather than attempting to provide editors, broken build systems and really quite nasty methods of including binary data, I would be less annoyed by it's existence.

That being said, I'm also not completely happy with PAlib. For example, the code is a mess, and it's sad that the VRAM layout is mostly fixed.

Quote:

It would be better if this pro/contra PAlib battle could be resolved. Even if the libnds concepts (official sound library without mp3 support, default arm7 core) don't match with the PAlib ones, there doesn't have to be this hostile attitude. We're not deliberately trying to break devkitARM.

And yet it continues to happen. The installer package which does deliberately break devkitARM continues to exist and support requests relating to that can really only be answered by "don't rely on PAlib, it breaks your toolchain and will force you to use outdated and unsupported toolsets"

Unfortunately I can't help feeling that PAlib is doing a great disservice to the homebrew community in it's current form. Advising users to stick with unsupported and outdated tools and surreptiously installing outdated and potentially broken libraries in place of official releases is unlikely to gain you much respect from the toolchain maintainers.

On the other hand, I do understand that there is a need for a higher level API which better suits the needs of novices. For us the best course would seem to be to provide that in libnds and provide better documentation.

The community would probably be better served by having the more clueful PAlib developers offer help, advice and potentially code to libnds rather than attempting to fix the frankenstein's monster that PAlib unfortunately became.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

simonjhall wrote:

So, [risks flame war] what is it that's wrong with the PAlib distro? I don't mean what's wrong with the actual code/messiness/OOness/whatever: if I install PAlib, how will it mess up my DKA installation?

The PAlib installer overwrites the official libnds install with a version not compatible with devkitARM r21 or the forthcoming r22. PAlib itself depends on code in libnds which was incomplete and in the process of being updated. This will eventually lead to a situation where you either have to dispense with PAlib or never update your toolchain again.

We do intend to provide code to wrap the 2D hardware a lot more, see the devkitPro forum thread linked to earlier in the discussion.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

wintermute wrote:

I was referring more to things like PA_WaitVBL, PA_ScanKeys etc - as far as I could determine these functions were pure wrappers for the underlying libnds functions.

They would also appear to make it possible to write a wrapper around PAlib that calls corresponding functions on Windows, Windows Mobile, or Pandora.

Quote:

There is some work in progress to address that particular issue. As I've mentioned in other places, most people who write tutorials are utterly clueless about good coding practices and have a limited knowlege of the subjects they purport to teach to others.

Would putting tutorials on a wiki help? For one thing, talk pages would let people who actually have a clue expose a tutorial's deficiencies.

I'll respond to your opinion about sequenced vs. streaming music in another topic because I don't see it as entirely toolchain related.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

ThomasS wrote:

Quote:

In particular, mp3 is not now, nor will it ever be a suitable format for game audio on the DS.

Why? By using Noda's as_lib, the decoding can be done on the arm7, so there is no time wasted on the arm9 (except for streaming the mp3 files).
Of course this doesn't match with your concept of one arm7 binary because then you won't be able to fit dsWifi and liblobby also into it.

Is that really the reason? If so: what about a kind of arm7 plugin system? Maybe that would be a pain to support, but I think it could balance nicely between a 'preferred core' and custom features. Don't get me wrong though -- I think 'preferred core' features are far more important to establish and implement.
_________________
- nanou

Just to clarify, nothing in future updates will prevent the use of a custom arm7 core. We just feel that providing a more extensive and useful default core which includes dswifi and tracker based music support would be beneficial to the community and make example code a little easier to maintain.

We now have a decent FIFO communication layer in place which will be used to build an API for dswifi, audio and the power management features. As this progresses any code which depends on the IPC struct you've been asked not to use will fail. This seems to include pretty much every other audio library, PAlib and liblobby.

With liblobby specifically, the code is rather unstable and the method used for FIFO communication is quite horrible. We hope to provide similar functionality in the future but for now, it's best avoided.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

Sounds about right. Will everything the arm7 is truly needed for be implemented in an arm9-accessible way? I think that's a good goal if it will all fit.

About the plugins comment: will it be easy to swap out unneeded code for replacement code or will I have to perform surgery directly on the source file(s)? If it's easier than surgery, that's probably good enough in my opinion. Even better if the build system can exclude unneeded things without my interference.
_________________
- nanou

Just thought of something... will the music support include support for the PSG?
_________________
- nanou

wintermute wrote:

There are applications where mp3 playback is a good choice - video players and mp3 players spring to mind, but not in a DS game.

The fact is that games on the DS have been released that use MP3 and they run fine, so it seems like MP3 was a good choice for those programmers.

Many of the games written for the DS (commercial as well as homebrew) are not particularly processor or resource intensive, so even though MP3 is inefficient compared to tracked music, there's still plenty of resources and processor time available for it.

Personally, I like tracker music better, not because it's more efficient, but because it's more flexible. Unfortunately, the fact is that it's very difficult to find people willing or able to make music for a game in tracker formats. I showed ModPlug Tracker to a couple people I know who had offered to make music for my homebrew DS games, but they just sort of laughed at me. I'm sure there people out there who can do it, but they're a very small number and I don't know any of them, whereas I know lots of people who can make music in waveform formats. So, now that I can use MP3 music in my DS games thanks to aslib and the recent version of PAlib, I can go back to those same people and we can work together and make a game with original music.

That's a better situation, no matter how you look at it. More options for developers makes more things possible.

Quote:

This part we do agree on, thus the poll and the move towards higher level APIs in libnds itself. For my part, the primary motivation behind doing this would be to make it easier for users to choose libnds and never have to install PAlib.

That sounds great, but libnds is nowhere near that point of development yet, so in the meantime PAlib is still a very important tool for homebrewers like me who don't have the programming experience to use the current libnds and don't particularly have the inclination to learn it. I'm just a hobbyist who wants to make some games for my DS, I don't really want to waste my time mucking about with low level hardware stuff.

Quote:

Unfortunately I can't help feeling that PAlib is doing a great disservice to the homebrew community in it's current form. Advising users to stick with unsupported and outdated tools and surreptiously installing outdated and potentially broken libraries in place of official releases is unlikely to gain you much respect from the toolchain maintainers.

What you're referring to is a particular problem with PAlib at a particular point in time, not the way PAlib always has been or always will be. Shortly after dkA r21 came out, Mollusk abandoned the project for various more or less apparent reasons, so PAlib users were left with the choice of either sticking with the outdated toolchain or else trying to keep their head above water in libnds without the help of PAlib. It wasn't a good situation, but it's something that Tom and others in the PAlib community are now trying to address with the most recent community update to PAlib.

Am I wrong or doesn't the 080203-Community Update Beta version of PAlib operate on top of the standard dkA r21 and the most recent libnds just fine without any shennanigans? I haven't actually updated to it yet since I decided to get my current game working fully before updating and doing whatever re-writes are necessary, but I have the Community Update partially installed, just so that I can refer to it and it doesn't seem to install any outdated versions of libnds or anything like that. Are they built into the PAlib source itself or something?

nanou wrote:

Just thought of something... will the music support include support for the PSG?

I would assume so since the functions to operate the PSG are pretty basic and wouldn't take up much space at all in the ARM7 binary.

I don't know about using the PSG for music, though. I know there was a demo released a while back showing how to do it, but man...if finding people to compose MOD music for you is difficult, just try finding someone to compose PSG music! PSG is great for sound effects, though, especially if you want a retro type sound for your game.

...word is bondage...

Last edited by Sweater Fish Deluxe on Wed Mar 12, 2008 6:57 pm; edited 1 time in total

Sweater Fish Deluxe,

You perfectly expressed what I'm currently thinking too. Great post.

Michoko

Huh, that answered most of my questions too!
Any idea of how many people actually use PAlib? I've looked at the palib.info forums and they're quite small - would I correct in guessing that there isn't much of a PAlib scene? Or is there some other hub for development?
_________________
Big thanks to everyone who donated for Quake2

I feel quite comfortable with the libnds level of abstraction, and PALib so far seems to be very "dynamic".

(here goes my first post, :o)

I think PA and libnds have their issues, but atm I'd hands down use libnds as a base for any project.

PA suffers from a few things which bothers me atm including

- force usage of their modified libnds
- Fixed arrangement of Vram (already noted above).
- Bloat code syndrome (binaries are huge).
- lack of any clean memory management, its hard to properly manage resources when things get tight.
- Wrappering of stuff that doesn't need it.
- code from hell, looking through the code once gave me nightmares

Overall PA lib is good for those with limited technical knowledge or just want to get something simple working fast, but overall its a toy.

Libnds does have a few things I'd like to see cleaned up in future, a few of them are for me:

- clean, resource light sound system. libnds already has very simple sound playback abilities but if you want to control what sounds goto what channel or do channel allocation, you currently will need to throw out libnds's default arm7 binary.
- the "gl" texture code needs more work, lack of ability to free specific textures will be a stalling point for some people that use libnds. atm I'm sure most simply write their own gl texture management code which kind of defeats the point.
- MACROs wrapping registers in my book is A ok, in fact I prefer it over calling functions due to callstack overhead. So instead of focusing on wrapping those things with functions, I'd rather have good documentation in its place.

As for the .mod/xm vs mp3 for game music. I'd prefer that if libnds guys implement sound it would be a tracker format. For games mp3 requires more memory, more cpu time and the fact that most homebrew carts are painfully slow (some have a fit if you read more then 14kb per frame). you could include both but you get binary bloat again *shrugs*

Last edited by DensitY on Thu Mar 13, 2008 12:37 am; edited 1 time in total

DensitY wrote:

For games [streaming audio] requires more memory, more cpu time and the fact that most homebrew carts are painfully slow (some have a fit if you read more then 14kb per frame). you could include both but you get binary bloat again *shrugs*

14 KB per frame? MP3 or Vorbis at 32 kHz stereo needn't be bigger than 14 KB per second (112 kbps).

Tech-wise, what I want in the ARM9 side of a standard sound API are

Engine noise. A way to allocate voices and play sampled sound effects including loops on those voices, and alter their sample rate, volume, and pan as they loop.
A ring buffer that the ARM9 can feed so that an audio engine can use custom synthesized instruments (e.g. TB303 emulation, text to speech, or telephony).
PSG support is not that important on the DS where PSG channels override sampled channels, but it's still nice to have.

_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Just because your game is so low-CPU-usage that you can play MP3s in the background no problem doesn't mean you shouldn't still be concerned about the overhead involved. This is a handheld system, so higher CPU usage = shorter battery life.
_________________
I'm a PSP hacker now, but I still <3 DS.

Quote:

14 KB per frame? MP3 or Vorbis at 32 kHz stereo needn't be bigger than 14 KB per second (112 kbps).

that does take 230 bytes per frame alway from your streaming budget. agreed thats not much for a small game, but homebrew games like for example the quakeds port, those 230 bytes + time lost due to FAT fseek to stream that avg of 230bytes per frame for sound ontop of everything else could end up being a killer with some projects.

As an example, Wolfenstein 3D suffers no noticeable performance loss when decoding an 128kbps mono MP3 on the arm7.

However, the only reason I am using this format is because the original music cannot be played in it's native format since there is just not enough power to emulate the YM3812 chip in software on the arm7.

Newer projects should be using something else though if possible, streaming music this way is a huge pain.

simonjhall wrote:

Huh, that answered most of my questions too!
Any idea of how many people actually use PAlib? I've looked at the palib.info forums and they're quite small - would I correct in guessing that there isn't much of a PAlib scene? Or is there some other hub for development?

I would guess that the majority of homebrew developers on the DS are using PAlib. I just looked through my folder of favorite homebrew games and out of 48 games in there, only eight were made without PAlib, though I'm unsure about another five.

Of course, it depends on exactly what kind of development you're doing. People writing PC-like apps or emulators or doing ports or things like that definitely don't use PAlib as much (though I think PAlib has indeed been used with varying degrees of success for each of those things). However, for actual ground up game development on the DS, PAlib is perfect. That's what it was written for and I would say that probably 90% of the people writing games on the DS are using PAlib.

Unfortunately, as you pointed out, the English-speaking PAlib community is pretty small. These boards take up some of the slack, but they're not really oriented to the kind of development many homebrewers are interested in. It's the same breakdown that I just mentioned between game-oriented coding and more technical-oriented coding. Most of the discussions on this forum are not only over my head, but not very interesting to me even when I do understand them.

It makes me wish I had paid better attention in those French classes I took in high school because dev-fr and Player Advance are both very active and more game development oriented.

...word is bondage...

Sweater Fish Deluxe wrote:

PAlib is perfect.

No it isn't.

I'm trying to be diplomatic about this but PAlib is the single biggest cause of devkitARM support requests. The vast majority of these issues are solved by removing PAlib. The experienced developers aren't using PAlib and many who start off using it later wish they'd spent the time learning the actual hardware.

Here are a couple of telling remarks.

Quote:

I would say that probably 90% of the people writing games on the DS are using PAlib

yet

Quote:

the English-speaking PAlib community is pretty small

The solution to the discussions being over your head is to start new discussions that aren't. What's your biggest question about DS homebrew programming?

Don't be intimidated by the technical wizardry around here, there are many people only too happy to help a fledgling programmer.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

I think PAlib has grown too big without any real plan. That's why I didn't think about using it when starting DS development a couple of months ago. While it was tempting when I saw some of the things I'd have to do were already handled by PAlib functionality, I think it's much better to learn the hardware at a lower level when dealing with a platform such as the DS no matter what your programming experience.

Still, there's a good argument for higher-level libraries, though I think any further development on higher-level libraries should be more tightly focused on specific areas (say, audio, sprites, image loading, and so on), rather than one all-encompassing lib.

I also want to take a moment to thank everybody involved with the homebrew community (including PAlib contributors even if I don't make use of it) for making all this possible.

What do people think about giving better support to an established game library, such as SDL? I took GPF's port, took the fm-0.99 code which is Linux-based SDL, and was able to use it with minimum hassle.

There is surely a lot of improvement potential to make it more workable with the DS, but at least the "upstream" API is somewhat "proven".

There may be other good game APIs, I'm just using SDL as an example here because I had some success with it.

SDL based on libnds, or "naked" libnds, is most likely what I'll be using for projects in the near future. PALib just felt awkward, I can't pin it down any more detailed than that (although others have).

Of course there is a huge chasm likely on the DS:
2D vs. 3D. IMHO the vast majority of homebrew coders, especially beginners, will cut their teeth on 2D games (well, if they don't, they should ;-). If you're going 3D you may as well go Direct3D or OpenGL on a PC. 3D for the DS feels to me to be for veteran PC 3D coders who want a challenge (3D in 4M).

So this chasm will likely be reflected in any useable game library layer.

Of course, using a generic library like SDL will miss out some DS-specific features (or perhaps make assumptions about the hardware that the DS can't fullfil, such as a full-fledged keyboard). But I wonder if it wouldn't be easier to overcome those restrictions rather than work with an unstable API that seems to be (no offense, it is only my impression, as well as the what I glimpse from some veteran coders' expressions of opinion) maintained by people with either too little experience in API design, Embedded software, too little feel for beginners' needs or a combination of these and other factors.

If PALib intends to be the "DS Coding for Dummies" supply, it would need even more care and effort not to confuse the beginners or teach them bad style.

Again, I can't really judge the quality of PALib, because I haven't analysed it in detail, but I am an experienced developer and while I initially thought PALib would be the perfect thing to get started and dig deeper only later, I was quickly put off the lib and at the moment use libnds exclusively.

wintermute wrote:

Sweater Fish Deluxe wrote:

PAlib is perfect.

No it isn't.

Talk about a misquote. You'd make a great reporter for like People magazine or something.

Quote:

I'm trying to be diplomatic about this but PAlib is the single biggest cause of devkitARM support requests. The vast majority of these issues are solved by removing PAlib. The experienced developers aren't using PAlib and many who start off using it later wish they'd spent the time learning the actual hardware.

PAlib is the single biggest cause of dkA support requests because, as I said, the majority of people developing on the DS are using it. And in particular, a huge majority of beginning programmers (who are also the most likely to request support obviously) are using it since libnds doesn't provide a very good entry point for someone with little or no experience (see: no documentation, very few and not very good examples, source not included with the dkA distribution, etc.). Your solution to these people's problems may just be for them to stop using PAlib, but there are in fact other solutions which are probably more amenable to the disposition of the person with the problem.

Understanding dynamics like this is the key to being diplomatic, by the way.

In the future, why not kindly direct people to palib.info when they have a problem that you think would be best solved by ditching PAlib. People over there who have more experience using PAlib than you may be able to suggest other alternatives. That would be more helpful to the person with the problem and it will also be helpful to the PAlib community, eh?

Quote:

Here are a couple of telling remarks.

Quote:

I would say that probably 90% of the people writing games on the DS are using PAlib

yet

Quote:

the English-speaking PAlib community is pretty small

Do you think that's a contradiction? I would say the dev scenes for the DS aremuch more active in Europe than they are in the U.S. or English speaking countries generally. That's not unusual, it's been my experience in most homebrew scenes. I also think that many people are using PAlib without posting very often to palib.info. Many of them post here on these forums, for instance.

Quote:

The solution to the discussions being over your head is to start new discussions that aren't. What's your biggest question about DS homebrew programming?

Don't be intimidated by the technical wizardry around here, there are many people only too happy to help a fledgling programmer.

I don't think I really have any big questions about DS programming. For the most part I'm able to do all the things I want to do and when things I'm unable to do come up, I have been able to solve them myself or get help at palib.info

What I would like is a place to discuss more conceptual elements of game design and aesthetics, but specifically tailored to DS homebrew. The Homebrew Announcements forum suits that purpose to an extent since the best way to discuss those things is in relation to an existing game.

...word is bondage...

Sweater Fish Deluxe wrote:

And in particular, a huge majority of beginning programmers (who are also the most likely to request support obviously) are using it since libnds doesn't provide a very good entry point for someone with little or no experience (see: no documentation, very few and not very good examples, source not included with the dkA distribution, etc.).

I second the request for a source package corresponding to each release of newlib, libnds, libfat, dswifi, and other libraries. I think I requested it before on SF.net, but it got shot down as won't fix any time soon.

Quote:

In the future, why not kindly direct people to palib.info when they have a problem that you think would be best solved by ditching PAlib.

I don't know, but part of me wants to draw an analogy to when SimonB changed the forum rules in May 2006. Until then, some forum members had habitually been referring warez kiddies to another phpBB 2 forum that uses the same default subSilver theme that gbadev.org uses but has a much more open policy about discussion of warez, the idea being that it gets the warez kiddies out of our hair. But after the change to the rules, forum members were no longer allowed to do this. Likewise, in this case, the underlying goal might not be to help PAlib users find PAlib resources but instead to encourage people to stop using PAlib at all.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

I don't know, but part of me wants to draw an analogy to when SimonB changed the forum rules in May 2006. Until then, some forum members had habitually been referring warez kiddies to another phpBB 2 forum that uses the same default subSilver theme that gbadev.org uses but has a much more open policy about discussion of warez, the idea being that it gets the warez kiddies out of our hair. But after the change to the rules, forum members were no longer allowed to do this. Likewise, in this case, the underlying goal might not be to help PAlib users find PAlib resources but instead to encourage people to stop using PAlib at all.

I didn't make that suggestion as a way for wintermute to get kiddies out of his hair, but simply as the most effective way of providing support in some cases.

As I've been trying to point out here, different people have different desires, goals and expectations when it comes to homebrew development. For some people, PAlib undeniably is the better choice whether that fact makes wintermute happy or not. Telling those people to stop using PAlib is not an effective way of providing support. I doubt it's an effective way of getting kiddies out of his hair, either, for that matter.

...word is bondage...

*checks API listing* SDL is a lot like DirectDraw, right? Set color keys, blit surfaces around, flip the buffers, rinse, repeat. Unfortunately, the DS doesn't work this way. Non-2^N texture is not supported. Nor are surface-to-surface blits, in any meaningful sense.

Now sure, you could do software blits. I'm porting a DirectDraw game, a sort of retro platformer. And the first thing I did (for curiosity and debugging) was write a mini-DirectDraw. It worked great.

It also ran 10-20fps... with moderate optimization. The DS isn't meant to do that. ;)

What I settled on was a hack. The game/art assets were SO tied to these "surfaces" that I split them up into 2^N wide texture strips, and "blit" them using the 3D engine. Then I did away with the code needing framebuffer copies and surface-to-surface. Much happier now. Perhaps an SDL could be done this way, but it would have disappointing limitations, as it's just working against the grain. I don't think you can really hide that, and IMHO new games, would get far more mileage with a DS specific library.

Anyway, am I the only one who finds the DS hardware inspiring? A lot of the registers are already incredibly high level. How is OR'ing a few bits in FOO_CR any different than calling setFoo*()? The real functionality I've had to build, is not so much that, but more abstract things like sprite, tile and texture allocation, bitmap fonts on custom/sparse tilemaps, UI events and object updates, power policy, messaging and synchronization, music and voice management... stuff on top.

I have to say PALib looks a bit (okay, alarmingly...) ad-hoc and disorganized for me. It seems to make assumptions about hardware state, but I can't tell what those are because they don't appear to be documented. I have a specific gfx setup and can't afford any helpful "adjustments", so that alone is a dealbreaker. If the API page is any indication, it is also missing some things listed above.

Re: MP3, what I'd like to know is what you do when an MP3 frame (some 1-2k samples--longer than a video frame) takes more than ~5-10ms to decode! The ARM is fast enough, but there's a latency problem, and Helix doesn't appear to do smaller units. Fine for a media player, but not an action game... :b

Sweater Fish Deluxe wrote:

PAlib is the single biggest cause of dkA support requests because, as I said, the majority of people developing on the DS are using it.

No, it's the single biggest cause of dkA support requests because it breaks the toolchain. It causes problems because people with a rather optimistic opinion of their own competence insist on handing out bad advice. People much like you in fact.

http://www.apa.org/journals/features/psp7761121.pdf

Quote:

In the future, why not kindly direct people to palib.info when they have a problem that you think would be best solved by ditching PAlib. People over there who have more experience using PAlib than you may be able to suggest other alternatives. That would be more helpful to the person with the problem and it will also be helpful to the PAlib community, eh?

Because the vast majority of the members of the PAlib community are idiots. They're digging a huge hole for would be DS programmers that most of them will never be able to find their way out of.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

Cydrak wrote:

*checks API listing* SDL is a lot like DirectDraw, right? Set color keys, blit surfaces around, flip the buffers, rinse, repeat. Unfortunately, the DS doesn't work this way. Non-2^N texture is not supported. Nor are surface-to-surface blits, in any meaningful sense.

Now sure, you could do software blits. I'm porting a DirectDraw game, a sort of retro platformer. And the first thing I did (for curiosity and debugging) was write a mini-DirectDraw. It worked great.

It also ran 10-20fps... with moderate optimization. The DS isn't meant to do that. ;)

This brings up something else rather interesting actually.

While SDL is eminently unsuitable for DS programming it does happen to be a well established cross platform API. If you start a DS game using SDL then eventually you're going to have to replace it with something more suited to the underlying hardware but, unlike PAlib, you'll have learned something about a library in widespread use on a vast number of platforms.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

tepples wrote:

Sweater Fish Deluxe wrote:

And in particular, a huge majority of beginning programmers (who are also the most likely to request support obviously) are using it since libnds doesn't provide a very good entry point for someone with little or no experience (see: no documentation, very few and not very good examples, source not included with the dkA distribution, etc.).

I second the request for a source package corresponding to each release of newlib, libnds, libfat, dswifi, and other libraries. I think I requested it before on SF.net, but it got shot down as won't fix any time soon.

I just checked, and source for libnds, libfat, dswifi, and newlib were all pretty easy to find on sourceforge. Sure they aren't put on the front page in big bold letters like the installer is, but the average person doesn't need the source to these, so it's better to not confuse them.

Sweater Fish Deluxe wrote:

And in particular, a huge majority of beginning programmers (who are also the most likely to request support obviously) are using it since libnds doesn't provide a very good entry point for someone with little or no experience (see: no documentation, very few and not very good examples, source not included with the dkA distribution, etc.).

Distributing source doesn't necessarily make things better. Putting the toolchain source in the hands of PAlib people is like giving a nuclear reactor to a group of rednecks. It still works but nobody around knows how to use it properly.

In all honesty, though, the source is available for those who take the effort into finding it. What I find interesting, however, is the same people complaining about the toolchain's lack of documentation are the same people requesting source.

Again, risks flame war :-)

Although I think libnds combined with the stock DKA install is light years ahead of what PAlib seems to offer I don't think it's perfect. I certainly don't wanna piss anyone off here (as my code is normally crap despite being a programmer in the games biz), but libnds itself seems to often be a moving target, esp the 3D subsystem.

Just today I upgraded the Q1 source from r20 to r21 (Q2 is built on r21, btw), shut my eyes and jabbed compile. Of couse it didn't build, some functions have been removed, some functions have been renamed - but nothing major (as I did read the release notes). Once it did build, it randomly locked up. Ah right, glGenTextures will hang after a few calls if the new glInit function has not been called. Good job I'd written a debugger that allowed me to discover this within minutes.

I dunno what I'm angling for here or who this is directed at, but could we get some kind of error checking, asserts or whatever in the library? I think because libnds is maintained by just a few people (?) on a completely different site and it comes with the toolchain we assume we're not allowed to modify it. If we find bugs or useful modifications, these bugs often linger as hacks and are not integrated and if they are released to the world they're often labelled as 'unofficial' and steadily get older compared to the latest code. (Granted if anyone could check in new code willy-nilly we'd be dead in a flash, and would need some auditing system.)

It almost seems as if the development of the toolchain and the libnds that accompanies it are decided by this invisible force when the decisions should really be influenced by feedback from the people who use it the most.

Unless I've missed some big fat libnds development forum somewhere...

(again, I don't wanna piss anyone off - I just want to help develop the toolchain and in particular offer taking the load off wintermute)
_________________
Big thanks to everyone who donated for Quake2

simonjhall wrote:

I dunno what I'm angling for here or who this is directed at, but could we get some kind of error checking, asserts or whatever in the library?

Error checking is hard to do in the lower-level interface, which may be just providing you a pointer to a u32 which you are flipping bits in. However, the new higher-level stuff dovoto is working on for sprites / backgrounds includes a bunch of assert()'s that i've noticed, if you pass invalid parameters or something.

Quote:

I think because libnds is maintained by just a few people (?) on a completely different site and it comes with the toolchain we assume we're not allowed to modify it. If we find bugs or useful modifications, these bugs often linger as hacks and are not integrated and if they are released to the world they're often labelled as 'unofficial' and steadily get older compared to the latest code. (Granted if anyone could check in new code willy-nilly we'd be dead in a flash, and would need some auditing system.)

I've made a few (admittedly very minor) changes to libnds, i posted them as patches to the SF tracker, and they got applied to the next release of libnds. I think this is the recommended way of getting your changes into libnds. Of course if you start making tons of changes/additions, and they are all great, the project maintainers are likely to let you commit directly.

simonjhall wrote:

Again, risks flame war :-)

Although I think libnds combined with the stock DKA install is light years ahead of what PAlib seems to offer I don't think it's perfect. I certainly don't wanna piss anyone off here (as my code is normally crap despite being a programmer in the games biz), but libnds itself seems to often be a moving target, esp the 3D subsystem.

Just today I upgraded the Q1 source from r20 to r21 (Q2 is built on r21, btw), shut my eyes and jabbed compile. Of couse it didn't build, some functions have been removed, some functions have been renamed - but nothing major (as I did read the release notes). Once it did build, it randomly locked up. Ah right, glGenTextures will hang after a few calls if the new glInit function has not been called. Good job I'd written a debugger that allowed me to discover this within minutes.

I dunno what I'm angling for here or who this is directed at, but could we get some kind of error checking, asserts or whatever in the library? I think because libnds is maintained by just a few people (?) on a completely different site and it comes with the toolchain we assume we're not allowed to modify it. If we find bugs or useful modifications, these bugs often linger as hacks and are not integrated and if they are released to the world they're often labelled as 'unofficial' and steadily get older compared to the latest code. (Granted if anyone could check in new code willy-nilly we'd be dead in a flash, and would need some auditing system.)

It almost seems as if the development of the toolchain and the libnds that accompanies it are decided by this invisible force when the decisions should really be influenced by feedback from the people who use it the most.

Unless I've missed some big fat libnds development forum somewhere...

(again, I don't wanna piss anyone off - I just want to help develop the toolchain and in particular offer taking the load off wintermute)

Implementing a proper/better (not sure if one exists actually lol) submission process for libnds modifications might be the way to go.

I think wintermute's core complain isn't so much PA modifying libnds and distributing it, its more that they do that and overwrite the programmer's libnds files vs storing changes in their own code.

in the project I'm working on, 3d stuff (default texture code = grr) in libnds is rarely used, rest of it is new code we decided to include in our binary vs hacking up libnds.

neither libnds or PAlib is perfect, but if both teams working on those libraries implement a submission path and seriously consider those submissions we'd end up with better base libraries.

simonjhall wrote:

Again, risks flame war :-)
I dunno what I'm angling for here or who this is directed at, but could we get some kind of error checking, asserts or whatever in the library?

Recently I've been considering providing debug & release versions of libnds. Personally I like to avoid asserts in production code which is mainly why there isn't a lot of error checking in there.

Quote:

Unless I've missed some big fat libnds development forum somewhere...

This is something that we need, I've mentioned this in a couple of devkitpro posts and recently added it to the links in the sidebar.

http://forums.devkitpro.org

The forums are intended for discussion of toolchain and support library issues and hopefully provide a feedback mechanism where we actually notice the posts. This little community is fantastic but toolchain & library related things tend to get drowned out a little.

Quote:

(again, I don't wanna piss anyone off - I just want to help develop the toolchain and in particular offer taking the load off wintermute)

Muhahaha, you might regret saying that ;)

There are a few things I need to get in place - documenting the submissions and bug reporting processes would be two of many. Both are exactly the same as any other SF based project but devkitPro is rapidly becoming a victim of it's own success ( downloads of the installer are hovering around 6k a month - o_O ).

Any help you can offer would be greatly appreciated.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

wintermute wrote:

This is something that we need, I've mentioned this in a couple of devkitpro posts and recently added it to the links in the sidebar.

http://forums.devkitpro.org

The forums are intended for discussion of toolchain and support library issues
[...]
Any help you can offer would be greatly appreciated.

How about posting a sticky link from one of the forums here?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

How can developers help out with devkitARM and libnds?

wintermute wrote:

Cydrak wrote:

*checks API listing* SDL is a lot like DirectDraw, right? Set color keys, blit surfaces around, flip the buffers, rinse, repeat. Unfortunately, the DS doesn't work this way. Non-2^N texture is not supported. Nor are surface-to-surface blits, in any meaningful sense.

Now sure, you could do software blits. I'm porting a DirectDraw game, a sort of retro platformer. And the first thing I did (for curiosity and debugging) was write a mini-DirectDraw. It worked great.

It also ran 10-20fps... with moderate optimization. The DS isn't meant to do that. ;)

This brings up something else rather interesting actually.

While SDL is eminently unsuitable for DS programming it does happen to be a well established cross platform API. If you start a DS game using SDL then eventually you're going to have to replace it with something more suited to the underlying hardware but, unlike PAlib, you'll have learned something about a library in widespread use on a vast number of platforms.

Is it unsuitable for DS programming _in_principle_? Or is it just that that there hasn't been any interest in extending some of the abstractions so that DS-specific features could be supported?

It would need the SDL maintainers' interest to embrace the DS, and DS coders' interest to provide the extensions, which may be too much to hope for. But are you saying the SDL is unsuited from a _conceptual_ point of view? Are you saying that any of the established libraries are unsuited in this way?

About the old PAlib version overwriting libnds:
I think the reason why Mollusk included the libnds files were some ndsmotion fixes from CVS. They shouldn't be neccessary for PAlib to work, so we'll remove the files from the archives to prevent further problems due to them. It could take some time, however, because we also have to update the installer (and therefore we must get its sources from Mollusk first).
_________________
<dsFont> <Game Collection>

nczempin wrote:

Is it unsuitable for DS programming _in_principle_?

Yes. SDL gives you a dumb framebuffer as the output, and assumes that blitting (copying) surfaces around can be done fairly fast. The DS is quite the opposite, it provides lots of hardware 2D functions like a tile engine, various layers, sprites, etc, none of which fit into how SDL works. In addition, the DS isn't fast enough that you can just blit around a ton of gfx willy nilly without using the specialized hardware functionality

Quote:

It would need the SDL maintainers' interest to embrace the DS, and DS coders' interest to provide the extensions, which may be too much to hope for. But are you saying the SDL is unsuited from a _conceptual_ point of view? Are you saying that any of the established libraries are unsuited in this way?

The 'extensions' however would be so different from SDL that there is really no point to making them part of SDL. And it would kill the crossplatform aspect of SDL as well, so you'd be better off writing the 'extensions' as a standalone library that doesn't interface with SDL.

josath's answer is perfect, and on another note also highlights why I think it makes more sense for beginners to learn libnds directly rather than PAlib - the DS is a platform where you really need to work to the hardware in order to get good performance for all but the simplest projects.

Again, I want to point out that I am a newcomer to DS development, this isn't some longtime dev looking down his nose at people who use PAlib. My point is that I have the same information and documentation as any other newcomer, but I still find myself siding with wintermute's arguments.

SiW wrote:

Again, I want to point out that I am a newcomer to DS development, this isn't some longtime dev looking down his nose at people who use PAlib. My point is that I have the same information and documentation as any other newcomer, but I still find myself siding with wintermute's arguments.

Well, wintermute's argument may be that no one should use PAlib, but that certainly doesn't mean that I take the diametrically opposed argument that everyone should use PAlib. Like I said in my first post, both libnds and PAlib have their strengths and weeknesses.

My suggestion for anyone coming to do homebrew on the DS, whether they're an experienced coder or not, is that they look at all the available tools, including not just libnds and PAlib, but also mLib and ds-lua and every other option or even possibly no lib at all. Look at all those options and see what best suits your needs. Some people will choose libnds, some will choose PAlib, some will choose lua, etc. There's a wide variety of tools available to meet a wide variety of needss. That's a good situation. It makes for a more diverse scene.

And the decision you make is never final, either. You can always change to another lib or tool if you find that what you're using isn't meeting your needs. It's really a pretty simple concept, I don't know why wintermute can't comprehend it.

...word is bondage...

wintermute wrote:

simonjhall wrote:

So, [risks flame war] what is it that's wrong with the PAlib distro? I don't mean what's wrong with the actual code/messiness/OOness/whatever: if I install PAlib, how will it mess up my DKA installation?

The PAlib installer overwrites the official libnds install with a version not compatible with devkitARM r21 or the forthcoming r22. PAlib itself depends on code in libnds which was incomplete and in the process of being updated. This will eventually lead to a situation where you either have to dispense with PAlib or never update your toolchain again.

We do intend to provide code to wrap the 2D hardware a lot more, see the devkitPro forum thread linked to earlier in the discussion.

I disagree with that. I'm quite used to using PAlib and libnds and you can easily update libnds and usually DKA without breaking your PAlib installation. Have you asked Mollusk or other people on the PAlib team to stop distributing libnds with PAlib, so that people would be more inclined to using updated versions, so they are not afraid of messing up their PAlib installations?
_________________
Development Blog: http://teendev.org
Homebrew Podcast: http://homebrewcast.net
Web Design: http://xtendesign.net

tondopie wrote:

I disagree with that. I'm quite used to using PAlib and libnds and you can easily update libnds and usually DKA without breaking your PAlib installation.

Come back & tell me that after r22 and the subsequent libnds update.

Quote:

Have you asked Mollusk or other people on the PAlib team to stop distributing libnds with PAlib, so that people would be more inclined to using updated versions, so they are not afraid of messing up their PAlib installations?

Mollusk has gone, I've asked others, the installer is still there.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

tepples wrote:

wintermute wrote:

This is something that we need, I've mentioned this in a couple of devkitpro posts and recently added it to the links in the sidebar.

http://forums.devkitpro.org

The forums are intended for discussion of toolchain and support library issues
[...]
Any help you can offer would be greatly appreciated.

How about posting a sticky link from one of the forums here?

I'll ask Simon permission first, I have a couple of things I want to get in place too.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

Lazy1 wrote:

How can developers help out with devkitARM and libnds?

I'm going to write up a definitive guide to this at some point for the devkitPro wiki. In the meantime we've put up a list of project ideas for GSoC which might be of general interest to anyone wanting to help out.

http://www.devkitpro.org/devkitpro/google-summer-of-code/
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

Huh, interesting stuff. I know which projects I'd take on there! Mentoring sounds entertaining, too.
_________________
Big thanks to everyone who donated for Quake2

wintermute wrote:

Lazy1 wrote:

How can developers help out with devkitARM and libnds?

I'm going to write up a definitive guide to this at some point for the devkitPro wiki. In the meantime we've put up a list of project ideas for GSoC which might be of general interest to anyone wanting to help out.

http://www.devkitpro.org/devkitpro/google-summer-of-code/

Hmm, that's a bit like what I wanted for my wishlist, a list of potentially useful projects for the DS (although mine includes games, "useful" only in a general sense ;-).

Out of my own wishlist, currently I feel most excited about a flight sim and a synthesizer.

It seems that for the synth I have to spend most time on the ARM7 to get anything useful; perhaps something good for any audio enhancements of the default code will come out of it (although that is not my main goal, at least I can keep it in mind).

nczempin wrote:

Out of my own wishlist, currently I feel most excited about a flight sim and a synthesizer.

Help wanted on my flight simulator...

ecurtz wrote:

nczempin wrote:

Out of my own wishlist, currently I feel most excited about a flight sim and a synthesizer.

Help wanted on my flight simulator...

I'll answer there...

Sweater Fish Deluxe wrote:

As I've been trying to point out here, different people have different desires, goals and expectations when it comes to homebrew development.

Excellent way of saying it. Not everyone cares about the hardware. Believe it or not, some people just want to write a game/app..

wintermute wrote:

Because the vast majority of the members of the PAlib community are idiots.

Nice.. At least the name calling took till the second page of posts.. Now, when you reference community, does that include anyone that has used PAlib (such as myself), or those that actively participate on the forums?

BigRedPimp wrote:

Putting the toolchain source in the hands of PAlib people is like giving a nuclear reactor to a group of rednecks. It still works but nobody around knows how to use it properly.

Wow.. the hostility is really starting to shine..

Sweater Fish Deluxe wrote:

My suggestion for anyone coming to do homebrew on the DS, whether they're an experienced coder or not, is that they look at all the available tools, including not just libnds and PAlib, but also mLib and ds-lua and every other option or even possibly no lib at all. Look at all those options and see what best suits your needs. Some people will choose libnds, some will choose PAlib, some will choose lua, etc. There's a wide variety of tools available to meet a wide variety of needss. That's a good situation. It makes for a more diverse scene.

Sounds like a reasonable request. I don't know why others seem to have a "MY WAY is the ONLY WAY" approach when it comes to tools and techniques.
_________________
NDS Homebrew Roms & Reviews

Lynx wrote:

Sweater Fish Deluxe wrote:

As I've been trying to point out here, different people have different desires, goals and expectations when it comes to homebrew development.

Excellent way of saying it. Not everyone cares about the hardware. Believe it or not, some people just want to write a game/app..

But there are ways and means to make that easier which avoid common problems. Many of the methodologies being recommended by certain people are known to be the source of issues which lead inevitably to demotivation and/or dysfunctional code.

Quote:

wintermute wrote:

Because the vast majority of the members of the PAlib community are idiots.

Nice.. At least the name calling took till the second page of posts.. Now, when you reference community, does that include anyone that has used PAlib (such as myself), or those that actively participate on the forums?

I have other personal issues with you in particular, this post illustrates one of them. Posting in defence of someone who steers novices towards a path of eventual failure is hardly a good way to help the community.

Quote:

BigRedPimp wrote:

Putting the toolchain source in the hands of PAlib people is like giving a nuclear reactor to a group of rednecks. It still works but nobody around knows how to use it properly.

Wow.. the hostility is really starting to shine..

and here we illustrate another. Drawing attention to statements that could perhaps have been more tactfully written and emphasising the negative.

Quote:

Sweater Fish Deluxe wrote:

My suggestion for anyone coming to do homebrew on the DS, whether they're an experienced coder or not, is that they look at all the available tools, including not just libnds and PAlib, but also mLib and ds-lua and every other option or even possibly no lib at all. Look at all those options and see what best suits your needs. Some people will choose libnds, some will choose PAlib, some will choose lua, etc. There's a wide variety of tools available to meet a wide variety of needss. That's a good situation. It makes for a more diverse scene.

Sounds like a reasonable request. I don't know why others seem to have a "MY WAY is the ONLY WAY" approach when it comes to tools and techniques.

And here you highlight your particular interpretation of what's happening. Your whole post leads to the conclusion that the OP is actually someone whose advice novices should pay attention to and that's blatently not the case.

This isn't about one person's way over another. This is about correcting the poor advice being handed out.

Unfortunately this thread appears to be turning into a bike shed.

http://a.mongers.org/clueful/1999-phk-bikeshed
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

I think I've figured out why there's so much disagreement over PAlib.

There's various distinctions between different types of coders that can be made in any homebrew community, but perhaps one of the most important is that between autistic coders and manic (or bipolar) coders. Having spent a lot of time following homebrew on various platforms over the years, I know that those two personality types are over-represented among homebrewers (probably programmers in general) and also that those two groups are--each in different ways--the real driving forces behind homebrew.

Mollusk (and therefore PAlib) seems more on the manic side since he produces a lot of code and it's messy and even has errors in it sometimes. On the other hand, I would say that wintermute is more of an autistic type, which maybe explains why he can't grasp this idea of people having different reasons why they want to create homebrew.

Autistics will be uncomfortable with manic behavior and manics will rebel against autistic behavior. It's just a basic incompatibility.

Therefore, I change my suggestion as stated earlier. I now suggest that anyone coming to homebrew decide at the outset whether they would prefer to be manic or autistic and select their tools based on that decision. Unlike the other decision about what your needs are, this decision is completely irrevocable. Once you choose to be either autistic or manic, there's no going back (without some serious drugs at least), so choose wisely!

...word is bondage...

Quote:

Sweater Fish Delux Says: Words Words Words

I hope thats a joke, cause otherwise thats the biggest load of horseshit I've ever read. o_O

---

In all seriousness the issue here is that PAlib installs BREAKING the official release of the library it was based on is *bad behavior* and I'm glad its been addressed.

( I'd be bitter too if I had other people making more work for me, especially when that work is "tech support for someone elses product"! )

The simple truth of the matter is that PALIB is (wobbly) training wheels for new developers: More experienced programmers should be starting with libnds.

Sweater Fish Deluxe wrote:

said some stuff that makes no sense to me, psychology reasonings for picking an SDK is just.. yeah..

People will pick SDK based on if they are capable of understanding the DS architecture or need someone to handle the low level side it for them. or if the person just wants something done stupidly fast

wintermute wrote:

But there are ways and means to make that easier which avoid common problems. Many of the methodologies being recommended by certain people are known to be the source of issues which lead inevitably to demotivation and/or dysfunctional code.

But, as I have said before, it's much easier to say something is complete shit than to take on the task of either A) replacing it with something you feel isn't shit, or B) helping to make it not be shit. I tell that to Liranuna all the time. He hates PAlib, but unless he provides something better, or attempts to make PAlib better, I couldn't care less of his opinion towards PAlib. Anyone can sit on a pedestal and tell everyone what is wrong, it takes a real man to do something about it!

Quote:

I have other personal issues with you in particular, this post illustrates one of them. Posting in defence of someone who steers novices towards a path of eventual failure is hardly a good way to help the community.

Well, I guess your an idiot! (for point only, I don't really believe that) How does me saying that help in any way in this conversation? Your right, it doesn't.. but that is exactly what you did, you called me an idiot for no reason. There are a few PAlib based games that I feel are excellent games. I love WordUP and believe it's better than a lot of non-PAlib homebrew. But, that doesn't mean I think PAlib makes for better games, or that non-PAlib makes for better games. No matter what libraries you use, it all depends on the coder.

Quote:

and here we illustrate another. Drawing attention to statements that could perhaps have been more tactfully written and emphasising the negative.

Name calling is name calling no matter how you put it. What I don't understand his how "you guys" seem to go strait to this kind of thing. I understand that the Internet provides a realm of anonymity (sp) and that people tend to feel they must strike out to make a point. But, it both cases the statements were uncalled for. Yet, I'm the one making a fuss because I was called an idiot and a hillbilly. What part of being NICE do you not understand? What part of RESPECT do you not understand? There is no need for it, and I don't accept it. People need to grow up!

Quote:

And here you highlight your particular interpretation of what's happening. Your whole post leads to the conclusion that the OP is actually someone whose advice novices should pay attention to and that's blatently not the case.

This isn't about one person's way over another. This is about correcting the poor advice being handed out.

But, who makes the call if it's poor advice or not?

Don't get me wrong, I'm not saying PAlib is the answer to everything, and you must use it for homebrew deving on the DS. I'm just saying, if you don't want to learn the hardware at all, it is an option, and until something comes along that is better, with the ease of PAlib, I will continue to state that fact.

For some reason, there always has to be sides. And in this case, I am not on either side. I choose to use PAlib and that is my choice. Others may make that same choice, and that is up to them. I feel I have supported you (and the DevkitPro toolchain) and the PAlib equally, even if you don't see it that way.
_________________
NDS Homebrew Roms & Reviews

Lynx wrote:

But, as I have said before, it's much easier to say something is complete shit than to take on the task of either A) replacing it with something you feel isn't shit, or B) helping to make it not be shit. I tell that to Liranuna all the time. He hates PAlib, but unless he provides something better, or attempts to make PAlib better, I couldn't care less of his opinion towards PAlib. Anyone can sit on a pedestal and tell everyone what is wrong, it takes a real man to do something about it!

But we are doing something about it. Earlier in the thread you might have seen reference to the higher level libnds functions currently in progress. With every devkitPro toolchain and support library release we get ever closer to something that provides most of the features a homebrew programmer could desire. We don't claim perfection but we've come a long way over the last 5 years.

Quote:

I have other personal issues with you in particular, this post illustrates one of them. Posting in defence of someone who steers novices towards a path of eventual failure is hardly a good way to help the community.

Well, I guess your an idiot! (for point only, I don't really believe that) How does me saying that help in any way in this conversation? Your right, it doesn't.. but that is exactly what you did, you called me an idiot for no reason.

Read what I said again. I didn't call you an idiot, I have issues with you.

Quote:

But, who makes the call if it's poor advice or not?

The experienced developers who frequent these boards.

Here's the thing. It's not PAlib or the abstraction I take issue with - it's the underlying design, much of the code, the random choice of unstable libraries issued with the library and tutorials that break several cardinal rules of programming.

We're trying hard to take devkitARM and libnds in a direction that allows for "RAD" but doesn't make experienced developers cringe. In my opinion PAlib is beyond saving, we may have to just agree to disagree on that point but I will continue to correct poor advice I see on these forums.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

wintermute wrote:

But we are doing something about it. Earlier in the thread you might have seen reference to the higher level libnds functions currently in progress

That's great, but until it's mature, what does it mean to me or other PAlib users?

wintermute wrote:

Read what I said again. I didn't call you an idiot, I have issues with you.

With my response to the following:

wintermute wrote:

Because the vast majority of the members of the PAlib community are idiots.

Oh.. so I'm to guess that I'm outside the vast majority.. \o/ yeah for me!

Seriously, am I the one that can't grasp the concept of name calling? Does it really have a use that I just can't understand? Wouldn't it have been just as easy and probably even more correct to have said, "Because the vast majority of the members of the PAlib community are inexperienced."

Quote:

Lynx wrote:

But, who makes the call if it's poor advice or not?

The experienced developers who frequent these boards.

So, your saying that even experienced developers always agree on coding models? So, which model is "right"? Richard Stallman's or Linus Torvalds'? Which one is the "experienced" developer? Just like when you interchange the word "Embedded programming" with "Handheld game console programming". Until you've worked on a few $180,000 embedded systems, I don't think you'll understand the difference.

Quote:

We're trying hard to take devkitARM and libnds in a direction that allows for "RAD" but doesn't make experienced developers cringe. In my opinion PAlib is beyond saving, we may have to just agree to disagree on that point but I will continue to correct poor advice I see on these forums.

That's fine, please continue. But, I will also point out childish/disrespectful behavior.. I guess you can call me a parent like that. I don't tolerate it from my 3 yr. old or 20 mo. old and I won't tolerate it on here either. I don't hide the fact that I suck as a programmer and never will. If it wasn't for PAlib, I couldn't produce colored backgrounds. But, just because I can't grasp the concepts of programming doesn't mean I deserve any less respect than anyone else in the homebrew community or that visits these forums. Or that "idiots" in the PAlib community deserve any less respect either. Everyone was a beginner at some time, and not everyone has the time or drive to learn the DS hardware to the point needed to understand the current alternative to not using PAlib.

I understand one of your issues with me is that I point out such childish behaviors, but if people would stop acting like children, I wouldn't have anything to point out, and that would be one less squabble you have with me.
_________________
NDS Homebrew Roms & Reviews

Lynx wrote:

wintermute wrote:

But we are doing something about it. Earlier in the thread you might have seen reference to the higher level libnds functions currently in progress

That's great, but until it's mature, what does it mean to me or other PAlib users?

Perhaps nothing. For the future it may mean that PAlib users will become increasingly unable to use the latest devkitARM.

Quote:

Seriously, am I the one that can't grasp the concept of name calling? Does it really have a use that I just can't understand? Wouldn't it have been just as easy and probably even more correct to have said, "Because the vast majority of the members of the PAlib community are inexperienced."

Have you perhaps considered that it's not just "name calling"?
Inexperienced is one thing, writing tutorials that repeatedly make the same fundamental errors is quite another. Attempting to override the toolchain libraries in what seems to be a bid to delay updating the code for the latest changes seems rather foolish to me.

Quote:

So, your saying that even experienced developers always agree on coding models? So, which model is "right"? Richard Stallman's or Linus Torvalds'? Which one is the "experienced" developer?

Stallman & Torvalds differ on project management models, some of their design philosophies and their political motivation. Present PAlib and the associated tutorials to either of those individuals and you'll find they'll rip it to shreds for much the same reasons.

Quote:

Just like when you interchange the word "Embedded programming" with "Handheld game console programming". Until you've worked on a few $180,000 embedded systems, I don't think you'll understand the difference.

Hmm.

webpage wrote:

An embedded system is a special-purpose computer system designed to perform one or a few dedicated functions

webpage wrote:

Physically, embedded systems range from portable devices such as digital watches and MP3 players, to large stationary installations like traffic lights, factory controllers, or the systems controlling nuclear power plants

My local University also uses the GBA as part of one of it's embedded systems programming courses. I'm pretty sure the price of the system has little relevance.

Still, I now regret starting this thread at all so I'm going to unsubscribe from it and go do something more productive. It's becoming increasingly obvious that little more good is going to come from this discussion.

There are some real nuggets buried amongst the noise, I can only hope that others reading the thread can pick them out.

http://forum.gbadev.org/viewtopic.php?p=152253#152253 in particular and the SDL related portions of the thread.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

I can pick out the sense, but I doubt everyone else will. Choice isn't always good if a vast majority of newcomers lack the knowledge to truly comprehend the decision.

You don't pick modules in primary school because you are not equipped to make that decision, we spend the first 11 years of our public education following a curriculum that differs only in small areas.

When presenting a user with a choice or recommendation in a small community we want the least amount of "buts". As for what I personally think, I think the entire library-developing-type should be working together. We would be a much stronger community if we could just say, "this is what you use for DS development", not, "erm, well, you could choose @@@ or ### because @@@ is for %%% and ### is for $$$". Especially if one group lacks experience, should they not be learning from the experienced and being mentored, hence creating a kick ass PALib library - fuelled by productivity, driven by foresight and guided by wisdom ^_^

keldon wrote:

in a small community we want the least amount of "buts"

Speak for yourself, the more butts for me the better!

Sorry, felt like adding some humor to this thread!

TwentySeven wrote:

Quote:

Sweater Fish Delux Says: Words Words Words

I hope thats a joke, cause otherwise thats the biggest load of horseshit I've ever read. o_O

Yeah, of course it was a joke, but that means there's still a kernel of truth to it, I think.

The point is that there's different types of people who want to develop on the DS and not all of them will want to follow wintermute's model.

That's just the way it is and it will continue to be that way. If some people can't understand it, they better at least learn to accept it.

Quote:

The simple truth of the matter is that PALIB is (wobbly) training wheels for new developers: More experienced programmers should be starting with libnds.

Like many others in this thread, you're making the assumption that I'm here to learn how to program. I'm not. I'm just here to make some games. Programming is only an obstacle along the way to that goal. Which is why I like PAlib, it smooths out the programming obstacle and gets me to my ultimate goal more directly.

I don't want to be challenged by programming so that I can become better, I want the programming to be easy so that my hobby will be fun.

wintermute would like to chime in again here and say that PAlib makes programming harder in the long run, but that's because he's still definining "long run" in terms of a goal that involves learning how to program larger more hardware instensive programs, which is not part of my goal.

I am 95% of the way completed on a game that I think is about as large as I ever plan to make on the DS and it was done entirely with PAlib (except the two lines of paddle control code).

I really don't think there's any more to say in this topic. I'd go back to the PAlib forum and have more rewarding conversations there, but the site seems to be down for some reason.

...word is bondage...

I know shouldn't get involved in this but for crying out loud - how many times does this need to be debated.

I'm 100% behind everything Sweater Fish Deluxe said - and not just cause he has a such a cool name ;)

The ONLY way you will get rid of palib is to make something better to replace it. That is a fact. Good luck! ^^

Sweater Fish Deluxe wrote:

...word is bondage...

No dude, bondage is word! Dig >_>

Sweater Fish Deluxe, you can't win. PAlib must be destroyed at all costs.
_________________
NDS Homebrew Roms & Reviews

Now that's being childish. Some of the comments in this thread have been interesting (hardware abstraction versus ease of use), whereas that comment is pure flame bait.

sonny_jim, sounds like a double standard. being childish is ok for some, but not for others? Actually, I was just waiting to see how long it took to get deleted. ;)
_________________
NDS Homebrew Roms & Reviews

Can't we agree to disagree and see what r22 brings?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Resolutions, resolutions, resolutions ...

Uhh.. it's already March.. aren't you supposed to have those worked out by January 1st?
_________________
NDS Homebrew Roms & Reviews

[quote="SiW"]I think PAlib has grown too big without any real plan. That's why I didn't think about using it when starting DS development a couple of months ago.[/quote]

That's pretty much the impression I got from the entire DS homebrew scene, PALib merely being the tip of the iceberg. Finding documentation is difficult, especially if you expect there to be more than broken code and half-assed, outdated tutorials - with a few notable exceptions.

I'm very much not a real programmer, a beginning junior level newbie at best.. I have read some tutorials from PALib site, peeked at the source (not for the faint of heart), and ended up just having a couple of xterms dedicated to grepping through libnds sources and headers for API reference. It's not difficult, but not served from a silver plate, either.

If libnds was properly documented and more up-to-date tutorials existed, PALib would have probably never emerged in the first place. Should be fairly obvious by now where I'm going with this..

I've spent enough hours banging my head against the wall just to find out it hurts, I will try and contain what little fragments of knowledge I might have into beginner-friendly form, with appropriate warnings regarding author cluelessness, obviously. I suppose as long as I perceive something difficult, it will be easier to explain it.

I skipped a good few pages of this threads nonsense, with that amount of text we'd have another tutorial already online ;-)

Cheers to those working for the DS scene!
_________________
--
K

I find libnds documented just fine - but then, I also like to work with bits. :^)

I agree that well written and up-to-date tutorials are needed, but I wouldn't go as far as saying that PAlib is representative for the whole scene.

PAlib's developers and designers do what they think is right and their library is only build on top libnds, which itself has a totally different purpose (low level hardware access) than PAlib ("middleware" and "library compilation").

Well, I guess that's just the open source world. ;^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

It is possible to use both the original libnds and palib. Just copy palib in libnds folder, fix path problems and you are done. Most functions work and you can use palib only to earn time.
Still that is what i do.

gbadev.org forum archive

DS development > PAlib/devkitARM future development

#152169 - wintermute - Tue Mar 11, 2008 12:06 am

#152196 - ThomasS - Tue Mar 11, 2008 6:06 pm

#152202 - simonjhall - Tue Mar 11, 2008 7:58 pm

#152204 - wintermute - Tue Mar 11, 2008 8:40 pm

#152205 - wintermute - Tue Mar 11, 2008 8:45 pm

#152221 - tepples - Wed Mar 12, 2008 3:44 am

#152230 - nanou - Wed Mar 12, 2008 1:11 pm

#152231 - wintermute - Wed Mar 12, 2008 1:39 pm

#152236 - nanou - Wed Mar 12, 2008 2:52 pm

#152241 - nanou - Wed Mar 12, 2008 6:04 pm

#152242 - Sweater Fish Deluxe - Wed Mar 12, 2008 6:51 pm

#152243 - Michoko - Wed Mar 12, 2008 6:55 pm

#152245 - simonjhall - Wed Mar 12, 2008 7:28 pm

#152246 - nczempin - Wed Mar 12, 2008 7:47 pm

#152253 - DensitY - Wed Mar 12, 2008 8:42 pm

#152256 - tepples - Wed Mar 12, 2008 9:51 pm

#152257 - HyperHacker - Wed Mar 12, 2008 9:53 pm

#152258 - DensitY - Wed Mar 12, 2008 9:59 pm

#152266 - Lazy1 - Thu Mar 13, 2008 12:56 am

#152310 - Sweater Fish Deluxe - Thu Mar 13, 2008 5:38 pm

#152315 - wintermute - Thu Mar 13, 2008 7:07 pm

#152323 - SiW - Thu Mar 13, 2008 8:15 pm

#152330 - nczempin - Thu Mar 13, 2008 9:37 pm

#152332 - Sweater Fish Deluxe - Thu Mar 13, 2008 9:42 pm

#152336 - tepples - Thu Mar 13, 2008 10:06 pm

#152337 - Sweater Fish Deluxe - Thu Mar 13, 2008 10:27 pm

#152339 - Cydrak - Thu Mar 13, 2008 11:02 pm

#152341 - wintermute - Thu Mar 13, 2008 11:37 pm

#152342 - wintermute - Thu Mar 13, 2008 11:51 pm

#152343 - josath - Thu Mar 13, 2008 11:56 pm

#152345 - BigRedPimp - Fri Mar 14, 2008 12:25 am

#152347 - simonjhall - Fri Mar 14, 2008 12:34 am

#152348 - josath - Fri Mar 14, 2008 12:41 am

#152349 - DensitY - Fri Mar 14, 2008 12:46 am

#152356 - wintermute - Fri Mar 14, 2008 3:19 am

#152358 - tepples - Fri Mar 14, 2008 3:30 am

#152361 - Lazy1 - Fri Mar 14, 2008 4:01 am

#152369 - nczempin - Fri Mar 14, 2008 1:15 pm

#152372 - ThomasS - Fri Mar 14, 2008 2:01 pm

#152390 - josath - Fri Mar 14, 2008 8:55 pm

#152395 - SiW - Fri Mar 14, 2008 11:28 pm

#152418 - Sweater Fish Deluxe - Sat Mar 15, 2008 4:53 pm

#152431 - tondopie - Sat Mar 15, 2008 8:50 pm

#152435 - wintermute - Sat Mar 15, 2008 11:58 pm

#152436 - wintermute - Sun Mar 16, 2008 12:05 am

#152447 - wintermute - Sun Mar 16, 2008 5:55 am

#152462 - simonjhall - Sun Mar 16, 2008 12:04 pm

#152473 - nczempin - Sun Mar 16, 2008 2:46 pm

#152480 - ecurtz - Sun Mar 16, 2008 4:36 pm

#152481 - nczempin - Sun Mar 16, 2008 4:44 pm

#152560 - Lynx - Mon Mar 17, 2008 8:16 pm

#152580 - wintermute - Mon Mar 17, 2008 11:28 pm

#152595 - Sweater Fish Deluxe - Tue Mar 18, 2008 1:46 am

#152598 - TwentySeven - Tue Mar 18, 2008 2:00 am

#152599 - DensitY - Tue Mar 18, 2008 2:10 am

#152601 - Lynx - Tue Mar 18, 2008 2:31 am

#152602 - wintermute - Tue Mar 18, 2008 2:52 am

#152607 - Lynx - Tue Mar 18, 2008 4:10 am

#152615 - wintermute - Tue Mar 18, 2008 6:12 am

#152621 - keldon - Tue Mar 18, 2008 10:39 am

#152622 - Rajveer - Tue Mar 18, 2008 12:08 pm

#152627 - Sweater Fish Deluxe - Tue Mar 18, 2008 4:00 pm

#152631 - sumiguchi - Tue Mar 18, 2008 6:33 pm

#152633 - keldon - Tue Mar 18, 2008 6:52 pm

#152641 - Lynx - Tue Mar 18, 2008 8:17 pm

#152642 - sonny_jim - Tue Mar 18, 2008 8:21 pm

#152643 - Lynx - Tue Mar 18, 2008 8:29 pm

#152690 - tepples - Wed Mar 19, 2008 7:39 pm

#152746 - keldon - Thu Mar 20, 2008 10:40 am

#152759 - Lynx - Thu Mar 20, 2008 2:13 pm

#162319 - Koston - Sun Aug 31, 2008 10:59 am

#162332 - silent_code - Sun Aug 31, 2008 8:34 pm

#162358 - jimis - Mon Sep 01, 2008 7:46 am