any way to make more use of space?/improve drawing distance?

[t377y000]

hi i was wondering if there were more ways to improve the use of textures & texture sizes, for example loading textures from fat?

the vram is 512mb correct?
i have been going by this chart for my games because of the limitation

Code: Select all

ds model exporter  16-bit nintendo ds converts
32 x 32 becomes 2kb			256 textures
64 x 64 becomes 8kb			64 textures
128x64 becomes 16kb		i could use for titles
128 x 128 becomes 32kb		16 textures (with consoledemoinit only 12)
256 x 256 becomes 128kb		4 textures
512 x 512 becomes 512kb		1 texture

also i was wondering about improving drawing distance, like for instance.
look at DS craft by this person the drawing distance seems alot better, & the skymap.


then heres my sandbox engine DS-DSi
the drawing distance stoppes then you juse see black above that lol.


i had a talk with this person & he said something about useing straight resisters, im still kinda confused tho
for sandbox engine i previously always used nitro engine, until i learn hot to use libnds alone 100

edit: heres a link to the tread where i post my games btw
mod: link removed, sorry, we don't link there
& heres a link to the main site.
https://sites.google.com/site/t3gameszero/

[Discostew]

VRAM is 512KB for the main banks, and an additional 144KB for the secondary banks. Using 15-bit textures for everything can lead to little availability of the main VRAM. If you are able to consolidate your textures to be palette-based, you can increase the number of textures and/or increase the size of them, as the palettes get stored in the secondary banks. If you were to have textures that were paletted, you could use up to 96KB of secondary VRAM space for them. At 8-bit (256 colors) per palette, that would be up to 192 unique palettes. You can further reduce the VRAM requirement for textures that can be converted to 4-bit (16 colors) or even 2-bit (4 colors) if you really need to.


I'm not sure what straight resisters are, but what values are you using for your near/far clipping plane? I assume you are using glPerspectivef32 (or an equivalent) to set up your projection matrix. Also understand that having a far drawing distance can lead to the polygon limit being reached much easier. When you get to that point, you'll have to decide how to proceed, whether to include fog, or even using the capture unit for rendering one part in one frame, and adding that to the next part(s) in following frames.

[t377y000]

heres the quote of what he said.

Hey
My game uses "straight devkitpro", no library other than libnds, libfat etc. Actually, I don't really use libnds's features all that much, for most of my stuff I work with registers directly; I also have my own framework to handle textures and other things.
To achieve the view distance in DScraft I use two main things :
- first and most important is obviously the frustum culling. Basically I have an algorithm designed to find out which polygons are in viewing frustum and which are not; this allows me to only draw what's necessary and therefore maximize my use of the GPU. Doing this can be quite a pain, there are lots of different ways to do it, it all depends on what kind of limitations your map format is going to have, but a nice thing about the DS's GPU is that it has something called "box tests" which very quickly check whether a given box is within the viewing frustum or not. You can find more info about it here : http://nocash.emubase.de/gbatek.htm#ds3dtests
- second is rendering in two passes. Since the DS's GPU is limited to a rather small number of polygons per frame (I can only get about 1700 quads out of each frame), I render my scene in two passes, once the foreground and once the background. This allows me to crank the quad limit up to over 3400/frame, but it also means I can't get a framerate better than 30FPS. Also, doing this is only possible if you have a well defined foreground and background (you have to sort polygons manually if you don't want to get weird artefacts) and it inevitably eats up two main VRAM banks (so that's 256KB of VRAM you won't be able to use for anything else) because it requires the use of DISPCAPCNT : http://nocash.emubase.de/gbatek.htm#dsv ... isplaymode

Hope this helps you.

[mtheall]

What he means about "straight registers" is by directly accessing the control registers and not accessing them through the libnds API.

[Discostew]

What he means about "straight registers" is by directly accessing the control registers and not accessing them through the libnds API.

Misspelling can lead to confusion, which is why I didn't know what he meant by "resisters" when he meant "registers".

[t377y000]

What he means about "straight registers" is by directly accessing the control registers and not accessing them through the libnds API.

Misspelling can lead to confusion, which is why I didn't know what he meant by "resisters" when he meant "registers".

sorry aboth that, it wouldnt let me edit the post for some reason.
& yes i meant registers.
typo my greatest weakness.

[t377y000]

anyone?

[zeromus]

Improving drawing distance requires fiddling around with your projection matrix and your world coordinate units. It's that simple. For an example, you can try changing the far clip plane parameter in any gluPerspective() call in the libnds 3d examples. For instance, change it to 2 in Env_Mapping

Your analysis of VRAM sizes for texture is not very accurate. It assumes 16bpp textures. Not many things use 16bpp textures. Most textures are paletted, and you can use more of them. But yes, you have 512KB max for textures (although then you will find it difficult to do anything with the 2D hardware; most games use something like 384K maximum textures, and quite a few use less memory than that even.)

Accessing registers directly isn't going to help you much, in general.

[mtheall]

Practically, you only really get to use 256KB of texture memory (slot 0 and slot 1) for general purpose. The other 256KB available is dedicated to the rear-plane image (128KB for the bitmap data (slot 2) and 128KB for the depth data (slot 3)). 256KB does not give much room for 16bpp textures. You get what? Room for 128K pixels (256x512 area, or 32 64x64 textures, for examples).

Of course, it's much more practical to use paletted textures. You can use up to a hefty 96KB to store your palette data. The variety is very versatile. You can use 2bpp, 4bpp, and 8bpp palettes, in addition to a few other formats. At 2bpp, this means you can have a nice 1M pixels of texture data, but it's more likely you'll want 4bpp or 8bpp textures. Not to mention you can do some cool palette swapping tricks to get more out of it (another significant advantage of using paletted graphics).

[zeromus]

Hardly anyone uses the depth image and even fewer people use the back plane image. Those will be available for textures in almost all cases. Dedicated is a poor choice of words.