#49689 - tomer - Mon Aug 01, 2005 6:51 pm
hi all!
my name is Tomer. I used to do GBA coding (Quake 1 demo for GBA).
i wanna do some DS, but pretty confused with what's going on.
It seems that the emulators can't render 3D, am I correct? . Does libNDS implement all of the GPU functionallity? Where do I start?
Me and ny friend's goal is to design a commercial 3D engine for a game,
and we would appriciate any piece of info about, where to start digging info.
cheers, and thx
#49693 - revo - Mon Aug 01, 2005 7:00 pm
| tomer wrote: |
hi all!
my name is Tomer. I used to do GBA coding (Quake 1 demo for GBA).
i wanna do some DS, but pretty confused with what's going on.
It seems that the emulators can't render 3D, am I correct? . Does libNDS implement all of the GPU functionallity? Where do I start?
Me and ny friend's goal is to design a commercial 3D engine for a game,
and we would appriciate any piece of info about, where to start digging info.
cheers, and thx |
iDeaS emulates some of DS 3D capabilities, but the best way to test is to try everything on hardware.
To get familiar with implemented in libnds 3D stuff, take a look at it's documentation, source code and examples - there are 11 lessons of NeHe converted by Dovoto. You can get info, how to get it, from first part of Chris Double tutorial
_________________
[ sorry for all mistakes, but my english isn't as good as I wish it to be ]
#49695 - tomer - Mon Aug 01, 2005 7:06 pm
BTW!
does DS have a FPU?
how long can I run with DS's GPU? i mean - does it do all of the graphic
pipeline (translation, rotation, clipping, projection, rasterizing)?
- I've heard that it uses only fixed point? no renderer can generate a
good frustum planes out of fixed point (except 90 degrees FOV), so
what's the deal? does it mix float points?
#49696 - revo - Mon Aug 01, 2005 7:26 pm
| tomer wrote: |
BTW!
does DS have a FPU?
how long can I run with DS's GPU? i mean - does it do all of the graphic
pipeline (translation, rotation, clipping, projection, rasterizing)?
- I've heard that it uses only fixed point? no renderer can generate a
good frustum planes out of fixed point (except 90 degrees FOV), so
what's the deal? does it mix float points? |
I can't answer to your questions, because I'm not familiar with DS hardware yet , but I think, that the best way to get them is downloading libnds and looking into it's source code.
_________________
[ sorry for all mistakes, but my english isn't as good as I wish it to be ]
#49711 - ector - Mon Aug 01, 2005 10:31 pm
| tomer wrote: |
- I've heard that it uses only fixed point? no renderer can generate a
good frustum planes out of fixed point (except 90 degrees FOV), so
what's the deal? does it mix float points? |
This statement of yours make me just go "huh??"..
It's perfectly possible to do proper 3D rendering in fixed point. It's just quite inconvenient :)
But yes the answer is that there is no FPU and you will have to do fixed point.
#49714 - dovoto - Mon Aug 01, 2005 10:50 pm
| tomer wrote: |
BTW!
- I've heard that it uses only fixed point? no renderer can generate a
good frustum planes out of fixed point (except 90 degrees FOV), so
what's the deal? does it mix float points? |
thats just silly...fixed point is actualy more accurate than floating point (in the same number of bits)...the only advantage to floatng point is speed (not an advantage on any system with no or crapy fpu) and convenience.
That out of the way, there is no fpu on the ds. All math is done in fixed point allthough there are floating point gl wrappers for many functions...to get a feel for gl on the ds look at the nehe examples which use float then compare 10 to 10b as 10b uses much more DS appropriate code. Fixed point is definatly a pain in the ass at times but it is very usable once you get used to it. You will loose a bit of accuracy (as the DS fixed point has only specific formats) but these inaccuracies will not be very noticable on the small screen and will be much less anoying to you than the DSs lack of texture filtering.
There are some aspects of 3D that still have not found it into the library such as the compressed texture format, a few miscelanious texture formats (which i have info for but have not found the time to test), and hardware fog and collision which we are fairly certain exist.
_________________
www.drunkencoders.com
#49722 - sajiimori - Tue Aug 02, 2005 12:41 am
| Quote: |
| thats just silly...fixed point is actualy more accurate than floating point (in the same number of bits)...the only advantage to floatng point is speed (not an advantage on any system with no or crapy fpu) and convenience. |
I don't know about the frustum thing, but this isn't true. Floating point has the very important property of distributing representable values so that fractional precision is reduced for large numbers and increased for small ones. The significant digits are spent exactly where they are needed.
In fixed point, you have to spend 12 (or whatever) bits on fractional precision even when you're dealing with numbers measured in tens of thousands, and you have to spend 19 (or whatever) bits on integer precision even when you're dealing with numbers measured in a few thousandths.
You might argue that you could allocate a different number of fractional bits depending on your range of expected values, but this limits variations in scale. If you want your world to have worms crawling on the surfaces of barrels and clouds soaring over entire islands (to steal an example from an engine demonstration for Black & White), then you'll want your coordinate system to have a wide range.
#49729 - tepples - Tue Aug 02, 2005 2:07 am
| sajiimori wrote: |
| If you want your world to have worms crawling on the surfaces of barrels and clouds soaring over entire islands (to steal an example from an engine demonstration for Black & White) |
Or for a more recent example, Katamari Damacy. Na naaa na na na na naa naa naa na naa naa na naa na...
| Quote: |
| then you'll want your coordinate system to have a wide range. |
But the farther you get from the origin of the coordinate system, the less precision you have. Wouldn't players notice if worms inhabited the northwest corner of the map but couldn't leave it because of roundoff error that increases as the coordinates get bigger? You need the precision spread out evenly over the map, which is only possible in fixed point.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#49732 - DekuTree64 - Tue Aug 02, 2005 2:20 am
| tepples wrote: |
| You need the precision spread out evenly over the map, which is only possible in fixed point. |
I wouldn't necessarily say that... Floating point loses accuracy as it gets farther out, but fixed point just overflows and doesn't work at all.
If your world is that big, you'll probably have to split it up into smaller sectors and store the positions of objects relative to the center of their sector, or something to that effect.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#49735 - tepples - Tue Aug 02, 2005 3:05 am
| DekuTree64 wrote: |
| Floating point loses accuracy as it gets farther out, but fixed point just overflows |
...at the edge of the map, which should either be walled off or wrap around.
| Quote: |
| If your world is that big, you'll probably have to split it up into smaller sectors and store the positions of objects relative to the center of their sector |
Splitting the world into a sector grid is conceptually no different from adding a few more significant bits to the coordinates.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#49737 - mike260 - Tue Aug 02, 2005 3:25 am
| sajiimori wrote: |
| Quote: | | thats just silly...fixed point is actualy more accurate than floating point (in the same number of bits)...the only advantage to floatng point is speed (not an advantage on any system with no or crapy fpu) and convenience. |
I don't know about the frustum thing, but this isn't true. Floating point has the very important property of distributing representable values so that fractional precision is reduced for large numbers and increased for small ones. The significant digits are spent exactly where they are needed.
In fixed point, you have to spend 12 (or whatever) bits on fractional precision even when you're dealing with numbers measured in tens of thousands, and you have to spend 19 (or whatever) bits on integer precision even when you're dealing with numbers measured in a few thousandths.
You might argue that you could allocate a different number of fractional bits depending on your range of expected values, but this limits variations in scale. If you want your world to have worms crawling on the surfaces of barrels and clouds soaring over entire islands (to steal an example from an engine demonstration for Black & White), then you'll want your coordinate system to have a wide range. |
Actually, vertices are transformed directly from modelling-coords to clipspace/viewspace, so they never get quantised to a worldspace fixedpoint grid. By putting appropriate scales/translates into your modelview matrix you can create models as finely detailed as you like, and position them miles from the origin with no loss of precision. What's more, you can embed these translates and scales inside display-lists (the DSes native model format) so they happen transparently to your rendering code. With a good enough art-pipeline, the issues you're concerned about basically disappear.
BTW, a worm sat on the surface of the earth gives you around a 1,000,000,000:1 ratio in sizes, which is quite doable with 32 bits of precision for scaling. And I don't think the B&W planet was *anywhere near* the size of the earth.
If you want something to complain about, complain about the DSes polygon limit ;)
#49738 - DekuTree64 - Tue Aug 02, 2005 3:31 am
| tepples wrote: |
| ...at the edge of the map, which should either be walled off or wrap around. |
Yeah, that's true.
| Quote: |
| Splitting the world into a sector grid is conceptually no different from adding a few more significant bits to the coordinates. |
Not quite, that will involve storing 64-bit positions and doing 64-bit math.
What I had in mind was for the characters to handle AI/collision detection/etc relative to their sector's center, so their positions are always small enough to fit in eg. 32 bits.
Then when rendering, subtract the camera position from the sector center, and add that to the position of the characters in that sector.
If sectorCenter-camPos is too big (will cause the chara positions to overflow), then that sector is too far away to be drawn anyway, so don't.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#49739 - tepples - Tue Aug 02, 2005 3:48 am
| DekuTree64 wrote: |
| tepples wrote: | | Splitting the world into a sector grid is conceptually no different from adding a few more significant bits to the coordinates. |
Not quite, that will involve storing 64-bit positions and doing 64-bit math. |
And sector number plus coordinate within sector is how many bits?
| Quote: |
| What I had in mind was for the characters to handle AI/collision detection/etc relative to their sector's center, so their positions are always small enough to fit in eg. 32 bits. |
Then what happens across sector boundaries?
| Quote: |
| Then when rendering, subtract the camera position from the sector center, and add that to the position of the characters in that sector. |
And in how many bits are those additions and subtractions done?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#49741 - DekuTree64 - Tue Aug 02, 2005 4:02 am
| tepples wrote: |
| And sector number plus coordinate within sector is how many bits? |
For the example here, 64. Otherwise there wouldn't be a whole lot of point in doing it.
| Quote: |
| Then what happens across sector boundaries? |
Add oldSectorCenter-newSectorCenter to his position. Sector positions would probably all be integer coordinates, or scaled down even further if necessary.
The subtraction there would be 32 bit, and then you could shift the result up to fixed-point (assuming sectors are close enough together that the difference will never be huge).
| Quote: |
| Quote: | | Then when rendering, subtract the camera position from the sector center, and add that to the position of the characters in that sector. |
And in how many bits are those additions and subtractions done? |
Since the camera would probably have to be done in 64-bit for a system like this, the subtractin would be 64-bit as well. No big deal compared to doing ALL your game logic in 64 bits.
Rereading your original post, yes, this is conceptually the same as pure 64-bit. Just thinking about practical ways that you could actually do it.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#49742 - sajiimori - Tue Aug 02, 2005 4:03 am
I'm still wondering why there's even a debate here. Why do you guys think processors include complicated FPUs, anyway?
#49743 - tepples - Tue Aug 02, 2005 4:11 am
| DekuTree64 wrote: |
| tepples wrote: | | Then what happens across sector boundaries? |
Add oldSectorCenter-newSectorCenter to his position. Sector positions would probably all be integer coordinates, or scaled down even further if necessary. The subtraction there would be 32 bit, and then you could shift the result up to fixed-point (assuming sectors are close enough together that the difference will never be huge). |
I meant what happens to the AI and collision across sector boundaries?
| Quote: |
| Rereading your original post, yes, this is conceptually the same as pure 64-bit. Just thinking about practical ways that you could actually do it. |
If you're going to split the 64-bit coordinate system into sectors at bit 32, then why not split it into subsectors at bits 16 and 48 too? Heck why not split it after each bit? This representation is called the "quadtree" or "octree" representation.
Remember that PS1 graphics also ran in glorious fixed point.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#49747 - DekuTree64 - Tue Aug 02, 2005 4:25 am
| tepples wrote: |
| I meant what happens to the AI and collision across sector boundaries? |
Hmm, that could get complicated... might need to make the characters aware of the 4 nearest sectors, so you can swap them out before they get close to the boudary.
| Quote: |
| If you're going to split the 64-bit coordinate system into sectors at bit 32, then why not split it into subsectors at bits 16 and 48 too? Heck why not split it after each bit? This representation is called the "quadtree" or "octree" representation. |
Sure, if you feel like trying to work in that :P
My goal was to keep the sector system as transparent to the game code as possible.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#49748 - DekuTree64 - Tue Aug 02, 2005 4:31 am
| sajiimori wrote: |
| I'm still wondering why there's even a debate here. Why do you guys think processors include complicated FPUs, anyway? |
Yeah, we don't seem to have a clear topic we're debating anyway, aside from the feasability of the sector idea that I just threw out there... hu
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#49751 - mike260 - Tue Aug 02, 2005 4:55 am
| sajiimori wrote: |
| I'm still wondering why there's even a debate here. Why do you guys think processors include complicated FPUs, anyway? |
No-one's suggesting that FPUs are a bad idea, only that the lack of an FPU doesn't limit what you can render as much as you think it does.
#49752 - sajiimori - Tue Aug 02, 2005 5:52 am
I didn't say a thing about rendering. What I will say is that we have 3 different vector length functions: one for vectors that are known to be short, one for vectors that are known to be long (more than around 720 units), and one for vectors of unknown length that checks the maximal component against a threshold to determine whether an overflow is possible and then forwards to the specialized version.
#50086 - LOst? - Fri Aug 05, 2005 6:57 am
| dovoto wrote: |
There are some aspects of 3D that still have not found it into the library such as the compressed texture format, a few miscelanious texture formats (which i have info for but have not found the time to test), and hardware fog and collision which we are fairly certain exist. |
Hardware collision? I want to know how that's supposed to work. Does Mario 64 DS use hardware collision? You mean collision detection right?
_________________
Exceptions are fun