Tomb Raider was over rated

[The Coop]

Lol you guys. Digging up old threads to wage another Saturn vs. PSX war.

They - say - two - thousand zero one one no one argues 'bout - system specs.

That's - why - to - night we're gonna argue like it's nineteen ninety-six.

[Nuxius]

You need to at least double-buffer the frames

Tekken 3 didn't and looked fine.

Here's a link to a VRAM dump from Tekken 3 (the image is too big for an image host).
http://www.speedyshare.com/files/28204135/Tekken3.zip


Only game I can find that triple buffers is Jumping Flash. Not so surprisingly enough, it's also the lowest res PSX game I have found so far (256*224 with borders).

http://img263.imageshack.us/img263/484/jumpingflash.png
(I had to compress this a bit colorwise to host it)

Most other games just stick with double buffering.

[sheath]

Capture cards can skew things. If you want to compare aspect ratio and overscan, you'd need to do that on a real CRT SDTV with normal calibration. (capture cards and some LCD sets can give false boarders relative to what a real analog set would show)

Having a larger vertical boarder wouldn't make sense if the PSX really is running in 320x240 and Saturn in 352x224. (the Saturn would have more vertical boarder than the PSX by that definition) Not that it matters since most TVs show no more than 224 lines (NTSC) anyway. (for PAL it would be more significant)

I wasn't talking about a border or cropping, the PS1 game displays more gameplay screen vertically. I didn't crop it out because the other versions occasionally display a screen that "tall" as well.

No, no, no!

Both framebuffers are for VDP1, just like the 128k buffers in the 32x. You need a framebuffer to display plus a back buffer to render to.

The added RAM comes from the SH1 work RAM and VDP2 tile RAM. (512k each)

Uh, yeah, thanks for that clarification. When you combine the VDP1 and VDP2 memory and the frame buffers the Video "bus" has 1.5MB to the PS1's 1MB. This can be over-emphasized of course, but it shouldn't be de-emphasized.

For Tomb Raider, the PSX has MORE nominal video RAM to work with as the VDP1 framebuffers are only using a small chunk of their RAM and VDP2 is barely used at all. (just for occasional water effects and maybe some BGs in the few open areas)

Do we know that the water effect was done with the VDP2 on the Saturn game? You know, you talk too much about stuff you read on a forum somewhere as though it is common (accepted) knowledge. I've seen homebrew types postulate that the VDP2 could be used to overlay effects over VDP1 3D graphics, but I haven't seen any sort of definitive examples of what that looked like. Tomb Raider is early enough, practically a first gen Saturn game for Core, that I doubt they did anything super special to achieve their effects.

Then there's the sound compression. ... You could probably use VDP2 RAM (possibly SH1 RAM) for added data, but you'd have to move that around as needed in other subsystems. (and I'm not sure if that's as straightforward as doing the same thing with CPU RAM on the PSX or Saturn)

And if they're not doing anything special with the "extra" RAM, the Saturn would effectively have been roughly 3.35 MB while the PSX would have effectively been 4.9 MB. (or, dropping the audio comparison, it would be ~2.85 MB vs 3 MB, though it would be closer in cases where VDP2 was being used)

Wait, now the SH1 is useful? I thought it was a complete waste and not programmable? I'm not being sarcastic, this is what I've seen discussed about it in these forums. The SH1 has RAM that can be accessed by other systems, but the SH1 itself can't be touched? I suppose you could be storing extra data in the CD-ROM sub system's 512KB while the Main RAM is full of game data and "shadowing" some VRAM data for the VDP1. That would be better than not having the extra RAM at all, but it still sounds like extended CD-ROM cache to me.

2 layers? And how would that definitively mean more polygons on-screen for the entire scene? (rather than just 1 specific object)

I thought I worded that carefully enough. All of the guard rails in the box scene have two rows of textured polygons instead of one. I doubt it is a big deal, but it is extra detail that only the Saturn version has in that scene.

Actually, the PSX version runs at 384*240. TRII runs at 384*240 as well. TR3, TR:TLR and TR:C all run at 512*240. This is the reason why Lara is always thinner in the PSX versions than she is in the PC versions (this is especially true for the last 3).

Great! Thanks for the update. Which emulator are those shots from?

