Comparison of 5th generation ("32/64-bit") game console hardware

Quote:

---

Originally Posted by Kamahl

Yeah coryoon is even worse than Air Zonk in this regard.

---

Chuka Taisen's boss battles are gorgeous. Coyoon's try to do pretty much the exact same thing, but are painful to look at.

The desert stage of Lords of Thunder opens with a gibberish background. It doesn't really look like anything, even though the base graphics are nice. Meanwhile other scenes in the same game, like the opening of the water stage, look great.

It may not be technically difficult for the hardware to perform, but it sure seems challenging to pull off well artistically.

We should probably switch this discussion over to the 4th gen thread. This effect wasn't used in the 5th gen afaik.

Quote:

---

Originally Posted by Kamahl

We should probably switch this discussion over to the 4th gen thread. This effect wasn't used in the 5th gen afaik.

---

I wouldn't be too sure of that . . . granted, it was popular to use real 3D for doing perspective BGs in 2D/2.5D games, but row scroll or (better) linescroll would still make tons of sense for providing good perspective effects for parallax. At least for linescroll, there's plentty of cases with broad terrain (plains, marhes, low-lying cityscapes, low lying hills, etc, etc -anything appearing flat-ish from the foreground PoV) that would be best achived (for 2D) using linescroll rather than any overlapping. (if texture space was an issue, combining that with hardware scaling per-line might have been attractive too)

Now, combining that effect with overlapping layers/objects (or even multiple linescrolled layers with overlap) could make tons of sense in many cases too, and there's other cases where the BG perspective is too sheer and/or uneven (not flat-ish) to make sense to use with linescroll.

Quote:

---

Originally Posted by Kamahl

We should probably switch this discussion over to the 4th gen thread. This effect wasn't used in the 5th gen afaik.

---

For reasons I stated earlier, it wasn't needed as much, but games like Keio Yugekitai, Macross Do You Remember Love?, Mobile Suit Gundam, Guardian Heroes, Princess Crown, Astal, Shinobi Legions, Rayman, Kolibri, Knuckles Chaotix, Adventures of Lomax, Megaman X4, Adventure of Little Ralph, Hermie Hopperhead, Mischief Makers, and Wonder Project J2... -all use the effect in varying ways.

Quote:

---

Originally Posted by Black_Tiger

For reasons I stated earlier, it wasn't needed as much, but games like Keio Yugekitai, Macross Do You Remember Love?, Mobile Suit Gundam, Guardian Heroes, Princess Crown, Astal, Shinobi Legions, Rayman, Kolibri, Knuckles Chaotix, Adventures of Lomax, Megaman X4, Adventure of Little Ralph, Hermie Hopperhead, Mischief Makers, and Wonder Project J2... -all use the effect in varying ways.

---

They use a similar effect, the layers are fully independent (at least the Playstation/N64 ones).

Quote:

---

Originally Posted by Kamahl

They use a similar effect, the layers are fully independent (at least the Playstation/N64 ones).

---

The effect isn't always done the same way on 16-bit consoles either. Many games tack on sprites for overlapping and PC Engine games often do it with animation.

Quote:

---

Originally Posted by Kamahl

We should probably switch this discussion over to the 4th gen thread. This effect wasn't used in the 5th gen afaik.

---

Which effect are we talking about again?

Quote:

---

Originally Posted by zyrobs

Which effect are we talking about again?

---

Air Zonk/Sonic style sliding parallax spams.

Simple parallax scrolling? Tons of Saturn games did that... a lot of them being 2d shooters. Darius Gaiden from the top of my head, but Radiant Silvergun had that (vertically) as well as others.

Oh, and some of the "heavy parallax" examples used above - Sonic and Thunder Force - have had pixel perfect Saturn ports too.

Quote:

---

Originally Posted by Crazyace

Yes - I was thinking more , and if Jerry's dsp was dropped ( and other things like the Object Processor ) audio and cd interfaces could have been placed in Tom - allowing an extremely cost effective system of just one custom chip plus ram :)

---

Quote:

