rg20+@andrew.cmu.edu (Rick Francis Golembiewski) (05/02/90)
BARRETT@owl.ecil.iastate.edu (Marc Barrett) writes: > There may be an easy solution, though. Perhaps Commodore should >pick a single graphics coprocessor that would, hereafter, be used in >all Commodore and third-party 24-bit graphics/animation cards. You'de still have to have a library for each graphics card (since it woun't be supplied by C=), and I doubt that a company is going to share too much code with their compeditors.... If C= would define something like an extended graphics library, so that when the companies release their graphics cards they would have a standard to follow, and developers could make thier programs able to load and use the routines in such a library, so that software could actually support these cards, without specific versions for them, this would also be a lot cleaner then trying to patch the current graphics library routines, and it wouldn't break with new releases of the OS. > I like the TMS34030 and the 88000. The 88000 is a RISC chip that >makes a nice coprocessor alongside a 68030 or 68040. The TMS34030 isn't >available yet, but will be by fall, and will be VERY powerful. Yes the 88K is a fast chip, but why not use an actual graphics co processor? (Especially since an 88K graphics card is going to be very $$$). As for the TMS34030, since it isn't available yet, developers are going to have to wait till fall (at least) before they can possibly ship, plus new technology is expensive. When designing a graphics card the main considerations should be is the card going to be fast enough, high res enough etc. for the market that you want to target, not that it uses the fastest available (or soon to be available) technology. -Rick Golembiewski
vilkas@ultima.cs.uts.oz (Peter Sumskas) (05/03/90)
Refer to my earlier article....it expresses much the same thing as Rick G......good on you mate! I agree a standard library is the solution to the graphicboard problem