gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > More about display lists and textures

#59724 - Webez - Thu Nov 03, 2005 7:41 pm

Hi.
I finally got how to export my data to nds display list. I am using them for exporting the map of my tactic-rpg. The problem is that the map is divided in cubes and each cube has 5 faces (the base doesn?t matter beacause it is no visible). And each of these faces can have a different texture. So I was thinking wich of this things is better.

a) Save all the textures in a big one (wich is not too good if I have a lot of levels in my game) so I can save all mapa data in a display list

b) Group data by texture and make a display list for each group

c) Don?t use display lists and load a smaller file with indexed vertex but with slower performance (I suposse it will be slower if I don?t use display lists..)

Thanks

#59728 - dovoto - Thu Nov 03, 2005 8:23 pm

I do not believe it is appropriate to represent the map itself as a display list but only the objects inside it. Mainly because you normaly do not want to draw your entire map each frame.

I believe you can bind to textures within a display list so there is no need to seperate objects based on texture (i guess i have not verified this yet but i see no reason why not). This means you can reference several textures from the same display list.

It is also normaly desirable to seperate your textures into the smallest size possible. There are a couple of reasons.
1) You can usualy get away with a lower color depth with a set of smaller textures vs one big one
2) One big one often will contain unused space
3) Small textures are much easier to load on the fly.

Not sure if this answered your question...
_________________
www.drunkencoders.com

#59731 - Webez - Thu Nov 03, 2005 8:36 pm

I didn't think before about not drawing the entire map but you are absolutely right, if I use a display list I suppouse things like frustum culling are not possible for things so big. So I?ll use them for houses or such a things.

And about binding a texture inside a display list how I am suposse to do it?

Thanks a lot for your answer.

#59735 - dovoto - Thu Nov 03, 2005 9:05 pm

Code:

void glNewList(listName, GL_COMPILE);
glBindTexture(blah);
//draw stuff
glBindTexture(blah2);
//draw some more stuff
void glEndList();


This is assuming you have my display list capable gl code (and since i have not written it yet i find this unlikely).

The actual bind texture would need to be placed in a display list compatible format which i dont recall off the top of my head...I am going to try to add display lists and a few other missing gl functions (glGetxxx, glPush/pop attribute, indexed data).
_________________
www.drunkencoders.com

#59983 - LunarCrisis - Sun Nov 06, 2005 2:37 am

Has it been verified that the DS counts polys drawn outside the screen towards the vertex limit? In theory, if it does the matrix multiplication right away (which it should) it could automatically throw away polygons which are outside the screen, couldn't it?
_________________
If a tree falls in the forest and no one is there to hear it, why the heck do you care?

#59986 - dovoto - Sun Nov 06, 2005 3:02 am

there are vertex and polygon ram counters...I will test this later tonight...Should be very simple to test for vertexes outside the view.=

My plan is to add:
--display lists
-- indexed vertex/texture/normal/color data
-- some getters for the current rotation and perspective matrix (done)
-- hardware fog
-- clean up some naming conventions
-- Hardware bounding box test (done)

Then make a new release. I have everything figured out I just need to make it pretty (and think of a memory efficient way to do display lists).
_________________
www.drunkencoders.com

#59999 - LunarCrisis - Sun Nov 06, 2005 4:46 am

dovoto wrote:
-- Hardware bounding box test (done)
Ermm, not quite sure I understand, if it's done by hardware what needs to be added?
_________________
If a tree falls in the forest and no one is there to hear it, why the heck do you care?

#60000 - tepples - Sun Nov 06, 2005 5:09 am

LunarCrisis wrote:
dovoto wrote:
-- Hardware bounding box test (done)
Ermm, not quite sure I understand, if it's done by hardware what needs to be added?

A test for how much of the hardware's resources it takes, perhaps?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#60011 - dovoto - Sun Nov 06, 2005 8:26 am

tepples wrote:
LunarCrisis wrote:
dovoto wrote:
-- Hardware bounding box test (done)
Ermm, not quite sure I understand, if it's done by hardware what needs to be added?

A test for how much of the hardware's resources it takes, perhaps?


Yes, i will test resource ussage tomorrow :)

By done i mean I know how and have created the following:
Code:
#ifndef BOX_TEST_INCLUDE
#define BOX_TEST_INCLUDE

int BoxTest(v16 x, v16 y, v16 z, v16 height, v16 width, v16 depth);
int BoxTestf(float x, float y, float z, float height, float width, float depth);

void BoxTest_Asynch(v16 x, v16 y, v16 z, v16 height, v16 width, v16 depth);
int BoxTestf_Asynch(float x, float y, float z, float height, float width, float depth);
int BoxTestResult(void);

#endif

_________________
www.drunkencoders.com

#60068 - dovoto - Sun Nov 06, 2005 11:37 pm

This should answer both performance (tepples) of the box test and what happens with vertex ram usage due to clipping and culling (Lunar Crisis).

http://www.drunkencoders.com/deos/ds/boxTest.zip
_________________
www.drunkencoders.com

#60101 - Lino - Mon Nov 07, 2005 3:26 am

Quote:
http://www.drunkencoders.com/deos/ds/boxTest.zip


can you post the code? thanks

#60111 - dovoto - Mon Nov 07, 2005 5:29 am

It has been included as an example in libnds and will be available at next release. If you need the code sooner grab it from the cvs (it should be available for normal users in an hour or three).
_________________
www.drunkencoders.com

#60286 - duencil - Tue Nov 08, 2005 5:41 pm

That's great new information. Thanks dovoto. Any idea whats going on with this code snipped from the boxtest? Bits 12 and 13 of the poly format register I don't have documented yet?

Code:
glPolyFmt(BIT(12) | BIT(13));
glBegin(GL_TRIANGLES);
glEnd();

#60296 - dovoto - Tue Nov 08, 2005 7:12 pm

Me niether, one of them seems to affect the far cliping plane (i dont have my notes with me so not sure which one). I am not sure what the other does.
_________________
www.drunkencoders.com

#60717 - duencil - Mon Nov 14, 2005 2:42 am

I've tested that out. Bit 12 of the poly format register affects z-far clipping. If its not set then polygons intersecting the far plane get culled instead of clipped.

I haven't yet seen how this affects the box test. But maybe the same thing is true, if your box is large and intersects the far plane, it would get culled instead of returning that its intersecting.

Also, seems like the box test just returns a boolean 1 if wholly or partly onscreen or 0 if completely off. There's no way to get the intersecting clipping planes, right?