---

Originally Posted by Crazyace

Just to fix the bugs to have gpu run from external would be enough - and launch fully in 93 :)


or just leave the blitter as is ( barring bugs ) - although a single indirection would be nice for colour expansion as seen in the jaguar 2 blitter.


I disagree, why would you need line buffers - just a simple 64 or 128 bit fifo driving a fixed 320pixel 16bit display would be enough, why would games want 24 bit mode?


Changing Z/Gourard seems to be moving away from the main design of the Jaguar too much, whereas removing the object processor is taking something that wasn't 'Flare'


I was concentrating on just removing Jerry and the object processor - as Jerry would be a major cost.

Quote:

---

Originally Posted by kool kitty89

And, again, I find it interesting that Martin Brennan specifically mentioned disliking the Panther/object processor video architecture concept, yet they ended up including that as a core element of the Jaguar. (albeit, had they released the Panther, having a backwards-compatible OPL in the Jaguar would have made more sense)
And, if anything, the object processor (or sprite/tile/line buffer) type architecture made more sense for the previous generation due to limitations of RAM costs (framebuffers are a bigger sacrifice), bandwidth, and the emphasis on a relatively limited set of 2D-centric genres. (albeit a blitter+OPL could make sense there too -using the blitter to draw onto OPL sprites for effects as well as character/tile mapping and/or decompression, albeit you could use the CPU for that too -but it would probably be more cost effective to switch to a slower/cheaper CPU and offload that onto a blitter -which would probably outperform a 16 MHz 68000 anyway)

---

Yes, it was that comment that made me think about it.

---

I was thinking on this again, and reading through Brennan's and Mathieson's interviews on the SLipstream archive, and noticed there's even more detail to the Jaguar's object processor being "out of place" in a Flare design than Brennan's comment about the Panther:

There's the Panther comment already mentioned:
http://www.konixmultisystem.co.uk/in...content=martin

Quote:

---

It was a novel video architecture that allowed you to create windows of different sizes and different bit depths. Essentially you didn't have a frame store - it was a composite of frame stores - a kind of smart video frame store. It would have allowed a great deal of sprite style animation. Sprites in general in those days would have been of a fixed size e.g. 16x16. The games looked 'spritey' because of that, this would have been quite an interesting departure. I wasn't keen on it, but I designed it and the chip was built.
But while I was over in California in '89, I actually convinced the bosses at Atari that 3D was the way to go, with the experience we'd gained on Flare one - if you didn't just do flat rendering, but shaded rendering you got a 3D appearance.
At the time, I was seeing pictures in magazines where computers were rendering photo realistic 3D wire meshes and I said "these are static images, but they only contain a very few number of polygons - we could take that, animate it and you could produce a game that was a quantum leap away from the current games".

---

But then there's also the comments both Brennan and Maithieson make regarding the Amiga and Flare 1:
http://www.konixmultisystem.co.uk/in...content=martin

Quote:

---

We based a lot of it on the Amiga as well. That was a great influence - they seemed to have designed a very powerful games machine - if not a games computer then at least a games capable system. They had Commodores purse to design that - and it showed - there seemed to be several different ways you could do the same thing on the Amiga which struck us as overkill. We felt there were lots of instances of doing the same job - but one way - the best way, and it would end up being cheaper. Plus there were certain things we didn't like about the architecture - it was bit planes architecture rather than a bit per pixel, so we felt we had some ideas that would make our lives and the game writers lives that much easier.
When you say was the Flare one derived from the Loki - I think you've got to say that Loki and Flare one were derived from the Amiga, so you've got to pay tribute to those guys.

---

http://www.konixmultisystem.co.uk/in...ent=john#start

Quote:

---

we believed that the Amiga was over engineered - it could animate with sprites and with a blitter, but why have both? We figured that if you could implement a system that could animate the screen then you only needed one set of hardware to do it. So we proposed a computer called 'Loki' as a Spectrum successor. The idea was never more than a paper design because Sinclair sold out and Amstrad took over before anything productive could happen to further the project".

