5.6 Nearly Done

[PyTom]

I'm a few days away from releasing 5.6.0, with only one major feature left to implement, and then the usual documentation and testing to do. (I'll probably release a test for a new fix to the mp3 bug before I release 5.6.0 final, to determine if I should just deprecate further mp3 support in 5.6.)

I thought I would ask people, especially the new wave of developers, if they have any final suggestions for features they'd like to see added to 5.6.0.

Once 5.6.0 is in the bag, I will be focusing more on tools, demos, and usability for the next couple of releases.

[Jake]

I thought I would ask people, especially the new wave of developers, if they have any final suggestions for features they'd like to see added to 5.6.0.

I think the only thing I can think of offhand is a version of Frame that tiles rather than scales, which isn't really a huge thing... I guess it ought to be possible to add as a user class anyway, really.

[monele]

There was this layer+mask thing, but other than that, I'm good ^^

[mugenjohncel]

I thought I would ask people, especially the new wave of developers, if they have any final suggestions for features they'd like to see added to 5.6.0.

Hmm... Let's see

Ah... I know!

Request No. 1
A way to prevent the user from clicking while an image or text moves... or prevent a user from clicking for a specified amount of time.

Request No. 2
A way to change an image and/or BG while in the middle of a sentence.
(Oh!... I really wanted to see this function in Ren-py)

Request No. 3
A way to tile an image and having it move in any direction we wanted... and control it's speed

What I plan to do on this one is have a tilled background moving from left to right indefinitely and an image of someone running.

Request No. 4 (Well... if possible)
Better Documentation on UI Functions and how to customize it and how to make and use SFONTS like the one used in O3... and Particle Motion.

Request No. 5 (Again... if possible)
Zoom function is cool but somewhat a bit grainy and jittery

OpenGL perhaps...

Well Dirext X might be a solution but Ren-py is a multi platform engine so I guess Direct X is out but... is it possible to somewhat make zoom a bit smoothly (Just a tiny bit will do).

I hope this isn't too much to ask.

[PyTom]

Jake >>> In, as the tile= parameter to Frame.

Monele >>> In, although I limit layers to being rectangular.

mugenjohncel >>>

Request No. 1
A way to prevent the user from clicking while an image or text moves... or prevent a user from clicking for a specified amount of time.

Well, you can always use

$ ui.pausebehavior(1.0)
$ ui.interact()

Antisocial behavior shouldn't be made easy, IMO.

Request No. 2
A way to change an image and/or BG while in the middle of a sentence.
(Oh!... I really wanted to see this function in Ren-py)

This has been around for a while:

"This is a test"

show second image

"This is a test{fast} of how to change images in the middle of a sentence."

Request No. 3
A way to tile an image and having it move in any direction we wanted... and control it's speed

What I plan to do on this one is have a tilled background moving from left to right indefinitely and an image of someone running.

Around for a while. Just tile the image twice (using, say, im.Composite), and then use Move or Pan with repeate=True.

Request No. 4 (Well... if possible)
Better Documentation on UI Functions and how to customize it and how to make and use SFONTS like the one used in O3... and Particle Motion.

The manual is being revised, but it won't be ready for 5.6.0.

Request No. 5 (Again... if possible)
Zoom function is cool but somewhat a bit grainy and jittery

OpenGL perhaps...

OpenGL support is off in the flying-car future.

[monele]

Monele >>> In, although I limit layers to being rectangular.

Eeeexzellent~ . The one thing I'll have fun with in this new version, for sure ^^

Well, you can always use

$ ui.pausebehavior(1.0)
$ ui.interact()

Antisocial behavior shouldn't be made easy, IMO.

Or at least have this skippable with CTRL. The idea is to avoid missing something and have a perfect timing the first time through I suppose (I hope...). So skipping should be ok ?

This has been around for a while:

"This is a test"

show second image

"This is a test{fast} of how to change images in the middle of a sentence."

Not needing this myself but : what if we want to show the image with a dissolve ? The text box would be dissolve too, then reappear, right ? :/

Request No. 5 (Again... if possible)
Zoom function is cool but somewhat a bit grainy and jittery

OpenGL perhaps...

