[Ohrrpgce] Menu bug on long menus

[Ralph Versteegen]

On 6 April 2018 at 14:37, Ralph Versteegen <teeemcee at gmail.com> wrote:

>
>
> On 6 April 2018 at 14:28, Ralph Versteegen <teeemcee at gmail.com> wrote:
>
>> I remember this problem. It's caused by the following code in
>> init_menu_state (for MenuDef):
>>
>>   .size = menu.maxrows - 1
>>   IF .size = -1 THEN .size = 17
>>
>> This hardcoded value of 17 is only suitable at 320x200 and only if the
>> itemspacing and borders haven't been changed. Obviously this needs to be
>> fixed, but last time I was makingchanges to the menu sizing code I left it
>> alone for because I didn't want to deal with it then, out of caution (eg
>> backcompat).
>> I don't think we should expect any backcompat problems changing it,
>> because few games run at a different resolution. If you did something like
>> reducing the item spacing to squeeze your 18 menu items together to leave
>> space to display something above or below the menu, only then would
>> changing it be a problem, but that sounds very unlikely to have occurred.
>>
>
> Oh, and I see this only changes .size, not the size of the menu's box... I
> think I changed how the latter was calculated without changing the former,
> so I probably already broke the above hypothetical game relying on current
> default maxrows behaviour anyway?
> Menu sizing really is a mess! I hate the fact that we have
> MenuState.has_been_drawn, that you have to call draw_menu/standardmenu to
> correctly calculate the size and position of the menu, which leads to
> momentary glitches when you enter some menus like the Battle System
> Options. The way I see to fix it is to put a bunch of arguments like the
> location at which a menu is drawn in MenuState, rather than passing it as
> args to draw_menu/standardmenu.
>

Oh, and I wanted to get rid of MenuState.size anyway and instead measure
menu size in pixels, so that a fractional number of menu items could be
visible, and menu items could be different heights (eg allowing per-item
changes in font). That would also imply .maxrows would be obsoleted

>
>
>>
>> On 6 April 2018 at 09:43, James Paige <Bob at hamsterrepublic.com> wrote:
>>
>>> I noticed recently that when a menu is set to:
>>>
>>> Max rows to display: Default
>>>
>>> The sizing always appears to be wrong for menus longer than a certain
>>> size. I am not sure if this has ever worked correctly.
>>>
>>> I think it is possible that anyone who has made a menu long enough to
>>> scroll has always had to just put a specific number in the "Max rows to
>>> display" to get it to look right.
>>>
>>> _______________________________________________
>>> Ohrrpgce mailing list
>>> ohrrpgce at lists.motherhamster.org
>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20180406/9a2f4626/attachment.html>