Support NeoGAF

[SkylineRKR]

Yeah well in laymen terms the Saturn had no transparancies, the bulk of commercial software didn't have them and showed ugly shadows and dithers. Including the more popular games like SR.

If you were a customer and you would walk into a store that ran Wipeout, Destruction Derby side by side. Or Daytona vs RR, or VF vanilla vs T1, the Saturn had already lost. It was simple as that. The potential was probably there, and -some- games did things PSX couldn't do (vice versa too), but what mattered is where did the most popular games of 1995 and 1996 look best, and who had the most interesting lineup? This was clearly PSX. The Saturn was quite a bit more costly, this was a gut punch. But on top of that it didn't show customers why it was so expensive, and how it was exactly superior to PSX.

Yeah eventually 2D fighters showed Saturn had an advantage, but the reality is that no one gave much fucks about 2D around that time.

Yeah I remember people claiming for decades that Japanese Saturn Tomb Raiders fixed the frame rate issues

John Linneman proved this was bollocks

I had Tomb Raiders. It ran the same to me, it wasn't better. I owned a English copy as well.

For every game that runs badly on the Saturn there will be at least one person blaming something other than the system itself.

The same thing applies for the Dreamcast. If a port on the PS2 is better the reason is because something unrelated to Dreamcast's hardware is holding it back. Maybe a delay, maybe the developer didn't care, whatever. It's never because the other system is simply better.

But if something runs badly on a non-Sega console? It's "weakness". Or "bottleneck". Or "badly designed hardware".

This is a double standard i notice with a lot of Sega fans, ever since i was lurking in the Sega16 forums. I understand being a Sega fan in the mid/late 90's was difficult (there was a lot of unfair pushing against the Saturn by gaming magazines and game stores) but it's over guys.

Yeah this is true. Those early Sega to PS2 ports had a lot of flak aimed at the PS2, it was 'proof' the PS2 was weaker. Same with the quick and dirty, unsanctioned by Itagaki release of DoA2. Those fans forget a few things. Games like DoA2 were created on Naomi hardware, which was the same architecture as the DC. Games like Headhunter were also specifically developed for DC hardware. They were quickly ported. Ps2 still runs them, and in case of DoA, actually added a ton of things. Ps2 eventually ran games like VF4 Evo from Naomi 2 fairly well.

Now, lets do this in reverse. Imagine the DC gets a port of MGS2, GT3 and Jak around 2001. That would turn out well wouldn't it?

 

[cireza]

Games like DoA2 were created on Naomi hardware, which was the same architecture as the DC. Games like Headhunter were also specifically developed for DC hardware. They were quickly ported.

But doesn't this apply to PS1 games ported to Saturn as well, such as Doom, SotN, Destruction Derby etc... ? All could have made a much better use of the hardware.

 

[SweetTooth]

For every game that runs badly on the Saturn there will be at least one person blaming something other than the system itself.

The same thing applies for the Dreamcast. If a port on the PS2 is better the reason is because something unrelated to Dreamcast's hardware is holding it back. Maybe a delay, maybe the developer didn't care, whatever. It's never because the other system is simply better.

But if something runs badly on a non-Sega console? It's "weakness". Or "bottleneck". Or "badly designed hardware".

This is a double standard i notice with a lot of Sega fans, ever since i was lurking in the Sega16 forums. I understand being a Sega fan in the mid/late 90's was difficult (there was a lot of unfair pushing against the Saturn by gaming magazines and game stores) but it's over guys.

What else you expect from deranged furries?

 

[nkarafo]

But doesn't this apply to PS1 games ported to Saturn as well, such as Doom, SotN, Destruction Derby etc... ? All could have made a much better use of the hardware.

Was Saturn DOOM a PS1 port? I thought they were all Jaguar ports.

Anyway, Saturn DOOM was not really the console's fault, Carmack pretty much ruined the port. The Saturn could easily handle a good DOOM port, judging from other games like Hexen, Duke Nukem and Powerslave.

SOTN could also be better, though i'm not sure about the transparencies, the original game makes heavy use of them.

Destruction Derby was probably too much for the Saturn.

 

[cireza]

Was Saturn DOOM a PS1 port? I thought they were all Jaguar ports.

This is bad faith and you know it.

Destruction Derby wasn't too much at all. It had a flat ground. Using VDP2 for it would have saved a ton of polygons. Imagine having a flat ground, developing on Saturn, and not using VDP2 for it...

