The Road to 6.13

[PyTom]

I thought I would write up where I'm at on the road to the next major Ren'Py release. I had been considering calling this 6.12.2, but decided to give the bugfix release that name and make this 6.13, following the new versioning scheme. Everything intended for 6.12.2 is now going into 6.13.

There are two big changes:

Newtext is the rewrite of the way Ren'Py handles the display of code. This code had been some of the ugliest in Ren'Py, and could get slow when a lot of text was being shown. Now, it's much cleaner and faster, and has new features like kerning and ruby support.

Newtext is done save for some minor bugs exposed through gameplay. (I also need to do more testing against complex games made by other people.)

On Windows, Ren'Py will now default to using DirectX via Angle. This required major restructuring to the OpenGL implementation to make it conform to the subset that OpenGL and OpenGL ES 2 have in common, but the end result is worth it. The DirectX implementation is much faster and more complete than the OpenGL one on at least one common card, the Intel GMA 945 used by many netbooks.

The Angle port is done, with the exception of the performance test that Ren'Py does when it starts. I'm going to rewrite that test so that Ren'Py always sticks with the renderer it starts up with - be it angle, directx, or software. If Ren'Py determines that a user's system is slow or misconfigured, it will direct them to a page with information about improving its performance.

There are also several other changes that will be less big:

The code for screen-based Music Rooms is done. I'm also going to add support for screen-based Image Galleries, based on the current newgallery code.

I'd like to add basic translation support to Ren'Py. For 6.13, this will be really simple, just text-replacement. 6.14 will add tool support, and more complex transformations.

Beyond that, there are some bug fixes, minor features, and documentation work that people have been asking for, so expect some of that too.

[Fawn]

Thank you so much for your continuing labor of love The new features sound great!

[OdysseyStudio]

Awesome, Can't wait to try this out.

[PyTom]

Here's a screenshot of the new _performance_warning screen. This screenshot will come up in two cases:

- The computer can't render a dissolve from black to black at a rate of 15fps or faster.
- The computer couldn't load the Angle/DirectX or GL renderer, and automatically fell back to software.

This should only happen if DirectX is missing or out of date* and OpenGL is either broken or too slow for practical use.

This screen is translatable and customizable in the usual fashion. By default, the link takes the user to a page on the Ren'Py site that will explain how to upgrade their graphics drivers when necessary.

This screen will be the first thing that a user could see when they start up Ren'Py - or your Ren'Py game - on a computer with a broken graphics system, one that would today transparently fall back to software rendering.** So I'd like feedback from creators as to the wording of this message, and how to improve it.

* We require the February 2010 DirectX update either be installed on the system, or bundled in with Ren'Py. For size reasons, I don't plan to distribute this update with Ren'Py. This is the requirement that Chrome has in order to enable WebGL support - the original purpose of the Angle library.

** Now that we have DirectX, I'm hoping to get rid of software rendering as a primary mode of operation - so that in a few releases, I can begin to take advantage of accelerated-only features.

[Aleema]

I very much appreciate the Performance Warning and think it is an excellent way to handle compatibility issues.

