[Ohrrpgce] Fufluns released! ...

Fri Mar 23 15:01:50 PDT 2018

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.

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.

>
>> 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
>>
>>
>
> _______________________________________________
> 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/20180323/6ad6b82a/attachment-0001.html>