SotN doesn't use VDP2 as it should either. Transparencies don't matter as much as people want us to believe. It could have been perfectly smooth.

Game runs poorly on PS2 = rushed port
Game runs poorly on Saturn = shit console

We got your point. But you are wrong though.

 

[nkarafo]

This is bad faith and you know it.

Lol, what? How?

I thought all console DOOM ports are based on the Jaguar port. How is that statement an attack against the Saturn?

Game runs poorly on Saturn = shit console

I just posted how DOOM could be much better on the Saturn.

I literally posted that on the very post you just quoted.


.....

I think you are getting a bit paranoid.

 

[Arioco]

It wasn't like FF7 was doing anything beyond the Saturn and if FF7 had to Saturn it would have been developed with its limitations in mind.

I'm not sure you're remembering FFVII as it really is, but the situation is VERY different from other games like Tomb Raider or Resident Evil, which just lost some little details here and there on Saturn (and maybe some fps), like a semitransparent shadow here or a smoke effect there. In FFVII every battle is literally full of all kinds of semitranspatent effects, rays filling the screen, particles everywhere, smoke, explosions, fire, ice, mist, the weapons leaving a semitransparent trail when hitting the enemies... Even the whole characters and enemies becoming gradually transparent. All that kind of stuff Saturn was notorious for struggling with. And it ran at just 20 fps on PSX. So yes, FFVII did do a lot of cool things beyond the Saturn. Had it launched on Saturn it would've been a very different game visually, more so than many other multiplat games that generation that compared not particularly well against the PSX version.

 

[Team Andromeda]

I'm not sure you're remembering FFVII as it really is, but the situation is VERY different from other games like Tomb Raider or Resident Evil, which just lost some little details here and there on Saturn (and maybe some fps), like a semitransparent shadow here or a smoke effect there. In FFVII every battle is literally full of all kinds of semitranspatent effects, rays filling the screen, particles everywhere, smoke, explosions, fire, ice, mist, the weapons leaving a semitransparent trail when hitting the enemies... Even the whole characters and enemies becoming gradually transparent. All that kind of stuff Saturn was notorious for struggling with. And it ran at just 20 fps on PSX. So yes, FFVII did do a lot of cool things beyond the Saturn. Had it launched on Saturn it would've been a very different game visually, more so than many other multiplat games that generation that compared not particularly well against the PSX version.

FF7 was not an amazing looking game for in-game graphics and Saturn could have handled a port, lets face it even the FMV (not all Saturn FMV was crap)

The point you see to miss is that if Square had gone with Saturn then it would have been made and designed with all the systems strengths and weaknesses in mind, hell it might have even supported the Video card. FF7 looked very different when on the N64 for example and you could have transparencies and nice effects in Saturn RPG's you had make use of the Hardware and work around it. Grandia is a much better looking game than FF7 IMO and that's a game that looks worse on the PS1 than the Saturn even the FMV runs in higher res on Saturn.

But it comes as no surprise as that was a game based around Saturn hardware. That's the way it was back then, same went for the Mega Drive and Snes

 

[Putyouinmyoven]

You can tell by the sound of the Guys checked out voice that he doesn’t mean it.

 

[cireza]

I'm not sure you're remembering FFVII as it really is, but the situation is VERY different from other games like Tomb Raider or Resident Evil, which just lost some little details here and there on Saturn (and maybe some fps), like a semitransparent shadow here or a smoke effect there. In FFVII every battle is literally full of all kinds of semitranspatent effects, rays filling the screen, particles everywhere, smoke, explosions, fire, ice, mist, the weapons leaving a semitransparent trail when hitting the enemies... Even the whole characters and enemies becoming gradually transparent. All that kind of stuff Saturn was notorious for struggling with. And it ran at just 20 fps on PSX. So yes, FFVII did do a lot of cool things beyond the Saturn. Had it launched on Saturn it would've been a very different game visually, more so than many other multiplat games that generation that compared not particularly well against the PSX version.

Nothing that was done better than Panzer Saga or Shining Force III.

 

[cireza]

I thought all console DOOM ports are based on the Jaguar port. How is that statement an attack against the Saturn?

Saturn version is a rushed PS1 port, everybody knows this.

 

[Team Andromeda]

