Yet another reason I think it's a better idea to start out with optimizations off - you have more code massaging your code, which means more code that can fail.

As I've mentioned in here https://forum.gbadev.net/topic/29-can-t-build-in-programmer-s-notepad?page=1#pid175 I think it's generally a good idea to use optimizations always so that you're always testing the code you will eventually run in the final build.

I did have to use the ARM compiler and linker from devkitPro as running the vanilla makefile didn't work though.

Yes, when building old code in general you should replace the makefile by the new one of devkitPro, they don't update it often, but over the years it tends to change, and you really don't want to waste your time fixing an old makefile when you can just take the new one.

jeffythedragonslayer wrote:

I'm going to have to strongly disagree with you on that one - I think being able to step through every line is extremely important - but no big deal, I can always write my own tutorial.

The GBA isn't a PC, it's a very resource-constrained device. People developing for GBA need to understand that it's not as comfortable as developing for PC. Only trivial code can be built without optimizations and expected to run at a reasonable speed. At some point in development you always need to enable optimizations, and you will eventually need to debug optimized code.

It's better to get used to the idea that compilers can rearrange code and debuggers stepping through that code may jump around. This is confusing for a beginner, sure, but only at the very beginning. In fact, some bugs may only show up with optimizations enabled (like timing-related bugs), so in any case you need to get used to debugging with optimizations enabled instead of disabling optimizations whenever you want to debug.

And it gets worse. On the GBA you sometimes need to place code in IWRAM for extra speed. Unoptimized code is bigger than optimized code, so you may simply not be able to build your game without optimizations if you are using too much of that RAM. And you should use that RAM, it's like a make-my-code-faster cheat! But then again, if you move your code out of that RAM for debugging, you're changing the timings of the actual code, which may hide bugs.

I think that in general it's better to debug the actual code you are going to run than a fake ideal version of the code. The only exception would be if you want to debug an algorithm, I guess, but you can always build it for the PC and debug it there, then use it on GBA.

I would say that if your first experience debugging code is debugging C on a GBA, you're going to have a hard time no matter what you do. Until fairly recently you couldn't even use GDB to debug code, the best you could do was to use no$gba to step through assembly code.

So yeah, while being able to debug line by line in a GBA project would generally be a nice thing, it's by no means something crucial for a developer, or even possible sometimes.

Hi! I've waited for a few months, but I think it's about time I make an actual introduction post for BlocksDS.

This is the official location: https://github.com/blocksds/sdk

BlocksDS is a Nintendo DS SDK built on top of GCC, and using libraries like libnds, maxmod, dswifi, and Elm's FatFs. The idea is to have an SDK that is mostly backwards-compatible with projects developed with devkitARM, while cleaning up the code and adding new features.

You can see a more in-depth explanation in this blog post, but I'll summarize below the points of the article that may be of interest to most people.

Some of the current advantages over devkitARM are:

• Smaller binary size and smaller RAM usage.
• The licences of all the code have been clarified and documented.
• A lot of system code of libnds has been documented to help future work on it.
• There is basic multithreading support.
• The DSi camera is supported.
• NDS ROMs can be generated with animated icons.

I'd like to thank a few contributors, including lifehackerhansol and Pk11, but specially asie, which has been super helpful.

The main disadvantages over devkitARM:

• BlocksDS is Linux-only. There are Docker images that you can use on other OSes, and you can install it in WSL if you're using Windows, but there is no native support, which may be a problem for some potential users.
• The compatibility with devkitARM isn't perfect. You will need to heavily modify any project that uses features provided by the fork of newlib in devkitARM, like devoptab (but this is a very niche situation).

Also, I've done a lot of work to bring NFlib and Nitro Engine up to date, clean their code and their documentation, check them out too!

Thank you for your interest!

Most people take the makefiles as they are, and use them right away. I think it's a good idea to leave optimizations on, as most people aren't actually going to step line by line in a debugger.

