So, like, is Star Blade does use teh FMV for its polygons or not, yo?

[sheath]

From what I have seen quoted the Sega CD CPU at 12.5Mhz should be 50-66% faster than the stock Genesis CPU. The Genesis CPU is rated at 1 MIPS, versus 25MIPS for just one 23Mhz SH-2 in the 32X. I had a rating for the Arm60 in the 3DO somewhere as well but I am not finding it at the moment.

There have also been a number of discussions about how much faster the Sega CD 68k is compared to the Genesis CPU around here and all of them have concluded that the difference was very significant, though not a generational leap. Combining the two, or at least using the two on separate tasks would made the Sega CD even more formidable.

[kool kitty89]

It wouldn't... which is exactly his point. If SCD Star Blade used FMV, you WOULD SEE lots of artifacts and loss of detail since the SCD isn't capable of really good FMV. He pointed out the Silpheed shows artifacts on the background, and we know Silpheed uses FMV. That Star Blade doesn't show these same artifacts is a point in favor of rendered scenes instead of FMV.

Unless lossless compression was used after already down-converting the color to native MD limitations . . . like Silpheed.

Hell, even look at Novastorm: it's posterized as hell, but there's no typical lossy compression artifacting, unlike the 3DO, PSX, or PC versions. (you see blocky compression artifacts in all of those -PC and 3DO probably using Cinepak or a similar vector quantization technique) Sega CD Novastorm seems to use RLE or some other lossless format . . . technically it probably could be a vector quantizer too (with the posterization alone being enough "filtering" to allow a decent compression ratio, but RLE would probably be the easiest)

Also, if Stablade did use streaming precalculated projected 3D coordinates that the system rasterizes in realtime, then why didn't they bother to rasterize the enemies? (they obviously put in the resources to compute/project the 3D points, but just drew vector lines rather than actually filling them -IIRC the ASIC can actually be exploited to draw vector lines too, so that could mean the CPU is just handling the 3D computation)

If only it had better gameplay, the graphics are just phenomenal. Same goes for Soulstar.
If every Sega-CD game looked like that you can bet the system would be more popular than it was.

I like the gameplay of Batman and Robin more than Batman Returns . . . the difficulty is a bit tough at times, but it's a lot of fun and the story/cutscenes add a lot to the feel IMO. (kind of wish they'd pulled more from the TV show's soundtrack for some of the cutscenes -the in-game soundtrack if fine though)

I wonder if there's anything Sega could have done to emphasize that sort of programming among 3rd parties. SoA already did invest a fair amount into ASIC rendering with outsourcing and being supportive of CORE's efforts as well, but I can't help but think they didn't promote that aspect enough publicly. (that and broader use of multimedia in all sorts of games rather than the relatively narrow aspect that tended to be pushed -not just by Sega- . . . PC developers were a bit better about the "not just interactive movies" during the multimedia revolution -Sega probably could have pushed more for certain PC ports too)
That and some realtime polygonal 3D would have been interesting to see beyond Stellar Fire. (with or without use of the ASIC as well -some circumstances might favor using 1Mbit wordRAM mode and disabling the ASIC) That and ray casting height maps. (Doom/Wolf3D/voxel style engines)

At least SoA invested in pushing the hardware to some degree . . . Sega of Japan seems to not really have bothered at all, aside from possibly encouraging some 3rd parties. (really odd given they designed the hardware and tended to be among the top developers for most/all of their other consoles -even the 32x)

Judging from the Namco System 21 board specs, at least one of the PCBs wasn't that far from the Sega CD.

Board 3 : CPU Board - 3rd PCB (looks very similar to Namco System 2 CPU PCB)
CPU: MC68000P12 x 2 @ 12 MHz (16-bit)
Sound CPU: MC68B09EP (3 MHz)
Sound Chips: C140 24-channel PCM (Sound Effects), YM2151 (Music), YM3012 (?)
XTAL: 3.579545 MHz
OSC: 49.152 MHz
RAM: MB8464 x 2, MCM2018 x 2, HM65256 x 4, HM62256 x 2

The System 21 is far, far more powerful than the Sega CD, it's in the same league as Sega's Model 1. The raw CPU grunt may not differ that much much from the MCD, but the DSP resources adds a ton (like the FPUs in the Model 1). Additionally, there's almost certainly some sort of blitter hardware that's not being listed (System-16 has very vague/limited technical information . . . you'd be better off sorting through the emulator documents if nothing else -I'm not going to do that right now though).

