/vr/ - Retro Games

Load times in muh OoT, no thanks

Positives
-Much better third party support (particularly more 2D games)
-Much more use of FMV
-Inclusion of redbook audio

Negatives
-Load times (perhaps fewer levels that could be traversed continuously without pause)
-Either higher console cost, or lower specs to offset the CD-ROM drive price

>inb4 "it would have good games"

I was actually thinking of starting this thread a few days ago.

Was the 64DD supposed to be released at launch?

I remember reading about it once in a game magazine circa 1997, thinking it had become vaporware and forgetting about it, then being surprised a few years ago when I discovered it had actually come to fruition.

>>2351080
I wonder if it would've outsold the PS1, it would've at least been a lot closer in terms of sales. Maybe the PS2 would have been less relevant.

>>2351083
Would've been awesome if Ura Zelda and Mother 3 came to fruition on the 64DD had it been successful.

>>2351087
Weren't there supposed to be add-ons for cartridge games?

I seem to recall hearing that it would have things like new levels for Mario 64 and OOT (the latter actually has a glitch where your save file can lock-up unless a 64DD with Zelda is attached).

Was "Ura Zelda" the original expanded concept for OOT, or was it supposed to be an add-on/expansion?

>>2351083
>inb4 "it would have good games"
It would have more good games. And way more third party support. And the games it currently has would probably have been even better.

Even 20 years later it's hard to believe just how much Nintendo fucked up by going with cartridges.

>>2351092

Ura Zelda was supposed to be an expansion for OoT to be released after OoT came out. Supposedly it was finished but shelved, and sits somewhere within Nintendo's vaults. Yes there if you play Japanese OoT on a N64 with DD attatched it says please insert Ura Zelda expansion disk.

There was a pretty cool F-Zero X expansion released though, with a track creator and car editor, along with more cups.

>>2351097

It really hurts to think how much Nintendo shot themselves in the foot with the N64, causing wounds that have yet to heal.

>>2351110
It's more funny that they keep doing it over and over. Using mini-dvds when everyone else was using higher capacity dvds, using dvds when everyone else was using higher capacity blurays (this one TWICE.)

>>2351110
The rest of the N64 hardware was pretty remarkable though. The design for the system's GPU practically gave birth to modern consumer-level accelerated 3D hardware.

>>2351116
>using dvds when everyone else was using higher capacity blurays (this one TWICE.)
Wii discs were actually higher capacity than 360 discs, because 360 used some kind of crazy security layer that ate up space. Wii U discs are Blu-ray in everything but name.

>>2351116
Nintendo has been up their as with pointless quirkiness since the mid 90s

I have to admit dual screens and 3D on a handheld is cool but that GameCube controller, Jesus why

>>2351117
That's what's so frustrating. The N64 gets so much right and then trips up in a few key areas and drags itself down as a result.

>>2351116
Exactly. Their consoles lately are a far cry from the glory of the Super Nintendo.

>>2351124
Nintendo just lacked a clear vision for the system (like one that Sony demonstrated with the PS1), instead it was like a patchwork of different corporate ideologies and strange bouts of mismanagement.

Now if I recall correctly...N64's GPU (the SGI RCP) had:
-An absolutely fully featured 3D feature-set. Other PC cards at the time had a few things here and there, but NEVER the full set (e.g. texture perspective correction, but no bilinear filtering). The first one on PC to deliver it all was Voodoo, released 6 months later.
-Hardware T&L, the GPU itself could transform polygons, unlike the CPU having to do everything. The Voodoo didn't even do this one. The Rendition Verite released some months later on PC did it too, but wasn't widely adopted. Hardware T&L made a comeback on PC in 1999 with the Geforce 256.
-Had a (somewhat) programmable T&L pipeline. This kind of thing also debuted on PC in 1999 with the Geforce 256.

Iwata would have had to tongue Ken Kutaragi's butthole to get the license for CD after what he pulled.

Has any add-on ever been successful?

Even the Sega CD was still considered a disappointment in the terms of sales and attachment.

>>2351145
The PCE got more CD games than Hu-cards.
FDS didn't fare that bad either.

>>2351145
Turbografx CD/PC Engine CD,in japan that is.

