Game Development Community

Limits to total number of animation sequences?

by Chris Calef · in Torque Game Engine · 01/29/2005 (9:33 pm) · 25 replies

Does anyone have experience running a player with a large number of dsq sequences included in the player.cs file? I'm getting an "out of range write" error (core/bitstream.cc) whenever I try to increase the number of animations past forty or so. The number is variable depending on which animations I include, but there is always a point where it breaks.

I came across a forum thread regarding this error (fix involved increasing a buffer size in game/gameConnectionEvents.cc) and the fix helped a little, but didn't solve the problem. (It went from a cap of thirty or so to a cap of forty or so, but I need a lot more than that.)

Any information as to what's going on here would be most welcome!
Page«First 1 2 Next»
#21
01/03/2006 (5:28 pm)
I ran into this problem about a week ago when I changed some of my paths around. Luckily for me, I spotted that there's code in stock TGE 1.4 that reduces the amount of text sent over the wire by stripping off duplicate path information. Given what's been written above, I'm guessing Ben Garney or someone else implemented the relative pathing code into the shape constructor stuff.

It won't fix 100% of your issues, but if you keep your animation filenames fairly short and keep them all in a single directory, it works fine.

For those wanting to know how to activate it, simply search for the following #define in ts/tsShapeConstruct.cc (should be around line 11 or so).

#define TS_IS_RELATIVE_SEQUENCES 0

... and change it to:

#define TS_IS_RELATIVE_SEQUENCES 1


Nice, neat, and easy.

Given the way that the tsShapeConstructor class works and the manner in which it registers animations with the TSShapes themselves, it probably wouldn't be too difficult to re-organize the code to allow multiple "datablock" definitions to accumulate a list of animations. So you could have a "PlayerBaseDts" constructor which contains all the basic animations, a "PlayerIdleDts" constructor which has all the idle animations, a "PlayerDeathDts" one that has all the death animations, etc.

If I run into any more problems with it, I'll do that and submit the changes to Ben. Odds are the relative pathing will be enough though, so don't hold your breath on it. =)


@Orion Eleenzil
Yes. The packet size limit applies to all characters (and all other DTS models) -- but individually. Each constructor is separate. So it's 1500 per model/character. If you have five characters, they each get 1500 to play with.

Though 1500 characters isn't going to go a long way when you consider that each of your animations, though only three characters in length, also has to include the path information ("starter.fps/data/shapes/player/") -- which is another 31 characters by default.

If you figure that there are 34 characters per animation (the path has 31 and the filename has 3), then you're pretty much limited to about 44 animations per constructor (plus or minus a bit based on other needed construction information). If you switch on the relative pathing, you only end up using 3 characters per animation plus the initial 31 characters for the path. So, assuming the constructor requires nothing else, you could get around 489 or so animation in there.

That being said, try to bear in mind that the .DTS file itself can include a bunch of animations that don't have to be listed in the tsShapeConstructor. You can have as many of those as you like -- it just makes the file a little bigger and slightly harder to work with in max/maya/milkshape.

Edited: Miscellaneous details. Don't touch my porridge.
#22
01/03/2006 (5:42 pm)
Hey Daniel, thanks for the quick and useful info!

I'm looking at i think about 110 animations per character, with somewhat descriptive names.

I'm in TGE 1.3, so
and i'm going to pretty much do the same modifications as listed here,
except that i'm also going to check if the .dsq file has the same name as the animation itself.

That is, for this sequence:
sequence6 = "path/path/path/path/whew.dsq whew"
all that really needs to be sent is "whew".
Chris's changes above i think are sending "whew.dsq whew".

I'm also throwing in a one-bit flag to allow fallback to the regular old fully-qualified sequence etc.

I'll put up a resource if it works well.
#23
01/04/2006 (11:47 am)
So i submitted a resource with a summary of this thread and code.
Folks who've been following this thread might be interested in the resource because it goes slightly further than Chris's (excellent) code above:
* it includes a bit indicating whether the path being sent has been altered or not, so that sequences which don't fit the format will still work.
* it strips off the .dsq
* it compares the filename of the .dsq to the name of the sequence, and only sends one if they're the same.

the pending-approval URL is:
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=9493

thanks again to all who contributed to this!
#24
01/31/2007 (6:38 am)
Hi, warning about the built-in 1.4 fix. After defining TS_IS_RELATIVE_SEQUENCES i'm getting a crash upon mission load: Run-Time Check Failure #2 - Stack around the variable 'pathedSeq' was corrupted. This is happening in debug mode. Do not know about release.
#25
08/26/2007 (5:06 am)
Important note: in shapeBase.h there is also a constant "ThreadSequenceBits" that you need to increase to allow more animations, otherwise the animations beyond the limit of this value won't play despite all the other changes.
Page«First 1 2 Next»