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

[sheath]

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.

I think the same case could be leveled at the cutscenes in Silpheed, and the levels that are solid flat colored polygons are artifact free as well. It is only the more shaded background elements that show artifacts at all.

I would like to know if there is any evidence of either of these Sega CD games rendering 3D, or streaming pre-rendered 3D. I can't see any other way some of these scenes could have been created.

[Joe Redifer]

It's OK, Joe, I think that we don't need to fight due to this "to be FMV or not to be" thing.
And, no, I don't think that you have to examine everything... It's just there for whoever may be interested.

I'm sorry for the mess, was not my intention to bog your thread down... After all, you know how much I enjoy your show.

I'm not upset about possibly being proven wrong. Facts are facts, after all. I think that, so far, we've discovered that Star Blade does something rather unique, but so far we're not sure exactly how it is doing what it is doing. We can conclude the following:

-It's not typical FMV.
-It's not 3D polygons in the typical sense, but perhaps coordinates filled in with color.

Of course this doesn't explain the backgrounds which are simple but not polygonal. If there were low color versions of those backgrounds created, they could be stored as pages and displayed in a manner similar to FMV without any graininess. I'm also not sure that the game has a true z-space or not. The wireframes probably do.

[j_factor]

Googly moogly, I had a long reply and it got moderated. I'm talking about loading additional game data without using a static screen.

I'm pretty sure a lot of games did that to varying degrees. Soul Reaver was impressive for its scale.

[A Black Falcon]

I think the same case could be leveled at the cutscenes in Silpheed, and the levels that are solid flat colored polygons are artifact free as well. It is only the more shaded background elements that show artifacts at all.

I would like to know if there is any evidence of either of these Sega CD games rendering 3D, or streaming pre-rendered 3D. I can't see any other way some of these scenes could have been created.

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

[matteus]

Surely if everything fitted nicely into the MD's colour palettes lossless compression would be possible? Thus no signs of artifacts would be present?

[Barone]

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

Racing Aces seems to be one of the worst programmed games on the Sega CD. It's surely not using its ASIC and the colors are really poor (let alone the sfx).
I don't think it's a valid parameter at all. By the way, which company developed the game??? Hammond & Leyland? Who?
Furthermore, I would not call it a "true 3D, polygonal game". Some of the objects seem to be just 2D sprites poorly scaled.

You also have to consider that Starblade has no AI. It certainly frees some processing resources.

I'm not upset about possibly being proven wrong. Facts are facts, after all. I think that, so far, we've discovered that Star Blade does something rather unique, but so far we're not sure exactly how it is doing what it is doing. We can conclude the following:

-It's not typical FMV.
-It's not 3D polygons in the typical sense, but perhaps coordinates filled in with color.

Of course this doesn't explain the backgrounds which are simple but not polygonal. If there were low color versions of those backgrounds created, they could be stored as pages and displayed in a manner similar to FMV without any graininess. I'm also not sure that the game has a true z-space or not. The wireframes probably do.

It's probably using a set of tricks and certainly benefiting from the facts that everything on the game is on rails and has no AI at all.

[A Black Falcon]

I just think that just like Silpheed, there's no way the Sega CD could possibly render as many polygons as you'll find in Starblade's backgrounds... that the enemies are wireframes is another sign that the backgrounds are prerendered. You are right that there are some destructible ships, but they must be using some kind of tricks there. But I just cannot imagine the Sega CD actually rendering those backgrounds in Starblade... far too many polygons, moving too fast!

Oh, and I like Starblade for Sega CD. It's a good game. My only real complaint is that with only three credits, it's just about impossible to finish. But I think the graphics and gameplay are both good.

As for Racing Aces, just because it's an unknown developer doesn't mean it's a badly programmed game... I think it was just too ambitious for the hardware, sort of like Vortex on the SNES Super FX.

[sheath]

If all we had to see the Sega CD's Graphics CoProcessor's capabilities was Road Rash or even Jaguar XJ220 we could easily say that games like Batman Returns, Battlecorps, BC Racers and others weren't possible with the hardware. That is about the same as saying that Racing Aces demonstrates the Sega CD's polygonal capabilities. We are also talking about an on rails precalculated engine, not a fully 3D engine with full range of movement.

Look at Virtua Cop 1 + 2 on Saturn and compare them to any first or third person polygonal shooter of that generation as an example. Virtua Cop looks a lot more detailed than that generation of hardware could do in a free 3D environment. StarBlade is even less complicated of a game than Virtua Cop, and would only be rendering polygonal objects that are on screen and front facing. Those ships don't have backsides or bottoms because they don't need to. Thinking of it that way, if the Sega CD is capable of rendering in the realm of 5,000-10,000 polygons per second untextured and unlit, StarBlade is in the realm of possibility.

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

[Chilly Willy]

I think the same case could be leveled at the cutscenes in Silpheed, and the levels that are solid flat colored polygons are artifact free as well. It is only the more shaded background elements that show artifacts at all.

