Ren'Py 6.99.12 Released

[PyTom]

Ah, and for those of you who feel like downloading 6.99.12.3, it's at:

https://www.renpy.org/dl/6.99.12.3/

[nyaatrap]

Hello, thanks for the fix about Japanese path issue.
However, every translations need to be updated due to gui variable change
from

Code: Select all

define gui.default_font = u'MTLc3m.ttf'

to

Code: Select all

define gui.text_font = u'MTLc3m.ttf'

and so on.
It looks translate_font("japanese", "MTLc3m.ttf") changes gui.default, not gui.text.

[PyTom]

6.99.12.3.2114 is out. It fixes the problem, and exposes all text properties to the gui system. So you have gui.text_bold, gui.label_text_kerning, etc.

[PyTom]

I've bumped the prerelease to 6.99.12.3.2121.

This has some updates to the Japanese and Russian translations. It also fixes an issue where going to a menu would reset sounds, causing the wrong voice to be recorded in history. (And perhaps preventing voice replay from working.)

Unless there is some major issue, I'm likely going to release this tomorrow so I can roll into AttributeImage and 6.99.13 development.

[ISAWHIM]

Found a glitch which is non-critical... Only tested on Windows 8.1...

I have dual-screen, so I am unsure if that may be part of the issue, but here is the minor issue.

When in "Full screen", (not windowed), there is no actual "Screen" for the game. There is, we see it, but in windows, it is invisible. Can test by hovering over the toolbar and you see no "capture" of the screen. Also, no video-capture, or "Print screen" capture, or other software "window" capturing works.

However, adding the windows border, while full-screen, will allow the screen to be captured.

Actually, it is kind-of odd, the things it displays in the menubar for the running game. Sometimes it is just invisible, other times it is black with odd box outlines of things that are not even on the screen, (vertical boxes and horozontal boxes that are not the textboxes or anything visible on the game.)

Also, the game does not "capture the mouse" when in full-screen. Traditionally, that is the desired "effect", so your mouse does not drift out of the full-screen game, on multiple monitors, and start clicking desk-icons and launching programs in the background. (Obviously, you need to test that on dual monitors.)

EG, RenPy is not actually going to "full screen", it is going into "borderless window", at the screens resolution. (That is also taxing on the video-drivers, a bit...)

[PyTom]

First off, I split ISAWHIM's wishlist into its own thread viewtopic.php?f=8&t=42476 , since discussion of it was blowing up to multiple pages.

I'm a bit confused by what you're saying above in this thread. When run fullscreen, Ren'Py does use the "borderless window" approach. I've found through experience that works a lot better than approaches that attempt to set the video mode to something different than normal. It doesn't risk messing the player's desktop if the game terminates early, for example.

I just tested for issues when it comes to odd display on Windows 10 dual monitor, and I don't see any problems. I don't understand what problems there could be with the menubar, since Ren'Py does not display a windows menubar. (It is possible you have some sort of buggy video driver that is causing things to render incorrectly.)

Ren'Py has a built-in screenshot function, which you can access by pressing 's'. Problems with other screenshot techniques should be taken up with the respective developers of those programs. Ren'Py is using a perfectly normal display technique, so if something can't capture it it's a problem with the capture program.

We don't capture the mouse because it's unnecessary for visual novels. It might makes sense to do so in games that use the mouse for aiming, but when it comes to a VN, I don't see a reason to force people to switch out of fullscreen mode to interact with a window on another monitor.

[PyTom]

I've released Ren'Py 6.99.12.3.2123 to the Ren'Py release channel. It's basically what's describe above, along with a change that means it does not read system fonts when config.developer is True. (This is intended to prevent games from depending on system fonts.)

[nyaatrap]

I noticed, does a new keymap "toggle_afm" documented?

[vollschauer]

Kind of, a PR for a updated keymap is in the pipe ...

[IrinaLazareva]

Hello. What's wrong with renpy.input() in Ren'Py 6.99.12.3.2123 (with GUI)?
There is a bug or I miss something?
viewtopic.php?f=8&t=42629

AttributeError: 'StoreModule' object has no attribute 'dialogue_xalign'

