[ 3 / biz / cgl / ck / diy / fa / ic / jp / lit / sci / vr / vt ] [ index / top / reports ] [ become a patron ] [ status ]
2023-11: Warosu is now out of extended maintenance.

/vr/ - Retro Games


View post   

File: 11 KB, 300x225, 1142464-sega_saturn.jpg [View same] [iqdb] [saucenao] [google]
10037843 No.10037843 [Reply] [Original]

Where does the myth that the Saturn was better at 2D than the PSX come from? The 2D fighters were better on Saturn because of the 4MB RAM cart, not any kind of underlying architectural superiority.

>> No.10037848

>>10037843
you just stated the reason why saturn was better at 2d

>> No.10037850

>>10037843
It's idiot weebs who don't know what they're talking about OP, pay them no mind. You're right it's only the RAM cart that really affects them for the most part. Even SEGA Lord X admits it's really down to your choice of controller in the end

>> No.10037856

>>10037843
Not a myth
It does actual 2D
And yes the 4mb RAM makes it even better for them

>> No.10037858

Like a dealer lot mustang versus a rally car, the saturn may have had more horsepower, but the PSX was a racing-spec machine.

>> No.10037860
File: 2.08 MB, 1410x1297, sbs.png [View same] [iqdb] [saucenao] [google]
10037860

>>10037843
too bad transparencies fucking sucked on it. Even the SNES could do them

>> No.10037864

Christ I hate gamers. Lowest IQ hobby by a wide margin.

>> No.10037868

>>10037864
you forgot a comma, mr. braingenius

>> No.10037869

Even without the RAM cart, it had more 50% more VRAM than the Playstation. VDP2 could also be used for raster effects. It's not outright better but it does have some advantages.

>> No.10037886

>>10037869
>It's not outright better but it does have some advantages.
Same could be said of the PSX. The Saturn is terrible at transparency.

>> No.10037890

>>10037843
OP these are the same people who insist the Saturn was made for 2D even though it was literally designed to play games like Virtua Fighter and Daytona, with VF2 being the highest selling game even in Japan.

>> No.10037892

>>10037886
Yes, that's the point. Playstation was also much faster at drawing sprites.

>> No.10037912

AFAIK the Saturn has a lot of hardware effects for 2D sprites (since the 3D rendering utilises sprites to draw polygons to the screen, hence why the polygons are quads rather than triangles) whereas the graphics hardware in the PSX is entirely based around doing vector maths quickly, so doing all the interesting stuff with sprites was written in software and run on the CPU rather than the graphics hardware.

>> No.10037917

>>10037890
no, these are not the same people.
you can think "saturn was made for 2d" is a persistent myth, while still thinking it does 2d better than ps1.

>> No.10037920
File: 1.62 MB, 320x240, MMX4 Sat.webm [View same] [iqdb] [saucenao] [google]
10037920

>>10037860
>X4
The afterimages just ruin the presentation on Saturn. Look how they are remain suspended in one place, fully opaque, before disappearing.

>> No.10037928

>>10037920
what is it supposed to look like?

>> No.10037929
File: 743 KB, 1005x547, unknown[1].png [View same] [iqdb] [saucenao] [google]
10037929

>>10037912
That's not true, the Playstation GPU was twice as fast at drawing sprites compared to textured polygons. Any 2D Playstation game takes advantage of this a lot.
It's fast enough that multiple background layers in a 2D Playstation game can be made out of these "sprites" without running into performance problems.

>> No.10037939

n64 was the most powerful 2d machine

>> No.10037945
File: 79 KB, 500x500, artworks-000182112994-cyoeg9-t500x500[1].jpg [View same] [iqdb] [saucenao] [google]
10037945

>>10037928
The afterimages are translucent on Playstation.

>> No.10037959

>>10037939
good one

>> No.10037968

>>10037920
That's horrible

>> No.10037975
File: 1.95 MB, 320x240, MMX4 PSX.webm [View same] [iqdb] [saucenao] [google]
10037975

>>10037928

>> No.10038025

>>10037975
Christ what a piece of shit the Saturn was. I’ll never understand why it has so many apologists.

>> No.10038039
File: 203 KB, 969x624, file.png [View same] [iqdb] [saucenao] [google]
10038039

>>10037920
>>10037860
>>10037975
same replies every time, AI needs more restrictions.

>> No.10038045

>>10038039
Facts don't need to be changed every day, mutant.

>> No.10038051

Now post how bad metal slug runs on saturn.

>> No.10038238

>>10037843
It's not a myth and you just stated the reason.

>> No.10038373

I think the more interesting question is, why didn't the Playstation anticipate the need for a RAM cart?
It would have made 2D arcade ports far better, possibly even in parity with Saturn. Both of the other consoles of that gen had RAM carts, but the Playstation had no expansion capability (the parallel port was too slow to be suitable). It was easy to anticipate that RAM prices would fall by a lot.

>> No.10038397

>>10038039
playstation drones are something else
>>10037843
>The 2D fighters were better on Saturn because of the 4MB RAM cart
Street Fighter Alpha 2 proves otherwise, fanboy.

>> No.10038523

>>10037843
>Where does the myth that the Saturn was better at 2D than the PSX come from?
> The 2D fighters were better on Saturn because of the 4MB RAM cart

You just described why it was better, you stupid faggot.

>> No.10038550

