Path: chuka.playstation.co.uk!news From: James Russell Newsgroups: scee.yaroze.freetalk.english Subject: Re: S*ga Dreamc*st Date: Thu, 06 Aug 1998 10:33:51 +0100 Organization: Sony Computer Entertainment Europe Lines: 102 Message-ID: <35C9787F.3CD3A9AA@scee.sony.co.uk> References: <3569980E.51FC@saqnet.co.uk> <356A77BD.596@dma-design.com> <356a4d1f.24746116@news.scea.sony.com> <356A8BBD.5DD9@dma-design.com> <35C13E1E.4A99D280@mail.datasys.net> <1dd416x.1cqaclz4vkpc1N@a1-88-110.a1.nl> <6q1g2e$fvf13@chuka.playstation.co.uk> <1dd8b4y.1g33oa41ggvfzhN@[194.151.88.144]> <35C829EA.55EFA3B1@scee.sony.co.uk> NNTP-Posting-Host: mailgate.scee.sony.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.5b1 [en] (Win95; I) X-Accept-Language: en Toby Sargeant wrote: > > >compete. So DirectX will go out the door very quickly. It will only be useful for PC developers > >wanting to port games. > > I doubt it. The Dreamcast will likely be fast enough that programmers, being > the lazy things that they are won't optimize for optimization's sake. I've never ever seen a games computer that was "fast enough". :O) In the first couple of years, people will use the DirectX API because its simpler than going low level. But towards the middle and end of the product lifecycle, programmers will be wanting to push the limits of the platform to compete with other games doing the same, and DirectX will go out the window. > Unnoticed by the programmers and testers. Probably mostly unreproducible by > the users. They're the nasty bugs. Actually, I use 95 and I find it very stable. It has a couple of very annoying things wrong with it, like freezing the entire system when you try to access a shortcut to a network drive (and it stays that way for 3 minutes if that computer is inactive). But as for system crashes, I get very few. Still, that's beside the point. In my experience, DirectX has a few very nasty bugs in it, and that's just when writing a relatively small app like RSDAnim or RSDTool. If you're a programmer developing for DC, you either have to workaround those bugs, or just dump the API in favour of your own. If the bugs are too numerous in DirectX, then people will favour their own. But since I've never programmed a full game in DirectX then I'm not in a position to justify that! > The N64 manages to provide a decent MIPS processor. And the N64 is consquently higher in price than the Playstation, although that's probably not just because the processor is faster. > Sure. But the point is that price is roughly exponential in terms of power, so > by providing 2 CPUs of lesser power, you can get an approximately 1 generation > jump for less than the comparable price. That may be true, but the system architecture of such a system is very complex, and subsequently difficult to program _efficiently_ (emphasis on _efficiently_). Since most OS's take care of this for you, most people don't notice the problems underneath. The OS handles the mutexes (or whatever) and allocating threads to different processors. Doing this at _maximum_efficiency_ is not a trivial problem for an OS, since it's dependent on the application. It's not hard to get _good_ use out of a multi-CPU system, but it is hard to get the _best_ use out of it. > Lies. All lies. Scene creation occurs as fast as possible into a circual buffer > of potential scenes as fast as it can. A separate thread waits for at least > one complete scene and then renders the most recent scene into polygons in a > second circular buffer. The third thread takes the most recently rendered > polygon scene, and then displays it. Thus, scene creation may be a frame or > so ahead of scene display, but the user won't feel it. That's what I meant by "assuming you haven't got the memory for triple buffering". In order to do what you suggest above, you'd have to have 2 sets of 2 buffers: The first is the first double buffer for the data necessary for scene creation, the 2nd is the double buffer of polygon data. Those memory requirements are a Big Deal to console programmers. It's also a specious argument, because although the CPUs are busy 100% of the time, you still get the same result as a 3 step pipeline (Pre Scene Creation -> Scene Creation -> Polygon Drawing). Some scenes created will have to be thrown away because they are no longer the most recent, and therefore you're not using your processors to 100% efficiency, even though they're busy all the time. If you look at the way the PSX generally does it, you'll see what I mean. The CPU creates frame X, while the GPU is busy drawing frame X-1 and displaying frame X-2. The CPU, because of memory restrictions, can't start creating the next frame yet because the GPU is using that part fo the buffer, so the CPU has to wait, twiddling its thumbs until the GPU is finished before continuing. If it had more than one buffer (i.e. a ring buffer), the CPU could continue, and the GPU would start on the most recently completed frame when it finished. But therein lies the rub - if the CPU is _generally_ faster at completing its task than the GPU, then the GPU will be throwing frames away, so time and memory was wasted (not that you'd get that time back in other ways, though). If the CPU is _generally_ slower at filling the buffer than the GPU, then the GPU will be the one twiddling its thumbs anyway because it can't get ahead of the CPU in the ring buffer. And if they're _generally_ working in step, then there's no point in having a ring buffer beyond the size of two, which is what we had to start with. The trick with PSX programming is to start creating the polygons for the scene as soon as the packet buffer becomes free (which occurs when the GPU has finished with it). But this means that your pre-scene should have already completed by then, so the favoured method is to start pre-scene creation as soon as you've finished scene creation (which starts at the beginning of a frame). > I think if you put your mind to it, you'll find that there's parallelism to > be had in a _lot_ of 3d games, and even in some 2d ones. [I'm hard pressed to > find parallelism in tetris, though...] When you complete a line and you're shifting the blocks down, that could be parallelised. :O) Yes, there are some things that could be parallelised very easily. > Again, it's a matter of OS support. An MMU is useful if you've got the > support for it already there. There's no reason why a game has to be a single > process, and in fact, there's no reason why the OS has to be a single process > either. Why do you need an MMU for multi-tasking? The Amiga didn't have one, and neither did the Mac. You need an MMU for memory _protection_, and I don't believe that's important enough to developers to warrant adding the extra silicon in for it. Cheers, James -- == James_Russell@scee.sony.co.uk +44 (171) 447-1626 == Developer Support Engineer - Sony Computer Entertainment Europe Don't judge a book by its movie.