Well, I threw this together for a little thing I was working on; just a transparent cursor in fullscreen mode on the CSE. You can move it around, it checks bounds and stuff, and has 3 bytes used for the location. Kinda neat, I guess. The cursor is really easy to change, it is XlibC style, one byte per pixel. I'll add the source once I clean it up a little.



This can go across anything onscreen, not just blank stuff. Maybe I'll show that somehow... Oh well.
It also doesn't flicker like that on-calc, well, it kind of does, but not even really noticeable.

One of the things I found made such a mouse routine much more user-friendly in Doors CS was the addition of some sort of acceleration. Would you consider adding any kind of adjustable acceleration factor to this mouse so the user doesn't need to hold down an arrow key and wait for the cursor to get from one side of the screen to the other? Very nice work on this!

Of course! That's a good idea; I'll make another variable to include the acceleration factor.

EDIT: Okay, so I just made it so you can change a varible to control how fast the acceleration is. One thing that I really need to work on is the flickering; I kind of just hacked it and printed out whatever was behind the character over the top. I could probably buffer it to provide cleaner output. And actually optimize my code. But hey, it works.

EDIT2: Okay, so I refined it by updating the sprite and saving the buffer within the same loop. That way it doesn't have to do the same thing twice. I wonder if I could also do the same with clearing it... On-calc though, it isn't even noticeable anymore. The only flickering now is mostly just gif issues. Which is annoying, because it is hard to see what it actually looks like.

Things to do are to add hover and click checking, which should go pretty fast.

Well isn't that just cool Nice work!

But the question is, what is the little thing you are working on?

Anyway, that looks really cool! The second GIF makes me think its part of a level editor.

So I got the mouse over routines and clicking routines complete! Also, I made it easy to add buttons; you put in the bounds for the button in de,hl, and bc, and then make a call which puts the button data at the end of the button buffer. Then another routine loops through and checks if any buttons are touching the mouse, and returns that element number of the button.

Here it is as follows:
Create button 1
Create button 2
Create button 3
CheckButtons => Touching 2, Returns 2 in A

It's kind of like a linked list, but only adds to the end. To delete an element, send the button number in 'a' and then it will delete that button. Screenshots soon. I'm not sure if this was the best way to handle it; any other ideas?


EDIT: Would it be better if you could input the button number itself, rather than adding it to the end? Probably....

Are you just using a linear search for buttons? Some kind BVH might get better performance on complex UIs, especially if you're going for axis-aligned buttons only.

Hmm, that might be interesting. It is just a linear search, but I imagine that could be somewhat improved. Anywho, here's a screen shot of some current progress of this routine: The first number represents the current button hovering over; the second number is updated to the pressed button when 2ND is pressed.

Doors CS uses a linear search through the available hotspots in the GUI API, and I think it's safe to say that the simplicity makes it overall easier for the number of hotspots that calculator programs generally have.

I think I remember some concerns when I was implementing the Strategic Conquest UI, because I wanted to have a unique clickable hotspot for each displayed tile on the map, which at 8x8 would have been a lot of tiles for a linear search...

I remember that that was indeed the case. Well, if I ever have the time and inclination to port the GUI API to the TI-84 Plus CE for Doors CS?E?, I'll make sure that I include smarter hotspot searching.