In fact, I created the libtonc-examples repository because the original examples were using a few different makefiles with more or less features, and a reduced version of libtonc called "toolbox" or something like that.

Most people take the first example they build and start building their game on top of it, it's important that all examples are decent enough to use them as base.

pmprog wrote:

I think I've also discovered that most of the projects I want to do are probably well out of my scope unless I can find others to do things like graphics and audio

Yeah, that's very true. Usually a team of an artist plus a programmer can create a pretty good game, but it's hard to find someone that can do both. If you're mainly an artist, writing code will take 10 times longer than creating art. If you're a programmer, the other way around.

e9zyI39w3 wrote:

I'm glad you were able to stick around after that tough experience. That last sentence means a lot.

You make it seem like it was an awful experience. 😅 It wasn't super bad, but it really made me take a long break afterwards (and by the time the break would have been over the covid restrictions ended, so I could go back to normal).

pmprog wrote:

SkyLyrac wrote:

There is no point in forcing yourself to do something you are doing for fun.

I used to agree, but not so much any more. I don't totally disagree, but there are times that you need to push through some less fun bits for the sake of the whole. Game Dev is a great example of this. There's the polish bit at the end which is hard and boring (most of the time), but if you can make your way through it, the end result of your game benefits greatly from it. At the end you'll be smiling a lot more.

Don't get me wrong, something that just is making you miserable or stressed, then yes, reevaluate what you're doing,

Oh, for sure, but even the less fun parts shouldn't be too bad. I even enjoyed the parts about creating the build system of my games, converting assets, etc. But I don't think I'd work on such a big project for a game jam again, I would try to keep it simple so that I can work on it when I actually feel like it.

exelotl wrote:

[...]

Wow, what a story! 😃

sasha wrote:

The Sims games on the GBA are fascinating to me from a game-design standpoint. I know some videos have been done on them. I owned Bustin' Out as a kid and played it a lot. I would have loved to see a more sandbox-y Sims game on the system, but there's probably some reason I'm not considering as to why they didn't ever go that route.

I loved how big and detailed the sprites are. I never owned either of them when I was young, but I ended up buying The Urbz a few years ago just because of how much I liked them.

e9zyI39w3 wrote:

I am so stuck on the third generation that I purified a Shadow Pokemon from Pokemon Colosseum and earned the max possible ribbons on my Flygon, Jinn. He currently has 67 ribbons and has been vacationing in Pokemon White for a long while.

I have a few purified Pokemon that have travelled from Colosseum and XD to Pokemon Home. I never bothered to get ribbons on them, though. 😅

e9zyI39w3 wrote:

That's so cool that you ported your homebrew GB game to GBA! How many people have done that before? I never would have considered it honestly.

The main issue is that it still feels like a GBC game. But the biggest advantage was that I didn't have to design a new game from scratch, so it was a more efficient way to use my limited free time. 😅

I've been working as a software developer for 7 years. The amount of time I dedicate to my hobbies fluctuates a lot. There have been years when I spent a lot of my free time writing code, and years when I've done basically nothing outside of work. I don't try to allocate any time for it because there is no way for me to actually stick to my plans.

With jams I try to make an effort, though. For the 2021 GBA jam I actually managed to work a lot more than I normally do and it wasn't a great idea, to be honest. I sacrificed time I normally dedicated to socialize, and I felt it after a few weeks. This is also why I avoid jams in general.

Nowadays I just take it easy. I may spend a few weeks working a lot on my projects when I have time, and then the new Pokemon games come out and I spend weeks playing and spending no time with my projects. Then I get bored and start coding again. This is the only way I have to not burn out. There is no point in forcing yourself to do something you are doing for fun.

My favourites are the Golden Sun games and Final Fantasy Tactics Advance. They are super polished. Great graphics, music and story. I still remember exploring the world in Golden Sun 2 for hours trying to discover things. Another game I really liked is "The Urbz, Sims in the City". I've replayed the 4 games several times, specially the first 3. 😅︎