---

The Jaguar's use of the Object Processor alongside the Blitter seems to contradict the very concepts and methodology originally applied to Loki, Flare 1, and Slipstream.
Technically speaking, the Panther itself didn't contradict that concept since its graphics were purely generated by the Object Processor (aside from possible software rendering to object windows), but Brennan just mentioned not really liking the architecture in general.

So the way the Jaguar was configured really seems odd in that respect, both in the context of Flare's general design concepts and the heavy emphasis on low cost with the Jaguar's design (and Atari Corp's market model in general).

Then there's the issue of magnetic or optical mass storage vs ROM carts in the Jaguar. The use of CD-ROM in 1993 wouldn't be far off in terms of cost/performance trade-offs as the DSDD floppy drive would have been in 1989. Plus, piracy concerns wouldn't have been an issue for CD-ROM yet. (and Flare's original semi-proprietary 880 kB floppy format would have reduced that to some degree as well)


And looking at the idea of a single-chip Jaguar more conceptually similar to the Slipstream, you've got the framebuffer controller, video DACs, DSP, audio DACs, CRAM and DSP scratchpad, main memory/CPU bus interface, and (in the final revision of Slipstream) integrated floppy disk controller as well. So compare that to the possible Jaguar ASIC based around a beefed up blitter, realtively framebuffer controller (some buffering to make decent use of bandwidth -like a pair of 128 or 256 bit buffers) and probably only direct color modes (no need for CRAM -aside from possible blitter CLUT), and integrated sound, IO (controller ports, UART, CD-ROM interface), and GPU/DSP RISC core with scratchpad (or, better, an actual cache). Except, unlike the Slipstream, you'd have a very powerful and flexible MPU in place of the DSP and thus no fundamental need for a dedicated CPU at all. (plus, the advanced design of the J-RISC also avoided some of the conflicts of handling both sound and 3D processing compared to the primitive Slipstream DSP)

I keep failing to talk about this, moved from here:

Quote:

---

Originally Posted by TrekkiesUnite118

I'm well aware of that, but according to the performance of the two systems the gap apparently wasn't that big with Model 2 doing 300,000 Textured Polygons per second and the Saturn doing 200,000 Textured Polygons per second. I'm not expecting the Saturn version to have the graphical quality of the Arcade game, I am simply asking why it couldn't do around 60fps with about 2/3 the polygons?

---

The original Model 2 that Daytona ran on still had the capability for 900k vectors per second, that is a good deal better than 5th generation hardware could do. Sony's specs for the Geometry Engine (in a vacuum) aside, Model 2 was practically a generation ahead of the 5th gen consoles even though it came out first. That's why Model 2 B and on could fudge the gap between 300k polygons per second and 900k vectors per second to make 2 million pixels per frame at 60FPS.

Most Saturn games seem to top at ~100k polys at 30fps.

I don't know how much polys the model 2 can draw but judging by the framerate and the way higher details, it would have to be at least 4x more powerful.

The only firm polygon count numbers I have been able to document so far are 60k polygons per second at 20FPS for Daytona USA and 80FPS at 20-30FPS for third party games in 1995, for both the Saturn and PS1 that year. Beyond that I have seen a lot of rumors and speculation and a few games actually brag on themselves. Iron and Blood, one of the PS1's ugliest games, boasts over 200k polygons per second but looks worse than Fighting Vipers, Fighters Megamix and Shining Force III's battle sequences. I think magazines claimed that NiGHTs ran at 180k polygons per second as well, but I have never been able to confirm that.

Sonic R seems to do 60-90k from what I remember, although its popular for its special effects not polygon count.

Wow, that would seem really low to me given the beveled edges on trackside objects and generally curved nature of everything. Crash Team Racing by comparison is a bunch of square blocks put together. ;)

Quote:

---

Originally Posted by zyrobs

Sonic R seems to do 60-90k from what I remember, although its popular for its special effects not polygon count.

---

Don't forget it also uses a lot of VDP2 floors. On other systems they'd probably be using polygons for those.

