Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#6791 closed defect (fixed)

ZVISION: Game feels sluggish around Frobozz Electric building (script bug)

Reported by: eriktorbjorn Owned by: bluegr
Priority: normal Component: Engine: ZVision
Keywords: Cc:
Game: Zork Grand Inquisitor

Description

Current git snapshot of ScummVM. English DVD version of the game.

When you approach the Frobozz Electric building, near the start of the game, the camera will linger on the building from a distance for a while. This is done by setting the render delay to a hundred frames, like this:

puzzle:10903 {  # px10_screenset
    criteria {
    }
    results {
        action:set_screen(mx10s011.tga)
        action:cursor(U)
        action:animpreload:10925(mx10w021.rlf 1 0 0 0)  # px10_camera_1_anim
        action:animpreload:10926(mx10w031.rlf 1 0 0 0)  # px10_camera_2_anim
        action:animpreload:10930(mx10w011.rlf 1 0 0 0)  # px10_banner_1_anim
        action:animpreload:10932(mx10w061.rlf 1 0 0 0)  # px10_banner_2_anim
        action:assign(10916, 0) # totem_count_flag
        action:delay_render(100)
    }
    flags {
        once_per_inst
        do_me_now
    }
}

It makes sense when approaching from the crossroads, but not when approaching from any other direction, or from a dialog. It would be nice if we could override the delay to, say, 10 frames in those cases, sine that seems to be the standard value.

I'm attaching one possible way of doing it, but it's not as foolproof as I would like it to be, so hopefully there's some much better way.

Ticket imported from: bugs/6791.

Attachments (1)

framedelay.txt (1.2 KB ) - added by eriktorbjorn 5 years ago.

Download all attachments as: .zip

Change History (7)

by eriktorbjorn, 5 years ago

Attachment: framedelay.txt added

comment:1 by bluegr, 5 years ago

Looks like a reasonable way of handling this.

This reduces the delay after zooming out of the signs outside of Port Foozle. Why do you say that your patch isn't foolproof enough? It does seem to work around this script bug correctly, unless I'm missing something.

To be honest, it would be better if we removed the extra delay in that scene in all cases, as it does make the game feel like it's stuck.

comment:2 by eriktorbjorn, 5 years ago

Why do you say that your patch isn't foolproof enough?

Because it doesn't seem to tell the difference between arriving from the crossroads and returning from the original save/load or preference dialogs while looking in the same direction as when arriving from the crossroads.

To be honest, it would be better if we removed the extra delay in that scene in all cases, as it does make the game feel like it's stuck.

Hmm... I don't know. I thought it was for the dramatic effect of lingering on the last frame, showing the building. I guess an alternative would be to only delay the very first time you approach, but I guess we'd need to use a state value or flag for that. Are there any available ones, or does the engine allocate only the bare minimum?

comment:3 by RichieSams, 5 years ago

The state flags are implemented using a hash map. So you can use any uint32 value that's not already used by other puzzles/global flags.

Are you sure the render delay is actually for gameplay reasons? It seems something more akin to, "let's pause here while we load all the data from disk". I feel like if they wanted the dramatic effect, they would have done it with a state flag check against where you come from.

Imo, we could remove the render_delay functionality.

comment:4 by eriktorbjorn, 5 years ago

I have no idea what the render delay is for in general, obviously. It just looked a bit too deliberate to be a coincidence that they would delay for much longer than usual on that shot of the building from a distance. Even if I' guessing that scene does have more than the usual amount of animations to load.

comment:5 by bluegr, 5 years ago

Owner: set to bluegr
Resolution: fixed
Status: newclosed

comment:6 by bluegr, 5 years ago

I've checked all the ZNEM and ZGI game scripts, and the render delay value ranges from 1 - 10. This location (px10) is the only place where it's set to 100. This looks to be a script bug, since this is 10 times the delay of any other scene, thus I've limited it to 10 frames maximum in commit 53a2c30cb0.

The fix will be available in the next daily version of ScummVM. Closing as fixed.

Note: See TracTickets for help on using tickets.