View unanswered posts | View active topics It is currently Fri Dec 15, 2017 1:05 pm



Reply to topic  [ 18 posts ]  Go to page 1, 2  Next
 any way to make more use of space?/improve drawing distance? 
Author Message

Joined: Wed Jun 02, 2010 3:14 am
Posts: 52
Location: United States
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:
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.
ImageImage

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

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/


Sun Sep 11, 2011 7:55 pm
Profile

Joined: Sun Mar 08, 2009 7:24 pm
Posts: 103
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.


Sun Sep 11, 2011 9:59 pm
Profile

Joined: Wed Jun 02, 2010 3:14 am
Posts: 52
Location: United States
heres the quote of what he said.
Quote:
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.


Tue Sep 13, 2011 7:35 am
Profile

Joined: Thu Feb 03, 2011 10:47 pm
Posts: 210
What he means about "straight registers" is by directly accessing the control registers and not accessing them through the libnds API.


Tue Sep 13, 2011 3:32 pm
Profile

Joined: Sun Mar 08, 2009 7:24 pm
Posts: 103
mtheall wrote:
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".


Tue Sep 13, 2011 4:21 pm
Profile

Joined: Wed Jun 02, 2010 3:14 am
Posts: 52
Location: United States
Discostew wrote:
mtheall wrote:
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. :cry:


Wed Sep 14, 2011 5:54 am
Profile

Joined: Wed Jun 02, 2010 3:14 am
Posts: 52
Location: United States
anyone? :(


Wed Sep 21, 2011 6:33 am
Profile

Joined: Wed Mar 31, 2010 6:05 pm
Posts: 212
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.


Wed Sep 21, 2011 6:59 am
Profile

Joined: Thu Feb 03, 2011 10:47 pm
Posts: 210
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).


Wed Sep 21, 2011 10:43 pm
Profile

Joined: Wed Mar 31, 2010 6:05 pm
Posts: 212
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.


Thu Sep 22, 2011 2:55 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 18 posts ]  Go to page 1, 2  Next

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.
Get devkitPro at SourceForge.net. Fast, secure and Free Open Source software downloads