Virtua Racing/Shooters

[KnightWarrior]

I'll bet Virtua Racing could be done on the Sega CD..I was reading in one of my friends EGM about the CD version...

How many shooters are out there for the Sega CD/Mega CD

[Genesis Knight]

Hold on - what does VR have to do with shooters?

[Aarzak]

The reason many game genres (fighting games, sports games, racing games) rarely if at all appeared on the Sega CD is not only because of it's bottlenecked, difficult-to-work with hardware, but because one of said bottlenecks and probably the biggest one was the HORRIBLE 1X CD drive that made games of this type on the CD a chore to play. Look at Mortal Kombat CD & NBA Jam CD for example. That's why a lot of SCD games were either Redbook music-enhanced Genesis ports or RPGs of some sort, as they were easy to work with the limitations of the hardware.

With that said, as far as shooters go on SCD, there's a few (Bari-Arm, Lords of Thunder, Robo Aleste, Silpheed) but nowhere near as much as the Genesis. Oh, and I doubt the SCD could've handled polygons much better than a stock Genesis could. If it could've then Sega wouldn't have invested in the 32X to begin with.

Oh............and while your cart may be 40 Meg and the biggest Genesis cart in existence, it sure doesn't look or sound like it should. The sound and music is horrible and tinny, totally unfitting for the analog Genesis sound hardware. :)

[KnightWarrior]

Hold on - what does VR have to do with shooters?

Without making 2 threads..I just combined it...

[Joe Redifer]

1x was standard for CD-ROM drives at the time. Nobody else had a faster drive. The load times are no worse and are actually better than the likes of the Xbox360 and Wii are in this day and age.

Anyway, the Sega CD could not have done Virtua Racing.

[evildragon]

Joe is right, the CD could NOT have done VR. VR has polygons, Sega CD does not.

[KnightWarrior]

Really..So V.R needed the SVP Chip

[evildragon]

Well duh, that was the point of having the SVP chip.

32X can do it, because it's hardware is better than the SVP chip.

Now, Sega CD 32X, it could be done, but not worth it.

[KnightWarrior]

ah nuts..I didn't think about the 32X CD version...Well I did, I didn't think everyone owned a 32X..more poeple owned a Sega CD

[j_factor]

Couldn't a Sega CD port of Virtua Racing be done by rendering the tracks as streaming FMV (FMV of polygons)? I think the Sega CD can handle enough polygons to make the VR car.

[evildragon]

It doesn't have polygon support at all.

[Sega-17]

I remember that issue from mid 1993. It was just speculation at a time when the editors of EGM were convinced that Silpheed was all being done in real time.

Only the ships and enemies in Silpheed were real time polygons, after all. Sega CD could do vector graphics and polygons and shit, but they were very limited.

Making VR a game with pre-rendered streaming tracks would have been as much fun to play as MegaRace.

[Psy]

Couldn't a Sega CD port of Virtua Racing be done by rendering the tracks as streaming FMV (FMV of polygons)? I think the Sega CD can handle enough polygons to make the VR car.
You'd have to video larger then the displayable area and panning to give the illusion of moving within the footage, while laserdisc arcade boards did this trick I don't think the SegaCD could it, it had enough problems doing full screen video.

[evildragon]

I am afraid that the animated ships in silpheed are streamed fmv from RAM, where the background is full FMV.

I'm not certain of this, but I am sure that's what's going on...

[tomaitheous]

I am afraid that the animated ships in silpheed are streamed fmv from RAM, where the background is full FMV.

I'm not certain of this, but I am sure that's what's going on...

ED: I was thinking the same thing (about the ships). They were rendered into ram and used as frames from a buffer. You notice they never change path or "frame" - they're always fixed (not talking about the FMV BG).

[Aarzak]

Oh well...........at least the game had a great soundtrack.

But yeah..........no polys on the Sega CD!

[j_factor]

Polygons can be rendered on all but the weakest microprocessors. It's only a question of how many. The vanilla Genesis has several polygonal games -- most of them suck ass, though. Sega CD could easily do a nominal amount of polygons. There's no such thing as "polygon support".

[evildragon]

Polygons can be rendered on all but the weakest microprocessors. It's only a question of how many. The vanilla Genesis has several polygonal games -- most of them suck ass, though. Sega CD could easily do a nominal amount of polygons. There's no such thing as "polygon support".
Yes there is. It's called "Hardware 3D Support", meaning, GPU does what the CPU shouldn't.

[Sega-17]

I'm pretty sure the small ships and bosses in Silpheed are realtime polygons.

