[cc65] Mouse API Proposals

Hi,

I'd like to suggest three (at least from my perspective) improvements
to the mouse API:


1. Default bounding box

The mouse API allows to set a bounding box using mouse_box(). There's
however no way to determine the default/inital/start value for this
box allowing to set the box to "the half of the screen" or to reset
the box to it's original value. There may be very well an educated
guess like "the full graphics resolution", but:

a) a portable program doesn't know that
b) there might be several graphics modes with different resolutions

From my perspective there's no need for a full blown function to
retrieve the current bounding box. Rather I would consider some
target-specific macros be sufficient - given that the initial bounding
box is an attribute of the target and not the individual drivers for
that platform.


2. Coordinate mapping

Creating a responsive user interface in graphics mode requires more
sophisticated graphics routines than TGI gives, so I believe my
presumption holds true that user interfaces for cc65 programs are
typically implemented in text mode - most likely using the conio API.
Based on this presumption it is very likely that the mouse API is
primairly used in conjunction with the conio API. In this scenario a
program has to map the "graphics" mouse coordinates to "character"
screen coordinates in order to determine the user interface element
manipulated with the mouse.

One might think implementing my proposal 1.) above is already
sufficient as one can use the default bounding box in conjunction with
the conio API screensize() to determine that mapping. But things can
become quite easily more complicated: The Apple II default bounding
box is [0..279,0..191] (which is the default graphics resolution
provided by the TGI driver) so the horizontal mapping factor for the
80 col. display is 3.5 - not good without float support (or way to
slow for potential float support). The obvious solution is "<cursor
pos> * 2 / 7 = <char pos>" but how should a portable program know
that?

Given the likeyhood of the scenario "mouse with conio" I propose an
API specific to this need allowing to determine the character
coordinate (in the current screen resolution) for a cursor coordinate.
Independent from the way it is presented to the user the API should in
my opinion be implemented in the mouse callback routines.


3. Cursor display

How the default mouse callbacks actually draw the cursor should be as
transparent as possible to program because:

a) using conio it would have a very hard time to deal with redrawing or whatever
b) any interaction with the mouse callbacks would tend to be way too
target specific for a portable program

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. Rather the (default) mouse callbacks should do this
internally. Given the fact that the mouse is initially hidden a CBM
specific program would still have the option to override the default
cursor with direct sprite operations after initializing the mouse but
before showing it.

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...


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