I would like to know if there is any evidence of either of these Sega CD games rendering 3D, or streaming pre-rendered 3D. I can't see any other way some of these scenes could have been created.

I can see a way... what they are streaming is not video, it's precomputed vertexes. There are two things that take the most time in 3D: first, computing the coords for everything; second, rendering everything. Star Blade seems to be run on a track, BUT you can still do damage to the ships in real-time. So my current theory of how everything works is they ran everything through a computer for the entire level, saving only the vertex coords for the final projected screen; those coords are streamed off the CD, and the game decides if the poly is drawn or damage is drawn. That way you save half the work in rendering real-time 3D - you are, however, stuck on a rail for the level. Seems to me that would be a great way to do some awesome 32X games as well.

[sheath]

I can see a way... what they are streaming is not video, it's precomputed vertexes. There are two things that take the most time in 3D: first, computing the coords for everything; second, rendering everything. Star Blade seems to be run on a track, BUT you can still do damage to the ships in real-time. So my current theory of how everything works is they ran everything through a computer for the entire level, saving only the vertex coords for the final projected screen; those coords are streamed off the CD, and the game decides if the poly is drawn or damage is drawn. That way you save half the work in rendering real-time 3D - you are, however, stuck on a rail for the level. Seems to me that would be a great way to do some awesome 32X games as well.

Is there an equation for figuring out how many polygons, flat unshaded or vertexes, a particular chip can generate (even if in a vacuum)? I know the ridiculous polygon specs of the PS1, PS2 and Xbox were based on something at least theoretically possible, I just haven't seen the calculations done myself. I would figure that method would be good enough for guestimating the polygon counts of previous systems, at least in capability. I don't think my polygons in memory comparison is really telling of what the systems were capable of.

[Joe Redifer]

Sheath I recovered your massive post that got lost. It's back where it would have been originally. Or at least it should be, unless the moderation validation process is all wonky.

[tomaitheous]

I can see a way... what they are streaming is not video, it's precomputed vertexes. There are two things that take the most time in 3D: first, computing the coords for everything; second, rendering everything. Star Blade seems to be run on a track, BUT you can still do damage to the ships in real-time. So my current theory of how everything works is they ran everything through a computer for the entire level, saving only the vertex coords for the final projected screen; those coords are streamed off the CD, and the game decides if the poly is drawn or damage is drawn. That way you save half the work in rendering real-time 3D - you are, however, stuck on a rail for the level. Seems to me that would be a great way to do some awesome 32X games as well.

