/vr/ - Retro Games

>>5463254
Well, the Saturn complicated geometry was because on how fucking rushed it sent out. It was originally set out to be a 2D gaming monster machine.

>>5463259
>It was originally set out to be a 2D gaming monster machine.
That's why they included VDP1 - a chip specifically deigned to push polygons - from the start, right?

Just got a response to my question to him "Just out of curiously, what makes you say the Saturn is poorly designed? What sticks out the most about it?"

Pretty much everything. Poor documentation, poor libraries, super complicated VDP2 that doesn't work well with the VDP1, way too many restrictions, no texture coordinates support, the VDP1 overdraws pixels (killing transparency and making the Saturn way slower than it could have been). And of course things like when you use the cpu bus the other cpu can't access ram, the scu dsp is poorly documented with little ram, etc. When you look at the Ps1, everything seems way easier and it should still gives you better results. That being said, the Saturn can be better than the PS1 in several areas and I want to make sure to use these advantages, but overall the PS1 is a better machine for sure.

>>5463254
multi chip consoles had been bashed just as multi core processors had been bashed. the problem is given enough time it becomes a standard

this is something the industry was slow to accept and multi threading support only recently became a standard for AAA ports in regards to multi core designed chipsets. so multi chip consoles were simply ahead of their time

>>5463418
>>5463254
Literally who

>>5463254
Why the fuck would anybody who has a more valuable opinion than this guy be on /vr/. He's one of the most knowledgeable saturn programmers right now.

And yes, the ps1 is a much cleaner and better design, nobody would argue otherwise unless they're a delusional fanboy. I love the saturn but it was obviously rushed and poorly designed.

>>5463262
VDP1 is basically a sprite blitter with distorted sprites for arbitrarily shaped quads slapped on. It uses forward texture mapping for crying out loud.

>>5463580
>It uses forward texture mapping for crying out loud.
what does that mean

>what makes you say the Saturn is Poorly designed?
> Pretty much everything. Poor documentation, poor libraries, super complicated VDP2 that doesn't work well with the VDP1, way too many restrictions, no texture coordinates support, the VDP1 overdraws pixels (killing transparency and making the Saturn way slower than it could have been). And of course things like when you use the cpu bus the other cpu can't access ram, the scu dsp is poorly documented with little ram, etc. When you look at the Ps1, everything seems way easier and it should still gives you better results. That being said, the Saturn can be better than the PS1 in several areas and I want to make sure to use these advantages, but overall the PS1 is a better machine for sure.
not a big surprise considering how rushed it is. I really hope he releases his tools, I'd like to see a proper Doom port, maybe realize that 60FPS dream.

>>5463586
I think he means that the VDP1 can't into proper UV mapping due to it's sprite-based nature.

>>5463586
Forward texture mapping is where you iterate over the entire texture and draw each texel to the screen, because you might be scaling a large texture down to a small triangle, you can get a lot of overdrawn where you write to the same pixel multiple times.

Nearly every other piece of 3d hardware and even software renderers do the opposite, iterating over the polygons texture in screen space, determining which texels go in each pixel, and avoiding overdraw. This is also why transparency is often avoided on the saturn, each transparent pixel is several times slower, and with overdraw that means multiple reads and writes to each pixels that are slower and can cause artifacts if the quad is heavily distorted (correct transparency should only cover each pixel once per polygon).

Shit console literally no good games

>>5463595
Yeah, it also means you can't do uv mapping. The hardware is designed to draw an entire sprite, I mean texture, to the screen every time. (except for clipping and stuff)

>>5463593
>no texture coordinates support
Wait, what?

>>5463610
"3D" on the Saturn is achieved by literally distorting 2D sprites.

>>5463628
Isn’t that still functionally 3D.

>>5463628
To be fair it's not really any less 3d than the ps1. Neither console's graphics hardware really does anything in 3d, they just have better or worse ways of affine texture mapping. Real 3d requires you to interpolate polygon attributes in 3d, which only the n64 did in the gen.

>>5463630
If an engine had a z axis, how can it not be “true 3D”

The "distorting 2D sprites" meme is missing the point because literally all polygon-based graphics consists of "distorted" "sprites"
The whole problem with the Saturn was how its implementation of 3D was less efficient and less powerful than the competition

>>5463632
Surr, the software does 3d, I mean vdp1 (and whatever the ps1 graphics chip is called) doesn't know about 3d.

