NDS-MD2Loader (DLDI)

[wraggster]

Payk (http://payk.drunkencoders.com/index.html?/Pages/Projects.html) has released NDS-MD2Loader, heres the release info:


I have seen many projects for NDS which are using MD2 in a VERY UNEFFICIENT WAY. Loaders like that one from Ethos which render a mesh directly from a binary stream and do not care that float is very lame for NDS. I decided to release my MD2 loader. It was seperated from my WolveSlayer engine by Smealum. I added normalmapping support and cleaned it a bit up. Smealum provided some sample stuff (example code, texture and md2) and i modified it slighty. You can download it and use it as you like, but do not remove credits.

Download and Give Feedback Via Comments

[TeenDev]

thanks a lot Payk!

[a128]

Yet another MD2 loader/renderer for the NDS that just uses GL_TRIANGLES....(:-

MD2 models already have GL_TRIANGLE_STRIP/FAN information in the MD2 structure....come one NDS coders ..do some research

If you render Strips you move less data to the NDS 3d pipeline

[a128]

Here is a MD2 loader with Strips/Fan for the Dreamcast. Feel free to use this code for a MD2 renderer with Strips/Fan for NDS

http://www.boob.co.uk/files/A128/md2and3ds.zip

[Payk]

Ahh no problem TeenDev ;)

a128: When speaking about research, did you considered that the NDS doesn't has an FPU (Floating point unit). Devkitpro provides some software emulation for float(or GCC which comes with that toolchain as well). Well anyway, using float (like that link you gave us) is simply inefficient. True is that i didn't implemented GLCommands yet, but will follow for sure as well as interpolation between frames. Anyway, that loader is still way faster then those loaders which were "ported" to NDS. They have to work with fixed point values to be efficient.
And those which doesn't do that (as most did not) are more then 5x slower (i mean even if they use triangle stripes) But you are right, it would save some render time when i would implement it, and it will be done soon. Till then, do me a favour and measure the speed of your loader on NDS, and that one provided by me. Hv fun ;)

PS: Even if you would add fixed point support and glcommands to that loader above, it will be slower. That loader i coded does precalculate the frames and store them in a different structure as well as it avoids many multiplications (not only because it doesn't have to scale and translate each vertex, it also avoids many pointer stuff. And as a coder as you are should know, each time you update a pointer, you do at least one multiplication ;) )
Did you saw that before posting you 2 posts?

[Buddy4point0]

now if someone made a q3 bsp renderer with physics, mixed this in, add some more code, then we have a fps

[a128]

[QUOTE=Payk;430141]Ahh no problem TeenDev ;)

a128: When speaking about research, did you considered that the NDS doesn't has an FPU (Floating point unit). Devkitpro provides some software emulation for float(or GCC which comes with that toolchain as well). Well anyway, using float (like that link you gave us) is simply inefficient. True is that i didn't implemented GLCommands yet, but will follow for sure as well as interpolation between frames. Anyway, that loader is still way faster then those loaders which were "ported" to NDS. They have to work with fixed point values to be efficient.
And those which doesn't do that (as most did not) are more then 5x slower (i mean even if they use triangle stripes) But you are right, it would save some render time when i would implement it, and it will be done soon. Till then, do me a favour and measure the speed of your loader on NDS, and that one provided by me. Hv fun ;)


You pretty misunderstood my post..I just want to say that using GL_TRIANGLES for MD2 is not the best method

Anyway.

[Payk]

I understood that part pretty well and i am open for such suggestions. But not for stuff like:


Here is a MD2 loader with Strips/Fan for the Dreamcast. Feel free to use this code for a MD2 renderer with Strips/Fan for NDS
^^Is that one using fixed point?
Because if it uses float, it will be MUCH slower then a md2 loader with fixed point and even without GL_TRIANGLE_STRIP.

I know that gl_trianlge strip does avoid sending same data over and over again. It reduces the bus usage up to 66%. Its an issue that has to be solved soon. But still i think that my loader is (on nds) at least 10x faster then your loader. That was reason enough to me to release "Yet another MD2 loader/renderer for the NDS that just uses GL_TRIANGLES" (aka YAM(L/R)FTNTJUGT :D)

Well the reason behind that release is not to fill scene with another loader. Nor to show anybody how to rape the bus between cpu and hw-render-unit. No, it simply was released because many ppl asked me: "How did you get wolveslayer working with 60FPS?"
And a good md2 render that uses fixed-point and pre calculates frames is one of that biggest tweaks which were necessary. When I released the source for wolvelsayer ppl asked me for help to get the md2 loader out of the source (it had a totally different normal mapping system which is not usable for hardware lights).
After smealum and I created a stand alone loader from that loader, I just decided to put it on my site.
It wasn't made to bother you with another loader. It was made to help ppl getting efficient games done. I thought that ppl would thankfully use it, and learn from it. I translated the loader from german to english just that anyone understands what it does exactly.
You could have just said "payk: it's not using triangle strips, it could be even faster" instead of giving it such a bad name and even post another loader which is more 10x slower, just to show anyone that you know what gl commands md2 is using, and that i don't know that (which is also wrong). That post of your link could just cause the opposite from what I tried to reach with releasing my code: fast 3d homebrew for nds. If you also want to support it, release a mod of my loader with glcommands or modify your loader to use fixed point. That would bring us all forward.

At least we are both Sega fans, 3d coders and speak same language. Instead of blaming each other for what we have released, we could simply try to work together and give us pointers and advices in a neat behaviour.

[a128]

Ok....lets go on coding :-)

[Payk]

;) yep, as always :)