[hatari-devel] Mouse ungrab, palette?

npomarede at corp.free.fr npomarede at corp.free.fr
Sun May 31 22:36:20 CEST 2009


On Sun, 31 May 2009, Eero Tamminen wrote:

> Hi,
>
> On Monday 25 May 2009, Eero Tamminen wrote:
>> I was reading through Steem features and noticed that it releases mouse
>> grab when the emulation is paused.  Now that we have pause button,
>> wouldn't ungrabbing make sense also for Hatari?
>>
>> I've never used mouse grabbing myself (if mouse is a problem, I use
>> fullscreen) so I'd like somebody who actually uses the grabbing to
>> answer...
>
> Attached is a patch that:
>
> * adds --grab command line option for enabling mouse grabbing also
>  from command line:
>  - earlier it could be done only from a shortcut, this feature needed some
>    changes also to screen.c
>  - at least when doing general Hatari testing, it's useful to have grab
>   active immediately. This way e.g. the space press to dismiss the memory
>   check is sure to go where it should and the mouse click to start the test
>   program (or open drive window) doesn't so easily miss the Hatari
>   window...
>
> * ungrabs mouse when Hatari is paused (and regrabs when unpaused)
>
> Anybody have objections on commiting it?


The idea looks fine to me.

>
>
>> There's also a feature to change Steem palette.  This can be used to see
>> whether there's actually something on screen.  Would that be useful for
>> Hatari too, e.g. for debugging DSP issues?  And how it should work?
>
> Any comments on the feature of forcing the default palette?
>
> Or ideas how to implement it?  I think 16 first colors would be enough and
> there could be a keyboard shortcut (e.g. Altgr+p) that forces the default
> palette.
>

Yes, this could be useful ; I sometimes uses this with steem, but it's 
more useful to see the tricks that were used to code a particular demo 
than to debug hatari :)

The place to do it should be in the convert/*c files I think ; it could be 
possible to intercept all writes to the color registers and replace them 
with a different palette, but the problem is that some game/demos only set 
the palette once and don't change it anymore, so you can't rely on the 
fact that the io handler for color registers will be called.

That's why I think the palette should be overridden when converting the ST 
screen to the host screen in 8/16/32 bits, but this has the disadvantage 
of adding some tests in these costly routines, so maybe this option should 
be made compile time configurable.


Nicolas



More information about the hatari-devel mailing list