On another note:
Sheath, it's cool that you included the PC versions for comparison, and the accelerated example looks great, but it doesn't look like your machine can handle the software renderer in DOSbox. All that low framerate and tearing skews things. (I also assume you're running it at the max 640x480 high detail mode -ie maximum perspective correction)

Dosbox was set to "original" resolution, which turned out to be 320x200, and then normal2x. The internal detail setting was set to high because that matches the detail levels I saw in the PS1 and Saturn games. The tearing is because Tomb Raider is a CPU hog and running it with Fraps dropped the framerate from 30fps to 22-27, with the very occasional dip into the high teens. I searched for over a week for ways to optimize this, way longer than I should have for a simple comparison. The 3dfx Tomb Raider Dosbox patch is vastly preferred on tombraiderforums, but I wanted to show the original texture maps without filtering too.

If you're not going to use a real 9x/DOS compatible machine, at least use a configuration that emulates it properly.
There should be a high framerate and no tearing at all. (you should also disable scaling -DOSBox does it by default, so you need to go into the conf file and change that)

Thanks for that. Actually, I had to get Tomb Raider working on my in law's single core laptop more times than I'd like to remember. This video is not misrepresenting how Tomb Raider was played on PC, especially not in 1996.

The framerate is noticeably lower on the Saturn too, I hadn't realized how big that gap was before. (still looks quite playable, but enough to be annoying when compared back to back)

No. Both versions are an inconsistent 30fps with occasional dips into the teens. The PS1 version doesn't dip as often in the gym/house scene though. The Saturn dips to 20FPS frequently in the box scene in particular.

[kool kitty89]

No, because they wanted progressive scan. The max vertical res the PSX can use in progressive is 256. When you bump that up to 480, it's interlaced only.

Exactly. Why would they even care about using progressive though? I like it more for some things, but most people seem to prefer interlacing in general (lack of scanline gaps among other things).
It's also only 224 lines due to normal TV overscan limits. (for NTSC; PAL is another story)

The only reason to do that is is you wanted 60 FPS rendering.

And again, increasing horizontal resolution is limited with composite video (which most people would have been using -if not RF), but bumping to interlaced will be far more dramatic by comparison.

320x480i would noticeably reduce jaggies and make dithering look better (blending vertically as well as horizontally -except PAL blends vertically in 240p as well). Or more realistically, you'd want 320x448 so as to not waste framebuffer space in overscan.

Most PSX models have pretty soft/blurry composite video, so that makes increasing horizontal resolution even less attractive.

I've had a hard time finding games that run at 320x480i during gameplay. I've found plenty that use it for menus though; Rage Racer, Dino Crisis and Silent Hill just to name a few. They all switch to 320*240p for gameplay though.

Yes, 320x240 (or 320x224) makes perfect sense, but going up to 512x240 doesn't make too much sense by comparison. (unless you can manage close to 60 FPS rendering)

Tekken 3 runs at 384*480i [bordered] (arcade version ran at 512*480); it's the highest gameplay resolution I can find.

Uh, no, emulators will run at whatever resolution your computer will allow. I'm talking about the actual PlayStation here.

I said:
Resolution has nothing to do with being "thin" or "fat",
and you:
For the PSX it does, as most games are stretched to 640*480 on it.

So if you're saying the PSX scales to that resolution, you make no sense. PSX games don't "stretch" anything, the 3DO and some N64 games interpolate to 640x480i (I think some PS2 games too), but the PSX doesn't support that at all AFIK.

Most games run in 240p native (ie you can see the scanline gaps and lack of interlacing on a TV), and I have no idea why you'd think it would be scaled to 640 width. (analog monitors and TVs can display ANY horizontal dot resolution -there's a limit to how small those pixels can get and still be discernable, but that's a separate issue)

Without interpolation/antialising, there's absolutely no reason to upscale anything. 640x240 will appear as 4:3 on an SDTV with 2:1 pixels (assuming the dot clock is 12.5 MHz and the TV has normal NTSC calibration -otherwise it won't be exactly 2:1).
Likewise, 320x480 will be 4:3 and fill the screen as well, but with 1:2 pixels instead. (assuming a 6.25 MHz dot clock)



And to my original point, it's up to the programmer/software to render properly for the resolution and aspect ratio used. (many, many NES/SNES/MD/SMS games didn't do this and ended up with stretched/squished looking graphics, and if they WERE corrected for NTSC, they pretty much never were for PAL and would thus look much too wide in PAL -sort of like setting a TV to anamorphic widescreen for fullscreen content)

The resolution for games on the PSX was limited by the vram. You need to at least double-buffer the frames, and the lowest color mode is thousands, which uses two bytes per pixel.

Isn't 16bpp the ONLY framebuffer depth the GPU supports? (the 24-bit mode being software managed)

Tekken 3 didn't and looked fine.

Here's a link to a VRAM dump from Tekken 3 (the image is too big for an image host).
http://www.speedyshare.com/files/28204135/Tekken3.zip

Interesting, I guess it has a consistently high enough framerate to avoid significant tearing.

Only game I can find that triple buffers is Jumping Flash. Not so surprisingly enough, it's also the lowest res PSX game I have found so far (256*224 with borders).

A bit odd that they'd even bother with triple buffering given the relatively limited advantages and significant disadvantages of eating up VRAM.

I wasn't talking about a border or cropping, the PS1 game displays more gameplay screen vertically. I didn't crop it out because the other versions occasionally display a screen that "tall" as well.

Ah, OK, I misread your previous post. (though, practically speaking, the PSX's resolution is totally wasted outside of PAL TVs or extremely tightly calibrated -or user adjusted- NTSC sets -the vast majority show no more than 224 lines)

Uh, yeah, thanks for that clarification. When you combine the VDP1 and VDP2 memory and the frame buffers the Video "bus" has 1.5MB to the PS1's 1MB. This can be over-emphasized of course, but it shouldn't be de-emphasized.

I wasn't de-emphasizing it, I was putting it in real-world context.

The 1.5 MB configuration in the Saturn is wasteful for the most part due to its inflexibility. (and it's not cheap commodity DRAM either, so that's far more significant)

VDP2 is basically unused in TR and many 3D games, so that 512k would be mainly useful for auxiliary storage if used at all. (not sure how convenient it is for added storage)
If it WAS practical for general storage as such, that WOULD give a realistic advantage over the PSX, but it would depend on how practical it is to use VDP2 RAM as such. (albeit not as much of an advantage as if VDP1 had a full MB of texture RAM, and more costly due to using 2 256k SDRAM chips and being on a separate bus with VDP2)

The framebuffers are rarely pushed close to capacity and thus also heavily inflate the Saturn's useful RAM. (they're generally not useful for any extra data either as they need to be used for other things)

That's not one bus either, it's 2 or 3 separate buses (another cost inefficiency of the Saturn). You have the VDP1 bus for texture or "sprite" RAM and the framebuffer being rendered to (I don't think that framebuffer is on a separate bus) and then you have the VDP2 bus with the 2D tile RAM plus the framebuffer being scanned out to the screen by VDP2. (not sure if that's a separate bus or the same as that used for tile RAM)
The framebuffers are definitely separate banks in both cases, but separate buses is another matter. (there shouldn't be any advantage of having a 3rd bus, so it's probably just the 2 buses with the framebuffers being flipped between)

If they WERE on the same bus, you'd have contention between VDP1 and VDP2 due to there being no buffering or caching. (unlike the PSX with heavy caching and buffering to allow efficient rendering in a single BANK of RAM on a single bus)

Do we know that the water effect was done with the VDP2 on the Saturn game?

I seem to remember CORE mentioning such, but I'm not positive.
I don't think it's a transparency effect though since it's warping, (maybe a linescroll/scaling effect being performed on the framebuffer layer)

You know, you talk too much about stuff you read on a forum somewhere as though it is common (accepted) knowledge. I've seen homebrew types postulate that the VDP2 could be used to overlay effects over VDP1 3D graphics, but I haven't seen any sort of definitive examples of what that looked like.

