Ren'Py 6.11.0 Public Pre-Release

[Counter Arts]

PyTom said something about textures having one extra pixel or something right? Does that something to do with it?

[Jake]

Jake - I can't repeat the grid problem. Are you using any sort of a Transform on the grid or the window containing it?

The code which produces that grid is as follows:

Code: Select all

            grid = Grid(x, fighterCount, padding=5, style="GridStatsGrid",*lines)
            window = Window(grid, style="GridStatsWindow")

            renpy.show("_battleGridStatsWindow", what=window, layer=l)

'l' will be set to a custom-added layer, above 'master' but below 'transient'; 'lines' is a big list of all the items that go in the grid; each name or stat ("label: x/y") and the facing at the end (N/E/S/W) are all Text instances with xalign set to either 0.0 or 0.5 as a named parameter.

The styles are as follows:

Code: Select all

    # GridStatsDisplay
    style.GridStatsGrid = Style(style.default)
    style.GridStatsWindow = Style(style.window)

    style.GridStatsWindow.background = Frame("gfx/frame.png", 25, 25)
    style.GridStatsWindow.xpadding = 15
    style.GridStatsWindow.ypadding = 15

I've seen the vertical lines before as well, but I don't know what's causing them. (My current theory is that it's rounding in the graphics card.)

It looks like the kind of problem you often get when your texture coords or your viewport coords are a bit off, to me...

[PyTom]

The problem is somewhat texture-coordinate related. Basically, OpenGL is choosing to sample the texture coordinates at the center of a pixel, even if only a small fraction of that pixel is covered by a triangle. When we scale up, this can lead to the texture coordinate being sampled outside of the pixels that we've defined, and hence the real data being averaged with black-transparent.

I have an idea of how I can fix this, by distorting texture coordinates when scaling up.

[Jake]

Also - this is unrelated, and happens in 6.10 as well, but it's still a bug: if you right-click on the dock icon of the Ren'Py launcher in OSX and choose 'Quit', then:
- the window remains visible, and the little arrowhead next to the icon suggests it's still running
- you can still move the window around
- none of the button/label/things are responsive if you click on them
- the close button on the title bar of the window doesn't work any more
- clicking/right-clicking on the dock icon again and again causes the app to finally crash out totally, with the generic "The application 'Ren'Py Launcher' has quit unexpectedly, etc., etc." message.

The dump is attached.

[PyTom]

Jake:

I'm still not able to reproduce the grid problem. I'm using the code:

Code: Select all

init python:
    style.GridStatsGrid = Style(style.default)
    style.GridStatsWindow = Style(style.window)

    style.GridStatsWindow.xpadding = 15
    style.GridStatsWindow.ypadding = 15
        
label start:

    python hide:

        lines = [ Text("This is some long text.") ] * 5
        grid = Grid(5, 1, padding=5, style="GridStatsGrid",*lines)
        window = Window(grid, style="GridStatsWindow")
    
        renpy.show("_battleGridStatsWindow", what=window, layer="transient")
    
    pause

Would it be possible for you to make a minimal demo, so I can see if your code is fails on my system, or if it's a more specific problem?

[PyTom]

Also - this is unrelated, and happens in 6.10 as well, but it's still a bug: if you right-click on the dock icon of the Ren'Py launcher in OSX and choose 'Quit', then:

This has just been fixed.

[Jake]

I'm still not able to reproduce the grid problem. I'm using the code:
...
Would it be possible for you to make a minimal demo, so I can see if your code is fails on my system, or if it's a more specific problem?

The code you supplied, pasted over the top of the default contents of script.rpy, produces the following results on my machine:

The machine in question is a MacBook Pro, 2.4GHz Core2 Duo, GeForce 8600M GT, OSX Tiger 10.4.11

It doesn't happen on my Windows machine, a 2.4GHz Core2 Duo, GeForce 8600 GT, Vista Home Premium.

Both are running 6.11.0.f.

Interestingly, if I go into the game menu on the Mac with this example code, I don't see the over-spilling grid text down the side, only when the menu's not up. I wonder whether it's maybe something to do with whether or not the item starts on or off the screen?

[PyTom]

