Jump to content
Sign in to follow this  
Mister VCS

Intellivision: 16-Bit

Recommended Posts

Takes the Intellivision any advance of the 16-bit processor? What is the reason that the most INTV-games doesn' t

look better and are slower than Colecovision-titels (8-bit)?

Why did the devolper use the (expensive) 16-bit processor?

Share this post


Link to post
Share on other sites

What he said. The INTV was a pretty week system actually. But it did pretty well IMO at what it could do. Got rid of the flicker and all that, it just didn't look as pretty as the multi colored sprites of the Coleco cause it was still for the most part useing the single colored sprites like Atari did.

Share this post


Link to post
Share on other sites

What he said. The INTV was a pretty week system actually. But it did pretty well IMO at what it could do. Got rid of the flicker and all that, it just didn't look as pretty as the multi colored sprites of the Coleco cause it was still for the most part useing the single colored sprites like Atari did.

 

Haven't you got that the wrong way round? Atari had the multicoloured sprites more than the CV, and they were brighter colours too.

Share this post


Link to post
Share on other sites

16 bits doesn't help much if your clock speed is measured in kilohertz. And it also doesn't help if your graphics chip is too lame to have single-scanline pixels (which was the main reason I didn't like the Intellivision back in the day).

 

As for Coleco, lack of colors was its main flaw. It only had 15 fixed colors, and it was difficult to use more than two different colors in the same area. But like Video said, they both only supported "single color sprites". You could only use one color per sprite, unless you stacked one or more on top of another sprite. And even then, there were only so many sprites you could use per line (64 pixels worth on Coleco, 16 pixels plus a ball and a couple of missles on the 2600).

Share this post


Link to post
Share on other sites

What he said. The INTV was a pretty week system actually. But it did pretty well IMO at what it could do. Got rid of the flicker and all that, it just didn't look as pretty as the multi colored sprites of the Coleco cause it was still for the most part useing the single colored sprites like Atari did.

 

Haven't you got that the wrong way round? Atari had the multicoloured sprites more than the CV, and they were brighter colours too.

 

Actually, the 2600 can only make 2 8 pixel monochrome sprites per scanline. They can have different colors top to bottome, but not side to side.

 

16 bits doesn't help much if your clock speed is measured in kilohertz. And it also doesn't help if your graphics chip is too lame to have single-scanline pixels (which was the main reason I didn't like the Intellivision back in the day).

 

As for Coleco, lack of colors was its main flaw. It only had 15 fixed colors, and it was difficult to use more than two different colors in the same area. But like Video said, they both only supported "single color sprites". You could only use one color per sprite, unless you stacked one or more on top of another sprite. And even then, there were only so many sprites you could use per line (64 pixels worth on Coleco, 16 pixels plus a ball and a couple of missles on the 2600).

 

I don't know if the Coleco can actually produce multi colored sprites, but it had enough sprite data that it could at least, with the same number of sprites as a 2600 game, produce the illuseion of multi colored sprites.

Share this post


Link to post
Share on other sites

I don't know if the Coleco can actually produce multi colored sprites, but it had enough sprite data that it could at least, with the same number of sprites as a 2600 game, produce the illuseion of multi colored sprites.

It's an illusion. The video chip they used only supports single-color sprites.

BUT it supplies 32 sprites, so you can stack sprites(provided you don't go overboard and hit the 8-sprites-per-line limitation). The red parts are one sprite, the green ones are a separate sprite, etc.

 

 

 

 

 

Related to the topic...

Is it just coincidence that Microsurgeon only wound up on the INTV and 99/4a, both of which used 16-bit processors, or does the game really need something the 6502 and Z80 lacked?

I've always kind of wondered about that.

Share this post


Link to post
Share on other sites

It's an illusion. The video chip they used only supports single-color sprites.

BUT it supplies 32 sprites, so you can stack sprites(provided you don't go overboard and hit the 8-sprites-per-line limitation). The red parts are one sprite, the green ones are a separate sprite, etc.

It's 4 sprites per line, BTW. That makes sprite-stacking unrecommendable on the CV, unless you have a good flicker management system.

Share this post


Link to post
Share on other sites

It's an illusion. The video chip they used only supports single-color sprites.

BUT it supplies 32 sprites, so you can stack sprites(provided you don't go overboard and hit the 8-sprites-per-line limitation). The red parts are one sprite, the green ones are a separate sprite, etc.

It's 4 sprites per line, BTW. That makes sprite-stacking unrecommendable on the CV, unless you have a good flicker management system.

Whoops!

I must've gotten the TMS... whatever it was... limit mixed up with the NES limit.

Share this post


Link to post
Share on other sites

It's an illusion. The video chip they used only supports single-color sprites.

BUT it supplies 32 sprites, so you can stack sprites(provided you don't go overboard and hit the 8-sprites-per-line limitation). The red parts are one sprite, the green ones are a separate sprite, etc.

It's 4 sprites per line, BTW. That makes sprite-stacking unrecommendable on the CV, unless you have a good flicker management system.

Actually, it's 8 8x8 sprites per line, but only 4 16x16 or 16x8 sprites per line. Like I said, 64 pixels of sprites per line.

Share this post


Link to post
Share on other sites

Actually, it's 8 8x8 sprites per line, but only 4 16x16 or 16x8 sprites per line. Like I said, 64 pixels of sprites per line.

The CV has a 16x8 sprite mode? I didn't know that... I also didn't know the number of displayable sprites per scanline doubles when you use 8x8 mode...

 

I'll go to sleep a little less ignorant tonight, so thanks! :D

Share this post


Link to post
Share on other sites
The CV has a 16x8 sprite mode? I didn't know that... I also didn't know the number of displayable sprites per scanline doubles when you use 8x8 mode...

No, I just got confused. The SMS only supports 8x8 and 8x16 (vertical); the TMS9918A supports 8x8 and 16x16 (exclusively one or the other). And for completeness, the Genesis supports 8x8 through 32x32 in any combination.

Share this post


Link to post
Share on other sites
16 bits doesn't help much if your clock speed is measured in kilohertz. And it also doesn't help if your graphics chip is too lame to have single-scanline pixels (which was the main reason I didn't like the Intellivision back in the day).

 

Ironically, the 2600's wonderful graphics are a result of it being even less sophisticated technologically than the Intellivision.

 

Almost all video display systems work by feeding data into display output registers at suitable times; this is true of almost anything more sophisticated than Pong. Most such systems provide hardware to automatically load the output registers with the contents of some sort of addressable memory. The timing of these loads may either be fixed (as is the case with full-screen bitmap or tile-map displays), variable (as is the case with vertically-mobile sprites and occasionally with horizontally-mobile ones as well), or some combination of both.

 

Having hardware manage the loading of the display output registers can make life easier for the programmer, and can allow a lot more data to be displayed than could be managed if the CPU had to do everything. On the other hand, hardware can only do those things that the designer allowed for. If the hardware is designed to read one row of sprite data every other line for eight rows, the programmer gets eight-row sprites at two-line resolution. The programmer might prefer a different size, but he gets what he gets.

 

On the 2600, the processor is responsible for loading the display registers directly. The 6507 is moderately zippy, so it can crank out a lot of stuff, but it can't manage anywhere near the amount of data that can be clocked out by the Intellivision, the O2, the Astrocade, or even the Channel F. On the other hand, unlike those systems, the 2600 can clock out data in whatever order or with whatever timing the programmer sees fit (subject to the speed limitations of the processor). If the programmer wants a sprite that's 40 scan lines tall, with separate color and shape data on every line, no problem. If he wants four sprites per scan line, three of which move together horizontally, while the other moves freely, and he wants all of them have independent color and shape data on every scan line, no problem. A programmer who pushes more data than "usual" on a scan line into some display registers will have to do without updating some of the others, but if the design of the game allows for that, no problem.

 

It may be ironic, but it's true: the reason the 2600 doesn't have the restrictions common to many other systems of the era is that the designers were too cheap to include them. :lol:

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...