ZDoom

Fair enough .

Stuff for later. I'm also not saying that the engine will never be able to play demos again, just not the original ones. I still hope that I can get it to a state where it can just record input like ZDoom does and play it back later.

Now that demo support for Blood has been removed, I think the startup and console messages regarding the presence and availability of demos in the game should be removed as well.

The "Demos" folder also still gets created in Raze's root directory when running Blood, if I delete it manually it reappears every time.

Graf Zahl wrote:The change that broke it was probably elsewhere, like in the collision or hitscan code which are both parts of the engine. Build games' play code should be as insensitive to rendering as Doom is.

Let's also not forget that Blood was the ONLY game here that could play demos, in all the others it was already disabled.

It could be collision related, the player does bump into some things when the desync occurs, which normally shouldn't happen, and the dynamite hits the player directly instead of being avoided completely.

The thing here was that Blood was kind of the "special one", but life moves on, since unlike with Doom, it was too much pain to keep working (in fact, demo support is mostly equal with no deep but needed refactorings in this case, so which one is worse?).

The change that broke it was probably elsewhere, like in the collision or hitscan code which are both parts of the engine. Build games' play code should be as insensitive to rendering as Doom is.

Let's also not forget that Blood was the ONLY game here that could play demos, in all the others it was already disabled.

That demo compatibility is broken by changes in the renderer says that demos in Build are not sensitive just to gameplay code, but also to code that should be irrelevant.

In Doom you can actually run demos without rendering anything, this is in fact used for regression testing in demo-compatible ports (run a demo as fast as you can actually run the pure gameplay code, without rendering audio or video output and without pausing tics to make them last 1/35th of a second; then compare the game situation at the last tic of the demo with what's expected; if you have the same actors with the same position, health, etc. vales then the demo didn't desync).

And thus demo compatibility endeth.

I knew it was coming (obviously), but to further expand a bit on Graf's point: Demo compatibility in the Build games, unlike Doom, is actually far too much of a roadblock that prevents some much needed, and major refactorings of the engine and the games, so it is essentially a pointless battle that doesn't go hand in hand with the philosophy of Raze - having an actual, fully modern Build engine source port. But sadly this means that it will have a future where demo compatibility will not be possible as we'd just be stuck endlessly chasing our own tail.

However, this doesn't mean that Raze will now turn into Fresh Supply 2.0, in the sense that it will soon start having HUGE behavioral differences from vanilla. It may lose demo compatibility for good, but the goal is still to offer an experience that is faithful to the original games. Besides, not all hope is lost, maybe it will return in the future, or maybe not, we'll live and see. But if it does not, NBlood and GDX can fit the role of demo compatible ports, while Raze can be its own thing.

If such changes affect demo playback I'll no longer try to keep it operational. It was nice to have the demos play to a certain degree but there's surely more to come in terms of restructuring so it'd be a futile battle between modernizing the engine and keeping everything in a state where demos still play.
As there's also issues with sound during demo playback it all sounds pointless. I personally found the demos disruptive enough to add a CVAR to disable them.

I'll need some feedback from Graf as to whether the engine is meant to remain demo compatible or be a demo-breaking engine before spending more time on this.

The de-sync issues as per HEAD start here, get worse here, then return to how it currently is in HEAD here

Please note I've only gone through the commits as per the commit history affecting source/blood and not all commits since the issue. It's possible that backend changes are the cause and not game-side code, but there's just soo much to go through.

Thanks for the feedback, I'd suspect the pause changes are the blame for this. I'll take a look on the weekend.

Just downloaded a devbuild of NBlood from today after taking a while to find the devbuilds page (which has since been added to its Git page, apparently).

Confirmed regression, the demo stays in sync in the NBlood build from today. Something either changed or is missing from Raze. Changed the title of the topic accordingly.

Basically the demos in Blood desync now. In the first demo Caleb gets killed by the Cultist throwing a dynamite in his direction, when he's supposed to be killed inside the building. The desync occurs noticeably early.