Quote:

---

Originally Posted by TrekkiesUnite118

Don't forget it also uses a lot of VDP2 floors. On other systems they'd probably be using polygons for those.

---

That's what I meant by special effects (vdp2 transparencies against the backgrounds on a per-polygon basis to do fog effect). Calculating that might take some load too, so it can't really be much of a polygon pusher, and it doesn't need to either, to look good.

Combining the VDP1 and VDP2 is what could've given the Saturn an edge that the Playstation simply couldn't match, but Sega killed the machine before commercial games could start using advanced techniques. Sonic R and Burning Rangers are the two most common examples of games that pushed the VDP2 in exotic ways.

But I don't know what game could be considered the biggest polygon pusher. Anyway, since you have to push game code, collisions, AI, etc, on top of running a 3d engine and then affine mapping it, 100k at 30fps is probably very good for the Saturn, unless you can get the SCU DSP to do something useful for a change, or you are doing a graphics-only demo (like the Zyrinx 32x demo).

I wasn't talking about the VDP2 transparencies. I was talking about the floors it does. That's not really a special effect in my book.

Quote:

---

Originally Posted by TrekkiesUnite118

I wasn't talking about the VDP2 transparencies. I was talking about the floors it does. That's not really a special effect in my book.

---

A floor isn't a big deal and could be done by Playstation, it has enough extra juice and memory to render the few hundred extra polygons of a static floor (even if it wouldn't be perspective correct and have some breakups).

What it couldn't do is the excessive warping, mirroring, linescroll, waving, etc, that the VDP2 can do. That's why they didn't port Radiant Silvergun to the Playstation, it goes through just about everything the VDP2 can do on its own. Same for the reflective water effect in Sonic R - although that wouldn't be a big deal to do on the Playstation, it would just be missing the wavy effect, essentially it would look like the PC Version just lower resolution.

Yeah, the floor could be done with polygons on the PS1, but there could possibly be a performance hit with that.

There would be a texture quality hit for certain, from potential 8-bit 256-color large textures down to 4-bit or pallatized textures as seen in Tekken 1+2. I think that, like Fighter's Megamix, Fighting Vipers, Shining Force III and Grandia, the use of the VDP2 floors wasn't just a simple workaround for the poor Saturn's VDP1 deficiencies, but it was an opportunity to pump as many polygons into non-floor objects as possible. So the PS1 not only couldn't do all of the "excessive" effects of the VDP2, but it also had to take polygons from the objects in order to use them on the floors and far background instead. The GE was fast enough to pull this off, but the 1MB Video RAM was still responsible for everything at once including the Frame Buffer.

The Playstation has enough extra video ram and horsepower to be able to pull off a single ground like that, the big problems would be lack of perspective correction, some poly breakup (these two are unavoidable due to using polys on the PS), and likely the texture quality would suffer too but that depends on what size of a ground are we talking about & what optimizations can take place.
Special effects on the ground would be severally diminished and so would be the draw distance (the VDP2 rotated background has no concept of draw distance).
It might not be able to pull off a 4096x4096 256 color ground floor, but it could get something pretty good done in place of it.

But when we start talking about crazy warping, double playgrounds, water ripple effects, simulated turning cubes, psychedelic rippling gradients, very extreme parallax scrolling, or practically all the above at the same time (on top of 2-6 other backgrounds, a polygon field, and transparency inbetween most of them) - that's what the Playstation can't do. Watch full a Radiant Silvergun playthrough and pay attention to the backgrounds, if you want to see some very sick effects that cannot be really done with polys.

On the perspective correct issues particularly with the PS1 I just stumbled over this post on EMUforums. Most of the description is in regard to fixing perspective correction in emulated PS1 games, which seems to be impossible. I recall the authors of Bleem!, particularly in regard to Bleemcast!, saying the same thing, and that texture warping and polygon separation were essentially have to be programmed out of each individual game.

Quote:

---

