3D

[ghettoboy]

does anyone know how to write 3D stuff for ipaq's
or of any tutorials for writing 3d and rasterising using software. the software rasterising stuff is really what i want to know

[refractor]

Hello.

Pretty much all of the graphics books will cover software rasterization:
Computer graphics principles and practice
procedural elements of computer graphics
.. etc

Do a bit of weeding through this:
and you'll find stuff on rasterization of polygons.

Michael Abrash also covered rasterization in his Black Book of Graphics Programming, IIRC (it's online for free somewhere or other.. you'll probably find a link to it from ).

Cheers,

Refractor.

[MirekCz]

[Phantom]

Keep in mind that the iPaq doesn't have an FPU. Many software rasterizers (especially when coded for Pentium+) use floating point extensively. You should really avoid that.

Anyway, if you need any specific info, just let me know, I'm a software rasterizing guru.

[MirekCz]

[refractor]

MirekCz, have you read ARM's Fixed-Point maths datasheet?



Cheers,

Refractor.

[Phantom]

Yeah that PDF was mentioned before, in the 'asm' thread I believe. Problem with this stuff is that we really need 64bit fixed point. Most calculations should be possible with just 32bits, but that requires a substantial amount of tweaking. 64bit should be enough accuracy for most apps that are being converted from floating point, and 64bit intermediate results should already help a lot. But that requires inline assembly, and that's something we can't use. Using external asm functions for fixed point operations with 64bit intermediate results would consume most of the speed gain, I'm afraid.

[refractor]

Oh yeah, without inline assembler for the 64 bit multiplies, you're kind of stuck if you're using C/C++ - I hadn't thought of that.

I still can't understand just why the hell the MS compiler can't cope with inline ARM.

Cheers,

Refractor.

[ghettoboy]

Hey all of you..thanks
and especially to the Phantom .. for the top advice
..i hope everyone here is going to send the Phantom an app with source cos this guy is so helpful that all of you are willing to use EasyCE so lets put something back,..im a novice..but im going to submit something .. and believe me it will be lame ..but hey we all start somewhere and ill be writing top apps within the next two months ..THANKS TO ALL YOU GUYS>>>THANKS THANKS THANKS

[Digby]

Read the articles on perspective texture mapping on Hecker's site. It's a fixed-point implementation.

[MirekCz]

digby:yeah, right, but if you take a look at it, they use 28.4 fixedpoint numbers... this might be good and fine for a little demo, but without at least 24:8fixedpoint numbers your accurancy is doomed (personally I try to migrate to 16:16 with everything that can be migrated, my line function using 24:8 often looked shitty, after transfering it to 16:16 it's rock stable and I don't get overflow. It wasn't easy to modify it thru)
My main problem atm are divides. While you can quite simple increase the mul precision by using two mul instructions per fixedpoint multiply, how can I help myself with divs? And 2 divs isn't really a solution here because of speed issues.
I have seen some asm code here before for a faster divide, would it be possible to give a lil explanation on it? with C source if possible? Maybe this way I could write a better divide function.
Thanks for your time.

[Phantom]

About the required position; look at it this way: If you're using 8bit precision, the value that you would store in the 9th bit is 'unstable'. So, 30:2 fixed point means that you can store values as small as 0.25, but you have to take into account that '0.25' is actually rounded; the actual value may be in the range 0.125...0.375. The maximum error is thus 1/(2^(2+1)) = 1/8 = 0.125. If you're doing a texture mapper for a 240x320 screen, you have to be accurate enough so that an accumulating error doesn't cause problems when each pixel causes the maximum error. 'Problems' can be defined as a visible artifact; a visible artifact occurs when the calculated u or v value differs more than 0.5 from the correct value (since that would result in fetching the wrong texel). A cumulative error of 0.5 over 240 pixels (horizontal) means that we can tolerate an error per pixel of 1/480. This means that 9 bits is enough to prevent visible artifacts.

There is an error in above explanation: When performing texture mapping, often an error of less than 1 is visible (for example when you're zooming in on the texture). You thus also have to take into account the maximum size of a texel on screen; if this size is 4x4 maximum, you would need 2 extra bits of precision; for 8x8 maximum you need 3 extra bits. So, 20:12 should be pretty safe; this makes it possible to use pretty huge textures, or extreme tiling.

- Jacco.

[MirekCz]

Jacco:well, I know the math by heart, so nothing new to me.
The main 16:16 advantage came because I don't have 3d clipping implemented yet and therefore x and y values could be sky-high (which, in extreme situation, creates an overflow).
I'm implementing 3d clipping as I write, but it's still problematic for me because I might not be able to fit my output values always to 320x240(I want to abandom 2d clipping completely), so I will probably end with a border around the screen few pixels wide which will have errors.
I can tell more about how it works once I finish it. The main accurancy killer is my delta value which describes where between two points is the frustum edge, as it's only between 0 and 255.

[MirekCz]

hmm I have implemented 3d clipping (for wireframe mode atm) and it works superb:) I don't seem to get any larger errors (I do leave a 2 pixel border unused just to be totally sure)
I'm very very happy:)
I hope to show you something that I have done in short time...

[Phantom]

A stable fixed point polygon clipper is a Cool Thing (tm). Congratulations!