Path: chuka.playstation.co.uk!news From: sceetech Newsgroups: scee.yaroze.programming.3d_graphics Subject: Re: 3D engines Date: Wed, 09 Apr 1997 11:32:19 +0100 Organization: SCEE Lines: 86 Message-ID: <334B7033.44F8@interactive.sony.com> References: <3347dd19.3248416@news.playstation.co.uk> <3348D38C.1DC1@interactive.sony.com> <334A3648.1873@micronetics.com> <3349266B.7BD4@interactive.sony.com> <3349a345.33045335@news.playstation.co.uk> <334A3058.218B@interactive.sony.com> <334b3a68.199522@news.playstation.co.uk> Reply-To: ps_yaroze@interactive.sony.com NNTP-Posting-Host: 194.203.13.10 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (Win95; I) Alex Amsel wrote: > > Firstly, after writing this reply I had an idea. How about emailing a > questionaire to all Yaroze owners asking questions like 'what did you > expect from the Yaroze?', 'what did you want to do on the Yaroze', > 'what would you like to see?' etc. Afterall, I am pretty opinionated > (nooooo, never!) and could quite easily be wrong. Besides, be a useful > exercise for Sony, and without too many owners it wouldn't take too > long to go over the replies. Hell, I'll do it. > > On Tue, 08 Apr 1997 12:47:36 +0100, sceetech > did quoth at me: > , > >At the moment the Yaroze is still a closed system, ( just like the full > >PS development kit ) with the libraries supplying you access. If you > >want to produce a landscape routine using the Yaroze libraries it > >doesn't have to run as fast as it might do using hand coded asm/gte > >code. That isn't really the point of the Yaroze. > > Appreciated , but the Yaroze /market/ (esp. in Europe) is at least as > much for people who are going to be speed freaks etc. You aren't going > to be getting AMOS programmers etc. using the Yaroze too often because > it requires a sound C basis as well as some 3d knowledge. > > I think perhaps some of us expected something different - like an > almost 'supported' console 'demo' scene. as well as the opportunity to > write a few games. > > >I have seen hundreds of games come in, many using LibGS, and many using > >'improved low level gte'. The performance differences in most cases come > >more from interleaved assembly than any straight change of > >functionality, and there are quite a few that seem to offer less > >performance rather than more. > > Poor programming then! As for interleaved assembly, I'll get into that > - can you recommend a good mips book? The vital point here is that the speed of a PlayStation game is VASTLY more affected by the underlying graphics, game and AI __algorithms__ than by whether it used Gs or GTE. The latter is itself going to make a maximum difference of ~10%; the optimisations available at the level of algorithms, however, are almost limitless. Algorithms, not libraries, make speed. Quicksort implemented in badly written C would always outperform bubblesort written in super-assembler, AND would be faster to develop. Going below the level of libgs is VERY unlikely to provide as much efficiency gain as you hope. > > >With Yaroze the emphasis is more on providing new styles of gameplay - > >original ideas, rather than upping your frame rate from 30 to 60. > > Personally I think both should be joint aims. But then I'm not a major > Japanese company. Wish I was! > > >We will update the Yaroze libraries, but we are very unlikely to replace > >them completely. After all the Japanese site has some excellent games, > >and they use LibPS. > > Only because they don't have a choice. I got the idea that a reason > for the Yaroze (unofficially) was to get more playstation programmers. > Providing only those that use gs is 2nd best to those who can do their > own 3d work. > Very strange to contrast using gs with doing their own 3d work. Using Gs _is_ doing 3d work. The modern trend is towards programmers using powerful, well-implemented APIs to achieve their effects; for instance Yaroze, and the Direct libraries on PC. NOTE that people are less interested than they were in having to reinvent every wheel and cog of (eg) a 3d engine for themselves than they were; that redoing things nowadays takes just as long as before, with progressively less benefit, since the APIs provided grow in efficiency and flexibility. One developer uses APIs, another builds their own engine; the second's game may run 10% quicker, but the first has hugely more development time left. This is the trade-off, and it doesn't favour reinventing the wheel. Can you please give specific examples of what exactly were you hoping to gain by going lower than libgs? It would clarify the issue Lewis