Ren'Py 6.99.9 Prereleased

[gas]

Well, after some test with the speaking attribute... it work fine, but there's a little behaviour issue.
The "not speaking", regular sprite is used in transitions and movements. That's mean, for example, when moving a sprite side to side to have another one enter the scene, both are shown as "not speaking". Seems logical, but is not.
Also, I think is strange to have this behaviour in narration or toughts.
My sprites change when the MC outside screen speak to them, and this is not natural (seems like talking alone). While seems good for animations, is not the case at all for static sprites (mine get darkened when silent, like Super Robot Wars or other games).

It's a little convoluted, but the more logical approach is to define a "not_speaking" attribute that is used just only when another onscreen character is actually speaking instead.
Or a way to set this behaviour programmatically, a kinda inverse config statement.

[SundownKid]

Well, I've tried using it and the movie glitch I've been having still exists exactly the same as before. Whenever I show a screen the movie displayable jumps to the foreground and freezes the game.

[PyTom]

SundownKid - can you put together a replication? I'd like to check your code against the newest best practices. (For example, are you forgetting to give a channel argument to Movie?)

[SundownKid]

I defined the movie like:

Code: Select all

image movie = Movie(size=(1920, 1080), xpos=0, ypos=0, xanchor=0, yanchor=0)

And then played it like:

Code: Select all

play movie "image/ui/vortex.ogv" loop
show movie

Then all I do after that is show a screen and it messes up.

[PyTom]

Yes. That would cause what you're seeing. Take a look at my example code in:

http://lemmasoft.renai.us/forums/viewto ... 48#p405648

to see the new way to do it.

[SundownKid]

Yes. That would cause what you're seeing. Take a look at my example code in:

http://lemmasoft.renai.us/forums/viewto ... 48#p405648

to see the new way to do it.

Fantastic, it finally works as intended!

[chiruchirumichiru]

I would like to report numerous issues I encountered in 6.99.9 and some previous builds (from at least 6.99.3). I have waited for them to be resolved, and waited, and waited some more... but now even stuff that worked previously starts to break. I can't be the only one observing such behaviors?
I have tested on Windows 7 Ultimate 64bit with DPI Scaling 200% and 4k monitor.

Project is set to

Code: Select all

    config.screen_width = 1920
    config.screen_height = 1080

1. Since something like 6.99.4 mouse cursor is not visible in fullscreen mode. Mouse can still press buttons and such but there is no way to tell where the mouse cursor is unless you hover something (you get hover effect then). In windowed mode cursor works fine.
2. Making a screenshot via S hangs system for like 20 seconds (but it makes screenshot eventually).
3. Stroke on the letters depends on some internal calculations of target resolution which produce some weird results with windowed and fullscreen mode. On low-ppi display the stroke becomes too thick https://gyazo.com/276f5f6e325e4276007db158292eed4c (note how it fills all inside あ for example). On main 4k screen stroke becomes too thin in windowed mode https://gyazo.com/66a681ae16b3e968efb1d32e33da02ec and roughly *intended thickness* https://gyazo.com/26f191ae60193acfd451fa7fc0880eae in fullscreen mode.
Stroke is set as

Code: Select all

    style.say_dialogue.outlines=[(3,("#190019"),0,0),]

