My old thread was locked. (A month seems like a short amount of time to autolock threads on such an inactive forum...)

Reaching out again since I spent a large chunk of time today trying to solve this with no luck. Went from a simple timer-less loop I implemented quickly, to adding a timer and even attempting to workaround by implementing my own mouse-poller via events. I get the same behavior either way. See the attached video. When holding down the spacebar to pan around my map editor, mouse input is pretty choppy, it's like the mouse is being polled every other frame. In the terminal I'm continuously printing the mouse motion, you can see that the mouse's movement is frequently coming in as 0,0 from the last frame, when a key is being held down.

"Stuck" on 5.2.3. Avoiding revisiting the non-trivial task of compiling Allegro just to find out whether or not the issue is a problem with Allegro and if so whether it still exists. (The precompiled ones don't work on either of my Forth systems SwiftForth and VFX.)

Here's the video so you can see what's happening:
https://www.dropbox.com/s/4bt2k7bgom3orha/2020-04-10%2018-29-06.mkv?dl=0

And here is my code:

: frame
    update  \ game rendering
    display al_flip_display
    kbs0 kbs1 /ALLEGRO_KEYBOARD_STATE move
    kbs0 al_get_keyboard_state
    ms0 ms1 /ALLEGRO_MOUSE_STATE move
    ms0 al_get_mouse_state
    step   \ game logic
 ;
: (go)
    begin
        queue alevt al_get_next_event if
            etype ALLEGRO_EVENT_TIMER = if
                frame
                kbs0 59 al_key_down if exit then
            then
            \ read-mouse  \ commented-out processing of mouse events
            pump  \ game events
        then
    again
;
: go
    kbs0 /ALLEGRO_KEYBOARD_STATE erase
    kbs1 /ALLEGRO_KEYBOARD_STATE erase
    al_uninstall_keyboard  al_install_keyboard drop
    queue al_get_keyboard_event_source al_register_event_source
    display al_flip_display
    1e 60e f/ al_create_timer dup al_start_timer to timer
    queue timer al_get_timer_event_source al_register_event_source
    (go)
    timer al_destroy_timer
;

Edited to remove superfluous code and comment some things

Can't say I understand this programming language at all but I kind of like it not having ';' at the end of each command.
Not understanding the language I am only guessing here though I think your '(go)' block should actually be processing also the ALLEGRO_EVENT_MOUSE_AXES events as well (move the code for this from the 'frame' block' to '(go)' block).
I think your 'frame' block also would need to have the 'al_flip_display' moved to the end of it?

p.s. You can make it easier to read your source code if you (when posting on this forum) add ... tags around the code itself.

p.p.s. re:keyboard events, since you are using al_get_keyboard_state you can disregard the ALLEGRO_EVENT_KEY_DOWN and only process the ALLEGRO_EVENT_MOUSE_AXES in your '(go)' block - though if performance is an issue you will likely want to change your code from polling the entire keyboard state each frame to only responding to the actual key-presses and for this you would want to remove al_get_keyboard_state and replace it with processing of the keyboard events(ALLEGRO_EVENT_KEY_DOWN ) in your '(go)' block.

EDIT2: Also, are you missing something like 'queue al_get_mouse_event_source al_register_event_source' in your code?

.. this is way over my head.. sorry to waste your time.

I left out the initialization code. You can assume I'm initializing all the subsystems and event queue, otherwise nothing would be working

Yeah, you are right. You are also using the ALLEGRO_MOUSE_STATE so no need to process any of the mouse events (which now that I've re-read your original post I see you have tried already).
Possibly try separating the code you have in the 'frame' block so drawing is not executed every 1/60th of a second(or, as a test, comment out the drawing altogether and see if your printout values still contain the '0 0' values). If you do have the keyboard and mouse events handled in your '(go)' block then I would go with that rather than polling the keyboard and mouse state each time a timer ticks.
Anyway, I see I'm no much help so I'll stop here and let others try to help you out.

I commented out the drawing (update) and the al_flip_display and that fixed the 0,0's. Uncommenting al_flip_display made them return. So we're getting somewhere.

Can you reproduce the issue in a small test case written in C++?

Hello roger,

Sorry to see you're still having trouble.

Troubleshooting steps I can think of ;

1) Compile a minimal example in C and try to reproduce the behavior.

2) If commenting out your 'display' function call removes the lag, then you should check your cpu usage. Constantly polling the keyboard and mouse involves polling Windows for the keyboard state, and that could certainly be a case of slowdown.

3) Don't poll. Use events the way they were supposed to. It is a trivial task to translate events into state. And events don't block like polling does.

4) Compile allegro yourself. No one wants to revert to 5.2.3 to test this for you when it might already be fixed. It's not that hard, honestly. Stop avoiding it.

5) Using al_get_next_event in a tight loop is wrong. You're burning out the cpu. Use al_wait_for_event like you're supposed to.

: (go)
    begin
        queue alevt al_get_next_event if
            etype ALLEGRO_EVENT_TIMER = if
                frame
                kbs0 59 al_key_down if exit then
            then
            \ read-mouse  \ commented-out processing of mouse events
            pump  \ game events
        then
    again

I honestly can't think of anything else at this point. Hope this helps.

Edgar

CPU usage was very low. I tried your suggestions #2, #3, and #5. Even though I'm no longer calling the polling functions, the behavior is unchanged.

Regarding #4 ... The last time I successfully compiled a DLL of Allegro that worked with Forth it took me an entire day - and that was years ago - come to think of it, I think the version I use (or a 5.2.4 one I ditched) was sent to me out of the kindness of someone's heart. It's not a big deal for you because you're a C/++ programmer and you're used to it. IIRC the last time I tried to compile Allegro I couldn't produce a DLL that Forth could recognize. It's a complicated task with many options and dependencies ... I think that's pretty objectively accurate.

On top of it, things aren't entirely "working", there's weirdness regarding the audio codec addon and after much trial-and-error discovered I had to copy the dependency DLL's into both system's bin folders to be able to load ogg files during development. With a 5.2.4 DLL I believe I compiled myself, I had horrible audio corruption playing certain files. Neither have been solved, despite lengthy interaction with the forum on both.

So ... maybe you can see now why I'm so hesitant to go down that rabbit hole, with so many potential pitfalls.

(BTW, thank you for your help so far.)

If you'll remember I offered to compile allegro for you, but you never said anything to me. You didn't answer my question as to whether it needed to be 32 or 64 bit.

I don't have any other ideas.

If 1) can't reproduce the problem, then it's not allegro. Check this before you continue.

My offer to build binaries for you still stands, but you have to work with me.

EDIT
Meet me on IRC on freenode on #allegro and we can discuss this real time.

EDIT2
My nick is Modulo5k

When was that? I don't have any recollection of you offering to do that recently - and my memory is really hazy - I don't know why I might have decided to give up on upgrading without saying anything but it was probably that I'd spent too much time on the problem already and found a workaround - but if you still don't mind, that would be great. It's worth a shot. Both Forths are 32-bit systems.

roger and I managed to solve it. Turns out 64 bit libraries aren't compatible with VFX forth. He tried it with my binaries for 5.2.5 and they fixed the problem.

If there's any interest in binaries for 5.2.6 binaries for 32 bit windows I may be inclined to build them.