Also, there was more than one genesis game that used polygon graphics.

[evildragon]

F-22 comes to mind, but it ran like shit.

[Sega-17]

F-22 comes to mind, but it ran like shit.


Yes, and so did Hard Drivin'. Point is, the ships and other non-bg items in Silpheed were small for a reason, as the Genesis/SegaCD Cpu(s) were probably maxed out making those limited shifting polys as smooth as possible.

[j_factor]

Yes there is. It's called "Hardware 3D Support", meaning, GPU does what the CPU shouldn't.

That is not required to render polygons.

[Aarzak]

Alright...........little to no worthwhile poly games on the vanilla Genesis and SCD hardware!

[Genesis Knight]

There were about three poly flight sims, Hard Drivin', LHX Attack chopper, that tank game... From what I remember, they're all actually pretty fun on an overclocked Genesis. (TmEE would know.)

[playgen]

I always thought it was a shame there wern't more flat shaded 3D games, there was some great ones on Amiga that would have been nice to see on Megadrive, like No Second Prizes and Stunt Car Racer.

[evildragon]

That is not required to render polygons.
For decent gameplay it is. That's why SVP chip was even used at all.

[Psy]

F-22 comes to mind, but it ran like shit.
But the SegaCD did turn the system into a dual 68k machine, so in theory you'd have more CPU power to render polygons then the stock Genesis.

[evildragon]

Not well though, that's why Silpheed used FMV.

If you want polygons, it's always better to have hardware that knows what a polygon even is.

[j_factor]

I always thought it was a shame there wern't more flat shaded 3D games, there was some great ones on Amiga that would have been nice to see on Megadrive, like No Second Prizes and Stunt Car Racer.

Hunter was really cool back in the day. I wonder if the Genesis could handle that...

[Psy]

Not well though, that's why Silpheed used FMV.

If you want polygons, it's always better to have hardware that knows what a polygon even is.
The arcade has the TMS34010 (that Texas Instruments wanted Sega to include in the Sega Genesis) but guess what, a stock Genesis was able to run the port of Hard Driven' in software. Of course Sega could have thrown a TMS34010 into the SegaCD as by the time the SegaCD came out they were pretty cheap, would have allowed programmers to easily do basic 3D graphics and would have allowed the SegaCD to ports of slightly more complicated 3D games like Steel Talons and the 3D games on the PC at the time. Sega could have probably even shoehorned Virtual Racing into the SegaCD if it did have a TMS34010 (though it would be watered down).

[tomaitheous]

I'm pretty sure the small ships and bosses in Silpheed are realtime polygons.

Also, there was more than one genesis game that used polygon graphics.

Rendered into a cache/buffer system and used as frames(sprites - hence the size). I wouldn't call that realtime.

I agree that the second SUB-CPU (@12.5mhz) could have been used for polygons (but to what point - I dunno). The Genesis not having a bitmap mode still bogs down the process of rendering polygons to a buffer (before sending to the display) - regardless of the either CPU. Maybe the SUB-CPU could render the polys to a bitmap buffer and the main cpu convert it to tile/map format on the fly(might take 2 or 3 frames per conversion).

[evildragon]

Rendered into a cache/buffer system and used as frames(sprites - hence the size). I wouldn't call that realtime.

I agree that the second SUB-CPU (@12.5mhz) could have been used for polygons (but to what point - I dunno). The Genesis not having a bitmap mode still bogs down the process of rendering polygons to a buffer (before sending to the display) - regardless of the either CPU. Maybe the SUB-CPU could render the polys to a bitmap buffer and the main cpu convert it to tile/map format on the fly(might take 2 or 3 frames per conversion).
Yes, the lack of buffer. This is why my SegaMac hoax isn't even possible, there's no true way to address a single pixel on the screen.

This however, is the max of my knowledge on the VDP. I know it runs in character mode, and that's it.

[Fonzie]

Well, the segacd have a framebuffer memory mode... so you render exactly like in a normal BMP framebuffer and it is automatically converted to tiles (at full speed).
Also, while the subcpu render the next 3d frame, the main cpu have all time to DMA the picture and update gameplay things...
So I would say that, to render polygons in software, the tandem mcd+md is probably 3 times faster than a single md (can render while dma, bmp2tiles conversion is automatic, true 4bit framebuffer, rendering cpu is 75% faster).

It is possible to render polygons in hardware with the megacd... or at least, vector lines. It is more a tweaking than a true polygonal feature.
But when you render using hardware, you cannot anymore use some other features so the speed would drop compared to software rendering, i guess.

