rahst7@unix.cis.pitt.edu (Russell A Howard) (05/17/91)
Now there are at least five 24-bit graphics boards for the Amiga - while they will all support the IFF-24 FILE standard, their is no standard way for the Amiga to send graphics info. to the boards. Meaning, if a program wants to directly support and display 24-bit graphics the programmers would have to write different drivers for each board. (READ: THEY WON'T) What we need is a standard way for the Amiga to send info to the display. Not hard at all. The mac does...you can use any graphics board with any program. The IBM doesn't...it's a graphics standard hell! Which way do we want the Amiga to go? All that has to happen is for Commodore to say, "This is how your board needs to recieve data, `cause this is how DPaintXX :-)is gonna send it!" How the board then creates its display (and price) will become the deciding factor for which board you buy - not if it's compatible. What do you think?
al158305@mtecv2.mty.itesm.mx (Gustavo Cordova Avila) (05/17/91)
I don't think the best way would be to say 'send the data such and such way becuz of....(reasons)', rather, I'd say that it should be better to create the guidelines (by C=) for a "24bit.device" or "24bit.library" which would have all the graphics primitives for such an adaptor, that way, many vendors could just write such a .device or .library for their board, and application program writers would be ensured compatability with any 24 bit board simply by following the proramming guidelines, ie: using the .device or .library. Other benefits of this: * You can have several monitors if it's a .device, simply specify a difrent unit number, if the graph board can accomodate you, or if your device can handle various physical boards. * The device doesn't need to be true 24 bit, it can dither if it needs to, simply let the driver do it and don't let the aplication know about it (but have the information ready if a program asks for a device config, or something). and many others I can't think about right know. so, is this a good idea, or is it junk? Gustavo -- | Gustavo Cordova Avila | al158305@mtecv2.mty.itesm.mx | | Electronic Systems Engineering | PL158305@tecmtyvm.bitnet | +--------------------------------+------------------------------------+
tucker@tahoe.unr.edu (Aaron Tucker) (05/17/91)
Although Commodore USA won't admit to it, there are two programmers working on a 24bit graphics library. I am not sure if Commodore Canada, Germany, UK, etc are involved or not. I do know that they are not all that well coordinated with each other, currently. Juan Trevino tucker@tahoe.unr.edu
s8922967@ipc10.tmc.edu (Murray John GILBERT) (05/17/91)
I reckon that the idea of having a "24bit.device" or "24bit.library" would be a good idea. Maybe something vaguely analogous to what X windows is in the sense that it would work regardless of the real capabilities of the underlying graphics hardware. One thing I wonder is that if it was say a library, what would the version number represent, I assume that it would specify the minimum functions that would be in each vendor's version of it, how can we be sure all the required primitives will exist, and how would extensions to the library be handled. Just some muddled thoughts - Murray _ \
es1@cunixb.cc.columbia.edu (Ethan Solomita) (05/17/91)
In article <205@equinox.unr.edu> tucker@tahoe.unr.edu.unr.edu (Aaron Tucker) writes: >Although Commodore USA won't admit to it, there are two programmers working >on a 24bit graphics library. > Very interesting. We kind of assumed this, but confirmation is always good. >I am not sure if Commodore Canada, Germany, UK, etc are involved or not. I do >know that they are not all that well coordinated with each other, currently. > But as far as I know (I'm almost positive) ALL research work has been centralized in West Chester, PA. So coordination isn't a problem. 8-) > >Juan Trevino >tucker@tahoe.unr.edu -- Ethan The constitution isn't perfect, but it's better than what we have now.
kholland@hydra.unm.edu (Kiernan Holland) (05/18/91)
I reckon that the idea of having a "24bit.device" or "24bit.library" would be a good idea. Maybe something vaguely analogous to what X windows is in the sense that it would work regardless of the real capabilities of the underlying graphics hardware. ----- A reply to that (I forgot to hit the "F" button): Well, imagine it, 24-bit color without a color table. I think Xwindows lacks a multi-screen environment like Workbench/Amigados. You could have your 24-bit buffered 1k by 1k card working with the amiga as a workbench environment and a some small blitter controlled 640X400 screens in the background working on more text oriented programs like a compiler/debuger. This would solve all those GUI problems but only for amigados not UNIX. For UNIX you would probably have to have two terminals working side-by-side to do the same sort of work. One can only hope for a SPARC or something to solve those problems. I'm always for .library support. It is very simple too.
dale@boing.UUCP (Dale Luck) (05/18/91)
In article kholland@hydra.unm.edu (Kiernan Holland) writes: >I think Xwindows lacks a multi-screen environment like Workbench/Amigados. Not true, X11 already has the concepts of multiple screens or frame buffers. If the server itself does not support multiple screens you can run more than one server, each controlling a different screen/framebuffer. (Up to a maximum of 10). With the multiple server approach you can even have different GUI's in each screen. Motif, TWM, OpenLook, etc. can all be running concurrently on one box. -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale
kholland@hydra.unm.edu (Kiernan Holland) (05/19/91)
In article <1991May18.061448.26378@ariel.unm.edu> kholland@hydra.unm.edu (Kiernan Holland) writes: >I reckon that the idea of having a "24bit.device" or "24bit.library" would be >a good idea. Maybe something vaguely analogous to what X windows is in the >sense that it would work regardless of the real capabilities of the underlying >graphics hardware. > >----- >A reply to that (I forgot to hit the "F" button): > >Well, imagine it, 24-bit color without a color table. >I think Xwindows lacks a multi-screen environment like Workbench/Amigados. >You could have your 24-bit buffered 1k by 1k card working with the >amiga as a workbench environment and a some small blitter controlled >640X400 screens in the background working on more text oriented >programs like a compiler/debuger. This would solve all those GUI >problems but only for amigados not UNIX. For UNIX you would probably have >to have two terminals working side-by-side to do the same sort of work. >One can only hope for a SPARC or something to solve those problems. > > I'm always for .library support. > >It is very simple too. > Excuse me, I didn't know what I was talking about the other night. I guess I was tooooooo sleeepy or something. Sorry for wasting the bandwidth. Later
brian@grebyn.com (Brian Bishop) (05/20/91)
In article <977@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: > >Not true, X11 already has the concepts of multiple screens or frame >buffers. > >If the server itself does not support multiple screens you can run more >than one server, each controlling a different screen/framebuffer. (Up to >a maximum of 10). >With the multiple server approach you can even have different GUI's in >each screen. Motif, TWM, OpenLook, etc. can all be running concurrently >on one box. >Dale Luck GfxBase/Boing, Inc. This is something I was trying to do recently. I figured that the solution was either configure the server to deal with two displays, or run two servers. But the main problem is: how do you get two servers to share the same keyboard and mouse? Under the implementation I have been running, one server eventually gets confused and shuts down... Is is different under Amiga X or Amiga/UX X? Brian Bishop Zyga Corp. -- Brian Bishop, Software Engineer, Zyga Corporation (brian@grebyn.com) "This one is for the eyes of the other dogs to come."
dale@boing.UUCP (Dale Luck) (05/20/91)
In article brian@grebyn.com (Brian Bishop) writes: >In article <977@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >>Not true, X11 already has the concept of multiple screens or frame buffers. > This is something I was trying to do recently. I figured that the solution >was either configure the server to deal with two displays, or run two servers. >But the main problem is: how do you get two servers to share the same keyboard >and mouse? Under the implementation I have been running, one server eventually >gets confused and shuts down... Is is different under Amiga X or Amiga/UX X? I presume you already know how to start up two different X11 servers on the same machine by using the :<servernum> argument so that they will each listen on different network ports. The Amiga switches pointer-keyboard focus when the left mouse button is clicked. If the mouse is free to move to what ever screen it wants, when a mouse down occurs, Intuition switches the active server to server(screen) that the mouse is over. > Brian Bishop Zyga Corp. -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale
kdarling@hobbes.catt.ncsu.edu (Kevin Darling) (05/23/91)
> [...] What we need is a standard way for the Amiga to send info to > the display. Not hard at all. The mac does...you can use any graphics > board with any program. The IBM doesn't...it's a graphics standard hell! > Which way do we want the Amiga to go? Towards device-independence, naturally. It would be _great_ to be able to say that all 3td party gfx boards could be used with standard software. But there will be a performance penalty, and so: 1. One of the more common current arguments people use to praise the Amiga (and _very_ stupidly, to slam systems which already use device-independent gfx) is based on animation and drawing speed. The irony is palpable, yet interesting to point out anyway :-/. 2. It's likely that whatever solution is worked up, would be called "unfair" by one or more gfx board makers, since it probably wouldn't show off _their_ board's animation capabilities to the fullest extent. 3. Because of 2, there will no doubt always be some software which is hardware-dependent, if for no other reason than to gain sales because of "speed", just as has happened with games for years. > All that has to happen is for Commodore to say, "This is how your board > needs to recieve data, `cause this is how DPaintXX :-)is gonna send it!" Almost every current application would have to be rewritten to use DIG, of course (I only know of a few major apps which don't do direct video ram access... I believe CanDo is one... any others?). Personally, I think that a good bet would be to define a PostScript-style animation language, and then future boards with their own cpu could fly! But that's a huge topic. - kevin <kdarling@catt.ncsu.edu>
ACPS1072@RYERSON <ACPS1072@Ryerson.CA> (05/25/91)
> Personally, I think that a good bet would be to define a PostScript-style > animation language, and then future boards with their own cpu could fly! > But that's a huge topic. - kevin <kdarling@catt.ncsu.edu> There is a thing out there called RenderMan. It has it's downsides, but it is a REAL thing. For more information see the "RenderMan Companion" by Steve Upstill, published by Addison Wesley, 1990 Supposedly source for this renderer can be gotten straight from PIXAR for under $3000... and you get developers status too. (this is pretty old info so the pricing may not be current) Derek Lang<<<<< | ACPS1072@Ryerson | "Get this clown trained. I want him in the games Toronto, ON | until he dies playing. Acknowledge." Canada | - Master Control Program