4. As a result of this discrepancy another issue arises, with furigana. It's very hard to capture footage but hope this is understandable https://gyazo.com/488c0b3eb948bfd594b3ae3cd2adad6c - this is in windowed mode. https://gyazo.com/220e1f0f7e65104d27fe2b5a9ef06d36 this is in fullscreen mode. In the end I could not capture with gyazo or OBS so here's live footage filmed from screen - https://gyazo.com/bfea28b4edd3fa98a889a369990b6712 you can see hanging pixels from masked ruby due to wrong stroke sizing (symbol mask is calculated at a certain size but stroke hangs outside it).
4a. I understand this is a result of the method Renpy uses to "unmask" symbols and its flaws/limitations. How to fix it? How to obtain consistent stroke size that is intended in design and to prevent such huge fluctuations of stroke size? Why does it detect target resolution wrongly?
4b. In general I find the reveal animation very rough and unpleasant, it's a shame Renpy does not excel even in the simple task of rendering the text (which is arguably the primary content in novels). How to achieve WhiteAlbum(2) style text fade-in with every symbol gradually changing opacity? How to apply some gradient wipe to show text in a nice smooth manner? https://gyazo.com/d00105a6431e474a21a26557974d5d4f - as far as I understand it renders entire line (s) and then applied some gradient mask + transparency change, is this possible in Renpy? What modifications would be required to achieve such look?
5. In 6.99.9 (maybe earlier as well) Auto now does not work at all, no matter the settings. Last time I checked (6.99.6) same exact script.rpy and it worked nicely, with "voice wait" and behaving logically. Now if you enable Auto it does not advance at all, no matter how long you wait. It's broken on both voiced and unvoiced lines. Did something change in Auto mechanic or in a way script has to be authored now? But the same script worked in numerous builds previously. I did not find anything in Google on this, why is Auto broken and how to fix it?
6. We need to use some blurred backgrounds/images in the project. To save on filesize we attempted the following approach - making blurred image asset lower resolution and scaling it in code upon display. Sounds reasonable, right? After all, if you blur some image, you can't really tell if it's high resolution or low resolution, and we save huge on filesize. However, it produces a bug since at least 6.18.3 - which still has not been fixed.
Following code:

Code: Select all

image prova blur= im.FactorScale("bg1x.jpg", 4) - declaration of our scaled asset

scene prova blur with dissolve

will produce a background featuring our small image scaled 4 times, however it renders at like 99% opacity for some reason and we can see debug checkerboard beneath (or black bg if we disable debug mode).
https://gyazo.com/209dd8c24f77677c37ef5962877ed0d8 look closely, compare with next screenshot in tab and switch back-n-forth if you need.
To work around this we had to make this "fix"

Code: Select all

transform blurbg:
     xalign 0.5
     yalign 0.5
     zoom 4.0
image provablur= Image("bg1x.jpg")
scene provablur at blurbg with dissolve

Which displays same lowres asset at 4x scale (does the same thing as im.FactorScale but without this 99% opacity issue. What gives?
https://gyazo.com/8e3bf055050a867b2e889ec97f52d412
Shouldn't it just work properly and not make us use this additional transform declaration?
7. Applying blur on layer produces bug where sprites in the layer become transparent but it's such an old bug I feel like it's never going to be fixed and pointless to report...

Code: Select all

    show layer master at boxblur

- produces bug:
https://gyazo.com/cf6ee7016bc8f5bfe26f7af6c637fb87

Code: Select all

     show bg uni at boxblur
    show sylvie at boxblur
    with dissolve

- produces result as expected (but this clumsy declaration is required for every object we want to display)
https://gyazo.com/ed9ed443442052589223c499e036673e
Not to mention this whole "procedural blur" approach is nonsense compared to the power of shaders and all other nice things...
7a. Which brings us to the question on how exactly we can do such things https://gyazo.com/cd02148fe6bf0c9dc13f93a823da7512 - blur layer and all its contents when new layer is summoned above.
8. Not a bug but rather a related question

Code: Select all

    show prova at zoomblur with dissolve
    show sylvie normal with dissolve

This manipulates background and sprite "blurriness" to simulate camera focus shift (from bg to sprite in this case). But the lines are executed sequentially. Is there a way to set them to execute at the same time to get more realistic "camera" effect?

[PyTom]

Can you break these up into logical and related bugs, and post them on github, or on the 6.99.9 release thread? (But github would be better.)

A response to some of these:

1) I'd need to know your platform, at least. I don't think this is happening to very many people (I could be wrong), so it could be some sort of driver issue.

2) Is known on the bug tracker. I was able to repeat it recently.

3) Offhand, this looks like it might be a font bug, where the clockwise/counterclockwise direction of something inside the font is wrong. This is a problem with some TTFs, since they're not meant to be stroked like this. (But it's defined in the spec, and necessary to tell what the inside and outside of a glyph is.)

4) I don't understand what you're trying to say here, and the animated text makes it really hard to understand what's going wrong.

5) Auto does work for me. It's possible that if the preferences have gotten screwed up, you could have broken it. Maybe try deleting persistent.

6-7a) We don't have supported in-engine blurring. I'd suggest pre-blurring assets if you want to do it, until I get time to work on shader support.

Code: Select all

show prova at zoomblur
show sylvie normal
with dissolve

[chiruchirumichiru]