[philat]

Well, for whatever reason, the new default input screen has an xanchor dialogue_xalign property that is new, but dialogue_xalign is not defined. Seems like a minor bug; for now, I would imagine you can comment it out.

[PyTom]

Here's a working new input screen and styles.

Code: Select all

screen input(prompt):
    style_prefix "input"

    window:

        vbox:
            xalign gui.dialogue_text_xalign
            xpos gui.dialogue_xpos
            xsize gui.dialogue_width
            ypos gui.dialogue_ypos

            text prompt style "input_prompt"
            input id "input"

style input_prompt is default

style input_prompt:
    xalign gui.dialogue_text_xalign
    properties gui.text_properties("input_prompt")

style input:
    xalign gui.dialogue_text_xalign
    xmaximum gui.dialogue_width

[IrinaLazareva]

Here's a working new input screen and styles.

Perfect! Thanks!

[PyTom]

I've just put 6.99.12.4.2168 up on the prerelease channel, and also at https://www.renpy.org/dl/6.99.12.4/ . This is mostly a bugfix release for Ren'Py 6.99.12, including a couple of fairly major bugs:

* The input screen of the new GUI was broken.
* A memory alignment issue that could result in a SIGBUS crash on ARM-based Android devices when playing video has been fixed.

In addition, the console has been updated to match more the Ren'Py developer interface, and to add new features like being able to debug during exceptions and to save history and watches. A full development changelog is at:

https://www.renpy.org/dev-doc/html/changelog.html

Also, Steam support was just updated to work with this (pre)release, so please re-download the steam files if that's your thing.

[ISAWHIM]

Sorry for the wishlist thing... I wasn't expecting replies to it. It was a rhetorical statement of wishes. (I don't expect a reply letter from Santa either. )

The window issue is not external-software related. Even the default "windows" capture, "The PrintScreen key", does not work. That captures windows screen-buffer, directly, and places the image into your clipboard. It captures everything except RenPy's screen, showing the windows behind it, or your desktop if you have no other windows open.

RenPy apps, all programs with a window, usually have a taskbar display. Unless it is in module-mode. (That is how we know programs are running, without going to the task-manager.) When you hold your mouse over, say... Chrome, it shows the page you are on, in chrome, when it is minimized or if it is behind another window. (Without dual displays, you never see it when in full-screen, because the taskbar is covered by the program, in most cases.) The screen for RenPy does not display there either, if it is fullscreen, non-windowed.

The chances that just RenPy is the only program that does this, and no other, and it is the drivers issue, is slim-to-none. This is all updated software and a standard Radeon-7970HD video-card, and the other was the built-in Intel-Display driver. None show the RenPy screen and none can capture a screen-shot from the program, when running in fullscreen non-windowed mode.

To test this... Launch a RenPy project. Set the display to "Fullscreen". Move your mouse to the other window's taskbar and hover your mouse over that games menubar, in the taskbar. (The tab with the same name as the game you just launched.) Should pop-up with a snapshot of the screen as you see it on the other monitor, or in the last state it was displayed, before being minimized.

Minimized, it displays a tiny black "X" or something where the thumbnail/snapshot of the screen should be, maximized, it displays... nothing, or a black box in the top left corner, or odd boxes all over, or solid black... depending where you are, in the game/novel. If you hover over the blankness... it should bring-up the screen, and show you that screen on top... Mine shows nothing.

Switch back to windowed, and now the taskbar menu shows the snapshot of the screen, and windows printscreen now works.

Like I said, it isn't a real issue. Few have dual-displays. Even less actually use screen-capture...

Same with the mouse... But even in a visual-novel, your hand can "drift" the mouse off the screen, and end-up clicking out onto your second desktop, hitting icons, launching other programs. (If you have a desktop like mine, where my icons run off both my screens, into purgatory... That happens a lot! Happens more when I do visual novels, because I am usually focusing on reading and clicking, not holding my hand steady and re-positioning my mouse every time I click.)

Going to be remapping that "S" key to "WASD" movement/input anyways... Why is it not a standard key, like "Print Screen", or "F12"? Just curious... No reply actually needed.