Jake >>> Ren'Py uses 4 OpenGL ClipPlanes to clip text and such to the virtual screen. For some reason, that's not operating properly on your mac. (Annoyingly, it's working fine on my mac.) I've made a few changes to when I enable clipping, in the hopes that might fix it, and added a count of the number of clipping planes to opengl.txt.

I'm going to release 6.11.0g, and if that doesn't fix it, I'll work with you to find a solution.


EDIT: Can you see if the viewport demo in the interface section works? And can you intentionally position an image at offscreenright, and see how it renders?

[PyTom]

And, 6.11.0g is up at:

http://www.renpy.org/wiki/renpy/releases/6.11.0

There are three big changes:

The first is the fix to the upscaling of texture coordinates. Previously, in some cases we could sample a pixel inside a texture that wasn't defined. This could lead to some artifacts when upscaling, including 1-pixel-tall lines between boxes, and surrounding the screen. This was fixed by slightly distorting the texture coordinates when upscaling (by half a texel at most.) This distortion usually isn't visible, but might be visible during a dissolve or imagedissolve, when the distortion changes very slightly.

The second is that the maximize button is disabled on windows. This is because of a problem in Windows 7 where, when the "Start Orb" overlaps the game window, OpenGL performance drops substantially. (On my laptop, it goes from ~400fps to ~30.) While we can't fix the underlying problem, hitting maximize made it always occur - so maximize is now disabled.

The second major change is a change in focus behavior. Previously, unhovered would be called at the start of each interaction, which made it overly easy to send the system into focus loops. Now, it's only called when a displayable loses focus due to user interaction. Please let me know if this causes major problems - I suspect it will actually make life easier.

Other changes are:

- Added the quickstart to the manual.
- {fast} works in menus and all-at-once mode.
- Unbranding the exception message.
- Menus no longer have a choice highlighted by default.
- A proper error is given when someone tries to supply an empty string as a displayable.
- Jake's Mac quit bug is fixed.
- Problems with the interaction of NVL-mode and window show/hide have been fixed.
- A problem with default focus and clipping was fixed. (This manifested when doing a slide transition.)

Right now, I show Jake's mac clipping bug and Spiky's mouse problem as outstanding. Thanks to everyone who's reported problems, as finding unknown problems (and in some cases, finding out what behaviors people consider problematic) makes Ren'Py better.

I'm starting to get to the point where I'd be comfortable releasing 6.11.0, once these bugs are fixed. I'm not going to have the documentation done in a reasonable timeframe, but all the issues that I had blocking release are now closed.

[Mihara]

The second major change is a change in focus behavior. Previously, unhovered would be called at the start of each interaction, which made it overly easy to send the system into focus loops. Now, it's only called when a displayable loses focus due to user interaction. Please let me know if this causes major problems - I suspect it will actually make life easier.

...That was a bad idea that makes life quite inconvenient on Windows other than 7, because now you cannot work with near-fullscreen sizes while keeping the editor on a second monitor -- you have to manually resize the window every bloody time you reload the script. Previously, maximizing the window was sufficient and could be accomplished quickly.

[Mihara]

The first is the fix to the upscaling of texture coordinates. Previously, in some cases we could sample a pixel inside a texture that wasn't defined. This could lead to some artifacts when upscaling, including 1-pixel-tall lines between boxes, and surrounding the screen. This was fixed by slightly distorting the texture coordinates when upscaling (by half a texel at most.) This distortion usually isn't visible, but might be visible during a dissolve or imagedissolve, when the distortion changes very slightly.

This -- I think it's this, it might be whatever was done to fix the window hide/show interaction with NVL -- produces unpleasant effects in NVL mode on high zooms when large amounts of text are printed on the screen with multiple intervening pauses within a single paragraph.

After a mid-sentence pause, which shows the ctc indicator, once the indicator is removed, the text already printed visibly shrinks. This can continue for the entire page, making it very noticeable. Sometimes it's horizontal, sometimes it's vertical, sometimes both. The amount of distortion does not appear to be dependent on the size of the CTC relative to the font, either.

That texel distortion is very noticeable during imagedissolve and other dissolves on lower native resolutions, if the sprites are drawn with thick lines on their edges -- when such dissolves occur often, it appears the sprites actually dance.

[PyTom]

...That was a bad idea that makes life quite inconvenient on Windows other than 7, because now you cannot work with near-fullscreen sizes while keeping the editor on a second monitor -- you have to manually resize the window every bloody time you reload the script. Previously, maximizing the window was sufficient and could be accomplished quickly.

I'll see if I can make Ren'Py preserve the old physical screen size after a reload.

This -- I think it's this, it might be whatever was done to fix the window hide/show interaction with NVL -- produces unpleasant effects in NVL mode on high zooms when large amounts of text are printed on the screen with multiple intervening pauses within a single paragraph.

Can you give some example code? I'd like to at least see what's going on here for you. It's not that bad for me.

That texel distortion is very noticeable during imagedissolve and other dissolves on lower native resolutions, if the sprites are drawn with thick lines on their edges -- when such dissolves occur often, it appears the sprites actually dance.

I'd also like an example here.

To some extent, we're stuck picking the lesser of two evils here. Either have the extra lines (which show up at the sides of the screen, and between the boxes in two_window_say) or the distortion here. I'm not sure how to make it work otherwise (without rendering to a texture every frame, when we scale up the screen. That could work, but would hurt performance quite a bit.)

[Mihara]

Can you give some example code? I'd like to at least see what's going on here for you. It's not that bad for me.

Here. It's extremely annoying when the 640x480 project is zoomed up to the entire 1920x1200 monitor.

Pardon me if I'm not suitably polite without me noticing, but that fix is worse than the original problem.
...Oh, and window show/hide is not fixed correctly either, you will see the example of what's wrong with it inside as well.

[Mihara]

...figured that bloody one out.

The screen name called for a yes-no prompt for most of the code is "yesno_prompt". That is, everything I have so far found except the code that calls for a quit prompt when the OS close window button is clicked.

That one calls a screen named "yesno" for an unclear reason. Overriding it with a "screen yesno:" produces a non-functional screen, since apparently, action names don't match too.

[Jake]

Jake >>> Ren'Py uses 4 OpenGL ClipPlanes to clip text and such to the virtual screen. For some reason, that's not operating properly on your mac. (Annoyingly, it's working fine on my mac.) I've made a few changes to when I enable clipping, in the hopes that might fix it, and added a count of the number of clipping planes to opengl.txt.

I'm going to release 6.11.0g, and if that doesn't fix it, I'll work with you to find a solution.

Same problem on 6.11.0g; I've attached the opengl.txt to this post, but the spoiler is that it reports 6 clipping planes.

opengl.txt

(3.63 KiB) Downloaded 56 times

EDIT: Can you see if the viewport demo in the interface section works? And can you intentionally position an image at offscreenright, and see how it renders?

The viewport demo seems to work perfectly fine. Positioning an image such that it passes offscreen at all results in the image being drawn into the off-screen area; I tried several different positions, but the result in each case was the same: