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.

[Vector2013]

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)

[Barone]

It's FMV . . . just because it's not streaming bitmaps or using bitmap style graphics compression (RLE, LZ77/LZSS/etc, vector quantization -cinepak, etc) doesn't mean it's not FMV.

Bullshit.
Only you seem to use such definition for "FMV".

I'll just let these quotes from Tom which make a lot more sense IMO:

I'd say no. It's either FMV or it's a variant of streaming animation. I think the only exception would be like It Came From the Desert. FMV but the BG is a non moving layer/plate.

Popful Mail isn't FMV by any stretched of the imagination (IMO). Chuck Rock II doesn't look like it either. Just streaming animation. It's variable rate, it's on different planes, and moves around separately and at a higher temporal resolution than FMV can deliver on these target systems, uses mirroring, etc. I'm think FLI format was like this.

I like it better then FMV, but of course it doesn't lend well, or at all, to real live video/stills.

The PCE could have done this with SCD card, easily (ACD, even better). No idea why they didn't. You stream packs of data and ADPCM data. Key parts need to buffer in the heavy animation parts, during the still or looped parts (cycled animation). And Sega pulled got the idea right But wtf, only two games???

As cool as the animation is for SegaCD Popful Mail, I dislike the low color count and color scheme (the blue and red is washed out). Not sir,... I don't like it.

Dark Wizard looks like streaming animation (can here the low sample rate of the audio). Not sure about 3x3 Eyes though (if it's Red Book audio, then it's not). It looks like it could be compressed into a single load with red book audio playback. No PCECD or SegaCD game that I know of, used subchannel data from CDDA to update cinema graphics. So I doubt that's an option. As far as FMV and just updating some tiles per 'frame', yeah that's just a form of compression. Still fits within the format of FMV. Streaming animation is more like a script format. You have x/y scroll registers, sprite offsets, multiple planes, etc.

Lossless video compression could look absolutely identical to precalculated vector animation, no artifacts whatsoever. (well, technically, a LOT of Sega CD FMV is lossless or even uncompressed, but the artifacts come from the conversion methods and how detailed the graphics are in general -shaded polygons already formated for the color restrictions of the MD can be truely losslessly compressed, as can 2D cartoon animation . . . hell, Cinepak can even be used as a lossless compression scheme, it's all a matter of the encoding process)

So you claim something that has not a SINGLE REAL EXAMPLE in the whole Sega CD's library, even considering that it's filled with FMVs?
Looks like Namco was hiding a perfect conversion algorithm then... Interesting they never used such amazing achievement in any other game, to not talk about the PS1 and 3DO versions being full of artifacts.

You also ignore the fact that IF it was possible to use a pre-rendered CG video with no artifacts as you suggest, you would need to create such CG video in the first place. And, in such regard, there's no mention in the credits or whatsoever about it. Just the Namco credits which are identical to the arcade version by the way.
In the 3DO and PS1 versions, which came out later, you'll find the credits for the CG creators, since those versions are actually just FMVs UNLIKE the Sega CD one. And the CG stuff wasn't made my Namco themselves but a third party.

Artifacts (especially dithering and posterization) say nothing specific about whether any compression has been used at all. A ton of Sega CD FMV is uncompressed but still has tons of artifacts from postierzation, dithering, etc.

Oh, thanks.

And I maintain that vector animation is still streaming video . . . so long as it's full-frame animation and not individual vector animated sprites/objects that are then manipulated in realtime. Then it becomes a hybrid realtime animation technique. (like streaming/buffered animation in some multiemdia PC games with animated objects moved across the screen independent of the animation frames themselves -like the Cutscenes in X-Wing or Tie Fighter, or Wing Commander 2 . . . among others -Lunar II and Popful Mail on MCD would also be good examples)

Yeah, again, only you would call it FMV.

[akm]

Yeah.. Call me an idiot, but I think (just from experience in playing most Sega CD games available), that the Sega CD version of Starblade is FMV (sans the wireframe real-time objects, of course). I think the Sega CD can produce the decent-[sharp]-quality FMV in Starblade because the game is embracing a relatively low-color palette. It doesn't look like it's doing anything crazier than something like Silpheed in terms of the background animations (which I assume is fully FMV). If you refer to the later stages of Silpheed that are far more "textured" than earlier stages, it becomes apparent it's FMV. The same rhetoric I think can be applied to Starblade, just on basic correlation. If someone can find deeper reasoning for it, then great, but if not, then I don't see the reason for arguing--it's moot, really.

[Barone]

It's really moot when people come to post without having read the previous posts.

[kool kitty89]

There's plenty of examples of lossless video compression on the Sega CD . . . some of it is using 16 color 2D/3D animation source video, while others are posterized down to 16 colors and loslessly compressed (like Dune, Novastorm, or Microcosm).

It's easy, If you render something that stays within the MD's native color and resolution restrictions internally, it can be perfectly losslessly compressed and then decoded and displayed on the MD looking identical to the source image. And would thus look idential to realtime rendering on the system, except with the potential to go way, way beyond the resource limitations of the hardware.


The reason you don't see it very often is because flat shaded 16 color polygons are bland and limited compared to high-end CGI at the time that was more popular for pushing FMV "eye candy" as such.



Now, what exact compression/encoding method was used for games like Starblade or Silpheed is an interesting academic question in its own right, but in any case the bottom line is it's some sort of precalculated/prerendered/compressed streaming animation. Whether it's vector or raster based, it's still streaming animation.
Both Silpheed and Starblade also use a single BG layer with single 16 color palette and frame by frame animation, so it's definitely FMV and not a more specizlized form of tile/sprite composited animation. (more like what Lunar 2 or Popful Mail's cutscenes do)



