11 replies to this topic

[William Imm]

Hello, I have a feature request to make:

I think a few of you may have heard of Suslik's problems with stuttering in a BWP Baldur's Gate game http://www.shsforums...he-stuttering/'>here. The same problem exists in PS:T as well, just not as prominent. Well, I want to see his/A64's fix for the problem in PS:T. However, I don't know of a way to do so without creating a TobEx for PS:T (which would be awesome), but I feel like this is something to defiantly include in a future release of the fixpack.

[i30817]

Never happened to me... the game hasn't that many mods.

[William Imm]

This is the reason why I brought this request up.

Edited by William Imm, 11 May 2012 - 01:59 PM.

[Sasha Al'Therin]

The question is if PST's handling of variables is like BG2 or like BG1. BG1 is a hardset value which Zed Nocear has discovered and sets to a higher value for BG:ToTSC. BG2 is more of a expandable type of handling which I guess can get too large and cause problems.

[William Imm]

It does sound like PS:T uses a dynamic variable system like BG2 according to the fact that trebonus appears to be experiencing the same stuttering problem as in BG2 (he said that that game, as well as BG2, exhibited it the most).

Then again, someone like scient needs to confirm that in the exe.

[ghostdog]

Have you tried the Ddraw fix for slowdowns/stuttering ?

[William Imm]

Have you tried the Ddraw fix for slowdowns/stuttering ?

Are you talking to me or to trebonus? If you are talking to me, then I've never really had any slowdown/stuttering problems, but I liked the fix for some flickering I had while playing the game (I posted on that, remember?). If it's trebonus, then it sounds like he hasn't tried it yet.

[scient]

I can have a look, but PST code base is closer to BG1 than BG2 for IE.

[William Imm]

Go have a look. If it does use the flexible hashmap, then go ahead and implement away.

[scient]

It looks like PST uses BG1 style memory storage of variables. It takes the string of variable in question (global, local, kaputz, etc) and passes it to a hash function. This will create a value ranging from 0-4096. It then uses value to look up in memory the VAR location. Basically something like code below, where dword_8E3810 is constant table for hash.

int var_table_hash_id(char *lpszVarName, int nLen)
{
int v1; // ecx@0
unsigned int v2; // ST2C_4@6
int v3; // ST10_4@7
signed int v5; // [sp+0h] [bp-34h]@2
signed int i; // [sp+20h] [bp-14h]@4
int v7; // [sp+24h] [bp-10h]@1
signed int v8; // [sp+30h] [bp-4h]@1

v7 = 0;
v8 = 1;
if (nLen >= 32 ) v5 = 32;
else v5 = nLen;
for ( i = 0; i < v5; ++i ){
   v2 = dword_8E3810[i] * (lpszVarName[i] & 0x2F);
   v7 += v2;
   v8 *= v2 % 4096;
}
v3 = (unsigned int)(v8 + v7) % 4096;
_dealloc(&lpszVarName);
return v3;
}

I'm actually curious if it's possible to create collision with certain VAR strings (ie. two different strings with same hash). But as for causing the game to lag, I don't really see that happening. The amount of time taken to look up global is really dependent on how long var string is.

Edited by scient, 07 June 2012 - 03:05 PM.

[scient]

Follow up to this. The way it handles duplicate var hash id's is that it will keep incrementing from initial id until it finds it or reaches null var location. In this sense, there may be some added delay because it has to loop through if there are multiple duplicates. Honestly, I don't think this will cause a lot of slow down. Everything has relatively fixed address. I mean, there could be instances where new var has low var id but only free space is at very end. So it has to loop through a lot of var till it finds it. But this might be couple var at most, I don't really see this causing lots of problems.

I could optimize the look up loop some, remove some of extraneous debug ASM op codes. This would decrease CPU time slightly, not sure if it would be significant.

Edited by scient, 08 June 2012 - 09:11 AM.

[scient]

Well, I cleaned up the var id look up function by removing a couple of redundant calls and local variables optimizing the loop. This only really matters when the variable id has duplicates and has to loop through to find it. Loading of saved games seem to be slightly faster but this might be placebo effect. If someone has late save game and experienced any kind of slight lag/delay I'd be willing to apply patch to exe to see if that resolves it.