OpenGL support is off in the flying-car future.

There is a way to smooth a zoom, except it's rather slow if you're zooming in (making something bigger).
And ohhh, poor rejected OpenGL ;o;

[PyTom]

Not needing this myself but : what if we want to show the image with a dissolve ? The text box would be dissolve too, then reappear, right ? :/

Well, if you set the new config.implicit_with_none variable to False, then you could write:

Code: Select all

"Foo"
show new picture
"Foo{fast}bar" with dissolve

Actually, this is a fairly good argument for making with_none configurable on a less-then-global basis.

There is a way to smooth a zoom, except it's rather slow if you're zooming in (making something bigger).

Bilinear interpolation is pretty slow regardless of which way you're going. (I actually had it implemented for a while, but it was slow enough that it was commented out.)

Have people tried using the after_child parameter to zoom? It lets you replace the zoomed image with a pre-zoomed image of higher quality, once the zoom is over.

And ohhh, poor rejected OpenGL ;o;

I waver on implementing OpenGl, as I'm fairly certain that it will increase my support burden, and it's not clear that the reward will be enough to make it worthwhile. There's also a question of what level of system to support. If a system doesn't support rectangular textures, then we need to store a 800x600 background using a 1024x1024x4 texture, which takes 4MB right there. For zooms, we need to mipmap, so add another meg or so in right there. (Alternatively, we can do some annoying tiling tricks... but those make my life more complicated.)

Non-hardware-accelerated OpenGL will be significantly slower then the current system, due to differences in rendering models. And I don't know if there's a good way to detect this case.

There's also the issue that I'm not an experienced OpenGL programmer, which means there may be tricks I don't know about.

[mugenjohncel]

Well, you can always use

$ ui.pausebehavior(1.0)
$ ui.interact()

Antisocial behavior shouldn't be made easy, IMO.

Uhh... the real reason why I really wanted to prevent the user from clicking for a specified amount of time is that (again... sorry about my english) I wanted to slide an image from offscreen right to center then replace it with an animated version of that picture huffing and puffing and if a user clicks while the picture is still sliding from offscreen right to center, the character seems to teleport out of nowhere and it definitely looked a little bit... odd.

I really wanted to show that part the way it was meant to be.
(again... sorry about my english)

I tried renpy pause but it still doesn't work the way I anticipated it.


I'll add another request... and once again it involves my favorite renpy function the "zoom".

Right now, the resolution of my current project if set at 800 by 600 and what I really wanted to request this time is for zoom to accept larger images (like 2000 by 1000) while keeping the game resolution at 800 by 600.

So far my attempts were futile.

The reason behind this little request of mine is that I wanted to create a dynamic zooming/panning effect the screen moves from left to right slowly while at the same time zooming out and the reason for the larger image is to produce a far more crisper image since zoomed images were a little bit on the grainy side if blown up on the current resolution (since OpenGL is out... this is the only workaround I could think of right now to compensate for the graininess... Direct X?... Nah!... I guess not).

Please forgive me if I'm asking a bit too much here... the zoom request of mine may be a bit too much for the meantime but I really do wish my little request to prevent the user from clicking for a specified amount of time be granted... I'll promise I'll try to be a good boy this year.

Thank you.

[DaFool]

That's a good question...how do you make animations viewed without being broken by abrupt user input.

Although, I'd just create the entire sequence as a single animated sprite...just hope the user doesn't click too fast to miss the animation, but if s/he doesn't, then the timing will be maintained.

[monele]

Bilinear interpolation is pretty slow regardless of which way you're going.

I made a few tests and it became awful when you, say, stretch a sprite to the size of the screen (800,600). Otherwise, if it's done sparringly, I'm sure it can be used. It's all about testing and choosing wether you want speed or pretties.
Btw, using a final better picture is an idea but, again, it only works with slight changes. Doubling the size of a sprite would lead to pixels being shown during the process and *then* smoothed out in the new picture. Maybe with a very fast animation it wouldn't be a problem, but otherwise it just seems weird. In my case, I chose to stay with pixels all the time when I couldn't use bilinear filtering.

I waver on implementing OpenGl, as I'm fairly certain that it will increase my support burden

