Hello, Guest the thread was viewed848 times and contains 8 replies

last post from Gurce at the

Mouse support for Dr Tempus :)

    Heya TOS22 :)


    I was trying to add mouse support inside your Dr Tempus game, as my daughter is a big fan of your game and keeps asking me to replay it :D


    I thought I'd try make use of the basic/kernal's existing mouse interrupt routine, by loading the game in the following way:

    • I would do: LOAD "TEMPUS"
    • Then: MOUSE ON, 2, 2 (mouse on port 2, with sprite #2)
    • Then I did RUN


    This allowed the mouse to move a little bit on screen, though your game-loop will always reset it to the cx, cy location instead.


    So I tried tweaking the code to comment that part out (the sprSetPos call), and instead replace it with some inline asm code to read the current sprite#2 location and place it in cx and cy vars, as below:

    img_2024_09_22_14_51_53.png


    I 'think' the logic of the code I added is fine, but when I try to rebuild and run the game, I run into problems:


    No artwork shows for the title screen:

    img_2024_09_22_18_28_47.png


    ...and the in-game graphics seem corrupted too :(

    img_2024_09_22_18_29_16.png


    At least some good news is that the mouse does indeed move the pointer now (which is that grey blob in the top-left at present), though it seems to ignore mouse clicks for now.


    Just wondering if you had any idea what I might've done wrong? Perhaps my addition muddled up something related to the loading of the bitmaps? Though I'm not sure how :)

    Aah, maybe there's something else at play.


    Just noticed that even if I build the original source, I get the same issue.


    It seems to relate more to the way I choose to load the compiled PRG afterwards...


    It fails this way, if I use:

    • LOAD "TEMPUS.PRG", it will fail this way
    • ^ "TEMPUS.PRG"

    ...but if I load it either of these ways, it loads normally:

    • SHIFT + RUN-STOP (to load it as the first thing off the disk)
    • RUN "TEMPUS.PRG"

    Not sure what the distinction is, but good to know I can avoid the problem this way... So I'll try my tweak again and see if it works... :)

    Aah, I think it was a xemu bug that was causing my issues. It seems that xemu's mouse support is a bit limited, and tailored to work as mouse on port 1.


    All mouse movements in xemu are sent to both ports 1 and 2, but mouse clicks are only sent to port 1.


    As this game was polling joyport 2 only, that's why it couldn't detect the mouse clicks for port 2. I'll let LGB-Z know :)


    I tried it on hardware just now, and cool, the mouse works, I can click on verbs and objects on the screen! :)


    I'll temporarily upload my results here for now, but at some later stage, maybe TOS22 can take a look at my changes and push something like that into an official release :)

    Oh, on the "tempus.d81" disk image, I added an "AUTOBOOT.C65" consisting of just:


    10 MOUSE ON,2,2

    20 RUN "TEMPUS"


    That seems sufficient to get it working for me now :)


    Perhaps a more polished ideal solution would be to let the game continue to support joystick on port 2, and then support mouse on port 1, but I'm heading off on holidays soon, so can't squeeze that polish in right now :)

    Xemu: In theory all joystick and mouse button events are routed to a single emulated joystick port however you can "swap" the emulated joystick ports, either with the "Swap" menu item in the UI under the "Input devices" section, or - as a quicker way - by pressing the numpad ENTER key. You'll even see an OSD display message for some seconds to confirm the operation. The idea behind this: on real hardware (even on C64) we often played "swap" when we realized the software needs the other joy port ;) However Xemu being an emulator, it's no more a cable plug in/out, but using the "swap" feature.


    I guess the confusion here, that mouse _movements_ at the other hand seems to be available regardless of the port. This is because the mouse movement is handled totally differently, via SID registers, so there the emulation "swap" feature's scope does not apply.

    By the way, Gurce was right, there is a bug in Xemu which makes swapping emulated ports problematic if used from the menu. However the numeric keypad ENTER solution should still work! It a tricky and interesting bug (it seems I did that by intent, but I cannot remember why I would do that at all ...), I'll fix that so the swap from UI solution will work as well. Sorry for the possible confusion.

    Quote from LGB-Z

    By the way, Gurce was right, there is a bug in Xemu which makes swapping emulated ports problematic if used from the menu. However the numeric keypad ENTER solution should still work! It a tricky and interesting bug (it seems I did that by intent, but I cannot remember why I would do that at all ...), I'll fix that so the swap from UI solution will work as well. Sorry for the possible confusion.

    That would be nice, my Macbook got no numeric keypad, so .... ;)