RE: Resource files was RE: [Algorithms] Few Questions About Racing...Again
Brought to you by:
vexxed72
Menu
▾
▴
RE: Resource files was RE: [Algorithms] Few Questions About Racing...Again
|
From: Michael P. <MPo...@cy...> - 2002-08-07 18:41:29
|
He means the EE and IOP take care of streaming. The EE sends requests to a streaming-thread on the IOP to load data off the cd. Cheers -----Original Message----- From: Chris Butcher (BUNGIE) [mailto:cbu...@mi...]=20 Sent: Wednesday, August 07, 2002 2:17 PM To: Killpack, Chris; gda...@li... Subject: RE: Resource files was RE: [Algorithms] Few Questions About Racing...Again Er... when you say "there are two processors on PS2", surely you don't mean that your VUs were actually generating the requests to stream a given resource? Every architecture I've looked at has simply used them to handle data once it was already available... [Apologies for the slightly platform-OT nature of this post] -- Chris Butcher AI Engineer | Halo Bungie Studios bu...@bu... =20 -----Original Message----- From: Killpack, Chris [mailto:Ch...@ea...]=20 Sent: Tuesday, August 06, 2002 18:54 To: Shawn Baird; Gottfried Chen; gda...@li... Subject: RE: Resource files was RE: [Algorithms] Few Questions About Racing...Again This sounds similar to the system used on Freekstyle. We organised the files in our monolithic archive into two groups. The first group was all files that (for a particular archive) were always loaded. The other group held all the remaining files that could be needed depending on the game situation. These groups were called DATA and STREAM respectively. When an archive is opened the file manager reads from the DATA group until it reaches the end. As each file is read from the archive it is dispatched to the relevant handler in the code - meshes go to the mesh manager, textures to the texture manager, etc. So rather than a system requesting resources, resources are 'pushed' to systems. The STREAM section is used in the more traditional way of an archive - game systems issue requests to load data (the seekable section if you will): "Load chosen character's ingame models". These requests are only granted once the DATA section has been read. The advantage of this system is that it keeps CD seeks to a practical minimum. Which translated to fast load times for Freekstyle (esp. on gamecube). There is a lot more to it than this though. Especially when you realise that there are two processors involved on PS2. I leave that as an exercise to the reader. Chris -----Original Message----- From: Shawn Baird [mailto:sb...@tr...] Sent: Tuesday, August 06, 2002 5:40 PM To: Gottfried Chen; gda...@li... Subject: Re: Resource files was RE: [Algorithms] Few Questions About Racing...Again While this is an okay back end solution to the problem, I think one of our programmers here has the right idea. He proposed and we eventually implemented a system where the data drives the load. It is still a single file with no seeking going on, but the data encountered controls what is loaded in next. This works pretty well, especially if you have a make driven asset system (we call the generated files pack files). I wish we still had the ability to run from cached files (actually we do but nobody uses it since it was only recently added). You'll get similar speedups, but without some of the frustration of the back end thing. Ideally you do as little processing on this loaded data as possible. Of course it isn't too hard to find yourself in a situation where only the back end technique is straightforward. We had to make some pretty radical changes to the engine we were working with to make the switch. The previous version, by the way, used the capturing technique to set things up (we called them stash files). Somewhere in the middle of the project when we had broken stash files and hadn't finished implementing pack files yet we had load times off of CD of 6 minutes. :) We're now in the sub-15 second range with room to improve. -- Shawn L. Baird (sb...@tr...) ----- Original Message ----- From: "Gottfried Chen" <got...@ne...> To: <gda...@li...> Sent: Tuesday, August 06, 2002 5:02 AM Subject: AW: Resource files was RE: [Algorithms] Few Questions About Racing...Again What you can also do besides having a filesystem that can deal with big WAD like files and single files is that before you ship to capture the whole loading process of loading a level into a single stream and save this stream as a single file that can later be played back like from a tape. All file routines are captured when you build the stream (like open/close/seek calls) and are also saved into the stream and played back when you load it. The stream is also compressed and loaded asynchronously during level loads. This really speeds up the level loading times. We did this for the MaxPayne Xbox version and we got up to 4 times loading speedup compared to the single monolithic file only version. Especially on consoles this is very helpful since you load from CD/DVD, random access is slow and then you got some TCRs requiring you to load a level under e.g. 15 seconds. ----------------------------- Dr. Gottfried Chen Senior Programmer neo Software Produktions GmbH A T2 Company email: got...@ne... web: http://www.neo.at > -----Urspr=FCngliche Nachricht----- > Von: gda...@li... > [mailto:gda...@li...] Im Auftrag von=20 > Jason Williams > Gesendet: Dienstag, 06. August 2002 10:58 > An: gda...@li... > Betreff: RE: Resource files was RE: [Algorithms] Few Questions About=20 > Racing...Again > > > > > Or do both: look for the most recent data registered file systems, > > > then zip files, etc. > > > > Yep, that's how our resource loading system at ISA works. We=20 > > actually do our zip loading implicitly; we look for files in the=20 > > actual directory tree first, and on failing check within zips that=20 > > are essentially spoofed directories. > > > > It makes our resource finding a bit slower, [...] > > I simply use a compact index for my WAD. > This is loaded from the main WAD on startup, and then if there are any > "patches", the existing index entries are redirected to point at the=20 > new resource location. This makes startup about a nanosecond slower,=20 > and then after that there is absolutely no performance hit for the=20 > location of "patched" resources. (Although when you go to actually=20 > load them you will still get extra seeks of course) > > Not that we ever actually need to do patches of course :-) > > Jason > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf=20 > _______________________________________________ > GDAlgorithms-list mailing list GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 |