kdarling@hobbes.catt.ncsu.edu (Kevin Darling) (04/16/91)
> DCTV will work with CDTV, however since Commodore hasn't licensed it > for CDTV as default, it won't really be used much. Uh, then why bring it up? :-) No problem, I'll just bring up that Philips promises to supply fullscreen/fullmotion adapters to all original CD-I players, and you can tell me that it doesn't matter, either. Fair? <g> Obviously both players will be upgraded over time; but we're only talking base hardware here. Anyway, still looking for hard DCTV tech info. Any recent articles in the magazines? Perhaps a technical BBS? Thanks! > One thing I don't understand is why CD-I chose RLE compression > for their images. RLE isn't a very good compression technique. It works > best on line art, not raw digitized picturres. You're confusing file storage with video hardware here. Regular video data would be stored/compressed just like any computer. But you're right, RLE is _best_ for such things as cartoons. Which is why realtime non-cpu-assisted RLE display was included as one of many video modes in CD-I. It can give an author some powerful animation playback and storage benefits. Let's take the simplest example: a fullscreen American flag on a black field. CD-I would only use a _few hundred bytes of memory_ to perfectly display it. On a normal (read: Amiga) display, you will always need to take up & move at least _16K_ because the video hardware demands each pixel be explicitly there! (note to CBM hardware crew: please add this mode to your chip wishlist :-). Want to ripple the flag a bit? CDTV = intense cpu/blitter action, or costly multiple screens already in memory. CD-I = flip display pointer to another _tiny_ section of RLE memory data... under copper control alone if wished. The memory and cpu savings can be almost beyond calculation. Think of the game/playback possibilities here, remembering also that the CD-I dual playfield you so casually dismiss means that 128-color RLE animation can go on top of a photographic background which _itself_ can be animated easily since the cpu isn't involved in decoding one field's data in the first place. Am I explaining this badly, or ?? It's actually pretty simple and cool. ready to help - kevin <kdarling@catt.ncsu.edu>
kdarling@hobbes.catt.ncsu.edu (Kevin Darling) (04/16/91)
kdarling@hobbes.catt.ncsu.edu (Kevin Darling) writes: >Let's take the simplest example: a fullscreen American flag on a black field. >CD-I would only use a _few hundred bytes of memory_ to perfectly display it. >On a normal (read: Amiga) display, you will always need to take up & move at >least _16K_ because the video hardware demands each pixel be explicitly there! Actually, I shouldn't have used an American flag as an example here, because most of it is regular enough that either CD-I or CDTV could use repeated normal video lines (via a copper list) to cut down on storage space... and of course someone is bound to pick nits :-) :-). Like I'm doing now. Therefore, pick another flag. Or a fairly fancy background scene (and/or foreground animation) of anything you can imagine. Perhaps clouds building up in the sky, or a very large running cartoon animal, or whatever. For non-photographic data, color RLE can be very fast coming off disc, and/or a win on memory usage in many cases... definitely can be cheaper on the cpu. I'm sure graphics programmers understand the possibilities. thanks - kev <kdarling@catt.ncsu.edu>
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (04/16/91)
In article <1991Apr16.071344.20589@ncsu.edu> kdarling@hobbes.catt.ncsu.edu (Kevin Darling) writes: >> DCTV will work with CDTV, however since Commodore hasn't licensed it >> for CDTV as default, it won't really be used much. > >Uh, then why bring it up? :-) No problem, I'll just bring up that Philips >promises to supply fullscreen/fullmotion adapters to all original CD-I players, >and you can tell me that it doesn't matter, either. Fair? <g> Obviously both >players will be upgraded over time; but we're only talking base hardware here. I thought you already knew DCTV wasn't a part of CDTV. I brought it up to show that CD-I's "impressive" video isn't unique since both DCTV and The Toaster display NTSC composite images. DCTV uses the same encoding as CD-I. DCTV costs $495 list and comes with a digitizer. >Anyway, still looking for hard DCTV tech info. Any recent articles >in the magazines? Perhaps a technical BBS? Thanks! > >> One thing I don't understand is why CD-I chose RLE compression >> for their images. RLE isn't a very good compression technique. It works >> best on line art, not raw digitized picturres. > >You're confusing file storage with video hardware here. Regular video data >would be stored/compressed just like any computer. But you're right, RLE >is _best_ for such things as cartoons. Which is why realtime non-cpu-assisted >RLE display was included as one of many video modes in CD-I. It can give >an author some powerful animation playback and storage benefits. Why bring RLE up if it can only be used for line art animation? What would you rather have, 1/4 screen 15fps HAM or DYUV(DCTV) or full screen cartoons? What I want to know is, what is CD-I's playback rate for FULL COLOR FULL SCREEN digitized data? Assuming a CDROM drive can deliver 170k/sec reliably and the average compressed frame (RLE/vertical byte run, etc) is 30k (generous) it looks like 5-8 frames per second. I still can't believe they are getting 15-24fps full screen with only a 170k/s xfer rate. >Let's take the simplest example: a fullscreen American flag on a black field. >CD-I would only use a _few hundred bytes of memory_ to perfectly display it. >On a normal (read: Amiga) display, you will always need to take up & move at >least _16K_ because the video hardware demands each pixel be explicitly there! >(note to CBM hardware crew: please add this mode to your chip wishlist :-). Yes but on the normal Amiga you can move objects and draw lines and perform manipulations on the flag in real time. How do you render pixels into compressed RLE pics? Probably uncompress it, render, and recompress. CD-I is starting to look cheesy compared to CDTV. >Want to ripple the flag a bit? CDTV = intense cpu/blitter action, or costly >multiple screens already in memory. CD-I = flip display pointer to another >_tiny_ section of RLE memory data... under copper control alone if wished. >The memory and cpu savings can be almost beyond calculation. Yes, but the images must be _canned_ ahead of time on the disk. What about providing a nice windowed/gadget interface with animated video interacting to the user. Canned video is nice, but what a video paint program, or a multimedia authoring disc? Even a 14mhz 68000 can't handle the blitter's speed. So how does CD-I manipulate images with the programmer producing Canned images for all possibilities. >Think of the game/playback possibilities here, remembering also that the CD-I >dual playfield you so casually dismiss means that 128-color RLE animation can >go on top of a photographic background which _itself_ can be animated easily >since the cpu isn't involved in decoding one field's data in the first place. But games need to MOVE different display objects around the screen in response to user input. You can't just have precomputed images on the disk for every object position. With the method you suggest, the only kind of games you could produce are Dragon's Lair look alikes. >Am I explaining this badly, or ?? It's actually pretty simple and cool. > ready to help - kevin <kdarling@catt.ncsu.edu> Yes. I don't understand how CD-I gets full screen full motion full color photographic quality video with just RLE compression and 170k/s xfer rate. Not all data can be compressed. With C-Cube's JPEG compression chip and a fairly fast HD you can do real time animation from a harddrive with 25:1 compression. Why didn't CD-I use this. I envision CD-I software consisting mainly of line-art data. If a programmer has to use photographic non compressible data, he will remove lots of data from the picture to make it smaller and more compressible. For CD-I to achieve atleast 15fps, it needs to compress frames down to 10k. For frame to frame compression on data that doesn't change too fast (a still picture with small object moving in the foreground) this might be possible, but I can imagine CD-I slowing down real quick on real world data. The CD-I consortium should have invested in improving CDROM technology and making it cheap, instead of trying to kludge I-TV on top of such a low bandwidth device. CD-I is not as technically superior to CDTV as you think. So as far as CD-I goes, I'll believe it when I see it. The claims of under $1000 full motion full screen video don't seem real. -- +-----------------------------------------------------------------------------+ | rjc@gnu.ai.mit.edu | // The opinions expressed here do not in any way | | uunet!tnc!m0023 | \X/ reflect the views of my self. | +-----------------------------------------------------------------------------+
es1@cunixb.cc.columbia.edu (Ethan Solomita) (04/17/91)
In article <1991Apr16.071344.20589@ncsu.edu> kdarling@hobbes.catt.ncsu.edu (Kevin Darling) writes: >> DCTV will work with CDTV, however since Commodore hasn't licensed it >> for CDTV as default, it won't really be used much. > >Uh, then why bring it up? :-) No problem, I'll just bring up that Philips >promises to supply fullscreen/fullmotion adapters to all original CD-I players, >and you can tell me that it doesn't matter, either. Fair? <g> Obviously both >players will be upgraded over time; but we're only talking base hardware here. > Yup, so CDTV comes with a blitter, and CD-I doesn't, in the base hardware. 8-) Sorry, you talked yourself into that. -- Ethan Q: How many Comp Sci majors does it take to change a lightbulb A: None. It's a hardware problem.
kdarling@hobbes.catt.ncsu.edu (Kevin Darling) (04/20/91)
[ Sorry for reply delay. In the interest of reader sanity, I'll answer his message in two articles. First, video modes: Later, tech details. ] In <1991Apr16.154153.11706@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: > Why bring RLE up if it can only be used for line art animation? What would > you rather have, 1/4 screen 15fps HAM or [invalid] or full screen cartoons? An incorrect comparison. RLE is just _one_ of the modes (do I have to repeat this ad infinitum?). Obviously it has great advantages in certain cases, especially since it can be overlaid on top of a screen of any other mode. A more comparable choice would be 1/4 screen HAM against either 1/4 screen CDI DYUV, or even against CD-I 256-color mode for that matter. > What I want to know is, what is CD-I's playback rate for FULL COLOR > FULL SCREEN digitized data? Whatever it is, it'll be faster under CD-I for the resolutions you keep talking about. See coming article for why. >>Want to ripple the flag a bit? CDTV = intense cpu/blitter action, or costly >>multiple screens already in memory. CD-I = flip display pointer to another >>_tiny_ section of RLE memory data... under copper control alone if wished. >>The memory and cpu savings can be almost beyond calculation. > > Yes, but the images must be _canned_ ahead of time on the disk. What about >providing a nice windowed/gadget interface with animated video interacting >to the user. Canned video is nice, but what a video paint program, or a >multimedia authoring disc? Even a 14mhz 68000 can't handle the blitter's >speed. One of the advantages of CDROM _is_ that many images can be on disc. It's expected that both systems will try to take advantage of this when able to. Given the RLE example, the cpu can easily be handling user interface details _while_ the animated data comes off disc, with minimal cpu time wasted on the animation. With the CD-I dual video playfields, this is in fact should be incredibly easier to accomplish. But no, obviously you wouldn't use RLE in a video paint program (altho I can think of ways to do it... not much worse than doing the same in CDTV HAM). You'd use the 16 or 128 or 256 color modes instead, don't you agree? Those blitter assumptions will be handled in a later article. > I don't understand how CD-I gets full screen full motion full color > photographic quality video with just RLE compression and 170k/s xfer rate. > Not all data can be compressed. With C-Cube's JPEG compression chip and > a fairly fast HD you can do real time animation from a harddrive with > 25:1 compression. Why didn't CD-I use this. JPEG is meant for stills (altho some Apple/IBM types use it temporarily for motion). MPEG is the one you meant, and is what will be used by players later (both players, we would assume). BTW, neither CDTV nor CD-I are claiming fullscreen/motion video yet. (Where _do_ you get your information? Certainly not from any of my messages.) Sure, Philips had intended to include it in the first CD-I consumer players, but the MPEG standard wasn't finished until just this year (video in September, audio in December), and quantity chip output will take a while to come. > The CD-I consortium should have invested in improving CDROM > technology and making it cheap, instead of trying to kludge I-TV on > top of such a low bandwidth device. Uhh, why do you think both players will be so affordable? That's right: cheap and proven CDROM technology. In addition, it was expected that MPEG would've been finished far sooner than it was. Not their fault. I do agree with you that it would be nice to see faster CDROM drives/etc. Ummmm. So then why did CBM bring out CDTV so prematurely? PS: I'll ask a favor now, if you can take a deep breath and grant it <g>... stay away from blitter topics until I can finish and post an article on that subject. I think that's fair. thanks! - kevin <kdarling@catt.ncsu.edu>
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (04/21/91)
In article <1991Apr20.131149.28247@ncsu.edu> kdarling@hobbes.catt.ncsu.edu (Kevin Darling) writes: >[ Sorry for reply delay. In the interest of reader sanity, I'll answer >his message in two articles. First, video modes: Later, tech details. ] > >In <1991Apr16.154153.11706@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: > >> Why bring RLE up if it can only be used for line art animation? What would >> you rather have, 1/4 screen 15fps HAM or [invalid] or full screen cartoons? > >>>Want to ripple the flag a bit? CDTV = intense cpu/blitter action, or costly >>>multiple screens already in memory. CD-I = flip display pointer to another >>>_tiny_ section of RLE memory data... under copper control alone if wished. >>>The memory and cpu savings can be almost beyond calculation. >> >> Yes, but the images must be _canned_ ahead of time on the disk. What about >>providing a nice windowed/gadget interface with animated video interacting >>to the user. Canned video is nice, but what a video paint program, or a >>multimedia authoring disc? Even a 14mhz 68000 can't handle the blitter's >>speed. > >One of the advantages of CDROM _is_ that many images can be on disc. It's >expected that both systems will try to take advantage of this when able to. Yes, I agree, but there are some times when image manipulation techniques are still needed. Especially with games, you need to be able to move lots of objects around the screen in different motion paths over who knows how many backgrounds. Even dual playfields don't help. >Given the RLE example, the cpu can easily be handling user interface details >_while_ the animated data comes off disc, with minimal cpu time wasted on the >animation. With the CD-I dual video playfields, this is in fact should be >incredibly easier to accomplish. > >But no, obviously you wouldn't use RLE in a video paint program (altho I can >think of ways to do it... not much worse than doing the same in CDTV HAM). >You'd use the 16 or 128 or 256 color modes instead, don't you agree? How are the non-RLE modes store on disk then? >Those blitter assumptions will be handled in a later article. > >> I don't understand how CD-I gets full screen full motion full color >> photographic quality video with just RLE compression and 170k/s xfer rate. >> Not all data can be compressed. With C-Cube's JPEG compression chip and >> a fairly fast HD you can do real time animation from a harddrive with >> 25:1 compression. Why didn't CD-I use this. > >JPEG is meant for stills (altho some Apple/IBM types use it temporarily for >motion). MPEG is the one you meant, and is what will be used by players later >(both players, we would assume). (actually, I meant JPEG, for one reason. JPEG chips have already been fabricated, I have no idea how long it will take for C-cube to design and produce an MPEG chip.) >BTW, neither CDTV nor CD-I are claiming fullscreen/motion video yet. (Where >_do_ you get your information? Certainly not from any of my messages.) >Sure, Philips had intended to include it in the first CD-I consumer players, >but the MPEG standard wasn't finished until just this year (video in September, >audio in December), and quantity chip output will take a while to come. I meantioned awhile ago 'I don't think CD-I has solved the full motion full screen video problem yet.' and someone said 'Wrong, CD-I now boasts full screen video.' >> The CD-I consortium should have invested in improving CDROM >> technology and making it cheap, instead of trying to kludge I-TV on >> top of such a low bandwidth device. > >Uhh, why do you think both players will be so affordable? That's right: >cheap and proven CDROM technology. In addition, it was expected that MPEG >would've been finished far sooner than it was. Not their fault. Why has it taken 5 years for CD-I to finally come near release? Look how fast C= threw CDTV together and got it to market. Actually before I heard about CDTV, I wanted CD-I above anything else (especially above Intel's DVI, or MPC) but I had assumed CD-I would eventually be 30fps TV quality video, then I heard about CD-I's problems with full motion video and stopped following it. >I do agree with you that it would be nice to see faster CDROM drives/etc. >Ummmm. So then why did CBM bring out CDTV so prematurely? I don't know if C='s goals were the same as those originally announced by the CD-I consortium. Also, bring out CDTV first gets them a head start. Just imagine if CD-I came out first? CDTV wouldn't have a chance. >PS: I'll ask a favor now, if you can take a deep breath and grant it <g>... >stay away from blitter topics until I can finish and post an article on that >subject. I think that's fair. thanks! - kevin <kdarling@catt.ncsu.edu> Ok. -- / INET:rjc@gnu.ai.mit.edu * // The opinions expressed here do not \ | INET:r_cromwe@upr2.clu.net | \X/ in any way reflect the views of my self.| \ UUCP:uunet!tnc!m0023 * /
kdarling@hobbes.catt.ncsu.edu (Kevin Darling) (04/21/91)
In <1991Apr20.210243.22134@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: kdarling@hobbes.catt.ncsu.edu (Kevin Darling) writes: >>One of the advantages of CDROM _is_ that many images can be on disc. It's >>expected that both systems will try to take advantage of this when able to. > > Yes, I agree, but there are some times when image manipulation techniques >are still needed. Especially with games, you need to be able to move >lots of objects around the screen in different motion paths over who >knows how many backgrounds. Even dual playfields don't help. Right, so you'd do so just as any computer would, even CDTV. You can do a lot of animation under cpu control, especially without multiple bitplanes. Note that in fullscreen modes, we lose most of our sprites under CDTV... and the blitter and cpu are slowed down immensely in proportion to CD-I. (tech details are coming - I'm way way behind at work right now :) >>But no, obviously you wouldn't use RLE in a video paint program (altho I can >>think of ways to do it... not much worse than doing the same in CDTV HAM). >>You'd use the 16 or 128 or 256 color modes instead, don't you agree? > > How are the non-RLE modes stored on disk then? Same as with any computer. Either straight, or compressed, or delta'd. There's nothing unique about either CDTV or CD-I files, I assure you ;-). >> JPEG is meant for stills (altho some Apple/IBM types use it temporarily for >> motion). MPEG is the one you meant, and is what will be used by players >> later (both players, we would assume). > (actually, I meant JPEG, for one reason. JPEG chips have already been > fabricated, I have no idea how long it will take for C-cube to design and > produce an MPEG chip.) I'm trying to refind an article I saw the other day on AP news. I _think_ they just announced one. Will let you know if I do. Not positive, but Motorola should be working on one now, too. You're right, dunno how long. > [fullmotion/screen video] No problem, Ray. Someone else must've jumped in somewhere with wrong info. > Why has it taken 5 years for CD-I to finally come near release? Look > how fast C= threw CDTV together and got it to market. Right <g>. Let's see. Counting creating the video chips, that makes what, almost _eight_ years from the start until CDTV was announced? :-) :-) Anyone could throw a CDROM drive and computer into a box, once someone else (CD-I) already carefully researched the objective, look, and product market. Any company could've done the same thing (altho only CBM with the Amiga base could have done even a fair imitation as quickly). > Actually before I heard about CDTV, I wanted CD-I above anything else > (especially above Intel's DVI, or MPC) but I had assumed CD-I would > eventually be 30fps TV quality video That's promised on the 1992 players, and as mentioned also promised as retrofit kits for any earlier players. In 1993 or so, MPEG-II (?) should come out, which'll give even higher quality video (I would guess for future HDTV situations? Haven't kept up that much). If CD-I could've waited still another six months, I believe all players would have fullmotion/screen plus a 68020 core. But that's still coming. MPC and DVI of course, are computers/addons... altho I suppose someone will sooner or later throw an Intel cpu into a player box too <shiver>. > I don't know if C='s goals were the same as those originally announced > by the CD-I consortium. Also, bring out CDTV first gets them a head > start. Just imagine if CD-I came out first? CDTV wouldn't have a chance. Yeah, CBM had hoped to beat CD-I by over a year. Now it's down to just months. In fact, I may get to borrow one to show in Chicago next weekend. Letcha know if I do. Maybe should borrow a CDTV player at the same time. thanks - kevin <kdarling@catt.ncsu.edu>