Path: chuka.playstation.co.uk!news From: "Craig Graham" Newsgroups: scee.yaroze.freetalk.english Subject: Re: S*ga Dreamc*st Date: 5 Aug 1998 11:30:35 GMT Organization: PlayStation Net Yaroze (SCEE) Lines: 138 Message-ID: <01bdc063$d0e4e900$f30b0a0a@Angela1.intelligent-group.com> 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: d2-s8-102-telehouse.mistral.co.uk X-Newsreader: Microsoft Internet News 4.70.1155 James Russell wrote in article <35C829EA.55EFA3B1@scee.sony.co.uk>... > Toby Sargeant wrote: > > > > b) adding OS development time to hardware development time means that the > > time-to-market of a console would (at a guess) be more than doubled. Of > > _course_ companies will like the option of choosing off the shelf OS > > solutions. It's a pity that the choice has been Microsoft's offering, > > though. > > From what I've heard, MS Windows CE is actually very good. You're forgetting that the _main_ reason > why people hate Windows is because it crashes alot. That's because there's millions of lines of > code, dating to way back when, some 16 bit, some 32, lots of horrible legacy code. Windows CE was > created from scratch, and hence its a very stable system. CE has more in common with the NT core than the Win95 core (but that doesn't make it the be all and end all). > However, I think Sega are missing the point somewhat. Initially, DC games will use DirectX because > it's a standard and easy to port from the PC. But to get the full power out of a console, you have I'd be interested to see how it works in practise (Direct3D is a real arse compared to your average console API (eg. everyone around here's favourite GS API). > to go low-level. You can't do that anymore on a PC, because you have to write drivers for every > video card around, which is why DirectX exists in the first place. But with a standard platform like > the DC, programmers will drop to low level to get more speed. There's no question about them doing > that eventually, because if you spend that extra time, you can get a much better looking game. Once > one company does it, it will be the standard, and everyone else will have to drop to low level to > compete. So DirectX will go out the door very quickly. It will only be useful for PC developers > wanting to port games. So you'll see a lot of ports. They'll replace the models with higher poly count versions, and rebuild for a quick port. Some may be critical of that approach, saying it gets them nothing beyond the PC version, but your average loaded gaming PC is 10 times the cost of a console, so it's same game to different market at no cost - good move from Sega. Console developers won't bother to use DirectX as it takes longer to code for than other API's anyway (apart from N64). Hopefully the Sega lower level API will be better than Saturn's was.... > > Having said that, there are a few things that I think could have been better. > > Rather than sticking with a hitachi processor, i would have liked to have seen > > a mid - high end MIPS, PPC or Alpha processor. > > The cost of such processors is large in comparison with the rest of the console. Remember that they > have to churn out millions of these CPUs _and_ make them cheap enough to put into a home console in > the first place. I would want to see a 1Ghz PPC or a 400 PII in PSX2, but nobody wants to pay £600 > for a console! :O) The voices of people who've never programed hitatchi processors - I've done load of hitatchi assembler, and the chips are very quick and very fast in practise. And cheap.... > > I don't know whether the dual CPU approach of the saturn was a > > good idea. Multi threading tends to confuse developers, and introduce all > > kinds of subtle bugs. On the other hand, it's a good way to get better > > performance for less cost. In the balance, a multi CPU with less powerful > > CPUs wins in my book. > > Programming for multi-CPUs _efficiently_ is at least twice as hard as normal coding. And the > complications with the system bus are massive. For instance, there are problems with cache > inconsistency between processors. All of these are solvable, of course, but getting 200% power out > of 2 CPUs is almost impossible and very difficult to design. From what Colin tells me, most Saturn > programmers used the second CPU like a GPU - it just sat there waiting for commands in a queue and > processed them whenever they arrived. That's not efficient, but it's easy to program. That's a lazy aproach. The TWTV box had 3 processors (68K, Hitatchi H8/334, custom Graphics Processor), and by treating the stuff in a Unixy sort of way (seperate programs sending messages and signals) it was possible to get a lot done in parallel, without really trying. > The other thing about multi-CPUs is that they're only good when you want to do many independent > things at once. If you consider that CPU time spent on sound/controller/CD is almost negligible, > then the rest of the time is divided into Pre-Scene Creation (like doing all the physics > calculations in Gran Turismo), Scene Creation (creating the polygons) and Scene Drawing (drawing > them). Since Scene Creation can't be done in parallel with Pre-Scene Creation (with the exception of > some games, and assuming you haven't got enough memory for triple buffering), and Scene Drawing is > done by the GPU anyway, then multi-CPUs aren't going to help in most cases. You can segment space to allow several CPU's/GPU's to work on the same scene (that's how Sega's new arcade system works). You do a quick clip to find which polygons lie in which zones, then split off to work on each zone independantly. Also, Pre-Scene for on frame can be done in parallel with Scene Creation for the previous frame, which is done in parallel with the actual scene drawing of the frame before that... > Cheers, > > James Craig.