Re: [cc65] Mouse API Proposals

On Tue, Aug 25, 2009 at 03:31:03PM +0200, Oliver Schmidt wrote:
> 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.

I don't think that adding macros is a good idea. There is currently no
platform specific stuff in the headers. It is not much more work to add
something like that to the drivers. How about expanding the mouse_info struct
by the 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.

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

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.

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

Actually two such functions are necessary: Calculate a character coordinate
from a native coordinate and vice versa. Extending the mouse callbacks is an
idea, but the current mouse callbacks are used from the driver not the kernel.
This would mean, all coordinate that go to the driver would be translated via
one mouse callback, and all outgoing coordinates by another. 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.

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

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.

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

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz@musoftware.de

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