Am Dienstag, 13. Februar 2007 schrieb Per Inge Mathisen:
> On 2/12/07, Dennis Schridde <[EMAIL PROTECTED]> wrote:
> > I was just experimenting with automatic unloading of unused resources.
> > So when we get an "Out of memory" error when trying to load a resource,
> > it would try to free resources which were not used for some time, to free
> > some memory.
>
> If you run out of memory loading Warzone data, you have bigger problems.
> IMHO.
>
> In my experience, dealing with out of memory situations is rarely
> worth the effort unless you really _need_ to, and I do not think
> Warzone has the amount of data that makes it necessary.
>
> I have not had the time to look closely at your lua work yet, but it
> sounds really cool.
Minor update:

-----------------------------------------------------------------
Revision: f7d87937830fb22f0d13cc06340c31064b12f197
Ancestor: f8e7e3ea39730b171bf20ea65e5ded615e685d5f
Author: [EMAIL PROTECTED]
Date: 2007-03-08T15:52:17
Branch: wz2100.wrf_lua

Modified files:
        Makefile main.c resource_manager.c resource_manager.h
        resource_manager_internal.h

ChangeLog:

- Strip parent parameter from WRF_getResource as it will usually not be used
- Remove WRF_Module as a result of the above
- Remove a litte bit of recursion in initResources/initModules (after all this 
is not Scheme ;) )
- Remove SizeImpl, Per brought me back on the floor...



I am currently thinking about: What is the benefit of storing the resources 
per module instead of in a global list?
My current ideas on this topic:

- In case you have some very big modules, finding a resource in a smaller 
module would be made slower because of all the foreign resources in the 
global list. When you keep the resources in per module lists, you don't have 
that "problem".

- Having them all in one global list would probably make the code a little bit 
cleaner, even though we might get into a problem when resolving cross module 
dependencies. (The resolving of resource deps would have to be moved to a 
position later in the code...)

- By forcing the user to specifying "module_name:resource_name" as a name when 
calling getResource, name conflicts are automatically prevented. (Well, as 
long as you provide reasonable modulenames...)
- This could of course also work if you would give each resource a prefix with 
your modulename, but problems with this would be:
  - Modders will tend to be lazy and forget it.
  - You could still get clashes when a modder uses/copies a resources from 
another mod. Suddenly you would not have new_mod:coolres and 
orig_mod:coolres, but 2 times orig_mod_coolres... (Copy and paste is so 
easy...) When orig_mod updates it's coolres, new_mod could get into problems. 
TES3:Morrowind users will know what I talk about...
- The clash of filenames that might occur in the latter example could be 
prevented by forcing each mod into it's own subdir. Eg. "--mod new_mod" 
searches for mods/new_mod and mods/new_mod.wz/new_mod

--Dennis

Attachment: pgpkTgjMjm1i2.pgp
Description: PGP signature

_______________________________________________
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Reply via email to