SegaCD = Greatest CD add on?

Quote:

---

Originally Posted by tomaitheous

Well.. CDDA for music and speech, and ADPCM chip with it's own 64k of ram. I'd say those were a step up from the cartridge based development. Storage space wasn't overly utilized, but contents/space of CD games were more than the current cart sizes out at the time (PCE or MD). I'd say those three things improved games.

---

Hmm, this got me thinking: did the PCE CD ever do any streaming video? I'm not sure what limitations there would be (at least as far as compression would be concerned), the color limitations might be bad as well. (512 color master palette like the Genesis, and more colors available on-screen, but all in seperate 16-color palettes like the Genesis)
You can use low-res uncompressed analog video, but that looks even worse and takes up a lot of memory (less so for B/W), I beleive some early SCD games used this but it also had some games using compression including a version of Cinepak ported to the console. (IIRC this used a 256 color format, though THe SCD couldn't display this many, but I think it used dithering to simulate this)


That brings me to another question concerning video, if the Sega Genesis VDP (and thus Sega CD) could only display with seperate 16-color palettes, how could they use all 64 colors on-screen for video?


On the price issue, wouldn't the SCD have been significantly cheaper if it's was just a CD drive for the MD? (maybe adding just the sound chip as you mention with the PCE; in the SCD's case it had the CD DAC integrated with the added PCM chip) Just the drive and necessary hardware for transferring data to the Genesis hardware; you could even use system cart like the PCE with additional RAM. No added CPU or video ASIC.

Quote:

---

Originally Posted by kool kitty89

(IIRC this used a 256 color format, though THe SCD couldn't display this many, but I think it used dithering to simulate this)

---

Yeah, could be dithering they're referring to. But it could for the codec itself and nothing to do with the actual hardware.

Quote:

---

That brings me to another question concerning video, if the Sega Genesis VDP (and thus Sega CD) could only display with seperate 16-color palettes, how could they use all 64 colors on-screen for video?

---

That's the million dollar question. Truth is, trying to do FMV with tiled graphics versus a real bitmap mode is pain in the ass. You have 4 sub palettes of 16 colors, it's really hard not to have redundant colors through out those four palettes. A single 8x8 tile can only access colors from a single subpalette. PCE has sixteen subpalettes for tiles (another sixteen reserved for sprites) and it's still a pain in the ass to do pic conversions like that. I wrote an app to do color and palette sorting for those 16 palettes for 8x8 tiles. My app usually maxes out at 40-60 colors at best on complex images.

You have a few options: overlay two BG layers to get two subpalettes in a single 8x8 square. You get 32 colors and two subpalettes per tile. Problem is that you eat up almost all your VRAM and have no room for double buffering. Double buffering is important because there's no way the VDP can update an entire 25k in a single vblank. So you'll get "tearing" if you lack a double buffer. Kinda like when your old 486 tried to play FMV ;)

You can use SH/HL on the second layer to kinda artificially increase the subpalettes, still restrictive though and still wastes just as much vram above two overlay BG method (i.e. no room for double buffer for full screen).

You can reduce the size of the FMV by 1/2 and get back that vram for double buffering. Increase color fidelity, smaller window. A lot of SCD games using dithering not just for pseudo color. It makes ERRORs in color reduction less noticeable. Heavy dithering is pretty good for masking this, but you still see it from time to time.

Before the SegaCD/MegaCD came out, the TGCD had the Sherlock Holmes FMV on the system. It ran at 512x high horizontal resolution for the FMV. It was an early code setup to still use the system card and didn't pull in the full transfer width of 150K per second. Since it transfers a lot of data per frame because of the high res, you can see slight pauses (1 or 2 frames) every so many seconds. It Came From The Desert is another FMV on the TGCD before the SegaCD came out. Though the coders sucked, the game is buggy as hell, and the FMV is 15color small window sent to a sprite buffer which is overlayed onto a BG still. John Madden Duo (for the Duo) has FMV. Some of it 30fps but in a really small window. The opening is full screen, but the res is scaled 2x vertically with a H-int linescroll call. The format is called HuVideo and was used in Yuna CD and Gulliver Boy (same game later ported by hudson to the Saturn). HuVideo's color count runs from 70-90 colors per frame but it heavily dithered like SegaCD FMV. And lastly there is a Golf game that uses HuVideo as 20-30fps. HuVideo is a special driver that bypasses the systemcard bios to access the CD hardware directly and maximize transfer rate. Audio is ADPCM compressed @16khz and passed directly to the ADPCM ports (you can write to adpcm ram while it's playing). The single CPU is doing all the work. Manually reading from the CD ports, decoding the palette table, copying data from the CD ports to syscard ram, and coping from the ram buffer to the offscreen buffer in vram. Timing is damn tight. Reading from those CD ports is slow too. what normally takes 10 cycles to copy a byte, takes 24cycles. So there's a lot of dead time on the CPU end. The only saving grace is that the PCE can write to vram during active display without interrupt or corruption. So, except for the palette block, the video is uncompressed. I clocked HuVideo driver at 122k a second (not the full 150k a second of 1x). Probably to buffer for random hicups in the transfer (interfacing with the CD SCSI controller requires polling of status bits until a single sector is ready for read). Driver uses the estimated seek time to do other stuff (audio & video updates). Hmm... that's probably more information that you wanted to know :o

Back to colors maxed for video. There are methods for easing the 8x8 tile to palette association. C64 does this in some modes (by the coder). It involves having a larger tilemap than the screen. And then repositioning the tile map mid screen on certain scanlines to "cut" down the tile size to 8x4 or 8x2 (pce can also do 8x1 because it has a larger definable tilemap). This can be done on the MD and PCE, but I haven't see it used by either in this fashion. It's a great method because it doesn't really require that much more bandwidth or memory, unlike the two layer method.

Fonzy has written a badass app for converting pics to tile/tilemap format for MD. It's pretty impressive.

A little off topic: The DS has tilemap modes in 16colors per 8x8 tile just like 8/16bit console systems. It's fairly popular mode in games. It has 16sub palettes for the tilemap. Nintendo wrote a badass app called Nitro Character that can take a pic convert is into this format (you define how many palettes are available to use). I've seen the results converted to PCE from that and it's really impressive IMO. Could be used for MD too (and SNES or GBA) because you can specify the number of palettes to use, if it weren't for the fact this it's only available via Nintendo's Nitro SDK for NDS. *bastards*

The sega cd is the best addon since its cheap plus it has good games such as android assault, sonic cd, earthworm jim, road rash, and more

Quote:

---

Originally Posted by tomaitheous

Yeah, could be dithering they're referring to.
That's the million dollar question. Truth is, trying to do FMV with tiled graphics versus a real bitmap mode is pain in the ass. You have 4 sub palettes of 16 colors, it's really hard not to have redundant colors through out those four palettes. A single 8x8 tile can only access colors from a single subpalette. PCE has sixteen subpalettes for tiles (another sixteen reserved for sprites) and it's still a pain in the ass to do pic conversions like that. I wrote an app to do color and palette sorting for those 16 palettes for 8x8 tiles. My app usually maxes out at 40-60 colors at best on complex images.

---

The 40-60 colors is for the PC Engine?

Quote:

---

Originally Posted by Chilly Willy

Not the same thing. The PCE CD only changed the way the games were delivered. PCE carts were nasty pieces of crap, so naturally devs switched when they had an alternative. The games then proceeded along a natural evolution as devs got better at making PCE games. The CD had nothing to do with it beyond giving devs a better delivery medium.

---

If we were talking about "biggest hardware upgrading add-on" then of course the Sega-CD has more inside it than other CD-ROMs. But if (in a hypothetical scenario) only crappy Sega-CD games were ever made and Genesis carts reached even greater feats of technical awesomeness than they already have... would people be so quick to call it the "greatest CD add-on"? The gap between Genesis/Sega-CD is already much narrower than that between PCE cards and CDs, both in quality and quantity of games.

A platform is ony as good as it's software just as any add-on is only as useful as what use a player actually gets from it. Genesis carts were pushed so far so often that it stole some of the thunder from Sega-CD games and there's a ton of cart games.

PCE carts are the exact same as Genesis carts, it's simply the way the games were delivered. Why didn't all the devs switch to Sega-CD, since carts are nasty pieces of crap?

A console could've used a punch card add-on and it would've been the greatest add-on if it delivered a greater library of games. If Sega had released a Genesis 64X add-on that was basically a Saturn in a cart, it still wouldn't be greater than the Sega-CD if it didn't have a greater software library.

I think that judging each add-on by it's CD games alone, the PCE is the greatest (but not at the expense of the Sega-CD). Comparing each console's CD games to their cart games, the PCE CD-ROM is also a "greater add-on".

The Sega CD is the best add-on and the only one that was mildly successful. I enjoyed going to Old Towne Video and renting a Sega CD for the weekend long ago. I'd get the Sega CD, two games, 2 litre of pop, and a box of popcorn for $20. Made for a great weekend playing Vay and Lunar. I also enjoyed playing Mansion of Hidden Souls and Night Trap.

Quote:

---

Originally Posted by Ghost Soldier

The Sega CD is the best add-on and the only one that was mildly successful. I enjoyed going to Old Towne Video and renting a Sega CD for the weekend long ago. I'd get the Sega CD, two games, 2 litre of pop, and a box of popcorn for $20. Made for a great weekend playing Vay and Lunar. I also enjoyed playing Mansion of Hidden Souls and Night Trap.

---

Sounds like good times! Renting games for the weekend and trying to squeeze every possible minute of gameplay value out of them was the highlight of my week through the NES and into the Genesis/Sega CD era. :D

Quote:

---

Originally Posted by kool kitty89

The 40-60 colors is for the PC Engine?

---

Yes, for PC-Engine. My app does palette sorting, but the color reduction part isn't finished. So I go back and fourth between the app and manually reducing trouble "spots" in complex images. It builds a palette for all tiles, combines all redundant palettes (small palettes that fit into larger ones). It then reorders palettes into highest priority. It then starts combining palettes for the ones that have less than 16 colors. This process is tricky because there can be many different out comes, so picking one palette at a time; it combines all other palettes into it and records the sub palette total. The build with the smallest total is chosen (well, the first of the smallest - it ignores others of the same size). It does this until that sub palette is full or can absorb anymore, then it goes onto the next subpalette and repeats the process. For some complex pics, it can take up to a minute. You also select which color of the palette is color #0 (very important for tile based systems). This can really effect the size of the sub palettes created. So I have an option to select color #0 and rebuild. You get a visual so you can choose the best output to work with (for images that create overflow subpalettes). For tiles that can't fit into 16 subpalettes, the program finds a subpalette that contains as many colors as possible for that tile and associates it. All colors of that/those tile(s) that don't have a color in the chosen subpalette are given color #0's color (and all colors #'s higher than 16 since a tile can only have 16 colors). This makes it easy to spot the "errors" visually. That last step, I never wrote into the code. It also spits out tons of text files giving all sorts of statistics for the current build/pal sort. I tend to use it more for lossless sorting than lossy conversion.

One of many sample images I've done -> http://pcedev.net//pics/950.png (http://pcedev.net//pics/pic1.pce is the rom with h-blur. Use mednafen or M.E. only). ~41 colors and 16 subpalettes.

But like I said, that's for PCE. I'm sure a better lossy converter would do better (like the NDS one or Fonzie's if it was adapted from 4 to 16 subpalettes).

There was a guy that wrote a lossy converter for PCE that divided the screen into 16 sections. One section per sub palette. Then did color reduction per section. He did RGB reduction and half-tone dithering before hand to get better results -> http://pcedev.net//pics/180.png (86 colors).

Some huvideo pics of the Hudon's Gulliver Boy (Hudson's Saturn port has the sames cinemas, would be fun to do a compare). Colors are in the 70-80 range.
http://pcedev.net//pics/133.png http://pcedev.net//pics/134.png http://pcedev.net//pics/135.png
http://pcedev.net//pics/136.png http://pcedev.net//pics/137.png http://pcedev.net//pics/138.png
http://pcedev.net//pics/139.png http://pcedev.net//pics/140.png http://pcedev.net//pics/141.png
http://pcedev.net//pics/142.png

2 cents:

I think the Turbo CD was the best because Hudson/ NEC introduced it as the wave of the future and they went forward with it- a larger percentage of games and developers went to the CD format and the Hucards/ TurboChip games became the 2nd priority.

While Sega made the Sega CD saying it was the future but never stood behind it 100% as a majority of their software was still on the Sega Genesis and the Sega CD was treated like a side project.

And yea- The Jag CD was a joke,

Potentially the Jag CD could obliterated the other two, but for what it's worth, it was an unnecessary add-on. Nintendo proved that cartridge was not dead when they made their own 64-bit system.

Sega CD owns this poll hands down.

Quote:

---

Originally Posted by gamegenie

Nintendo proved that cartridge was not dead when they made their own 64-bit system.

---

They did???

Quote:

---

Originally Posted by tomaitheous

They did???

---

Nintendo 64...?

Quote:

---

Originally Posted by Baloo

Nintendo 64...?

---

Exactly. Only thing it proved, was that Nintendo were fools :cool:

Quote:

---

Originally Posted by Baloo

Nintendo 64...?

---

Yeah, but how much better could some of those game shave been with CD storage capacity (granted, with highly compressed data in ROM, the largest 32/64 MB -256/512 Mbit cats could compete somewhat with uncompressed CD storage, but at a high price), and how any more 3rd party developers/games would have taken interest with a chearper, less limiting media available?

The base unit would be more expensive to produce with a drive and there would be load times (though with the later start it's conceivable Ninitendo could have used a faster drive), and ther'd be tremendous savings on the discs over carts. They could have eaten the added hardware costs to a large degree, cut the price of the games a bit due to much cheaper media, and still made far more profits per game as well as attracting far more 3rd parties. (and kept more from the SNES days that decided to leave, like Square)

A big reason for going with carts was to have a propritary format that was more easy to regulate and highly resistant/deturrant to piracy. If they'd been thinking ahead, Nintendo could have desigened a propritary disc format that would be similarly resistant (like was done with the GameCube). Had it been designed in parallel with the console hardware starting very close to the begining (say late '93 to early '94) it shouldn't have delayed the release whatsoever, especially considdering the seperate delays in harware development.
Even if they'd used a mini-disc format (like a CD equivelent to the GC disc) it would still hold far more data than the average cart and be far cheaper (and fairly priactical to have multiple disc set games), with around 210 MB, compared to a "700 MB" CD. (which is actualy more like 730-740 MB)

Quote:

---

Originally Posted by kool kitty89

Yeah, but how much better could some of those game shave been with CD storage capacity (granted, with highly compressed data in ROM, the largest 32/64 MB -256/512 Mbit cats could compete somewhat with uncompressed CD storage, but at a high price), and how any more 3rd party developers/games would have taken interest with a chearper, less limiting media available?

The base unit would be more expensive to produce with a drive and there would be load times (though with the later start it's conceivable Ninitendo could have used a faster drive), and ther'd be tremendous savings on the discs over carts. They could have eaten the added hardware costs to a large degree, cut the price of the games a bit due to much cheaper media, and still made far more profits per game as well as attracting far more 3rd parties. (and kept more from the SNES days that decided to leave, like Square)

A big reason for going with carts was to have a propritary format that was more easy to regulate and highly resistant/deturrant to piracy. If they'd been thinking ahead, Nintendo could have desigened a propritary disc format that would be similarly resistant (like was done with the GameCube). Had it been designed in parallel with the console hardware starting very close to the begining (say late '93 to early '94) it shouldn't have delayed the release whatsoever, especially considdering the seperate delays in harware development.
Even if they'd used a mini-disc format (like a CD equivelent to the GC disc) it would still hold far more data than the average cart and be far cheaper (and fairly priactical to have multiple disc set games), with around 210 MB, compared to a "700 MB" CD. (which is actualy more like 730-740 MB)

---

Resident Evil 2 puts that whole question to rest.


It could be done, it could still be done today at even larger memory sizes.