It's a shame no polygonal games took advantage of this hardware... Yeah, 3 times faster, probably.

Fonz

[Aarzak]

The "dual 68000-processor" ability of the Genesis/Sega CD combo apparently isn't anywhere near what it's hyped to be. The combo works differently and nowhere near as well as Sega's dual-processor arcade boards.

[evildragon]

Yea, one CPU actually gets haulted for the other to do the work, if I'm not mistaken.

[Psy]

Yea, one CPU actually gets haulted for the other to do the work, if I'm not mistaken.
Actually the issue is the the CPUs are in series were the SegaCD CPU has to hand its output to the Genesis CPU.

[Fonzie]

Well, I should shut up then (usually, when I write about something its because I owned it before..) ;) If you want to stay with unfounded theories, it is a choice too.

Bye

[evildragon]

I would rather hear the truth.

[tomaitheous]

Well, the segacd have a framebuffer memory mode... so you render exactly like in a normal BMP framebuffer and it is automatically converted to tiles (at full speed).
Also, while the subcpu render the next 3d frame, the main cpu have all time to DMA the picture and update gameplay things...
So I would say that, to render polygons in software, the tandem mcd+md is probably 3 times faster than a single md (can render while dma, bmp2tiles conversion is automatic, true 4bit framebuffer, rendering cpu is 75% faster).

It is possible to render polygons in hardware with the megacd... or at least, vector lines. It is more a tweaking than a true polygonal feature.
But when you render using hardware, you cannot anymore use some other features so the speed would drop compared to software rendering, i guess.

It's a shame no polygonal games took advantage of this hardware... Yeah, 3 times faster, probably.

Fonz


Hey Fonz,

When you say automatically converted to tiles at full speed, are you referring to brute force method of the main CPU or the ASIC? I know ASIC has bitmap output mode, but I wasn't aware of any BMP input mode.



Actually the issue is the the CPUs are in series were the SegaCD CPU has to hand its output to the Genesis CPU.

Right, but I would call it an issue per say. You can swap out either 1megabit (128k) buffer between of the SUB-CPU and man CPU instantly (like NES mappers) or use the 2 megabit memory mode and have the main CPU run in system ram. Either way is instantaneous. The only issue I ever saw with the SEGACD setup was the small amount of memory available to the main CPU in comparison to the SUB-CPU. If the SEGACD had it's own VDP then I could understand the layout, but otherwise it's kind of strange.

[Zebbe]

I would rather hear the truth.

How much Mega Drive/Mega CD programming experience do you have compared to Fonzie?

[evildragon]

How much Mega Drive/Mega CD programming experience do you have compared to Fonzie?
Not enough. That's why I would rather him here telling us things, rather than other people coming up with things.

[Fonzie]

When you say automatically converted to tiles at full speed, are you referring to brute force method of the main CPU or the ASIC? I know ASIC has bitmap output mode, but I wasn't aware of any BMP input mode.

In flipflop 1M ram mode, the other unused 1M is a mirror of the first one in hardware BMP2TILES conversion on the genesis side.
On megacd side, the unused 1M area is a mirror of the other 1M but with several little modes possible, I remember reading about a byte>4bpp automatic conversion which is quite handy because a cpu can't write one single pixel at a time without hardware help*.

* On megadrive 3d rendered games, they either had to write 2 similar pixels at a time (so the second pixel is mostly dithering garbage) or they used some slow cpu manipulation to write 2 different pixels at a time.

[tomaitheous]

In flipflop 1M ram mode, the other unused 1M is a mirror of the first one in hardware BMP2TILES conversion on the genesis side.
On megacd side, the unused 1M area is a mirror of the other 1M but with several little modes possible, I remember reading about a byte>4bpp automatic conversion which is quite handy because a cpu can't write one single pixel at a time without hardware help*.

* On megadrive 3d rendered games, they either had to write 2 similar pixels at a time (so the second pixel is mostly dithering garbage) or they used some slow cpu manipulation to write 2 different pixels at a time.

Oh, I see (page 13 of the manual). I interpreted it backwards (ASIC full graphic function). The input it bitmap(scanline) format and the output is 4bit cell format. That is pretty handy :D

[KnightWarrior]

How do you guys know this...Where did you find this info

[Fonzie]

I know this because I had programming sessions on megadrive, megacd and 32x... However, lately, a part of the official documentation was leaked... It should be easy to find on google.

[Psy]