Nothing that was done better than Panzer Saga or Shining Force III.

I would agree mostly and people also look over how wonderful Dark Saviour looked and that was a early game, but to be fair Vagrant Story was the best looking RPG on the 32-bit systems and there was no hope of Saturn matching that.
Thought to be fair the game came out in 2000 when most of the PS1 tricks would have been widely known at that point

 

[cireza]

I would agree mostly and people also look over how wonderful Dark Saviour looked and that was a early game, but to be fair Vagrant Story was the best looking RPG on the 32-bit systems and there was no hope of Saturn matching that.
Thought to be fair the game came out in 2000 when most of the PS1 tricks would have been widely known at that point

Sure. But FF VII is definitely manageable.

 

[Team Andromeda]

Saturn version is a rushed PS1 port, everybody knows this.

It wasn't even rushed. It was the fact that John Carmack wouldn't allow Jim to use the VDP1 to draw and handle the game for fear of warping. I think John Carmack even said sorry to Jim on Twitter and said he was was wrong.

If not for John the Saturn version would have looked better

https://www.retrovideogamer.co.uk/rvg-interviews-jim-bagley/

Yes, and no, we were given the PC and PlayStation data, but initially, I wanted to use the Saturn’s hardware to its max potential, and wrote a render engine to display the PC levels drawing the walls with the GPU, the problem I came across, was apparently John Carmack wasn’t happy about this, he wanted it to look exactly the same as the PC version, but it looked a lot nicer, and was running full screen at 60fps, he said it had to be drawn using the CPU, and not the GPU, he even suggested I used the two DSPs on the Saturn to render the screen, but as they only have 4KB,

Didn't Hexxen run better on the Saturn mind?, Funny how that's never brought up by the PS1 fans

 

[Team Andromeda]

Sure. But FF VII is definitely manageable.

Other than FMV there's nothing that would trouble the Saturn 3D wise.

I

 

[Geometric-Crusher]

I also thought that the Saturn could run any pre-rendered PS1 game, but a homebrew programmer told me that thanks to the garbage dual-pool memory system, the Saturn cannot run such games except using the expansion cartridge to eliminate the bottleneck, and before you use RE1 or Deep Fear, these games only have 8 cameras per room while pre-rendered PS1 games operate with up to 16 camera angles per room.
Sorry to burst the bubble, FFVII is beyond the Saturn's capabilities in terms of pre-rendering, real-time graphics and effects.

 

[PaintTinJr]

It wasn't even rushed. It was the fact that John Carmack wouldn't allow Jim to use the VDP1 to draw and handle the game for fear of warping. I think John Carmack even said sorry to Jim on Twitter and said he was was wrong.

If not for John the Saturn version would have looked better

https://www.retrovideogamer.co.uk/rvg-interviews-jim-bagley/







Didn't Hexxen run better on the Saturn mind?, Funny how that's never brought up by the PS1 fans

Surely the bigger question - other than why John really didn't let him use the VDP1 3D back then on a 2.5D game before Quake2 that relied on John's pioneering software raster technique- is why didn't the Saturn do a great job in software alone, given how well Doom ran on PCs like my friend's crappy off the peg Compaq 80386SX 20Mhz with 2MB + 3.5" and 5.25" FDDs and something like a 100MB HDD - that later needed me to fit a 2x CD-ROM for X-wing/Day of the tentacle.?

 

[RoboFu]

I also thought that the Saturn could run any pre-rendered PS1 game, but a homebrew programmer told me that thanks to the garbage dual-pool memory system, the Saturn cannot run such games except using the expansion cartridge to eliminate the bottleneck, and before you use RE1 or Deep Fear, these games only have 8 cameras per room while pre-rendered PS1 games operate with up to 16 camera angles per room.
Sorry to burst the bubble, FFVII is beyond the Saturn's capabilities in terms of pre-rendering, real-time graphics and effects.

16 camera what !? lol

Can we not get a thread ban on this guy yet?

 

[cireza]

Surely the bigger question - other than why John really didn't let him use the VDP1 3D back then on a 2.5D game before Quake2 that relied on John's pioneering software raster technique- is why didn't the Saturn do a great job in software alone, given how well Doom ran on PCs like my friend's crappy off the peg Compaq 80386SX 20Mhz with 2MB + 3.5" and 5.25" FDDs and something like a 100MB HDD - that later needed me to fit a 2x CD-ROM for X-wing/Day of the tentacle.?