Okay, I will post a quick explanation on this, as I've posted several long essays on this in the past and can't remember exactly what I've said ... last thing I want is someone saying "You said this now, but you said this on {insert some really old date in here}!!" http://images.ngemu.com/forum/smilies/Standard/wink.gif

Here goes: the PSX GPU does lack a z-buffer (the N64 does have one, afaik). Because the PSX GPU lacks a z-buffer, no depth information is passed to the GPU with the primitives that are sent for rendering. Because there is no depth information sent with the primitives (ie. on x & y values are sent), there is no way to do perspective correct texturing (which requires *correct* depth values for each vertex in the primitive, so the 1/z interpolation can be performed).

Bilinear filtering does not require any more information than the PSX GPU already gets passed, so it can be enabled. *BUT*, bilinear filtering does require carefull layout of textures in VRAM, which most PSX games do *not* do. This means there are glitches when enabling bilinear filtering, such as black halos (due to chroma-keying issues).

Perspective correct texturing would stop texture "swimming" or "warping", but would be dependant on the PSX game doing perspective correct clipping on the side of the view-port. If the game just does simple clipping, and does no take 1/z interpolation in to account when clipping primitives, you will still get texture swimming on the edge of the view-port, particularly when cameras are slowly panning, etc.

Perspective correct textuing would not really help "wobbling" polys: that needs sub-pixel accuracy in the vertex data (PSX has no sub-pixel accuracy, so everything is rounded to integer values). This is also why small objects do not scale very well even when running an emulator at 1600x1200: one step on the PSX screen of 320x240 results in a jump of 5 pixels on the emulator screen! If the PSX had sixteen levels of sub-pixel correct vertex data, the emulated screen would still be sub-pixel correct.

---

Quote:

---

Originally Posted by sheath

The original Model 2 that Daytona ran on still had the capability for 900k vectors per second, that is a good deal better than 5th generation hardware could do. Sony's specs for the Geometry Engine (in a vacuum) aside, Model 2 was practically a generation ahead of the 5th gen consoles even though it came out first. That's why Model 2 B and on could fudge the gap between 300k polygons per second and 900k vectors per second to make 2 million pixels per frame at 60FPS.

---

Model 2 was a high end arcade board :) and 300k polys per second probably is 900k vectors per second given fixed 3 vertex triangles.
900k Vectors/second is less than the PS1 GTE peak rate - the GPU triangle rate will be the bottleneck there.
In terms of pixel fill rate model 2 specs go from 1.2MP@60 to 2MP@60 - given 72MP/s to 120MP/s. That's where the advantage is - 2-4x better than PS1 ( fill rate 33MP/s - 66MP/s )

Given the raw power differences both Saturn ( Daytona CCE ) and PS1 ( Burning Road http://www.youtube.com/watch?v=oGmv9Fu_Tu0 ) gave quite good versions of the Model 2 games.

Is really Sonic R such a big deal compared to this:

Solid 30 fps in real hardware
Real hardware YT capped video:



Solid 60 fps in real hardware
Emulated crap YT capped video:



Solid 60 fps in real hardware
Real hardware YT capped video:



60 fps and real-time shadow casting in real hardware
Real hardware YT capped video:

It has been a while since I last played PS1... damn how much those polys and textures twist around !

Those games are technically impressive in their own ways, but one good looking or impressive game doesn't take anything away from another. Speed Punks has a good engine and does look nice, but the stages are kinda simple and blocky to maintain the draw distance. The Muppet game again, strikes a difference balance and loses more in some ways to give us more in others.

What all of those games fall short off though, is artistic quality, which is all the more important in early 3D graphics. It's what makes Sonic R more than anything, even if the engine is also nice. If you took a fugly 32-bit game and dropped it into the Sonic R engine, it would still be fugly, although technically impressive.

i dont remember the road clipping in ray tracers being that bad

anywya my question is a bit beyond the scope of the thread
but how does the dreamcast hold up in comparison to the various model 2 boards ?

Quote:

---

Originally Posted by Black_Tiger

Those games are technically impressive in their own ways, but one good looking or impressive game doesn't take anything away from another. Speed Punks has a good engine and does look nice, but the stages are kinda simple and blocky to maintain the draw distance. The Muppet game again, strikes a difference balance and loses more in some ways to give us more in others.

What all of those games fall short off though, is artistic quality, which is all the more important in early 3D graphics. It's what makes Sonic R more than anything, even if the engine is also nice. If you took a fugly 32-bit game and dropped it into the Sonic R engine, it would still be fugly, although technically impressive.

---

I was mostly referring to the tech side of things since the previous posts sounded to me like if people were suggesting that PS1 couldn't handle the Sonic R engine, which is not the case IMO (thus why I post those videos).

But, yeah, games like Running Wild looks very generic thanks to its poor/mediocre art direction...

Quote:

---

Originally Posted by Crazyace

Model 2 was a high end arcade board :) and 300k polys per second probably is 900k vectors per second given fixed 3 vertex triangles.
900k Vectors/second is less than the PS1 GTE peak rate - the GPU triangle rate will be the bottleneck there.
In terms of pixel fill rate model 2 specs go from 1.2MP@60 to 2MP@60 - given 72MP/s to 120MP/s. That's where the advantage is - 2-4x better than PS1 ( fill rate 33MP/s - 66MP/s )