I know this because I had programming sessions on megadrive, megacd and 32x... However, lately, a part of the official documentation was leaked... It should be easy to find on google.
How hard would it be for the home brew community to develop for the SegaCD? Most use the Dreamcast since it is easy to get around protection, a few are trying their hand on Saturn but I have yet to see a real effort to bring home brew games to the SegaCD.

[playgen]

I doubt its simply the ease of using copied CD's that attracts people to Dreamcast development, more likely not having to code in assembly and the more capable hardware. You can use copied CD's on a MegaCD too.

[Joe Redifer]

Fonzie is developing a Sega/Mega CD game. Codename: Tavern RPG.

[Psy]

I doubt its simply the ease of using copied CD's that attracts people to Dreamcast development, more likely not having to code in assembly and the more capable hardware. You can use copied CD's on a MegaCD too.
Well Saturn is seeing a bit of home brew action due to Game Basic a 3rd party development kit for the Sega Saturn released in Japan and Saturn development tools created by the home brew community. You can see the projects here SEGA Saturn Coding Contest 2006 (http://www.rockin-b.de/c4/2006/results.html)

I would think all the SegaCD would need is a development kit for the homebrewers and it would also see home brew games.

[Benjamin]

Well Saturn is seeing a bit of home brew action due to Game Basic a 3rd party development kit for the Sega Saturn released in Japan and Saturn development tools created by the home brew community. You can see the projects here SEGA Saturn Coding Contest 2006 (http://www.rockin-b.de/c4/2006/results.html)

I had Game BASIC for a bit which I bought out of curiosity. It had a pretty nice shooter bundled with it to show off what is possible, but it wasn't worth anywhere near what it cost me. The Japanese manual and menus were off-putting, too. I'm also pretty positive that Game BASIC was a first party release, though it's been a while. Still, people will develop for what interests them, and I'm sure Dreamcast's Windows CE compatibility and a more mainstream audience far outweigh some inferior system's moon language resources when discussing homebrew appeal.

[tomaitheous]

I doubt its simply the ease of using copied CD's that attracts people to Dreamcast development, more likely not having to code in assembly and the more capable hardware. You can use copied CD's on a MegaCD too.

If I remember correctly, Fonzie uses C compiler for his MD and MCD dev. Although ASM is much more fun :D

[j_factor]

I don't understand Game BASIC. People weren't really programming in BASIC anymore by that time. It must be rather limited.

[Psy]

I don't understand Game BASIC. People weren't really programming in BASIC anymore by that time. It must be rather limited.
Game Basic was a 3rd party devlopment kit by ASCII Entertainment that was aimed at hobbyist programmers in Japan.

[j_factor]

I know what it was. I specifically remember when it came out, and I read a review of it on saturnworld.com. They basically said it was useless.

[TmEE]

If you know BASIC well you can do wonders in it... but in any case, I'll be doing ASM dev on everything I'll try out (simply because I don't know C, and I hate its syntax too much to learn it). I wonder how fun would be to ASM for DC ? All I need for dev are good documents on hardware... I'm not going to use any dev kits, I'll write my own ;) (like I'm doing for the MD)

[tomaitheous]

All I need for dev are good documents on hardware... I'm not going to use any dev kits, I'll write my own ;) (like I'm doing for the MD)

I totally agree. It's also the best way to really learn the system in and out.

[KnightWarrior]

Is there any sites I could look up on how the Genesis/Sega CD Tick

[ary incorparated]

Who cares for this i,ve seen polygon arcade conversions to sega genesis and saturn and they looked miserable,like example then vf or Vracing,i dont blaim the 32x because it handeld them fairly well i apreciate vf for that system much,on the other side it looked shitter on saturn which could have run the arcade version with ease,it is a game from 92 and saturn is from 94 95 and powerfull enough.VR on a genesis model 1 looks great,oaky you have some blur but i like the filter thing manipulation which makes up colour that arent even in the pallet etc(something like that)which makes vracing barable to look,on genesis model 2 it looks horrific but oevral it,s on with stunt race which isnt that good looking either.

I think its more something of the later generation which didnt even show a decent port of the arcade greatness of virtua fighter.if where talking polygon i give the 32x the most credit for it if concerning sega only.I dont get why people want another vr with another svp chip or something,neo geo aes nd snes megadrive do their work without it altough segs cd tried to come close to psx with some games.


Is there any sites I could look up on how the Genesis/Sega CD Tick

Inventually youlle see a bunch of sega 16,s members making the next streets of rage come true and worthy on megadrive,And when is the next shenmue coming to the genesis?.

[tomaitheous]

Is there any sites I could look up on how the Genesis/Sega CD Tick

Are you interested in SegaCD or Genesis dev?