examples for consoleNew, consoleInit, etc?

[PypeBros]

Hello.

I'm porting old code (libnds dating back from october 2007) that still used consoleInitDefault() in various subtle ways -- like calling twice to have the font available on both screens or changing which screen hosts the console at run time to the latest release ( 1.4.8 ) of libnds. Yet I'm missing some examples of how things work, and it looks like I don't even have the consoleNew that the doxygen documentation talks about >_<

Any hint ?

[zeromus]

which doxygen docs? you sure theyre not old ones?

why dont you just read console.h for documentation--then you wont have a mismatch between sources and docs.

[WinterMute]

Sounds like you're using random doxygen docs from somewhere other than http://libnds.devkitpro.org

http://libnds.devkitpro.org/a00107.html

[PypeBros]

Actually, I was refering to doxygen-compatible comments found in the code itself. And the link http://libnds.devkitpro.org/a00107.html says:

PrintConsole * consoleGetDefault (void)
Gets a pointer to the default console (this should only be used when using a single console, other wise use consoleNew(PrintsConsole* console).

Thanks for the official online dox, btw. For some reason, my package (libnds-1.4.8 for Linux) was complaining about a missing libnds.dox file.

[zeromus]

thats interesting. documentation is out of date as soon as it is written. it doesnt seem like a very large logical leap to get from consoleNew to consoleInit. the answers are still in that header file.

[PypeBros]

i sure can write

Code: Select all

PrintConsole SecondConsole = * getDefaultConsole();
ConsoleInit(&SecondConsole, ...);

if that's the intent. That doesn't make the current documentation less confusing.

[zeromus]

I just patted my head and rubbed my tummy and it didnt make the current documentation any less confusing, also.

It's interesting. Its almost like you would have to edit the documentation to make it less confusing, or something like that. Am I crazy?

But I also think there is another way. It depends on how you parse things. You could say that the documentation is less confusing if it confuses you less, right? And it would confuse you less if you ignored it (which you should do because documentation is out of date as soon as it is written). I thought maybe you would experience a little bit of that thrill when you typed in code in clear contradiction to the guidance in the documentation, but I guess not. Well, it works for me anyway. I never get confused by docs (and I never read them) and thats all I can say for sure.

You could also try reading the docs but assuming theyre maliciously modified to cause trouble for you by sneaking in inaccuracies of all sizes. That way you can get guided in the right direction without tripping too hard on traps. Sort of like holding your arms out while stumbling through dark woods following a ghostly voice. It's only common sense.

[PypeBros]

But I also think there is another way. It depends on how you parse things. You could say that the documentation is less confusing if it confuses you less, right? And it would confuse you less if you ignored it (which you should do because documentation is out of date as soon as it is written). I thought maybe you would experience a little bit of that thrill when you typed in code in clear contradiction to the guidance in the documentation, but I guess not. Well, it works for me anyway. I never get confused by docs (and I never read them) and thats all I can say for sure.

You could also try reading the docs but assuming theyre maliciously modified to cause trouble for you by sneaking in inaccuracies of all sizes. That way you can get guided in the right direction without tripping too hard on traps. Sort of like holding your arms out while stumbling through dark woods following a ghostly voice. It's only common sense.

That quite sounds like an answer from a character in "Alice in Wonderland"

Well, I guess the best I have to do is to print out console.c and console.h and reverse-engineer that to figure out what the dudes that modified the interface had in their mind at that time.

[WinterMute]

The other approach is to realise that writing libraries for machines we have no documentation for is doomed to always be a work in progress and, despite our best intentions, things will change, better ways to do things will be found & old code is unlikely to compile or work with the latest set of tools and libraries.

It looks like Dovoto either didn't get around to implementing consoleNew or intended to use consoleInit instead, I'll update the doxygen stuff at some point when I have more time to look properly. Of course patches to fix problems like this are always appreciated

There are also numerous examples which go some way towards illustrating intended use of various libnds features. examples/nds/Graphics/Printing/print_both_screens is probably a good place to look.

[PypeBros]

I'll have a look at that print_double_screen example, thanks.