Have you tried reading the Hourglass development thread? I'm probably wrong, but this question was asked, like, every two pages. There is no short answer.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Actually, yes it is, I've done it before.
1. Start a new game on any level of Half Life 2 (or Portal, Half Life 2 Blue Coast, etc.)
2. As soon as you have control, press ~ on your keyboard to open the developer console
3. Enter "record [name of demo]" without quotes, then enter "host_timescale 0.1" without quotes (make sure you type sv_cheats 1 first or it won't work)
4. Now start playing, but make sure every thing you do is direct and straightforward; also to entertain your audience, mess around a bit while waiting for stuff to happen, I. E. throw objects around, hit stuff with the crowbar, turn the flashlight on and off repeatedly, scroll through your weapons really fast, anything to pass the time
When you're done recording, go back to the console and type "stop" and it should say "Completed demo, [x] frames, etc."
When you want to watch, type "playdemo" and then the name of your demo you recorded. If host_timescale is set to 1.0, everything you just did in slow motion will look like Gordon Freeman smoked a metric **** ton of crack.
Hope this helped! Let me know what the end result was.
A wise man once said "Damn, that's one hell of a steak."
Haven't looked into rerecording, but my guess is for rerecording you could just save at a certain point and when something screws up you can load up that save. As for slowdown, yeah. Just play the game slowly as possible like you would on an NES emulator, for example. I'll have a video up in a bit about it.
A wise man once said "Damn, that's one hell of a steak."
Joined: 8/3/2004
Posts: 100
Location: Michigan, United States
I imagine this would be quite a bit different from the TASes we are used to seeing here. Having played plenty of Source engine games myself, I doubt turning the timescale down will bring gameplay to the granular level of frame-advance TASing, where you are dealing with the absolute limits of a game's engine.
I'm sure camera movement would not be sluggish at a reduced timescale, nor would the framerate. These kinds of advantages, while technically still a form of tool-assisted play, I think might break the barrier of what could be accomplished in real-time, and perhaps may go against some of the philosophies here, I'm afraid.
If for instance you play at 60fps, and you reduced the timescale down to 0.1 while still technically getting 60fps (and I assume therefore still recording inputs at 60fps), then playback at normal speed would mean 600 inputs/sec.
*shrug* Maybe the only reason we don't have TASes with that much temporal resolution yet is because we don't have any systems emulated with re-recording that would benefit from it yet.
Just some thoughts.
If for instance you play at 60fps, and you reduced the timescale down to 0.1 while still technically getting 60fps (and I assume therefore still recording inputs at 60fps), then playback at normal speed would mean 600 inputs/sec.
I remember reading some notes from someone who was TASing Portal, and I got the impression that the source engine uses discrete physics ticks at a set rate. The Source console even has a way to use frame advance, and in that case a frame is a predetermined length.
Though again, this is just the impression I got from this guy. You'd probably need to do some digging to verify all this.
Joined: 8/3/2004
Posts: 100
Location: Michigan, United States
BrotherMojo wrote:
I got the impression that the source engine uses discrete physics ticks at a set rate.
Same here, though I assumed the tick rate was tied to the display refresh rate for the sake of efficiently conveying smooth motion. I believe the tick rate can be set independently of both timescale and frame-rate, however, which leads me to believe physics engine motions are vectors rather than hard-set keypoints.
BrotherMojo wrote:
Though again, this is just the impression I got from this guy. You'd probably need to do some digging to verify all this.
Haha, so true. Gotta love how we're both sitting here with the internet (answer) at our fingertips and yet we choose to speculate =D
I remember reading some notes from someone who was TASing Portal, and I got the impression that the source engine uses discrete physics ticks at a set rate.
Nope. Even in regular gameplay, FPS changes have an effect on physics. Variations in FPS affect, amongst other things: falling damage, firing speed and NPC behavior.
Even in regular gameplay, FPS changes have an effect on physics. Variations in FPS affect, amongst other things: falling damage, firing speed and NPC behavior.
Really? Ugh. That's one of my game programming pet peeves. :/