>>10037843
I don’t think the PSX was actually capable of straight 2D, wasn’t every spite a 3D object with a texture? In practice it makes no difference, but I would assume that would make the 2D limited to the capabilities of the 3D. Also looking at games like Dragon Force where they have 200 sprites running around on screen is impressive for the time. Did PSX have a game with a similar number of sprites on screen?

>> No.10038554

>>10038550
There are a couple bullet hell shoot 'em ups like Dodonpachi which move crazy amounts of sprites on screen. The Playstation did support 2D sprites and was faster at drawing them the Saturn, so these games tended to have less slowdown on the Playstation.

>> No.10038560

>>10037912
The Saturn's power comes from it background layers. There is nothing special about its sprite capabilities.

>> No.10038568

>>10038550
>3D object with a texture
I think you're describing N64

>> No.10038573

>>10038568
Saturn, Playstation and N64 all supported sprites.
Actually even the PS2 did plain old sprites.

>> No.10038580

>>10038554
Yep. Those sort of games are just a static background with a ton of sprites on screen. There's nothing about the Saturn's advanced hardware that helps.

>> No.10038585

>>10038573
yeah N64 supported it, but the cartridge needed microcode patches on board.
in a lot of 2d cases it was putting textures on flat polygons.

>> No.10038596

>>10038554
>these games tended to have less slowdown on the Playstation
that and the transparancy issues sound pretty damning for the saturn

>> No.10038609

>>10038585
RSP microcode can't add extra draw commands to the RDP, the hardware support was always there. If you're doing fully 2D stuff you don't even need to interact with RSP for graphics.

>> No.10038618

>>10038609
Scratch that I double checked and it's still RSP which processes the display list. An optimized microcode can help, but one was already provided.

>> No.10038646

>>10037890
This is the myth that truly baffles me. It makes zero sense for Sega who pushed for 3D at the arcade and mostly relied on console ports at home to make a console during the 3D boom to not be a primarily 3D based console to port their big 3D arcade releases.

>> No.10038661

>>10038646
It's a myth that mutated out of multiple overlapping truths.
Distorted quads were 3D but were an overall poor way of doing it. Additionally, Saturn's 3D capability was also improved in response to the Playstation by adding a second SH2 (importantly, not changing the VDPs)
Filter this through a zoomer attention span and what you get is "Saturn was primarily 2D until they saw the Playstation and then they made 3D better, so 3D is an afterthought".

>> No.10038694
File: 645 KB, 1200x1150, More Chips Than Lay's.png [View same] [iqdb] [saucenao] [google]
10038694

There is no myth. First of all, CD-based 2D games are memory-hungry because of the memory needed to hold all the sprite and tile data. The Saturn had more RAM than the PS1 even before expansion, and significantly more after (plus some games came with a ROM cartridge instead of RAM that had their sprite data on the actual cart). Even without an expansion cart the Saturn had more memory which greatly benefitted it for 2D.

Second, it's 3D aspects were essentially just an extension of it's 2D capabilities. The "polygons" on the Saturn used quads instead of tris because they were essentially sprites that could be squished and stretched on four points to basically act like a square polygon. A textured model was essentially a bunch of sprites all squished and stretched and connected together to form the 3D model rather than how everyone else did it where it was three points with a shade or texture drawn within the space of those points.

The entire thing was a 2D powerhouse at the time from it's amount of even base memory to how it was practically more of a supercharged 2D console that could modify sprites enough to make them look like 3D polygons than a normal fully 3D system.

It's really no surprise that the Saturn outclassed the PS1 in 2D... shame that all of these severally handicapped it's 3D capabilities and everyone was moving over to 3D games so... (It's absolute insanity spaghetti of an architecture didn't help things either for developers)

And yes, it could do transparencies.... for standard square-shaped fully 2D sprites. It couldn't do transparencies on polygons or vector graphics however. Look at Sonic R, the shield powerup is transparent, because it's just a sprite.

>> No.10038731

>>10038694
>Second, it's 3D aspects were essentially just an extension of it's 2D capabilities. The "polygons" on the Saturn used quads instead of tris because they were essentially sprites that could be squished and stretched on four points to basically act like a square polygon
None of that makes it draw sprites faster than Playstation. Playstation was better at simply putting sprites on the screen, and it didn't gimp it's polygon capabilities in the process.
More VRAM and also dedicated background layers was where Saturn 2D excelled. Let's not start another myth that distorted sprites made Saturn 2D better, when the actual reasons are right there.
>And yes, it could do transparencies.... for standard square-shaped fully 2D sprites.
It was 6x slower doing transparencies this way, limiting its usefulness. For the most part you just use the mesh effect or VDP2 compositing instead.

>> No.10038746

>>10038731
>None of that makes it draw sprites faster than Playstation.

And what good does "drawing sprites faster" do you if you don't have the memory to load a lot of sprites at once or have less hardware tricks you can do with them?

That's like getting a gigabit internet connection that has a 100GB monthly cap.

>It was 6x slower doing transparencies this way, limiting its usefulness.

Considering it could only apply it to sprites, it was more than enough, and used cleverly it could do a lot (Sonic R is yet another example again with the face-ins). The myth that people keep spreading, which you didn't refute I might add, is that it couldn't do them at all.

>> No.10038757

>>10038746
My only point is that you are wrong about point 2 and inaccurate about the last point. Rave about the Saturn if you like, but be correct when you do.

>> No.10038770

>>10038746
>And what good does "drawing sprites faster" do you if you don't have the memory to load a lot of sprites at once or have less hardware tricks you can do with them?
Did saturn games even use the hardware to its full capability? Just like the N64 it had higher specs than the PSX but it was bottlenecked by a fucking god awful development kit that few people bothered with. Fewer cared about VDP2 still, because of it.