I thought we sorted this out. (whatever thread that was) VDP2 can overlay onto anything with transparency, as can VDP1 for 2D objects with its basic 50/50 blending.
It's only warped quads that break things (ie 3D objects or warped 2D objects can't be translucent).

Some were claiming that warped quads could eb translucent over anything but other quads, but I'm pretty such you actually get garbage pixels or messed up textures if half transparency is enabled on a warped primitive. (I need to look into the specifics again, but that's the impression I got)

It's a VDP1 bug, VDP2 doesn't have any such problems, and that bug is also one of the supporting points for the late redesign of the Saturn in 1993 adding the 3D drawing modes to VDP1. (thus not having time to fix the bugs)
That's pure speculation, of course, but logical nonetheless.

Tomb Raider is early enough, practically a first gen Saturn game for Core, that I doubt they did anything super special to achieve their effects.

I wasn't claiming they did anything super special, I was saying that unless they put special effort into using 2ndary storage in the Saturn, the PSX would nominally have more memory at its disposal. (doing software decompression on the 68k wouldn't be "special" though, and neither would preprocessing the samples to sound better when converted to 8-bit PCM -namely dynamic range compression)

Wait, now the SH1 is useful? I thought it was a complete waste and not programmable? I'm not being sarcastic, this is what I've seen discussed about it in these forums. The SH1 has RAM that can be accessed by other systems, but the SH1 itself can't be touched? I suppose you could be storing extra data in the CD-ROM sub system's 512KB while the Main RAM is full of game data and "shadowing" some VRAM data for the VDP1. That would be better than not having the extra RAM at all, but it still sounds like extended CD-ROM cache to me.

I was just speculating and it has nothing to do with the Sh1 being useful, just its RAM. If the main CPUs have access to the SH1's work RAM/buffer and you weren't doing any on the fly loading from CD (SH1 is idle), it could be feasible to use that RAM as 2ndary storage.
Same for VDP2 tile RAM, though that also might not be especially practical to use depending how it can be accessed. (you'd need to be able to access it fairly easily to make it useful as such)

I wasn't talking about loading more data from CD, but "hacking" the SH1/CD RAM as added general purpose storage. (again, that assumes other processors can access that RAM -they'd have to to some extent to load CD data, but the question is whether it's fast/easy enough to use for general purpose storage)

Normally, the SH1's work RAM is for buffering CD-ROM data and for SH1 program data and possibly code (I think it might be purely configured as an MCU though with all code on-chip or in external ROM).
And, yes, the SH1 isn't programmable, or at least Sega never released documentation or tools to support it.

Dosbox was set to "original" resolution, which turned out to be 320x200, and then normal2x. The internal detail setting was set to high because that matches the detail levels I saw in the PS1 and Saturn games.

There's no "original" resolution. The original DOS game (and demo) has 2 res options with 320x200 (the lowest common denominator for VGA) and 640x480 (selected in the options menu or by pressing F1).

The closest detail level is the lowest. Increasing detail adds perspective correction that makes the game look better than the Saturn or PSX versions.

The tearing is because Tomb Raider is a CPU hog and running it with Fraps dropped the framerate from 30fps to 22-27, with the very occasional dip into the high teens.

If it's that big of a problem, you should disable 2x scaling in DOSBox and enable double buffering. (DOS Box doesn't double buffer by default even if a game would be double buffering on real hardware -ie games tear that would never tear on a real DOS/9x machine)
Though double buffering in DOSBox can get screwy at times and seem to slow things down. (odd since double buffering should have basically no impact on performance)

Also odd that Voodoo emulation works so fast. I assume it takes advantage of modern hardware acceleration. (but that would also mean modifying performance compared to original hardware since such early accelerators always needed a fair chunk of CPU grunt for the 3D math/transform computations)

I searched for over a week for ways to optimize this, way longer than I should have for a simple comparison. The 3dfx Tomb Raider Dosbox patch is vastly preferred on tombraiderforums, but I wanted to show the original texture maps without filtering too.

It's not just filtering, it's a totally different color depth. Rendering in 256 colors makes the textures (and shading on untextured polys) get posterized (especially under certain lighting), and that's the main disadvantage to the PSX and Saturn versions.

Using 3Dfx should also allow effects to be disabled, so you could drop detail down to the level of PSX/Saturn. (I'll bet it also offers dithering as a detail option )

Thanks for that. Actually, I had to get Tomb Raider working on my in law's single core laptop more times than I'd like to remember. This video is not misrepresenting how Tomb Raider was played on PC, especially not in 1996.

The tearing is the exception to that though, it should be double buffered. (pretty much all DOS games from the early 90s onward were double buffered)

Of course, for a PC at the time, it really depended on the machine. (laptops of the late 90s would obviously be crap for such)

And if your PC DID run it that slow, it would run much worse with the 3DFX example as well. (CPU is a limiting factor with such old graphics cards)

No. Both versions are an inconsistent 30fps with occasional dips into the teens. The PS1 version doesn't dip as often in the gym/house scene though. The Saturn dips to 20FPS frequently in the box scene in particular.

It's the dips I was mainly commenting on. (that's the usual area of complain for framerate anyway, slowdown/stutter)



There's certainly nothing night and day about the Saturn and PSX versions, but I've never really felt otherwise.
The PSX has a slight advantage overall IMO, but not anything that would be a deal breaker for buying one system over the other with all else being equal. (the PSX controller WOULD be a deal breaker for me though -and that's including the model 1 Saturn controller, which really isn't too bad at all)
I've gotten rather used to playing TR with a keyboard though. (there are actually a few things that are easier that way, including the roll -hit up and down together or zero on the num pad)

[sheath]

Interesting, I guess it has a consistently high enough framerate to avoid significant tearing.

Tekken 3's claim to fame back in the day was its technical feat of running at 60fps. That's one of those facts that doesn't really show up in gameplay, as the only thing that visibly updates that fast is the floor and background if the camera moves.

VDP2 is basically unused in TR and many 3D games, so that 512k would be mainly useful for auxiliary storage if used at all. (not sure how convenient it is for added storage)
If it WAS practical for general storage as such, that WOULD give a realistic advantage over the PSX, but it would depend on how practical it is to use VDP2 RAM as such. (albeit not as much of an advantage as if VDP1 had a full MB of texture RAM, and more costly due to using 2 256k SDRAM chips and being on a separate bus with VDP2)