1. "I have tested on Windows 7 Ultimate 64bit with DPI Scaling 200% and 4k monitor." Also while trying to capture footage with OBS I noticed the following - cursor is visible in OBS preview window, but OBS can't capture any footage from the actual game (it grabs first frame and stays on it). Cursor is not visible completely in fullscreen on all recent builds (6.99.x)
GPU is Titan x2 with nvidia drivers. (several driver updates did not fix this issue and I doubt it is caused by anything system-related, this only happens with renpy)
2. Also since 6.99.3 at least. I did not test every build but I tested at least 6.99.3 6.99.6 6.99.9
3. Font is a popular MPlus https://mplus-fonts.osdn.jp/ I doubt very much it has anything to do with font, I suspect it has everything to do with this "3" value in here:

Code: Select all

style.say_dialogue.outlines=[(3,("#190019"),0,0),]

It calculates actual stroke size in px based to some relation to what it thinks current target/render res is. Then it gets funny when DPI scaling is involved (apparently it thinks it renders to 4k in window mode and some 1080p in fullscreen mode?). I'm pretty sure you can reproduce precisely this issue with any font. Note the glitch that happens when furigana is on 2nd line (since both lines are pre-rendered and then unmasked). Even if this bug was not visible, why do I have to be content with some random stroke thickness in various resolutions? Why can't it be some fixed value, or some value fixed in relation to declared project res (1920x1080)?
4. You can see that parts of furigana from 2nd line are rendered and visible before they should be visible. This happens because for example game thinks character + furigana will take 40px vertical space and sets mask height to that value. But due to 3. issue it actually takes 43px (for example), so we see those 3px hanging. I think it's pretty clear in the video, I do not know how to communicate this any clearer, you should be able to reproduce it with any case with 2 (or more) line text using furigana. This issue is from at least 6.99.3 This issue happens in fullscreen. In windowed since stroke is thinner this issue is not visible.
I checked specifically now and you can observe the same issue in Tutorial project by just adding

Code: Select all

define eruby = Character(
    _("Eileen"),
    color="#c8ffc8",
    what_ruby_style=style.ruby_style,
    what_line_leading=10,
    what_outlines=[ (1, "#282") ])

in demo_text.rpy
the issue appears on this line

Code: Select all

    eruby "You are able to write ruby text, which can help clarify how to pronounce words, like {rb}Ren'Py{/rb}{rt}ren-pie{/rt}."

But I have to note in Tutorial project the stroke width seems more stable than in my project. I wonder what is the difference in declaration. Do we declare stroke using some old/wrong method here?

Code: Select all

    style.say_dialogue.outlines=[(3,("#190019"),0,0),]

