#49795 - tomer - Tue Aug 02, 2005 4:30 pm
hi all.
well, I said:"
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?"
and u guys said it silly to ask. well, you probabely didn't do enough
3D to know, that every bit of float point is important for frustum planes.
and no. no fixed point can emulate "perfectly" these normals unless
90 degrees of FOV are used (and that's because of th 1.0 normal it turns out to be). this cab be done but not precisely.
For example, you can't build a 3D portal renderer entirely with fixed-points. but a 2D portal renderer is possiable with fixed points all-the way.
So before u start saying, that I was saying silly things, you should first check, if u know what you're talking.
The fact, that all of u wrote a "Hello World" graphic software doesn't
make you an expert. specially when you're speaking with me, I
can teach you moreabout graphic SW renderers than u think you all know.
anyway, have a nice day. Hope you'll all be more helping next time
#49801 - Ethos - Tue Aug 02, 2005 5:48 pm
1) Why is this a forum post??? This looks more like a private discussion you were having with someone.
2) I believe the GPU accepts only fixed point.
3) | Quote: |
So before u start saying, that I was saying silly things, you should first check, if u know what you're talking.
The fact, that all of u wrote a "Hello World" graphic software doesn't
make you an expert. specially when you're speaking with me, I
can teach you moreabout graphic SW renderers than u think you all know. |
An "i'm better than you...so tell me the answers...but I already know more than you..." cliche
If you really want floating point, build a layer ontop of the current implementation. But please note your target platform has a hit on floating point calcs and the final value must be converted into fixed point at the end. (point 2)
_________________
Ethos' Homepage (Demos/NDS 3D Tutorial)
#49805 - sajiimori - Tue Aug 02, 2005 6:13 pm
| Quote: |
| An "i'm better than you...so tell me the answers...but I already know more than you..." cliche |
True that. Calling things "silly" is probably unnecessary, though.
#49806 - dovoto - Tue Aug 02, 2005 6:22 pm
There is allready limited floating point support in my current GL implementation and gcc has a software floating point library that will handle whatever floating point functionality you care to implement (it does this using all integer math btw).
I understand that you have some experience writing 3D engines but it seems likely that you have limited understanding of number formats in general.
Floats trade range for precission. In a 32 bit float you sacrifice 7 bits to store the range which is nearly 25% of the precission. This is both an advantage in that it makes tracking the range unecessary and so much more efficient over widely varying values, and a dissatdvantage in that those 7 bits are unecessary when you have a small range and result in a loss of precission.
When working with a known range and having a library that supports overflow and large integer math (or hardware that supports it such as the DS) it is very possible to get the same or better precission using fixed point math.
This does put constraints on your data. For instance vectors must be between -8 and 7.997 (or so)...but you can use hardware scaling to raise this range arbitrarily and with precission.
Fixed point is more difficult from a programming perspective as it requires you to constantly be aware of the range of data and make adjustments and calculations to keep precission accross ranges (this is why it is slower for arbitrary range and precission on any system equiped with a decent FPU).
Generaly this results in a system with limited range and occasional loss of precission when compaired to a similar floating point based system as constantly adjusting range to the optimal values requires signifigant overhead.
To make things less enjoyable, much of the fixed point math on the DS takes place in 16 bits of precision (or even 10 bits) so yes, you will loose accuracy in comparison to floating point values.
It is not my claim that fixed point is a better system than floating point for 3D geometry. With double precission floats you will have all the accuracy one could need in all but the most extream of circumstances. With todays FPUs you can do these calculations fast enough that a fixed point library with the same precission and range could not hope to keep up. It is also vrey true that floats are much more intuitive to work with
But, the DS has no FPU and has a pretty well designed fixed point processing in place for fast efficient 3D math. It is all you have and i think you will find it works better than you currently think possible.
_________________
www.drunkencoders.com
#49813 - tomer - Tue Aug 02, 2005 7:55 pm
Hi Devoto!
it's interesting what u said.
I once tried to do perfect 3D clipping, and even Derek from Yeti3D told me,
that I can't expect fixed point math to do it all perfectly.
you can't do everything with fixed point.
try the following scenario:
rotate a fixed point Normal. You use a fixed point cos/sin functions.
it will overflow. but, what you can do is normalize them both to prevent
overflow, and remember they are normalized by a 100 let's say.
I remember trying every implementation. but things just didn't get right.
I dont know how to explain it.if I can learn further, then I'm willing
#49814 - tomer - Tue Aug 02, 2005 7:57 pm
even more Dovoto!
I remember, that the precision for clipping had to be very very
high in order to get it right. so a loss of one bit was not an option.
take that into consideration too
#49815 - tomer - Tue Aug 02, 2005 8:04 pm
Dovoto!
another question!
is the 3D clipping happens on the GPU?
I'm checking out the libnds code gor GL, but I wonder if it was tested
#49816 - tomer - Tue Aug 02, 2005 8:07 pm
wait!
I've seen the GL.
software implementation until 3d clipping. but how does it connect to the GPU?
#49818 - MrAdults - Tue Aug 02, 2005 8:11 pm
It's probably best to think of it from the perspective of "32 bits is 32 bits". You can manipulate and store data however you want in those 32 bits. This is the bottom line and nothing else even matters except when it comes down to performance, where obviously having a hardware FPU is going to be faster.
Essentially, fixed point or floating point aside: the more bits, the more range and/or precision.
-Rich
Last edited by MrAdults on Tue Aug 02, 2005 8:15 pm; edited 1 time in total
#49819 - tomer - Tue Aug 02, 2005 8:11 pm
what does it do -> GFX_END = 0;
#49820 - tomer - Tue Aug 02, 2005 8:18 pm
ok it's a register setup, that tells the GPU to start acting, right?
Every thing you've done was according to DS spec. and all the matricres
are stored in registers too?
#49821 - tomer - Tue Aug 02, 2005 8:22 pm
Anyway DOvoto.
that's a nice library. How did u come up with it?
how do u know all of the adresses of the registers?
#49822 - sajiimori - Tue Aug 02, 2005 8:34 pm
| Quote: |
rotate a fixed point Normal. You use a fixed point cos/sin functions.
it will overflow. |
I do fixed point vector rotation all the time, but quantization is a bitch on unit normals because I can only use 12 of the 32 bits for significant digits.
Well, unless I want to define a new datatype just for small numbers, then templatize the vector class and all other math functions that operate upon them, then ensure that the correct type is used in every circumstance, then refactor any code that previously assumed that real numbers all had the same type, inserting explicit barriers when transitioning between one type and another.
#49841 - dovoto - Tue Aug 02, 2005 10:17 pm
tomer i came up with it via several hundred hours of studying hardware and all avalable sources of information (dissembly of metroid and other code).
Since you bring up sin and cos I thought this would serve as a great way to describe the advantages and disadvantages of fixed over float.
Sin has a fixed range from -1 to 1. This makes any range adjustments on the fixed point values unecessary. Now because we can use 31 bits for the value in the table to hold data and 1 to hold sign (you can actualy use all 32 bits in a half sin table) this will result in much more precission at the ends of the sin cos range. But, as the values approach zero less and less bits will be used resulting in a lowering accuracy.
float point does not have this issue as it stores the range dynamically (as part of the number) and therefor at some point will have more precission than the fixed point table which is why a fixed point sin table will appear to have less precission.
This is easily (well...easy is a relative term after all) overcome by spliting the sin table into regions that return differing fixed formats. This is normaly not nececessary though as it would be difficult to manage.
THe DS has hardware rotation, scale, transform, and lighting (and yeti3D works fine on DS as i ported it very recently). It also has hardware clipping and collision. These are all done in fixed point of differing formats.
The register names and addresses are found in videoGL.h.
Any advice you would like to give to improve the library would be more than welcome.
_________________
www.drunkencoders.com
#49846 - sajiimori - Tue Aug 02, 2005 10:54 pm
How do you do hardware collision?
#49847 - dovoto - Tue Aug 02, 2005 10:58 pm
Thats a good question...as soon as i figure it out i will let you know :) I could be making it up but am pretty sure there is functionality there...there is also hardware fog that needs to be added to the library.
_________________
www.drunkencoders.com