Nice and dismissive. Why don't you explain what you take issue with? Or are we just going to constantly post random saturn videos?Quote:
Originally Posted by Thief
Printable View
Nice and dismissive. Why don't you explain what you take issue with? Or are we just going to constantly post random saturn videos?Quote:
Originally Posted by Thief
Might as well quote this for tomaitheous, since I have no idea how he missed this...Quote:
Originally Posted by TrekkiesUnite118
According to Sega Retro the total fill rate of the system is 57.2728 million pixels/sec with 28.6364 million of that coming from VDP1 supposedly. So I'd imagine the remainder is coming from VDP2. How accurate those numbers are though I don't know.
The main advantage would be for any game that could use it for floors or ceilings or both. That would save significant polygons, which you can see in games on both systems where the Saturn port takes advantage of VDP2:
Notice how the PS1 is struggling in the draw distance of the alien ship while the Saturn has pretty much infinite draw distance. Also there's Mass Destruction running at double the frame rate on the Saturn over the PS1 due to it using VDP1. That would imply the fill rate is higher when making use of VPD2. Grandia runs a lot choppier on the PS1 over the Saturn, and a lot of details like shadows and what not that were done by VDP1 are missing on the PS1 port. And I think there's an interview floating around with Traveler's Tales explaining that the PS1 wouldn't be able to handle Sonic R because of the use of VDP2.
Basically on the PS1 or on a Saturn without VDP2 you would probably need to use a mesh of polygons to replicate that. I don't know if a really large polygon would be able to pull it off as well.
And tell me, you know for a fact that the deciding difference in frame rate of those two ports, is the VDP2? I could easily post SOTN, where the saturn version is slowing down. I don't want anecdotal evidence. You think I can't look a some videos and draw a simple and similar conclusion?Quote:
Originally Posted by Thief
I want numbers, I want specifics. Simple answers are for children. If you're happy with that, then fine. I want to know the specifics and case significant scenarios.
Btw, that game is 2D. Having a small handful of simple polygons as buildings and what not, sprinkled around in the scene, does not a 3D game make.
I think there's an interview with the developer actually confirming this. The game is 3D. The buildings, tanks, etc. are all 3D. On the PS1 the ground is done using polygons as well.Quote:
Originally Posted by tomaitheous
EDIT:
Found it, it was posted as a comment on one of the youtube videos about it:
https://www.youtube.com/watch?v=sNL07BtCWUw
Now how true this is I don't know, it is from a youtube video after all. But it seems to match up when we compare the games in emulators.Quote:
Hi, someone sent me a link to this, and I just thought I'd point out your comment about the game running at a solid 30 fps is slightly off. I wrote the Saturn version, and it ran at a constant 60 fps. The PSX version could only manage 30 fps though.
The Saturn version got the extra performance from having some custom hardware that really helped that particular game. The terrain was displayed much like Mode7 on the SNES, ie a scroll screen that could have a perspective transformation to display it at the correct viewpoint to match the polygonal display drawn over it. It wasn't tiled by the hardware though, I used the bitmap mode, and dumped the tile data in 2 strips, to update the horizontal and vertical edges. Since the scroll screen wrapped round in both directions, it gave a seamless scrolling landscape.
The PSX had to draw the terrain as a grid of polygons, and so was forced to run at 30 fps due to the limited rendering power of that console generation. Without the scroll screen hardware, the Saturn version would also have been stuck at that frame rate.
The game was written almost completely in C, with a few SH2 assembler functions to handle the update of the scroll screen data in the vertical blank. This was the first game I'd written in C at that point, everything prior I'd done in assembler. I used the SGL libraries, as these were far more capable than the SBL libs that were initially available.
The Saturn hardware also allowed me to have parts of the scene reflected in the water, by drawing the reflected geometry inverted and using various priority/blending settings in VDP2 to combine the frame buffer and scroll screens.
As for programming the Saturn now, I'm sure you'd find the stuff available on the web will cover any of it admirably.
This was my only Saturn game, after that I moved on to various crappy projects on the PSX, and then PC.
What? You want me to take up learning how to program a Sega Saturn for something that explains itself? As if.Quote:
Originally Posted by tomaitheous
But I will post another random YouTube video, thank you.
https://www.youtube.com/watch?v=f_OchOV_WDg
You are sorting of asking the impossible really since you aren't going to get polygon numbers, more so from Sega games as Sega never liked to talk polygon numbers in much detail . All one can do is look at the games and any Saturn games that used the VDP 2 for the floors or the skies took a huge work load off the VDP 1 and then it was a effect that the PS had issues with as anyone who played both versions of Thunder Force V, Street Racer and Mass Destruction could see and if one looks at the floor draw distance in the likes of Omega Boost compared to Zwei or Tekken 3 compared to Fighters Megmix can see a easy win for the VDP2 and all with none of the polygon folding that would got with either the PS or even when the VDP 1 on the Saturn had to draw the floor or sky .Quote:
Originally Posted by tomaitheous
Seriously Thief?:
http://i102.photobucket.com/albums/m...ps1vrs7xxo.png
Don't send me snarky and insulting comments about people I have the utmost respect for around these forums.
^ Gee, I thought a PM response instead of a post for everybody to see would of been less offensive. But, whatever. (PS. I can't spell his name. So sue me if I shortened it) (PPS. And it's not like he can spell my name either)
SOTN is not a 2D game and there's not many parts in that game where the VDP 2 Could be used to better the PS, plus of course the PS version was the lead , But if you want some Examples play both versions of street Racer and see the Saturn handle effects no in the ps version thanks to the VDP 2 .play Thunder Force V level 3 and see the PS failing to handle the VDP 2 floor with its effects draw distance and also the PS floor has issues with polygon folding as wellQuote:
Originally Posted by tomaitheous
SotN on the Saturn is 2D and is using VDP2 for background layers. However I think it's using VDP1 for some of the background layers as well.
It's not a true 100% 2d game there are 3D polygons effects and parts to the game and that's when the Saturn would have issues with transparent effects and what not , never mind issues of having a different team handle the port and coming up a little bit shortQuote:
Originally Posted by TrekkiesUnite118
Isn't SotN a sloppy copy and paste port instead of the devs taking the extra time, as was normal, to program it to the Saturn's strengths? I mean, there's no excuse for SotN to be the way it is on Saturn.
Also, explains why Maria has way less slowdown since she was programmed from the ground up on the Saturn, thus more optimized.
The worst slowdown in the game is in parts where there's no 3D objects, just butt loads of sprites. And ironically the parts that use true transparency seem to run fine:Quote:
Originally Posted by Team Andromeda
I don't know where I read it, but someone basically seen that they just copy and pasted most of the code from PS1 to Saturn, instead of doing any optimizing. So yeah, of course it's going so suffer lots of performance with lame effort such as this.
If that was the case it would be doing everything on VDP1 as if I remember correctly the PS1 did it all as polygons. The fact background layers are broken down into VDP2 layers and it is making use of true transparency when it can tells me it wasn't just a simple sloppy port.
I think what's going on here is that SotN has more layers of parallax that even VDP2 can't handle all of it in parts, so in those areas VPD1 has to handle it on top of the large sprites, lots of animation, etc. The PS1 though is able to run it in a lower resolution, and the Saturn is running in a higher resolution while unevenly scaling everything up, which I would imagine is a relatively costly operation to do on everything. It would be interesting to see how the game could run if it was simply windowed or had expanded draw distance on either sides.
This has been an issue in this thread and in recent Sega-16 technical discussions in general. It seems to be a mounting trend.Quote:
Originally Posted by tomaitheous
People want to argue but they come with empty hands and strongly narrow minded.
It's weird and annoying at the same time. And ultimately sad because this kind of attitude in technical discussions (even if shallow ones) is like a cancer for knowledge creation because instead of refining thoughts it leads to misconceptions and the spread of myths and inaccurate statements.
To me it's a very negative sign that people can't even do a honest visual inspection anymore when talking about graphics. That's the first step into the investigation process when you want to come from a more easy-to-read perspective; if you completely screw up that part then everything else will go downhill from there.
With that said, the VDP2 argument needs to be reset to a more realistic proportion and a more detailed context IMO.
I'd start trying to find minded answers to the following questions:
- Is the VDP2 extensively usable in all kinds of 3D games?
- In the 3D games where the VDP2 plays an important role, does the Saturn have the graphical edge when compared to similar games released for PS1/N64?
- How technically impressive are the best looking Saturn 3D games which do good use of the VDP2?
- Which kinds of graphical effects the VDP2 can provide to 3D games?
- Which conditions have to be set in order to take the most out of the VDP2 for 3D games? Such conditions result in gameplay limitations? If yes, to what extent?
- For the graphical effects the VDP2 can pull off and which are useful in 3D games, what's the cost of them (be it cycles, memory, bus usage, etc)? How its performance on executing such effects compare to the same/equivalent effects when performed with the PS1's and N64's hardware?
No doubt there are areas the team could and should have done better . But it was a game lead on the PS so that was never going to help matters , but yeah for sure it wasn't made as well as it could .Quote:
Originally Posted by TrekkiesUnite118
Obvious answer here is no. Racers would really need to have their tracks designed in a way to make use of it. And we'd either end up with a completely flat track or you would need to do something like what Sonic R does. Games that don't have a lot of flat terrain or a large flat section wouldn't really work either.Quote:
Originally Posted by Barone
I'd say yes. In Thunder Force V a lot of details are missing on the PS1 port. Grandia runs choppier on the PS1 from what I remember, and all the shadows are missing. Dead or Alive has a significantly worse stage draw distance as do a lot of 3D Fighters on the PS1. And then there's games like Mass Destruction that run better on the Saturn. So I'd say yes for game where VDP2 can play an important role it does give the Saturn an edge, simply because it reduces the load on VDP1.Quote:
Originally Posted by Barone
Depends how you define technically impressive. I'd say Radiant Silvergun and the 3D Fighters look pretty impressive, as do Sonic R and Sonic Jam.Quote:
Originally Posted by Barone
The rotating planes can provide floors or ceilings, or can be used as a base level for a multi-level stage as Sonic Jam shows. It could also be used for transparency effects, limited pseudo-multitexturing effects (Sonic R does this), and then there's always the way Burning Rangers handles it's transparencies.Quote:
Originally Posted by Barone
I'd say it would have more of a limit on level design than gameplay, though that would only be if you were using the rotating planes. Basically you'd need to design your levels in a way that could make the most use of those planes to allow you to use polygons for more important things. So for example a game like Mario 64 and possibly even some areas in Ocarina of Time and Majora's Mask could probably make some good use of it in a lot of it's stages, while a game with much more complex geometry in it's terrain probably wouldn't be able to make use of it.Quote:
Originally Posted by Barone
The transparency and blending effects I wouldn't imagine having much impact on gameplay though.
I'd imagine it would depend what we are talking about. The rotating planes from what I understand are basically no cost in performance. But you do lose some scrolling layers if I remember correctly. Transparency and blending depends on what's being done I think. Simple things like drawing a transparent layer over the screen like Quake does, or the clever layering Sonic R uses I wouldn't imagine would be that performance heavy. Stuff like what Burning Rangers does though has an obvious impact on performance.Quote:
Originally Posted by Barone
I understand that. The idea is to setup similar case scenarios, in which you can calculate an estimate of pixel fill rate, transform rate, etc. There were quite a few homebrewers in both PS and Saturn dev scene that could probably do this. And again, the range could run the gamut. Poor code, or design, vs proficient code/design. But it would still be nice to get an idea, number wise and scenario wise, how effective the VDC2 and how much of a number of impact it has between the two systems (obviously it has an impact on the Saturn itself).Quote:
Originally Posted by Team Andromeda
That's my point though; SOTN should have been much better than it was. The vast majority of the game engine is 2D, and the Saturn does excel at 2D stuff more so than the PS.Quote:
Originally Posted by Team Andromeda
Lol! He's a fool.Quote:
Originally Posted by TrekkiesUnite118
The PS has a "sprite" mode where the paired triangles are setup like a traditional sprite. It's also faster to process them on the PS, than full polygons (to emulate sprites).Quote:
If that was the case it would be doing everything on VDP1 as if I remember correctly the PS1 did it all as polygons.
But this whole SOTN thing is missing the point. It was just an example to where someone could point to a video and say, "look here, this proves this!".
People come to these technical discussions with preconceptions, which is fine, but you would think people would want to get to the truth of all matters. But what I see is people defending their preconformed idea instead of trying to objectively look at things. People are so emotionally attached to these systems, that anything said in negative light is perceived as an attack against something sacred to them - their core beliefs. I've never been one to be happy with simple answers, as far back as I can remember, because they're never accurately or truly representative in explanation, and understanding things. People, in general, just seem to be happy with prepackaged answers to everything - never bothering to dig deeper, to look for themselves. To actually try and make sense of things. This is probably the biggest disconnect I have with human species.Quote:
It's weird and annoying at the same time. And ultimately sad because this kind of attitude in technical discussions (even if shallow ones) is like a cancer for knowledge creation because instead of refining thoughts it leads to misconceptions and the spread of myths and inaccurate statements.
I like technical answers as well, and if they blow away my preconceived notions so be it. I think the issue I have is sometimes some of those responses are either too technical that if you're not a hardware engineer or an assembly programmer you easily get lost, or they're just too long and don't really get down to the point. Which is why I really appreciate the answers that come from Tom, Chilly, Tiido, and Kamahl. You guys are pretty good at explaining stuff but keeping it concise and easy to follow and understand.
The VDP2 is a strange beast. It has its own VRAM, along with using shared memory.
http://segaretro.org/VDP2_32-bit_bac...play_processor
Notice the part about the Saturn being able to do progressive scan at 480p.Quote:
Originally Posted by segaretro
Iron Storm is a good example of VDP2 being used to layer transparent weather effects over what VDP1 is doing.
Skip ahead to about the 1 hour and 16 minute mark to see the transparent clouds being shown.
I did notice that the Saturn has some nice texture smoothing going on with the ground textures. I was kind of surprised to see that, considering that the Playstation usually has better texture quality.Quote:
Originally Posted by tomaitheous
No not all for a Game like Sega Rally the VDP 1 is having to go most of the work.Quote:
I'd start trying to find minded answers to the following questions:
- Is the VDP2 extensively usable in all kinds of 3D games?
-Play Mass Destruction and see thanks to the VDP 2 reflection effects with the flame thrower on the water . Play Granda and see better water effects , play Street racer as not only see a better draw distance on the floor, but reflection effects and a 3D scrolling sky and Thunder Force V floor effects just aren't in the PS version at all and any time the VDP 2 was used it had zero polygon folding.Quote:
In the 3D games where the VDP2 plays an important role, does the Saturn have the graphical edge when compared to similar games released for PS1/N64?
Wasn't that was so great about the VDP 2 in that even if you used it it had zero impact on the VDP2 or any impact on the 2 CPUs .Quote:
- Which conditions have to be set in order to take the most out of the VDP2 for 3D games? Such conditions result in gameplay limitations? If yes, to what extent?
[ Which kinds of graphical effects the VDP2 can provide to 3D games [/QUOTE]
http://youtu.be/JaKU_Q2eWqU
http://youtu.be/2rOUVgl8BKE
Grandia does the transparency layer as well:
Though again Sonic R is a game that takes this to the extreme in Radiant Emerald. Radiant Emerald is basically doing the following:
VDP1 draws the track and characters, but sets priority on the track as the lowest layer and the characters as the highest layer.
VDP2 takes the track and draws it first.
VDP2 then draws the HUD.
VDP2 then draws a transparent layer (possibly a rotating plane?) with a tiled image over top the track and HUD to give the shimmer effect.
VDP2 then draws the outer space background image overtop everything it has drawn so far as 50/50 transparency.
VDP2 finally draws the characters overtop that.
This is why we have the following oddities in the track.
You can see the background through the track but not other parts of the track or see characters through parts of the track ahead of or above you.
The shimmer effect is applied to everything, including the Ring doors, speed booster, and the HUD.
Get that from time to time . The Mega Drive version of Smash TV wasn't half as good as the Snes and yet it was the Snes meant not to able to handle a game with loads of sprites on the screen . In the Hunt was another 2d game far better on the PS.Quote:
was. The vast majority of the game engine is 2D, and the Saturn does exce
If I remember correctly VDP2 does have a blur feature. That might be what's going on there. I've noticed something similar in other games like Digital Dance Mix.Quote:
Originally Posted by gamevet
Whatever makes you feel better.Quote:
Originally Posted by tomaitheous
But you guys are still way overcomplicating what I started. But if you guys want to go on and write pages about it, go ahead, be my guest. Both Trek and Andromeda got what I said from the get go, and I'm fine enough with that.
No... This thread is drying again... well, here's something to that you guys can overanalyze;
Remember that first town in Grandia? Well, I'm curious if there could be a possibility on the Saturn version having it's entire floor made of one background layer & for the sky one skyline background layer to actually = to saving up on RAM or something? Because on the PS1 the town is split in two via a loading screen (the 2 bridges going over the river). So, can anyone think of why this is/could be, or is it just poor optimizing? As this still contributes to the "large 3D worlds" chit chat we're having since the PS1 version curiously effectively chopped this massively detailed 3D town in half.
EDIT - oh wait, the Saturn has more RAM too, so.... nvm?
https://boards.openpandora.org/topic...comment=402824Quote:
They had different strengths and weaknesses.
PS1 was just better designed for 3D. It had a coprocessor dedicated to geometry transformation and lighting calculations. In theory Saturn had a DSP meant for this purpose, but in practice it was a poor fit for it and thus games didn't use it. Instead 3D games had to use one of the two SH2 cores for this purpose and even with an entire core dedicated to this purpose they would still struggle to get comparable throughput to what PS1 games could accomplish. Which is probably why most 3D Saturn games don't bother with lighting at all even though the VDP1 chip supported gouraud shading (in a kind of crappy form), because it was one less set of per-vertex calculation the CPU had to do.
VDP1 was also not really that well thought out for 3D. Sprites are a lot more restrictive for meshing than triangles, they don't lend themselves well to tessellation or clipping, and Saturn's implementation causes internal overdraw which both wastes fillrate and breaks blending. It also lacks the higher internal resolution + dithering and uses a lower precision additive gouraud shading instead of multiplicative. And because the framebuffer and textures are in different RAMs there are various render-to-texture effects it can't do, at least not without a huge efficiency hit. On the other hand, Saturn's sprites didn't warp as badly in perspective as PS1's affine triangles did.
Saturn may have more total VRAM, like this article points out, but stating that alone is misleading. What it has is 512KB of framebuffer memory, 512KB of VDP1 memory, and 512KB of VDP2 memory. Since normal framebuffer configurations don't use nearly the entire 256KB some of the framebuffer RAM gets wasted. Some of the VDP1 memory gets wasted by requiring display lists to be stored there, in a very inefficient format requiring 32 bytes for every command even if they don't need nearly that much and the gouraud shading tables aren't even stored with the commands (another possible reason why it isn't used a lot). And there isn't really a useful 8bpp paletted mode, which is fairly commonly used on PS1, so some gets wasted there. As for VDP2, well it's only useful for as much as the game can use it, which is for 2D stuff plus one projected plane. So all told, it's hard to say that Saturn's VRAM configuration is always better than PS1's unified 1MB.
That VDP2 plane can be a big asset. I would go so far as to say that it's pretty much the only thing which gave 3D Saturn games a fighting shot against PS1. That and the 8bpp mode which resulted in some unshaded/very flat looking but high resolution fighting games. And for 2D games VDP2 is just largely advantageous in general.
https://boards.openpandora.org/topic...comment=402849Quote:
I used to a be a games programmer back in those days (1997 - 2000) and spent most of my time on the PSX. I helped out the Saturn guy a bit with the PSX port and the thing that struck me most was how much better Sony's libraries were than Sega's. You needed like a page and half of initialisation on the Saturn and it had to be in the right order otherwise the machine would lock-up. The PSX in comparison needed about five lines or so.
Although the PSX framerate suffered with layered transparencies, it could at least do them. I think with the Saturn it was nigh on impossible to do so and if it was, there were dire performance consequences, which falls in with Exophase's point about texture ram and framebuffer occupying different memory locations.
Also, nobody I knew ever programmed either system in C++. The code was C as it was simpler and easier on memory requirements (you only had 2mb remember on PSX) and exception handling was a performance drain, especially on the PSX where memory access (even reads) were slow. The two outstanding engine/core programmer guys I worked with in that time (I was the low-level subsystem, peripherals guy, with odds 'n sods like game camera, some game AI and menus and game-state transition handling code), got the game to a near mature state then converted the main rendering loop to R3000. The rest stayed in C.
BTW, if you ever want to compare the two, take a look at the Saturn and PSX versions of Tomb Raider side-by-side. The Saturn one I believe came out first (and Core weren't slouches when it came to the Saturn) and whilst both systems framerates chug a bit, the framerate and general fidelity of the PSX is higher. Tomb Raider II didn't come out on Saturn (system was all but dead for non-Sega support), but if you compare side-by-side you'll see a massive performance increase in framerate over TR1, whilst poly counts were up.
https://boards.openpandora.org/topic...comment=402980Quote:
Yeah, I don't think C++ was very commonly used for console code in this era. With PS1 and Saturn I'd more say that a lot of them were moving away from pure assembly language for the first time, and like you say there was still a fair bit of that too. But it's interesting to note that at least some GBA games were using C++ despite being very RAM restricted (with the addition of code and constant data accessed directly from cartridge ROM). At least one GBA game, Mother 3, was obviously done with C++; the this pointers and setter/getter functions are pretty blatant.
On the topic of main RAM, Saturn had 2MB of it like PS1, but it consisted of two 1MB chunks in completely different sections of the address space. Leading me to believe that they added the second 1MB late in the design process. This may have been a more subtle impediment to design. Unless you had many small allocations you would struggle to fill up the first 1MB without wasting space, and larger allocations are preferable for many things.
On the other hand, PS1 made you use a tiny 1KB scratchpad RAM for data reads or be subject to main RAM access times, while Saturn had a unified cache that worked with both code and data. So more care was necessary to allocate the most critical items in that scratchpad.
https://boards.openpandora.org/topic...comment=402980Quote:
Yeah, we stuck the stack in the scratchpad, got a crazy speedup like 10 or 15%. Of course I had to do a mass of stack depth checking (i.e builds that monitored stack depth after testers had been through the game in multiple modes several times in a single sitting) before we left it in there.
https://forum.beyond3d.com/posts/1827968/Quote:
Saturn used rectangles, and could have drawn them perspective correct w/o Z data, but it didn't, because it's not free. Especially if you have to derive the depth from the distortion of the sprite. It'd make more sense to just take some form of depth data.
There was less distortion than with triangles, though. For instance, a ground plane projected towards the horizon would at least compress in the X axis. Just not in the Y axis.
But Saturn's rendering approach had a bunch of other problems.
Exophase, Feb 27, 2015
https://forum.beyond3d.com/posts/923225/Quote:
remember it all to well. In fact, I still have that disc somewhere....
I believe the Dinosaur used some sort of animation technology .... "mime"? Early on it was supposed to be a big deal on PS1. It could deform models smoothly and looked cool. Polyphony used it for Motortoon GP. After awhile the technique was abandoned for some reason.
Crayon, Feb 4, 2007
https://forum.beyond3d.com/posts/923284/Quote:
T-Rex demo
I didn't write the T-Rex demo itself, but at Sony I wrote the demo disc that the T-Rex demo is running inside in this movie. I had the source for the T-Rex demo and the assets... (and the manta ray, and various other Sony tech demos). That set of demos were around in 94 pre-Japanese launch and were used to persuade developers that the machine was worth developing for.
I demoed the T-Rex thing to developers at ECTS in 94 (well Sony's offsite thing) and many of the developers insisted on pulling the composite cables out of the console to check it was not coming out of some PC behind the scenes ;-)
I gotta say I can't remember what resolution it was, its so long ago! It was one of the higher ones which used too much VRAM to be commonly used in games, anyway - 512x480 maybe, but thats a guess.
Someone mentioned the MIMe technique, this was a bit spin based really, it was just that the GTE could do fast interpolation between vertices and so morph target animation was a reasonably quick thing to do.
Someone said the GTE was a floating point coprocessor - not true, PS1 had no FPU and the GTE was fixed point. The R3000A was severely cut down.
And yes, you couldn't see the texture distortion as it had a pile of tris so the linear interpolation wasn't so visible, and especially not on a stretching skin. You really did tend to see it in things like roads or buildings made out of very few polys.
Al
cullenskink, Jun 21, 2007
Quote:
"The hardware was super-strong and relatively well balanced. The SPU audio processing was amazing for its time. The GTE was very powerful once we figured out how to access it at the low-level. Memory size was a challenge but nothing unusual for the day," Mallinson notes.
http://www.eurogamer.net/articles/di...ing-of-wipeoutQuote:
"On the 3D programming side, we had to start from scratch. The first libraries shipped from Tokyo were too high level and so we had to do a little reverse engineering to get the maximum performance from the GTE."
About clipping:
https://forum.beyond3d.com/posts/1824447/Quote:
PS1 had a bit of a guard band and the GTE computed some flags to help detect polygons that went outside of it (or depth frustum) and needed to be clipped.
Saturn had the worst clipping problems of all. You couldn't tessellate textured polygons against the clip boundary if you wanted to, thanks to textures all being rectangular sprites - so good luck if any vertexes do fall outside the guard band And it has very limited ability to avoid processing pixels that go outside the draw area. Here I do remember frequently seeing polygons disappear against the near plane and sometimes worse.
Exophase, Feb 11, 2015
About the lack of sub-pixel accuracy:
https://forum.beyond3d.com/posts/1825474/Quote:
Not like Saturn had sub-pixel precision either. Actually I think it was even worse because of the way the lines were overdrawn and overlapped internally. Skinning was really bad because the quads were textured with sprites instead of arbitrary quads.
Exophase, Feb 17, 2015
http://psx.rules.org/gte.txtQuote:
This document is a collection of all info on the GTE i could find and my
own notes. Most of this is the result of experiment, so not all info might
be correct. This document is most probably not complete, and not all
capabilities and quirks of the GTE are documented. No responsibility is
taken for anything that might occur using the information in this document.
https://forum.beyond3d.com/posts/39885/Quote:
How did Banjo-Kazooie have such beatiful textures in only 4kilobytes? Does anybody have any guesses on how they did that
n64, Nov 2, 2002
https://forum.beyond3d.com/posts/39889/Quote:
Same way anyone else would. No miracles I'm afraid.
4K just means no individual texture can exceed 4K and if your using Trilinear it's actually effectively 2K. Nothing stops you loading it over and over other than bandwidth.
Banjo does use 2 texture layers for a lot of the ground modulated with vertex alpha channels which does make it look a lot more varied than some other N64 titles.
My understanding is that Rare had micro code access well before anyone else. They used it for some custom lighting code, if I remember what I was told correctly, and in fact what I was told was accurate.
ERP, Nov 2, 2002
https://forum.beyond3d.com/posts/39892/Quote:
The playstation textured from a large texture page, of which you could draw from a 256x256 sub-page. There was a cache of sorts used after the page, but it wasn't explicitly loaded basically if my memory serves me correctly if a row was >32 pixels there was a performance penalty.
ERP, Nov 2, 2002
https://forum.beyond3d.com/posts/39894/Quote:
So were the Banjo games and BFD doing multi-texturing or did I misread the posts ?
The N64 would seem to have the fillrate for it but could it blend efficiently enough to make that possible - and could it do 2 textures in one pass (a must presumably given the relatively weak triangle rate?)
Did you effectively lose 2k of tmem even with just bilinear filtering? Could point sampling improve fillrate performance much?
Roly, Nov 2, 2002
https://forum.beyond3d.com/posts/39897/Quote:
Banjo does, Ive never bothered playing BFD so I can't comment there.
In real terms N64's fillrate was comparable to that of PS it didn't really have a big advantage. Most N64 titles woluld either have been fill bound or more likely CPU bound. Cache size and RAM latency were such that unless data and code were extremly carefully organised CPU performance would be very poor.
No basically, Trilinear requires you to read from two different MIP levels simultaneously. In order to accomplish this you have to split the texture cache in half, and have one MIP level in each half, so you end up with the largest MIP level limited to 4K/2 = 2K.
ERP, Nov 2, 2002
https://forum.beyond3d.com/posts/1102657/Quote:
Are there any games on the PS1 more technically impressive than MGS?
PSman, Dec 4, 2007
https://forum.beyond3d.com/posts/1102664/Quote:
Count my votes for Gran Tourismo 1 and Ridge Racer 4 (I think that was the last PS1 one)
Gran Tourismo for the combination of the physics on the crappy CPU and the decent visuals.
RR4 just for the visuals, it had almost none of the trademark PS1 graphics issues.
ERP, Dec 5, 2007
Quote:
Why did GPUs abandon quads in favour of triangles
https://forum.beyond3d.com/posts/1813181/Quote:
Triangles are preferable because setting up interpolation gradients is straightforward. Because the interpolation is linear in unprojected space the gradients are constant for the triangle. And there's only one way to interpolate, so the result is never unexpected. It also means the polygons are always convex which avoids complications or unexpected results in rasterization.
Nintendo DS supports quads natively (and higher order polygons, if they get clipped). It does this by doing two-fold linear interpolation, where it interpolates top to bottom then left to right for every scanline. This is a lot less efficient, results in non-coplanar and/or concave quads getting warped if they're not aligned with the x axis, and (at least with how DS hardware works) causes the interpolation to look all jittery because of roundoff error each scanline. Annoyingly, the last issue is more prevalent on triangles, which didn't need that implementation in the first place.
Saturn did quads a different way, and it also had a ton of problems. Unlike most other 3D hardware I know of, Saturn used a sort of "forward rendering", where it mapped lines from a sprite to stretched lines in screen space (the norm, "backwards rendering", maps pixels in screen space back to the texture, and marches through the screen one at a time). This technique suffered from a serious amount of internal overdraw, where pixels in the same quad are drawn on top of each other. This happens for two reasons. Because the line algorithm suffers from integer roundoff at the edges, adjacent lines would normally leave some gaps between them, so the lines are drawn thicker by inserting an extra pixel where they change slope. And, when the two control edges of the quad are not the same size, multiple lines from the sprite naturally overlap.
This overdraw results in wasted fillrate. Especially if you drew triangles (as degenerate quads) in the wrong way, resulting in a ton of overdraw as every line converged on the same point. It also makes the 50% blended draw mode very glitchy, because the overdraw pixels get blended multiple times. That's why very few 3D games use it, instead opting to use the garish mesh mode.
Saturn's quads also had another major problem: because they were drawn by distorting sprites, the source texture had to be an axis aligned rectangle (where the width is a multiple of 8 pixels no less). This restricted how you could apply textures to meshes. It also made it so that you basically couldn't freely clip or tessellate the quads. This wasted fillrate (although it did at least reject lines that were entirely outside the clip rectangle), and if your transformed coordinates happened to exceed the limited vertex coordinate space you were screwed, so you'd have to be careful with your quad sizing and camera angles to prevent this.
Had they gone with mapping arbitrary quads as textures the implementation would have been far more expensive.
The line based redrawing also just plain resulted in more visible interpolation roundoff error inside the quad because of how the errors stack. There's a Saturn vs PS1 comparison video of Grandia where the difference seems apparent to me (although in other ways Grandia runs better on Saturn)
There was one advantage its quads gave vs PS1 though (outside of being more efficient for geometry sometimes). While the quads still weren't perspective correct, ones that project rectangles (like say, floor tiles) would at least be drawn with much less noticeable distortion than they would had they been drawn as two triangles. And a side-effect of the line by line approach meant that some concave quads would have kind of a curved look to them instead of correctly matching an inflection point, although I think in the real world this would be difficult to utilize for much.
Saturn had a bunch of other weaknesses in 3D vs PS1, but they weren't related to quads so I won't go on about them here.
Incidentally, 3DO had a "forward" style quad renderer too, and it seemed to avoid some of the problems Saturn's had. But even after reading the documents a few times I still don't really understand the finer details of how it works.
#30Exophase, Dec 12, 2014 Last edited: Dec 12, 2014
https://forum.beyond3d.com/posts/1813293/Quote:
- A triangle (ignoring trivial rejection of co-linear points) is always planar. This means there is at most one Z value per screen pixel.
- A quad is unlikely to be planar and rendering one with an implicit silhouette edge at constant per-pixel rate is not pleasant.
- A quad might not be convex! That would be nasty.
- Texturing. In 3D space, a triangle can be texture mapped with simple linear interpolation, which then maps to (relatively simple) hyperbolic interpolation in perspective screen space. Not so simple for quads.
- There is no (significant) data saving having a quad primitive over a pair of triangles using indexed or strip/fan formats.
- Modelling some objects with quads would require degenerate edges.
Simon F, Dec 12, 2014
https://forum.beyond3d.com/posts/207911/Quote:
As general cpu's the SH2 multiplies were far faster than the MIPs on the PS1..
For a 3x4 matrix mul you might do something like...
Where vec is xyz, tx/ty/tz are translations, and matrix is a 3x3 rotation..Code:lds.l macl,tx
mac.w @vect+,@matrix+
mac.w @vect+,@matrix+
mac.w @vect+,@matrix+
addi #-6,vect
sts.l macl,rx
lds.l macl,ty
mac.w @vect+,@matrix+
mac.w @vect+,@matrix+
mac.w @vect+,@matrix+
addi #-6,vect
sts.l macl,ry
lds.l macl,tz
mac.w @vect+,@matrix+
mac.w @vect+,@matrix+
mac.w @vect+,@matrix+
sts.l macl,rz
Without counting for stalls this will need about 9x2 ( mac.w ) + 8 giving 26 cycles.
On PS1 in cpu you would use
This gives (7+1)*9 +1 or 73 cycles - a lot slower, but you could use the coprocessor to do the same in ~10 cycles.Code:mul vx,m0 (7)
mflo temp (1)
mul vy,m1 (7)
add rx,temp,tx (0)
mflo temp (1)
mul vz,m2 (7)
add rx,temp,rx (0)
mflo temp (1)
mul vx,m3 (7)
add rx,temp,rx (0)
mflo temp (1)
mul vy,m4 (7)
add ry,temp,ty (0)
mflo temp (1)
mul vz,m5 (7)
add ry,temp,ry (0)
mflo temp (1)
mul vx,m6 (7)
add ry,temp,ry (0)
mflo temp (1)
mul vy,m7 (7)
add rz,temp,tz (0)
mflo temp (1)
mul vz,m8 (7)
add rz,temp,rz (0)
mflo temp (1)
add rz,temp,rz (1)
Crazyace, Feb 18, 2004
https://forum.beyond3d.com/posts/377393/Quote:
The RDP basically just reads a FIFO and raterizes polygons.
The RSP is the transform portion of the RCP, although it's really just a DSP like R4000 core with 8 bit integer vector ops.
In a typical N64 game the RSP would do transforms, lighting, clipping, triangle setup and some of the audio decoding.
The was no specific requirement that the RSP do any of those and it was relatively common to do audio on the main CPU to increase the graphics performance. I've also worked on N64 games that used custom uCode and clipped on the main CPU.
The RSP is completly programmable, but only a very few devs at the end of the N64 lifecycle were given documentation and tools to rewrite the uCode.
FWIW writing N64 RSP code (triangle setup in particular) makes writing PS2 VU code look trivial.
ERP, Jan 10, 2005
https://forum.beyond3d.com/posts/377400/Quote:
As crippled as the N64 processor was it was still a lot better than the PSX it was competing with.
It had signficant bandwidth problems when rendering with Z on.
And of course the 4K texture cache needed to be bigger.
ERP, Jan 12, 2005
https://forum.beyond3d.com/posts/377402/Quote:
FWIW I'd also guess that WDC pushes more polygons that most PSX games (significantly more than any I ever looked at in an emulator). And probably more than any other shipped N64 game but I couldn't proove that. It renders everything with no Z buffer, and the transform load was shared between the main CPU and the RSP. For the most part it demonstrates extremly balanced RDP/RSP/CPU usage.
Most other uCode tweaks I know of were slight performance gains or tweaks to the lighting model.
ERP, Jan 12, 2005
http://www.ign.com/articles/2000/11/...ng-indy-to-n64Quote:
IGN64: What strengths and weaknesses did the N64 have when porting this game over from the PC?
Factor 5: The big strength was the N64 cartridge. We use the cartridge almost like normal RAM and are streaming all level data, textures, animations, music, sound and even program code while the game is running. With the final size of the levels and the amount of textures, the RAM of the N64 never would have been even remotely enough to fit any individual level. So the cartridge technology really saved the day.
In terms of weaknesses we fought hard against the fill-rate limitations of the N64. We loved Hi-Res on Rogue because of its crisp look, but the framerate was questionable. So when starting the engines for both Indy and Naboo, the main goal was to get a high framerate in Hi-Res. This meant not using the Z-Buffer, because it alone uses quite a bit of the N64's fillrate.
I've always considered the Playstation as the most powerful console of its generation. It did everything very well, while the Saturn and N64 struggled in some form or fashion trying to do things outside of their comfort zone.
Sony understood that having great development tools available to its 3rd party developers would allow their console to shine, while Nintendo and Sega weren't so open with tools that could help them.
I'd rep you if I could Barone. ;)
Thanks for the info Barone. I too would give you some rep if I could.
Though for what it's worth I don't think any of us were really debating the PS1's 3D superiority.
Again to bring us all the way back to when this kicked off, the original debate was Saturn and PS1 vs the N64. And the question that brought us into Polygon performance was were those fancy effects like Z-Buffering, Texture Filtering, etc. worth the hit they imposed on the N64's performance in other areas like polygon performance?
Which again the examples that have been brought up to try and say it wasn't a big issue are almost all ones that turn those effects off and use custom microcode. When those effects are all turned on how does the N64 stack up against the PS1 and Saturn in the polygon performance department?
And to be clear, I'm not denying any of what you just posted. It all pretty much aligns with what's already been said. PS1 was the king of 3D performance, Saturn was a cooky nightmare with funky warped quads, overdraw issues, glitchy transparencies, and memory that was divided into a less than ideal way, and the N64 when using custom microcode could perform on par with the PS1 or possibly outperform it. The question I'd like to have answered though is how it stacks up with those effects all turned on. I've seen people post over the years that it was either superior to both the Saturn and the PS1 at all times (ABF), or that it was worse than the PS1 and even worse than the Saturn at times with those effects all turned on. Obviously these contradict each other, it would be nice to have a solid answer to end this debate once and for all.
That wasn't my main goal either, but those tidbits only seem to come in such debates. :?Quote:
Originally Posted by TrekkiesUnite118
I'll reply to the other stuff later because it's already way too late for me.
Only one of Barone's developer quotes touched on the VDP2. But it did say it can be a big asset.
It was also very interesting to read that the Z-Buffer was actually not used on some N64 games. This I never knew. And wish more N64 did this.
That guy worked at BOSS? Great find!
I agree. Also, this whole N64 microcode situation sounds so crappy to me. It makes it look like only a few developers had the proper tools to code for the console. Unless i missed something.Quote:
Originally Posted by Thief
And also this:
This was the biggest problem N64 had IMO. I already mentioned the terrible 3r party Japanese support. And i can't think of more than 3 or 4 devs who really made the console work properly with graphics. Nintendo themselves NOT being in the list.Quote:
And quite honestly there was a shortage of high quality developers on N64, and it was an easy machine to screw yourself and et very poor performance on.
Also:
Quote:
I also think that there are a lot of inflated PSX numbers, and a lot of people assume that N64 games had a lot less polys simply because of the poor textures in a lot of cases. I've run a lot of top tier PSX games through emulators when they first stated to appear just to look at what they were actually doing and most have far fewer polygons on screen than the claims that were floating around.
And:
^ Pretty ironic this quote. "Cartridge saved the day"?? How many times did you hear that back in the day? I remember the flack i was getting when i was trying to point out the advantages the cartridges have. I even wrote to a local games magazine back then and it even got posted, but the answers from PSX fanboys were funny...Quote:
Factor 5: The big strength was the N64 cartridge. We use the cartridge almost like normal RAM and are streaming all level data, textures, animations, music, sound and even program code while the game is running. With the final size of the levels and the amount of textures, the RAM of the N64 never would have been even remotely enough to fit any individual level. So the cartridge technology really saved the day.
I always believed that the cartridge is actually a better medium for the games themselves to function (sans the lower storage that can affect the quality of the games negatively). But with a bit more storage, the medium has many more advantages. I mean, Solid State is the future now right?
You can also go back a bit further, when 8bit/16bit computers were around. Everyone were so jealous about the "plug and play" cartridges the new consoles had. They were more expensive but so much faster than floppy disks (in early days, carts didn't even have much bigger storage size either. They were just faster and more reliable.). And when the CDs came around, they looked like glorified floppy discs to me, bringing back some of the awful things the carts got rid of, like loading times, loud mechanical noises and slow/unreliable mechanical parts.
I don't think anyone debated that cartridges are faster which can reduce load times and what not, but with the 5th generation cheap mass storage was more important for quite a lot of major games like Metal Gear Solid, Resident Evil, Final Fantasy, Star Ocean, Grandia, Lunar, etc. Yeah, Resident Evil 2 did get ported, but it's heavily compressed and it shows regardless of how impressive it is. Try putting a game with tons more prerendered backdrops and FMVs like Final Fantasy VIII on an N64 cartridge and see how well that works. A game like Resident Evil has maybe 10-15 minutes worth of pre-rendered FMV at most, while games like Final Fantasy can have up to an hour or more:
And as the Saturn proved, with a RAM expansion the load times can become a non-issue:
I already mentioned the small cart sizes. But still, solid state will always be better, no matter. Optical/Mechanical mediums will always be slower and less reliable. As for your Street Fighter example, according to MAME, the first SF Alpha was less than 16MBs uncompressed. That's the size of the average N64 cart during it's lifetime (there are more 12 and 16 MB carts than 8MB). Which means the N64 could easily just fit the whole game in there and stream it, without RAM expansions and zero loading (try streaming a whole game off a CD). Or at least i assume it would, had Capcom actually cared for the system.
Also, i never cared about FMVs (most were cringe worthy to me). I was sick of them on the Mega CD, years before the PSX/Saturn. They are not gameplay. They are just video files that take a huge space. I'd rather have in-game cutscenes any day. I really loved the cutscenes in OOT/MM because there was no jarring difference graphically when you go back in game, the transition is seamless. In FF& (or any other game that had elaborate FMVs) i had to recalibrate my senses everytime a FMV was over. The transition was horrible.
I'd rather have the extra space filled with more textures and game content.
Ah and i'm not impressed by your FF "lots of hours FMV" comment. The game was 3 CDs ffs.
You're forgetting one thing the PS1 and Saturn versions of those Fighters did over the Arcade release. They usually had more content added (characters, stages, modes, etc.), art gallleries, better quality music (For Alpha 1 and 2 at least), and in the case of the PS1 better voice samples. The Saturn and PS1 versions of those games are significantly bigger than their arcade counterparts. Newer systems also showed that simply having a little bit more RAM can significantly reduce load times. For example look at Dead or Alive 2 on the Dreamcast. Loads between stages are practically seamless.Quote:
Originally Posted by Soulis
As for FMV, that's your personal opinion, but I think most of us JRPG fans appreciated them. In many cases they really helped tell the story in a better and more cinematic way. And in the Final Fantasy games they were even used for more animated dungeons and backdrops with the 3D characters being rendered overtop.
As for Solid State Drives, it still has the same major drawback this kind of media has always had. It's freaking expensive. For the price of a 256GB SSD I could get a 2+TB HDD. That's an area it will probably not overcome for a long time. In the long run which is the more cost effective design? A system that uses 1GB Cartridges? Or a system that uses 50GB Blurays with a highspeed drive and a large amount of RAM that developers can use to set up a streaming system to hide/reduce load times?
And Resident Evil was on 2?Quote:
Originally Posted by Soulis
Final Fantasy VIII is 4 discs and you can easily sink about 100 hours into it with all the side quests as well as if you want to build up your characters and experience everything the game has to offer. I'd say the hour of FMV + the massive amount of content the game has is proof of how big of an asset cheap mass storage is over minor load times. Which for what it's worth, the Final Fantasy games typically do a very good job hiding their load times.
My point is that this particular game would be no problem for a N64 cart. You want more content? Use a 32MB cart (these existed too for the more important releases). Also, how much space you think a SF game takes on a CD? Do you even believe that most games fill the whole disc? Try finding a torrent with compressed ISOS in zip/7z form. Or scrubbed ISOS that get rid of empty space. You would be surprised at how many games use less than 1/6th of the CD space. Some are even as small as a N64 game.Quote:
Originally Posted by TrekkiesUnite118
FF was 3 CDs so i don't know how great example it is. They could use 10 CDs and make even more stuff, doesn't matter.Quote:
Originally Posted by TrekkiesUnite118
A game on a Solid State drive would be able to stream more data than any mechanical drive will ever be able too. Maybe today, 20-50MB/s is enough for most games but don't hold your breath. Soon, the mechanical mediums will hit a wall and you will see how much of a bottleneck they will become, when SS mediums become the standard.Quote:
Originally Posted by TrekkiesUnite118
Medium size does not equal actual gameplay content. I spend 100+ hours completing OOT 100% and that game is 32 MBs.Quote:
Originally Posted by TrekkiesUnite118
Also, you forget what the Factor 5 dev said. Carts don't help in loading times only, they help in streaming data faster, DURING gameplay. Read what he said.
I don't have to, I can simply put the disc in my computer. Street Fighter Alpha 3 for the Saturn is 513MB. About 400MB of that is the ADPCM compressed music. Which means the game data itself is over 100MB.Quote:
Originally Posted by Soulis
http://i102.photobucket.com/albums/m...psqambpxls.png
As I already said the game was on 4 discs and you can easily sink over 100 hours into it. You would not be able to fit that on an N64 cartridge. Resident Evil 2 was on 2 discs with most of it being redundant content and using only about 10-15 minutes worth of FMV between the two discs. The point is, without cheap mass storage those games wouldn't have been possible with out cuts.Quote:
Originally Posted by Soulis
Possibly, but we're not there yet. And we probably wont be there until the price issue of Solid State can be addressed. A SSD is great for using for your main OS and having maybe one or two of your load heavy games on it. But good luck finding one big enough to have your whole Steam library installed on it for a decent price.Quote:
Originally Posted by Soulis
I have 100% completed OOT many times. It does not take 100 hours. Final Fantasy VIII has significantly more content and a much longer quest. That's not to say OOT is a bad game, but it's not really a long game when compared to RPGs on the Saturn and PS1.Quote:
Originally Posted by Soulis
And what do you think those RAM cart games are doing? They are probably streaming data for the next thing it needs to load while the game is displaying something else (i.e. streaming the next stage data while the game is displaying the whole "You won, the next challenger is X" sequence). And then there's modern examples like the Hedgehog Engine which streams graphic data off the disc to allow for long and detailed levels:Quote:
Originally Posted by Soulis
Street Fighter Alpha 3 is 45MBs on the arcade board. Considering how they managed to fit 2 CDs in one 64MB cart, i don;t think it would be too hard to fit this game on a 32MB cart, with minor cuts. Or they could use a 64MB cart and even add some content. We are talking about Capcom here, they would be more than capable doing an arcade perfect N64 version, if they really wanted. And there would be no loading ofc, with the standard RAM.
This is maybe a shock for you but really, N64 carts were big enough for games. There are 4 major things that hold it back.
-Price. Obviously carts were more expensive to produce.
-FMVs. Doesn't count as game content IMO. In game cutscenes can still be used as an alternative and even has it's own strengths.
-Sound quality/voice acting. Again, you can have alternative formats of sounds on a cart. And this may sound biased but i actually prefer good quality midis over orchestral music (not always but most of the time). Most of my favorite soundtracks are Midi anyway. Plus you get dynamic music this way. Voice acting is a huge plus on CDs but it appears that they got around it anyway and many N64 games had fully voiced characters, like in Starfox, PD, Shadowman, Conker, etc
-Textures. This is the only important thing that CD games could really take advantage of IMO. But i think that it was mostly the texture cache that caused N64 most problems in this aspect, not the size of the carts. I believe that a 32MB cart would be able to fit decent textures, i mean DOOM 64 is only 8MB and it's one of the best looking N64 games texture wise.
Game content/hours of gameplay is something mostly unrelated with the size of the medium.
And how much RAM does the cart give you? Extra 2 MBs? What if you need more later? Buy a bigger RAM cart?Quote:
Originally Posted by TrekkiesUnite118
You don't need that much RAM with cartridges, according to what the Factor 5 dev said. Even the extra 4MB (8 in total) N64 RAM wasn't enough for Battle for Naboo (which is much less than what the RAM cart gives you on the Saturn). But the game was possible on the N64 because it could use the cart almost as a RAM. That's what he said. And sorry but i will take his word for it instead of yours:
Quote:
We use the cartridge almost like normal RAM and are streaming all level data, textures, animations, music, sound and even program code while the game is running. With the final size of the levels and the amount of textures, the RAM of the N64 never would have been even remotely enough to fit any individual level. So the cartridge technology really saved the day.
This is from Wiki:
Quote:
Specified at 5 to 50 MB/s, Nintendo cited the ROM cartridges
The difference in speed is as massive as the difference in storage space between them. It's not just "a few times faster". Even at the lowest rated speed of 5MBs, you still get 15+ times faster, plus you don't have the latency of the actual lens mechanism since you can get data from anywhere in the cart at any given point.Quote:
Few contemporary CD-ROM drives have speeds above 4×, and the competing consoles Sega Saturn and Sony PlayStation have 2× drives running at about 300 kBps with high latency