>>2351145
The Famicom Disk System was successful in Japan because it launched a lot of first party Nintendo series like Zelda, Metroid, Famicom Tantei Club, and arguably Kid Icarus.

>>2351145
Famicom Disk System. If it wasn't for the rampant piracy, it could argued to be just as successful as the Famicom itself.

>>2351154
I wonder if the 64DD was released earlier and had similar support to the FDS if it would've been a success?

>>2351068
Games would have just looked like piece of shit instead of a pile of shit.

>>2351162
Would it have been as successful without piracy?

>>2351142
>Iwata
He wasn't the head of Nintendo at that time.

>>2351083
the 64dd was announced BEFORE the release of the actual n64. I guess they thought that not including the cd drive components would have made the base console cheaper and more appealing.

we're lucky the n64 did as well as it did, really.

>>2351145
The PC Engine CD had more games than the actual platform it was an add-on of i believe.

>>2351080
>Much more use of FMV
>postive
wait, what? do not remember what FMV heavy games were like back then or something?

>>2351246
the 64DD was not a cdrom component, it was a magnetic disk drive.

>>2351068
My N64 uses optical media. You must be doing it wrong.

>>2351151
>Implying the Japanese market covers the rest of the planet.

>>2352518
The Japanese market did cover the rest of the planet. Only the casualest of children waited 2 years for PCE shit to be released in their home country.
Ask your parents. They might be old enough to remember.

>>2352501
Did anyone develop games specifically for the Doctor V64 or comparable devices?

>>2352597
About the closest thing is this demoscene for the 64drive flash cart.

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

>>2351121

gamecube controllers are comfy, brah

gamecube everything is pretty comfy

>>2352597
No games that I'm aware of but there were tools that ran on the console and exchanged data with the backup device. Using the PC connection you could even make an online game.

>>2352616
That's a demo for the N64. It doesn't care what flash cart or backup system it runs on.

>>2351068
Intriguing.
Maybe Nintendo would have more experience with Internet activity and Userbase (With randnet and all that)

>muh load times

what if it was designed to have both a CD tray and a card slot? Picture the sega saturn if the expansion slot in the back was for games rather than just memory and ram carts.

So that way most games could just be on cheap CDs while the games that actually get a benefit from being on cartridges can still be cartridge games

>>2352760
CD-ROM drives weren't free in 1996.

>>2352760

Some Saturn games actually had rom carts.
You see it never caught on.

>>2352762
didn't stop every other 5th gen console from using them.

And I do believe the reason nintendo refused to use a CD drive is because it would make the console more expensive and they'd have to sell it for 300 instead of 200. But this is bullshit because the cartridge games cost more than CD games, so any benefit was offset after just a couple games.

Cartridges didn't hurt the 64, just like mini dvds didn't hurt the gamecube. Nintendo has good games

>>2352768
are you really that naive?

>>2352760
I'm picturing it. It looks just like my Saturn that uses the slot in the back for games. I can also plug my modem into that slot.
Thanks for the keks

>>2352762
How much would a x4 drive have cost in 96?

>>2352597
You really think someone would waste their time making something for a pirate add-on with a manufacturer's warranty they probably copy-pasted from a fridge?

>>2351068
N64DD I think should have used VCDs.

>>2352765
Nintendo expected memory prices to keep dropping which they were on track to until earthquake and tsunamis destroyed all the chip fabs.

>>2353185
>VCDs
Wow, you're an idiot.

>>2353172
They did for the SNES.

>>2353172
Top kek :)

>>2353172
It's been done for many other systems.

Even though cartridges were still quite a big dealbreaker for publishers, it was far from the deciding factor for Nintendo's lack of third party support. The console would still have been this ass backwards machine that had to have games written in a very special way to work, and you still had to deal with Nintendo's method of business. The PS1 trumped over the N64 and Saturn mostly due to Sony being much more accepting of third parties, as well as being a huge corporation themselves with a finger in practically every major market. Sony's success from the PS1 days was all but guaranteed, and to this day they still have an edge over their competitors. They even manage to make several games biased to their platform, despite technical disadvantages (IE, MGS2 was a shoddy port on Xbox and barely worked on Windows, GTA5 on PC inexplicably has more pronounced distance fog than the PS4 version).