>> No.10038776

>>10038757
Not only did you not address point 2, but developers have flat out mentioned that's how it's 3D works.

And I am not at all inaccurate about the last point, it can do transparencies, which you refused to admit until I posted an example of a game that does (And I didn't even lie about it, I said it only worked on sprites), in which case you went "Well, well, well, it was slower doing it though!" when I never once talked about the draw speed.

Try to make your fanboysm a little less obvious next time eh? I am just interested in the truth, not fighting a 30 year old console war by lying through omission and then when called out on it try to move the goalposts then act like the other person was lying because the new goalpost was never mentioned.

>> No.10038881

>>10038646
>It makes zero sense for Sega who pushed for 3D at the arcade and mostly relied on console ports at home to make a console during the 3D boom to not be a primarily 3D based console to port their big 3D arcade releases.

Development of the Saturn started in 1991, at which point they had no 3D arcade stuff. The developers also asked every in-house division and all of them except one wanted better 2D. So they made it 2D.

This is perhaps the thing that makes the most sense about the Saturn. There are plenty of other idiocies in there.

>> No.10039060
File: 616 KB, 956x717, jikksaturn.png [View same] [iqdb] [saucenao] [google]
10039060

Does the Playstation actually have sprite capabilities, or are they just '2D' polygons sorted by the 2D engine? Because I know, devs could use the polygons as flat surfaces and display sprites as textures. This can be done with the 2D sprite capabilities. The Saturn appears to be basically a raster machine that displays in sprite/ tiles. Even the 3D polygon games are 2D sprites being spun around in 3D bill boarding style. Like this chunky Jill Valentine model is basically a bunch of 4-sided sprites called quads. The Saturn is basically just a 2D sprite machine that can render sprites as polygons. The Playstation either is a completely triangle based machine, or also has some sort of 2D rendering hardware as well. I always kinda felt that the Saturn worked best with 2D scaling sprites and 3D environments.

https://youtu.be/Jqt-jgPBprw?t=442
Decathlete is a weird game. It uses the Saturns 'high-res' interlaced mode, runs at 60fps. Uses a Saturn background layer and has some polygon characters.
https://youtu.be/pEm8Uy1tqRI?t=1055
https://youtu.be/Y1oS6s0nzmg?t=2449

>> No.10039267

>>10038039
>someone brings up the visuals of X4 on Saturn
>relevant webm is posted in response
>this is a problem (for fanboys)

>> No.10039279

>>10037843
It's completely true because that's how you ended up with that end-product. Their two prototype designs were heavily based on 2D architecture.

>> No.10039286

Guess who didn't even get MVC after you bought the Action Replay.

>> No.10039301

>>10039267
after images are a cringe thing to obsess over

>> No.10039328

>>10039060
>Does the Playstation actually have sprite capabilities, or are they just '2D' polygons
The PS1 can draw polygons, lines, and rectangles. The rectangle command basically draws a rectangle with a solid color or a texture. No 3D, rotation, or scaling.

>> No.10039370

>>10038373
>I think the more interesting question is, why didn't the Playstation anticipate the need for a RAM cart?
RAM carts weren't a thing before this generation and weren't a thing after. It's interesting both the Saturn and N64 had them.

>> No.10039415

>>10039370
Pc engine had them

>> No.10039450

>>10037920
SF Alpha does the same thing nobody complained.

>> No.10039536

>>10037864
Might be HAM radio aside from a handful of boomers. Or muscle cars because of the boomers. Competitive airsoft is up there too, it's meant for children and people that aren't smart enough to afford paintball. I can think of a few others but yeah, easily bottom tier.

>> No.10039546

PSX could have higher resolution sprites and effects could be fancier

>> No.10039924

https://www.youtube.com/watch?v=phgLOEHQgoc

>> No.10040520

>>10038770
> Fewer cared about VDP2 still
VD2 was use in most 2d games, but in 3d games it was basically useless unless the game was designed around it. Also, making significant use of VDP2 will significantly constrain level design since you need large flat floors and ceilings for vdp to be useful.

>> No.10040528

>>10039060
There is no fundamental difference between sprites and polygons to begin with. Its a bad mental model to make a hard distinction between them.

>> No.10040582

>>10040528
The terms are ambiguous anyway. If we use sprite in the original meaning, no 5th gen console has sprites. Without being precise it's meaningless to talk about.

>> No.10040997

>>10039924
holy molly, sega USA ads marketing lads were really mad about psx marketing guys.

>> No.10041514

>>10040528
>There is no fundamental difference between sprites and polygons

They are two different rendering techniques though. Video above is how the Saturn does polygons. It really is just a sprite being warped by four vertices. The Playstatiion and N64 allows for UV mapping via triangles. This is generally how most modern systems work. The Saturn does fundamentally function as a 2D machine.
https://www.youtube.com/watch?v=8TleepxIORU

https://www.youtube.com/watch?v=WDJgeuoaSvQ&t=118s

>> No.10041517

Hate on it all you want, more for me. Hahahah

>> No.10041678

>>10041514
I am aware of how the Sega Saturn gpu works. I just don't agree with the idea that a technical implementation detail alters the fundamental definition of what is being drawn.

>> No.10041691

>>10040582
I agree. It is quite a stretch to first go to "a sprite is any 2d image" and then straight to "Saturn renders 3d by distorting sprites".
Using a weird quad rendering method doesn't make it "not 3d" just because other consoles don't do that.

>> No.10041696

>>10037864
No, it's definitely hotdog eating competitors

>> No.10041708

>>10041691
2D vs 3D is a gradient, anyway.
There's several things that make things "more" 3D. 3D projection, UV mapping, z sorting, perspective correction all contribute to making something more 3D, but lacking one or more does not make it strictly 2D.

>> No.10043164

>>10039301
>why are you so obsessed bro

literal retard response

>> No.10043172

>>10037843
IIRC the PS1 had 2MB RAM and 1.5 MB VRAM. Not sure what the PSX had over Saturn.

PS1 vs Saturn Grandia had different effects, but ultimately it's a tradeoff.

>> No.10043207

>>10038560
Explain the Saturn's background layers, please.

>> No.10043213

>>10038746
Lack of memory can be overcome by streaming?

>> No.10043216

>>10043172
Playstation had
>2MB RAM
>1MB VRAM
>0.5MB Audio RAM
Saturn had
>1MB fast RAM
>1MB slow RAM
>0.5MB disc cache
>0.5MB VDP1 sprite/texture memory
>0.5MB VDP1 framebuffer
>0.5MB VDP2 memory
>Optionally more if you have a RAM cart.
So it was considerably more although you had to be careful how it was used.

>> No.10043219

>>10043216
Oh the Saturn also had
>0.5MB Audio RAM

>> No.10043221

>>10043216
Imagine the games we'd have if Sony went with 8MB RAM.

>> No.10043223

>>10043213
Sprite streaming is appropriate for a cartridge based console. That's effectively how the Saturn's RAM carts worked, but it was also used frequently on platforms from the NES to the GBA. Doesn't really work for discs though, the latency is too high.
Streaming level data isn't too bad because it has a time budget of seconds, not milliseconds.

>> No.10043225

>>10043223
Crash Bandicoot is all streaming, albeit 3D.

>> No.10043227

>>10043221
RAM is expensive. Neo Geo CD went with 7MB of RAM total with 4MB of VRAM, and its 2D games speak for itself.

>> No.10043232

>>10043225
That's streaming data which can tolerate a bit more lag (specifically occlusion info). Streaming graphics on the fly is not viable here.

>> No.10043250
File: 5 KB, 1024x768, Coleco Donkey Kong 2600.png [View same] [iqdb] [saucenao] [google]
10043250

>multiplats objectively show system capability and aren't subject to preferential treatment or developer laziness

>> No.10043276

>>10043207
Imagine if the SNES could use all of its graphics mode at the same time, now double the amount of backgrounds, and you are halfway there.

>> No.10043283

>>10043207
Playstation does not have backgrounds per se. To display a background elements it simply draws lots of sprites or polygons.

Saturn has two display processors. VDP1 draws sprites. The result from VDP1 is taken by VDP2 and merged with up to four background layers in any order.
VDP2 backgrounds can be scrolled, rotated, scaled or perspective transformed. They are effectively flat planes which can be viewed from any angle. Unlike Playstation, they don't wobble.
They can have holes cut out of them using the "window" effect. This was used in Sonic Jam's Sonic World for the small rivers between the flat ground.
Raster tricks can be used to add various effects like the heatwave in Megaman X4.
Transparency is free on VDP2. Combining a background with a sprite, a sprite with a background, or a background and a background costs nothing.
VDP2 has its own VRAM. The more stuff you draw on VDP2, the more space you have for sprites or textures on VDP1. Because of tilemapping it is very economical with RAM, too.

>> No.10043314 [DELETED] 

>>10043283
*Up to six background layers.

>> No.10043374

>>10043164
Why are you? After images are a boring thing to react to like this: >>10038039

>> No.10043381

>>10037843
It has a little more RAM and can have a few more frames and background tiles loaded. One example I can think of offhand is Silhouette Mirage, but that's a port. That said, I bet the PS1 can have more sprites on screen at once without slowdown, and a game made for it in mind can probably have just about as much data loaded. The difference really isn't so pronounced, as you say.

>> No.10043407

>>10043381
PS1 has to draw background layers using sprites, so whilst it may be able to draw more, most of them are burned on backgrounds.

>> No.10043421

>>10043407
Either way, it doesn't turn out to be a bottleneck. Games like SotN can stack 3 or 4 background layers and large sprites too without hitting performance issues.
Running out of VRAM is a realistic issue, on the other hand.

>> No.10043468

Since we’re in a Saturn thread, how easy or hard are they to repair. What I mean is, are a lot of the issues easily solvable or do Saturns that break down usually do so because of weak parts? Got a line on a broken one for 80 but I don’t know if I have the skill to fix it yet. I have recently torn apart and cleaned up a 64, kinda got it working lol.

>> No.10043471
File: 16 KB, 259x194, images.jpg [View same] [iqdb] [saucenao] [google]
10043471

>>10037843
>Where does the myth that the Saturn was better at 2D than the PSX come from?
It came from the Saturn being bad at 3d, so the natural assumption was that it must be good at 2d instead. BTW, it is perfectly good at super scaler style games

>> No.10043678

>>10037843
The Sega Saturn was not a well thought out system. It was bloated, sloppily designed (the whole VDP1 and VDP2 nonsense), and overly expensive. It was a system created out of a company's arrogance. Sega was riding high from their success with the Sega Genesis and thought whatever system they made would be happily eaten up by fans no matter what. They were wrong.

That's the story of Sega Saturn.

>> No.10043703
File: 40 KB, 640x466, top-10-best-selling-original-playstation-games-1[1].png [View same] [iqdb] [saucenao] [google]
10043703

>>10043678
They were coming at it from a dated mindset. VDP2 and to a lesser extent VDP1 make sense for a 2D game or a 3D game with a limited perspective. "3D game with limited perspective" fits many arcade ports like Virtua Fighter or arcade-like games like Panzer Dragoon, Sega's bread and butter.
Those games were increasingly less important. Of the top 10 best selling Playstation games, at most two of them benefit from that approach to graphics.

>> No.10043717

>>10043227
>RAM is expensive. Neo Geo CD went with 7MB of RAM total with 4MB of VRAM, and its 2D games speak for itself.

And even with that much memory, I do know that some Neo-Geo CD games are missing frames of animation and are not 100% perfect to the AES versions. I'm pretty sure some of the Metal Slug games are missing a few frames of animation, and maybe a few later entry fighters.

>> No.10043849

>>10043717
Makes me wonder what the N64 might have been capable of if it ever got any 2D games. Streaming from the cartridge might have been viable to get lots of frames of sprite animation.

>> No.10043872

>>10043849
There’s no need to wonder. Bangai-O was made with that explicit purpose in mind. The sprites even had significantly reduced detail and no transformations to put more in screen. It also chugs a lot as it gets to be too many. But it’s super impressive. But “streaming from the cartridge” doesn’t make a lot of sense in this regard. The hardware is way to limited to make that work. More ram and a bigger cache is simply the better solution.

>> No.10043879
File: 104 KB, 598x896, aof3.png [View same] [iqdb] [saucenao] [google]
10043879

>>10043717
>And even with that much memory, I do know that some Neo-Geo CD games are missing frames of animation and are not 100% perfect to the AES versions
Art of Fighting 3 had to downscale the sprites to fit them into the Neo Geo CD's RAM

>> No.10043884

>>10043879
>top on the juice
>bottom a clean fight
This is a comparison of recovery from crippling drug addiction anon

>> No.10043946

>>10043283
>The result from VDP1 is taken by VDP2 and merged with up to four background layers in any order.

If the VDP1 draw RGB sprites, then they can be only above or behind every VDP2 layer.
VDP2 has something like 7 layers in total, they range in functions from a single color to a 16 million color hi-res zoomable background. It also can do mode 7 background but it has a whole different set of limitations.

>They can have holes cut out of them using the "window" effect. This was used in Sonic Jam's Sonic World for the small rivers between the flat ground.
There were no window effects there, they just draw polygons on top of the VDP2 plane.
Window effect means punching a hole through a VDP2 layer to show another VDP2 layer.

>Transparency is free on VDP2.
If you want to do sprite to background transparency, you have to use paletted sprites, which heavily limits your colours, shading, and breaks sprite transparency.

Saturn is a hard to program because if you enable one effect, you must disable something else somewhere and this can break everything. Playstation can do every effect in every mode (as long as you don't use 24-bit color), you are just limited in how much memory you have.

>> No.10043986

>>10043946
Thanks for the corrections.
>VDP2 has something like 7 layers in total,
This one confuses me the most and the documentation doesn't summarise it clearly. There's 4 2D layers, 2 3D layers, a 1-color-per-line backdrop, and a meta-layer for color calculations. And another layer for "external input" (VCD?). But enabling both 3D layers disables the 2D layers too.

>> No.10044015
File: 78 KB, 951x630, saturn.png [View same] [iqdb] [saucenao] [google]
10044015

>>10043207
>>10043283
>>10043946

There's an article on Saturn transparency which has an example of how the Saturn's VDP1 and VDP2 layers work. You can toggle them on/off and reorder them to see how they interact and limit each other.

https://mattgreer.dev/articles/sega-saturn-and-transparency/

>> No.10044028

>>10043872
Bangai-O demonstrates filling the frame with as many sprites as possible, but not animating them as much as possible with a wide variety of tiles. The latter is what you would want to use streaming for.
I have a hunch that Mario Kart 64 uses sprite streaming, because the karts have quite a large number of frames of animation and other MK games have been known to do it - but I haven't checked.

>> No.10044046

>>10044028
maybe it does? but it’s not faster and doesn’t look very good. It’s just not suited to it unfortunately. But there’s still impressive “2D” things on the N64!

>> No.10044613

>>10043213
You can't just replace loading with streaming, the game has to be built around it. If you could then no game would have had loading times.

And don't forget that the consoles had quite slow CD drives, as well as the entire hardware for all of that itself was slow compared to a cartridge port. Even NES had limits, IIRC the reason there are those hallways before bosses in the Megaman games is because originally they could not load the boss sprites fast enough when there was just a single door. This was eventually fixed (I forgot if it was fixed in development of Megaman 1, or if it was fixed by 2, I know for sure 2 didn't need them anymore) but kept because it as a good way to let the player know the boss was coming out and just the general aesthetic.

So not even the NES could stream the handful of boss sprites fast enough from a cartridge. An early CD-based console sure as hell would not be able to stream sprites fast enough for a 2D game. A fighter would be utterly out of the question, maybe you can do a linear platformer but you would need chunks where nothing happens to unload some of the sprites for others.

Most of the games that streamed data were 3D for this reason, and it causes limitations. Crash 1 for example streamed the level data, and that was why they were linear and you could not go backwards. Soul Reaver did as well and gated loading zones between swapping worlds, Metroid Prime would simply make doors not open when shot if they had not loaded in time and had hallways deliberately designed to slow you down.... this is also why elevators crash the game if you get to them too fast.

Basically, you can't just stream shitloads of sprites off a 5th gen console's CD drive to match a console that had a cart or more RAM, the drive and hardware is just not fast enough, and you have to VERY specifically design your game around it which means having many limitations in order to allow the streaming to work.

>> No.10045304

wonder what drove the codec usage decision between PS and Saturn, mjpeg v cinepak.

definitely, cinepak was inferior performance...

>> No.10045380

Which console had real 2D of this gen?

>> No.10045397

>>10045380
All of them.

>> No.10045407

>>10045397
According to /vr/ that is not true

>> No.10045443

>>10045407
2D is just 3D with one less D. Any 3D system can do 2D, it's just a matter of how much effort to the developers want to put into it.

>> No.10045529

>>10045380
The Saturn is the only one that didn’t need to use polygons if that’s what you mean

>> No.10045530

>>10045529
Nope, Playstation and N64 didn't have to use polygons either.

>> No.10045535

>>10045530
Nah mate, the PlayStation and N64 sprites needed to be within a 3D engine
They are not the same type of 2D as older consoles and the Saturn
I assume that’s what that anon was asking about

>> No.10045547
File: 216 KB, 1262x940, playstation sprite.png [View same] [iqdb] [saucenao] [google]
10045547

>>10045535
There was no such requirement. All three consoles were capable of drawing sprites in the same way. Don't speak so proudly about things you don't actually know.

>> No.10045558

>>10045547
Ah yes, the flat poly, the way sprites have always been made

>> No.10045561
File: 164 KB, 489x462, latest[1].png [View same] [iqdb] [saucenao] [google]
10045561

>>10045558
That's referring to another, separate feature of the Playstation which also had higher bandwidth. The "flat" is referring to the lack of texturing. FF7 and Spyro used this frequently for higher poly models.

Please just think a little, and read what is written. If a "flat poly" is something that has no texture, then it's not very useful for drawing 2D elements, and not the other half of what that slide is talking about.

>> No.10045595

>>10045561
I don’t care what it’s referring to
All sprites are placed on a one sided flat poly

>> No.10045607

>>10043986
>This one confuses me the most and the documentation doesn't summarise it clearly.

Back screen, line screen, rotating background 0, normal background 0, 1, 2, 3, and rotating background 1, window, external input, VDP1 (technically counts as a layer).

external input takes over normal background 0 when active.
normal background 0 and 1 can do scaling (to a certain amount), bitmaps, line scroll, column scroll.
normal background 0 can do up to 24bit color. normal background 1 can do up to 15bit color.
normal background 2 and 3 can only use 256 colors, no bitmaps, no scaling, no line scroll, no column scroll.
rotating background 0 can scale and rotate freely, and do bitmaps, but it has no line scroll/column scroll (not that it needs them)
rotating background 1, when enabled, will disable ALL normal backgrounds. It also can't do bitmaps, only tilemaps, and it will take the 2nd rotation matrix as its input (so rotation background 0 can only do 1 plane and no windowing).

rotating background 0 can take 2 rotation matrixes. It can either cut the screen in half and display both (so a skybox and a flat ground that meet in the middle, see panzer dragoon, sonic jam, radiant silvergun), or use the window function for the second matrix so you have a cut-out in the middle of one plane where a different 3d plane can be seen through, like a window on a wall. Grandia uses this to display two set of grounds at different heights.

cont.

>> No.10045610

>>10045607
You can also do tricks like blending two layers together, even two layers which have stuff inbetween them, for ex. combining a background that is normally covered and unseen, to a sprite layer. Last boss in Nights and last level in Sonic R do this.

There's also a set of other stuff like gradation (blurring of a layer), two types of sprite shadows (sprite data is only used to display a black half-transparent field ignoring the sprite colors), global color offseting (useful for fadein/fadeout), mosaic (has limitations on rotating bgs), rotating the VDP1 framebuffer, hi-res modes have their own limitations, and there's two 31kHz 480p modes.

However all of this needs MANUAL micromanaging of memory access timings. Some modes may need more timing "slots" assigned to them.
And you also have 16 different sprite formats to handle.

it's a really bullshit overcomplicated system.

>> No.10045612

>>10045595
>I don’t understand what it’s referring to
ftfy

>> No.10045637
File: 151 KB, 564x1166, affine texture.jpg [View same] [iqdb] [saucenao] [google]
10045637

>>10045535
>>10045547
the playstation gpu can draw triangles with a bunch of parameters including
- flat color (entire triangle is 1 color),
- gouraud shading (per vertex color that gets averaged out over the entire area)
- transparency (reads what is already in the framebuffer at a given pixel and combines it with the polygon pixel with 4 different selectable algorithms)
- texturing (uses per vertex UV coordinates to "map" a region of VRAM into the triangle).
- always 15bit color, and dithering is automatically applied.

That's all in 1 command and at the same speed no matter what you do. Saturn VDP1 sprite drawing is the same, except that it is slower, dumber, less colorful, and very wasteful.

The sprite drawing on Playstation is different. It's not a real draw command, only technically. What it does is execute a data copy. It copies data from VRAM into framebuffer with zero processing. Because of this you can only draw even edged rectangles (no 4-point deformation like on Saturn), or put any effects on them, or get dithering. Up side is that it's 2x as fast.

Neither of them are true hardware sprites like on 8-bit and 16-bit consoles. They are just hardware plotters with a given amount of framerate and features. And the playstation is far ahead on everything, except if you want to do 4-point transforming with seamless texturing (psx has a draw command to do this but it internally breaks it down to two triangles, so you get affine mapping artifacts in the middle).

>> No.10045642

>>10045304
PSX can hardware decode mjpeg. Saturn has no hardware decode built-in, so they had to do software decoding. There were at least half a dozen different codecs used...

>> No.10045656

>>10045637
>The sprite drawing on Playstation is different. It's not a real draw command, only technically. What it does is execute a data copy
Block copy is a different and much simpler command.
Rectangle draws use the same texture format as polygons and support palettes, flipping, uv mapping, transparency, and color modulation.

>> No.10045674

>>10045656
>Rectangle draws use the same texture format as polygons and support palettes, flipping, uv mapping, transparency, and color modulation.

Rectangle draw just executes two triangle draws with shared vertices. I mentioned that.

Block copy is what >>10045547 brought up, and it's the one that you can use to draw "sprites". It's twice as fast and is the only way to get around dithering, but it can't do any effects whatsoever.

>> No.10045680
File: 41 KB, 787x332, Screenshot 2023-07-07 115342.png [View same] [iqdb] [saucenao] [google]
10045680

>>10045674
Quad != rectangle. Drawing quads is done with the same command as drawing tris, and those are decomposed to tris internally.. Drawing rectangles (sprites) is another command entirely.

>> No.10045683

>>10045612
and yet, I'm not wrong

>> No.10045687

>>10045680
>Quad != rectangle.

You called the 4 point polygon drawing as a "Rectangle draw" in the first place. Stop arguing for the sake of arguing.

>> No.10045691
File: 58 KB, 778x416, Screenshot 2023-07-07 120303.png [View same] [iqdb] [saucenao] [google]
10045691

>>10045687
Like I said, rectangle draw is a different command to quads and also to block copies.

>> No.10045849 [DELETED] 

>>10045529
A squad is still a polygon.

>> No.10045857

>>10045535
Saturn renders polygons to a frame buffer just like the ps1, and N64. Older 2d consoles did not have a frame buffer. Also, ps1 does not use a 3d engine to render 2d. The ps1 gpu is fully 2d and knows nothing of the third dimention.

>> No.10045861

>>10045857
Lol, ok buddy

>> No.10045876

>>10045857
>The ps1 gpu is fully 2d and knows nothing of the third dimention.
While that's sort of true, there's still a difference to be made between untransformed, affine transformed, and projected primitives.

>> No.10045972

To me the real distinction is between realtime drawing and rendering into a framebuffer.

>> No.10045994

>>10044613
I thought streaming in this case meant the sprite engine pulls sprite data directly from the cartridge instead of VRAM. I think some N64 games like Indiana Jones also did this with textures. Maybe some Rare games did as well.

>> No.10046013

>>10045994
>I thought streaming in this case meant the sprite engine pulls sprite data directly from the cartridge instead of VRAM.
There's only two platforms I know of where you can render sprites directly from cartridge ROM. Those are the NES (with CHR-ROM) and the Neo Geo. There's no need to stream anything, these platforms don't even have VRAM.
Otherwise, streaming involves copying sprites from the cartridge into VRAM just in time for rendering This was quite common. Saturn does this whenever it uses the RAM cart.

>> No.10046032

>>10046013
Guess I was thinking of the NES then. Thanks for clarifying.

>> No.10046052

>>10043407
>background layers
>sprites

kek.

>> No.10046061

>>10046013
>>10045994
The N64 can pull textures from ROM to T-Buf directly. This was recommended as it freed the RAMBUS for CPU usage while it was happening. While it was convenient and good for performance, it meant you couldn't compress the textures on cart which sucked.

>> No.10046063

What is the original source for this sort of nonsense? Some youtube video or forum post?
It is technically correct that the Playstation does not use sprites, but neither does the Saturn.
The "flat polygon" thing is so ridiculous though. What do you think a polygon is, exactly?

>> No.10046065

Saturn ran a lot of shit better than ps1 but that lack of transparency was so fucking shit.

>> No.10046068

>>10046061
>This was recommended as it freed the RAMBUS for CPU usage while it was happening
Interesting tidbit, is there a source for this?

>> No.10046128

Explain this
https://www.youtube.com/watch?v=XaP8S2VPS50&t=270

>> No.10046135

>>10037928
The character trail.

>> No.10046138

>>10046068
>>10046061
I don't have time to google it properly and cursory googling suggests that either common knowledge is wrong or I've mixed it up with SGI GPU programming. So for expediency's sake, disregard that, I suck cocks, etc.
I don't see why the pointer to the texture for gDPLoadTextureBlock can't be ROM, but every resource says "DRAM" so that's either a commonly held misunderstanding, or there's some hardware limitation that means you can't put the ROM address in your display list. I have a strong desire to try it now and see what happens...

>> No.10046158

>>10046128
Does it really do that on real hardware? I just booted it up on emulator to check and I don't see it.

>> No.10046183

>>10046158
Probably not
But why would it glitch like that if it was just 2D like the SNES

>> No.10046196

>>10046183
Maybe they didn't use the 2D rendering primitives. Just as people in this thread don't believe the PS1 had a dedicated 2D RECT command, so too would people programming games jump straight to the conclusion that they should be using polygons arranged to mimic a sprite blit.
don't fall into the trap of thinking commercial game programmers know everything about the hardware, you're lucky if they were even TOLD all the features of the hardware before being given a copy of codewarrior and told to get to fuckin' work.

>> No.10046218

>>10046196
I don’t think they are made of polygons
I think they are projected onto one

>> No.10046290

>>10046128
Who knows, I've never played a 2d playstation game that does that. Either an emulation glitch, or Capcom fucked up somehow. I think their Megaman games were primarily developed on the Playstation, not Saturn, though, so no clue.

>> No.10046319

It really doesn't fucking matter how sprites are drawn if the end result was 2D sprites on the screen. Nobody cared back then.

>> No.10046506

>>10046319
It can kinda matter for efficiency-minded devs. Blitting stuff onto a framebuffer is inherently an slower affair. It's why 2D sidescrollers on IBM-PC sucked shit until CPUs got fast enough to brute force it. You get basically infinite sprites sure but now you're contenting with fillrate and GPU processing slowing everything down.

>> No.10047182

>>10046319
>lets not have a discussion because I don't care
please

>> No.10047235

>>10038039
A schizo is not much better than an AI.

>> No.10047302

>>10037843
>Where does the myth that the Saturn was better at 2D than the PSX come from?
>The 2D fighters were better on Saturn because of the 4MB RAM cart
Sheesh

>> No.10048602
File: 599 KB, 640x480, SaturnComposite.webm [View same] [iqdb] [saucenao] [google]
10048602

>>10037860
> Even the SNES could do them
The SNES is even more limited with them. On SNES additive/subtractive blending works as follows:

-You have two screens, the main screen and the sub screen.
-Half your palettes are dedicated to the main screen, the other half to the subscreen.
-Anything you want to be blended you put on the sub screen.
-Anything you don't want blended goes on the main screen.
-The subscreen is then blended with the main screen at the specified settings, so everything is blended with the same settings.

So you can't just say "I want this sprite blended with these settings, this background layer with these settings..." and so on and so forth. It all gets blended the same. It also means you lose half your color palettes to do it and you can't stack transparencies on top of each other. So to do something like the Megaman X4 example, you'd sacrifice half your color palettes just for the spot lights and after images, and they still wouldn't look right because of the inability to layer transparencies on top of each other.

Saturn on the other hand can do 50/50 blending on VDP1 with sprites. They can be layered on top of each other and everything. The problem is it's only 50/50 blending, takes 6x longer to draw, only works on 15-bit RGB color, and can have corruption issues with pixel over draw in distorted sprite mode. VDP2 can do proper blending on all it's layers just fine.

The main issue that comes about and what X4 is struggling with is the issue of VDP1 doesn't know what VDP2 is going to draw. So as a result it can either blend with VDP1 objects, and be opaque over VDP2 layers, or it can flag it for VDP2 to blend but then it will overwrite the pixels that were already drawn by VDP1, thus erasing them.

There's ways to work around it, but it's tricky and takes a lot of careful though to make work. So meshes were used instead. But honestly on a CRT over composite meshes look just fine.

>> No.10048614

>>10048602
The real ugly part with the meshes in MMX4 is that overlaid meshes don't blend with each other. In the Playstation version the searchlights are brighter where they overlap.

But it is small potatoes in the big picture.

>> No.10048707

>>10048614
Sure that's the drawback of meshes. The point is more though that the SNES wouldn't really have an easier time with that either. Everything would be blended with the same settings and wouldn't be able to overlap either.

One thing that could be done on Saturn though would be to do a kind of flicker effect where you have it alternate every other frame between blending with VDP1 sprites and blending with VDP2 layers, or just switching between half transparent and not transparent, etc. At 60Hz it would be fast enough that it would look like it blends properly with everything. Cotton Boomerang does something similar to that effect.

>> No.10048742

>>10043849
It’s a shame we were so obsessed with 3D at the time because we could’ve gotten some bad ass street fighter ports on N64 or a proper Super Mario World or Super Metroid sequel.

>> No.10048757

>>10048707
That's true too. The GBA supported transparent sprites but many games resorted to 60Hz flickering when sprites overlapped to avoid this problem.

>> No.10049070

>>10048757
Also some GBA games like Golden Sun software rendered sprites on a bg to blend them with hw sprites.

>> No.10049094

>>10049070
Makes sense, it had plenty of layers to do it with.

>> No.10049414

>>10049070
>>10049094
A few Saturn games do this as well. Grandia does it for it's battles and Burning Rangers famously does it for the transparent 3D objects.

>> No.10049958

>>10037843
>Where does the myth that the Saturn was better at 2D than the PSX come from?
Coping retards.

>> No.10049992

>>10046063
>The "flat polygon" thing is so ridiculous though. What do you think a polygon is, exactly?

There are explanations why SOTN looks like crap on the Saturn, made back in the GameFAQs era, which try to explain it that way, that the Saturn couldn't run the game because it used flat polygons from the PSX instead of true 2d like on the Saturn. As opposed to the Saturn just sucking ass and not being able to run the game properly period.

It's one of those Sega cope bullshit terms like Blast Processing.

>> No.10050024

>>10049958

2d ports that were released on both had more original animation frames than the psx in pretty much every example, even before the ramcart

>> No.10050160

>>10049992
> As opposed to the Saturn just sucking ass and not being able to run the game properly period.
To be fair, Saturn SotN was ported by the F Team at Konami. There's a lot of really stupid and inefficient things that game does that has nothing to do with the hardware.

But Saturn's 2D strengths really aren't in sprites vs polygons, it's VDP2's background layer capabilities.