DevKitPro vs BlocksDS?

[loook]

Recently started a homebrew project for Nintendo DS.
Years ago I learned the existence of DevKitPro as the go-to toolchain to develop for the DS.
I went as far as setting up a basic build pipeline for myself and managed to build some of my own code, using DevKitPro, that runs on DeSmuME.
Recently i learned about BlocksDS and saw. that in many aspects it's a more extensive SDK, offering more features and also seems to be more optimized, not to mention it seems it has even more tutorials/samples.

Should i just switch to BlocksDS, is there any reason to stick with DevKitPro other than legacy reasons (if one's maintaining an old project)?
Does DevKitPro offer something, that the other still does not?

Right now I have very few code written and I could switch rather easily to BlocksDS.

 

[elhobbs]

Recently started a homebrew project for Nintendo DS.
Years ago I learned the existence of DevKitPro as the go-to toolchain to develop for the DS.
I went as far as setting up a basic build pipeline for myself and managed to build some of my own code, using DevKitPro, that runs on DeSmuME.
Recently i learned about BlocksDS and saw. that in many aspects it's a more extensive SDK, offering more features and also seems to be more optimized, not to mention it seems it has even more tutorials/samples.

Should i just switch to BlocksDS, is there any reason to stick with DevKitPro other than legacy reasons (if one's maintaining an old project)?
Does DevKitPro offer something, that the other still does not?

Right now I have very few code written and I could switch rather easily to BlocksDS.

it probably comes down to personal preference. the recent-ish calico library added threading to the devkitpro libnds version and replaced the FIFO system for arm7/9 communications - breaking changes that require changes for more complex projects.
i am not a blockds expert but the biggest difference seems to be dswifi replaced the custom implementation with lwip. also better/more documentation- which has never been a devkitpro priority. but since i prefer examples/code to documentation this has not been a deal breaker for me.
i am curious as to what additional features and optimizations are that you referred to?

 

[loook]

it probably comes down to personal preference. the recent-ish calico library added threading to the devkitpro libnds version and replaced the FIFO system for arm7/9 communications - breaking changes that require changes for more complex projects.
i am not a blockds expert but the biggest difference seems to be dswifi replaced the custom implementation with lwip. also better/more documentation- which has never been a devkitpro priority. but since i prefer examples/code to documentation this has not been a deal breaker for me.
i am curious as to what additional features and optimizations are that you referred to?

can't find the link, but read somewhere, that they reduced the code to grab input (touch+buttons) from 8kb to 1kb, or along those lines.
i presume after all these years people figured so much thing about the DS, that they can do some heavy optimization to existing techniques, but some of them are not backwards compatible.

 

[elhobbs]

can't find the link, but read somewhere, that they reduced the code to grab input (touch+buttons) from 8kb to 1kb, or along those lines.
i presume after all these years people figured so much thing about the DS, that they can do some heavy optimization to existing techniques, but some of them are not backwards compatible.

i am not sure how accurate that is currently. calico did replace a lot of the underlying structure for the devkitpro libnds version. i suspect that each has their strengths and benefits over the other, but it likely depends on the project - and possibly does not really make a difference in most and/or many cases.
devkitpro has a longer history and has been consistently maintained during that time. blockds is newer and has seen consistent updates as well, but only time will tell if that will continue.
and then maybe none of that really matters if you can build what you want …

 

[AntonioND]

can't find the link, but read somewhere, that they reduced the code to grab input (touch+buttons) from 8kb to 1kb, or along those lines.
i presume after all these years people figured so much thing about the DS, that they can do some heavy optimization to existing techniques, but some of them are not backwards compatible.

8kb to 1kb is unlikely, but it's true that you can get smaller ROMs with BlocksDS than with devkitPro (there are a few reasons, like not using devoptab, and using picolibc instead of newlib, but they are very technical...). I need to write a new blog post about the current state of BlocksDS, I'll probably do it over the next few days during my Christmas break.

We do have a new touch driver that asie wrote, but so does calico.

-------------------------------

The main difference between BlocksDS and devkitPro at this point is that BlocksDS has accepted contributions from other people, something that devkitPro generally doesn't like to do. That has given me a lot more freedom to work on other things like the documentation and the tutorial (WIP, but it already mentions many things). Of course, there are plenty of examples too, a lot more than in devkitPro at this point (I keep adding examples as I write the tutorial so that both examples and tutorials are interlinked).

Another nice thing of BlocksDS is that it supports local multiplayer without the need for a router (the same way as official games do it), and it supports IPv6 when it connects to the internet. I replaced the old sgIP of dswifi by lwIP as sgIP had lots of memory leaks and it only supported IPv4.

Maxmod (the music player) in BlocksDS is fully converted to C code instead of being in assembly, which has made it possible to fix lots of bugs. Only the critical parts are still in assembly (for extra speed).

In general, there are a bunch of helpful people in Discord willing to chat with you if you have issues while developing your applications, which is another thing that devkitPro lacks.

Oh, and this is more of a curiosity than something useful, but BlocksDS also has support for the DSP of the DSi (an additional CPU that it has and it's dedicated to audio). The toolchain is super buggy and I wouldn't recommend using it, but it's there if you want to play with it.

In any case, BlocksDS is based on libnds and other libraries that came with devkitPro, so of course I'm also grateful to them for improving the libraries. BlocksDS has made an effort to remain as compatible as possible with older projects, while calico is more of a break, for better or worse.

EDIT: Also, you have a few additional libraries for the DS that you can install with BlocksDS (NFlib, Nitro Engine, Woopsi... https://blocksds.skylyrac.net/docs/libs/additional_libs/ )

 

[loook]

8kb to 1kb is unlikely, but it's true that you can get smaller ROMs with BlocksDS than with devkitPro (there are a few reasons, like not using devoptab, and using picolibc instead of newlib, but they are very technical...). I need to write a new blog post about the current state of BlocksDS, I'll probably do it over the next few days during my Christmas break.

We do have a new touch driver that asie wrote, but so does calico.

-------------------------------

The main difference between BlocksDS and devkitPro at this point is that BlocksDS has accepted contributions from other people, something that devkitPro generally doesn't like to do. That has given me a lot more freedom to work on other things like the documentation and the tutorial (WIP, but it already mentions many things). Of course, there are plenty of examples too, a lot more than in devkitPro at this point (I keep adding examples as I write the tutorial so that both examples and tutorials are interlinked).

Another nice thing of BlocksDS is that it supports local multiplayer without the need for a router (the same way as official games do it), and it supports IPv6 when it connects to the internet. I replaced the old sgIP of dswifi by lwIP as sgIP had lots of memory leaks and it only supported IPv4.

Maxmod (the music player) in BlocksDS is fully converted to C code instead of being in assembly, which has made it possible to fix lots of bugs. Only the critical parts are still in assembly (for extra speed).

In general, there are a bunch of helpful people in Discord willing to chat with you if you have issues while developing your applications, which is another thing that devkitPro lacks.

Oh, and this is more of a curiosity than something useful, but BlocksDS also has support for the DSP of the DSi (an additional CPU that it has and it's dedicated to audio). The toolchain is super buggy and I wouldn't recommend using it, but it's there if you want to play with it.

In any case, BlocksDS is based on libnds and other libraries that came with devkitPro, so of course I'm also grateful to them for improving the libraries. BlocksDS has made an effort to remain as compatible as possible with older projects, while calico is more of a break, for better or worse.

EDIT: Also, you have a few additional libraries for the DS that you can install with BlocksDS (NFlib, Nitro Engine, Woopsi... https://blocksds.skylyrac.net/docs/libs/additional_libs/ )

Thank you for the reply.
One thing i noticed with BlocksDS, is that it's just has a few more annoying installation steps over DevkitPro (it was rather simple after adding the pacman repository), namely you have to do everything trough the wonderful toolchain - could this be simplified a bit?
It does not bother me that much, as my already set up DevkitPro environment is in an Arch VM on VirtualBox, so I wont mess up my host machine, but the fewer steps these toolchains have, the better.

The project, that I started is really in infancy (so far i only printed some messages and created a debug menu), so switching is really painless.

The real driving for for me was the multitude of examples, most of them with proper explanation. It was really annoying to hunt down the nocashMessage() function for sending messages trough the debug port, for some reason I found it's existence in some message board (I knew something like this had to exist, but the naming was rather unconventional)

 

[AntonioND]

Thank you for the reply.
One thing i noticed with BlocksDS, is that it's just has a few more annoying installation steps over DevkitPro (it was rather simple after adding the pacman repository), namely you have to do everything trough the wonderful toolchain - could this be simplified a bit?
It does not bother me that much, as my already set up DevkitPro environment is in an Arch VM on VirtualBox, so I wont mess up my host machine, but the fewer steps these toolchains have, the better.

The project, that I started is really in infancy (so far i only printed some messages and created a debug menu), so switching is really painless.

The real driving for for me was the multitude of examples, most of them with proper explanation. It was really annoying to hunt down the nocashMessage() function for sending messages trough the debug port, for some reason I found it's existence in some message board (I knew something like this had to exist, but the naming was rather unconventional)

Yes, the installation steps are definitely more annoying, and that's something I'd like to improve (it has been in my to-do list for a while) but it's a bit harder than with devkitPro because Wonderful Toolchain distributes the toolchain, so you're really installing Wonderful Toolchain + BlocksDS.

There's a debugging guide for BlocksDS here: https://blocksds.skylyrac.net/docs/guides/debugging/ It mentions printing debug messages with no$gba and melonDS and other ways you can use to debug.