>>2351893
I think he was referring to like cutscenes that flow better. Like the ps1 version of Spider-Man vs the N64 version.

I would still buy a Playstation.

Why didn't the FDS ever make it to the west?

>>2353798
Just speculation but probably because mappers became a thing before it was (eventually) brought over. FDS was partially designed as a way of overcoming ROM size constraints with cartridges, but decreasing memory prices in combination with mappers sort-of obliviated the need for the FDS

Don't fucking TELL me to "Discuss" stuff you little bitch, fuck you.

I'm going to discuss the Dreamcast in this thread instead. What a great console the Dreamcast was.

>mfw my N64 boots faster than my television does.

Optical a shit. Cartridges are the main saving point of the N64.

>>2353798
Because Nintendo of America couldn't get a tight grip on floppy production like they could with ROM chips.
Unlicensed games were popular in Japan.

>>2353776
>The console would still have been this ass backwards machine that had to have games written in a very special way to work
The irony is that it's quite the opposite. The N64's hardware resembled modern consoles very closely. Developers weren't used yet to how 3D acceleration.

At the time they were more comfortable with the actual ass backwards way of just drawing polygons on the CPU and then texturing/rasterizing on a semi 2D affine mapping thing like on PS1 and Saturn.

>>2351068
bulky drive was a piece of shit.

however a cd format would have saved the system.

>>2354054
also it relied on "kiosks" that Nintendo would either have to install or pay someone else to.

>>2351140
Yes but, correct me if i am wrong, wasn't that great gpu caged inside a convulted architecture and most of its flexibility locked by nintendo not allowing devs to play with the micro code?

>>2353338
Leave luck to heaven

>>2356132
>wasn't that great gpu caged inside a convulted architecture
No. It was pure SGI architecture, very similar to popular 3D workstations. The difficulty in programming came from Nintendo trying to save money in a few areas which made the N64 allergic to unoptimized code (like using RAM with amazing bandwidth but awful latency).

>most of its flexibility locked by nintendo not allowing devs to play with the micro code?
It's not that they weren't allowed. It's that for the first few years Nintendo didn't tell anybody how. And even in the latter years when you did it, Nintendo would bounce your game unless the way you coded your microcode was to their liking (too many PS1 style polygon sorting issues and they'd bounce your game).

>>2353339
How is it idiotic? the typical VCD has more capacity than most, though not all Zip disks.

>>2356798
Do you even know what a VCD is?

>>2356203
Ok correct me if i am wrong again please.
As I understand it, latency is the time it takes from issuing an operation to completing it while bandwidth is the quantity of operations you can do on a given time frame. So, if the memory was a pipe the memory operations were the water flowing through it, latency would be the lenght and bandwith would be the width, right? Given that a high bandwith but with high latency scenario would be okay for pre-computed stuff (like racing games or rail shooters) but you'd be fucked for something more open world (you'd have to make the graphics a lot simpler). Am I right? How did that compare to the playstation and the saturn?

>>2356203 #
Ok correct me if i am wrong again please.
As I understand it, latency is the time it takes from issuing an operation to completing it while bandwidth is the quantity of operations you can do on a given time frame. So, if the memory was a pipe and the memory operations were the water flowing through it, latency would be the lenght and bandwith would be the diameter, right? Given a high bandwith but with high latency scenario, that would be okay for pre-computed stuff (like racing games or rail shooters) but you'd be fucked for something more open world (you'd have to make the graphics a lot simpler). Am I right? How did that compare to the playstation and the saturn?

>>2351085
I imagine it would've been much more popular in Japan (as it would presumably have more RPGs) and about the same in the rest of the world.

>>2351116
The 360 used DVDs for it's games, despite having an HD-DVD drive available.

>>2351145
I've heard that in Japan the Mega CD had a 1:4 attachment rate to the Mega Drive. But I think only Japan really accepts add-ons and expansions; others want all games fully compatible with the basic machine.

