[Ohrrpgce] remaining bugs for calipygous+1

[Ralph Versteegen]

There is one more fix I want to get into C+1: a change to how cursor
visibility is handled in fullscreen. It affects all backends and I
just need to get gfx_directx working. I have now handled all known Mac
problems (except the one discussed below which I couldn't fix).

I did also manage to fix the mouse positioning problem in gfx_directx,
but I don't plan to merge that into C+1 because it isn't that
important, and it got mixed up in a lot of other changes.

On 5 May 2016 at 03:53, Ralph Versteegen <teeemcee at gmail.com> wrote:
> On 30 April 2016 at 02:58, James Paige <Bob at hamsterrepublic.com> wrote:
>>
>>> Sure, those changes would be great. We should probably actually
>>> mention that Custom is resizeable in whatsnew, since Mac and Linux
>>> users get that by default.
>>
>>
>> I just found another serious bug on Mac. If you resize the window, you lose
>> all text string input.
>>
>> Arrow keys work, typing numbers works, but trying to type strings just goes
>> dead.
>>
>> running with -no-native-kbd avoids the bug.
>
> I've fixed this; will commit later. Just another difference in SDL
> behaviour on OSX.
>
> Couldn't figure out how to stop SDL from recentering the window every
> time (another bug/quirk),
> but probably there's no need to center the window anyway; I'm guessing that OSX
> places windows in a decent way.

After reading the SDL source I found that there is no way to disable
this extremely annoying behaviour. SDL_VIDEO_CENTERED does nothing in
the Quartz backend. There would be some complicated kludges like
getting an OS handle to the window and doing things ourselves, but by
far the best thing to do is to give up, since it will be a non-issue
in Dwimmercrafty, where the sprite editors will not be forced to
320x200 (I'm almost there).

I also found that the SDL devs are still accepting stuff (like
recently, better Atari support) into SDL 1.2; I had thought it was
EOL. And that they have been working on PSP support in SDL 2.0.

>>> -gfx_directx mouse tracking is still broken when the window is maximised
>>>
>>
>> I have no idea what to do about this one. My last unsuccessful attempt to
>> fix it taxed my brain.
>>
>> I feel like there may be something fundamentally flawed about gfx_directx's
>> approach to implementing io_setmouse
>>
>> gfx_sdl uses SDL_warpmouse
>>
>> gfx_fb uses the fb internal setmouse command
>>
>> gfx_directx gets the window size, gets the window position, gets the desktop
>> size, does floating-point math on them, and then sets the mouse cursor
>> relative to the screen. I can't see where this takes zoom into account. I'm
>> not sure if a directx way to set mouse cursor exists, and I don't know why
>> this is done using floating point math rather than integer math.
>
> It has to use floating point because the window scaling is not necessarily
> an integer multiple.
> I'll have a look at this in a couple days, and plan to add support for
> variable resolution while I'm at it!
>
>>
>> On Thu, Apr 28, 2016 at 7:38 AM, Ralph Versteegen <teeemcee at gmail.com>
>> wrote:
>>>
>>> On 28 April 2016 at 02:12, James Paige <Bob at hamsterrepublic.com> wrote:
>>> > What bugs are remaining for callipygous+1?
>>> >
>>> > I remember that the mac terminal wrapper still has to be fixed to work
>>> > when
>>> > ~/.ohrrpgce/ does not exist, but was there anything else?
>>> >
>>> > Also, so you think I should copy over the changes I did to make menus
>>> > use
>>> > the whole screen when you maximize? I think those changes are all pretty
>>> > safe, and I have been testing them a lot since I did them. (running
>>> > maximized all the time)
>>> >
>>> > ---
>>> > James
>>>
>>> Sure, those changes would be great. We should probably actually
>>> mention that Custom is resizeable in whatsnew, since Mac and Linux
>>> users get that by default.
>>>
>>> I fixed the two reported Mac bugs, but while testing on Mac I
>>> immediately noticed two further bugs (I'm surprised noone mentioned
>>> these)
>>>
>>> -The window size options don't work at all, because the desktop size
>>> can't be determined (we fall back to using the value from SDL because
>>> I didn't write a mac implementation, but it turns out that SDL just
>>> returns 0*0, at least on my machine). So 2x zoom is used.
>>>
>>> -Every time you resize the window (by dragging the window corner), the
>>> window is recentered on the main monitor. Very annoying. gfx_sdl used
>>> to do the same thing on windows and linux and I already fixed it on
>>> those. It's done using envvars in a way that I guess isn't portable.
>>>
>>> Other bugs for C+1:
>>>
>>> -gfx_directx mouse tracking is still broken when the window is maximised
>>>
>>> -workaround when a working#.tmp dir can't be cleaned up on Windows
>>> (the problem reported by Brotoad). This isn't really a new problem in
>>> Callipygous. But previously you would have been told "Couldn't delete
>>> ...; you may have to delete it manually", now you get a less
>>> informative error. And we can now silently ignore those directories.
>>>
>>> Bonus bugfixes that would be good:
>>>
>>> -Add a backcompat bit and fixbit to use unfilteredalt as the menu key.
>>> IIRC this was introduced in Zenzizenzic, and does cause brokenness in
>>> a number of scripted games
>>>
>>> -Any bugs.
>>>
>>> -Window scaling when launching C.Kane through steam is the wrong size?
>>> But I installed steam under wine and can't reproduce it... not too
>>> surprised about that. Surlaw seriously needs to update the linux
>>> version to Callipygous; the window gets created off-screen and I had
>>> to add ohrrpgce-arguments.txt to run it.
>>> _______________________________________________
>>> Ohrrpgce mailing list
>>> ohrrpgce at lists.motherhamster.org
>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
>>
>>
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>