Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

DDR and Control Lag...

Seven Shikami
Registered User
Join date: 22 Sep 2006
Posts: 82
02-17-2007 22:31
I'm working on a Dance Dance Revolution game. I know this is possible; Promenade Breakout works under the same principles.

1. You keep a scrolling list of expected inputs.
2. Every time interval, you drop the current one and append a new one to the back.
3. When a control input comes in, you check it against the current expected input. Match, points, fail, miss.

I have a bigger version with prim-based arrow board and so on, but it has the same problem that the following dirt-simple, drop-it-in-a-prim-and-go proof of concept version has. At one second or larger time intervals, it's fine. But any faster, notably 0.5s, and the controls lag... you can see in the readout that it's getting the arrows one step too late.

This shouldn't be a problem. Promenade Breakout doesn't have this problem. It's not my skill at DDR stinking on ice; 0.5s is 120bpm and I can play 150's without problems on Stepmania. Why is it that the control procedure seems to lag behind?

Attached is the proof-of-concept version.

CODE
integer toggle = 0;
// Just a flag to see if the game's running or not.
list expectations = [0,0,0,0];
// Storage for current input and three upcoming inputs.
list mappings = [".","<","v","^",">"];
// This lookup table is so we don't have to memorize what number is what arrow.

default
{
touch_start(integer num_detected)
{ if (toggle == 0)
{ toggle = 1;
llRequestPermissions(llDetectedKey(0), PERMISSION_TAKE_CONTROLS);
llSetTimerEvent(0.5); // Fast speed; works fine at 1.0 seconds
}
else // the second touch means 'I'm done playing the game, lemme go'
{ llReleaseControls();
toggle = 0;
llSetTimerEvent(0.0);
}
}

control(key id, integer held, integer change)
{ integer player1input = 0;
// Integers are 1 = left, 2 = down, 3 = up, 4 = right.
if (~held & change & CONTROL_FWD) { player1input = 3; }
if (~held & change & CONTROL_BACK) { player1input = 2; }
if ((~held & change & CONTROL_ROT_LEFT) || (~held & change & CONTROL_LEFT))
// Gotta check both, in case they used mouselook or arrows vs. wasd.
{ player1input = 1; }
if ((~held & change & CONTROL_ROT_RIGHT) || (~held & change & CONTROL_RIGHT))
{ player1input = 4; }
if (player1input == 0) { return; } // In case it wasn't really a keypress, just bail.

llOwnerSay("Expectation: "+llList2String(mappings,llList2Integer(expectations,0))+" Input: "+llList2String(mappings,player1input));
// Tell the owner what the game wanted, and what they actually input just now.
}

timer()
{ expectations = llDeleteSubList(expectations,0,0) + [llRound(llFrand(3.0) + 1.0)];
// Delete the front item of the list, append a new one to the back.
llSetText(llList2String(mappings,llList2Integer(expectations,0))+" "+
llList2String(mappings,llList2Integer(expectations,1))+" "+
llList2String(mappings,llList2Integer(expectations,2))+" "+
llList2String(mappings,llList2Integer(expectations,3)),<1.0,1.0,1.0>,1.0);
// Displays the expected item first, then the next three expected items that will be comin' up.
}

run_time_permissions(integer perm)
{
if (perm & PERMISSION_TAKE_CONTROLS)
{ llTakeControls(CONTROL_FWD | CONTROL_BACK | CONTROL_ROT_LEFT | CONTROL_ROT_RIGHT |
CONTROL_LEFT | CONTROL_RIGHT, TRUE, FALSE);
// A basic control snatch.
}
}


}
Ziggy Puff
Registered User
Join date: 15 Jul 2005
Posts: 1,143
02-20-2007 16:10
Well, list operations are slow... maybe the time taken to run the full timer event + time taken to run the full control event == too close to 0.5s? Events are queued, and processed in sequence. Maybe try inserting some timestamp calculating code, and print those, and see how long it takes you to run the events. Make sure the debug code is light, you don't want yoru debug code itself slowing down the functions. So no string operations, just print a number on function exit saying how long the function ran for.

I'm not sure if that's the issue, but it's one possibility.