Given the raw power differences both Saturn ( Daytona CCE ) and PS1 ( Burning Road http://www.youtube.com/watch?v=oGmv9Fu_Tu0 ) gave quite good versions of the Model 2 games.

---

Do vertices translate 3:1 to a triangle polygon as any sort of uniform standard? I'm pretty sure I've seen discussion here about the number of vertices possible not being directly relateable to polygon count at all. I don't recall if I saw any thorough discussion on how to convert a max vertex count, like Sony's for the PS1 GTE or the PS2 GE and turn that into any sort of real world polygon spec. As I understand it people have tried taking the vertices from PS2 and Dreamcast emulators as well and failed to come up with any concrete or comparable data. Anyway, I would love to know otherwise as it seems like vertices is a more readily available spec than the actual number of polygons per second.

I also haven't been able to substantiate the PS1 being capable of 66MP/s fillrate, the discussions we have had here ended with the discovery that the actual PS1 fillrate was closer to 30MP/s and the Saturn's VDP1 was 28MP/s. This came a lengthy discussion in this thread I think about the Saturn's VDP1 fillrate being as low as 10MP/s, which ended up not being the case. Ah, here it was in the Sega Saturn Mega Thread, where else?

That Burning Road video is very interesting. The draw distance looks worse than Daytona USA's but the framerate looks to be solid 30FPS. Texture mapping looks better to me than most PS1 games in general. I don't know if I have ever head of any Model 2 ports to Playstation, that is cool on its own!

Burning Road isn't a Model 2 port to my knowledge. It's a game built just for the PS1.

Burning Road looks amazingly Model 2 like, or at least Daytona like. It's a great comparison regardless.

I don't think Sonic R wouldn't be possible on the PS1, I just think some effects very much catered to the Saturn hardware. The translucent final track with a "floating" texture in it was replaced with a generic rainbow texture in the PC and every subsequent release. As such I doubt the PS1 would have had a translucent track complete with relatively high detail textures and the floating floor texture in that. It's just something that the Saturn could do with the VDP1 and VDP2 combined. The racing games Barone linked to similarly show off things that the PS1 was especially capable of, such as tossing around a fair amount of textured and lit polygons at 60FPS. These games would not likely port very well to the Saturn as a result. It sucks that the Taito racer with the shadow casting had such issues with clipping and texture warping though, otherwise that engine would have really made a great looking game.

Quote:

---

Originally Posted by sheath

Burning Road looks amazingly Model 2 like, or at least Daytona like. It's a great comparison regardless.

I don't think Sonic R wouldn't be possible on the PS1, I just think some effects very much catered to the Saturn hardware. The translucent final track with a "floating" texture in it was replaced with a generic rainbow texture in the PC and every subsequent release. As such I doubt the PS1 would have had a translucent track complete with relatively high detail textures and the floating floor texture in that. It's just something that the Saturn could do with the VDP1 and VDP2 combined. The racing games Barone linked to similarly show off things that the PS1 was especially capable of, such as tossing around a fair amount of textured and lit polygons at 60FPS. These games would not likely port very well to the Saturn as a result. It sucks that the Taito racer with the shadow casting had such issues with clipping and texture warping though, otherwise that engine would have really made a great looking game.

---

Well, that's the good sense talking and I surely agree with that.

The point which got my attention was where you and Trekkies were speculating about the possible performance hit that a PS1 version would take to render the floors. Again, look at Running Wild, it's solid 60 fps. So, my point was: at 30 fps it could surely handle stuff like Running Wild along with more detailed graphics and/or more especial effects, etc... Speed Punks has a ton of special effects sometimes (depends on the weapons used by you and the CPU cars) and still keeps the frame rate intact.
So, IMO, it's clear that it could pull off something that could look as impressive as Sonic R technically speaking.

It's also clear that each hardware has its strengths and "special features" so you surely would have to change/adapt things if you would port it.
If you look around 32:00 of the Muppet Race Mania you'll see an example of one possible approach to replace the Radiant Emerald track effect used in Sonic R. Is it the same thing? Obviously not. Could the Saturn pull it off? Probably not, due to the use of transparencies...


About Ray Tracers engine, it's a shame they didn't released a sequel of some sort... 'Cause it's a January 1997 release and I think they could have pushed it a bit more later on the PS1's life, like other game engines also got improved in terms of dramatically reducing clipping and texture warping.


Burning Road might have looked somewhat impressive for the 2 months it stayed in the market before the Daytona USA CCE release. But that's about it.
It has the graphical quality (not art quality) similar to the first Daytona USA port on the Saturn, with almost exactly the same bad drawing distance but with steady 30 fps instead of the iffy 15-20 fps of the Saturn game; however, with only 8 cars instead of 40 on the track...
IMO Burning Road is nothing more than a funny rip-off (damn, all racing games should have all those camera angles; back then, you'd be lucky to find games with more than two angles...) which may serve as a demo of how Daytona USA would look like on the PS1 but, seriously, released more than one year after the first Saturn version it's more about trade offs than actual improvements; so it's nothing special to me. Daytona USA CCE is far more impressive IMO.
There's a sequel called Explosive Racing (Europe)/ X.Racing (Japan) (yeah, not released in US...) which seems to use the very same engine, with the same horrible drawing distance but maybe a bit more detailed textures. Still, nothing special for a late 1997/early 1998 release, quite the opposite.

^ get a life

Stoner dude, please let the grown ups continue talking.

Barone, yeah upon watching Burning Road I am seeing much more in the way of trade offs with Daytona USA than anything else. As for the translucent track in Sonic R, I think due to the "excessive" VDP2 usage it simply would not be portable. Same goes for Radiant Silvergun, as Vic Ireland said it would need to be ground up rewritten for PS1 and there simply wasn't enough VRAM to do it without ugly results.

As for Muppet Mania, yes that translucent floor is exactly what I was picturing in a PS1 rendition. It uses the PS1's normal translucency effect and relatively sparse textures at the same time as I would expect. I used to assume that the jump from 30FPS to 60FPS would always half the polygons on screen in the process, and so assumed that taking an engine capable of 60FPS and dropping it to 30FPS would easily double the amount of detail on screen. That doesn't seem to usually be the case though, and VRAM constraints are much higher at lower framerates with more detail.

I don't think that there should be any doubt that the PS1's polygon capabilities are at least on par with what is seen in Sonic R though, that seems rather obvious. I think the point of any Sonic R discussion is that a 1997 game has that much detail in the first place, and that the engine could have been expanded, tweaked and improved in subsequent years, just like all engines can, while retaining relatively exclusive to Saturn VDP2 usage.

Quote:

---

Originally Posted by STONEDSTONER

^ get a life

---

:fail:

Quote:

---

Originally Posted by sheath

Barone, yeah upon watching Burning Road I am seeing much more in the way of trade offs with Daytona USA than anything else.

---

Yep.

Quote:

---

Originally Posted by sheath

As for the translucent track in Sonic R, I think due to the "excessive" VDP2 usage it simply would not be portable. Same goes for Radiant Silvergun, as Vic Ireland said it would need to be ground up rewritten for PS1 and there simply wasn't enough VRAM to do it without ugly results.

---

Agreed. I find Radiant Silvergun far more impressive in terms of showing up 3D tricks.

Quote:

---

Originally Posted by sheath

As for Muppet Mania, yes that translucent floor is exactly what I was picturing in a PS1 rendition. It uses the PS1's normal translucency effect and relatively sparse textures at the same time as I would expect.

---

It's still good looking IMO and I don't think it would be considered inferior by the average gamer or the biased magazines compared to the Radiant Emerald one. Oranges and Apples IMO.
The Radiant Emerald effect can be used everywhere in a open view circuit like that, everything looks so solid that it reminds me a Disney hand-animated top quality 2D creation. But I doubt that most of the people would give it the same "importance" that I do.

Quote:

---

Originally Posted by sheath

I used to assume that the jump from 30FPS to 60FPS would always half the polygons on screen in the process, and so assumed that taking an engine capable of 60FPS and dropping it to 30FPS would easily double the amount of detail on screen. That doesn't seem to usually be the case though, and VRAM constraints are much higher at lower framerates with more detail.

---

It's not like that but I kinda disagree with what you said in the last part.
60 fps racing games constraints in that console gen were usually huge: limited number of CPU cars (Ridge Racer Turbo, Motor Toon Grand Prix R, Motorhead, Gran Turismo Hi-Fi mode...) and/or reduced drawing distance (Motorhead, Muppet Race Mania, F-Zero X, Ray Tracers) and/or lower texture detail (F-Zero X, Ray Tracers, Motorhead) and/or limited special effects usage (explosions, etc...) (Running Wild, F-Zero X) and/or limited trackside objects (F-Zero X, Motorhead) and/or limited animation (Ray Tracers, Running Wild, F-Zero X).
Stuff like Speed Punks in 60 fps would be impossible for Saturn, PS1 and N64 (even with the expansion pack) IMO. The N64 games with similar level of detail, effects, animation and drawing distances actually don't maintain 30 fps.

Quote:

---

Originally Posted by sheath

I don't think that there should be any doubt that the PS1's polygon capabilities are at least on par with what is seen in Sonic R though, that seems rather obvious.

---

Agreed.

Quote:

---

Originally Posted by sheath

I think the point of any Sonic R discussion is that a 1997 game has that much detail in the first place, and that the engine could have been expanded, tweaked and improved in subsequent years, just like all engines can, while retaining relatively exclusive to Saturn VDP2 usage.

---

Yep, it's very impressive for 1997 IMO.
I still can't believe how Sega didn't expand the Saturn line-up over those more impressive engines like: Daytona USA CE, Virtua Fighter 2, Sonic R, NiGHTS... The N64 used its few impressive engines to death in comparison.

The playstation could handle Sonic R, except for the mirrored water effect, and the ground would look poorer.

Radiant Silvergun would work too, but the majority of the backgrounds would look hilarious.

3 vetexes per triangle was mostly software renderers and very early hardware. To cut down the amount of vertexes needed, you very quickly got triangle strips and fans. Use of those cut drastically down on the number of vertexes you needed.

traingle strip
http://upload.wikimedia.org/wikipedi...trip_Small.png

triangle fan
http://upload.wikimedia.org/wikipedi...rianglefan.png

That's right, now I remember the vertices that touched two triangles didn't count as two they counted as one vertex. That's what made guessing polygon performance based on vertices per second impossible.

Quote:

---

Originally Posted by zyrobs

The playstation could handle Sonic R, except for the mirrored water effect, and the ground would look poorer.

Radiant Silvergun would work too, but the majority of the backgrounds would look hilarious.

---

What do you mean by hilarious?