On this forum, I've read a few times that the file "nes.lib" for the CC65 isn't very good and instead an alternate library should be used. And now I wanted to to know why exactly this is the case.
Until now, the only thing that I need the "nes.lib" for is when I have language constructs that cannot be translated directly into assembly code.
For example, when I have a function that takes parameters or when I write something like array[index++] = 5. In this case, the compiler relies on predefined variables and functions and then I have to specify -t nes instead of -t none in the compiler options, so that the compiler takes these functions from the "nes.lib".
But what I haven't done until now is using any actual predefined functions.
For example, I never tried to use printf or clrscr or sleep or something like that for my NES game. All the "nes.lib" does in my program is transforming C language constructs into assembly code.
So, where exactly is the "nes.lib" bad and what's the advantage in using an alternate library?
Until now, the only thing that I need the "nes.lib" for is when I have language constructs that cannot be translated directly into assembly code.
For example, when I have a function that takes parameters or when I write something like array[index++] = 5. In this case, the compiler relies on predefined variables and functions and then I have to specify -t nes instead of -t none in the compiler options, so that the compiler takes these functions from the "nes.lib".
But what I haven't done until now is using any actual predefined functions.
For example, I never tried to use printf or clrscr or sleep or something like that for my NES game. All the "nes.lib" does in my program is transforming C language constructs into assembly code.
So, where exactly is the "nes.lib" bad and what's the advantage in using an alternate library?