The framebuffers are rarely pushed close to capacity and thus also heavily inflate the Saturn's useful RAM. (they're generally not useful for any extra data either as they need to be used for other things)

One of the development docs says that the VDP2 renders from, or combines its backgrounds with, one of the framebuffers while the other one is being used by the VDP1. The description made it sound like both were being used at all times, regardless of whether they were "full". Wouldn't an engine that consistently maxed out CPU or RAM resources be inefficient anyway?

That's not one bus either, it's 2 or 3 separate buses (another cost inefficiency of the Saturn). You have the VDP1 bus for texture or "sprite" RAM and the framebuffer being rendered to (I don't think that framebuffer is on a separate bus) and then you have the VDP2 bus with the 2D tile RAM plus the framebuffer being scanned out to the screen by VDP2. (not sure if that's a separate bus or the same as that used for tile RAM)
The framebuffers are definitely separate banks in both cases, but separate buses is another matter. (there shouldn't be any advantage of having a 3rd bus, so it's probably just the 2 buses with the framebuffers being flipped between)

Yeah, I understand how that complicates programming for the Saturn. What I don't get is the Jaguar to PS1 texture mapping comparison fell to the PS1 because it had sub systems for game related thing. Yet the Saturn having more dedicated buses is inefficient. I suspect this is in the eye of the beholder.

If they WERE on the same bus, you'd have contention between VDP1 and VDP2 due to there being no buffering or caching. (unlike the PSX with heavy caching and buffering to allow efficient rendering in a single BANK of RAM on a single bus)

Okay, so the VDP1 having the frame buffers and its own RAM and the VDP2 having its own RAM and access to one of the frame buffers before outputting works because the system lacks buffers or cache for a unified structure. That's the why of the structure.

There's no "original" resolution. The original DOS game (and demo) has 2 res options with 320x200 (the lowest common denominator for VGA) and 640x480 (selected in the options menu or by pressing F1).

The closest detail level is the lowest. Increasing detail adds perspective correction that makes the game look better than the Saturn or PSX versions.

Well, my experience is different. Dosbox defaults to the setting of "original" resolution, that happened to be 320x200. Similarly, setting the internal graphic details to Highest made the textures and warping indistinguishable to the Saturn and PS1 games, as I tried to demonstrate in the video.

If it's that big of a problem, you should disable 2x scaling in DOSBox and enable double buffering. (DOS Box doesn't double buffer by default even if a game would be double buffering on real hardware -ie games tear that would never tear on a real DOS/9x machine)
Though double buffering in DOSBox can get screwy at times and seem to slow things down. (odd since double buffering should have basically no impact on performance)

Also odd that Voodoo emulation works so fast. I assume it takes advantage of modern hardware acceleration. (but that would also mean modifying performance compared to original hardware since such early accelerators always needed a fair chunk of CPU grunt for the 3D math/transform computations)

I even copied most of the 3dfx patch's dosbox.conf settings to level out where I did with vanilla Tomb Raider. I also tried recording without the normal2X setting but the performance differences were not noticeable. Double buffering only works in full screen, which totally sucked with Fraps running and didn't stop the occasional tearing anyway, which is why I disabled it.

It's not just filtering, it's a totally different color depth. Rendering in 256 colors makes the textures (and shading on untextured polys) get posterized (especially under certain lighting), and that's the main disadvantage to the PSX and Saturn versions.

