Ren'Py 6.12.1 Pre-Released

[PyTom]

Can you put together a small example of the problem, so I can repeat it? It's probably something that differs from the previous one.

[chensterrain]

Hopefully this'll work...

[PyTom]

Is there some particular thing that triggers the bug? I've saved multiple times, without problems. (The last bug was really specific - only to certain parts of imagesmaps - however.)

[chensterrain]

There doesn't seem to be anything that triggers it - the screenshot is black no matter where I save, whether there's an imagemap on screen or not. Maybe it's just my computer? :/

[PyTom]

If you hit shift+U in the launcher, it will update things to 1498. That version has some extra debugging involving taking screenshots - if you can run it, save, and then send me the log.txt file, I'd appreciate it.

[chensterrain]

Hope that helps!

[PyTom]

Hm... Could you try updating your graphics drivers? You have an Intel GPU, so you can look for drivers here:

http://support.intel.com/support/graphics

I suggest hitting "guide me", since I'm not 100% sure which card you have.

[jack_norton]

intel chipset and openGL aren't really best friends
That's one reason why most casual games use DirectX sadly. It's intel fault for making buggy drivers, but tell that to the end users...

[chensterrain]

Sorry for the late reply! I upgraded my drivers (I think I was already on the latest one, actually), but I'm still getting the bug.

Edit: Huh. On further testing, Ren'py's screenshot function doesn't seem to be working at all now? If I take screenshots with the S key, they end up being completely black, too.

Also, I'm really sorry to keep posting here, but I was just wondering whether ATL has changed in 6.12.0+? I was playing through my game again to test the screenshot error and I got the following crash, with code that worked fine before 6.12.0:

Code: Select all

Executing ATL code at C:\Users\xxxx\Documents\Renpy\Projects\Lucky Rabbit Reflex/game/Events_NetballClub.rpy:115
  File "C:\Users\xxxx\Documents\Renpy\Projects\Lucky Rabbit Reflex/game/dayplanner.rpy", line 569, in script call
        call events_run_period from _call_events_run_period_3
  File "C:\Users\xxxx\Documents\Renpy\renpy-6.8.0\Lucky Rabbit Remix/game/event_dispatcher.rpy", line 297, in script call
  File "C:\Users\xxxx\Documents\Renpy\Projects\Lucky Rabbit Reflex/game/Events_NetballClub.rpy", line 751, in script call
        call netballanim
  File "C:\Users\xxxx\Documents\Renpy\Projects\Lucky Rabbit Reflex/game/Events_NetballClub.rpy", line 114, in script
            show netball ball:
TypeError: unsupported operand type(s) for *: 'float' and 'NoneType'

This is the code it seems to have issues with:

Code: Select all

    if netball_win:
        show netball ball:
            linear 1.0 align (0.1, 0.9) knot (0.4, -0.4)
        $ renpy.pause(0.4)
        play sound "SE-success.mp3"
        play music "SE-bigcheer.mp3"
        $ renpy.pause(0.6)
        show netballdys happy
        show netballgirl sad

It crashes at the 'show netball ball' part. I've checked the changelog, but it doesn't seem to say anything about ATL? Sorry if it's just my crappy coding at work again! :B

[PyTom]

Did you have screenshots working on 6.12.0? (That is, is this a new regression, or a problem you've been having?)

[chensterrain]

Yeah, they were working fine in 6.12.0. I think they also worked in the first release of 6.12.1, but I'm not entirely sure about that, sorry!

[PyTom]

That's really useful to know. The big difference is that, after the first 6.12.1 release, I read the screenshot from the front buffer, rather than the back buffer. I'll try to put together a fix today, so stick around.

[PyTom]

If you use shift+U in the launcher, you'll download 6.12.1.1499. That version removes all use of the front buffer - so hopefully, screenshots will work for you.

[chensterrain]

It's working perfectly now, thank you so much!

[PyTom]

intel chipset and openGL aren't really best friends
That's one reason why most casual games use DirectX sadly. It's intel fault for making buggy drivers, but tell that to the end users...

My eventual plan is to switch the windows build over to using DirectX (via the ANGLE layer). But that's one of those things that hasn't been a priority - especially since there hasn't been an official release of ANGLE yet.