Skip to content

Lax libraries handling glk_request_char_event when the window has identical pending input #25

@curiousdannii

Description

@curiousdannii

So I've just discovered that Kerkerkruip causes a fatal error in some interpreters by calling glk_request_char_event when the window already has pending character events. I'm pretty sure that was my mistake, though as I was predominantly testing back then on Garglk and Windows Glk my mistake was enabled by lax interpreters. In Quixe and RemGlk-Rs it causes a fatal error. (RemGlk is probably the same.)

I'm thinking of updating RemGlk-Rs so that it ignores multiple calls to glk_request_char_event/_uni as long as the window already is waiting for the same type of input. That seems harmless. I'm not going to change glk_request_line_event, as even if it was called with the same buffer it seems too risky to overwrite it.

I'm filing an issue here in case you think it's worth adding a note that some games expect lax Glk libraries.

(I've also just seen that Windows Glk doesn't seem to be accepting keyboard input in the Kerkerkruip menu. Don't know what's up with that.)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions