RGB18? Is it posible on Nintendo DSi

[Aloz1]

I am a beginer at development on a nintendo ds system (or any system at all). So i thaught i would start off with a tutorial.

And it went somthing like this.

#include <nds.h>
#include <stdio.h>

int main(void)
{
int i;

consoleDemoInit();

videoSetMode(MODE_FB0);

vramSetBankA(VRAM_A_LCD);

printf("Hello World!\n");
printf("www.Drunkencoders.com");

for(i = 0; i < 256 * 192; i++)
VRAM_A = RGB15(31,0,0);

return 0;
}

Now my uncle is very good at c++ so i was asking him some questions when we descovered that the Nintendo DSi is capable of an RGB18 because it is capable of using 262,000 colors although it has the same screen resolution as its predesesors. I was wondering what i have to do to video.h and/or videoGL.h.

This is the part in video.h that i think i have to add to.

// macro creates a 15 bit color from 3x5 bit components
/** \brief Macro to convert 5 bit r g b components into a single 15 bit RGB triplet */
#define RGB15(r,g,b) ((r)|((g)<<5)|((b)<<10))
#define RGB5(r,g,b) ((r)|((g)<<5)|((b)<<10))
#define RGB8(r,g,b) (((r)>>3)|(((g)>>3)<<5)|(((b)>>3)<<10))

The thing is i don't know what to add, my uncle thinks that i have to add
#define RGB18(r,g,b) ((r)|((g)<<6)|((b)<<12))
just above
#define RGB15(r,g,b) ((r)|((g)<<5)|((b)<<10))

Appart from this i am absolutly clueless on what to add, what to do or even if this is correct.
Thankes for all replies

[StevenH]

I'm assuming your refering to this line from the GBATek site:
2x LCD screens (each 256x192 pixel, 3 inch, 18bit color depth, backlight)

Yes the screen of the DS (Phat, Lite and i) can handle 18 bit colour, but only in specific situations (mainly when you are doing 3D) but there is no way to access the 18 bit colour of the screen in code it's all done as part of the 3D hardware, the DS and DSi are 15bit colour systems only, there is no native RGB18 for any DS homebrew.

IIRC the 3D hardware uses the extra 3 bits for lighting and alpha blending of images, but only in the 3D mode, not the 2D mode that your using. Not only that you are still limited to the 15 bit colour area for textures, as an 18 bit colour scheme would use 4 bytes of video ram for 1 pixel, and since the video ram is a limited resource you would be limited to static images only, or smaller screen resolutions due to the reduction in available video ram for the screen.

To sum up:

The DS uses a 15bit RGB palette.
The DS screens are 18bit, which the 3D hardware uses to make the 3D rendering look better.
There is no way to access a pixel with 18bit RGB since a pixel is stored in 1 16 bit memory location (in your example code), and in 3D you do not have access to pixels or to any texture format other than the 16 bit ones (1 bit alpha, 5 red, 5 green, 5 blue) - http://nocash.emubase.de/gbatek.htm#ds3dtextureformats (in case your not aware but a Texel is like a pixel but in texture space),

[elhobbs]

Someone put together a PoC using 18bit color. It involved using two backgrounds and using the hardware blend. Ithink there is a link on forum.gbadev.org

[Aloz1]

I'm assuming your refering to this line from the GBATek site:
2x LCD screens (each 256x192 pixel, 3 inch, 18bit color depth, backlight)

Yes the screen of the DS (Phat, Lite and i) can handle 18 bit colour, but only in specific situations (mainly when you are doing 3D) but there is no way to access the 18 bit colour of the screen in code it's all done as part of the 3D hardware, the DS and DSi are 15bit colour systems only, there is no native RGB18 for any DS homebrew.

IIRC the 3D hardware uses the extra 3 bits for lighting and alpha blending of images, but only in the 3D mode, not the 2D mode that your using. Not only that you are still limited to the 15 bit colour area for textures, as an 18 bit colour scheme would use 4 bytes of video ram for 1 pixel, and since the video ram is a limited resource you would be limited to static images only, or smaller screen resolutions due to the reduction in available video ram for the screen.

To sum up:

The DS uses a 15bit RGB palette.
The DS screens are 18bit, which the 3D hardware uses to make the 3D rendering look better.
There is no way to access a pixel with 18bit RGB since a pixel is stored in 1 16 bit memory location (in your example code), and in 3D you do not have access to pixels or to any texture format other than the 16 bit ones (1 bit alpha, 5 red, 5 green, 5 blue) - http://nocash.emubase.de/gbatek.htm#ds3dtextureformats (in case your not aware but a Texel is like a pixel but in texture space),

Ok so does this meen that the only thing to do with the screen that they upgraded was the size? Does this meen it is imposible to use the last 3 bits during 2d rendering?

and also i forgot to ask before, is it posible to use dev-cpp with devKitPro? I will include a link to the website incase you have never heard of it.
http://www.bloodshed.net/devcpp.html
I have seen this question throught the web but never been answered.

[elhobbs]

You are correct. It is not possible to directly use 18bit color. It is only used internally by the hardware during calculations.

[Discostew]

The "output" to the screens are 18-bit (6 bits for each color channel), but the "input" is limited to 15-bit (5 bits per color channel). Like what was said, there can be blending on the system from backgrounds, 3D, etc., and the extra bit per channel helps to improve the image. As far as limiting the input, I want to say that the reason is because that's the limit of the "short" type (2 bytes), and using any more bits would force the type to become "long" (4 bytes). 18-bits out of 32. Quite a bit of wasted space, especially since there is only 656KB of VRAM that is split among multiple banks.

[StevenH]

Ok so does this meen that the only thing to do with the screen that they upgraded was the size? Does this meen it is imposible to use the last 3 bits during 2d rendering?

No there's a couple of other changes that happened between the DSPhat, DSLite and DSi - Changes to the number of backlight brightness levels (increased from original DSPhat), removal of the easy psuedo-pressure sensitivity on the DSi, and possibly a couple of others that I'm not aware of.

and also i forgot to ask before, is it posible to use dev-cpp with devKitPro? I will include a link to the website incase you have never heard of it.
http://www.bloodshed.net/devcpp.html
I have seen this question throught the web but never been answered.

More than likely as devcpp uses makefiles for it's building process, but I'm not sure what you would need to change in it to allow dev-cpp to work. There's a wizard for the latest version of Visual C++, and with the new Express Editions (MS's free but limited version of Visual Studio - No resource editor, no MFC...) you can utilise the intelisence feature to assist in your coding.

[WinterMute]

devcpp is designed to manage makefiles for you and, while it does have the ability to use custom makefiles, isn't recommended at all. Currently we provide Programmer's Notepad 2 with the windows installer but we're considering moving to CodeLite for the sake of cross platform compatibility. Obviously almost any code editor can be persuaded to work with the devkitPro suppled templates but, for ease of support & user sanity, we prefer to keep our advice to a limited subset of those available. That's probably going to be CodeLite, Visual C++ Express & Xcode, we'll be phasing out PN2 in the near future.

[vuurrobin]

devcpp also hasn't seen an update in 5 years.


@wintermute, why are you considering removing PN2? I thought that PN2 already was cross platform. and why codelite instead of an other IDE (like codeblocks)


you could also not include an IDE with the installer and just let the user choose one from the get go. there are enough tutorials and templates around for setting up an IDE and I think this will be more preferable.

[WinterMute]

You're speaking as someone who already knows which IDE you want to use.

PN2 isn't cross platform and the last time I looked at code::blocks it was difficult to work with devkitPro makefiles. CodeLite seems decent although I'm currently having some trouble getting it to build as a universal binary.

What's preferable for you personally unfortunately doesn't necessarily translate to preferable for the majority of toolchain users. A surprisingly large percentage of new users have never programmed before so I'm working towards a reasonably homogenised environment which should hopefully support consistent tutorials. OSX usage seems to be picking up rather a lot of late so there's a need for an installer/updater package there too.

Ultimately I think it's better for both the community & my own sanity to have a recommended editor which is light and flexible enough to be used with all the toolchains.