Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!taco!hobbes.catt.ncsu.edu!kdarling
From: kdarling@hobbes.catt.ncsu.edu (Kevin Darling)
Newsgroups: comp.sys.amiga.advocacy
Subject: CDTV, CD-I, DCTV, etc
Message-ID: <1991Apr16.071344.20589@ncsu.edu>
Date: 16 Apr 91 07:13:44 GMT
Sender: news@ncsu.edu (USENET News System)
Organization: North Carolina State University
Lines: 39

> 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>