Because it is running unoptimized PS1 code. Same shit as usual with PS1 to Saturn ports.

Or maybe you want to make a point about the Saturn being unable to run Doom when it runs Exhumed, Hexen, Duke Nukem 3D and Quake ?

 

[RetroGamingUK]

I also thought that the Saturn could run any pre-rendered PS1 game, but a homebrew programmer told me that thanks to the garbage dual-pool memory system, the Saturn cannot run such games except using the expansion cartridge to eliminate the bottleneck, and before you use RE1 or Deep Fear, these games only have 8 cameras per room while pre-rendered PS1 games operate with up to 16 camera angles per room.
Sorry to burst the bubble, FFVII is beyond the Saturn's capabilities in terms of pre-rendering, real-time graphics and effects.

Eh, Resi 1 on Saturn had the same camera angles and backgrounds as the PlayStation bersion

Character models (well, textures and lighting actually) were a downgrade though.

 

[RoboFu]

Eh, Resi 1 on Saturn had the same camera angles and backgrounds as the PlayStation bersion

Character models (well, textures and lighting actually) were a downgrade though.

That was a low budget port by Nextech which is a trend on the Saturn.

 

[Parazels]

Transparencies don't matter as much as people want us to believe. It could have been perfectly smooth.

I don't understand either, why they concentrate on transparencies so much.

I personally even like those fake grey transparents on Saturn.

 

[Geometric-Crusher]

Eh, Resi 1 on Saturn had the same camera angles and backgrounds as the PlayStation bersion

Character models (well, textures and lighting actually) were a downgrade though.

at least the port was possible, if we had a programmer like XL2 here he would explain it better, ignorant people like me simply don't accept this information, I myself found it difficult to accept that this limitation in L-Ram and H-Ram memory was so serious to the point of making pre-render games with up to 16 camera angles per room unfeasible. To make it easier for friends to understand, a game doesn't exist outside of RAM, so all this bitmap is accumulated to create the angles so that there is no way to make proper use of it because of this bottleneck in the RAM system.
F Fafalada have you heard about this?

 

[Fat Frog]

That was a low budget port by Nextech which is a trend on the Saturn.

Next tech also made a low budget port of Bayonetta for the PS3... and i think the result is even worse

 

[nkarafo]

Saturn version is a rushed PS1 port, everybody knows this.

And saying it's a Jaguar port like in every other console, singles out the Saturn negatively in what way?

Forgive me for not knowing this, i didn't want to hurt your feelings or your favorite console's.

If not for John the Saturn version would have looked better

I already posted this but somehow he took my post as an attack against the Saturn.

Other than FMV there's nothing that would trouble the Saturn 3D wise.

Transparencies: The Game

why didn't the Saturn do a great job in software alone, given how well Doom ran on PCs like my friend's crappy off the peg Compaq 80386SX 20Mhz with 2MB

My man, please, no.

There is no way in the world DOOM was running "well" on such PC. Not even in the smallest sized window. Even the 3DO version would be faster than that.

DOOM needed a 486/33mhz minimum to reach a playable performance.

 

[PaintTinJr]

My man, please, no.

There is no way in the world DOOM was running "well" on such PC. Not even in the smallest sized window. Even the 3DO version would be faster than that.

DOOM needed a 486/33mhz minimum to reach a playable performance.

You're right, I'm miss remembering us running Wolfenstein on that one, and Doom on its 486DX replacement.

 

[cireza]

And saying it's a Jaguar port like in every other console, singles out the Saturn negatively in what way?

Forgive me for not knowing this, i didn't want to hurt your feelings or your favorite console's.

Correcting you when you are wrong = hurting my feelings ?

 

[cireza]

You're right, I miss remembering use running Wolfenstein on that one, and Doom on its 486DX replacement.

Damn you Copilot !

Just joking.

 

[nkarafo]

Correcting you when you are wrong = hurting my feelings ?

You said i posted this info "in bad faith". Explain.

 

[cireza]

You said i posted this info "in bad faith". Explain.

Already did. Common knowledge. Don't intervene in a topic if you don't have basic knowledge about it ?

 

[nkarafo]

Already did. Common knowledge. Don't intervene in a topic if you don't have basic knowledge about it ?

Are you kidding me?

You just want to argue with me for arguing sake?

