Changing Loading Time for ActorsActor loading on startup

[RallosZek]

First of all, I don't have any OpenGL experience, which is why after looking at the code, I'd try this one.

 

Secondly, I'm not entirely convinced, that is an inconvenience that you want fixed, since you might substitute startup slowdown with multiple slowdowns during gameplay (might need to test this in a busy environment, which is hard on test server ).

 

So, I'm going to play around with the code and test various scenarios:

1. Figure out the cause of the slowdown: load/parse all XML but skip the Cal_*/SDL_* parts.
   
2. Split the init_actor_defs and related functions to skip the parts that cause slowdown.
   
3. Add hooks to loading what has been skipped and tie them with dynamic actor loading
   
4. Adjust XML if needed to allow for 'always load this actor on startup'; modify relevant datatypes with a loaded flag.
   

I was also thinking whether it would be possible to load all creatures residing on a map, when changing to a map, but this would make it very easy to find out what creatures are on a map, so unless somebody jumps up and says 'that would be best', I'll skip that for now.

 

As a side note, I might not have a slow enough computer to detect what might be 'significant improvements' to others.

 

Comments? Tips? Objections? If not I'll make an account with berlios and continue coding .

[The_Piper]

Secondly, I'm not entirely convinced, that is an inconvenience that you want fixed, since you might substitute startup slowdown with multiple slowdowns during gameplay (might need to test this in a busy environment, which is hard on test server ).

 

Uhuu, thats exactly the point imho. Imagine a fight and then somehow 10 ppl/creatures are passing by and must be loaded.

 

So, better let it be how its now, load all creatures in advance, who really cares about a slow startup, but DONT load them when they needed. Imagine how that would look like to players with a slow computer.

 

Yes, and guess, how such a fight would end, if the client is blocked for 1-2 seconds loading creatures and you cant heal, when its needed.

 

Just my 2 cents.

 

Piper

[Learner]

Secondly, I'm not entirely convinced, that is an inconvenience that you want fixed, since you might substitute startup slowdown with multiple slowdowns during gameplay (might need to test this in a busy environment, which is hard on test server ).

 

Uhuu, thats exactly the point imho. Imagine a fight and then somehow 10 ppl/creatures are passing by and must be loaded.

 

So, better let it be how its now, load all creatures in advance, who really cares about a slow startup, but DONT load them when they needed. Imagine how that would look like to players with a slow computer.

 

Yes, and guess, how such a fight would end, if the client is blocked for 1-2 seconds loading creatures and you cant heal, when its needed.

 

Just my 2 cents.

 

Piper

The issue is that it is loading every single animal, monster, race, armor, and weapon before it can even do anything. This is only going to get worse as more monsters & equipment are added to the game, so now is the time to start taking steps to come up with a balanced approach.

[RallosZek]

Secondly, I'm not entirely convinced, that is an inconvenience that you want fixed, since you might substitute startup slowdown with multiple slowdowns during gameplay (might need to test this in a busy environment, which is hard on test server ).

 

Uhuu, thats exactly the point imho. Imagine a fight and then somehow 10 ppl/creatures are passing by and must be loaded.

 

The issue is that it is loading every single animal, monster, race, armor, and weapon before it can even do anything. This is only going to get worse as more monsters & equipment are added to the game, so now is the time to start taking steps to come up with a balanced approach.

 

It brings up a point for invasions though. Might need server support to preload invasion monsters, before they're launched, so that not half the people are dead before they see what hit them.

[Entropy]

If someone is going to implement this, make it so that it preloads only the playable races.

[ttlanhil]

personally, I think load on demand is a bad idea.

you have three options, load all data when the client loads, when you need it, or in-between

on load: you waste a fair bit of memory and it takes longer to start up... the second isn't much of an issue to me, though, i'd rather it take longer to start and then run smoothly than the other way around. what we currently have. it doesn't scale well, however

on demand: the game will load a lot faster, but you'll have some lag when you need to load the data, and when monsters show up is the time when lag is the least desirable. also, you either spend a bit of work on unloading unused data or your memory use creeps up to what you get with on-load anyway

in-between: eg, on map change, you load the animals, etc that are known to be on this map. invasions and summons will mean you have to load more on-demand, but that won't be as common. and of course if the client has some warning that monsterX is invading, even if not in visible range, you can clean it up a bit... the problem here is that the client then has to know all the critterage of a map, when there's an invasion or summons elsewhere on the map, etc.

[Learner]

The good news is that if all the XML data is parsed, loading one or two actors on the fly is actually very fast. Before Cal3D that is how all of the actors were handled and the cache manager was used to keep the more recent models in memory and unload those that hadn't been seen in a while. When Cal3D was implemented is when it was changed to all the actors being loaded at startup.

[RallosZek]

Yeah, I see traces of that, which is actually a good thing.

For instance, the actor still knows the skeleton_name, iso just having a ref to the Cal created core model.

[Puntif]

Is it possible to load all the stuff that's needed immediately right away then (perhaps in a "background" thread) load everything else?

[Hyperion]

Wouldn't that slow down your performance untill everything is loaded? thus making your game run less smooth for a certen periode of time

[RallosZek]

Is it possible to load all the stuff that's needed immediately right away then (perhaps in a "background" thread) load everything else?

 

A background thread would cause problems for sure (fight between 'on demand' and 'background', when something comes into view that's loaded in the background) and on the machines you feel it the most it would just move the problem from "before login" to "after login".

I've already added a property to the "actor" element in the defs to allow for loading on startup. And like ent said, all playable races should be loaded before login.

 

Wouldn't that slow down your performance untill everything is loaded? thus making your game run less smooth for a certen periode of time

 

That assumes you meet every actortype in the game in a session.

 

Question:

What happens if I 'meet' 2 .... male orcs. Are the cal created objects in there (like the skeleton) copied or pointers passed and Cal3d works from there to display them?

[Learner]

Is it possible to load all the stuff that's needed immediately right away then (perhaps in a "background" thread) load everything else?

 

A background thread would cause problems for sure (fight between 'on demand' and 'background', when something comes into view that's loaded in the background) and on the machines you feel it the most it would just move the problem from "before login" to "after login".

I've already added a property to the "actor" element in the defs to allow for loading on startup. And like ent said, all playable races should be loaded before login.

 

Wouldn't that slow down your performance untill everything is loaded? thus making your game run less smooth for a certen periode of time

 

That assumes you meet every actortype in the game in a session.

 

Question:

What happens if I 'meet' 2 .... male orcs. Are the cal created objects in there (like the skeleton) copied or pointers passed and Cal3d works from there to display them?

Once the model is loaded for a single type of actor or object, cal3D just uses the data that was loaded once.

[RallosZek]

Little status update:

been working on it on and off.

 

The biggest problem is that some parsed data isn't stored anywhere but passed directly to cal3d. I tried one approach, then started over - I'll have something testable hopefully early next week.

 

It will however be a trade off between dynamic loading and overall bigger structures (and thus memory), most notably, cal_anim will contain 255 bytes more to hold the filename of the animation, which will add up in the actor_types structure.

[Vegar]

Isn't it possible to dynamically allocate memory for the filename?

[Learner]

Isn't it possible to dynamically allocate memory for the filename?

strdup()

[Entropy]

Why the hell would someone dynamically allocate memory for a file name??

[Vegar]

Because a) if the filename is longer than 255 bytes you'll have a problem, and

if the filename is very short, you'll waste over 200 bytes.

Edited April 11, 2006 by Vegar