Re: [cc65] Mouse API Proposals

Hi,

>> 1. Default bounding box

> Another idea would be to place the information
> into a know storage in the driver, so the C layer can retrieve it without
> calling a driver function.

Similiar to the resolution etc. in the tgi drivers? Seems the most
elegant solution to me :-)

>> 2. Coordinate mapping

> Currently there aren't many programs using the mouse, so stating that the
> primary use of the mouse is with conio is probably an exaggeration:-) Anyway,
> it's a possible use case, so such an API is probably helpful.

At least Contiki 2.x could/would make use of it.

> This would mean, all coordinate that go to the driver would be translated via
> one mouse callback, and all outgoing coordinates by another.

Maybe a misunderstanding. I was thinking about explicit translation
routine(s). Nothing like "get/set as char pos"...

> Maybe it would be
> better to have a set of routines that extend the kernel, since translating
> mouse coordinates is platform independent and can be done by the mouse kernel
> before passing the coordinates. This keeps the drivers smaller and shared code
> in the kernel.

The situation on the Apple2 is...
a) there are two text mode resolutions (40 and 80 col) and the
translation routine needs to know which one is active (the same for
the C128 ?).
b) translating between 280 and 80 requires more than just an integer
division / multiplication.
Both aspects seem quite platform specific to me - but not mouse
specific. Therefore I was thinking about the mouse callbacks as the
right place.

>> 3. Cursor display
>>
> [...]
>> >From that point of view it doesn't seem correct to have the program
>> load and configure sprite 0 for use by the mouse callbacks. I strongly
>> believe that the program shouldn't be required to know anything about
>> sprites at all.
>
> On such small machines that is almost impossible. Ok, if you're using conio
> and ignore sprites alltogether it would be a good thing to allow the mouse
> driver to manage sprite 0 completely. But if you're using graphics mode with
> your own sprites, if you're using collision detection or any other VIC stuff,
> you need to know and control what the mouse driver is doing. This is the
> reason why the mouse callbacks can be changed by the user while a common
> implementation is supplied.

Following this very argumentation (custom mouse callbacks) I would
come to the conclusion that the default mouse callback should manage
the sprite for conio and pure TGI programs while programs using
sprites actively would probably need custom mouse callbacks.

> Also, the mouse driver doesn't know anything about the memory layout of the
> program. But the sprite data has to go into a specific memory location which
> depends on the graphics mode and where VIC memory is mapped. I don't think it
> is possible to let the driver do that transparently without adding lots of
> code.

I wasn't advocating to have the driver involve into that game. My
understanding is that the driver is responsible for delivering cursor
coordinates (and button) state and thus isn't involved in handling the
actual cursor at all.

On the Apple II (without any hardware sprites / cursors / whatsoever)
the mouse callback draws _INTO_ the screen and therefore needs to have
an intimate knowledge of the current video mode. I'm far from knowing
enough to argue on the other targets.

As you pointed out I'm maybe to text/conio focused so I'd still see a
benefit in transparent sprite handling, even if it would only work for
that scenario, but after all I can't decide if this is feasable with
reasonable overhead.

>> For that purpose the mouse callbacks should have an init and exit
>> entry point called by the mouse kernel. This would in general be
>> beneficial as i.e. currently the Apple II default callback use a
>> constructor to determine the text screen resolution - an approach
>> failing for sure a soon as the screen mode becomes switchable...
>
> Mouse callbacks are called from the driver. That is not true for init and exit
> (they will be called from the platform independent mouse kernel), so I'm not
> sure if this is the correct approach. Is there a reason why there is a
> constructor used instead of doing that inside the driver when INSTALL is
> called?

The screen resolution is totally independed from the way the mouse
works and has only to do with displaying the mouse cursor so I
understand that it shouldn't be involved here, should it?

If we want to stay with paradigm of the driver being the only instance
calling into the mouse callbacks then it could of course do so in its
INSTALL / UNINSTALL entry points.

Best, Oliver
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.