Additionally, the issue does not seem to appear on lowppi monitor. So if you are using lowppi monitor you might never see it?
4b. Please confirm if this is possible/not possible/possible but hard to do (? Replace default rough unmasking with some gradient mask).
5. Obviously I did that, and it did not help. Both "voice wait" or not, nothing works at all. The line does not advance from current line unless I click it manually (Auto worked fine in at least 6.99.6 and I'm testing the exact same project).
6. Lack of support for something is not the issue (then it would be feature request, wouldn't it? but I'm just reporting bugs) You provide im.FactorScale method. Is it deprecated? Why doesn't it work properly? It displays scaled asset but at some 99% (or 99.5% or I don't know, maybe it's 254 instead of 255 alpha due to some error somewhere in engine) which makes layers below/or debug grid visible (see screenshot). Using another method with transform blurbg: that does supposedly the same (4x scale) produces no bug. We shouldn't use im.FactorScale ? It does not work? It won't be fixed?
8. This worked, thank you!

Thank you for taking the time to consider the reports. I'm sorry I did not find "release thread" or whatever that is. Google pointed me here.

[PyTom]

1. "I have tested on Windows 7 Ultimate 64bit with DPI Scaling 200% and 4k monitor." Also while trying to capture footage with OBS I noticed the following - cursor is visible in OBS preview window, but OBS can't capture any footage from the actual game (it grabs first frame and stays on it). Cursor is not visible completely in fullscreen on all recent builds (6.99.x)

I just tried it on my Windows 10 box, and the cursor is visible. I'd suggest uninstalling capture programs, as they might confuse the issue. If there's a problem with capture software, that's likely to be a problem with the capture software - I believe that Ren'Py is producing valid OpenGL (and would love to know if it's not), so if a capture program can't deal with that - I don't think there's anything I can do about it.

GPU is Titan x2 with nvidia drivers. (several driver updates did not fix this issue and I doubt it is caused by anything system-related, this only happens with renpy)

There has to be some sort of system or OS-related component - since otherwise, everyone would be seeing it.

3. Font is a popular MPlus https://mplus-fonts.osdn.jp/ I doubt very much it has anything to do with font, I suspect it has everything to do with this "3" value in here:

Code: Select all

style.say_dialogue.outlines=[(3,("#190019"),0,0),]

It calculates actual stroke size in px based to some relation to what it thinks current target/render res is. Then it gets funny when DPI scaling is involved (apparently it thinks it renders to 4k in window mode and some 1080p in fullscreen mode?). I'm pretty sure you can reproduce precisely this issue with any font. Note the glitch that happens when furigana is on 2nd line (since both lines are pre-rendered and then unmasked).

The way the outlines work is that:

drawable_scale = drawable / virtual

When 0 <= drawable_scale < 2.0, outline_scale = 1.0
When 2.0 <= drawable_scale < 3.0, outline_scale = 2.0
When 3.0 <= drawable_scale < 4.0, outline_scale = 3.0
etc.

The reason for this is that we want to ensure that when a font has multiple outlines, they remain proportional to each other. You should be able to check the scaling in log.txt, in a line like:

Screen sizes: virtual=(800, 600) physical=(672, 504) drawable=(672, 504)

Even if this bug was not visible, why do I have to be content with some random stroke thickness in various resolutions? Why can't it be some fixed value, or some value fixed in relation to declared project res (1920x1080)?

Well, it's not random - it tries to pick an outline size that remains proportional to other outlines. If you want a fixed outline size - always 3 drawable pixels - then you can have:

Code: Select all

style.say_dialogue.outlines=[(absolute(3),("#190019"),0,0),] 

4. You can see that parts of furigana from 2nd line are rendered and visible before they should be visible. This happens because for example game thinks character + furigana will take 40px vertical space and sets mask height to that value. But due to 3. issue it actually takes 43px (for example), so we see those 3px hanging. I think it's pretty clear in the video, I do not know how to communicate this any clearer, you should be able to reproduce it with any case with 2 (or more) line text using furigana. This issue is from at least 6.99.3 This issue happens in fullscreen. In windowed since stroke is thinner this issue is not visible.

The issue here is that the line split is in the wrong place. There's a discussion of this at:

https://www.renpy.org/doc/html/text.htm ... t-concerns

You may want to increase line_leading and decrease line_spacing, I think.

4b. Please confirm if this is possible/not possible/possible but hard to do (? Replace default rough unmasking with some gradient mask).

Right now, this is not possible. It's been on my todo list forever, but I probably won't get around to it until later this year.

5. Obviously I did that, and it did not help. Both "voice wait" or not, nothing works at all. The line does not advance from current line unless I click it manually (Auto worked fine in at least 6.99.6 and I'm testing the exact same project).

Can you try it in the tutorial? Since I just tested, and it works for me there. I just tested it a few minutes ago.

6. Lack of support for something is not the issue (then it would be feature request, wouldn't it? but I'm just reporting bugs) You provide im.FactorScale method. Is it deprecated? Why doesn't it work properly? It displays scaled asset but at some 99% (or 99.5% or I don't know, maybe it's 254 instead of 255 alpha due to some error somewhere in engine) which makes layers below/or debug grid visible (see screenshot). Using another method with transform blurbg: that does supposedly the same (4x scale) produces no bug. We shouldn't use im.FactorScale ? It does not work? It won't be fixed?

I'll have to look into this at some point to determine if it's behaving properly. Until then, Transform is almost certainly much better.

Thank you for taking the time to consider the reports. I'm sorry I did not find "release thread" or whatever that is. Google pointed me here.

The release thread is at:

viewtopic.php?f=8&t=37513

I'd suggest replying there, since it'll make it easier for me to find replies.

[chiruchirumichiru]

I just tried it on my Windows 10 box, and the cursor is visible. I'd suggest uninstalling capture programs, as they might confuse the issue.

The issue happens without any capture/overlay software running. It began to appear on the first "HighDPI" build I've tested. It appears on both 150% DPI and 200% DPI. I can check on my Windows 10 machine (Intel GPU) some time later. You say the cursor is visible. Is Renpy running in some borderless window or it asks dedicated fullscreen? Because alt-tab does not work for me smoothly either.

There has to be some sort of system or OS-related component - since otherwise, everyone would be seeing it.

Yes, that's what's puzzling.

You should be able to check the scaling in log.txt, in a line like:

Code: Select all

Screen sizes: virtual=(1920, 1080) physical=(3648, 2052) drawable=(3648, 2052)

Is something wrong here? This seems like a windowed mode.

Code: Select all

Screen sizes: virtual=(1920, 1080) physical=(3840, 2160) drawable=(3840, 2160)

This is after launching/exiting in fullscreen.

If we take into account your explanation it seems in windowed mode it uses 1.0 and in alt-enter fullscreen it becomes 2.0 (thick outlines)

Code: Select all

Screen sizes: virtual=(1920, 1080) physical=(1200, 675) drawable=(1200, 675)

This is on lowppi monitor. I wonder why the outlines are thickest here then.

Ok I tried to figure this out but still don't get why it works like this:
https://gyazo.com/1ff3085490f345d32e58fd32b13cc8a1
EACH of viewing modes produces wildly different results, with no consistency (stroke width in px / viewport width value is different in all 3 cases)
LowPPI 1200x675 - thickest at 0,0025
Fullscreen 4k 3840x2160 - 0,0015625
Windowed 4k 3654x2055 - 0.00082101806 (windows calculator even refuses to count such value)
As you can see they are visually very different, we don't know what device/ppi environment user will be playing on, how to achieve some controlled design? The whole 4. issue is also a direct result of this one. If we had some predictable strokes, we could fix that "hanging pixel" issue with line height/spacing or something at least.

Why does it work like that? Do you really consider it a proper output? Why doesn't it calculate as
3/1920 = 0,0015625 (stroke value / project width value set in options.rpy) and render stroke to that value no matter what the width of viewport is (if it's 1200 then stroke should be 1,875 px - you can round to 2, and if it's 3654 the stroke is 3654 * 0,0015625 = 5,709375 = 6px and not 3px). Then everything would always be nice and predictable no matter the physical resolution of user device. Honestly I just can't understand why it does not work like that and why this wasn't reported previously. There are a tons of devices with exotic resolutions/ppi now on the market (Samsung Phones, Microsoft Surface, wide iPhone/iPad family)

When 0 <= drawable_scale < 2.0, outline_scale = 1.0

Even from just this it's obvious nothing is done to scale stroke value below in case our physical res < project res (easily the case on 1280x720 screen for a 1920x1080 project).
The issue is probably less prominent in Tutorial project due to its low 800x600 size. Last time I checked it's 2016 and even Japan long moved to 1920x1080 games.

Well, it's not random - it tries to pick an outline size that remains proportional to other outlines. If you want a fixed outline size - always 3 drawable pixels - then you can have:

Code: Select all

style.say_dialogue.outlines=[(absolute(3),("#190019"),0,0),] 

Well it's not really a fix because the (stroke width in pixels/viewport width) value would still be wrong in many cases.

drawable_scale = drawable / virtual

how about simply some_value_we_draw_the_strokes_with = value_set_in_options.rpy*(drawable / virtual) then?

4.

The issue here is that the line split is in the wrong place.

No, the issue is that stroke width is unpredictable. If clipping is predictable indeed it could be addressed by line spacing.

Right now, this is not possible. It's been on my todo list forever, but I probably won't get around to it until later this year.

Thank you for the information. Every day this is not implemented, god kills a catgirl. Think of the catgirls!

Can you try it in the tutorial? Since I just tested, and it works for me there. I just tested it a few minutes ago.

5. Auto works in tutorial indeed. I can only confirm no changes have been made to my script since 6.99.6 and auto works there as well, but does not work in 6.99.9 This is most mysterious.

[PyTom]

5. Auto works in tutorial indeed. I can only confirm no changes have been made to my script since 6.99.6 and auto works there as well, but does not work in 6.99.9 This is most mysterious.

I think I know the problem - what does your say screen looks like? Does it have id "what" like the normal screen does?

(Sorry, going to sleep now.)