You're right, I miss remembering use running Wolfenstein on that one, and Doom on its 486DX replacement.

That being said, i'm not sure how the PS1/SAT CPUs fare against the 486.

 

[s_mirage]

at least the port was possible, if we had a programmer like XL2 here he would explain it better, ignorant people like me simply don't accept this information, I myself found it difficult to accept that this limitation in L-Ram and H-Ram memory was so serious to the point of making pre-render games with up to 16 camera angles per room unfeasible. To make it easier for friends to understand, a game doesn't exist outside of RAM, so all this bitmap is accumulated to create the angles so that there is no way to make proper use of it because of this bottleneck in the RAM system.
F Fafalada have you heard about this?

You're specifically talking about Resident Evil 2, aren't you?

Eh, Resi 1 on Saturn had the same camera angles and backgrounds as the PlayStation bersion

RE1 had less maximum angles per area than RE2; its rooms took up less RAM. Even there, the backgrounds took a slight quality hit in translation to the Saturn by reducing their colour palette to 8-bit vs 15-bit (I believe) on the Playstation. The PS1 benefitted from using the MDEC unit to decompress the single frame backgrounds from the compressed files in RAM directly into VRAM, but the Saturn had no equivalent.

My rough understanding of what is being referred to in regards to the RAM situation is that the Saturn's main RAM is split into two non-contiguous 1MB banks, one fast SDRAM, and one slower DRAM. The bigger rooms in RE2 are 1MB compressed so would take up an entire bank even if they used the same compression technique as on the PS1. If the Saturn had to use a less efficient compression scheme to save on CPU cycles, that's potentially a problem as the biggest rooms would need to be split between the two RAM banks. Then there's the other problem: where do you put the decompressed backgrounds? If the Saturn can't decompress them directly to VRAM, and if most of the RAM is already being used by the compressed files and the program code, that's a problem.

Maybe the rooms could have been split into smaller chunks. That would have meant more loading from CD though.

 

[PaintTinJr]

....


That being said, i'm not sure how the PS1/SAT CPUs fare against the 486.

nimum System Requirements for Doom:
Processor: 486 processor

Memory: 4 MB RAM

Operating System: MS-DOS 5.0 or higher

Graphics: VGA-compatible video card

Storage: Approximately 12 MB of free hard disk space

Sound: Sound Blaster or compatible sound card

Recommended System for Doom:
Processor: 486DX2/66 or better

Memory: 8 MB RAM

Operating System: MS-DOS 6.22 or higher

Graphics: VGA-compatible video card

Storage: Approximately 12 MB of free hard disk space

Sound: Sound Blaster 16 or compatible sound card

Well the MIPS3000 was stronger than the minimum spec 33Mhz 486SX(without a 487 FPU) by having better memory system- that didn't get split 512KB-ish useable of 640KB and then indirect fast access up to 1MB and then slightly slower extended memory access, but way off the recommended specs off a 66Mhz 486DX with its inbuilt FPU.

For anything that could be worked in parallel the Saturn's 2x 28Mhz SH2s + 30-50% of the 14Mhz SCU DSP should have made it more powerful assuming the split memory and DMA coping to the VDP2 framebuffer didn't cause scheduling issues to use the parallel processing.

 

[nkarafo]

Well the MIPS3000 was stronger than the minimum spec 33Mhz 486SX(without a 487 FPU) by having better memory system- that didn't get split 512KB-ish useable of 640KB and then indirect fast access up to 1MB and then slightly slower extended memory access, but way off the recommended specs off a 66Mhz 486DX with its inbuilt FPU.

For anything that could be worked in parallel the Saturn's 2x 28Mhz SH2s + 30-50% of the 14Mhz SCU DSP should have made it more powerful assuming the split memory and DMA coping to the VDP2 framebuffer didn't cause scheduling issues to use the parallel processing.

I'm sure the wizards who made DOOM 32X Resurrection would be able to make a perfect PC port on the Saturn. One that doesn't even rely on the simplified Jaguar DOOM maps.

 

[cireza]

RE1 had less maximum angles per area than RE2; its rooms took up less RAM. Even there, the backgrounds took a slight quality hit in translation to the Saturn by reducing their colour palette to 8-bit vs 15-bit (I believe) on the Playstation. The PS1 benefitted from using the MDEC unit to decompress the single frame backgrounds from the compressed files in RAM directly into VRAM, but the Saturn had no equivalent.

