RE: File Access: cache-on-HDD, more

[Christian Reiniger <warewolf@mayn.de>]

hsmith@dockside.co.za wrote:

>regarding disk cache. I worked witha  group of guy's who was working on a game
>and they used a nice system that works like this.
>
>When installing the game, you usually have a minimum, medium and maximum
>install.
>
>They decided that this is not a good way of doing things. So when installing it
>ask you what space you want to allocate for your install, let's say 100MB
>
>so it creates a 100MB file for install .. then when you play the game it reads
>from the cdrom .. and dumps it into the cachefile ( install file ) 

Cool idea (except that I think the reorganization of the *one* file
slows things down).

Hmmm, perhaps we can give the game some ppFReorganizeHddCache () function
to be called e.g. at a level change when the cached data almost completely
changes. Perhaps together with some rc.hddcache file giving hints about
what to cache with which priority at which point in the game, e.g.

--------
[1]   # first game part (see below)
3d/meshes/basicdoor.3d  1  # top priority, is accessed very often
gfx/textures/wall/lvl1* 2  # all level 1 wall textures are accessed quite
                           # frequently
sound/music/danger1.snd 9  # just cache if there's enough space left

[2]   # 2nd game part
.
.
.
--------

and have the game call ppFReorganizeHddCache (n) where n is the number of
the game part (the installer would call ppFReorganizeCache (1) of course).


>This can work well for tile based games .. but can it maybe be applied to 3d
>games as well ??

I don't see any relevant difference between these...

Cu
	Christian
--

Even idiots can handle computers, and many do.