Ren'Py 6.11.0 Pre-Released
Forum rules
This is the right place for Ren'Py help. Please ask one question per thread, use a descriptive subject like 'NotFound error in option.rpy' , and include all the relevant information - especially any relevant code and traceback messages. Use the code tag to format scripts.
This is the right place for Ren'Py help. Please ask one question per thread, use a descriptive subject like 'NotFound error in option.rpy' , and include all the relevant information - especially any relevant code and traceback messages. Use the code tag to format scripts.
- jack_norton
- Lemma-Class Veteran
- Posts: 4084
- Joined: Mon Jul 21, 2008 5:41 pm
- Completed: Too many! See my homepage
- Projects: A lot! See www.winterwolves.com
- Tumblr: winterwolvesgames
- Contact:
Re: Ren'Py 6.11.0 Pre-Released
EPIC WIN so far!
Everything works, including my effects! Now I see explosions destroying my enemies
Everything works, including my effects! Now I see explosions destroying my enemies
Re: Ren'Py 6.11.0 Pre-Released
Still no change on Eee 901/Linux -- GL plays video in displayable but doesn't play it fullscreen, software plays video fullscreen but does not play it in a displayable.PyTom wrote:- Fixed a potential (but unlikely) race condition in the video playback code.
I guess that should be documented somewhere as a known problem for now until anyone else bumps into it.
Re: Ren'Py 6.11.0 Pre-Released
Mmm. I did some test with this simple code and clicked the Quit button in preference menu to quit this example,
error message shows up again and again.
error message shows up again and again.
Code: Select all
init:
$ t = 1
screen toggle:
textbutton 'ToggleTest' action ToggleVariable('t', true_value=0, false_value=1)
label start:
show screen toggle
'.'
Code: Select all
Exception in thread Thread-1:
Traceback (most recent call last):
File "threading.pyo", line 532, in __bootstrap_inner
File "threading.pyo", line 484, in run
File "E:\renpy-6.11.0\renpy\loadsave.py", line 326, in autosave_thread
File "E:\renpy-6.11.0\renpy\loadsave.py", line 158, in save
File "E:\renpy-6.11.0\renpy\loadsave.py", line 47, in dump
PicklingError: Can't pickle <type 'module'>: attribute lookup __builtin__.module failed
Re: Ren'Py 6.11.0 Pre-Released
I'm developing a class that shows a hint text for button when there's mouse cursor over the button. As long as I have only one button everything is all right, but when I add second button with the hint, then Ren'Py stops responding to any mouse clicks or keyboard. I'm not completely sure if this isn't my mistake. I reproduced it with Ren'Py 6.11.0e and 6.10.2e, both on Window 7 x64.
The code to reproduce the problem is in the attachment.
The code to reproduce the problem is in the attachment.
- Attachments
-
- script.rpy
- Code to reproduce the problem.
- (1.84 KiB) Downloaded 75 times
Re: Ren'Py 6.11.0 Pre-Released
Noticed some rather bizarre behaviour, which may or may not be a bug.
Eee 901/Linux, RenPy runs rather slow for some reason, but ok, I guess the machine is just not very fast in the first place.
NVL mode, running in GL. Walls of text are routinely printed that take up almost the entire screen. I'm reading them as slow text. The font is DejaVu Condensed.
In the beginning of the page, FPS is actually high enough for me to see every individual character being printed (I'm reading at 30 CPS) but once it gets past the third line or so, it drops, and continues dropping until the page is full. By the end, it's actually only high enough for me to see a whole word pop up on screen with every frame, not a single character.
Once the page clears, FPS is back, and the cycle immediately repeats as a new wall of text is printed. It's as if RenPy is rendering the entire text window from scratch with every new character, but even if that is what it does, it probably shouldn't be so slow as to cause FPS to drop to 5-6...
Eee 901/Linux, RenPy runs rather slow for some reason, but ok, I guess the machine is just not very fast in the first place.
NVL mode, running in GL. Walls of text are routinely printed that take up almost the entire screen. I'm reading them as slow text. The font is DejaVu Condensed.
In the beginning of the page, FPS is actually high enough for me to see every individual character being printed (I'm reading at 30 CPS) but once it gets past the third line or so, it drops, and continues dropping until the page is full. By the end, it's actually only high enough for me to see a whole word pop up on screen with every frame, not a single character.
Once the page clears, FPS is back, and the cycle immediately repeats as a new wall of text is printed. It's as if RenPy is rendering the entire text window from scratch with every new character, but even if that is what it does, it probably shouldn't be so slow as to cause FPS to drop to 5-6...
-
- Regular
- Posts: 70
- Joined: Sun Jul 15, 2007 2:36 pm
- Projects: EH...
- Contact:
Re: Ren'Py 6.11.0 Pre-Released
I've been on a bit of a hiatus for a while (trying to recover—mostly unsuccessfully, it seems—from an RSI), but 6.11 sounded exciting, so I had to at least try tossing the current version of Errant Heart at it to see how it worked.
So far it looks great (hooray for fullscreen now working with my 16:10 aspect ratio!), but I did notice one little quirk I wanted to ask about: I've mostly been using sprites scaled with ATL transforms so that I can use one image and display it at a number of different sizes. However, it seems that whenever I use a "with dissolve" transition (either adding or removing another sprite, or on a text window), the sprites on screen will momentarily get blurry during the transition. While it'd be pretty cool to have blur as a special effect option, it's a bit distracting for the sprites to get fuzzy each time something is added or removed from the scene.
Is there something I'm doing wrong (i.e., am I using outdated language for dissolves?), or is this just part of the GPU acceleration?
So far it looks great (hooray for fullscreen now working with my 16:10 aspect ratio!), but I did notice one little quirk I wanted to ask about: I've mostly been using sprites scaled with ATL transforms so that I can use one image and display it at a number of different sizes. However, it seems that whenever I use a "with dissolve" transition (either adding or removing another sprite, or on a text window), the sprites on screen will momentarily get blurry during the transition. While it'd be pretty cool to have blur as a special effect option, it's a bit distracting for the sprites to get fuzzy each time something is added or removed from the scene.
Is there something I'm doing wrong (i.e., am I using outdated language for dissolves?), or is this just part of the GPU acceleration?
- PyTom
- Ren'Py Creator
- Posts: 16088
- Joined: Mon Feb 02, 2004 10:58 am
- Completed: Moonlight Walks
- Projects: Ren'Py
- IRC Nick: renpytom
- Github: renpytom
- itch: renpytom
- Location: Kings Park, NY
- Contact:
Re: Ren'Py 6.11.0 Pre-Released
I don't think that should happen - can you put together a minimal demo, so I can see what's going on?
Supporting creators since 2004
(When was the last time you backed up your game?)
"Do good work." - Virgil Ivan "Gus" Grissom(When was the last time you backed up your game?)
Software > Drama • https://www.patreon.com/renpytom
Re: Ren'Py 6.11.0 Pre-Released
I can confirm that 'goes blurry' on my Windows machine with Nvidia GX260.
I thought it was a normal artefact of scaling, though. It's quite subtle and hard to notice.
I thought it was a normal artefact of scaling, though. It's quite subtle and hard to notice.
-
- Regular
- Posts: 70
- Joined: Sun Jul 15, 2007 2:36 pm
- Projects: EH...
- Contact:
Re: Ren'Py 6.11.0 Pre-Released
Okay, here's a quick example that should demonstrate the issue. I've tried it on my laptop and desktop (both running WinXP), and they both look the same, so I don't think it's device-specific...though both systems do use nVidia chips (a Quadro NVS 110M and GeForce 8800 GT, respectively).PyTom wrote:I don't think that should happen - can you put together a minimal demo, so I can see what's going on?
- Attachments
-
- A Little Blurry-win32.zip
- (6.52 MiB) Downloaded 26 times
-
- Veteran
- Posts: 351
- Joined: Sat Sep 05, 2009 8:47 am
- Contact:
Re: Ren'Py 6.11.0 Pre-Released
Hmm.
I just ran this like, five times in a row on a WinXP laptop with crummy Intel integrated graphics (mobile 965 chipset) and I couldn't see anything at all. Like I said, I tried five times in a row—with my eyes about six inches from the monitor.
So it's probably how the graphics driver implements OpenGL. Anyone with an ATI card out there getting different results?
I just ran this like, five times in a row on a WinXP laptop with crummy Intel integrated graphics (mobile 965 chipset) and I couldn't see anything at all. Like I said, I tried five times in a row—with my eyes about six inches from the monitor.
So it's probably how the graphics driver implements OpenGL. Anyone with an ATI card out there getting different results?
Re: Ren'Py 6.11.0 Pre-Released
Same here. I played this on my PC with Gigabyte GF250 GTS and I can't seem to find any sort of graphical glitch - everything seems to be fine, as far as I can see. I don't know if this may be the driver implementation bug, but you might try updating your drivers, if you didn't done this in a while. I also agree it would be good to check this on an ATI card and a direct equivalent would be the best.
I try to do a stronger Ren'Py check on my specs. Who knows if there are any driver or card-specific bugs hiding somewhere...
I try to do a stronger Ren'Py check on my specs. Who knows if there are any driver or card-specific bugs hiding somewhere...
-
- Regular
- Posts: 70
- Joined: Sun Jul 15, 2007 2:36 pm
- Projects: EH...
- Contact:
Re: Ren'Py 6.11.0 Pre-Released
Updating the drivers on my laptop isn't really an option, sadly, since it's just not supported anymore (and my attempts with unofficial methods just caused too many headaches). The drivers for my desktop were updated fairly recently—I believe only two or three weeks ago—so I doubt that would make much of a difference.IceD wrote:I don't know if this may be the driver implementation bug, but you might try updating your drivers, if you didn't done this in a while. I also agree it would be good to check this on an ATI card and a direct equivalent would be the best.
Hmm, maybe it's just time for a new laptop and video card...
- PyTom
- Ren'Py Creator
- Posts: 16088
- Joined: Mon Feb 02, 2004 10:58 am
- Completed: Moonlight Walks
- Projects: Ren'Py
- IRC Nick: renpytom
- Github: renpytom
- itch: renpytom
- Location: Kings Park, NY
- Contact:
Re: Ren'Py 6.11.0 Pre-Released
@bberation, are you running the game in a mode that scales it up (such as in fullscreen mode, or when you make the window bigger)?
If so, I can repeat the problem here.
There's a difference between how the screen is rendered normally, and when you're in a dissolve or an imagedissolve. In normal rendering mode, the images are drawn to the screen directly. In dissolve mode, we first draw everything to a texture the size of the virtual screen, and then draw that texture to the physical screen, scaling it up as necessary.
What's happening is that when an image is scaled down, and scaled back up again, there's a little "bonus resolution". The image that's being drawn is sharper than it would have been has the original image been loaded at the lower resolution. When we do the dissolve, rendering to the texture lowers the image's resolution, and scaling that texture up then shows the effects of the lowered resolution.
The fix will probably be to eliminate the "bonus resolution" somehow. But I'm not sure if I'll get to it before 6.11 is released.
If so, I can repeat the problem here.
There's a difference between how the screen is rendered normally, and when you're in a dissolve or an imagedissolve. In normal rendering mode, the images are drawn to the screen directly. In dissolve mode, we first draw everything to a texture the size of the virtual screen, and then draw that texture to the physical screen, scaling it up as necessary.
What's happening is that when an image is scaled down, and scaled back up again, there's a little "bonus resolution". The image that's being drawn is sharper than it would have been has the original image been loaded at the lower resolution. When we do the dissolve, rendering to the texture lowers the image's resolution, and scaling that texture up then shows the effects of the lowered resolution.
The fix will probably be to eliminate the "bonus resolution" somehow. But I'm not sure if I'll get to it before 6.11 is released.
Supporting creators since 2004
(When was the last time you backed up your game?)
"Do good work." - Virgil Ivan "Gus" Grissom(When was the last time you backed up your game?)
Software > Drama • https://www.patreon.com/renpytom
-
- Regular
- Posts: 70
- Joined: Sun Jul 15, 2007 2:36 pm
- Projects: EH...
- Contact:
Re: Ren'Py 6.11.0 Pre-Released
Yup, that's exactly the case. I was running in fullscreen mode, and, checking now, I see that I don't get the same effect when running in windowed mode at the normal (100%) size.PyTom wrote:@bberation, are you running the game in a mode that scales it up (such as in fullscreen mode, or when you make the window bigger)?
That would explain it. Here I was surprised at how sharp the sprites still looked even when stretched to that size...I hadn't realized that they actually were sharper than they should have been.PyTom wrote:What's happening is that when an image is scaled down, and scaled back up again, there's a little "bonus resolution". The image that's being drawn is sharper than it would have been has the original image been loaded at the lower resolution. When we do the dissolve, rendering to the texture lowers the image's resolution, and scaling that texture up then shows the effects of the lowered resolution.
Hmm...it almost seems like there's potential there somewhere to make the VNs capable of scaling their resolution to whatever monitor they're being played on...uh, but I imagine that'd end up introducing complications all over the place.
Re: Ren'Py 6.11.0 Pre-Released
When predefined ATL events are used inside an image definition, they seem to never get triggered.
I.e.
doesn't produce the expected alpha changes on show nor on hide, even though that is where such ATL blocks would make the most sense, while
works as expected, but isn't very useful...
Is that how it should be? If it is, it should be documented.
I.e.
Code: Select all
image something:
"somebitmap.png"
on show:
alpha 0.0
linear 1.0 alpha 1.0
on hide:
alpha 1.0
linear 1.0 alpha 0.0
Code: Select all
show someimage:
on show:
alpha 0.0
linear 1.0 alpha 1.0
on hide:
alpha 1.0
linear 1.0 alpha 0.0
Is that how it should be? If it is, it should be documented.
Who is online
Users browsing this forum: Ahrefs [Bot], Semrush [Bot]