Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
OnyxStar

New PRBoom Demo Builder

Recommended Posts

Hi,

It has been over 10 years since my last post! I have an edited version of PRBoomPlus that I'm hoping you guys will like. (If you don't remember, I previously made a walk-cam mod and a not so great TAS demo of HR2)

I think making/watching TAS demos is really fun, however there is definitely a high barrier for entry, and it takes a lot of patience to make a reasonably good demo. My goal was to make it easier to create TAS demos.

Binaries: http://www.mediafire.com/download/oo8yqmfdh83fszt/PrBoomPlus_DemoBuilder.zip

Source: http://www.mediafire.com/download/3h5aq1v332eq994/PrBoomPlus_DemoBuilderSource.zip

So what does it actually do? As you are playing the game, quicksaves will automatically be happening. When you press the new navigate key (defaults to N), the game will pause and you can jump back and forth between saved frames. Pressing the navigate key again will continue from your currently position.

Even better, if you are recording a demo, it will automatically fix the demo anytime you use navigate. As an example, say you are playing through a map, but you make a mistake and die. Press navigate and go backwards to before you died, press navigate again, and keep playing. The recorded demo will look like you never died at all.

Finally, your 'frame history' is saved along with your demo. Using the new record continue option, you will start paused at the last save frame with all the demo information loaded. Navigate to where you want, and continue on. No more waiting for the demo to play all the way to where you left it!

Here are the new command line options you need to use:

-framesave : Need to actually save frames. You can use this even without demo recording to navigate between frames as you play. Pair with -record or -recordcontinue to build a demo.

-recordcontinue <demoname> : Loads the demo you were recording previously. You need to have been recording with -framesave or there won't be a file needed to read the saved frames.

Here are some example uses:

glboom-plus -framesave -record test_demo

glboom-plus -framesave -recordcontinue test_demo

---

I've only tested this with doom2 1.9 demo compatibility in PRBoomPlus. As you might expect, I make no guarantee that everything will work perfectly. If you run into any troubles I'd be curious to hear what they are.

Extra details: You can edit the navigate key in the key bindings menu. (I like using Q since I can quickly press it) You can also edit the frequency of saving frames. It defaults to every 50 frames. If you go much lower than that it becomes a pretty big memory hog, but that's probably not too bad on more modern PCs.

The keys to navigate frames are tied to your movement keys. The strafe left and strafe right keys will move back/forward in the frame history, one save at a time. So, if you are saving every 50 frames, it will move back/forward 50 frames. If you press the move forward or move back keys, you will navigate 50 histories back/forward. (So, 50 times 50) I use W,A,S,D to move, so my A and D keys move me back and forward respectively. S and W move back and forward in the bigger amounts.

When you use -recordcontinue you'll notice a weird graphical glitch where you seem to be at the beginning of level 1. Just start navigating and it will correct itself. I was too lazy to figure it out, but it really doesn't impact demo creation.

This may be confusing, so let me know if you have any questions. Also, I'm definitely interested to hear if people enjoy using it!

Share this post


Link to post

Cool! How does it work? Do you dump the current thinker list to disk every 50 tics, and then overwrite the list in memory when you navigate forward / backward in time?

Share this post


Link to post

It does a full quicksave every 50 tics (by default). The saves are held in memory and also written to disk if you are recording a demo. Navigating loads a quicksave each time you choose to move back and forth in the history. They are stored in order so you can jump back and forth between them.

Share this post


Link to post

But quicksaves don't save 100% of the information about game state (like monster wake state, perhaps most obviously). Did you extend the quicksave format to cover everything? Or does prboom already fix this? (Which seems more likely I guess.)

Share this post


Link to post

Not even PRBoom's is complete, as it lacks an exact order of the blockmap (as far as I can tell), among other lists. That is very sync dependent.

Share this post


Link to post
Edward850 said:

Not even PRBoom's is complete, as it lacks an exact order of the blockmap (as far as I can tell), among other lists. That is very sync dependent.

Interesting. In most cases, it doesn't matter, since you're restarting game play.

The real question is: Does it save enough data to maintain demo compatibility, and, due to the nature of the project, I would guess that answer was a solid "Maybe". Here's a good question: Can you save your demo-in-progress, stop the program, and start it back up later, and create a demo that plays in sync?

Here's something else I have been wondering for some time. A neat experiment:
What would happen if you added some code that would perform a SaveGame, followed immediately by a LoadGame, and you wrote code to make that happen, say, every 5 tics. Then, run the game, and play a demo. The question is, would the demo stay in sync? That might be a really good diagnostic tool to ensure that you were, in fact, saving enough data in your save game. I'll have to try this eventually :)

More on topic: This is a neat idea! Those few seconds it saves you really make the difference. It's the tedious stuff that makes projects fail, and you've eliminated a lot of that. Good job!

Share this post


Link to post