I'm going to lean towards raster/bitmap based lossless compression of some sort rather than vector based stuff, since RLE/LZ based compression should be plenty effective and less complex than software rasterization of vector animation, and especially as it's done as full-frame animation. (with Silpheed in particular you also have quite a bit of graphics that aren't just shaded polygons, but explosion/wave effects, planets, and other BG objects that would clearly compress well using conventional lossless bitmap based techniques, and would also explain the lower framerates of the planet surface stages where there's a big chunk of complex graphics that would tend to compress more poorly -and it's lossless, apparently without any added filtering to reduce detail and maintain a higher compression ratio as Cinepak stuff tends to do)

On that note, it's also important to realize that pretty much all those compression schemes on the Sega CD are technically lossless, including Cinepak, and all the "lossy" stuff comes from added filtering and preprocessing applied before or during the encoding process in able to maintain a higher compression ratio. (that, and anything with high framerates, resolution, and/or color, you're at least going to have some "loss" due to down conversion to the MD"s native video format)
Again, anything that already complied with the MD's video/color limitations could be fully compressed using any number of schemes (including CInepak) without added detail loss. In the cartoon animation end of that, Sonic CD's by-hand optimized redrawn pixel art would be a good example . . . the actual game uses low framerate uncompressed 16 color video, but compression could have significantly increased the framerate and/or screen size without any detail loss. (with the very large amount of simple color/shading and very simple/mininal dithering, CInepak would be excellent for losslessly compressing that)

In fact, most Japanese FMV examples would work very well with Cinepak . . . though they'd also work well with LZ based stuff, or simple RLE, and I'm honestly not sure why not even RLE was used. (Wolf Team's stuff could have doubled the framerate at the very least, same for things like Sonic CD or Mansion of Hidden Souls -though more typical cinepak dithering and multi-palette tiling should look better for the latter at least)

Whether that sort of animation is "better" than more detailed/shaded cartoon stuff that ends up more heavily dithered to retain that detail, more like Batman and Robin or Dragon's Lair, is up to aesthetic preference. (there's also some middleground, like using only 1 pass of dithering in "checkerboard" style, like Keio Flying Squadron does)

[retrospiel]

Not sure if it has already been mentioned but Starblade MCD was developed by Technosoft:
http://gdri.smspower.org/wiki/index....ga_CD/Sega_CD)

[M4R14NO94]

Not sure if it has already been mentioned but Starblade MCD was developed by Technosoft:
http://gdri.smspower.org/wiki/index....ga_CD/Sega_CD)

...well, holy shit. I'd never have thought so!

[CRV]

Naosuke Arai from Technosoft is interviewed in the recently-released Untold History of Japanese Game Developers Volume 3. He was the development director on Sega CD Starblade, and here's what he had to say about it: "The indestructible background elements were indeed streaming off the CD based on the player's coordinates. So it was partially real-time, in a way. Other elements were real-time, but there were no actual polygonal calculations." So it's probably using something like others were talking about earlier in the thread, not FMV.

Arai also said he believed they were working through a middleman, but he didn't say which one. Old Internet posts say it was Telenet Japan.