rjc@wookumz.ai.mit.edu (Ray Cromwell) (12/16/90)
[cross posted since it deals with hardware and software vendors/developers] About a year ago if you asked a developer why there aren't any video boards or device independent libraries he might respond: 'There aren't any video boards because there isn't any device independent library support, and there aren't any device independent libraries because there are no video boards.' This type of circular reasoning seemed to suggest the Amiga video market was boxed in at both sides. Miracously, it has broken out of this loop. I can count atleast 10 framebuffers or video mode enhancer boards (HAM-E) now. The reason I'm writing this is because it will be atleast another year before Commodore releases any retargetable specs/libraries, but we need them now. I suggest that the Amiga hardware and software vendors should get together and work towards a temporary stop-gap for video independence. If the PC world can do it (EISA?), so can we. Now I'm not suggesting running Intuition screens on video boards/frame buffers. What I'm suggesting in a simple set of graphic primitives to dump IFF24 bit files to framebuffers. Perhaps, a rtg.library which Commodore can replace at a later date with their own. What this library might contain is calls to plot a pixel, plot a line, do a pattern fill, and dump a scanline. (also routines to read pixels/scanlines, and request screen dimensions). If you haven't noticed, Imagine supports output to Firecracker, Toasterpaint outputs to the Toaster(of course), DCTV and HAM-E have their own paint programs. Its getting redundant having software specially tailored to specific hardware. With a simple library of primitives, current software could utilitize all the new boards coming out. In fact, simple hacks could be created to make current software work without any changes. Simply make a DOS level IFF handler. (IFF: ?) And have software save files to IFF: instead of disk. (I guess it would be better to pipe the data to IFF: and disk. So it isn't lost.) The only thing that would be required is that vendors make their own rtg.device. Then, an Amiga owner could easily put the IFF: handler in his mountlist and have it use the right rtg.device. Please, I don't wish to start any flame wars. Don't respond to this message with posts like 'If Commodore doesn't implement RTG immediately, the Amiga is dead.' Instead of attacking Commodore or the Amiga, why don't we utilitize our combined skills, and actually do something productive- like try and agree on a temporary stop-gap for RTG until Commodore gets their act together-. My ideas are merely suggestions. Lets not get too complicated with stuff like emulating the blitter/copper, and supporting intuition/workbench style windows on video boards. I'm only interested in allowing portability between video software and hardware until real RTG is implemented. (Hopefully ADOS 2.1/2. RTG is easier to do than MMU Protection.) I also realize none of this is needed as we could all go out and buy ASDG's Art Department, process the images, and load them up into dctv/hame/toaster/firecracker24s conversion software. This process is lengthy (it could be automated by arexx assuming all the conversion software had an arexx port and STANDARD commands), but it is much easier to support a dump from a library directly to the attached hardware for display. So now the Amiga is getting a myriad of video boards. I feel one way or another this is going to FORCE an rtg standard. The Amiga is not an IBM, we just can't go poking registers on hardware boards, and making drivers for each board.(like IBM programmers have to do with all those cga/ega/vga/super vga/foobar enhanced vga). Amiga developers are used to having OS facilities to help development. I don't think anyone feels like crafting routines to poke registers on hame/dctv/firecracker everytime they develop some new software.
rwm@atronx.OCUnix.On.Ca (Russell McOrmond) (12/17/90)
In a message posted on 15 Dec 90 19:12:49 GMT,
rjc@wookumz.ai.mit.edu (Ray Cromwell) wrote:
RC>this is going to FORCE an rtg standard. The Amiga is not an IBM, we just can't
RC>go poking registers on hardware boards, and making drivers for each board.(like
RC>IBM programmers have to do with all those cga/ega/vga/super vga/foobar
Well, we do have to do that for Serial Ports due to Software problems.... I'll
be quite happy to see a video standard set, but I'm not going to put any money
down on it.
---
Opinions expressed in this message are my Own. My Employer does not even
know what these networks ARE.
Russell McOrmond rwm@Atronx.OCUnix.On.Ca {tigris,alzabo,...}!atronx!rwm
Use atronx!rwm@carleton.ca ^^^^^^^^ Domain registry in progress
FidoNet 1:163/109 Net Support: (613) 230-2282
Amiga-Fidonet Support 1:1/109daveh@cbmvax.commodore.com (Dave Haynie) (12/18/90)
In article <12437@life.ai.mit.edu> rjc@wookumz.ai.mit.edu (Ray Cromwell) writes: >[cross posted since it deals with hardware and software vendors/developers] > The reason I'm writing this is because it will be atleast another year before >Commodore releases any retargetable specs/libraries, but we need them now. I >suggest that the Amiga hardware and software vendors should get together and >work towards a temporary stop-gap for video independence. At least a few folks have already suggested adopting an existing standard, such as X Windows, Postscript, TIGA, etc. Although C= should set a standard, it would be far better to have two high level imaging standards, one now and one later, that have a chance of being cross translated, than 10 or 15 hardware level "standards" like they have on the IBM PC, which can only be painfully emulated at the register level. >If the PC world can do it (EISA?), so can we. EISA is certainly a standard, though a bus standard. The PC world is still confused about graphics. They just have lots of different standards, with non-standard subvariations. >Now I'm not suggesting running Intuition screens on video boards/frame buffers. >What I'm suggesting in a simple set of graphic primitives to dump IFF24 bit >files to framebuffers. Perhaps, a rtg.library which Commodore can replace at >a later date with their own. What this library might contain is calls to plot >a pixel, plot a line, do a pattern fill, and dump a scanline. (also routines >to read pixels/scanlines, and request screen dimensions). What you're really suggesting is far more than a way to dump IFF24 bit files into framebuffers, but rather some form of retargetable imaging model. All you need to dump IFF files of any kind to any new board is an IFF loader for that particular board. A simple, retargetable imaging model is something far more powerful, since it can be driven interactively by a program, rather than just used to display a canned image. >So now the Amiga is getting a myriad of video boards. I feel one way or >another this is going to FORCE an rtg standard. One would hope so. Unfortunately, its just as possible for software people to drive Amiga display boards individually at the register level, just as they do on the PC. This would not be a good trend, and a little harder on the Amiga than the IBM. IBM itself established most of the register conventions that are emulated by the clones. So, while they changed things around at various levels (MDA, CGA, EGA, MCGA, VGA, etc), it wasn't until VGA (except for Hercules) where lots of different large variations of the basic register model existed. C= isn't promoting this, so everyone on the Amiga is pretty much on their own with register models for display boards. >The Amiga is not an IBM, we just can't go poking registers on hardware boards, >and making drivers for each board.(like IBM programmers have to do with all >those cga/ega/vga/super vga/foobar enhanced vga). It CAN be done that way on the Amiga, but it SHOULDN'T. Because every basic Amiga has Graphics and Intuition libraries, and only a few have other display cards, this hasn't happened yet except for the bundled paint, etc. programs that come with alternate display cards. That doesn't mean it never will... -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "I can't drive 55" -Sammy Hagar
bsyme@cs.strath.ac.uk (Brian J Syme IE88) (12/18/90)
A body has been set up to discuss/develop/define standards for amiga graphics extender cards, etc. called GRAFEXA. Mail me for an address... -- <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> <> Brian Syme <> Why make things difficult, when with just a <> <> bsyme@cs.strath.ac.uk <> little more effort you could make them <> <> <> impossible. <> <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
peter@sugar.hackercorp.com (Peter da Silva) (12/18/90)
In article <16612@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: > At least a few folks have already suggested adopting an existing standard, > such as X Windows, Postscript, TIGA, etc. Uh, what's wrong with maintaining the graphics.library/intuition.library interface? If I ever get another head for my Amiga I damn well want to be able to mouse around it. (X windows? Give me a break!) The BitBlt routines will, of course, have to emulate the blitter. Since the 68020 has the horsepower to beat the blitter (according to Henry Spencer, who is a pretty reliable source) that's not such a great hardship. At least any such RTG interface should provide the same basic interface as graphics.library. Why even consider anything else? In the previous article, someone not Dave Haynie wrote: > Now I'm not suggesting running Intuition screens on video boards/frame > buffers. Why not? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
rjc@wookumz.ai.mit.edu (Ray Cromwell) (12/20/90)
In article <16612@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >In article <12437@life.ai.mit.edu> rjc@wookumz.ai.mit.edu (Ray Cromwell) writes: >>[cross posted since it deals with hardware and software vendors/developers] > >> The reason I'm writing this is because it will be atleast another year before >>Commodore releases any retargetable specs/libraries, but we need them now. I >>suggest that the Amiga hardware and software vendors should get together and >>work towards a temporary stop-gap for video independence. > >At least a few folks have already suggested adopting an existing standard, >such as X Windows, Postscript, TIGA, etc. Although C= should set a standard, >it would be far better to have two high level imaging standards, one now and >one later, that have a chance of being cross translated, than 10 or 15 hardware >level "standards" like they have on the IBM PC, which can only be painfully >emulated at the register level. Right. Register level hardware bashing is ugly and restricts board manufacturers in the design of the board. >If the PC world can do it (EISA?), so can we. > >EISA is certainly a standard, though a bus standard. The PC world is still >confused about graphics. They just have lots of different standards, with >non-standard subvariations. What I mean by EISA, was a rumor I heard that EISA was drawn up by third party vendors instead of IBM. What I meant, is that Impulse,ASDG,Newtek, etc should be able to get together and agree upon a temporary stop-gap. >>Now I'm not suggesting running Intuition screens on video boards/frame buffers. >>What I'm suggesting in a simple set of graphic primitives to dump IFF24 bit >>files to framebuffers. Perhaps, a rtg.library which Commodore can replace at >>a later date with their own. What this library might contain is calls to plot >>a pixel, plot a line, do a pattern fill, and dump a scanline. (also routines >>to read pixels/scanlines, and request screen dimensions). > >What you're really suggesting is far more than a way to dump IFF24 bit files >into framebuffers, but rather some form of retargetable imaging model. All you >need to dump IFF files of any kind to any new board is an IFF loader for that >particular board. A simple, retargetable imaging model is something far more >powerful, since it can be driven interactively by a program, rather than just >used to display a canned image. Yes your right. Basically I wanted ray-tracers,paint-programs,etc to be able to display scanline based images on a video board. >>So now the Amiga is getting a myriad of video boards. I feel one way or >>another this is going to FORCE an rtg standard. > >One would hope so. Unfortunately, its just as possible for software people to >drive Amiga display boards individually at the register level, just as they >do on the PC. This would not be a good trend, and a little harder on the >Amiga than the IBM. IBM itself established most of the register conventions >that are emulated by the clones. So, while they changed things around at >various levels (MDA, CGA, EGA, MCGA, VGA, etc), it wasn't until VGA (except >for Hercules) where lots of different large variations of the basic register >model existed. C= isn't promoting this, so everyone on the Amiga is pretty >much on their own with register models for display boards. Yes, this is the very thing I'm trying to avoid. Its ugly, and limits your software in the amount of hardware configurations it can run on. >>The Amiga is not an IBM, we just can't go poking registers on hardware boards, >>and making drivers for each board.(like IBM programmers have to do with all >>those cga/ega/vga/super vga/foobar enhanced vga). > >It CAN be done that way on the Amiga, but it SHOULDN'T. Because every basic >Amiga has Graphics and Intuition libraries, and only a few have other display >cards, this hasn't happened yet except for the bundled paint, etc. programs >that come with alternate display cards. That doesn't mean it never will... I realize that. I'm hoping most of the Amiga vendors realize this and work together toward a solution. > >-- >Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy > "I can't drive 55" -Sammy Hagar Sorry for the long message (not cutting much out) I'm fairly sick right now, and stuck at 1200 baud.
rjc@wookumz.ai.mit.edu (Ray Cromwell) (12/20/90)
In article <7307@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <16612@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >At least any such RTG interface should provide the same basic interface as >graphics.library. Why even consider anything else? > >In the previous article, someone not Dave Haynie wrote: >> Now I'm not suggesting running Intuition screens on video boards/frame >> buffers. > >Why not? This has been hashed and rehashed before, but I'll explain. Intuition and graphics.library are very tuned to the graphics chip set. How many frame buffers have sprites? A copper? Scrollable bitplanes? A display co-processor? The sad fact of it is, dragable screens, viewports, super bitmap screens, sprites aren't availible on most framebuffers. Some hardware doesn't even use bitplane format(for instance, Chunky Pixmaps). To get around this it may take a year of programming and bug testing to emulate this kind of stuff. We can't wait that long. We need something to make ray-tracers, paint programs, and video processing software work on now. Most of these kinds of programs open up a custom screen and dump scanlines to it directly bypassing intuition. >-- >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>.
rosenber@ra.abo.fi (Robin Rosenberg INF) (12/20/90)
In article <1990Dec19.175634.19203@mintaka.lcs.mit.edu> rjc@wookumz.ai.mit.edu (Ray Cromwell) writes: >In article <7307@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >>In article <16612@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>At least any such RTG interface should provide the same basic interface as >>graphics.library. Why even consider anything else? >> >>In the previous article, someone not Dave Haynie wrote: >>> Now I'm not suggesting running Intuition screens on video boards/frame >>> buffers. >> >>Why not? Of course we need intuition on the new graphics cards. > This has been hashed and rehashed before, but I'll explain. Intuition >and graphics.library are very tuned to the graphics chip set. How >many frame buffers have sprites? A copper? Scrollable bitplanes? >A display co-processor? The *implementation* of Intuition and graphics.library work very closely to hardware. But mostly they are a set of routines and datastructures for drawing graphics and maintaining a user interface. > The sad fact of it is, dragable screens, viewports, super bitmap screens, >sprites aren't availible on most framebuffers. Some hardware doesn't >even use bitplane format(for instance, Chunky Pixmaps). > > To get around this it may take a year of programming and bug testing >to emulate this kind of stuff. We can't wait that long. We need something >to make ray-tracers, paint programs, and video processing software work >on now. Most of these kinds of programs open up a custom screen and dump >scanlines to it directly bypassing intuition. I suggest that a frame buffer become a new kind of ViewPort, so you could open a new screen on the frame buffer. The new screen could then take over the monitor completely (like the A2024) or show up on a separate monitor. Somehow it would be possible to drag the mouse over to the other monitor and make its screen the active one. And nothing would stop us from having any number of monitors, (as many as we can fit graphics cards into the machine). It is quite obvious that graphics.library is not optimal for driving other types of video hardware than the Amiga custom chips, but it is definitely possible. Many of the routines aren't based on a bitplane paradigm and can be translated to any kind of video hardware relatively easy, WritePixel(), ReadPixel(), MoveTo(), Draw(), PolyDraw(), Text(), RectFill(), WritePixelArray, etc. Some of the other routines, e.g. ClipBlit, BltPattern, might require translation from bitplane to packed pixel format (or whatever is used) and vice versa, but that kind of translation isn't too hard to do. The graphics.library is eight bits and that seems to be hardwired into the design of it, so a new set of calls and structures must be defined for 24 bit graphics. The old routines would work work ofcourse, limited to drawing max 256 different colors. Of course there would be the programs that do things assuming a bitplane oriented architechture, but having BOTH the Amigas own video hardware would make it possible to run these programs on the standard monitor in a standard view mode. Only new programs would know how to create a 24 bit screen, and one could allways run Workbench on the standard monitor. ----------- Robin Rosenberg
rjc@wookumz.ai.mit.edu (Ray Cromwell) (12/20/90)
In article <ROSENBER.90Dec20005953@ra.abo.fi> rosenber@ra.abo.fi (Robin Rosenberg INF) writes: >In article <1990Dec19.175634.19203@mintaka.lcs.mit.edu> rjc@wookumz.ai.mit.edu (Ray Cromwell) writes: >>In article <7307@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >>>In article <16612@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>>At least any such RTG interface should provide the same basic interface as >>>graphics.library. Why even consider anything else? >>> >>>In the previous article, someone not Dave Haynie wrote: >>>> Now I'm not suggesting running Intuition screens on video boards/frame >>>> buffers. >>> >>>Why not? > >Of course we need intuition on the new graphics cards. Let Commodore do this. What I am suggesting is a method of allowing software to render to a 'custom' screen display. Most video software does not use Intuition windows, instead they use custom screens. >> This has been hashed and rehashed before, but I'll explain. Intuition >>and graphics.library are very tuned to the graphics chip set. How >>many frame buffers have sprites? A copper? Scrollable bitplanes? >>A display co-processor? > >The *implementation* of Intuition and graphics.library work very >closely to hardware. But mostly they are a set of routines and >datastructures for drawing graphics and maintaining a user interface. Mostly. But some of the things that make the Amiga special are defined as a fundumental part of that interface. Like sprites, viewports, dragable screens, palette control. >> The sad fact of it is, dragable screens, viewports, super bitmap screens, >>sprites aren't availible on most framebuffers. Some hardware doesn't >>even use bitplane format(for instance, Chunky Pixmaps). >> >> To get around this it may take a year of programming and bug testing >>to emulate this kind of stuff. We can't wait that long. We need something >>to make ray-tracers, paint programs, and video processing software work >>on now. Most of these kinds of programs open up a custom screen and dump >>scanlines to it directly bypassing intuition. > >I suggest that a frame buffer become a new kind of ViewPort, so you >could open a new screen on the frame buffer. The new screen could then >take over the monitor completely (like the A2024) or show up on a >separate monitor. Somehow it would be possible to drag the mouse over >to the other monitor and make its screen the active one. And nothing >would stop us from having any number of monitors, (as many as we can >fit graphics cards into the machine). This is almost the same as tossing out intuition. Your new kind of 'viewport' is virtually the same as my suggestion of a set of primitives for rendering to a custom-display device. >It is quite obvious that graphics.library is not optimal for driving >other types of video hardware than the Amiga custom chips, but it is >definitely possible. Many of the routines aren't based on a bitplane >paradigm and can be translated to any kind of video hardware >relatively easy, WritePixel(), ReadPixel(), MoveTo(), Draw(), >PolyDraw(), Text(), RectFill(), WritePixelArray, etc. Some of the >other routines, e.g. ClipBlit, BltPattern, might require translation >from bitplane to packed pixel format (or whatever is used) and vice >versa, but that kind of translation isn't too hard to do. The work entailed to rewrite the entire graphics library and intuition would be tedious and comprehensive. Its easy to talk about doing it, but try it once. I'm all for doing this, but I know it will be a year atleast before any results, thats why the title of my post is called TEMPORARY STOP-GAP. >The graphics.library is eight bits and that seems to be hardwired into >the design of it, so a new set of calls and structures must be defined >for 24 bit graphics. The old routines would work work ofcourse, >limited to drawing max 256 different colors. > >Of course there would be the programs that do things assuming a >bitplane oriented architechture, but having BOTH the Amigas own video >hardware would make it possible to run these programs on the standard >monitor in a standard view mode. Only new programs would know how to >create a 24 bit screen, and one could allways run Workbench on the >standard monitor. Yet another problem. WritePixel is soooo slow on a standard Amiga,many developers craft their own line drawing/pixel plotting routines based on the bitplane. >----------- >Robin Rosenberg
peter@sugar.hackercorp.com (Peter da Silva) (12/20/90)
In article <1990Dec19.175634.19203@mintaka.lcs.mit.edu> rjc@wookumz.ai.mit.edu (Ray Cromwell) writes: > The sad fact of it is, dragable screens, viewports, super bitmap screens, > sprites aren't availible on most framebuffers. How much of this is needed to extend the workbench screen, the way a multiheaded Mac or Sun does it? You don't need draggable screens, for certain. Nor superbitmap screens. And you could probably get away without having a sprite for the mouse. > To get around this it may take a year of programming and bug testing > to emulate this kind of stuff. Probably, but you can design *towards* that goal by using the graphics.library as a model as far as you can go. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
rjc@wookumz.ai.mit.edu (Ray Cromwell) (12/21/90)
In article <7337@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1990Dec19.175634.19203@mintaka.lcs.mit.edu> rjc@wookumz.ai.mit.edu (Ray Cromwell) writes: >> The sad fact of it is, dragable screens, viewports, super bitmap screens, >> sprites aren't availible on most framebuffers. > >How much of this is needed to extend the workbench screen, the way a >multiheaded Mac or Sun does it? You don't need draggable screens, for >certain. Nor superbitmap screens. And you could probably get away without >having a sprite for the mouse. > >> To get around this it may take a year of programming and bug testing >> to emulate this kind of stuff. > >Probably, but you can design *towards* that goal by using the graphics.library >as a model as far as you can go. You still don't understand my point do you? I am 100% PRO-intuition+graphics library being extended to third party hardware. But it will be atleast a year before this happens and there are many people already working on this. I suggest a quick stop gap method that can be availible in 1 or 2 months to prevent developers from banging hardware registers on video boards like what is done on the IBM. So what would you rather do? Wait over 1 year until real RTG is ready meanwhile all the video hardware out is unusable or supported by horrible hacks or have something ready in 1 or 2 months that will keep the market going until Commodore introduces real RTG. The more standards the better. >-- >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>.
kevins@dgp.toronto.edu (Kevin Schlueter) (12/21/90)
Some people are asking why we should accept the limitation of not being able to run intuition on new displays. Basically, the issue is that of 2D graphics vs 3D graphics. By 2D graphics, I'm referring to the graphics used for window and gadget imagery and the graphics found in draw programs, basic paint programs and other common apps. These programs require bitblt and its relatives, rectangle/polygon draw/fill, flood fill, pattern fill, optimized text display routines, etc). By 3D graphics, I'm talking about the kind of graphics required by 3-D modelling and animation programs -- i.e. primitives to support 3D affine transformations, complicated clipping, various types of shading/illumination models, and texture mapping. Often, when designing a framebuffer, you make tradeoffs that favour one type of graphics over the other, in order to keep costs down. For this reason, we should consider whether we need to run _all_ applications on fancy 24 bits frame buffers or whether we should make 24 bit displays that are optimized for modelling and animation. Just a thought...
peterk@cbmger.UUCP (Peter Kittel GERMANY) (12/21/90)
In article <7337@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1990Dec19.175634.19203@mintaka.lcs.mit.edu> rjc@wookumz.ai.mit.edu (Ray Cromwell) writes: >> The sad fact of it is, dragable screens, viewports, super bitmap screens, >> sprites aren't availible on most framebuffers. > >How much of this is needed to extend the workbench screen, the way a >multiheaded Mac or Sun does it? You don't need draggable screens, for >certain. Nor superbitmap screens. But this reminds me a little of the phrase "do we really need multitasking?". Well, all these little details make up the Amiga as it is. And I wouldn't like to trade in any existing feature, that would be a drawback. > And you could probably get away without >having a sprite for the mouse. Hmm, perhaps we really could live with this. But then you need a tremendous software overhead to make sure that every program that manipulates the pointer still works the same. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
peter@sugar.hackercorp.com (Peter da Silva) (12/21/90)
In article <1990Dec20.054258.1952@mintaka.lcs.mit.edu> rjc@wookumz.ai.mit.edu (Ray Cromwell) writes: > Let Commodore do this. What I am suggesting is a method of allowing > software to render to a 'custom' screen display. Most video software > does not use Intuition windows, instead they use custom screens. True. But if the retargetable graphics library interface isn't close to the standard graphics.library/intuition.library interface (and those custom screens do use intuition.library, they just aren't *workbench* screens), then (a) you might prevent Commodore from getting a viable intuition interface for these devices, if your standard takes on a life of its own, and (b) it'll be harder to switch to the regular graphics libraries when C= gets their device independent graphics.library working. > >could open a new screen on the frame buffer. The new screen could then > >take over the monitor completely (like the A2024) or show up on a > >separate monitor. Somehow it would be possible to drag the mouse over > >to the other monitor and make its screen the active one. And nothing > >would stop us from having any number of monitors, (as many as we can > >fit graphics cards into the machine). > This is almost the same as tossing out intuition. No it *isn't*. Remember the Hedley monitor... you can't drag *that* screen down, but you can run a workbench on it just fine. Programs that are too bitplane-dependent won't work on a pixel-mapped screen, but that's their problem. That's what you get when you write hardware specific software. It's not as portable. Plenty of programs should still run. (why did you take comp.sys.amiga.tech out of the newsgroups line? This is certainly an appropriate topic for tech, or for programmer once the great renaming takes place) -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
daveh@cbmvax.commodore.com (Dave Haynie) (12/22/90)
In article <1990Dec20.164538.24027@jarvis.csri.toronto.edu> kevins@dgp.toronto.edu (Kevin Schlueter) writes: >Some people are asking why we should accept the limitation of not being >able to run intuition on new displays. Basically, the issue is that >of 2D graphics vs 3D graphics. My point, when I first mentioned it, was that such a thing would be quite useful. Basically, there are levels of graphic displays. Things like graphics.library and Display Postscript manage an imaging model, which is what you need, with device independence, to draw a picture of some kind on any display. You have to get to that point anyway to go to the next step, which would be having something like Intuition run on an arbitrary display device. Intuition basically deals with the problem of control rather than display (though it has a few higher-level display primitives, they could just as easily been part of graphics). The problem of re-implementing graphics.library has already been tackled by C= software engineers, and it hasn't proven trivial to adjust it for new displays based on the Amiga chip set, like A2024 or ECS. So I don't expect that every 3rd party display maker is going to build a graphics.library equivalent. So far, none of them have. Ideally, Intuition would be fully threaded through graphics, so if you replaced graphics.library and said the proper magic incantations, you would have Intuition running on the alternate display. I doubt reality would be this kind, at least not yet. I would happier than the proverbial pig in sh*t at this point if I could hook up a 1024x1024 or 1600x1200 monitor and have virtually any program display just it's imaging work on the alternate device. This is actually rather common in CAD work, to have separate image and control displays. RTG would be even better, but it would only be gravy for the kind of stuff I do. The other thing to address in an imaging model is printers. Ideally, your display and your printer speak the same exact language, and it should be a higher language then either would naturally speak, since displays and printers don't each do everything well. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "I can't drive 55" -Sammy Hagar
jnmoyne@lbl.gov (Jean-Noel MOYNE) (12/22/90)
In article <16728@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: > I would happier than the proverbial pig in sh*t at this point if I could hook > up a 1024x1024 or 1600x1200 monitor and have virtually any program display > just it's imaging work on the alternate device. This is actually rather > common in CAD work, to have separate image and control displays. RTG would > be even better, but it would only be gravy for the kind of stuff I do. I couldn't agree more, it'd be *really great* if we could run intuition on an alternate display. Because then, it would be possible to have Intuition on 2 screens at the same time. And those of you who have ever used a Mac with 2 screens know what I'm speaking about. This feature of the Mac is _great_ ! And I don't even dare to imagine how cool it'd be with the Amiga multitasking !!!! Of course it isn't easy to do, but if hardware manufacturers could agree on a common set of instructions (requests) you could send to a device driver (then you utilise the driver the vendor provides with the card), it'd be allready something on the right direction. And it wouldn't be too hard to do. When cbm's soft guys modified Intuition for the ECS, the overscan, etc ... I hope they did it a way Intuition is now more adaptable to special displays. JNM -- These are my own ideas (not LBL's) Petit papa Noel ... Heilige nacht .... Jingle Bells ... what a cr*p ! (Punk chrismass)
peter@sugar.hackercorp.com (Peter da Silva) (12/24/90)
In article <1990Dec20.182227.14646@mintaka.lcs.mit.edu> rjc@wookumz.ai.mit.edu (Ray Cromwell) writes: > You still don't understand my point do you? I am 100% PRO-intuition+ > graphics.library being extended to third party hardware. But it will be > atleast a year before this happens and there are many people already > working on this. I suggest a quick stop gap method that can be availible > in 1 or 2 months to prevent developers from banging hardware registers > on video boards like what is done on the IBM. I understand your point quite well. We're busily talking over each other's shoulders at about an 88 degree angle. I'm not saying "make it full intuition RIGHT NOW", I'm saying "use the existing graphics.library as a model". So you can't get all the details right, just try to keep from having to recode everything from scratch should Commodore come out with a device independent intuition.library. Ideally you should be able to replace "rtg.library" with a small library that adds a dob of glue and calls "intuition.library" or "graphics.library" with minimal effort, once everything is in place. If you don't do this you'll be stuck with a situation only a little bit better than on the IBM. Hell, you might already be doing this. My original post was a reaction to the folks who were talking about making it compatible with X or Renderman or something else that would well and truly break high res graphics on the Amiga forever. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (12/24/90)
In article <661@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: > But this reminds me a little of the phrase "do we really need multitasking?". Me too. "Do we really need high-res intuition"? Damn straight we do. > Well, all these little details make up the Amiga as it is. And I wouldn't > like to trade in any existing feature, that would be a drawback. But you wouldn't... you;d still have all that stuff on the first head. You would just gain the ability to run a second head on your Amiga. You need to run two headed *anyway* the way things are, simply because the existing high res cards don't support the workbench. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
kdarling@hobbes.ncsu.edu (Kevin Darling) (12/28/90)
On the subject of doing a stop-gap gfx library for those new video boards out now, two thoughts: 1. Perhaps CBM could/should help out by releasing some preliminary lib plans of their own? Can't hurt, might help in the long run. 2. About the 8-bit limitation in the current gfx library methodology, a reply that someone just posted on a similar topic on CIS struck me as an interesting slant on things: [taken without permission] "24 bit color is already there - the Amiga has had a 24 bit color standard in place for a long time. It's called "IFF". The OS is 8 bit, essentially, so OS operations are limited at the present time to 8 bits or less... apparently. :`) "I say apparently, because the OS can handle 3 8-bit rastports quite well, no one needs to tell it that those are all in the same display. :`)))" kevin <kdarling@catt.ncsu.edu>
jerry@truevision.com (Jerry Thompson) (01/02/91)
Does anyone know how to get in touch with Martin Lowe of Amiga Centre Scotland or the GRAFEXA group? -- Jerry Thompson | // checks ___________ | "I'm into S&M, I loved the peace and solitude | \\ // and | | | | Sarcasm and so much, I invited my friends. | \X/ balances /_\ | /_\ | Mass Sarcasm."
jms@tardis.Tymnet.COM (Joe Smith) (01/08/91)
In article <1990Dec20.164538.24027@jarvis.csri.toronto.edu> kevins@dgp.toronto.edu (Kevin Schlueter) writes: >2D graphics: window and gadget imagery and the graphics found in > draw programs, basic paint programs and other common apps. These > programs require bitblt and its relatives, rectangle/polygon draw/fill, > flood fill, pattern fill, optimized text display routines, etc). >3D graphics: 3-D modelling and animation programs, primitives to support > 3D affine transformations, complicated clipping, various types of > shading/illumination models, and texture mapping. > >Often, when designing a framebuffer, you make tradeoffs that favour one >type of graphics over the other, in order to keep costs down. For this >reason, we should consider whether we need to run _all_ applications on >fancy 24 bits frame buffers or whether we should make 24 bit displays that >are optimized for modelling and animation. I've noticed that Sun has looked into this problem with their SPARCstation 2GT workstation, and decided not to compromise, and instead implemented both. The 2GT has 108 bitplanes! Two sets of 24 bits for doing double-buffered 24-bit true color. Two sets of 8 bits for 256-color overlays. (This allows pop-up menus to be rendered without disturbing the 24-bit image below it.) Two planes for hardware cursor; one to enable, the other to select one of two colors. Plus various other enable planes, 24-bit Z buffer, hardware window clipping. My point is: when designing a high-performance deep-pixel video card that will be used in a windowing environment, manufacturers should consider implementing 24+N bits per pixel. The extra +N bits are for showing things like window borders, menus, and other overlayed graphics. I wonder how many companies designing video cards for the Amiga are working on more than 24 bits. -- Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-C51 | BIX: smithjoe | CA license plate: "POPJ P," (PDP-10) San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga 3000 speaks for me."
martin@IRO.UMontreal.CA (Daniel Martin) (01/08/91)
In article <1402@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: >I've noticed that Sun has looked into this problem with their SPARCstation >2GT workstation, and decided not to compromise, and instead implemented both. >The 2GT has 108 bitplanes! ... >My point is: when designing a high-performance deep-pixel video card that >will be used in a windowing environment, manufacturers should consider >implementing 24+N bits per pixel. The extra +N bits are for showing >things like window borders, menus, and other overlayed graphics. > >I wonder how many companies designing video cards for the Amiga are working >on more than 24 bits. >Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com I wonder how much does it cost, and how many units I would sell on the amiga platform. Take for instance how many people here thinks a 256 color card at 1200$ is overpriced, and doesn't fit on an A500 :-). On a side note, uses of 108 bitplanes on a 1024 * 1024 eats over 14meg of video memory. It can become costly, especially if you want to adress and perform special operations while displaying (need faster chips, prices goes up) Daniel. -- // Daniel Martin Universite de Montreal \\ // MediaLab, ca vous regarde! C.P. 6128, Succursale A, \\ \\// Mail: martin@IRO.UMontreal.CA Montreal (Quebec), CANADA, \\// \/ Tel.: (514) 343-6111 poste 3494 H3C 3J7 \/