>>2353185
You mean be able to play VCDs? The Doctor V64 could as far as I know (the Chinese went ape for VCDs and almost nobody else) but Nintendo was terrified of piracy (think off all the famiclones and modded PSOnes) and tried to prevent it by using more expensive media.

>>2357207
The v64 can play VCDs. I honestly think the guy you're replying to doesn't know that a VCD is just a CD with video data on it though.

It would have been interesting to use that functionality in a game. Do the game as a ROM file but do all the cut scenes in FMV playing off the v64 MPEG chip. Similar to Lunar. Probably could have even done reasonable Dragons Lair type games using the same concept.
If only the Chinese could harness their powers of innovation for something other than making copies.

VCDs were huge all over Asia not just China. You can still buy them in shops in most countries here.

>>2357007
>As I understand it, latency is the time it takes from issuing an operation to completing it while bandwidth is the quantity of operations you can do on a given time frame
Not quite. Bandwidth is the time it takes from starting an operation to completing it, and latency is the time between random operations.

N64 RAM is extremely good (far superior to PS1, Saturn, even contemporary PC) at accessing a linear chain of memory, but is absolutely awful at accessing random blots of memory spread throughout the RAM. If developers don't actively defragment RAM to group bits of relevant memory together, the performance is terrible. The problem is, doing that in a real-time game is quite difficult without ending up with memory leaks and crap.

Your genre comparison is a little bit too hard to guess at, but I can say with absolute certainty that the N64 will be far better than PS1 and Saturn at open world games. N64 draws polygons with higher precision than PS1 and Saturn, which means that landscapes can be composed out of fewer polygons without assortments of glitches.

>>2358067
Thanks for the answer it is very interesting.
>latency is the time between random operations.
So, with higher bandwidth you process segments of memory faster and the time it takes to switch to another segment is the latency?
>If developers don't actively defragment RAM to group bits of relevant memory together, the performance is terrible.
Given that a console spec is static and retro games usually had its memory use layout strictly defined (i mean, devs decided in advance where everything went into the memory, there was no os and no dynamic allocation (unless they coded a mechanism for that)) is that really a big problem?
What other benefits do low latency have besides ease of software development and processing of undetermined data sets?

>>2358172
>So, with higher bandwidth you process segments of memory faster and the time it takes to switch to another segment is the latency?
Yes, that's pretty much right.

>had its memory use layout strictly defined (i mean, devs decided in advance where everything went into the memory, there was no os and no dynamic allocation (unless they coded a mechanism for that)) is that really a big problem?
It is, because while there will be an allotment in the memory for say, textures, the order within that allotment is important. When you wander around an open world different textures will get loaded/unloaded from memory. Ideally you want to have all of the textures to load in a frame to be linearly ordered in the RAM for best performance. That's kind of hard if things are constantly loaded/unloaded. I suppose if you had enough RAM to load everything at once (including doubles of data when necessary) it might help things, but that's not a feasible solution on a console.

>What other benefits do low latency have besides ease of software development and processing of undetermined data sets?
Threading. High latency can result in letting one thread hog the memory stream, while the other threads stall while they wait for their turn, since the random accesses are too costly to allow for interrupts.

>>2358193
Thanks again, sorry if I am overloading you with questions but this is very interesting.
>I can say with absolute certainty that the N64 will be far better than PS1 and Saturn at open world games. N64 draws polygons with higher precision than PS1 and Saturn, which means that landscapes can be composed out of fewer polygons without assortments of glitches.
>When you wander around an open world different textures will get loaded/unloaded from memory.
So imagine the landscapes are made with different low res skyboxes (different depending on the part of the world were the player is and maybe generated on the fly from various simple elements) on a supposed PSX/Saturn version of this supposed open world game (instead of actual geometry). Wouldn't the lower latency help in this case or would still the N64 version perform better?
(Anyway I suppose that apart from things relating to RAM the N64 would have a more seamless world while the PSX/Saturn could have a bigger on because of carts vs cds).
Thanks again for your answers.

>>2353338

>which they were on track to until earthquake and tsunamis destroyed all the chip fabs
Can you go more into detail on this point?
And if you can, can you talk about why the price of flash memory dropped so massively over the course of the last decade or so?

>>2358292
>Thanks again, sorry if I am overloading you with questions but this is very interesting.
No problem, happy to help.

