Re: [Algorithms] Asset management/rejection - was RE: Entity Management, Messaging and Traversal

[Conor S. <bor...@ya...>]

Actually, I know a few military contractors who have to use this sort of sc=
heme per contract... =0A=0AAlthough, they use a static array + an enumerato=
r for their memory address locations, so they're documented in-code.=0A=0AC=
heers,=0AConor=0A=0A----- Original Message ----=0AFrom: Tom Forsyth <tom.fo=
rs...@ee...>=0ATo: Game Development Algorithms <gdalgorithms-lis=
t...@li...>=0ASent: Tuesday, October 2, 2007 2:02:52 AM=0ASubj=
ect: Re: [Algorithms] Asset management/rejection - was RE: Entity Managemen=
t, Messaging and Traversal=0A=0AThat reminds me of some companies' rather e=
xtreme attitudes to memory=0Aallocators. They knew their exact working set =
ahead of time, so why use a=0Adynamic allocator? They had what they called =
a "human memory manager", i.e.=0Aduring development you needed some memory,=
 so you emailed Memory Man Bob,=0Awho would open up his Excel spreadsheet, =
give you an address, and you'd use=0Athat one.=0A=0AIt's slightly more extr=
eme than I'd be happy with, but if you're=0Asingle-platform and very discip=
lined, I guess it might work. But it must=0Acause immense hassles during de=
velopment if you change your mind about=0Athings and have to reshuffle what=
 goes where.=0A=0ATomF.=0A=0A=0A> -----Original Message-----=0A> From: gdal=
gor...@li...=0A> [mailto:gdalgorithms-list-b=
ou...@li...] On Behalf Of=0A> Jason Hughes=0A> Sent: Monda=
y, October 01, 2007 10:03 AM=0A> To: Game Development Algorithms=0A> Subjec=
t: Re: [Algorithms] Asset management/rejection - was RE: Entity=0A> Managem=
ent, Messaging and Traversal=0A> =0A> Nick Trout wrote:=0A> > I can see how=
 you request assets (and having a separate asset=0A> management=0A> > syste=
m under your entity system is a good idea); but what you don't=0A> > mentio=
n is rejecting assets. I.e. world streaming console game.=0A> >=0A> > Do yo=
u do any streaming and/or prioritisation? Situations may occur=0A> > where =
you have fragmentation and/or run out of memory. Do you stream=0A> > LODs, =
damaged objects? Do you prioritise loading order and rejection=0A> of=0A> >=
 unnecessary (or lower priority assets)?=0A> >=0A> > What other schemes do =
people have?=0A> >=0A> > Nick=0A> >=0A> =0A> Nick,=0A> =0A> I've been worki=
ng on a system on and off that gives control over some=0A> aspects that I h=
aven't seen in my other work experiences.  Typically, a=0A> level is built =
by assembling the runtime assets required for the level.=0A> This is where =
the memory crunch can occur, and a lot of back-and-forth=0A> with artists a=
nd designers to get them to keep their assets small=0A> enough=0A> that the=
y fit, often without knowing whether the level actually *fits*=0A> until yo=
u fail when loading.  The failure could be from memory=0A> allocator=0A> wo=
es, actual lack of memory, or failing to stream in time for the=0A> transit=
ion (seek time or transfer rates on the edge of a disc, etc).=0A> =0A> My s=
ystem is based on an explicit graph, so I know all the possible=0A> streami=
ng transitions, including GUI pages that pop up but aren't=0A> always=0A> l=
oaded with another level, etc.  Each of these nodes represents a=0A> loadab=
le game state.  The whole thing must load, so I don't have the=0A> notion o=
f "rejectable" data... in a well-designed game, with a=0A> well-designed en=
gine, you shouldn't need to put such a burden on the=0A> CPU=0A> during loa=
d time.  Loading should be dumb and move the smarts to the=0A> tools, IMO.=
=0A> =0A> I can't talk too much about the system I'm working on, because it=
's=0A> something I plan to eventually license once it's built.  But, the=0A=
> feature set is: complete foreknowledge of the loading details, down to=0A=
> the address each chunk should load to burned into the chunk by the=0A> to=
ols; automatic setting of memory budgets per chunk of the game based=0A> on=
 streaming transitions; aggregating shared assets between transitions=0A> t=
o reduce streaming time; and automatic detail reduction of assets to=0A> me=
et the necessary budgets.=0A> =0A> In short, taking human error, memory all=
ocators, and seek times out of=0A> the equation.  :-)=0A> =0A> JH=0A> =0A> =
=0A> ----------------------------------------------------------------------=
-=0A> --=0A> This SF.net email is sponsored by: Microsoft=0A> Defy all chal=
lenges. Microsoft(R) Visual Studio 2005.=0A> http://clk.atdmt.com/MRT/go/vs=
e0120000070mrt/direct/01/=0A> _____________________________________________=
__=0A> GDAlgorithms-list mailing list=0A> GDA...@li...urcefor=
ge.net=0A> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list=
=0A> Archives:=0A> http://sourceforge.net/mailarchive/forum.php?forum_name=
=3Dgdalgorithms-=0A> list=0A=0A=0A-----------------------------------------=
--------------------------------=0AThis SF.net email is sponsored by: Micro=
soft=0ADefy all challenges. Microsoft(R) Visual Studio 2005.=0Ahttp://clk.a=
tdmt.com/MRT/go/vse0120000070mrt/direct/01/=0A_____________________________=
__________________=0AGDAlgorithms-list mailing list=0AGDAlgorithms-list@lis=
ts.sourceforge.net=0Ahttps://lists.sourceforge.net/lists/listinfo/gdalgorit=
hms-list=0AArchives:=0Ahttp://sourceforge.net/mailarchive/forum.php?forum_n=
ame=3Dgdalgorithms-list=0A=0A=0A=0A=0A=0A       =0A________________________=
____________________________________________________________=0ANeed a vacat=
ion? Get great deals=0Ato amazing places on Yahoo! Travel.=0Ahttp://travel.=
yahoo.com/