Path: chuka.playstation.co.uk!news From: Craig Graham Newsgroups: scee.yaroze.freetalk.english Subject: Re: An adventure project Date: Mon, 07 Jun 1999 11:11:44 +0000 Organization: Data Uncertain Lines: 52 Message-ID: <375BA8F0.A51D20C4@hinge.mistral.co.uk> References: <3759079a.1869875@www.netyaroze-europe.com> <375b033f.286182@www.netyaroze-europe.com> NNTP-Posting-Host: d3-s52-212-telehouse.mistral.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.2.0 i586) X-Accept-Language: en Barry & Robert Swan wrote: > > Blimey, this is a nice few responses... > > I had a look at the cyclone demo, it worked, I never thought more > about it until now when I could really use it. Now I'll have two file > servers to look at. And I was seriously considering CodeWarrior... > btw, does CodeWarrior have a half decent debugger? Its only since > getting my job that Ive realised how much effort they save, Ive im > love with them. Nice of Sony to supply the gdb docs with the Yaroze, > not. We did our last (pro) project in CodeWarrior. The debugger is pretty good (at least in the ProDev4 version - if you're at SCEE, I expect there's a couple of copies kicking around). It works fine with the Yaroze (although there's a bug in the comm's DLL for the yaroze in later versions, so you have to replace it with an earlier one). Also works a treat with the H2000/H2500/H2700 as well (you get an extra GTE register view on them that the yaroze module doesn't support). > In terms of graphics format with rsdanim, that would be great. That > certainly isnt going to be rushed though, as Ive got to make sure that > the format does everything that I want it to before committing > (currently each vertex has 3 sets of RGB data; don't ask...!) Guessing the 3 RGB sets are..... original (local static lights on) original (local static lights off), current (product of original+any dynamic lights). > I do need to write some better way of handling the graphics and data > files. I know some people have written programs to do this, but in the > current state they wouldnt help much. So what Im hoping is that people We alway's just malloc'ed a buffer for the object files after first loading the whole of the used VRAM as one big compressed TIM. > What else? oh yeah, maybe the compression routines that someone wrote > might be useful, although with file server functionality it may be a > moot point. Must admit I was planning on using VRAM for some array > storage though, so maybe it would remove the necessity for that. For a serial server (as it's dog slow compared to the ARS fileserver or the one on the devkit) the best thing would be for Nathan to add transparent compression to the fileserver and it's library (I never bothered doing it for ARS 'coz the link is so much quicker). You'd never notice it was there, but stuff like TIM's would be shit load's quicker to download (even RLE'ing the average TIM improves things loads). Craig.