Yeah, this is what I was thinking as well. Sounds doable too. I looked at quite few of the files in the SegaCD ISO and the data structure has a non video format looking structure (I looked at it in a few different visual forms. Even if you can't see the data in the form is needs to be in, it still presents itself in a sort visual identifiable form or pattern). It's not structured like completely compressed data (which looks like random noise). It actually has a lot of 16bit values that range up and down in small increments at large periods of time/large pattern. Looks a lot like what vector points moving over time or such.

IMO - though, given that it's a rail shooter and you can't control the 3D perspective at all - that while the background might not be FMV in the most common sense, that it's still just a streaming background. Albeit with some destructible parts, but that's no different that streaming multiple layers and composite them in real time, then allowing a certain circumstance dictate which layer will be disabled/viewed or such. I would gamble a guess to say that the vector points aren't even 3D. That is to say, they might have been 3D at one time but they have been translated into simple 2D coords. I mean, there's no need for the third depth coord. I'm willing to also bet that it provides a *much* better bandwidth from the CD to the unit in terms of displaying such the amount of data to a full screen (the 'destructible' parts being a pretty big bonus too).

The question then is; what process do they use to draw the 2D primitives to the buffer? Is it all the subcpu? Or the subcpu and main cpu drawing different layers (enemies/BG)? Is the ASCI used in anyway to facilitate line drawing? And since is seems the most plausible explanation is that backgrounds are compressed into 2D vertexes/vectors (given all the evidence), that would also explain why some ships or objects are wire frame drawn. Pixel plotting bandwidth is probably the biggest issue. That is to say, you can only write so many pixels in a given time frame. Wireframe vectors (2D or 3D) are easier on processing than solid form just for the fact that the pixel fill rate is tiny in comparison, and so it stands to reason that the system (or routines they route) are hitting their peak bandwidth. I doubt it detects this, more like something they evaluated before hand and made such a decision to avoid slowdown.

I'm also curious, are the enemies/objects ("3D" or vector ones) on the same layer as the 'BG' layer? I suspect that it is (which would also reduce upload bandwidth to the VDP thus increasing frame rate or keeping it at a steady high rate).

Anyway, my 2 cents. This is a pretty interesting discovery too

[Barone]

Thanks, Tom.

You may want to check it (PM previously sent to Chilly this afternoon after his last post and a bit edited now):
I can't make a video 'cause Fraps only work with direct 3D stuff (like Kega Fusion) and thus it doesn't work with Gens_Kmod.
But, please, take a look at these address on the Gens_Kmod debugger 'cause I think that they prove that Sega CD is rendering the whole thing based on pre-calculated stuff. I also double checked Silpheed and there's nothing similar to those crazy things happening at the addresses that I pointed for Starblade (the addresses are using the debugger index, it's easy to locate them) (Use the addresses in a way that they will be in the middle of the scroll if you understand what I mean):

Silpheed:
M68K Ram Viewer:
Genesis (projectiles):
D0A0

M68K Ram Viewer:
Sega CD (objects):
28D48
Sega CD (some counters):
2B950
2B8C0
Sega CD (some rendering or whatever...)
0FFA0


Starblade:
M68K Ram Viewer:
Genesis (player's projectiles):
D9xx
Genesis (enemies' projectiles):
DF40

M68K Ram Viewer:
Sega CD (rendering background or everything):
70000
Sega CD (looks like a list being sequentially read or something like that):
7B120
Sega CD (probably rendering objects):
7FF68

Just complementing the info to avoid mistakes:
CPU->Debug->Sega CD->Sega CD 68K->View PRAM
it's the PRAM not WRAM
Once you have clicked in WRAM you'll get fucked... You'll need to click on "View Disasm" and then the same button will become "View PRAM".

The fact that the original arcade game used 2xM68K processors made think that Namco could have split the processing between Sega CD and Genesis, like they really did!
You'll see in the Sega CD sub-CPU RAM viewer that it's loading great amounts of data from the CD for both Silpheed and Starblade, but in the Starblade it's not so constant as for Silpheed (Starblade's seem to depend on the appearance of new ships in the background) and not so fast as for Silpheed as well.
I analyzed part per part of the extensive Sega CD RAM View, so I'm sure about what I'm saying.


Here's my theory:
- The original arcade game probably used one M68k for the background/non interactive objects and another for the enemies/interactive objects and projectiles.
- The 3D coordinates were calculated on the fly by the TMS32025 (24MHz DSP) and the results were used by both processors by accessing a shared RAM.
- The Sega CD port occurred mainly to the fact that the original code was already in M68K assembly; not for any specific interest of Namco on the Sega CD. After all, Starblade arcade seems to have been huuuuge in Japan since you can find lots of Japanese gameplay videos at youtube, also including several ones for the 3DO version.
- Since the Sega CD would never be able to calculated all those coordinates without that powerful DSP, they used the advantage of the CD, storing all the pre-calculated data for the whole game there. Maybe there was not so many changes in the original source code, it would be just something like "You were fetching those coordinates from TMS32025's shared RAM, now you'll take them from the RAM after loading it from the CD"..
- But, probably, the projectiles had to be calculated on the fly, since it depends on if the player killed or not the enemy. So they used the Genesis processor for this task (including the collision detection IMO) as well as for the explosion and wireframe fragments sprites after enemie's death, since the Sega CD one would be already fully occupied transferring data from the CD to the RAM and rendering the polygons based on the pre-calculated coordinates stored in the RAM.

If you check the addresses that I provided you'll see that Starblade is more CPU intensive on the Genesis than Silpheed.
Silpheed's rendering (if that portion of the memory is really showing the rending or part of it happening) on the Sega CD is also minimal compared to what Starblade does.

I did some other tests after that and games like Stellar Fire and SoulStar seem to have a similar pattern but not so "intensive" as you see in Starblade.

Several FMV games also tested and they mostly look like "dead" in terms of memory usage, just your average constant chunk update for each 1 or 2 seconds while the FMV is being played. Some of them use more the WRAM than the PRAM and some others do the opposite.

[sheath]

Sheath I recovered your massive post that got lost. It's back where it would have been originally. Or at least it should be, unless the moderation validation process is all wonky.

Thanks, that look about right. I'd rather the more technical programmers see the entire stream of consciousness. I really would like to know if the 32-40byte per polygon standard is really a standard. In addition, I would like to know if polygon processing capability can be calculated in any standard means from one processor to another.

[sheath]

I got StarBlade for Sega CD in today. On my X'EYE with RGB output to HDMI and upscaled to 720p on my 40" LCD it's pretty clear this isn't video. I need to pop in Silpheed for a bit and compare, but I never saw artifacts in the polygonal cutscenes or polygonal backgrounds there either. I also always wondered why the framerate of the earth level was so low, if it was pre-rendered why wouldn't they have just rendered all the frames.

-edit-

I just watched Silpheed's intro scene a few dozen times and now I'm watching the first level entrance cutscene. I cannot see any evidence of this being video either. The aliasing from the ultra low resolution polygons makes the ships almost look like they could be made of voxels. The backgrounds in these scenes are definitely something the Genesis CPU could o on its own. They're just flat walls like in Flashback and Out of This World. Then in the game certain aspects look more like they could just be a rotating 2D background, perhaps with some frames of animation, as much as they could be FMV. Other elements look more like FMV, but could just be animated as well.