CompuServe Messages

Mike, >> There is a simple way around the problem for now. Make the images and >> save them to a different drive, then simply copy them in mass over to >> the PAR drive . . . The problem was essentially my fault, in that the Amiga was on site at the customer's facility and I walked in, perhaps a bit overconfident, with my trusty new 3.1 disk and announced that now we could do field rendering (which they had insisted on for this particular project). The result, as you can Imagine, was rather embarassing. The client didn't want to hear about workarounds; they wanted to see me do what I said I could. My fault; I should have tested it out privately. >> We will fix the problem in the RIGHT manner, not just some dumb fix >> that will break something else. Fair enough. >> [w]e will figure out some way of getting this fix to those who have >> the PAR, I trust this answer will suffice for the time being . . . Can't get much fairer than that. Please make sure I'm on your "PAR" list. >> I do find it silly, as a side note, that DPS has not said, hey we >> could make our code look for a file format, if it aint right we will >> just wait for another cycle and see what happens . . . Well — not really. They took a unique approach to a generic problem: how do we do what the PAR needs to do, given how the existing 3D programs work. Their approach was to make the PAR look like another hard drive to the application. But given what the PAR does, it can't completely be treated like a regular hard drive — because it isn't one. That's a basic hardware limitation of the PAR; and it didn't present a problem to 3D applications existing at the time the PAR was developed. One can hardly hold DPS responsible for not knowing how Impulse was going to implement field rendering. It's just a matter of luck that you and Newtek used different methods, and theirs happens not to break the PAR. It could just as well have worked the other way around. Pete