[Ohrrpgce] Fufluns released! ...

Ralph Versteegen teeemcee at gmail.com
Fri Mar 23 15:43:31 PDT 2018


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/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-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/20180324/05bea94d/attachment-0001.html>


More information about the Ohrrpgce mailing list