Lemma Soft Forums

Yes, it should be fairly small.

What's more, the user will be able to pick which variant of the language he wants to use. There will be two new statements added to the language:

rpy version <x>

will cause the rest of the file to be parsed using rpy version <x>.

rpy default version <x>

will cause all future files to be parsed using rpy version <x>.


I do have a vague idea that namespace support in Ren'Py might at some point become a good idea. (So that one can easily combine two games that use the same labels, images, and maybe even python functions and variables.) But I think that will strictly be extending the language, without changing existing code.


The current road map is as follows:

6.11 will:
- Add support for optional OpenGL acceleration.
- As necessary to support the previous goal, rewrite some of the special-purpose functions in terms of the transform system.
- Update more of the tutorial.

6.12 will:
- Jump us to Python 2.7 (beta?)
- Jump us to a more modern pygame. (This may move up to 6.11)
- Rewrite the Python handling
- Include the rpy2 language improvements.
- Move Character and certain other classes from the guts of Ren'Py into .rpy files, where people can more easily understand them.
- Finish the tutorial.
- Add a new default theme.

7.0 will:
- Be mostly a marketing release.

I'm also starting to think about how the Python 2 -> Python 3 transition will work, but I don't have concrete plans about that yet. Obviously, existing Python 2 games will need to be supported for gameplay forever. I'll probably also want to support development of Python 2 games for at least a couple of years, until all of the in-development games are released.

(I don't expect the Python 2->3 change to really affect Ren'Py games that much.)

_________________
"It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face in marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming" - Theodore Roosevelt

holy, is that an actual roadmap? that is nice to have indeed.

In other news, I couldn't help noticing that you rather quietly dropped the ramplen parameter from ImageDissolve's documentation. Since it's rather important and I use it a lot I'd like to as what's up with that.

_________________
The rest is left as an exercise for the reader.

ramplen may be ignored when OpenGL is used. It's not clear that I'll be able to support it --- especially on systems that don't have support for fragment shaders.

_________________
"It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face in marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming" - Theodore Roosevelt

An update on the ramplen issue: It now looks like I'll be able to support it, provided the ramplen is a power of two.

That makes the following assumptions about the user's hardware:
* It supports ARB_multitexture, with at least 4 texture units.
* It supports ARB_texture_env_combine
* It supports either ARB_texture_env_crossbar _or_ NV_texture_env_combine4

If these are not supported, then dissolves will be shut off. That includes both ImageDissolve and regular Dissolve.

_________________
"It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face in marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming" - Theodore Roosevelt

One might infer from the above statement that this applies to sprites positioned with Position(). One might also spend half an hour trying to figure out what they did wrong in their code when it proves not to be the case.

One might even conceivably waste another ten minutes scouring documentation until they hit an obscure part of a changelog that explained Position()'s stepmother locked her in the basement and she never got to go to the ATL dance like all the other position-related functions.

But thankfully we are all seasoned vets here and that never happens.

I'm kind of mulling over a 6.10.3 release, maybe next weekend. This would be very limited in scope, probably restricted to:

- Renaming some new methods that could conflict with cardgame and other User-defined displayables.
- Updating/recompiling ffmpeg so that it works with more theora files.

What do people think? Is there anything else that should be taken care of before NaNoRenO?

_________________
"It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face in marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming" - Theodore Roosevelt

I'd like a way to save images like composite to files. Documentation is sketchy on how to pass displayables to native pygame methods like image.save. The paperdoll maker would be an example of where this could be useful. If there's an obvious way of doing this I apologize.

A feature I had suggested time ago but probably was lost among all the others was to add a support for drag&drop, I think could be useful for many projects. Of course, not a priority right now (depending how long would it take).

_________________
follow me on
computer games

Just to clarify, 6.10.3 is intended as a pure bug-fix release, to maximize usefulness and stability for NaNoRenO. So I don't really plan to add features to it.

I'm not sure that being able to save a displayable to a file is a feature I want to support. It would be a totally different code path, especially when we're using GL rendering. Wouldn't a better approach be to just output code that creates the image from data stored in an rpa file?

Drag and Drop can probably be a cookbook recipe, at least for 6.10, and then move into Ren'Py in 6.11.

_________________
"It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face in marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming" - Theodore Roosevelt

PyTom, you suggested I use the Cardgame framework for the educational game I'm working on (the student/player has to rearrange letters with the mouse to spell words correctly).

Two questions: Will Cardgame be patched in the next release, and how would a Drag and Drop feature of Cookbook recipe differ from Cardgame?

Thanks.