I've personally given up on it and am just trying with whatever's left. Seeing the Fate/Stay night demo proved me that quite a few things could be done without OGL and still look *very* good. OpenGL would just help with bilinear filtering and maybe... additive blitting (for lighting effects). Of course, the speed boost for everything else would be nice too. But still, it's possible to work without it.

[PyTom]

Uhh... the real reason why I really wanted to prevent the user from clicking for a specified amount of time is that (again... sorry about my english) I wanted to slide an image from offscreen right to center then replace it with an animated version of that picture huffing and puffing and if a user clicks while the picture is still sliding from offscreen right to center, the character seems to teleport out of nowhere and it definitely looked a little bit... odd.

Well, I'd argue that if the user chooses to click the mouse, he's accepted that the game will immediately skip forward, and is willing to deal with the fact that the game may look odd as a result. Players are not the enemy, trust them to do what gives them the highest amount of enjoyment when playing your game.One of the advantages of the VN format is that the player has control over the pace of the story.

That being said, you can use ui.pausebehavior and ui.interact to achieve a non-breaking pause, if you really want to. I just don't want to make this easy, as it's a really bad idea. In a VN, clicking the mouse should always advance the game, and that's something that should take precedence over the integrity of effects.

Right now, the resolution of my current project if set at 800 by 600 and what I really wanted to request this time is for zoom to accept larger images (like 2000 by 1000) while keeping the game resolution at 800 by 600.

It should be able to do this already. It's just that this won't really improve quality much, as the scale does nearest-neighbor interpolation.

I'm not sure why so many people are so obsessed with Zoom. I can't recall ever seeing it in commercial or doujin games... probably for these reasons.

[monele]

I'm not sure why so many people are so obsessed with Zoom. I can't recall ever seeing it in commercial or doujin games... probably for these reasons.

You should *really* play Fate/Stay night demo ^.^. The one translated by Insani . It uses a lot of ImageDissolves too, but zooms are a big part in most of their effects.

[DaFool]

It's more of zoom-pans that interest me rather than plain zooms.

That being said, I just did a sprite count and totalled around 115. No way I'm going to draw all that stuff. Suffice to say effects are not my priority anymore

[PyTom]

Okay, so I figured out how to make reasonably fast bilinear interpolation code. The downsides to this code: It'll only work with solid images (for speed reasons), and it only properly scales down to 0.5x. (But it's no worse then the previous code after that.)

Non-scientific timings, on my 1.8ghz Sempron 3100+:

Code: Select all

Bilinear
100x75 0.0042s (240 fps)
150x112 0.0064s (157 fps)
200x150 0.0052s (193 fps)
250x187 0.0062s (162 fps)
300x225 0.0068s (148 fps)
350x262 0.0087s (115 fps)
400x300 0.0105s (95 fps)
450x337 0.0118s (85 fps)
500x375 0.0119s (84 fps)
550x412 0.0149s (67 fps)
600x450 0.0170s (59 fps)
650x487 0.0184s (54 fps)
700x525 0.0205s (49 fps)
750x562 0.0226s (44 fps)
800x600 0.0267s (37 fps)

This is tested outside of Ren'Py, so the framerates and timings may be off by quite a bit. For comparison, the framerates for the old Nearest-neighbor zoom:

Code: Select all

Nearest
100x75 0.0043s (233 fps)
150x112 0.0043s (233 fps)
200x150 0.0069s (146 fps)
250x187 0.0048s (208 fps)
300x225 0.0072s (138 fps)
350x262 0.0060s (167 fps)
400x300 0.0082s (122 fps)
450x337 0.0072s (139 fps)
500x375 0.0082s (122 fps)
550x412 0.0101s (99 fps)
600x450 0.0106s (94 fps)
650x487 0.0104s (96 fps)
700x525 0.0131s (76 fps)
750x562 0.0146s (68 fps)
800x600 0.0138s (72 fps)

In both cases, the time scales primarily with the size of the result, rather than the size of the initial image. (But BiZoom will probably be a bit better, as it will properly crop things to the screen if it can.)

Who loves you?

[monele]

Booya! . Away with pixels ! *sends a virtual hug* XD