[Ohrrpgce] Fufluns released! ...

Sun Jul 7 08:28:51 PDT 2019

Ahoy, Ralph!

I would love to try and make the Fufluns release happen this month, and I
think I'll have some time to actually work on it.

Let's come up with a list of the absolute critical blockers.

I would define a blocker as a bug that would leave some important
functionality in Fufluns significantly broken in comparison with the same
functionality in Etheldreme.

I sent an invite to join my OHRRPGCE Asana project. Don't feel obligated if
you don't want to use it, but I have been finding it pretty handy for
listing to-do-list tasks. We can also just discuss plans here if that works
better.

---
James Paige

On Fri, Mar 23, 2018 at 6:43 PM Ralph Versteegen <teeemcee at gmail.com> wrote:

>
>
> On 24 March 2018 at 11:01, James Paige <Bob at hamsterrepublic.com> wrote:
>
>>
>> On Fri, Mar 23, 2018 at 2:41 PM, Ralph Versteegen <teeemcee at gmail.com>
>> wrote:
>>
>>>
>>>
>>> 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.
>>>
>>
>> That sounds reasonable. I can implement that.
>>
>>
>>>
>>>
>>>> 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.
>>>
>>>
>> Hmmm... I didn't think of that, but you are right. That would be a
>> reasonable backcompat bit.
>>
>> So both textbox backdrop position and script backdrop position would
>> default to either same-as-previous with the bit off, or top left corner
>> with the bit on.
>>
>
> But if we're adding a back-compat bit, we could take the opportunity to
> make the new default centered rather than top-left.
>
>
>>
>> I can work on that also.
>>
>> Actually though, none of this sounds like a release blocker to me, just a
>> feature that isn't as complete as we would like it to be, not a bug or a
>> breakage.
>>
>
> Yes, it's not a blocker.
>
>
>>
>>
>>>
>>>> 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/forum/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-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
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
> _______________________________________________
> 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/20190707/167c139e/attachment.html>