My rough understanding of what is being referred to in regards to the RAM situation is that the Saturn's main RAM is split into two non-contiguous 1MB banks, one fast SDRAM, and one slower DRAM. The bigger rooms in RE2 are 1MB compressed so would take up an entire bank even if they used the same compression technique as on the PS1. If the Saturn had to use a less efficient compression scheme to save on CPU cycles, that's potentially a problem as the biggest rooms would need to be split between the two RAM banks. Then there's the other problem: where do you put the decompressed backgrounds? If the Saturn can't decompress them directly to VRAM, and if most of the RAM is already being used by the compressed files and the program code, that's a problem.

Maybe the rooms could have been split into smaller chunks. That would have meant more loading from CD though.

What's the issue here already ? You have the compressed backgrounds in RAM on PS1 and you decompress them into VRAM. You can do exactly the same thing on Saturn. You simply read the compressed data, decompress it on the fly and write the result in VRAM. You can do this on Master System, so why not on Saturn ?

 

[s_mirage]

What's the issue here already ? You have the compressed backgrounds in RAM on PS1 and you decompress them into VRAM. You can do exactly the same thing on Saturn. You simply read the compressed data, decompress it on the fly and write the result in VRAM. You can do this on Master System, so why not on Saturn ?

Okay, so this is where my knowledge is a bit gappy, but for tasks like image decompression I believe that you'd typically decompress to H-RAM and then DMA to VRAM during VBlank, rather than having a CPU directly write to VRAM. Bear in mind that during active display the VDPs, CPUs, and the buses are going to be doing significantly more than just decompressing/moving backgrounds.

Plus, there's another reason to decompress to RAM first: if I'm understanding it correctly, VDP2 renders somewhat like older consoles - racing the beam. It has no framebuffer to keep an image on screen. VDP1 does, of course, but I doubt VDP1 would be able to render the models and the backgrounds.

VDP2 displays scrolling screen data while reading it from VRAM in synchronization with TV scanning.

If you decompressed directly to VDP2s VRAM, and assuming a background couldn't be fully decompressed during a VBlank period (a very safe assumption), I believe you would have to shut off the display (effectively, if not literally) every time you replaced the active background to avoid literally seeing incomplete frames as the background is decompressed. Fancy a multi-frame black screen every time the camera angle changes? Decompressing to RAM first avoids that since the completed background can be copied during VBlank.