I forgot to reply to this first point more thoroughly. I think there are Genesis space sims that have the fisheye effect on the stars in the background. Shadow Squadron on 32X looks to be using the Genesis for the backgrounds and it fisheyes everything. I'm not sure if that is what you meant by the stars having a 3D aspect to them. What I was suggesting about Silpheeds backgrounds is a composite of Genesis CPU/VDP effects with heavily animated background tiles and a smattering of that technobabble 3D vector stuff people have been suggesting.

Not sure what you mean by fish eye (looks like typical starfield projection to me), but Shadow Squadron is all 32x except for the overlays and some parts of the boarder. Likewise, Silpheed's background is all rendered on one layer (stars are part of the FMV layer) with enemies/projectiles rendered on sprites and the HUD on a separate tilemap layer. (so all are accounted for)

I think some of the better FMV games do some of this already, cutting out "FMV" objects and placing them on a regular tile background to eliminate the free floating video artifacts all over the screen. Load Star and Rebel Assault are two that spring to mind, in addition to Stellar Assault's intro.

Not really sure what you mean here either . . . unless you mean static tilemap and/or sprite object overlaid with FMV (you could also blit that into the FMV framebuffer too, depending on the format used -that's how PC games did it too). In that case, you can count Dragon's Lair and Space Ace in there too. Rebel Assault does do that, but it's so horribly optimized in other areas that it's kind of moot IMO. (PC/3DO does the same thing more or less and also has crap video/color optimization given the capabilities -IMO the Sega CD could have done better than the 3DO or PC/Mac versions of Rebel Assault if optimized well enough). In the Sega CD version, the sprites/objects are all blitted onto the FMV buffer layer in Rebel Assault, though a few other things get laid on the 2nd background. (the whole thing still sticks to a fixed 16 color palette AFIK . . . so Atari ST quality color -probably could have been done in identical quality on the Atari STe with a CD drive)

Most FMV railshooters have some sort sprites overlaid (or software sprites drawn to tiles). Sewer Shark did this, as did Loadstar, Rebel Assault, Novastorm, Microcosm, Silpheed, and a few others. Several of them used scaled sprites.

Yeah, simply look at Racing Aces to see the kind of framerates the Sega CD gets in a true 3d, polygonal game.

I wouldn't call that polygonal 3D, and it looks totally crap in any case.

Stellar Fire isn't . . . stellar in the 3D department, but it's a legitimate example at least. (framerate isn't bad either, but there's not a ton of models on-screen -didn't use any textures either)

Geograph Seal on the x68000 is probably more in line with what the MCD could have handled in terms of pure software rendered polygons. (the ASIC leaves room for some interesting additions for scaled sprites, textured ground, and textured polygons though)

Have no idea what you guys are talking about but, Sega CPU was MUCH faster. 12.5 Mhz Vs 7.6 Mhz. About 5 Mhz difference was huge back in the day!

On top of that (aside from the ASIC's rendering features) is that you've got all 12.5 MHz of that without contention, unlike on the MD where you've got to halt the CPU to update VRAM . . . or even slower if you copy to VRAM using the CPU. So even in games where actually sharing most of the workload between the CPUs isn't that attractive, you could have the sub-CPU running full bore and slave the main CPU to minor game related tasks (like I/O handling) and possibly handling bitmap to tile conversion if needed. (the ASIC can do that too, but there's cases where you'd want to disable the ASIC too . . . both for some types of FMV and for software rendering)

So overall, the MCD, even without using ASIC graphics features, is probably at least 2x as fast at software rendering than the MD alone.

Pretty sure the Neo Geo cpu was 12 Mhz also.

Not sure why that matters in this discussion.

[Joe Redifer]

Has anyone ever tried putting a Sega CD 68000 in a Neo Geo or vice versa and gotten it to work? Should theoretically work if you can match the pins, right?

[evildragon]

except the pins are quite different.

[TmEE]

NeoGeo has a vanilla 68K in it like MegaCD has. MegaCD has a PLCC chip and NeoGeo a shrinkDIP. There would be no difference as the chip won't run any faster than the clock fed to it... these are not modern processors that dictate the speed :P

[sheath]

The System 21 is far, far more powerful than the Sega CD, it's in the same league as Sega's Model 1. The raw CPU grunt may not differ that much much from the MCD, but the DSP resources adds a ton (like the FPUs in the Model 1). Additionally, there's almost certainly some sort of blitter hardware that's not being listed (System-16 has very vague/limited technical information . . . you'd be better off sorting through the emulator documents if nothing else -I'm not going to do that right now though).

Yup, I was just tossing out the available documentation and making a rough comparison, nothing more. You never know when somebody will pop in with more technical knowledge.

Not sure what you mean by fish eye (looks like typical starfield projection to me), but Shadow Squadron is all 32x except for the overlays and some parts of the boarder. Likewise, Silpheed's background is all rendered on one layer (stars are part of the FMV layer) with enemies/projectiles rendered on sprites and the HUD on a separate tilemap layer. (so all are accounted for)

I'm not sure what comment original this is referencing. I was referring to Genesis and 32X games with moving dots for stars in a concave view, so they appear more 3D.

Not really sure what you mean here either . . . unless you mean static tilemap and/or sprite object overlaid with FMV (you could also blit that into the FMV framebuffer too, depending on the format used -that's how PC games did it too). In that case, you can count Dragon's Lair and Space Ace in there too. Rebel Assault does do that, but it's so horribly optimized in other areas that it's kind of moot IMO. (PC/3DO does the same thing more or less and also has crap video/color optimization given the capabilities -IMO the Sega CD could have done better than the 3DO or PC/Mac versions of Rebel Assault if optimized well enough). In the Sega CD version, the sprites/objects are all blitted onto the FMV buffer layer in Rebel Assault, though a few other things get laid on the 2nd background. (the whole thing still sticks to a fixed 16 color palette AFIK . . . so Atari ST quality color -probably could have been done in identical quality on the Atari STe with a CD drive)

Most FMV railshooters have some sort sprites overlaid (or software sprites drawn to tiles). Sewer Shark did this, as did Loadstar, Rebel Assault, Novastorm, Microcosm, Silpheed, and a few others. Several of them used scaled sprites.

Yeah, I don't remember the comment I was replying to. What I am referring to is cut out animated objects on top of a static background though. Like in Lethal Enforcers or even Dragon's Layer on Sega CD looking better than full screen FMV typically. Rebel Assault's scenes where you control the person on the ground and shoot enemies is what I was thinking of I'm sure. I would assume that for static screens this method is a lot easier on DMA bandwidth than full screen video and makes for a cleaner look.

I might speculate here that StarBlade is using standard Genesis tiles for the stars and far backgrounds and displaying uncompressed FMV objects for the "3D" stuff on top of that. That's where I was probably going with the streaming vector data too, to save on processing the entire screen doesn't need to be streamed vectors, just the ships, asteroids and whatnot.

[Vector]

What is amazing is that the Genesis makes the clouds and ground for Virtua Fighter (32 x does characters, floor etc) but all the audio is Genesis too. So how can that audio be so clear in that game but muffled as hell in regular Genesis game ? Cool stuff about Sega CD in here.

[kool kitty89]

NeoGeo has a vanilla 68K in it like MegaCD has. MegaCD has a PLCC chip and NeoGeo a shrinkDIP. There would be no difference as the chip won't run any faster than the clock fed to it... these are not modern processors that dictate the speed :P

You'd also probably be totally fine swapping in 8 MHz 68ks on the NG or CD, given how consistently they tend to overclock (especially CMOS ones).

What is amazing is that the Genesis makes the clouds and ground for Virtua Fighter (32 x does characters, floor etc) but all the audio is Genesis too. So how can that audio be so clear in that game but muffled as hell in regular Genesis game ? Cool stuff about Sega CD in here.

Sound quality (for samples) is all up to the quality of the samples (in terms of bitrate, format, and optimization for the conversion to said format) as well as the programming for the sound engine (or specifically the sample playback portion of the engine).

On that note though, Virtua Fighter does use the 32x's PWM channels for all samples, and uses some sampled instruments as well as speech/FX, though the quality really isn't anything beyond what the MD's DAC could be made to do with the Z80 in general. (some of the sampled instruments might be harder to do with the Z80 alone, assuming they're pitch-shifted and not just straight samples)
Several 32x games do just use the Genesis sound hardware, and there's no consistency in quality difference on either, though the 32x's PWM frees up the 6th FM channel on the YM2612 and allows stereo effects (simultaneous left and right channels -YM DAC can only do hard left/right/center panning with all mixed channels panned together). You've got a lot of extra CPU resource on the 32x for sound processing (potentially), so that's the main advantage. (even then there's few examples that even start to show that off)

This is at least true in respect to the way the 32x sound hardware was used historically, with DMA support not possible on the 32x's PWM channels, that gives a lot more potential to sound capabilities. (the difference between the slave SH2 maxing out at around 8 22 kHz channels vs 32+ channels if using DMA -and/or leaving a lot more room for other processing tasks) This feature went unused back in the 90s due to the pre-release dev units having a bug with DMA sound and later updates to the dev kits never addressing the lack of documentation before it was cancelled. (we only have access to it now thanks to some code on a Sega diagnostic cart that wasn't even intended for developer use)

I'm not sure what comment original this is referencing. I was referring to Genesis and 32X games with moving dots for stars in a concave view, so they appear more 3D.

I get that you were talking about starfield effects, but I don't personally see the "concave" or "fisheye" perspective you mention. Some starfield effects do use 3D projection for the particles (including even quite a few examples on old consoles and computers).

Yeah, I don't remember the comment I was replying to. What I am referring to is cut out animated objects on top of a static background though. Like in Lethal Enforcers or even Dragon's Layer on Sega CD looking better than full screen FMV typically. Rebel Assault's scenes where you control the person on the ground and shoot enemies is what I was thinking of I'm sure. I would assume that for static screens this method is a lot easier on DMA bandwidth than full screen video and makes for a cleaner look.

DMA isn't a limiting factor here really . . . though DMA bandwidth limits do hurt for single-buffered games (tearing is more frequent and obvious -like in Rebel Assault), but these techniques don't really help that in any case.

The technique is purely helpful for better visual quality for the streaming FMV. Technically, you could consider it a form of interframe compression since the background is only replaced as needed rather than every single video frame, the difference from typical interframing (even in Cinepak type schemes) is that an entirely separate layer is used for the static (or mostly static) parts of the frame rather than blocks sorted on a grid for motion deltas (or run-length deltas in the case of PC Wing Commander FMV). As such, you get more efficient use of the limited CD data bandwidth and limited compression techniques in-use. (I'm betting the backgrounds are mostly uncompressed and the foreground is lossless compression of some type -maybe RLE- along with sorting out of the transparent tiles) In the specific use on the Genesis (unlike a similar technique applied to a framebuffer system like PC games), you've also got the palette limitations, and any palettes used in the static BGs will befixed until the BG is updated again, therefore the foreground graphics will have a more limited number of unique palettes to use each frame. (it seems likely that each layer has 2 palettes dedicated to it, possibly all 4 used on the foreground but only 2 able to be updated per foreground update and the other 2 reserved as fixed color selections for the BG . . . I can't remember if we did a palette breakdown for that game or not, but I'm confident the foreground has at least 1 15-color palette dedicated to it -and allowed to change each frame- and also that both layer use multiple palettes -since both use more than 16 colors and the foreground shows tile boarder artifacts at times)

I might speculate here that StarBlade is using standard Genesis tiles for the stars and far backgrounds and displaying uncompressed FMV objects for the "3D" stuff on top of that. That's where I was probably going with the streaming vector data too, to save on processing the entire screen doesn't need to be streamed vectors, just the ships, asteroids and whatnot.

Nope. The stars are part of the framebuffer background just like the polygon ships . . . in fact, almost all of the in-game window is done with just one 16 color tile layer, the 2nd layer is just used for the HUD, and the rest is done with sprites. (even the laser fire is drawn to the framebuffer, with only the portion at the tips using sprite animation, choppily animated missile sprites and similar things are hardware sprites too -don't seem to be scaled either)
Since the wireframe objects are drawn to the framebuffer (and lasers are too, etc), that means FMV has to be decoded and drawn to a full bitmapped frame, not decoded to tiles with redundancy sorted out (which Silpheed seems to do), it also barely needs compression at all. The game window is just 192x144, and it runs at 15 FPS, so you'd need less than 1.5:1 compression to pull that off. (far less than what silpheed manages -aside from the detailed planet animations that use lower compression ratios) RLE should handle that easily.




On a separate note, on the game in general: the lack of music (let alone good music) and the bland, weak, and (mostly) apathetic voice acting totally kills the atmosphere of this game IMO. (a problem with the arcade original too)
Albeit, at least it doesn't bait and switch like: http://www.sega-16.com/forum/showthr...?14245-A-X-101 (I'm not a big fan of crosshairs based rail shooters in general, but that game made me want to like it in so many ways it was just frustrating -and by crosshairs I don't mean first person but fixed PoV non-panning, something that's hard NOT to do with FMV, though Rebel Assault tried panning -I think they could have pulled it off too, if they'd made more compromises on the screen size/resolution)