Next time I want to do FDAs for a WAD I will probably use this and just rewind whenever I die and spin in place to indicate it or something.

Share this post


Link to post
kb1 said:

The real question is: Does it save enough data to maintain demo compatibility, and, due to the nature of the project, I would guess that answer was a solid "Maybe". Here's a good question: Can you save your demo-in-progress, stop the program, and start it back up later, and create a demo that plays in sync?


I haven't tested a huge range of maps, but so far it has stayed in sync. I was messing around with Doom2 map11. I would start a demo, intentionally 'screw up', navigate back, etc. Then I'd exit the game, use the -recordcontinue feature to continue from where I was, and do this whole thing several times. (So I'd quit the game several times) When I play the demo back it's still in sync.

I'm definitely hoping to get more test cases by having people use it. I've been mostly proving the concept out to myself each step of the way. Maybe it has some flaws related to questions/thoughts in previous posts, but surprisingly I haven't seen it fail yet.

Share this post


Link to post
OnyxStar said:

I haven't tested a huge range of maps, but so far it has stayed in sync. I was messing around with Doom2 map11. I would start a demo, intentionally 'screw up', navigate back, etc. Then I'd exit the game, use the -recordcontinue feature to continue from where I was, and do this whole thing several times. (So I'd quit the game several times) When I play the demo back it's still in sync.

I'm definitely hoping to get more test cases by having people use it. I've been mostly proving the concept out to myself each step of the way. Maybe it has some flaws related to questions/thoughts in previous posts, but surprisingly I haven't seen it fail yet.

Good deal. Of course, that test has a better chance of staying in sync, cause you're adding to the demo from the load point. That second experiment would be definitive, and I honestly do not know what success you may have. The blockmap list ordering that Edward850 mentions could have an effect. Essentially, you'd be proving that the save game is vanilla demo-compatible, which would really be something great. Luckily, it's not a scenario that normally occurs, but it could be an issue:

For example, imagine a feature in which you allowed a player to join an in-progress game. You could do a save from an existing client to the new computer, which would load the game, and join in. If all clients reloaded, it should work, but what if only the new computer did a load? In that case, you would want your save file to perfectly emulate the environment of the other PCs, or else it would eventually go out of sync.

Anyway, I haven't had a chance to try your code yet, but I'm looking forward to it.

Share this post


Link to post

That's neat. Personally I would have taken a different approach: saving every 50 tics is quite often (that's less than two seconds between frames). Might be more efficient to save every eg. 10 seconds, and then incorporate a "fast forward" replay so that you can load the last frame and then seek forward to the tic you want.

Share this post


Link to post

This is like the best thing i've ever seen, which will make me record a lot of uv-max slaughtertases (okumap, i'm looking at you!) if/when it gets improved. But still, in its current state, this demo builder is a handy and neat tool already, nice job.

Decided to test it out in the worst environment ever: complevel 9 + revenants + 1k monsters waking at once. It was extremely fun to play around with frame history, but sadly the demo always desynced for me when i tried to play it back. I guess prboom's quicksave system needs to be modified to store more info. DRE & xdre developers might know a thing or two about that.

Share this post


Link to post

Any updates on this? Not having to wait sounds awesome but jongo's feedback on desyncs is worrying.

Share this post


Link to post
jongo said:

Decided to test it out in the worst environment ever: complevel 9 + revenants + 1k monsters waking at once. It was extremely fun to play around with frame history, but sadly the demo always desynced for me when i tried to play it back. I guess prboom's quicksave system needs to be modified to store more info. DRE & xdre developers might know a thing or two about that.


basetic vs. gametic issue in A_Tracer? Maybe PRBoom Demo Builder does not manage basetic in saves/loads? (Normally, basetic does not need to be saved, cause it's set to 0, but, for something like this, maybe it's necessary?)

	if ((gametic - basetic) & 3)
		return;

Share this post


Link to post

So... I tested your stuff. Not so good as i expected.
Very high chance of desync. For example tried Doom2 map22 -complevel 2 and everything was fine until:
1) I don't see what a time of demo and speed of slow-mo. // For me it's too important to know how fast i am and what a speed of game now. Because i manipulate speed by wheel of mouse.
Also AV jumps i'm controlling by time which i can't see... Awesome.
2) When i started watch my demo, desync happened in 1/3 of whole time of demo. It's even worse than i expected. I thought i can use that Tool and rerun by another PRBoom but your tool destroying everything.
3) Non-segmenting. I'll explain. For example I'm making UV-MAX. Tried a few routes and comparing their after.
So i just can select demo where looks fine for time and for me. Here I must to be perfect and must know route. It will take much longer to make demo.
//Yeah i just can copy demos and rerecord after but i got used to when PRBoom doing it automatic
I hope problems with desync and HUD will be corrected.

Share this post


Link to post

Oh yeah... Forgot to add that it's crashing on another complevel.
But it's useful if you want avoid savestates and finish wad or level in such way.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×