There might be other issues too, or I might be completely wrong (though I don't think I am), so if there are any experienced Saturn devs here, some input would be appreciated.

 

[PaintTinJr]

What's the issue here already ? You have the compressed backgrounds in RAM on PS1 and you decompress them into VRAM. You can do exactly the same thing on Saturn. You simply read the compressed data, decompress it on the fly and write the result in VRAM. You can do this on Master System, so why not on Saturn ?

Sounds like the problem comes from using an algorithm that needs to immediately start overwriting the data source with output data from a small working buffer area before completing the decompression task to conserve the amount of available memory at all times, and having the source and output data while unpacking cross a 1MB boundary on non-contiguous memory breaks the efficiency, requiring the source data to be scaled down so that the output data doesn't exceed 1MB.

The other issue about colour precision being made is actually a bit of a quirk of the Saturn hardware, where despite it having the option to use any of the 24bit 16.5M true colour range, the system can only use a palette of 10bits (1024) colours at any one time, according to the SGL manual colour modes, and I believe this quirk applies to texture/sprites too.

 

[s_mirage]

The other issue about colour precision being made is actually a bit of a quirk of the Saturn hardware, where despite it having the option to use any of the 24bit 16.5M true colour range, the system can only use a palette of 6bits (1024) colours at any one time, according to the SGL manual colour modes, and I believe this quirk applies to texture/sprites too.

I believe this is only relevant to palletised sprites/backgrounds. Any using RGB values instead have no such limit, but take up more RAM.

 

[cireza]

Okay, so this is where my knowledge is a bit gappy, but for tasks like image decompression I believe that you'd typically decompress to H-RAM and then DMA to VRAM during VBlank, rather than having a CPU directly write to VRAM. Bear in mind that during active display the VDPs, CPUs, and the buses are going to be doing significantly more than just decompressing/moving backgrounds.

Plus, there's another reason to decompress to RAM first: if I'm understanding it correctly, VDP2 renders somewhat like older consoles - racing the beam. It has no framebuffer to keep an image on screen. VDP1 does, of course, but I doubt VDP1 would be able to render the models and the backgrounds.



If you decompressed directly to VDP2s VRAM, and assuming a background couldn't be fully decompressed during a VBlank period (a very safe assumption), I believe you would have to shut off the display (effectively, if not literally) every time you replaced the active background to avoid literally seeing incomplete frames as the background is decompressed. Fancy a multi-frame black screen every time the camera angle changes? Decompressing to RAM first avoids that since the completed background can be copied during VBlank.

There might be other issues too, or I might be completely wrong (though I don't think I am), so if there are any experienced Saturn devs here, some input would be appreciated.

If you can't do it during a single vblank, you simply use a dark transition that lasts a few frames.

But anyway, there is a possibility (understand that thisnis most likely) that you have enough VRAM to display one full screen picture and decompress the next screen to another location in VRAM, in which case you then simply have to update the tilemap which is going to be super fast on a 32 bits console.

 

[cartman414]

The video game industry can be full of what ifs. Had NCL not pissed off SONY or turned its back on CD Roms. Nintendo could have the PlayStation and FF7 .

Pure propaganda. Sony attempted to pull a Daniel Plainview on Nintendo.

The Weird History Of The Super NES CD-ROM, Nintendo's Most Notorious Vaporware

Nintendo never released a CD-ROM gaming system. But for a while in the early 1990s, it flirted with the idea. That protracted will-they-won’t-they romance produced pages of breathless gossip columns in video game magazines, a mountain of vaporware, some terrible Zelda games, and one priceless...

kotaku.com

 

[Team Andromeda]

Pure propaganda. Sony attempted to pull a Daniel Plainview on Nintendo.

The Weird History Of The Super NES CD-ROM, Nintendo's Most Notorious Vaporware

Nintendo never released a CD-ROM gaming system. But for a while in the early 1990s, it flirted with the idea. That protracted will-they-won’t-they romance produced pages of breathless gossip columns in video game magazines, a mountain of vaporware, some terrible Zelda games, and one priceless...

kotaku.com

It's hardly propaganda when NCL 'could' have worked with SONY
Also, there was nothing stopping NCL from going with another corp for a CD drive for the N64 which would have ensured that N64 would have had FF7 and no doubt a hole host of more 3rd party support and for sure far more Arcade ports

Transparencies: The Game

FF7 isn't a great looking game and Saturn did better looking RPGs. For sure the latter FF games would be an issue but not FF7. Also, the Saturn was perfectly able to do transparent effects but they had to be done using the VDP2 planes or 2D sprite based effects like one saw in Grandia which is not only a much better RPG than FF7 but also a much better-looking game too even the heavily cutback PS1 version

That's to overlook how FF7 been built for Saturn the game would have been designed around its chipset and features.
You know like if Square had made a Mega Drive RPG it would have let go of Mode 7 and colour laying effects you build a game around the system's strengths and weakness

 

[PaintTinJr]

I believe this is only relevant to palletised sprites/backgrounds. Any using RGB values instead have no such limit, but take up more RAM.

Not as far as I can tell. This is from section 7-17 (and before) about polygon rendering in colour with Gourand shading which should offer the highest colour mode because it would be the only element that could possibly avoid being a composite scroll layer - that requires to span across the 4 128KB banks of VRAM causing the palette limitation AFAIK - and the modes list says otherwise, unless I am missing something,

The more I look at SGL documentation the more I believe the Saturn was originally designed without texture mapping, and it has been cobbled in as a last minute desperation feature, and fakes texture mapping by forcing the GL client/server rendering down to one primitive per render call, effectively a requirement to let a 2D sprite engine post-texture map it.

 

[s_mirage]

Frankly, I'm a bit confused by what you've posted. What does that chart have to do with what you're claiming? It literally lists a 15-bit colour mode. Gouraud shaded textures literally use the 15-bit RGB mode:

When using half-bright mode, semi-transparent mode, or gouraud shading, polygons support only RGB direct mode and textures support only 32,768-color RGB mode. Objects will not be displayed properly with any other settings.

Also:

The fourth parameter “Color” specifies the polygon color and the offset address for the texture color palette. In the case of a polygon, the color data specification method is limited to RGB direct, and the format is “C_RGB(r,g,b)”. “r,g,b” refer to the three primary colors of light (red, green, and blue), and can be specified with decimal numbers in the range from 0 to +31. In the case of texture, the color data specification method depends on the “Mode” specification (the sixth attribute parameter; refer to "Mode"). Specify either the macro “No_Palet” in the case of 32,768-color RGB mode, or else the offset address for the color palette in the case of another index mode.

The only place where 1024 (or 2048) colours comes up as far as I can see is with regards to the colour RAM used for palletised graphics, and it says this:

Color RAM is used to control color for all palette-type sprites and scroll screens

 

[PaintTinJr]

Frankly, I'm a bit confused by what you've posted. What does that chart have to do with what you're claiming? It literally lists a 15-bit colour mode. Gouraud shaded textures literally use the 15-bit RGB mode:



Also:



The only place where 1024 (or 2048) colours comes up as far as I can see is with regards to the colour RAM used for palletised graphics, and it says this:

My point was that even without the compositing in the VRAM that downgrades the composited final image AFAIK, and is pretty much a given situation as texturing will be used, the colour range in the most optimal situation is still only 32K colours optimal, 2048 of 16bit in VRAM composition versus full 16bit texture mapping on PS1, and still had support for 24bit colour beyond texture mapping.

 

[Drell]

It's hardly propaganda when NCL 'could' have worked with SONY
Also, there was nothing stopping NCL from going with another corp for a CD drive for the N64 which would have ensured that N64 would have had FF7 and no doubt a hole host of more 3rd party support and for sure far more Arcade ports

N64 not having a CD drive was probably the main reason for square to not make FF7 on it but there were others too:

Square did some test with the N64 hardware and couldn't get good performances while displaying a high polycount behemot model. Also, despite releasing Mario RPG, their last game for Nintendo, as lat as 1996, their relation with them wasn't so good. Yamauchi litteraly taunted Square with their FF7 when they criticised Nintendo's hardware choices. On their side, while being the newcommers, Sony were extremly good at seducing devs, despite them being "loyal" to Nintendo during all these years and developping for PS1 was easy.

I think that even if Nintendo did release a CD based N64, things wouldn't have changed that much. The console would have got more games and of better quality but square would still leave Nintendo for Sony.

 

[cireza]

Sony were extremly good at seducing devs

 

[Team Andromeda]

N64 not having a CD drive was probably the main reason for square to not make FF7 on it but there were others too:

Square did some test with the N64 hardware and couldn't get good performances while displaying a high polycount behemot model. Also, despite releasing Mario RPG, their last game for Nintendo, as lat as 1996, their relation with them wasn't so good. Yamauchi litteraly taunted Square with their FF7 when they criticised Nintendo's hardware choices. On their side, while being the newcommers, Sony were extremly good at seducing devs, despite them being "loyal" to Nintendo during all these years and developping for PS1 was easy.

I think that even if Nintendo did release a CD based N64, things wouldn't have changed that much. The console would have got more games and of better quality but square would still leave Nintendo for Sony.

Let's face it was the main reason. Had the N64 had a CD drive Square wouldn't have needed to make it all realtime to try and save on space .whoever had FF7 would have won Japan back then and losing Enix and Square over space size cost NCL dear where NCL went from having 92% of the Japanese market to 3rd place even behind SEGA and Saturn

It's a shame too an N64 with a CD Drive would have been a fab system and it would have got a lot more Arcade ports and RPGs for sure.

 

[PaintTinJr]

Let's face it was the main reason. Had the N64 had a CD drive Square wouldn't have needed to make it all realtime to try and save on space .whoever had FF7 would have won Japan back then and losing Enix and Square over space size cost NCL dear where NCL went from having 92% of the Japanese market to 3rd place even behind SEGA and Saturn

It's a shame too an N64 with a CD Drive would have been a fab system and it would have got a lot more Arcade ports and RPGs for sure.

Even with a CD-Drive the N64 still has a texturing issue which was ultimately an important hardware feature for making great looking games that everyone but Sony heavily compromised on.

 

[Emedan]

I don't want to drive by this thread or anything but Jesus how did this get to be 13 pages long.. It's been 30 years let it go.

 

[Geometric-Crusher]

I don't want to drive by this thread or anything but Jesus how did this get to be 13 pages long.. It's been 30 years let it go.

you wouldn't get it