Lemma Soft Forums

Starting a thread for work on the 6.11 series. Here's the current roadmap:

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.)

PyTom wrote:Starting a thread for work on the 6.11 series. Here's the current roadmap:

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.)

Whoo-hoo!!!!

PyTom wrote: 6.11 will:
- Add support for optional OpenGL acceleration.

6.12 will:
- Jump us to Python 2.7 (beta?)
- Jump us to a more modern pygame. (This may move up to 6.11)
- Include the rpy2 language improvements.

7.0 will:
- Be mostly a marketing release.

Out of interest, why not make the big code changes at the same time as the big version number changes, since people generally expect all minor versions of the same major version of a bit of software to work the same? "OpenGL is only available in Ren'Py 7 or greater" or "the new language features only exist after version 7" makes more sense and is more memorable to most people than "after v6.12" or whatever.

If you want to get those features out and usable as soon as possible rather than waiting until 7 is ready, you could always just note that some pre-releases of 7 are more stable than most...

PyTom wrote:Starting a thread for work on the 6.11 series. Here's the current roadmap:

6.11 will:
- Add support for optional OpenGL acceleration.

Oh, hell yes!

When you add OpenGL, the pygame will still be available? I think I remember you posting something about incompatibility of normal pygame when you'll add openGL.
(not that I use pygame now, but anyway...)

Wish list time
Thank you for all your hardwork Pytom...

- Ability to dictate individual hover sounds for individual imagemap hotspots.

- Add an image map based delete save screen ...and a delete save integrated in the navigation bar.

- A way to dictate a default volume for music, sfx and voice kinda like the text speed.

- A simple game featuring DSE with graphics utilizing a full imagemap based GUI to be included with the Renpy distribution... yes imagemaps!

- For the demo game to have drawn BG's to compliment the current Eileen sprite.

"POOF" (Disappears)

PyTom wrote:Starting a thread for work on the 6.11 series. Here's the current roadmap:

6.11 will:
- Add support for optional OpenGL acceleration.

Forgive my ignorance in regards to graphics APIs, but...

That OpenGL support you have planned - that wouldn't happen to encompass the OpenGL ES subset, would it?

Hm... I'm certainly keeping OGL ES in mind, but I'm not sure it will be able to do everything I need it to. So we'll see.

The big problem is imagedissolve. I'm not sure I'll be able to pull off a proper imagedissolve on, for example, the iphone hardware. We'll see.

Update: I just looked up how many texture units the iPhone has: 2. There's no way we can do an imagedissolve with 2 texture units. So we'll just have to do without platforms that don't have at least 3 texture units and OES_texture_env_crossbar.

By "do without", I mean to degrade to a standard, non-image dissolve.

PyTom wrote:Hm... I'm certainly keeping OGL ES in mind, but I'm not sure it will be able to do everything I need it to. So we'll see.

The big problem is imagedissolve. I'm not sure I'll be able to pull off a proper imagedissolve on, for example, the iphone hardware. We'll see.

Update: I just looked up how many texture units the iPhone has: 2. There's no way we can do an imagedissolve with 2 texture units. So we'll just have to do without platforms that don't have at least 3 texture units and OES_texture_env_crossbar.

By "do without", I mean to degrade to a standard, non-image dissolve.

Hmm. I don't recall exactly, but I _think_ the iPhone 3Gs and the latest generation of the Touch have eight texture units. I believe they have full compatability with the 2.0 spec of OpenGL ES.

Ah. Yeah - here we go:

http://www.mobileorchard.com/a-huge-lea ... phone-3gs/

Texture units. The iPhone 3G had two texture units, so you were limited to fairly basic effects: diffuse texture plus a detail or a lightmap. Anything else required multiple passes, rendering the same geometry twice and slowing things down significantly. The new and improved hardware offers 8 texture units, so the sky is the limit as far as the kind of effects we can dream up.

Give me OpenGL and I will show you magic and lotsa special effects. Can you say a lot of particles?

It's all going to be Vsynced right?

PyTom wrote:By "do without", I mean to degrade to a standard, non-image dissolve.

Speaking as someone who will probably get most of his money from the iPhone Apps store, thank you.

It should be Vsynced, yes.

While an iPhone version would be nice, it's not a priority right now. For one thing, I'm not sure if Apple would accept a Python application. (I suspect they would not, unless I link everything statically and so on.) There are also licensing issues with SDL that we'd have to work out.

In general, I'm not in a huge rush to support non-computer platforms.

Tsundere Lightning wrote: Speaking as someone who will probably get most of his money from the iPhone Apps store, thank you.

sorry about the OT- I still make more in 1 day of Pc/Mac sales of a 5 years old game (non - VN) than 4 months of iPhone with a brand new game ported for it. If for you that's lot of money... don't be brainwashed by all the (fake?) posts in those blogs claiming everyone making a tetris for iphone will earn $5M dollars.

PyTom wrote:While an iPhone version would be nice, it's not a priority right now. For one thing, I'm not sure if Apple would accept a Python application. (I suspect they would not, unless I link everything statically and so on.) There are also licensing issues with SDL that we'd have to work out.

Yeah, I was curious about that.

Well, technical details aside, my enthusiasm for the App Store has cooled since its inception. Apple's fickle, nonsensical approval process being one of the major issues in my mind. There's no way I'm going to spend months developing something SOLELY for the App Store if Apple can't provide me with any insight or guidance on my specific project. Not until it's done, anyway.

predictable LSF dogpiling on iphone platform

Let's put it in a more objective perspective.

• The iPhone 3.0 SDK EULA expressly forbids using it to produce code interpreters. Even Saurik doesn't see room for interpretation on this. Ren'Py would have to compile down to native iPhone code, a strategy quietly adopted by multiple development platforms.
• Python on the (jailbroken) iPhone is currently a stunt with very little to show for itself right now. Ditto Java.
• Excepting the 3GS, the iPhone platform runs inside 128Mb RAM on a medium-grade ARM. An HTML5 Canvas sprite animation demo (i.e. not optimized for GL) shows the limitations of the CPU and possibly intensive memory swapping. Smooth video playback is the result of H.264 decoding in hardware, not the inherent speed or memory of the platform.
• As Tom pointed out, SDL is freely licensed for all platforms -- except iPhone, which currently requires a commercial license.
• iPhoneOS does not by default support custom fonts, unless you add a bit of code someone else wrote which still requires you to know the canonical internal name for that font (as opposed to the filename).
• Unless software-based decoders for OGG turn out to be comparable to the hardware decoders for MPEG/MP3/AAC, video and audio assets will have to be transcoded to patent-encumbered formats. Apple is unlikely to approve an app that supports OGG.

The iPhone platform itself is perfectly capable of hosting games like the ones made with Ren'Py. We've already seen an abandoned VN made by an LSF poster that proves this. But those apps work precisely because they play to the platform's own strengths instead of importing everyone else's all-purpose frameworks and libraries.