[Ohrrpgce] Fufluns released! ...

Fri Mar 23 14:41:27 PDT 2018

On 24 March 2018 at 03:42, James Paige <Bob at hamsterrepublic.com> wrote:

> I agree that adding a textbox option does sound best. Are you thinking an
> option to change the anchor/align? or pixel positioning or both? I think I
> would be inclined towards adding those positioning options in a way that is
> similar to what is available in a slice, but not going as far as actually
> saving slice data in the current textbox format.
>

Both, I suppose. Definitely want pixel position. Alignment isn't strictly
necessary if you can position, but it's convenient. Don't need separate
alignment and anchoring, just combined align+anchor.

> I am fine with leaving the default positioning top-left
>

I'm also OK with top-left if it has to be, although it seems suboptimal for
backdrops smaller than the screen - you're unlikely to want them there.
If you increase the game resolution (and especially if you used backdrops
as portraits), the textboxes move to the center but the backdrops don't.

But actually on further thought I realised the default position is NOT
top-left, see below.

Oh! Another thing: if the backdrop isn't as large as the screen and isn't
transparent, it would be good to have an option to cover the rest of the
screen with a solid colour.

>
> As for "show backdrop" I could add convenience arguments that would change
> the anchor/align of the backdrop slice.
>

Those convenience arguments would be very nice. However I note that current
behaviour is that "show backdrop" (and also textbox backdrops) don't change
the position/alignment of the backdrop slice, so for backcompat we ought to
keep that behaviour... however it's a very strange default to have and will
cause heaps of annoyance if alignment arguments to showbackdrop and textbox
backdrops are added. Imagine: you change one backdrop to use some other
alignment and now you have to make sure that you either manually change the
alignment back to top-left afterwards, or change followup
textboxes/showbackdrop calls to explicitly specify top-left. That would be
dreadfully annoying!

So maybe we need a backcompat bitset to make textboxes and showbackdrop
reset the backdrop position to top-left 0,0 by default instead of keeping
the previous position.

> On Thu, Mar 22, 2018 at 10:13 PM, Ralph Versteegen <teeemcee at gmail.com>
> wrote:
>
>> Also, how should non-320x200 backdrops be positioned? Currently, textbox
>> backdrops and I think "show backdrop" places these backdrops aligned to the
>> top-left corner of the screen, while the titlescreen and battle backdrops
>> are centered. Perhaps we should change this. It would be best to add a
>> textbox option to position the backdrop.
>>
>> On 23 March 2018 at 18:11, Ralph Versteegen <teeemcee at gmail.com> wrote:
>>
>>> The spriteset editor is unusably slow in large games; I need to get rid
>>> of the defpal#.bin lumps. (WIP)
>>>
>>> .pt# and .mxs lumps need to be deleted.
>>>
>>> Cursor keys in the spriteset editor are still very wonky. I rewrote the
>>> cursor key handling, I just need to clean up the code and commit it.
>>>
>>> Also, the Windows 10 bug which breaks gfx_directx fullscreening ought to
>>> be addressed, I think at least 4 people have complained about that problem.
>>> The easiest way to solve it would be to switch to gfx_sdl as the default
>>> for game.exe, but switching backends always causes unexpected problems (and
>>> gfx_sdl fullscreening is really bad anyway), so I'd rather try to figure
>>> out how to fix the problem properly.
>>> (And anyway, Pepsi reported another new problem with gfx_sdl
>>> fullscreening on Windows: https://www.slimesalad.com/for
>>> um/viewtopic.php?p=132358#132358)
>>>
>>> There was a bug which resulted in broken textbox links; I fixed that bug
>>> but for some reason didn't merge in the upgrade code to scan a game for
>>> broken textbox links and show a message.
>>>
>>> Although I merged in my branch which reenabled MP3 previewing, when I
>>> tested it later it didn't actually work for some reason. Should either fix
>>> it or delete that from whatsnew.
>>>
>>> I still need to fix the rest of the bug where copy-pasting text is
>>> broken on Windows (it appends \r characters to each line).
>>>
>>> Audio doesn't work at all on Windows when the codepage (for non-unicode
>>> applications) is set to Japanese, because in that codepage the \ character
>>> has a different code point. Not really a blocker, but serious
>>>
>>> On 23 March 2018 at 16:09, James Paige <Bob at hamsterrepublic.com> wrote:
>>>
>>>> Hehe! Well, we will release for real soon enough. Other than the Sprite
>>>> import/export stuff, what else would you consider blockers?
>>>>
>>>> ---
>>>> James
>>>>
>>>>
>>>> On Thursday, March 22, 2018, Ralph Versteegen <teeemcee at gmail.com>
>>>> wrote:
>>>>
>>>>> Haha! Surprisingly for that split second before seeing the "Just
>>>>> kidding" I didn't feel shock or annoyance; more like relief :)
>>>>> I have been unfortunately too busy, and when I have had time, failed
>>>>> to work on the important stuff, so this is turning into a bit of a farce...
>>>>> I am currently working on the missing spriteset import/export now though,
>>>>> and will follow that up with other important features.
>>>>>
>>>>> I don't want to keep delaying forever and have come to think that we
>>>>> (mainly I) are following the wrong strategy: rather than releasing late to
>>>>> fit in more features, we should cut early releases when we have something
>>>>> cool we want to get into people's hands without delay! (However in this
>>>>> particular case we couldn't, and can't, release on-time because of blockers)
>>>>>
>>>>> On 22 March 2018 at 11:03, James Paige <Bob at hamsterrepublic.com>
>>>>> wrote:
>>>>>
>>>>>> Just kidding! not yet! I like imagining your reaction to that subject
>>>>>> line, TMC ;)
>>>>>>
>>>>>> But seriously, how are you feeling about pending features and
>>>>>> bugfixes?
>>>>>>
>>>>>> Shall we push the stabilization of for another couple weeks?
>>>>>>
>>>>>> ---
>>>>>> James
>>>>>>
>>>>>> _______________________________________________
>>>>>> Ohrrpgce mailing list
>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherh
>>>>>> amster.org
>>>>>>
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>
> _______________________________________________
> 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/20180324/1b9de607/attachment.html>