PS2 Performance Rhetoric

Okay, I\'ve read the articles and think I get the gist but I still have a few questions and would like to promote a discussion on what exactly goes on and where the weaknesses might really be.
I\'ll start off by reminding everyone that the dirn thing is supposed to be able to process video info at a speed that makes a large amount of VRAM unnecessary... insufficient VRAM being a major complaint of a lot of people from what I\'ve seen.

This brings up a question though. This being the case, what is it that could hold up the speed of the games that we play? Could it be that the drive doesn\'t read information fast enough or that we have to wait for it to find the information on the disk that it needs? What other kind of RAM is necessary and what is it used for exactly?

And what\'s up with this "Developer\'s Learning Curve?" If you give them a Dev Kit and tell them how the thing works, doesn\'t it stand to reason that they\'ll be able to do well right from the git go (assuming they know what they\'re doing)? Given the fact that the hardware configuration is static, you\'d think this thing would be cake to make software for.

yep, i know.  4 mb or vram is just too little.  I heard something about the 48 gigbytes of bandwidth thing solve the problem or sumthing like that...but still, wouldn\'t it be easier with more mb of vram than higher bandwidth?  Sorry, I am not a programmer so I don\'t know.  Hopefully someone could tell please give a specific explanation.

the difference is, that when you hhave a lot of bandwith you don\'t need all that much of vram, because you can stream the iformation, which means, instead of stacking all your textures and stuff into your random access memorie, you put in, only the stuff that is needed at a given time, and refresh it every certain time, the advantage is that you can make levels as big as you want, cause you don\'t need to pt in the whole level into vram.
Here is a link to an article that is posted on this forum several times before, so no flaming please, cause I said I knew it was posted before:  http://arstechnica.com/reviews/1q00/playstation2/ee-1.html
you\'ll probably undrstand maybe 10% of what the writer is saying, but it gives you an idea of how the things work

That 4 megs might be really fast, but the fact that it\'s relatively small will limit performance somewhat. If there is more than 2 or so megs of textures per frame they will need to be swapped in at a rate of less than the 3.2 GB/s provided by the system ram.  48 GB/s bandwidth or not, the whole thing will be waiting for textures if they don\'t fit in whatevers left over of v-ram after frame and z buffers. Ten 16 bit 512x512 textures are going to take up 5 megs, for example, and a frame using them would have the gs idling for a bit while whatever texture is needed is being swapped in.  Good swapping routines would be required for texture-heavy scenes and no matter what I\'m sure they won\'t be hitting the theoretical specs for the fill-rate of this thing.

I also don\'t think it would be at all easy to develop for the ps2, at least not after developing for pc\'s for a long time.  On a pc you can assume you\'ve got 16 megs of video ram minimum, and can take advantage of prebuilt transform and lighting routines built into direct3d or opengl.  Texture handling would be a lot easier and you don\'t have to do something as potentially hard as programing transform and lighting routines directly for the vector units of the ps2.  Also fsaa is a non-issue.  It\'s taken care of in video drivers and developers never have to look at it.

Oh, well. I\'m too tired to proofread so if this doesn\'t make sense or it turns out I said something stupid, I\'ll have to fix it tomorrow I guess.

-greg

MDK2 programmers found an easy way around the VRAM problem so I would assume that other developers can do the same. They have some big @ss levels and some pretty heafty textures to boot and they said no problem we\'ll just swap them in and out. They todate run a 60FPS+ so if other developers get off there lazy @ss\'s and learn to build stuff from scratch then they would have nothing to ***** about.

Now as for programming for a PC..... All that Opengl and directx crape leads to one thing. Allmost all games look exactly the same. I have seen midtown madness and several other racers look the same minus the textures. All the production houses do is program or write code to tell a set routing of instructions to take off and do there stuff. This leads to almost all the game looking the same. I personnally have been playing PC games for a decade, and since the introduction of these, lazy mans programming, prebuilt package routines I find the games less enthusiastic and more or less looking exactly the same. I\'m glad sony broke that mold, and are forcing the programmers to go out and build it from scratch. Just look at RRV and Midnight street racing. Those two games were launch titles and they couldn\'t look more different from one another. Now look at Midtown madness, monster truck racing, and test drive 5. Those titles have so many simularities that you loss count. The graphics, same boxy look. The sound same type of cut in and cut out procedure. Why were they like this, because they all run off the same prebuilt routines. Now this is in no way a beat down on the PC or a rise for the PS2, but a congrates to Sony for breaking the mold. The dreamcast works on the same means, with the TDK that sega released before the DC hit the shelves. And nintindo is doing the same, just like the N64, with the gamecube. And as we all know the X-box is built around Directx (hint the X in the X-box, and yes that is where the X came from). I just hope that tring to break the dam and let the water flow like it should doesn\'t come back around and drown Sony.

This is my two cents, take it as you like.

Two very interesting posts dragon and Skip.

Dolby, the main problem that programmers are running into is :

Micro-programming: Unlike the PSX which used C+ software libraries to program, the PS2 uses base-level micro-code to actually run the hardware. This presents a problem in that most programmers are used to programming in a higher level language (like C+ or DirectX) as opposed to writing in microcode. Unfortunately, Sony didn\'t get all the "middle-ware" support (which allows programmers to write programs in a higher laungage and the decompiles it into assembly language or microcode) set-up properly by launch time. Hence, many of the early titles didn\'t support all the functions that the PS2 supports (like using the Vector Units). So a lot of companies got stuck trying to figure out how to compile higher level programs to run properly on the PS2.

Fortunately, this is not the case anymore. There are now over a dozen middleware companies offering libraries, game engines, and compilers for the PS2. Plus, quite a few software developers have come up with some interesting software of their own to help tame the hardware (look at Polyphony\'s GT3..). Things will only get better and easier as time goes on.

Ah, I see now.  I was hoping for a response like that, thanks Regent... yer the man.