#136959 - ChrisKnott - Mon Aug 06, 2007 10:16 pm
I`ve noticed that sometimes a display list is defined with normal gl commands, between glBeginList( GL_COMPILE ) and glEndList() (I think), and sometimes it is written as just a u32 array with raw FIFO commands.
What is the difference between these two methods?
And also, how do you `save` a display list to a .bin file once you have it done?
Thanks a lot.
#137007 - ChrisKnott - Tue Aug 07, 2007 11:27 am
Pretty please?
#137008 - Dark Knight ez - Tue Aug 07, 2007 11:30 am
Well, the DS does not have OpenGL commands like glBeginList and glEndList.
Some people (including myself) might have coded them -- or something similarly named -- to easily create such a u32 array with raw FIFO commands.
So basicly, on the DS, a display list is a u32 array and nothing more. Sometimes hidden by functions.
You might be interested in checking out the following project's source code... that is to say, the displaylistlib.c and displaylistlib.h files.
Tools for 3D models
In it are OpenGL-like display list functions: glBeginListDL, glEndListDL, glVertex3fDL, etc. Basicly the regular functions but ending on DL to make a distinction between writing to a display list and writing to regular output.
_________________
AmplituDS website
#137010 - ChrisKnott - Tue Aug 07, 2007 11:47 am
Thanks a load!
I hope you don't mind if I just reel off a few more questions about display lists...?
1. How do I make a precompiled .bin file?
2. What commands can I used for reading in variable data within a display list, like I presume I can't just use variables normally (it doesn't seem to work at least), do I have to use matrices?
3. If you make a triangle strip, how does it know which edge to add the next triangle on?
Thanks again.
#137016 - silent_code - Tue Aug 07, 2007 1:12 pm
| ChrisKnott wrote: |
3. If you make a triangle strip, how does it know which edge to add the next triangle on? |
it depends on the order you pass vertices: a new vertex creates a tri with the last two. simple, isn't it? ;p
Last edited by silent_code on Tue Aug 07, 2007 1:18 pm; edited 1 time in total
#137017 - tepples - Tue Aug 07, 2007 1:13 pm
1. To read a .bin file, use bin2o (which should happen automatically with wintermute's template if you put your files in the data folder) to put it inside the .nds, or use libfat to read it from another file on the CF or SD card.
2. To learn how to make dynamic arrays in C, look up malloc(), calloc(), and free(). In C++, also look up new and delete.
| ChrisKnott wrote: |
| 3. If you make a triangle strip, how does it know which edge to add the next triangle on? |
GL triangle strips always add points on alternating sides of the strip. Fans are not implemented on the DS.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#137019 - silent_code - Tue Aug 07, 2007 1:20 pm
| tepples wrote: |
| 1. To read a .bin file... |
he meant "create", not "read"... ;p
also, your pt #2 is totally unrelated (or is it just my brain being offline? i'm still a bit sick because of a bad cold. ;) ).
he wants to know how to, e.g. scale his model dynamically (you could do that with a matrix) or make other dynamic adjustments to his displaylists (like changing positions, colors, normals or whatever).
EDIT: now, what tepples *might* mean, is that you could read the diplaylist into a chunk of memory and knowing where what data is, you could just write to that memory, altering any values currently in there. i wouldn't recommend it until you're knowing what you're doing, though. this is very prone to errors, especially when your dl changes.
you could still "process" that data (figuring out where the data to be changed is located by scanning through), though knowing the exact locations/offsets is still faster.
you sure try to do skinned meshes, ain't you? ;D
Last edited by silent_code on Tue Aug 07, 2007 1:48 pm; edited 2 times in total
#137021 - ChrisKnott - Tue Aug 07, 2007 1:34 pm
Thanks peeps, I guess re: the dynamic arrays he was saying that you can read data inside a display list as long as you actually assign the memory and don't just put it on the stack...
At least that's what I read it as, I'll try it out now.
Yes, what I want to do (basically as a test) is to have a display list that describes how the vertices are joined together, and their UV data, but gets passed the positions and normals every time it is called.
Also right, I was curious as to how you MAKE the .bin file, the Makefile I am using at the moment already compiles them nicely. I guess you just make a .c with the just the display list array in and.... er... that's about as far as I got ;).
#137022 - silent_code - Tue Aug 07, 2007 1:50 pm
as far as i understand, the way you're doing it, the dl is compiled into the rom. if i'm not totally wrong (see above), it creates a .bin and a .h file. include the .h file and you have access to the array as well as some additional information (take a look at one of those .h). from there you can then read / modify the array. no loading, but less ram available. (i'm sure i'm totally mixing up stuff now! i need to go *HOME*! ;p )
what you seem to want is a tool that creates a .bin with the raw content of the compiled dl array, right?
a parser comes to my mind: it takes a .c and scans through it, writing corresponding binary values to a .bin.
... that means if you don't want to write a small (PC/MAC/whatever) prog: include the .c files (you should make them .h instead) including the initialized array and compile. it (read a simple printf) should then output the arrays to the according .bin files.
that's sort of a sh*t way to do it and you'll have to compile every time you want to convert a new dl and make adjustment for each and every dl (.bin name, a line that passes each array for output). a makefile may help, though it's still pretty sh*tty and definitely *not* artist friendly.
Last edited by silent_code on Tue Aug 07, 2007 2:13 pm; edited 1 time in total
#137024 - ChrisKnott - Tue Aug 07, 2007 2:12 pm
I'm not sure I really do need a tool that creates the .bin files, at the moment at least, it just wondered how they did it - for example a lot of the demos use teapot.bin, and you can just chuck that file around like a model file.
The makefile builds a header which you can then include, and you can then call the display list with one command, just seemed the nicest way of managing objects imo.
#137025 - silent_code - Tue Aug 07, 2007 2:18 pm
ok, you want to take a mesh, then convert that mesh into a dl and write the binary representation to a .bin file to use it just like the teapot etc., right?
there's some plugin for an *expensive* 3d gfx package (3ds max, iirc) that does that. i guess i can't help you any further.
I'd write a small converter taking whatever mesh file format you're using, building the dl (rip any needed functions from libnds or take a look at how that plugin does it, if possible) and outputting that as a .bin. (i guess this is the way "they" did it.)
good luck! ;)
EDIT:
... and if it isn't that, what *exactly* is it you're trying to do (and doesn't work)? describe how the process (""workflow"") *should* be and where you're having problems. in a quick, short way, that is.
also, look into your build folder after you compiled the demo (for any suspicious .h files etc.).
NOTE: sorry, i didn't read your last post before... so this may be obsolete.
#137032 - ChrisKnott - Tue Aug 07, 2007 3:25 pm
Thanks, I'll fiddle around with trying to get a .bin file, I had noticed the plugins for Maya and Max etc. not much help to a Milkshaper...
I tried refering to memory from within a display list, it compiles ok, but it doesn't work in an emulator I run it in. I tried it on the DS and it kind of works, as in it tries to draw a red triangle, but I think it's just pulling junk out of the memory every time I tried to use a variable in the display list.
I'm basically doing this:
| Code: |
u32* Verts;
u32 Triangle[] =
(
10,
blah,
FIFO( COLOR, VERTEX, VERTEX, VERTEX )
rgb15( 0, 2414521 63161 )
Verts[ 0 ], Verts[ 1 ]
Verts[ 2 ], Verts[ 3 ]
// just put variables in the display list ^^
Etc...
)
int main()
{
Verts = new u32 [ 6 ];
Verts[ 0 ] = VERTEX_PACK( inttov16( 0 ), inttov16( 0 ) );
etc.
// Actually define the vertices here, in main.
..
...
....
glDrawList( triangle );
}
|
I am aware that that is the worst code example ever posted on these forums...
Should I be declaring the pointer some other way? I think that's what's going wrong, it doesn't recognise Verts from withing the display list.
#137036 - Dark Knight ez - Tue Aug 07, 2007 4:09 pm
I don't quite understand...
The easiest way for you to use display lists would be to use something like my .x converter to DS display list format. If Milkshape can export to .x (in ASCII format) that is.
The converter will spit out a .c file in which the array is present, and with that everything is pretty much self explanatory. Just doing a callList on the array in that .c file will do the trick.
Again, check the model tools section and see if it's of use. If not, then ignore my words here and I must've misunderstood you.
There are also other tools to convert from .x to DS display list, or from other formats too I think... Search these forums for them.
_________________
AmplituDS website
#137047 - ChrisKnott - Tue Aug 07, 2007 5:16 pm
Sorry, I'll try to clarify...
I can happily convert a model I make in Milkshape into display list, I wrote my own little text editing program to do that.
I only wonder how to make that chunk of code into a .bin file, rather than having it in a separate code file, I just personally thought it was nicer as a .bin file but that isn't a great worry...
My problem is I want to adjust vertices of a model I make, dynamically in the code, basically a kind of animation...
Say I have a display list of a cube, instead of it saying
| Code: |
FIFO_COMMAND_PACK( FIFO_VERTEX16, ... )
VERTEX_PACK( inttov16( 0 ), inttov16( 1 ) ), ....
...
|
It could say something like:
| Code: |
FIFO_COMMAND_PACK( FIFO_VERTEX16, ... )
VERTEX_PACK( Verts[ 0 ], Verts[ 1 ] ),....
...
|
Where Verts was an array of v16s which I could set in the code. That would allow me to do crazy distorts on the cube, stretching it and stuff, but the display list should still draw the triangles between all the the right vertices and also UV it correctly.
Basically what I need is a way of reading data I can set in main(), in a display list... is the only way of doing this, by using the special matrix list? Or is there another way of getting variable data into a display list?
Thanks.
#137062 - Dark Knight ez - Tue Aug 07, 2007 6:42 pm
Aaaaahhh...
Well, it wouldn't work like that, of course. It's not like pointers to other memory locations in the displaylist array itself will work.
The only way for this to work would be to either create a new displaylist array for every motionframe, or to adjust values in the existing displaylist array itself.
_________________
AmplituDS website
#137081 - ChrisKnott - Tue Aug 07, 2007 8:45 pm
But I heard that you could still access the DS's matrix stack from with a display list? In that case, you could just pack some matrices full of positions, and read them off.
Although, maybe that isn't the case. I think I heard that you can RESTORE matrices, but not Push/Pop them.
Maybe the best option would be to just draw the triangles that are effected by more than one bone normally, ie. not in a display list.
#137087 - M3d10n - Tue Aug 07, 2007 9:06 pm
I've tested push and pop on display lists, and they seem to work OK. I'm using that to include scaling directly into my display lists (the models are scaled during rendering because I'm scaling the vertices coordinates to fit on the v16 range).
I had to add some extra FIFO defines for the matrix functions, though. But it's just using the REG2ID() macro just like all other FIFO defines to generate FIFO ids for the matrix commands.
#137155 - silent_code - Wed Aug 08, 2007 1:23 pm
i'm using milkshape aswell!
what i do is basically: export anything to milkshape ascii and then load that into my custom tools, which in turn export what i need.
now, all you need to do in your export tool is:
- build the dl array
- open a file in binary mode
- write the content of your dl array into it
- close the file
done. now you have your .bin.
as for passing pointers: i guess the other posters are right, it won't work as expected. but you can still do the trick i posted before: you know the layout of your array. so, when building the dl, you just pass the regular vertex positions (not pointers). then, when animating the mesh, you just point into the dl array and change the values.
you could have a vertex pointer array pointing to the vertecies, then you'd only have to index them, not scan through the array or whatever. there are differnt ways of doing this.
make sure you allways have access to the original values (of the bind pose etc.) for transformation calculations, though.
also note, this is just to get you started, it might be a bad solution to the problem. anyway, i hope you get the idea.
else i'd recommend using matices (as they seem to work). though, then i don't think you could have multiple bone influences.
#137197 - ChrisKnott - Wed Aug 08, 2007 7:55 pm
Ah yay now I can make a .bin file!
I'm basically going to have the display list set out something like this...
__in code__
- Calculate the set of matrices for this frame, from interpolating two frames stored in file
- Save all bone matrices to matrix stack
- Calculate vertex positions for triangles with 2+ bones, save in list array
__in list__
- Load matrix, draw all it's triangles
- Repeat for all bones
- Draw 'joining' triangles
So basically there's a nice neat bit at the start of the display list, then some messy stuff at the end joining it all together.
I think it'll be pretty fast, I'll try it out and post results....
#137212 - silent_code - Wed Aug 08, 2007 9:25 pm
good luck! i hope you get some real great results (and of course post them, as you said!). :D
ps: any coputer i have is broken atm., so i'm kinda sitting idle all the time instead of programming...
#137259 - ChrisKnott - Thu Aug 09, 2007 5:08 pm
Yay, got it reading off the matrices inside the display list! Should be able to get a little demo off quite soon.
As an aside, what is the point of setting the matrix mode to MODELVIEW? I doesn't seem to do anything differently if I lose that line...
#137417 - M3d10n - Sat Aug 11, 2007 5:52 pm
| ChrisKnott wrote: |
Yay, got it reading off the matrices inside the display list! Should be able to get a little demo off quite soon.
|
Congrats! Don't forget to post it, I'm looking forward to it. :)
| ChrisKnott wrote: |
| As an aside, what is the point of setting the matrix mode to MODELVIEW? I doesn't seem to do anything differently if I lose that line... |
The matrix mode actually sets which matrix stack you're working on. You only need to change it to MODELVIEW if you have it changed to something else before. The DS has 3 matrix stacks (projection, modelview and texture).
#137716 - ChrisKnott - Tue Aug 14, 2007 10:48 pm
Hey finally managed to get back to programming (life... tsk).
I've got it to the stage where I can export from Milkshape (with joints) and load it on DS, with the matrix restores in the display list.
This let's me animate the model, but at the moment I've only got it drawing out the triangles which are only effected by one bone.
What I have is a section at the end, which has all the other triangles in. I was planning on setting these values of the display list from the code, because then I could do this:
- load bone matrix 1
- calculate and write all vertices and normals of bone 1
- load bone matrix 2...
- etc.
That would mean I only have to load each matrix once, but would have to do hundreds of multiplications and writes to the display list array.
I was just wondering whether that would be fast enough...
Would it actually be faster to just write hundreds of matrix restores into the original display list? I mean, there would have to be a matrix restore for possibly every single vertex, but it would mean I wouldn't have to edit the list from within the game code...
Lastly, if the method of editing the list is faster, I might as well do the whole thing like that, and not have ANY matrix restores in it...?
#138159 - silent_code - Mon Aug 20, 2007 12:17 pm
you'd have to try going different ways.
another option would be sorting vertices (and polys) into influence groups, making these groups individual displaylists and thereby getting more flexibility. you'd have more small dls, but with full control. think about it.
greets!