dMZX Forums: ESCAPE_MENU counter -> Archived Requests -> Tracker

It'd be just like LOAD_MENU, ENTER_MENU, F2_MENU, but affect the quit dialog. Shift+Escape would open the dialog regardless of the counter's setting, preventing the game from becoming trapped. This would be implemented as a real counter, just like LOAD_MENU & the rest.

What's the point? Just so people can use ESC in their games? I don't think the bug you coincidentally files counts as justification -- that can be fixed without this.

--ajs.

Lancer-X requested this at some point. The only point is so that people can use ESC in their games. It's been brought up several times but I don't think it's ever formally had its own thread.

Also worth noting is that some people like to cue music to stuff like title screens and cinematic stuff. (Think the intro to Ryanthunder or &) As hard as it is to get mzx to even reliably sync to the music, if the player presses escape for whatever reason, it'll all be ruined. I'd like to be able to take that ability to ruin stuff away from the player.

I could also see having escape pause the music/sound circumventing that issue too, but that sounds like it's harder.

This post has been edited by ThDPro: 27 December 2012 - 03:36 AM

Has the ESC trap issue been fixed? I'm too lazy to check the whole forums.

Thud: do what CoAZ did and forcibly sync the video to the audio, instead of trying the other way around. If this was implemented as suggested the user could still do the same thing with Shift+Escape though

T-Bone: no not really

Or by using another of SDL's quit triggers, like window manager close requests (the cross, alt-f4, Command-Q, etc.). These should always allow the user to quit. We've chosen to require confirmation -- most other 'native' applications would close immediately in such a case (unless saving or similar was required).

I don't think it's a good idea to implement this. But maybe I'm just sentimental about the ESC key and its near-universal implementation by DOS games & applications.

--ajs.

Another thought on the A/V sync issue: what about pausing the audio callback when MZX is in a system dialog? If the game initiates a dialog, it presumably expects de-sync.

I think this only wasn't done historically because BWSB worked much like SDL's audio callback does now and the mixer effectively ran in its own 'thread', and there was never any real synchronization done.

--ajs.

While I agree that allowing custom actions for the Escape key, and thereby allowing getting rid of one of the last vestiges of MZX's default game behavior, could be a good thing... holy shit, we'd have to be really careful about this one. A problem with dealing with this not yet addressed (or at least something I'd consider a possible problem) is the inability to exit the game state directly through MegaZeux coding, but that definitely presents its own (potentially very large) problems on top of the ones of denying easy, universal game-escaping access in the first place.

I agree with ajs that attempting to close the window, alt+F4, etc, should always bring up the exit dialogue. What would we do about the more esoteric platforms, though?

Apart from Wii the other platforms don't yet support keyboards, so there's no legacy use cases to worry about, at least. I think GP2X could return to a menu if an app exited cleanly, so not all console platforms are reliant on a reset or power switch.

IOW: As long as we don't implement this for the wrong reasons (i.e. ThDPro's suggestion of 'preventing' closure) it's not a big deal. I'd be happy so long as the window manager can initiate closure, there would be no need to add a 'shift-esc'.

--ajs.

Honestly, I'd be much more willing to accept this feature if it were grouped with the other features listed in the standalone build discussion than if it were implemented just by itself.

The SDL_QUIT event and the escape key have been separated in GIT b5aa3bd, which was most of the work necessary for this feature, should it be implemented.

Updating status to: Implemented
Updating severity to: 1 - Low
Issue fixed in: GIT

Implemented in GIT 256b78d, with an additional fix for ALT+F4 in GIT d535fe8.

Moving to: Archived Requests