>>5463629
Yes, but it seems very hack-ish on the Saturn.

>>5463635
Basically true but both saturn and ps1 are basically doing 2d texture mapping (depth interpolation aka z axis aka the 3rd dimension isn't done correctly). Check out Chris Heckers article on texture mapping to learn more about that.

>>5463639
Well it’s how Sega was doing it in their state of the art arcade games at the time. To be fair, it’s not like there was a standard to 3D graphics back in ‘93.

>>5463639
That really isn’t “hacking”. That’s just how hardware of the time worked.

>>5463643
How it's done on "modern" GPUs (ie. anything newer than these 5th gen dumpster fires) is you basically extend each vertex from 3D to 4D, project with a 4D matrix, interpolate in 4D, and then convert back to 3D, and the UV coordinates magically get perspective-correct values thanks to some bullshit math I never actually understood. This technique was actually around for years before 5th gen but it only became the standard technique for consumer hardware when Microsoft blessed it in the form of an official API.

>>5463664
Yeah but they could have just done it quake style or something, interpolate depth in 2d and perform the depth division every 16 pixels or something. Would have been way better than nothing. I guess those tricks weren't all that well known at the time.

>>5463664
In English mofo. I dont understand all this technical mumbo jumbo.

>>5463418
The PS1 seems simple because they worked with third parties from day zero to get the best libraries out. SEGA specifically held back every library because third parties were considered direct competition to them.

The only real issue with the system was the VDP1, and maybe the SCSP not having hardware compression. VDP1 was six times slower than the PS1 GPU and it was extremely difficult to get all of its features working, because everything came with a "you can do this, but then you can't do that" kind of loophole. That's what makes the system a true puzzle, and that's why developers had a horrible time getting performance out of the machine, and why they considered 3d transparency to not work (you can get it working, but then you have to completely ignore the VDP2 and your framerate will suffer).

Even the VDP1 having shit feature set wasn't a problem, if it was fast enough, they could've made up for that. But it was just slow. That's all it boils down to.

If the VDP1 wasn't anaemic, they could've gotten around all the rest of the problems over the years; redesign the chipset to use fewer chips, make the console cheaper, have libraries that allow perfect use of SCU DSP and both SH2s and do software sound decompression (all of these were in the devkits by 1997 too).

>>5463603
>Nearly every other piece of 3d hardware and even software renderers do the opposite, iterating over the polygons texture in screen space, determining which texels go in each pixel, and avoiding overdraw.

Keep in mind that there weren't too many 3d hardware and software renderers at the time. 3d rendering as a whole didn't have a proper industry standard yet. They experimented with all sorts of shit in the 90s, voxels, tiled rendering, raycasting, raytracing, you name it. Forward mapped quads had some arguable advantages at the time (not the way Sega implemented them though).

>>5463680
It's fucking magic to me too but I'll try to explain.

In 2D graphics you use 2D coordinates to tell the hardware where to draw a sprite. Each corner, or "vertex," can be described by two numbers, X and Y, referring to the column and row where a pixel is drawn. The hardware can then calculate averages between these values to refer to any point inside the graphic it's trying to draw; for example, the top center of a sprite is halfway between the top left vertex and the top right vertex. This is called "interpolation." The hardware needs to do this when it's trying to draw a sprite at a larger or smaller size than the actual pixel art that defines it.

In 3D graphics, you're constantly drawing stuff at different sizes, plus you also need to be able to tell the hardware how far away something is from the camera, so closer things can cover up things that are further away. To accomplish that, each vertex gets a third component, called Z. Now the hardware can scale and rotate any 2D graphic and place it anywhere in a 3D scene. It can also shrink one end of a graphic more than the other in order to simulate perspective (pic related). All this is called "projection."

Doing this for each polygon involves a bunch of math, but most of it only needs to be done once per camera position, and then you can save it in a structure called a matrix, and the rest is just a handful of additions and multiplications per vertex. A 2D matrix has 4 entries (2 times 2) and a 3D matrix on the Playstation would have 9 entries (3 times 3). And as long as you're drawing solid color triangles, that's all you need.

However, we all know that textured triangles on the Playstation have crazy warping effects when they get close to the camera. The "4D matrix" trick I described earlier is a workaround. I'm not sure why it works, exactly. I understand everything I just described, except for this.

>>5463681
>Keep in mind that there weren't too many 3d hardware and software renderers at the time. 3d rendering as a whole didn't have a proper industry standard yet.
Just for reference, OpenGL 1.0 had perspective-correct triangle texturing in 1992, but it was aimed at the high-end CAD market. OpenGL was based on the even earlier IrisGL, created by Silicon Graphics, the company that made the N64's GPU. I guess this helps explain why the N64 could do "real" texture mapping while the other 5th gen consoles were kind of a clusterfuck.

>>5463739
that actually makes sense. Thanks for elaborating my dude.

>>5463681
>"you can do this, but then you can't do that"
So basically the Saturn can't chew gum and skip at the same time, like we've known for twenty+ years now.

>>5463896
Glad I could help

The saturn console is a weird piece of videogame history.

>>5463648
Sega arcade machines had perspective texture mapping at the time

>>5463664
The reason that PS1 and Saturn don't do perspective correct texturing is because the z value is discarded before the triangle setup stage which is where the perspective divide is supposed happen. N64 does retain the z for triangle setup though.

>>5463681
>VDP1 was six times slower than the PS1 GPU
To be fair though, that's only at transparency.

The reason Saturn was poor at 3D is simply because Sega's console division lacked expertise and preparation. They were constantly off-guard about what their rivals were doing so everything became a band-aid for extra performance.

The CPUs on Saturn are the things that are supposed to do the bulk of calculating T&L (the SCU DSP was only ever supposed to be a supporting chip which is why it's so hard to use for most things). Hitachi SH-2 is a bit better than other CPUs at doing it due to special MAC instructions. Not a problem when expectations are low. But out comes Sony with a specialist T&L processor for the PS1, the GTE. It's a fixed function vector unit that blows a general purpose CPU out of the water. Sony also demonstrate a more efficient GPU design than Sega's old-school inspired distorted quad technique.

How does Sega response? They haven't got the time or the R&D money to reinvent the wheel and come up with new custom 3D chipsets to respond to Sony. The only solution is to double up the existing Hitachi SH-2 for extra T&L performance. And they quickly adapt an arcade style background tile engine which they call VDP2 to give the Saturn a bit of extra kick for 2D games and certain 3D games that were popular at the time like Virtua Fighter.

Saturn was the way that it was due to under-preparation, over-engineering, and desperation.

>>5464703
Well it does ports of arcade 2d games better than the original PlayStation at least.

>>5464909
Isn’t that just a matter of RAM?

>>5464703
Perspective divide needs to be done for every pixel (or span of pixels as an optimization) not just in triangle setup. That's why everybody tried to do affine instead.

>>5465145
I suppose since none of big three 5th gen consoles have a dedicated triangle setup unit (as far as I know) it's probably just more pertinent to say that the z doesn't make it across to the rasterizer stage on PS1 and Saturn

>>5464909
Mostly b/c the Saturn had slightly more RAM and a hardware background tile-mapper for slightly better performance gains. Even then if you wanted the arcade "perfect" experience on the Saturn you needed a RAM cart.

>>5464703
>To be fair though, that's only at transparency.
No, it's for regular texturing. For transparency, it gets worse.
Sega listed a formula for calculating the cycles it takes to draw a textured polygon, and when you apply it to the speed the VDP1 is running at, it comes out to something like 5-8 MPixel effective fillrate. Playstation was doing 24+ MPixel in tech demos on LAUNCH DAY, and the 95+ revisions could do alpha twice as fast (it's why they had two dev playstations, blue and green).

>SCU DSP was only ever supposed to be a supporting chip which is why it's so hard to use for most things
No, it was meant to do T&L from day one. Model 2s all relied on DSP code for T&L, and the idea was the same for the Saturn, a weaker main cpu and a 3d DSP. But then the PSX specs came out and they looked for a new main cpu, and ended up with dual SH2s. Even then, the DSP is faster at T&L than the SH2s - but the point is moot because it's the VDP1 that kills the performance.

>The only solution is to double up the existing Hitachi SH-2 for extra T&L performance

They were still deciding for the main chip back then, but went with the dual SH2s after Sony dropped the bomb. This was confirmed by a recently translated interview.

>they quickly adapt an arcade style background tile engine which they call VDP2

100% bullshit, the VDP2 was part of the design from the beginning. The VDP1 doesn't even work without it (all image output and applying palettes are handled on the VDP2 side).

Keep in mind the original Saturn design was, one main CPU, one sound CPU plus the SCSP, VDP1+2, SCU holding it together and DSP to help with math. Then they added the whole CD subsystem (was meant to be an optional upgrade), and the dual SH2s which also required a glue/controller to work in tandem, plus an extra megabyte of 16-bit ram because why not.
The original plan had 4 ASICs and 2 CPUs. They ended up with 7 ASICs and 4 CPUs, plus the 4-5 chips on the CD drive.

>>5464686
Sega arcade machines were not consumer hardware, they cost thousands of dollars, they used something like 6 math CPUs for the T&L setup only.

>>5463770
Silicon Graphics machines started at 5 figure price points and could reach 6. They were not consumer 3d hardware either, like the Saturn, N64, Playstation, then later the Voodoo and ultimately the Geforce.

Back in the 90s, the consumer market had no 3d standard. You had Nvidia experimenting with 9 point quads that could do extremely smooth round edges, you had games experimenting with 3d voxels, you had Microsoft developing tile based rasterizers (Project Talisman), the most popular games all used raycasters like Doom and Duke simulating 3d with hacks, and you had Carmack optimizing his 3d software code to the point of infinity so he could run Quake at decent speeds (which at the time meant 30fps in 320x240 at 256 colours). Raytracing also existed even then, just not in games.

It wasn't until the 3dfx Voodoo that things started to get on the right track, and even then it would take 5 years of conflicting and poorly supported standards until we reach the Geforce, when things were finally set in stone.

And part of the reason they even reached a point where things could be standardized, is because hardware like the Voodoo and the Playstation became so popular. If it was the Saturn and the NV1 that sold 100+ million units, then maybe it could've been quads that become the standard.

>>5466313
>the most popular games all used raycasters like Doom and Duke simulating 3d with hacks
Wolfenstein and its imitators used raycasting, but Doom and BUILD could rotate polygons by arbitrary angles (with limited choice of axis). The weirdest parts of these engines were the clever data structures they used to represent geometry, so that polygon depth was encoded by traversal order.

>>5466291
>apply it to the speed the VDP1 is running at, it comes out to something like 5-8 MPixel effective fillrate
This seems like an extraordinary claim given the “peak” theoretical texturing rate is supposed to be 28 MTexel/s. Do you have a source for this?

>No, it was meant to do T&L from day one.
Then why is it missing so many useful T&L functions?

>Model 2s all relied on DSP code for T&L, and the idea was the same for the Saturn
I would argue just because the Model 2 did it a particular way doesn’t say anything of significance for the Saturn by itself. Arcade and consoles have completely different design paradigms. Model 2 using DSPs would have simply been because nothing else on the market at the time could have provided the requisite performance.

>100% bullshit, the VDP2 was part of the design from the beginning
But wasn’t there that interview which confirmed that VDP2 was added in after the PS1 specs became available?

>>5466313
I'm super autistic about this but doom and duke 3d did not use raycasting.

They were quad renderers with restrictions that allowed for perspective correct texturing with no per pixel divide (lines of constant z). Doom uses a bsp to get the set of quads to render, and duke used a portal graph. Both were a lot more advanced than the typical raycaster like wolf3d.

>>5463586
It means he has a clue and those who don't shouldn't pretend to by parroting

>>5466494
>This seems like an extraordinary claim given the “peak” theoretical texturing rate is supposed to be 28 MTexel/s. Do you have a source for this?
Nobody ever made a 28MTexel/sec claim for the VDP1. Even Sega themselves put ~20MPixel/s (not 28) in the EARLY dev docs.
Sega DTS March 1996 has a tutorial slide under DOCUMENT\SATURN\SGL&MORE. It gives you 302 + (x * y * 3) + (y * 5) cycles for drawing a textured, gouraud shaded polygon. This implies that it takes THREE cycles to draw a single pixel, so with the chip running at 28.6MHz, even at peak performance you couldn't get more than 8-9 megapixels of textured polygons on the Saturn. And this is not counting the setup time for drawing, the time it takes to copy over new display lists every frame, etc.

>Then why is it missing so many useful T&L functions?
Such as? It's meant to do matrix calculations for 3d, and it does that faster than the SH2 despite running at half the speed. There's actual code in the devkits that do 3d transformers a third faster than the SH2.

>But wasn’t there that interview which confirmed that VDP2 was added in after the PS1 specs became available?

No, there wasn't. Adding the VDP2 would've been completely counter intuitive for that purpose anyway, since it was a pure 2d chip and they were trying to squeeze out more 3d at that time.

What they did was opt for a stronger CPU, and the only one they could find was having two SH2s in main/slave mode.

>>5463254
>poorly designed
Your opinion goes into the trash

>>5463254

Who's this nobody and why can't he even use proper capture equipment?

>>5467929
> I know literally nothing about the Sega saturn

>>5467930
He made https://youtu.be/foMLX3Lz8fQ

>>5464703
>How does Sega response? They haven't got the time or the R&D money to reinvent the wheel and come up with new custom 3D chipsets to respond to Sony.
Why not? They could've let the Genesis/Sega CD live a few years longer and then release the Dreamcast earlier in '96/'97.

>>5463254
Look at all this effort for a game that's going to be forgotten in dusty rom sites shortly after release. Cool from a tech standpoint though.

>>5468106
>dude, he made an HTML5 game in unity
>Holy fuck, he invented the internet!
You are officially even more retarded than Al Gore

>>5468457
>Unity
You can't be fucking serious. Did you read even a single post in this thread?

This guy has been working on a recreation of the Sonic X-Treme engine for a couple of years, first building on the various beta builds available (what you're seeing there) and now doing his own experiments with the Saturn hardware. His early stuff like that video were recorded in emulators, now because he's doing exclusively hardware testing and doesn't have a capture card he's recording his screen.

>>5468457
He made a recreation of the sonic xtreme engine in c and running on a saturn, from scratch

>>5468457
He made a recreation of the sonic xtreme engine in c and running on a saturn, from scratch.

If that doesn't give him the credentials to talk about how much of a pain in the ass the hardware is, then idk what would.

>>5468132
>They could've let the Genesis/Sega CD live a few years longer and then release the Dreamcast earlier in '96/'97.

Genesis was dead and not selling in Japan, where the company was headquartered at.

>>5468774
>from scratch

he is using the SGL library from the devkits.

>>5468826
It still looks better than anything that actually came out on the Saturn. Which is just fucking sad. It runs at 60 FPS and 30 in split screen.

>>5468826
>he is using the SGL library from the devkits.
was, not any more.

>>5468830
not even the creator thinks that, he cites the slavedriver engine as the pinnacle of saturn based technology. He's targetting more of a middle ground, more generic in use but flexible with less concern for a tight overhead.

Wow. Someone made a Saturn game that gets over 15fps 20 years after the console was relevant. I guess anything is possible if you wait long enough.

>>5468840
Ok that’s something I’d definitely admit. Powerslave/Exhumed looks much better. Dook is also technically really impressive. Then there’s the panzer dragoon games of course. Besides that there’s not really anything else that’s both impressive with that kind of frame rate on the system

>>5468826
You're right. I think he was talking about rewriting a lot of it for his quake experiments

>>5468132
Do you really think they could have built the Dreamcast without learning a thing or two from the boneheaded mistakes they made with the Saturn?

>>5468106
More than you pleb. Didn't develop for the Saturn, but for the PS1. That is more than you will ever achieve.

>>5463254
literally who?

>>5463664
interpolation is actually done in 2D screen coordinates. this is to make rasterization efficient. the perspective correction seems impossible to understand, but with the correct approach is actually pretty simple. I'll dump math if anyone is interested.

>>5469503
Lol ok bro. We weren't talking about me. We were comparing you to an actual saturn dev (and let's throw in another saturn dev who said the design sucked http://www.gareth.uk/2010/08/07/interview-with-ezra-dreisbach-of-lobotomy-software/ )

>>5469606
>ezra dreisbach
>believing what jews say

>>5469656
> listening to random posters on 4chan

>>5469663
Hi Ezra

>>5469656
You dipshits just want to blame "the Jews" for your problems when really you just failed at life because you're a fucking imbecile

You're all saying Sega resorted to dual SH2s to beef up the Saturn, yet the 32X already had those (though their launches were close). Kind of confused why they did that on the stop-gap system as well if it wasn't (or was it?) going to compete with the PlayStation.

Saturn still is a shit console with no games.

>>5471121
Keep rimming Sony's ass, buttmad Sony drone

>>5471168
stay mad segatard.

Saturn was aesthetic as fuck

The quad thing always made me wonder, what happens if all four points on a quad aren't coplanar? What if the points are arranged so that opposing edges of the quad cross over each other?

>>5471171
Sony Dronie insults are babby-tier

>>5473008
your company is dead

>>5473035
>>5473008
>>5471171
>>5471168
>>5471121
>>>/v/

>>5463259
>It was originally set out to be a 2D gaming monster machine.
Please stop using youtube as your source of information. Thank you.

>>5473078
You can't take the 4chan out of 4chan. That's why people leave 4chan, because they get tired of these non-discussions with people who have no social gradient.

4chan is 4chan, and shitposting is 4chan... If you don't like the shitposting, it might be best to take off.

>>5471115

http://www.sega-16.com/forum/showthread.php?33527-The-Story-of-the-Hitachi-SH-2-and-the-Sega-Saturn

According to Gryson's translation of a Nikkei Electronics magazine's 1997 article:

"In the summer of 1993, a slight incident occurred. Sega stated that the performance of the SH-2 (25 MIPS) was insufficient for a next-generation home console (this was right around the time when Sega’s biggest rival Nintendo announced that they were including a 64-bit CPU as well as a graphics processor jointly developed with Silicon Graphics, Inc. in their next console, the Nintendo 64). They wanted to increase the performance of the SH-2 by raising the frequency. However, to do that, it would be necessary to re-examine the chip design, and the SH development group did not have the time remaining to do that.

The decision of what to do was left for the top-level meeting between Hitachi and Sega executives that took place in Hakone in September 1993. The SH group had prepared a secret plan to resolve the “performance improvement problem.” Their solution was stated as follows: “If we use the multiprocessor function that is included in the SH-2, we can operate two SH-2s linked together. This should satisfy the request for higher performance.” Nobody had expected that the multiprocessor function, which they had been reluctant to include, would prove to be this useful.

In this way, Sega’s next console, the Sega Saturn, came to be equipped with two SH-2s. "

So the decision to incorporate a second SH-2 was made in the summer of 1993. The 32x was conceptualized, designed, and released all within 1994 I believe.

>>5473238
This is 4channel not 4chan.

>>5473035
No. Back to /v/ you sperg.

>>5472995
VDP1 (which draws quads) doesn't know about z coordinates

>>5473283
Isn't that not taking into account the power of the 2 VDPs and the SCU?

>>5473283
Thanks for the info anon.

The real retardation of the Saturn was sega going:
>"oh look doing this sound/disc drive/etc... could take away from the main CPU's ability to run code, lol let's add another CPU just to handle that!"
like for fucks sake why does the disc drive need it's own 32bit CPU??????? It could have been below $400 if they hadn't done that
>>5463580
>sega used an inefficient method to do polygons, so that means it never was designed to do them in the first place!
No

>>5467882
>Nobody ever made a 28MTexel/sec claim for the VDP1. Even Sega themselves put ~20MPixel/s (not 28) in the EARLY dev docs.
>Sega DTS March 1996 has a tutorial slide under DOCUMENT\SATURN\SGL&MORE. It gives you 302 + (x * y * 3) + (y * 5) cycles for drawing a textured, gouraud shaded polygon.
Wait a sec though, gouraud shading and texturing are two different pixel operations. The reason I say that Saturn should be 28 MTexel/s is because that’s the speed of the pipeline which should include a texture unit capable of one texel per clock. So if the max speed is actually 20 MTexel/s then that either implies that the texture unit isn’t fully capable of 1 cycle per pixel (but has some timing hang over that causes a stall every so often) or *always* overdraws even in the best case scenario.

Though because you’ve said that the process also includes Gouraud shading, that complicates things. The stall might be in the shading operation side of things rather than the texturing. At least because the max fill rate isn’t half of the pipeline speed that implies that VDP1 can shade and texture within the one pipeline clock.

>Such as?
The way you feed it with data and the way it is pipelined doesn’t give it much functional flexibility at all. I’m not underestimating its speed, but it can’t do everything you want it to do. That’s why it was often underused.

>No, there wasn't. Adding the VDP2 would've been completely counter intuitive for that purpose anyway, since it was a pure 2d chip and they were trying to squeeze out more 3d at that time.
I’m referring to that story where it was said that Sega added another graphic chip in response to PS1 specs being revealed. Supposedly it was VDP2. And it’s not a fully 2D chip really because it does have utility in some 3D games, like Virtua Fighter. Hell, the early PowerVR 3D chips for PC supported a similar infinite plane mode.

>What they did was opt for a stronger CPU
Didn’t do both?

Was the Saturn harder to program for than the Atari Jaguar?

>>5474262
>>5474262

I would guess not. Certainly Hitachi would have had quality C-compilers for their CPUs as they were already on their second generation of SuperH chips. The Jaguar's C-compiler was trash, evidently, and most competent developers probably had to create their own.

Though I really admire the Jaguar's unified bus design (and think Sega should have implemented something similar for the Saturn, but with alterations), developers would have constantly been bandwidth-starved and would have to design and program around that limitation. The Saturn had a multi-bus design that would have alleviated the issue.

Atari also released the system with notable hardware bugs that limited the system's performance which developers had to work around or just accept. The Jaguar hardware developers probably needed one more year to work on a major revision of their GPU and sound chips. As far as I understand, Atari was running against the clock and needed to expedite the launch of their system to drum up investor support and to combat the release of the 3DO and probably hoped the bugs weren't as serious as they ended up being.

I was always under the assumption that programming for the Saturn wasn't hard in and of itself, but only became so when trying to tie all the hardware components together to push the system further than it was designed for to meet the quality of its better-designed competition.

>>5474262
I'd argue it was harder since you had like 3 cpus to juggle but then again the Jaguar hardware had bugs.

>>5474296
There’s a few similarities between the N64 and Jaguar.

>Though I really admire the Jaguar's unified bus design (and think Sega should have implemented something similar for the Saturn, but with alterations), developers would have constantly been bandwidth-starved
This was an issue on N64 as well which used a unified memory bus. Although it had very high bandwidth, unless the game was programmed well the bus would constantly stall due to contention and random access latency. Not to mention how most N64 developers turned on the GPU’s bandwidth hungry features like z-buffer and edge anti-aliasing.

>Atari also released the system with notable hardware bugs that limited the system's performance which developers had to work around or just accept
Similar to N64 but to a far lesser extent. The console launched with a major bug in the memory controller that would cause it to stall under specific (undisclosed) circumstances. Not a major issue but developers would have to avoid triggering those circumstances. It was identified before launch but SGI took so long developing the chipset and the console’s launch was already so delayed Nintendo said fuck it and just released the machine.

>>5474026
I never said it was proof, just that if I had a sprite blitter and my boss told me that I needed to add "3d support" in a very short amount of time, a distorted quads system would probably be the simplest way to do it.

>>5472995
>what happens if all four points on a quad aren't coplanar
doesn't happen in early implementations, rasterization is done in 2d
>What if the points are arranged so that opposing edges of the quad cross over each other
depends on the precise way rasterization is done you either get a < style shape or a screen full of artifacts

Can I achieve real transparencies by brute-forcing that in software or is the cost simply not practical, speed-wise?

>>5475537
The Saturn can do "real transparency", if by that you mean sprite-over-sprite transparency on VDP1. There are simply some caveats.
#1 it's fillrate hungry. 6x more. And the VDP1 already sucks at fillrate.
#2 It causes artifacts on most distorted sprites.

>>5475628
So, what are my other options?

>>5475646
You wanna do transparency between sprites and backgrounds, or backgrounds and other backgrounds, you don't have a problem. Saturn does that without breaking a sweat.
I guess you could do software rendering for sprites over sprites but now you're getting impractical. Expect 32x tier performance.

>>5463426
Is a hatchling jumps out the nest and dies because it can't fly it that doesn't mean it was "ahead of it's time", it just means it was retarded and removed from the gene pool. Was the Power Glove "ahead of it's time" or was it just a bad idea and product? This "something bad was similar to something good later so it's justified" mentality is beyond me.

>>5475658
>guess you could do software rendering
This was what I meant originally. Not for massive screen filling quads but a few sprites at a time.

>>5475670
I'm not sure if that would work.
Burning Rangers has VDP1 render a few low res sprites into VDP2's memory (extremely inefficiently) to achieve translucency effects. That's a good example of how you can use creativity to get better transparency on the Saturn.

>>5473238
Still this is a nice & informative thread, like one would except from /vr/, so why shit on it with le ebin 4chan shitposting culture?

as crappy as the saturn ended up, it's still cool as hell and has some really good games