Learning basic 3D

[darkblu]

An abbreviated version of AART? I'm not saying that you're wrong, as I don't have 3D CG, but the full AART is only 426 pages - I find it hard to believe that there'd be an even shorter book on the same subjects by the same author.

well, i don't have 3D CG either but back in '94 when i was considering which of the two to pick i recall finding 3D CG to be pretty much a subset of AART (the two books shared even some of the colour plates). of course, the later editions may diverge substantially.

 

[epicstruggle]

would any of you buy books from amazon.com if it meant part of the money would go to b3d?

please add your 2cents here:
http://www.beyond3d.com/forum/viewtopic.php?t=8397

maybe its a bad idea, let me know what you think.

later,
epic

 

[rwolf]

So what C compilers are you guys using? Microsofts low end is cheap but doesn't optimize. Borland is cheap but may not be as compatible.

 

[darkblu]

So what C compilers are you guys using? Microsofts low end is cheap but doesn't optimize. Borland is cheap but may not be as compatible.

gcc.
though i'm presently using a rather oldish version (2.9-something), it's still way more language-standards-compliant than vc6 that i use at work, and produces more correct output (vc6's optimiser has been the source of some of the most "ingenious" bugs i've come across in my practice). not to mention gcc's ability to seamlessly integrate inline assembly within the code produced by the optimiser (most other cc's have their optimiser states reset after an inline asm statement)

 

[Simon F]

Ditto gcc.

Very standards compliant even, sometimes, to the point of implementing some really stupid (IMHO) features of the C standard, but I can live with those warnings.

 

[Dio]

Yeah, gcc takes 'picky, picky, picky' to the nth degree.

It's a decent enough compiler - although I've seen significant optimisation bugs there, and the rate of change has in the past - although not at the moment I believe - made it hard to use a standard, bug-free version of the compiler. I've not hit significant bugs in VC6 for a while, although that is mostly on C code.

In my experience, inline assembly is a big problem with gcc, as the last time I used it as my main production compiler you were restricted to the dodgy 'we think all languages should be source, dest not dest, source' paradigm and there was no support for MMX, SSE, etc.

 

[darkblu]

It's a decent enough compiler - although I've seen significant optimisation bugs there, and the rate of change has in the past - although not at the moment I believe - made it hard to use a standard, bug-free version of the compiler. I've not hit significant bugs in VC6 for a while, although that is mostly on C code.

but whereas gcc's optimiser bugs are well know (often accounted for in the compiler documentation), msvc6's optimiser bugs come out of the blue, and as a rule take a fair amount of tracing (on asm level, i.e.) in order to be caught.

In my experience, inline assembly is a big problem with gcc, as the last time I used it as my main production compiler you were restricted to the dodgy 'we think all languages should be source, dest not dest, source' paradigm and there was no support for MMX, SSE, etc.

allow me to disagree - in my opinion, gcc has the overall best inline asm support there has been in the industry for some time now. and if a 'src, dst' paradigm is the cost of that i'm more than willing to pay that price : ) apopos, the one 2.9-something i use (also considered ancient by gcc standards) has mmx and 3dn. and i believe gcc 3 and above have support for sse.

 

[Dio]

In my experience, inline assembly is a big problem with gcc, as the last time I used it as my main production compiler you were restricted to the dodgy 'we think all languages should be source, dest not dest, source' paradigm and there was no support for MMX, SSE, etc.

allow me to disagree - in my opinion, gcc has the overall best inline asm support there has been in the industry for some time now. and if a 'src, dst' paradigm is the cost of that i'm more than willing to pay that price

But standards are a good thing.

I originally learnt x86 asm from a book and implemented the code in gcc, so had to learn one form and write another - it was nothing short of a f***ing nightmare, even though I was a many-years-experienced asm programmer. In the end I had to virtually chuck the book away and guess opcodes based on what I knew from 68000, and that's not a satisfactory solution, and I effectively had to relearn x86 coding when I upgraded to Watcom.

That experience left such a bad taste in my mouth... I wouldn't recommend it to anyone. It smacks to me of 'Oh, we don't like the way Intel did this, Motorola assembly was much smarter, we'll do it our way just because'. I was actually hoping you'd come back and say they'd fixed this, because not fixing it is just plain dumb.

I'm not bitter. But my pint is.

 

[darkblu]

That experience left such a bad taste in my mouth... I wouldn't recommend it to anyone. It smacks to me of 'Oh, we don't like the way Intel did this, Motorola assembly was much smarter, we'll do it our way just because'. I was actually hoping you'd come back and say they'd fixed this, because not fixing it is just plain dumb.

AFAIK the gcc guys find the 'src, dst' to be an issue indeed, but they have to stick with it lest compatibility hell arises. at some point they were thinking about providing dual syntax support, dunno what happened though, didn't follow that closely as i've been fine with the at&t syntax ever since the univ (despite being rised on intel's

I'm not bitter. But my pint is.

)

 

[Simon F]

In my experience, inline assembly is a big problem with gcc, as the last time I used it as my main production compiler you were restricted to the dodgy 'we think all languages should be source, dest not dest, source' paradigm and there was no support for MMX, SSE, etc.

allow me to disagree - in my opinion, gcc has the overall best inline asm support there has been in the industry for some time now. and if a 'src, dst' paradigm is the cost of that i'm more than willing to pay that price

But standards are a good thing.

I originally learnt x86 asm from a book and implemented the code in gcc, so had to learn one form and write another -

You know, I don't think I have ever written code in x86 assembler**...

6502, PDP10, PDP11, CDP1802, 68000, T-800 (Transputer), Ti C31, and MIPs, yes, but strangely no x86.

** I have looked at the assembler output of x86 C compilers to see how to re-arrange the C so that it generates more efficient code.

 

[pascal]

8080, 8085, Z80, 68000, TMS32010/20, some NEC dsp, x86 and 8051 here

The microcontroller assembler is fun. Is there any 3D chip available to play with? or any Open Core?