>>2358292
>So imagine the landscapes are made with different low res skyboxes
I'm not quite sure what you mean by landscapes made from skyboxes since in my mind a skybox is what sits behind the actual landscape. But to try to answer your question anyway, on N64 and PS1 a skybox is comprised of large textured polygons. The Saturn has an extra option of using VDP2 to generate an actual background as a skybox, which is by far the least computationally expensive method of the three consoles.

As for N64 vs PS1, each have some advantages and disadvantages for the creation of a skybox. To put it simply, the N64 can only draw textures out of a cache, 4KB at a time (64x64 pixels), while the PS1 can draw textures straight out of VRAM and I don't think there's a size limit as long as the texture fits in VRAM. On the other hand, the PS1 has to subdivide the skybox polygon into smaller polygons to prevent coordinate errors, while the N64 can have one big polygon.

To put it simply, it's much easier to subdivide polygons than to stream texture tiles out of a texture cache from RAM with high latency. That doesn't necessarily mean the N64 has a gross performance disadvantage for this task, but it's just much harder to get it right over PS1.

>>2351097
Fuck you, I like carts. Waiting for tracks to load in F-Zero X, or levels in Mario 64, or what have you, would suck. That's the main reason I personally like the 64 better than the PS.

>>2358335
>I'm not quite sure what you mean by landscapes made from skyboxes
I mean having elements that are not that far in the skybox graphic instead of making them with geometry (unless you're quite close of course) and alter them according to the position of the player. The representation would be a bit inaccurate and would change in steps instead of seamlessly but you wouldn't have the polygon sorting artifacts (or at least not that much).
>the N64 can only draw textures out of a cache, 4KB at a time (64x64 pixels)
>To put it simply, it's much easier to subdivide polygons than to stream texture tiles out of a texture cache from RAM with high latency
I find those two to be a bit contradictory, I may be missing something. So the correct way of working with that would be having the textures in the most useful order possible in ram and then stream them in chunks of 4kb to the cache to draw them one at a time (then load the next chunk)? Doesn't this negate some of the benefits of high bandwidth? i mean, stopping every 4 kb and then moving the next chunk to the cache isn't as costly in terms of latency as jumping to another segment(even if the textures are next to eachother in ram)? Isn't 64*64 just the size of a small texture or two very small ones? Also, didn't the gs in the ps2 work more or less the same way?
>the PS1 has to subdivide the skybox polygon into smaller polygons to prevent coordinate errors
I read about that in the following link check it out
>http://phoboslab.org/wipeout/

By the way how comes you know so much about the subject?Did you develop for those consoles or are you just a hardware engineer or a hobbist with good knowledge?are you cold storage?I found him in some forums (sorry if i am getting personal no need to answer any of this)
Could you,in a nutshell list the general advantages and disadvantages of the PSX,Sat and N64 hardware architectures?
Thanks again for the quality info,as it is the best cure for fanboyism

>>2351068

Who knows.

It's hard to say whether or not it would have been successful. Historically, add ons have a pretty high failure rate financially.

Sega CD is the most notable success but even then add ons for consoles are always vanity type items.

The most recent example is the Kinect for 360. It came out so late in the systems life and thought it wasn't as intensive as something like the sega cd (using actual different media formats) it was a hard sell past the novelty of it because the motion control fad was already fading and most if not all the games for it barely worker correctly.

64DD probably would have suffered from similar issues. The potential is awesome, I've considered someday saving to get one just for the F-Zero expansion, I love that concept but the consumer market probably would not have allowed it to thrive

>>2358429
>I mean having elements that are not that far in the skybox graphic instead of making them with geometry (unless you're quite close of course) and alter them according to the position of the player. The representation would be a bit inaccurate and would change in steps instead of seamlessly but you wouldn't have the polygon sorting artifacts (or at least not that much).
Still not quite sure what you mean. Is there a game that does this that you could point to?
>Doesn't this negate some of the benefits of high bandwidth? i mean, stopping every 4 kb and then moving the next chunk to the cache isn't as costly in terms of latency as jumping to another segment(even if the textures are next to eachother in ram)?
The large latency penalty is for random access. Sequential read is a different story. You also have to remember that the texture cache has bandwidth that is far in excess of the RAM itself, so the RAM is not really stalling waiting for the next chunk. That being said, the system does ultimately have a bit of a texturing bottleneck, but the blame is spread evenly amongst the size of the texture cache, the latency of RAM, and the requirement that textures must be explicitly loaded from the texture cache. In theoretical terms, the system is better at texturing than PS1 and Saturn, but getting close to the peak performance is much tricker.

>Did you develop for those consoles or are you just a hardware engineer or a hobbist with good knowledge?
When it comes to this mostly a hobbyist, though I have an understanding 3D graphics programming. I've also conversed with people that developed games for 5th generation consoles.

>>2358465
>Could you,in a nutshell list the general advantages and disadvantages of the PSX,Sat and N64 hardware architectures?
Saturn
+Advantages over PS1 for 2D games reliant on backgrounds and more RAM
+Unlike PS1 can actually generate a couple of perspective correct textured polygons (with VDP2)
+More "general" (non-vertex) processing power over PS1
-VDP1 is an inefficient 3D chip, and particularly flawed at transparencies with rampant overdraw
-VDP2 usefulness in 3D games usually requires extreme technical creativity, otherwise sits there useless
-Twin SH2s + DSP can't match PS1's GTE for vertex transform
-Too many processors means too much stalling with unoptimized code as processors wait for each other negating their usefulness
-Slow RAM (though there's more of it)

PS1
+GPU (texturer/rasterizer) is fast at 3D, fast at 2D - it just works, nice and efficient
+GTE co-processor is very powerful at vertex transforms
+RAM is divided into two pools, with one set CPU-friendly and the other set GPU-friendly (VRAM)
-3D tends to be look messier than Saturn (unsure whether this is because of lesser fixed point maths precision or that Saturn's quads are just less affected by imprecision)
-No possibly of perspective correct texture mapping, GPU literally cannot accept parameters to make it happen
-Less RAM than other consoles

N64
+Raw power up the wazoo, CPU is more powerful than the others, RSP is more powerful than PS1's GTE, RDP is more powerful than PS1's GPU
+Extremely comprehensive hardware 3D feature-set
+Unified RAM offers some flexibility, and bandwidth is great
+T&L is very programmable with microcodes, unlike the fixed units of the other consoles
+Better alpha blending thanks to flexible color register combiners
-Terrible RAM latency, main cause of programmer headache
-Textures can only be loaded from texture cache, considering that requirement it should have been bigger
-Sound has no dedicated chip, must be processed on either CPU or RSP
-CPU doesn't have DMA

>>2358497
Should also mention that the number of positives or negatives is not indicative of anything. Some negatives are worse than others. Some positives are better than others.

An infographic comparing all the most important aspects of the 5th gen systems hardwarewise was posted here a couple months ago. Anyone got it?

>>2358504
Not sure how right it all is but here you go.

>>2358505
I only learned that the Saturn theoretically can do FM audio recently. Are there any games that actually do this?

I know that in general, when there's a Saturn and Playstation game, the Saturn version has better music, but I've never heard it doing FM.

Also, that graph does a good job explaining why the Saturn is "better at 2d". It isn't, really. Just that it gets free background layers and can do ports of then popular arcade fighters better.

>>2358497
Thank you very much for taking the request man, really appreciated.
>>2358505
This is also cool, saving it.

>+Unlike PS1 can actually generate a couple of perspective correct textured polygons (with VDP2)
>-VDP2 usefulness in 3D games usually requires extreme technical creativity, otherwise sits there useless
How can the VDP2 help with perspective correctness if it's for backgrounds? Does it involve drawing the texture with the correct perspective on VDP2 and then have a polygon on VDP1 that's like a hole to what is shown in the background (and I suppose repeat that for every polygon, but wouldn't that be very computationally expensive?)?
>particularly flawed at transparencies with rampant overdraw
wasn't that a hardware bug (i heard somewhere) or was it just bad design? I've seen (mostly in videos tho) that most games do transparencies by having a grid pattern (with one pixel "on" and another "off", interleaved) on whatever that has to be transparent. It is very evident on flat panels but I suppose it worked Okay on CRTs. But Sonic R does real transparencies (even while the draw distance is very bad), what's going on there?
Also, how was the DSP useful? Even if it wasn't as powerful as the GTE you could aid 3d calculations with it, right? what else could you do?

>+RAM is divided into two pools, with one set CPU-friendly and the other set GPU-friendly (VRAM)
Is it latency vs bandwith again? (lower latency for CPU and higher bandwith for GPU)
>+GTE co-processor is very powerful at vertex transforms
Also, I read somewhere that another advantage the PSX had was very high fillrate and polygon throughput, is that implied on this plus point?Or didn't you list it because
>RSP is more powerful than PS1's GTE, RDP is more powerful than PS1's GPU
this?

>+T&L is very programmable with microcodes, unlike the fixed units of the other consoles
does it mean vertex shader kind of stuff (waves, models changing shapes...) or could you program more stuff?

>>2358438
>Sega CD is the most notable success
0/pleasebetroll

I'd hold off on buying a 64DD at this point. Right now there's major progress being made understanding how it works. Even if you're a collectorfag wait for the price to drop because of flash carts.

>>2359159
How is he trolling? The Sega CD wasn't the failure that people seem to think it was. It's unfairly lumped together with the 32X.

>>2359238
It really was. Not nearly as many games were made for it as you'd think (cheaper to make) because the install base was so low compared to the Genesis.

>>2358901
>How can the VDP2 help with perspective correctness if it's for backgrounds? Does it involve drawing the texture with the correct perspective on VDP2 and then have a polygon on VDP1 that's like a hole to what is shown in the background (and I suppose repeat that for every polygon, but wouldn't that be very computationally expensive?)?
No, VDP2 can draw two backgrounds rotated into 3D space with perspective correct texture tiles mapped on them.

>wasn't that a hardware bug (i heard somewhere) or was it just bad design?
A little bit of both. Overdraw was the issue. It both botches transparency and wastes valuable drawing time.

> But Sonic R does real transparencies (even while the draw distance is very bad), what's going on there?
Saturn can do true transparency with VDP2, but I'm not sure of Sonic R's technique, whether it is true transparency or cleverly disguised fake transparency.

>Also, how was the DSP useful? Even if it wasn't as powerful as the GTE you could aid 3d calculations with it, right? what else could you do?
It could calculate vertex transforms, but being just another chip in the Saturn pipeline it was hard to use it properly without stalling something else. It was fixed function, so it couldn't do anything else.

>Is it latency vs bandwith again? (lower latency for CPU and higher bandwith for GPU)
Pretty much

>Also, I read somewhere that another advantage the PSX had was very high fillrate and polygon throughput, is that implied on this plus point?Or didn't you list it because
The fillrate is part of the PS1's GPU (the texturer/rasterizer). Polygon throughput is reliant on the GTE and the GPU. PS1 was very competent at both. The N64 parts had 18 months of improvements and were better (though the N64's throughput was directly affected by microcodes).

>does it mean vertex shader kind of stuff (waves, models changing shapes...) or could you program more stuff?
Mostly vertex shader stuff. But extremely flexible.

>>2352597
some developers (notably Acclaim/Iguana) used V64s for development instead of the official development kits because they were significantly cheaper and the official kits were in short supply

>>2353798
piracy.

>>2357649
VCDs were big in Asia because VHS tapes didn't do very well in humid environments.

Sony even released a PS1 for the Asian market with a built-in MPEG1 decoder to play VCDs, and pirate manufacturers released add-on decoders that plugged into the I/O port (my family had one of these)

>>2351068
It would have finally opened the door for Micazako to do what he wanted to do way back in the Hizaki days. It would have meant a vectrex level of operable software on an inferior but cool gimmick.

>>2353839
Fuck the Dreamcast, Saturn is better.

>>2353859
I would personally take more games and better textures over loading times.

>>2359725

Dreamcast wasn't bad enough to kill sega.

>>2359726
Have you read this thread? Cartridges have little to do with textures.

>>2359445
As far as I know no Sony games used the MPEG functions which is completely retarded.

>>2359740