Quantcast

Page 66 of 87 FirstFirst ... 165662636465666768697076 ... LastLast
Results 976 to 990 of 1301

Thread: Micro-64 Feature: Nintendo 64 Vs. Sega Saturn

  1. #976
    Hero of Algol TrekkiesUnite118's Avatar
    Join Date
    May 2010
    Age
    34
    Posts
    8,544
    Rep Power
    145

    Default

    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.

  2. #977
    Hero of Algol
    Join Date
    Aug 2010
    Posts
    8,306
    Rep Power
    199

    Default

    Quote Originally Posted by tomaitheous View Post
    I had to go back and double check that I was clear in my question,
    This has been an issue in this thread and in recent Sega-16 technical discussions in general. It seems to be a mounting trend.
    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?
    Last edited by Barone; 12-20-2015 at 12:39 AM.

  3. #978
    ESWAT Veteran Team Andromeda's Avatar
    Join Date
    Jul 2010
    Location
    Wales, UK
    Posts
    7,048
    Rep Power
    80

    Default

    Quote Originally Posted by TrekkiesUnite118 View Post
    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:

    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 .
    Panzer Dragoon Zwei is
    one of the best 3D shooting games available
    Presented for your pleasure

  4. #979
    Hero of Algol TrekkiesUnite118's Avatar
    Join Date
    May 2010
    Age
    34
    Posts
    8,544
    Rep Power
    145

    Default

    Quote Originally Posted by Barone View Post
    - Is the VDP2 extensively usable in all 3D games?
    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 View Post
    - 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?
    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 View Post
    - How technically impressive are the best looking Saturn 3D games which do good use of the VDP2?
    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 View Post
    - Which kinds of graphical effects the VDP2 can provide to 3D games?
    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 View Post
    - 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?
    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.

    The transparency and blending effects I wouldn't imagine having much impact on gameplay though.

    Quote Originally Posted by Barone View Post
    - 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?
    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.

  5. #980
    ding-doaw Raging in the Streets tomaitheous's Avatar
    Join Date
    Sep 2007
    Location
    Sonoran Desert
    Age
    46
    Posts
    3,981
    Rep Power
    79

    Default

    Quote Originally Posted by Team Andromeda View Post
    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
    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 View Post
    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
    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 TrekkiesUnite118 View Post
    Seriously Thief?:



    Don't send me snarky and insulting comments about people I have the utmost respect for around these forums.
    Lol! He's a fool.

    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 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).

    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!".

    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.
    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.
    Last edited by tomaitheous; 12-20-2015 at 01:05 AM.

  6. #981
    Hero of Algol TrekkiesUnite118's Avatar
    Join Date
    May 2010
    Age
    34
    Posts
    8,544
    Rep Power
    145

    Default

    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.

  7. #982
    End of line.. Shining Hero gamevet's Avatar
    Join Date
    Jan 2008
    Location
    Dallas, Texas
    Posts
    10,212
    Rep Power
    141

    Default

    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


    Quote Originally Posted by segaretro
    VDP2 32-bit background and scroll plane video display processor

    VDP2 1st version.
    The VDP 2 serves as the Sega Saturn's background processor. Certain special effects such as texture transparency and playfield rotation and scrolling (up to five fields at any given time) are handled here.

    Both the VDP2 and VDP1 32-bit video display processor have direct access to the both SH2s, as well as direct memory access (DMA) to both the main and video RAM.

    Background engine
    Four simultaneous scrolling backgrounds
    Uses 8x8 or 16x16 tiles or bitmap display per background
    Programmable memory access controller for VDP2 VRAM
    Two simultaneous rotating playfields
    VDP2 can rotate VDP1 framebuffer position while scanning out to display for rotation effects
    Color RAM supports 15-bit (32768 colors) and 24-bit (16.7 million colors) display modes
    Programmable priority at the per-background / per-tile / per-pixel levels
    Background color tinting/fading, and transparency effects
    Background blur effect (gradation) to simulate distance
    Programmable display resolution:

    Horizontal sizes of 320, 352, 640, 704 pixels
    Vertical sizes of 224, 240, 256 scanlines, non-interlaced
    Vertical sizes of 448, 480, 512 scanlines, interlaced
    (Only PAL consoles support 256 and 512 scanline displays)

    Hi-Vision (EDTV) and 31KHz (VGA) display support:
    31KHz: 320x480 or 640x480, non-interlaced (progressive scan)
    Hi-Vision: 352x480 or 704x480, non-interlaced (progressive scan)
    (Requires compatible monitor and video cable)
    Notice the part about the Saturn being able to do progressive scan at 480p.


    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.

    Quote Originally Posted by tomaitheous View Post
    That's what you see. What I see is the PS1 actively fading the both lines (ground and sky line). Something that takes more effort than simply two flat projections meeting at a dead point. The VDP2 definitely helps with 2D games, especially if they use any sort of "tiles", but where is the evidence that it makes up the difference in polygon power between the two system (polygon performance: pixel fill rate, processing transforms, polygon rasterization)? Simple speculation isn't enough for me.

    Maybe Barone knows this, but doesn't the PS1 have hardware tiled texture mode? As in a texture, or whatever size, is tiled across the polygon surface? I thought I remember something about the developer of a Saturn game saying the Saturn didn't have this support, but that PS1 and PC cards at the time did (and they had to make a work around). I thought it was Powerslave on the Saturn, and in this forum.
    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.
    Last edited by gamevet; 12-20-2015 at 01:26 AM.
    A Black Falcon: no, computer games and video games are NOT the same thing. Video games are on consoles, computer games are on PC. The two kinds of games are different, and have significantly different design styles, distribution methods, and game genre selections. Computer gaming and console (video) gaming are NOT the same thing."



  8. #983
    ESWAT Veteran Team Andromeda's Avatar
    Join Date
    Jul 2010
    Location
    Wales, UK
    Posts
    7,048
    Rep Power
    80

    Default

    I'd start trying to find minded answers to the following questions:
    - Is the VDP2 extensively usable in all kinds of 3D games?
    No not all for a Game like Sega Rally the VDP 1 is having to go most of the work.


    -
    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?
    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.

    - 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?
    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 .

    [ Which kinds of graphical effects the VDP2 can provide to 3D games [/QUOTE]



    Panzer Dragoon Zwei is
    one of the best 3D shooting games available
    Presented for your pleasure

  9. #984
    Hero of Algol TrekkiesUnite118's Avatar
    Join Date
    May 2010
    Age
    34
    Posts
    8,544
    Rep Power
    145

    Default

    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.

  10. #985
    ESWAT Veteran Team Andromeda's Avatar
    Join Date
    Jul 2010
    Location
    Wales, UK
    Posts
    7,048
    Rep Power
    80

    Default

    was. The vast majority of the game engine is 2D, and the Saturn does exce
    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.
    Panzer Dragoon Zwei is
    one of the best 3D shooting games available
    Presented for your pleasure

  11. #986
    Hero of Algol TrekkiesUnite118's Avatar
    Join Date
    May 2010
    Age
    34
    Posts
    8,544
    Rep Power
    145

    Default

    Quote Originally Posted by gamevet View Post
    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.
    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.

  12. #987
    Banned by Administrators
    Join Date
    Jan 2010
    Location
    spaghetti
    Age
    42
    Posts
    5,991
    Rep Power
    0

    Default

    Quote Originally Posted by tomaitheous View Post
    Lol! He's a fool.
    Whatever makes you feel better.

    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.

  13. #988
    Banned by Administrators
    Join Date
    Jan 2010
    Location
    spaghetti
    Age
    42
    Posts
    5,991
    Rep Power
    0

    Default

    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?
    Last edited by Thief; 12-20-2015 at 12:18 PM.

  14. #989
    Hero of Algol
    Join Date
    Aug 2010
    Posts
    8,306
    Rep Power
    199

    Default

    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=402824


    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=402849


    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=402980


    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://boards.openpandora.org/topic...comment=402980

    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/1827968/




    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/923225/

    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
    https://forum.beyond3d.com/posts/923284/


    "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.
    "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."
    http://www.eurogamer.net/articles/di...ing-of-wipeout


    About clipping:
    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
    https://forum.beyond3d.com/posts/1824447/


    About the lack of sub-pixel accuracy:


    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
    https://forum.beyond3d.com/posts/1825474/


    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.
    http://psx.rules.org/gte.txt


    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/39885/
    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/39889/
    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/39892/
    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/39894/
    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/39897/


    Are there any games on the PS1 more technically impressive than MGS?
    PSman, Dec 4, 2007
    https://forum.beyond3d.com/posts/1102657/
    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
    https://forum.beyond3d.com/posts/1102664/


    Why did GPUs abandon quads in favour of triangles
    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/1813181/
    • 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/1813293/


    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...
    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
    Where vec is xyz, tx/ty/tz are translations, and matrix is a 3x3 rotation..
    Without counting for stalls this will need about 9x2 ( mac.w ) + 8 giving 26 cycles.

    On PS1 in cpu you would use
    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)
    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.
    Crazyace, Feb 18, 2004
    https://forum.beyond3d.com/posts/207911/


    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/377393/
    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/377400/
    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
    https://forum.beyond3d.com/posts/377402/

    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.
    http://www.ign.com/articles/2000/11/...ng-indy-to-n64

  15. #990
    End of line.. Shining Hero gamevet's Avatar
    Join Date
    Jan 2008
    Location
    Dallas, Texas
    Posts
    10,212
    Rep Power
    141

    Default

    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.
    A Black Falcon: no, computer games and video games are NOT the same thing. Video games are on consoles, computer games are on PC. The two kinds of games are different, and have significantly different design styles, distribution methods, and game genre selections. Computer gaming and console (video) gaming are NOT the same thing."



Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •