Request a Ren'Py wiki documention

[Jo'ogn]

Some want more documentation, some are willing to provide it - if there's a specific request. Some features of Ren'Py are literally "hidden" as they are not mentioned anywhere, or perhaps deep somewhere in a board topic.
The idea is, that documentation requested here will be added in the Ren'Py wiki.

~

I would ask for a more extensive explanation of the "show" statement as it can take a lot of parameters.

Occasionally PyTom mentions performance relevant information. How to deal e.g. with images to be either RAM efficent, or CPU performant.

[delta]

This is an interesting problem. Basically, what's written on http://renpy.org/wiki/renpy/doc/referen ... _Statement is all there is to a show statement (I would add that it's just a wrapper for the python function renpy.show() though). I believe what you are looking for is what an image_spec can do, which is higher up on that page (and ironically not as easily linkable), since it applies to show, scene and hide. Maybe this should be arranged more logically, but it means rewriting the single most important page in the whole manual completely, so I'm not doing it just like that,

As for performance, if you're not doing anything outside the Ren'Py script environment, there's not much you can do wrong outside making images unnecessarily large or using more images than you actually need (for example, moving them offscreen and forgetting to remove/hide them).

[Aenakume]

As for performance, if you're not doing anything outside the Ren'Py script environment, there's not much you can do wrong outside making images unnecessarily large or using more images than you actually need (for example, moving them offscreen and forgetting to remove/hide them).

That's not necessarily true... there are a lot of ways you can waste resources unnecessarily. There is another thread here today that mentions im.Rotozoom and FactorZoom. While they don't technically do the same thing, they do overlap in functionality, and using the wrong one can make a fairly huge difference in some cases.

This is certainly something that can use a page or two in the wiki. There are lots of ways you can plan ahead to make your game more efficient... versus things you can do to make it slow.

[delta]

I thought this was only referring to the show statement, but yeah, once you get into effects it becomes a whole new thing. But since this basically boils down to "don't use effects you don't need", it would be sufficient to note how performant the effects are in comparison to each other.

[Jo'ogn]

Thank you ^_^

There could be a page e.g. under "Reference" called "Performance" giving advice in general. How to keep memory and CPU usage moderate. In order that anyone reading either page can find the info, either collect all perfomance info on the Performance page and link from the functions to this page. Or link from the "Performance" page to the functions and have the info there.

~

There was recently a discussion of how to scale a game to different screen sizes, esp if there are different aspect ratios 4:3, 16:9, 16:10? Is it worth the hassle? Do I need to care? Esp if many creators can barely finish their hobby VN.

~

Why Ren'Py?
Ren'Py is a free and cross-platform engine that helps you make story-based games. These include:

* Visual Novels, computer-based stories presented using words, pictures, sounds and music. Ren'Py's script language makes writing visual novels easy and efficient, allowing visual novels to be made without needing a dedicated programmer.

* Simulation Games, such as dating and management sims, can be written using Ren'Py's support for embedded Python. Ren'Py takes care of details like persistence and efficient rendering, letting the programmer focus on the game's user interface and logic. The same Ren'Py script language that makes writing visual novels easy makes it easy to include story segments inside your simulation game.

The Ren'Py adept should keep in mind: Only on the simplest level of Ren'py it is really easy, because it is fully documented in "three and a half" different ways: "quick start", "web tutorial", "simple" and the reference.

There is this recent discussion about "How good are Ren'Py games?" Which makes one wonder if at the most basic level the games are considered "not good enough". Even though the critics address more the images ("art work") or dialogues than the actual programming behind it. But eventually a creator wants to go beyond the basics and this is where the doc needs extension, to offer Ren'Py's intention: easy and efficent.

~

@delta - What's "image_spec"?

Only the very basic usage of "show" is documented. Apart from a simple "at left" it does not tell what else can be done with "at" in combination with "with". Unless I happen to look e.g. at Factorzoom, where I find an example that gives an idea what else can be done. But there are already two parameters given to "at"...

It might not be intuitive for beginners to understand that such things are possible at all. I do not see it in the statement's explanation, therefore it doesn't exist. I (as a programmer with not much OOP experience) wouldn't even guess, that it's possible to combine statements with functions. Because in my mind a programming language is usually limited and has a clearly defined syntax.

The "hidden" OOP capabilities of Python in Ren'Py leave me at a loss: I can write things some "funny" way, because this method belongs to some funny class and therefore inherits this to that and suddenly Tada!!! It literally "conjures" some (to me) not expected results o_0;;

Of course "we" can not cover OOP and Python as well, but perhaps the basics could be wrapped up somewhere, at least where they become relevant?

~

im.Rotozoom and FactorZoom. While they don't technically do the same thing, they do overlap in functionality, and using the wrong one can make a fairly huge difference in some cases.

I had a feeling about this, but didn't ask ^_^

[delta]

@delta - What's "image_spec"?

I'd show you what I mean but it has already been changed.

[Jo'ogn]

Could anyone please add an example for ui.imagebutton?

[monele]

Done.

[Jo'ogn]

Thank you.

Is it possible that the example in renpy.curry isn't correct?
The defined function is never called o_0

maybe: add = renpy.curry(real_add)?

[PyTom]

Yeah, that's a bug in the documentation.

[luminarious]

Pardon me if I'm misplacing my thought, but I just looked throught the documentation and found myself wishing Ren'py´s was more like PHP documentation.. You know, http://www.php.net/manual/en/

That's a pretty sensible organization, with installation, configuration and language reference for each variable and function and all in specific subcategories and so on. Almost everything not only explains what the thing does, but gives an example or two. Also, what I have found extremely useful is the comments readers have added concerning alternative uses of a function and additional examples and whatnot.

Then again, maybe I'm just too tired to make sense of the wiki right now. I'll check again tomorrow..

[PyTom]

Fundamentally, I wouldn't be opposed to a reorganization of the reference manual. But I'm still doing Ren'Py mostly as a hobby, and documentation is always the least entertaining part of things, and I've never been all that great at it in the first place... so unless someone steps up, there probably won't be a major reorganization of the Reference Manual in the near future.

[Jo'ogn]

Maybe we can do sth similar to the php user comments in that users may add a paragraph under the examples of their take/use/understanding on a function with the wiki singature element "--~~~~". Eventually someone in the know might have to weed out errornous 'comments'.


e.g. I went through the "call_in_new_context" functions last night, they only vaguely mention what a new context for an interaction within an interaction might be good for. Some functions bear more information than similiar ones, like the three different kind of ui.buttons...

Personally - even if short - an explanation of reasonable usage is often enough for me to understand functions.

[Megaman Z]

Maybe we can do sth similar to the php user comments in that users may add a paragraph under the examples of their take/use/understanding on a function with the wiki singature element "--~~~~". Eventually someone in the know might have to weed out errornous 'comments'.

I agree with this idea to a degree - people that understand how a function works and how (and possibly more importantly, WHEN) a function should be used should probably add more examples showing such. *points at the DynamicCharacter entry on the wiki which [last he saw it] has two examples - one simple, one slightly more involved*

e.g. I went through the "call_in_new_context" functions last night, they only vaguely mention what a new context for an interaction within an interaction might be good for. Some functions bear more information than similiar ones, like the three different kind of ui.buttons...

this has personally been the one thing that irks me about un- or misdocumented things. while one can't expect the dev(s) of a continuously evolving program to do full documentation, we should at least have a couple people with a reasonable amount of knowledge be able to maintain the documentation (or, in this case, the wiki). otherwise, the people writing the scripts will suffer their equivalent of Guide-Dang-It.

Personally - even if short - an explanation of reasonable usage is often enough for me to understand functions.

Works just fine for me. heck, sometimes, even subtle hints is enough. of course, I did end up figuring out the hard way where to recolor the dialougue windows (although it worked on my first try. ^-^)