Using 3Dfx should also allow effects to be disabled, so you could drop detail down to the level of PSX/Saturn. (I'll bet it also offers dithering as a detail option )

The in game detail options were locked. I did see that hitting the F3/F4 keys resulted in polygon tearing, and some of the textures moved but didn't seem to increase or decrease in detail like they did in the software rendered mode.

The tearing is the exception to that though, it should be double buffered. (pretty much all DOS games from the early 90s onward were double buffered)

Of course, for a PC at the time, it really depended on the machine. (laptops of the late 90s would obviously be crap for such)

And if your PC DID run it that slow, it would run much worse with the 3DFX example as well. (CPU is a limiting factor with such old graphics cards)

My 133Mhz Cyrix system with the Matrox Mystic 4MB either didn't run Tomb Raider well, or didn't run it as well as the Saturn did. I can't remember why I decided to stick to the Saturn version back in the day. I see occasional tearing in every PC game I have ever played to this day, with or without buffering enabled.

[Chilly Willy]

Isn't 16bpp the ONLY framebuffer depth the GPU supports? (the 24-bit mode being software managed)

Yes, 16bit is the only depth for hardware drawing, but you might have had a game that was slow (like an RPG) where they wanted the image to be as good as possible and so used software 24bit to avoid any dithering. I don't think any did, but they COULD have.

A bit odd that they'd even bother with triple buffering given the relatively limited advantages and significant disadvantages of eating up VRAM.

If you look at the vram dump, it's clear that vram space was not a problem... it's mostly empty even with three buffers! A lot of Jumping Flash is Goraud shaded polys, so they didn't need much vram for textures. Having three buffers meant they could run the game at rates between 30 and 60 Hz (although the video would naturally max out at 60 Hz). Using double buffer means that you either run at 60 Hz, or 30 Hz if you can't reach 60. There's no 59 Hz with double buffer video.

[The Coop]

[Team Andromeda]

Why does every thread have to do into a slagging match with Tech Spec's ?


I thought both the 1st and 2nd TR games to be utterly brilliant and my only faults were that I would have liked a save system to save exactly where you were in the level (at any point). I also thought the 3D of TR held up really well against Mario incredible given it was on 32bit systems and made by a tiny British company

[Chilly Willy]

I really loved the first Tomb Raider. I like the first three well enough, then lost interest in the series at number four. The third was perhaps the best of the three, but the first still has that "awesome new game" specialness that is hard to beat.

[Black_Tiger]

As I mentioned earlier, Tomb Raider was definitely overrated by Gamefan. My summed up quotes were actually nothing compared to the real deal. It helped that the game was on Playstation at the time. Here are scans of the game's coverage from a single issue-


Playstation Review

Saturn Review

Playstation Article Page1

Playstation Article Page2

Playstation Article Page3

Playstation Article Page4

Playstation Article Page5



Some classic quotes from Dave Halverson-

All one need do is read my TR review to know how awestruck I am with Core's soon-to-be-legendary new game. Lara's character of the century, and this game is beyond any adventure you've ever experienced. The ambient music, vast levels, intelligent enemies, brill CD cinemas an movie-quality story only begin to tell the tale. Buy a Playstation now if you haven't already. Tomb Raider will make your Christmas Merry!

Three years ago when I was talking to Jeremy Smith about Core's vision for the ultimate 32-bit adventure game, who'd have thought that it would end up one of the best games ever made?

After playing completely through the "perfect" Mario 64 and Crash Bandicoot, he's goes on to say that

...of the three, in my opinion, Tomb Raider is the best.

Newly-named Lara Croft is on a quest parallel to just about every Indianna Jones adventure in the book.

Lara's an astounding babe, and this is an astounding story that unfolds as you play a game, not watch a movie.

We begin with Lara herself, the most graceful and fun to control video game character of all time.

Lara does many things -so much so that you'll often feel you are controlling a living, breathing woman.

Lara has perfect control.

Vast does not begin to describe it.

Sadly, the Saturn version is but a shell of the godly PS version, which is so good, I would urge you to rent or buy a PS just to enjoy this version.

One thing for sure, Tomb Raider gets my vote for game of the year - and perhaps of all time.

Caption of screen shots depicting the handstand/cartwheel-

It doesn't get any better.

Also check out Takuhi's Playstation review.

As I mentioned earlier in the thread, even if time has shown how overrated Tomb Raider was, the fact that they trashed the "perfect" game on Saturn because the graphics weren't as good already makes them hypocritical. By Dave Halverson's own words, the Saturn had a better game than Mario 64 and Crash Bandicoot, but he scored it much lower.

[kool kitty89]

Yes, 16bit is the only depth for hardware drawing, but you might have had a game that was slow (like an RPG) where they wanted the image to be as good as possible and so used software 24bit to avoid any dithering. I don't think any did, but they COULD have.

24-bit was probably used most for splash screens with high detail images and similar situations.

One of the development docs says that the VDP2 renders from, or combines its backgrounds with, one of the framebuffers while the other one is being used by the VDP1. The description made it sound like both were being used at all times, regardless of whether they were "full".

Yes, sort of, it's rather like the 32x or somewhat like VGA cards on PCs (except I don't think many -if any- VGA cards used hardware page flipped buffers like that, most used single banks of DRAM or VRAM AFIK).
It's also somewhat comparable to how the ASIC works in the MCD. (except you aren't page flipping dual buffers there either, but DMAing to MD VRAM)

VDP1 is a blitter of sorts that renders into a framebuffer. That buffer is then flipped to active display and the other buffer is flipped to VDP1 to render into.
This is very much like how the 32x uses its 2 128k buffers with one being rendered to while the other is monopolized by the Super VDP scanning it out to the screen. (and also handles analog genlock with MD video)

In the Saturn, VDP2 handles all the video DAC duties. It scans the active display framebuffer out to the screen. (and combines the other VDP2 layers along with that)

