From: Christopher Phillips (shrydar_at_jaruth.com)
Date: 2004-11-03 12:51:19
On 3 Nov 2004, at 18:48, Hatch wrote: > Wow, you sure seem to know your stuff, I know very little about 3D so > your input and advice will be very helpful. *blush* I just noticed you've got an aussie email address - where do you live? I've just "deemigrated" - after nearly eight years in the UK I've moved back to Perth, Western Australia. > A lot of this stuff is more > complex then what I will be designing. My cct is going to be very low > spec. A couple of easy to implement features such as the on the fly > screen filler and the byte filler. As far as assisting in 3D > calculations > I was looking at something a bit simpler, like a 16 bit divider or > something. What simple calculations would you suggest or do you think > would be > the most helpful in speeding up 3D? > *nod* A 32bit/16bit -> 16 bit result divide would be really useful. Even better would be if you also had a 16bit*16bit->32 bit multiplier, whose result could be automagically placed into the input for the divider, to give A*B/C to 16 bit precision with a 32 bit intermediate. > also if I go for a chunky display, > which way should the graphics data be displayed? 200 rows? 320 > columns? other? If you did a chunky display, you would really need to provide hardware assist with filling - either a simple XOR fill, or preferably a triangle fill. A 1MHz 6502 will be seriously underpowered for dealing with 64k of VRAM. As for layout, you could argue either way. 320 columns would let you have a <1page memory mapped EOR buffer though, so I'd probably lean in that direction - then a 3d plotter could scan-convert from left to right rather than top to bottom, and could still use indexed addressing for plotting the edge events into the buffer. Christopher Jam/Shrydar Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.