Re: [AD] Possible mouse user-end improvement

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


> While writing some wheelmouse code I noticed that Allegro could be
> making some simple mousewheel button emulations which are quite common.

How would this interact with supplementary buttons?  IIRC a patch was posted 
some time ago that would have added a 4th real button on Windows.

> The proposed patch is quite big because it includes the genexamp.py
> output, which caught a few outdated bits of documentation. Also, I added
> documentation for SCREEN_W, SCREEN_H, VIRTUAL_W and VIRTUAL_H. An
> omission which I can't explain myself, as they are quite known
> variables.

It would be nice to make separate patches here.


+@@#define @SCREEN_W;
+@@#define @SCREEN_H;
+@xref screen, set_gfx_mode, VIRTUAL_W, VIRTUAL_H
+@eref Available Allegro examples
+   Global defines which return the width and height of the screen size, or
+   zero if the screen has not been initialised yet.

I think 'that' is better than 'which' and 'size' is superfluous.

+@@#define @VIRTUAL_W;
+@@#define @VIRTUAL_H;
+@xref screen, set_gfx_mode, SCREEN_W, SCREEN_H
+   Global defines which return the width and height of the virtual screen
+   size, or zero if the screen has not been initialised yet.

Likewise.


-   This program demonstrates how to get mouse input.
+   This program demonstrates how to get mouse input and change the
+   mouse cursor.  During the first part of the example, the raw data
+   generated by the mouse is dumped on the screen, both in form of

..onto the screen.. (I think)

+   digits and sentences telling what is happening. Pressing any key will
+   switch to the second part where the standard mouse cursor is shown
+   for the first time. The third and final part is like the second,

I think 'for the first time' is superfluous.  You could use 'is introduced' 
but that would perhaps be a bit overkill.  ...second one...

+   but showing a custom mouse cursor.


-   The basic approach is to select a 15 or 16-bit screen mode, but
-   then draw onto 24-bit memory bitmaps. Since we only need the bottom
-   5 bits of each 8-bit color in order to store 15-bit data within a
-   24-bit location, we can fit a light level into the top 3 bits.
-   The tricky bit is that these aren't actually 24-bit images at all:
-   they are implemented as 8-bit memory bitmaps, and we just store the
+   The basic approach is to select a 15 or 16 bit screen mode, but
+   then draw onto 24 bit memory bitmaps. Since we only need the bottom
+   5 bits of each 8 bit color in order to store 15 bit data within a
+   24 bit location, we can fit a light level into the top 3 bits.
+   The tricky bit is that these aren't actually 24 bit images at all:
+   they are implemented as 8 bit memory bitmaps, and we just store the

Why did you remove the dashes?  It's a valid construct AFAIK.

-- 
Eric Botcazou




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/