I believe the frambuffer that VDP2 scans out is treated somewhat like the ASIC rendering to a MD BG layer such that most/all of the effects VDP2 can apply to its tile layers can be applied to the framebuffer layer. (screen scrolling, line scroll, rotation, etc -I think it can do 3D warping effects and translucency as well, but I'm not positive -maybe even per cell translucency if the framebuffer is actually treated as a VDP2 tilemap)

So in that sense it's "VDP2's" framebuffer, but that's oversimplifying it big time. You need both framebuffers for VDP1 to display anything, just like the 32x. It's hardware double buffering. (OK, technically you COULD get by with 1 buffer if you only rendered in vblank, but that's pretty unrealistic and would mean single buffering for most resolutions)

Wouldn't an engine that consistently maxed out CPU or RAM resources be inefficient anyway?

How do you mean? An efficient game would squeeze out as much CPU resource as possible with almost no idle time (less optimized games would have a lot of idle CPU time where it's waiting for another operation to complete rather than multitasking as best as possible).

Likewise, a good game would pack as much into RAM as possible and get as close as possible to 100% utilization. The only reason you'd want added "open" space would be for additional buffering. (either to stream more date from CD on the fly, decompress on the fly, or as a buffer to move data between different subsystems -like if you wanted to use sound RAM for added game data or textures in the PSX you'd want to leave a small buffer available in main RAM to copy into and another buffer region in VRAM if you were doing on the fly texture updates -just like you wouldn't fill all of MD/SNES/SMS/PCE VRAM if doing on the fly animation updates)

That's definitely NOT the case with the Saturn's framebuffers, or the 32x framebuffers for that matter. (except in that case, the added buffer space makes scrolling easier as you can have the 256 color buffer extend into overscan)

It's not like ROM where you'd want to cut back as much as possible on memory usage. (though in that case, maxing out RAM would also be a good thing, compressing as much as possible and loading into RAM ahead of time)

Yeah, I understand how that complicates programming for the Saturn. What I don't get is the Jaguar to PS1 texture mapping comparison fell to the PS1 because it had sub systems for game related thing. Yet the Saturn having more dedicated buses is inefficient. I suspect this is in the eye of the beholder.

The jaguar and N64 opted for single bus designs to save on cost. There are other trade-offs for low cost on multi-bus designs, and other trade-offs with using wider buses. But, in general, a highly optimized design using a single high-bandwidth bus would be the most cost effective. (though it also requires some of the most intensive R&D to pull off)

The PSX opted for a multi-bus design and was thus more expensive, but the GPU was heavily buffered for high bandwidth and efficient operation on a single bus. (still it was only 32-bits wide and thus required faster, more expensive RAM to achieve that bandwidth than the likes of the Jaguar -of course, having 32 data lines would save cost on the PCB and chip packages over 64-bits, so it's a design trade-off too -hence the N64 using extremely fast high-end RDRAM with a 8/9-bit bus -also facilitated by their partnership with SGI)
I think it also may have used dual-port VRAM for video rather tan cheaper normal DRAM, but I'm not positive. (using dual port VRAM would increase performance by cutting out overhead to read the framebuffer)

Sony could afford to support a higher-end design for the added performance, but if you had a company with fewer advantages, the based PSX chipset (or a very similar one) could have been configured at far lower cost by merging it into a single bus design. (it would have been lower performing, but with better cost to performance ratio as well)
Rather like how the jaguar could have had much higher performance if it was a multi-bus design, let alone if it used expensive/higher-end CPUs, RAM or number of buses on the level of the PSX or Saturn. (even a dual bus configuration closer to the 3DO would have been extremely significant though, or keeping the single bus design and adding a better CPU with a cache, adding RAM to the 2nd bank to improve bus sharing a bit more and improve texture mapping; let alone bumping to 26.6 MHz EDO DRAM rather than the 13.3 MHz FPM DRAM -or adding a 32k SRAM chip as a high-speed external texture buffer -of course, even more options for an even more cost effective design if you developed the custom chips further, and that's exactly what the jaguar 2 design was doing)

The Saturn OTOH was not a very aggressive design and was also riddled with feature creep that kept it from a practical mass market cost/price point as well. (the 3DO was a very conservative design too, but it was at least relatively simple and designed in a way that further consolidation would be substantial -given the large 1 micron chips initially used- it also cut back cost by using a 2 bus design, cheap DRAM for main memory, and a low-cost CPU -even with the large/old process chips and use of dual-port VRAM, it should have been nominally cheaper to manufacture than the PSX and definitely Saturn if pushed at similar margins and volumes -of course, Sony's vertical integration would deflate the manufacturing cost of the PSX and skew that comparison)

The most aggressive design element of the Saturn was also probably its least useful one for the 5th gen market: VDP2. Albeit, even then it wasn't that impressive given the jaguar had an even more powerful 2D engine with the object processor and the blitter to assist that and all on-chip with the RISC GPU, MMU, blitter, and 4kB SRAM scratchpad. (granted, it couldn't push rotated/warped objects as fast as VDP1 due to the slow texture mapping, same for the VDP2's mode-7 like scaling/rotation effects -it could scale objects extremely fast, just not distort or rotate, more like the PSX's sprite mode but managing a lot more with less bandwidth as it wasn't a blitter but a specialized list processor)
And, on top of that, the Jaguar did that while using slow/cheap commodity DRAM on a single shared external bus.

The Saturn has at least 6 external buses (SH1/CD-ROM subsystem memory, main CPU memory, VDP1, VDP2, and audio), and more banks of RAM on top of that (the framebuffers are configured as separate banks to allow separate source and destination banks for VDP1 rendering -I'm assuming texture and framebuffer RAM banks are not actually on separate buses since that would be unnecessary).

It uses a ton of (for the time) expensive SDRAM, but uses it at such speeds that it's totally unnecessary. (cheaper EDO DRAM would be as fast; the only explanation I've heard was Chilly Willy mentioning that SDRAM's synchronous interfacing would allow cutting corners on R&D costs and time -sort of like using PSRAM and/or SRAM instead of similarly fast DRAM on some older consoles- . . . except the Saturn and 32x both also use asynchronous DRAM, so that makes things more confusing -maybe they already had FPM DRAM interfacing configured but didn't want to invest for EDO DRAM)
Of course, they could have use ALL cheap FPM DRAM and buffered for wider bus widths for high bandwidth. (exactly what the jaguar did . . . except for texture mapping unfortunately -had flare though texture mapping was really high priority for 3D back in 1990/91, they could have put more focus on that than other features and had close to PSX speed texture mapping while still using the same RAM as the current Jag -one discussion on Atariage brought up that such texture mapping would take less chips space than the Z-buffer logic, but flare apparently felt Z-buffering was a more important feature at the time -something the 3DO, Saturn, and PSX all lack in hardware)
The 32x is also pretty inefficent, but that's more excusable due to it being developed in about 6 months. (if the Saturn had been a fully backwards compatible, evolutionary design, some inefficiency would also make more sense . . . except compared to the current Saturn, a well-optimized MD+CD based machine could have been significantly more cost effective still)

Then there's the generally wasteful use of the SH1, overbuilt custom sound system, but that's a common problem of the time. (though in the Saturn's case it ironically still lacked a common feature -decompression, or a DSP/CPU capable enough to do it in software -DSP in the SCSU doesn't have the right features, 68k isn't fast enough to do ADPCM for more than a few of the channels at once -OK for a SFX engine, but not for a complex realtime music engine . . . albeit it doesn't seem like developers pushed it for SFX even).
Then there's the 512k of SDRAM for that SH1. (128k or even 512k of cheap DRAM would have been much more cost effective and even 128k would have meant more buffer space than the PSX or 3DO -128k DRAM would probably have been cheaper than the 32k SRAM in the others)

Anyway, having more dedicated hardware isn't inefficient, it's generally MORE efficient (hence dedicated blitters, sound processors, GPUs, etc rather than having a CPU do everything or a bunch of off the shelf stuff -like arcade games and workstations often do or did).
The problem is that it's often unclear exactly WHAT features will be definitively important in hardware.
If advanced 2D BGs with proportionally limited sprite/object (and 3D) rendering had dominated the mass market in the mid 90s, then the Saturn's VDP2 (and PC-FX) would have made a lot more sense, but there was no indication of that whatsoever.

For the time (ie 1992-94), the most sensible option would have been to put emphasis on a aggressively engineered flexible blitter capable of high bandwidth and possibly working on a shared bus with the CPU and audio (or at least one single bus/bank for rendering/framebuffer/texture data). Optimizing for efficient and consistent use of memory with caching and buffering to maximize bandwidth (keep it close to peak bandwidth) would be key.
They could even have focused solely on the 2D drawing operations and required CPU or coprocessor assistance for full 3D rasterization or warped objects. (you'd have optimization for high bandwdith 2D objects/BGs and scaled/rotated objects, but like the Jag blitter and MCD, would need added resource for warped primitives and planes; that way you also avoid favoring quads or triangles or wasting logic to cater to quads specifically -one thing that could help for coprocessor based rasterization would be a drawing command cache/buffer that the coprocessor could periodically update rather than having to constantly manage the blitter, making multitasting much easier for the coprocessor GPU/CPU/DSP -whatever is used; that's one problem with the Jag GPU+blitter configuration as it is: you need careful coding to efficiently multitask while rasterizing 3D, otherwise the GPU ends up waiting to send the next drawing command while the blitter is drawing -thus, without very careful coding, you'd need to halt the blitter for the GPU to do other tasks like calculating 3D math, trasform, lighting, object lists, gale logic or physics, etc)


On that note the N64's design is inherently flexible, but used in a very fixed-function manner for the vast majority of cases. More dedicated logic could have been cheaper (ie less silicon for similar performance) than having the RSP do it in software (via microcode).
The N64 chipset was an extremely tight design in terms of consolidated and aggressive chip design and cost effectiveness, and the flexibility seen with it was the most foolproof option for the time, but in hindsight the flexibility was largely unnecessary. (though, actually, given SGI's emphasis on polygonal 3D from the start -and similar in their workstations- it doesn't seem like that flexibility was aimed at being able to program microcode tuned for 2D or "pseudo 3D" rendering, so that may actually be more of a coincidence)

That flexibility DOES apply to fully polygonal 3D as well, of course, so that's a plus too. (especially given the poorly balanced performance of SGI's standard microcode) and if that standard microcode's feature set had been been implemented in hardwired logic, developers would have been totally stuck. (granted, given the poor microcoding support for the RSP, that was the case for most developers anyway)


Having more buses or expensive RAM where cheaper RAM could be as good (or better) is the inefficient thing. Same for using more silicon where a more aggressive design with less silicon could do better. (a huge part of that is an aggressive R&D effort targeting cutting edge chip fabrication processes -like how Atari used .5 micron when 3DO was using old 1 micron process chips and when new high-end CPUs were just reaching .6 micron and more often closer to .8 micron -the first .5 micron CPUs arrived in 1994 with the likes of the Power PC 603)

The fixed-function GTE was almost certainly a cost saving option over a flexible coprocessor (unless they dialed back performance considerably), and probably savings for R&D as well. (investing in R&D to bring up the R3000 to a reliable 66 MHz would have been one other direct trade-off for R&D -that would have used less silicon too, but yields may have been more of an issue, if not heat dissipation)



Now, putting that all in perspective to the Saturn: if you ignore the feature clash with market demands at the time (the Jaguar and N64 weren't ideal in that regard either -the PSX wasn't for that matter, but closer), the issue of it being inefficient is a matter of cost effective design.
If the Saturn effectively did everything it does now at the speed it does now (more or less), but did so with fewer, more consolidated chips, fewer buses, and cheaper RAM, it would be a much better system.
Specifically, if it could mean things like cut to a 1 bus design with 4 MB 64-bit EDO DRAM and enough buffering for similar overall bandwidth as the Saturn, or perhaps 32-bit SDRAM clocked at 2x the speed (albeit, the SH2s wouldn't be able to take advantage of added bandwidth in either of those cases), or perhaps a 2 bus design using 32-bit EDO DRAM in 2 2MB banks (1 for video, 1 for audio and CPU).
In the long run a single faster CPU would be more cost effective (more expensive initially, but cheaper in the long run due to board space and traces, plus more performance), but there aren't many options for that unless they delayed the release or got hitachi to produce special high-speed SH2 variants. (putting one CPU on the video bus and one in main could be another option to improve cost effectiveness -not cheaper, but potentially better performance and the ability for both CPUs to work in cache simultaneously -perhaps the one could be treated as a GPU-like coprocessor -cutting out the audio DSP and the little-used SCU DSP would save on cost too, more so if the sound system was cut back to more basic DMA audio with buffering for bus sharing with the CPU, or maybe switch to an off the shelf option like Yamaha's OPL4 and add some embedded interface logic to allow it to efficiently share main RAM rather than requiring dedicated SRAM)

The CD-ROM system should have been cut back to an embedded MCU managing data transfers and the cache/buffer. (perhaps use a cheap 128k DRAM chip for the buffer -cheaper than SRAM and more space to work with)

Actually, for the time, the Jaguar 2 concept (and working prototype) was probable the most well balanced and cost effective in the industry. (not the best performing in all categories, but that was due to a low-cost configuration)
Something 1/2 way between the Jag and the Jag 2 would have been perfect for what Sega wanted (powerful and flexible 2D performance and capable 3D performance), but extremely consolidated and cost effective. (more so since the RISC core used for the GPU and DSP also made for a decent CPU at the time, so they could cut out the overhead of buying an off the shelf CPU and also never worry about having to license a CPU for custom consolidation into the chipset)
Of course, the market at the time really didn't demand 2D power on the level of the object processor (putting all emphasis on the blitter for 2D and 3D would make more sense), but it certainly would have been in line with SoJ's desires at the time. (and would have been awesome for 2D in the arcade)


For that matter, if the Saturn DID retain such an expensive configuration, but actually did something useful with it, it could be an arguably good design. Like if the SDRAM was actually clocked close to 60 MHz and most/all processors could take advantage of that. (except that even at 2x the clock speed, VDP1 would have less peak bandwidth than the PSX GPU's VRAM -16 bit at 57.3 MHz is 114.6 MB/s vs the 133 MB/s of the PSX)
So to really push that, it would involve one of the above sort of circumstances of buffering, but with more buses on top of that. (like 32-bit SDRAM close to 60 MHz dedicated to VDP1 . . . except that's impossible with the current configuration of RAM chips Sega used)



Things like quads, difficult to work with architecture and weak tools (exacerbated by the architecture, but more due to Sega's organization.management problems) are separate issue from the cost ineffectiveness of the hardware.
In Sega's position (being a 3rd party hardware maker with outsourced manufacturing), they needed a MORE aggressive and MORE cost effective design than Sony to pull it off on a cost/price competitive basis.
That, or just a cheaper and less powerful design. (especially with the benefit of backwards compatibility or even more friendly architecture and tools, more so if the performance was even more optimized for the market than the PSX)

Sega had that with the Dreamcast over the PS2, and if Sega had had that sort of advantage in the previous generation, they'd have been far, far better off. (given the hardware/cost issues exacerbated management issues, that would have been even more significant -especially if it was low cost enough to displace the 32x/mars project)

Best case for Sega by late 1993 would have been an aggressive approach to stripping down the Saturn and improving cost efficiency where possible. (it COULD have been made cheaper than the PSX, and more cost effective than the existing Saturn for sure, but there wasn't enough time to make it similarly or more cost effective than the PSX unless they delayed the release until '95)

And, of course, developers don't care about cost effective manufacturing, they just care about the capabilities and ease of accessing that. (and market share of the console, of course, and that's tied to a lot of different factors -including price point and marketing; cheaper hardware allows more favorable margins at lower price points and thus more funds for marketing )

Edit:
Heh, that was a long rant . . . at least I've got something fairly coherent (could be a lot better, granted) to link to rather than constantly rehashing things piecemeal fashion.

Okay, so the VDP1 having the frame buffers and its own RAM and the VDP2 having its own RAM and access to one of the frame buffers before outputting works because the system lacks buffers or cache for a unified structure. That's the why of the structure.

VDP1 has the separate framebuffers for 2 reasons: 1 to flip the buffers to a separate bus to be scanned out to the screen (like the 32x Super VDP), and 2 to allow consistent use of SDRAM in page/burst mode rather than suffering slow random accesses. (the PSX has buffering and caching to address that; the 3DO steals the main bus to do that by comparison -for the 3DO, main RAM is more like VDP1 texture RAM and VRAM is more like VDP1 framebuffer RAM)

Then there's VDP2's own tile RAM used independently for the VDP2 tile layers. (VDP1 RAM and the framebuffers are totally unused for the 5 VDP2 BGs)

Well, my experience is different. Dosbox defaults to the setting of "original" resolution, that happened to be 320x200. Similarly, setting the internal graphic details to Highest made the textures and warping indistinguishable to the Saturn and PS1 games, as I tried to demonstrate in the video.

Hmm, must be some odd settings in DOSbox . . .
320x200 is the default when you fist boot the game, as is low detail. (you have to use the function keys or options menu to change that)

DOSBox should display in the native resolution of the program unless scaling is enabled. (or aspect correct to stretch 320x200 to 4:3)
I also switched to open GL for rendering DOSbox since direcdraw is buggy and problematic on my computer. (and 320x200 doesn't display at all, though 320x240 works)

I even copied most of the 3dfx patch's dosbox.conf settings to level out where I did with vanilla Tomb Raider. I also tried recording without the normal2X setting but the performance differences were not noticeable. Double buffering only works in full screen, which totally sucked with Fraps running and didn't stop the occasional tearing anyway, which is why I disabled it.

Odd, full-screen should be no more intensive than window mode. (with both set to the same scaling/aspect correct options)

The in game detail options were locked. I did see that hitting the F3/F4 keys resulted in polygon tearing, and some of the textures moved but didn't seem to increase or decrease in detail like they did in the software rendered mode.

Yes, that's normal. The screen will tear or flicker when adjusting detail options. F3 expands the game window while F2 shrinks it (if already full-screen, F3 will do nothing but make the screen blip).
F4 toggles detail (perspective correction) and you should see an immediate change in texture warping when doing that. (there's 3 levels; low with no correction, medium with correction on near objects only, and high detail with correction on most/all visible areas of the scene)

F1 toggles between 640x480 and 320x200.

My 133Mhz Cyrix system with the Matrox Mystic 4MB either didn't run Tomb Raider well, or didn't run it as well as the Saturn did. I can't remember why I decided to stick to the Saturn version back in the day. I see occasional tearing in every PC game I have ever played to this day, with or without buffering enabled.

Accelerated or unaccelerated? If you ran accelerated with the matrox (one of the cards to use the crappy S3 ViRGE chipset iirc) and pushed the settings too high, it would have been substantially slower than plain software rendering. (with filtering, perspective correction, dithering, fog, etc all disabled, it should have been faster than 256 color rendering at the same resolution, but in higher color with less posterization)

Running at 640x480 in high detail probably would have been pushing it for a 133 MHz pentium class CPU, but dropping to 320x200 and low detail should have had it faster than the Saturn. Albeit, if you weren't using perspective correction or 640x480 mode, it would lose all advantages over the Saturn version -slightly lower resolution and 256 color vs highcolor. (if you could run at 640x480 low detail or 320x200 high detail, there would be advantages over the Saturn version though)

[Silanda]

Accelerated or unaccelerated? If you ran accelerated with the matrox (one of the cards to use the crappy S3 ViRGE chipset iirc) and pushed the settings too high, it would have been substantially slower than plain software rendering. (with filtering, perspective correction, dithering, fog, etc all disabled, it should have been faster than 256 color rendering at the same resolution, but in higher color with less posterization)

The Mystique used its own chipset that was supposedly faster than the shit heap known as the Virge, but had a somewhat weak feature set IIRC. It was also significantly slower than the Voodoo 1.

[sheath]

The Mystique had no hardware 3D acceleration. It's claim to fame was the 4MB RAM for better texture mapping, which only affected those few games that were made specifically for Matrox cards.

Black_Tiger, thank you for the scans. Having played all three versions of Tomb Raider recently I can not see any reason to call only one version "godly" to be sure.

[Silanda]

The Mystique had no hardware 3D acceleration. It's claim to fame was the 4MB RAM for better texture mapping, which only affected those few games that were made specifically for Matrox cards.

AFAIK this isn't quite right. From what I remember, and from everything I can find, it did support 3D acceleration, and had a Direct3D driver, but was missing a hell of a lot of features that it was really taken for granted that a 3D accelerator would have. Bilinear filtering, mip mapping, alpha blending? Not on the Mystique.

[sheath]

That could be true, and certainly might have confused me early on about Direct 3D versus Direct Draw capabilities.

I ended up picking up the Matrox M3D PCI expansion to get full 3D accelerated effects. About the only thing that worked on was the 'X' demo that I used to benchmark my system before 3DMark.