I suggest not being very concrete in telling the user that their computer is not working. It may just freak them out. A more subtle "your graphic drivers may not be ..." would be less alarming. Also, is "operating correctly" the appropriate blanket phrase here? It appears for a system with missing drivers, but also for an out of date system (which isn't "not correct," just old). Either way, since it appears for out of date systems as well, that's my only concern. A simple "may not be operating correctly or out of date" would fix this.

[Nebi]

What about:

Oh Noes!
Your video card might have trouble displaying some of the graphics, nya.
This game may not perform well on your computer, nya.
Learn how to troubleshoot this problem, nya.
Continue, nya.
Quit, nya.

OR

Warning! Your computer is obsolete.
This game may not display correctly.
You may need to update your video card.
Click here to troubleshoot this problem.

OR

[Graphics Test]
Your graphics card works perfectly.

[Graphics Test]
Your graphics card is poorly suited for this game.
[Test Again]
Your graphics card is performing below normal standards.
[Test Again]
You may want to consider buying a new computer.
[Test Again]
It doesn't get any better than this!

[jack_norton]

Thanks for your effort to always improve Ren'Py. I believe after the DX addition you can safely unsupport the software rendering mode and start doing even more cool effects using shaders/3d.

I'd like to add basic translation support to Ren'Py. For 6.13, this will be really simple, just text-replacement. 6.14 will add tool support, and more complex transformations.

What you mean by "tool support" ?

[PyTom]

I very much appreciate the Performance Warning and think it is an excellent way to handle compatibility issues.

I suggest not being very concrete in telling the user that their computer is not working. It may just freak them out. A more subtle "your graphic drivers may not be ..." would be less alarming. Also, is "operating correctly" the appropriate blanket phrase here? It appears for a system with missing drivers, but also for an out of date system (which isn't "not correct," just old). Either way, since it appears for out of date systems as well, that's my only concern. A simple "may not be operating correctly or out of date" would fix this.

I now have it as:

This computer is displaying graphics slowly.

Its graphics drivers may be out of date or not operating correctly. This may lead to slow or incorrect graphics display. Learn how to fix graphics problems.

Along with your changes, I also made the second line about the computer, rather than about the person - since people don't like having their faults being pointed out to them.

By the time a user sees this message, Ren'Py has already determined that the drivers are broken - if you can't render at a below-reasonable fps with DirectX -or- OpenGL, your system certainly has problems. But I agree that there's no reason to scare the user so "may be" it is.

What you mean by "tool support" ?

In 6.13, there will be support for reading translations out of a file. In 6.14, there will be a tool (part of the redesigned launcher) that will make it possible to generate these files automatically.

[Alex]

In 6.13, there will be support for reading translations out of a file.

Great, waiting impatiently...

And about translating main and game menus - while use default menus, it was necessary to reload a game when language changed, but for now (using screens) - is this behaviour steel the same?
http://www.renpy.org/wiki/renpy/doc/coo ... ge_Chooser

[PyTom]

Today was a fairly technical day of Ren'Py hacking.

Now that DirectX is in, the software renderer is a deprecated path - mostly to be used for telling the user about how to upgrade his system. One of the most complicated and error-prone bits of code in Ren'Py was the support for scaling software-rendered images. So I went ahead and replaced the complex code with a simple path, one that takes the screen and scales it down at the end of each frame. While this is a bit slower, it tends to avoid the artifacts that software scaling could cause.

Similarly, I've cleaned up the pixel format use of Ren'Py. Now, the only non-RGBA portion of Ren'Py is the software renderer. This makes all other graphics code simper and faster, as the alpha byte is now always in the same place.

Okay, these aren't the most exciting changes in the world - ideally, creators and players won't notice these. But it will let me remove about a thousand lines of code from Ren'Py, and in general will make it easier for me to change in the future - both of which are nice things.

[PyTom]

And about translating main and game menus - while use default menus, it was necessary to reload a game when language changed, but for now (using screens) - is this behaviour steel the same?
http://www.renpy.org/wiki/renpy/doc/coo ... ge_Chooser

I don't know yet - I'm going to try to abuse rollback to make a language change possible without needing to reload the game.

[PyTom]

As the culmination of a really good weekend, I implemented style preferences according to the spec I set out in June.

If you'd like to get started with style preferences today, grab the file from the download link at:

http://bazaar.launchpad.net/~renpytom/r ... rences.rpy

and stick it into the common directory of Ren'Py. It's standalone enough that it should be able to work with 6.12.2 without problems.

[PyTom]

Last night, I added a feature someone requested here on the forum - the ability to specify the left, top, right, and bottom borders of a Frame independently.

[PyTom]

Implemented a few more features today.

First, I added the new caret style propert, which lets you specify the caret of an input. (That is, the vertical line at the end of the text.) It can be set to any displayable.

Implemented several new actions. SelectedIf lets you determine if a button should be rendered as selected, SetMixer sets a mixer's volume to a specific value. The Rollback and RollForward actions let you bind these functions to buttons, imagebuttons, etc.

Finally, threw together the translation framework. It takes files of the format:

Code: Select all

# Comment

< Start Game
> Artstay Amegay

< Load Game
> Odlay Amegay

And applies that to all text - dialogue, menu items, character names, text in screens, etc.

There's also a Language action, that changes the language. This takes affect as soon as it's clicked - no need to start a new game, reload the game, or even click through to another statement.

I'm not going to add tool support for creating and updating these files until the next release, however, as it will require some of the new features scheduled for 6.14. So for now, you'll have create the translation files by hand. Sorry!

[PyTom]

To bring people up to speed on the last few days of Ren'Py development:

I added an image gallery to Ren'Py proper. The image gallery I added is based on new_gallery.rpy, but it's been updated so it supports screens and transforms. (It also has been stripped down a bit - now, Ren'Py expects you to use screens to define an image gallery, so the hard-coded look has been removed.) The image gallery code provides an action that shows images when buttons are clicked (that handles locking and unlocking), and also includes code to create buttons with borders that show if they're locked or not.

Probably the biggest change was the addition of a new "quick menu" to the screens.rpy file that's used for new games. Here's a screenshot:

screenshot0001.jpg (27.58 KiB) Viewed 2321 times

It's in the lower-right of dialogue screens. The buttons are fairly subtle by default, so as not to detract from the game, but become more visible when hovered, and change to a yellow color to indicate selection. (All of this is configurable, of course.)

I integrated 5 new themes contributed by Aleema, along with several new color schemes by her as well.

I added a time_warp parameter to Dissolve and ImageDissolve in response to a request by Cradle Song, and fixed a bunch of bugs.

With the exception of a new feature for Android I may or may not add, the only things remaining on my 6.13 TODO list are various release engineering tasks. So I'll begin the release campaign tomorrow.