PyTom wrote:From a game-maker's perspective, the big benefit is I'll hopefully become more responsive to feature requests. The hope is that I'll be able to make pre-releases to a shift+U update, and you'll be able to start using the new features immediately. You'll also be able to expect that prerelease to become a final release within a month or two. This means that Ren'Py updates can benefit games on a timely basis, even for short-to-moderate length games.
Is there any easy way to make the shift-U updates available as context diffs as well? (As that makes it much easier for me to merge a Ren'Py update with my internal customizations.)
Separation of feature updates and bugfix updates would be useful for game-makers, but might be impractical.
PyTom wrote:
Image Attributes. Right now, the code:
Code: Select all
image eileen happy bikini = "ehb.png"
image eileen mad bikini = "emb.png"
show eileen bikini happy
Will give an error. But should that really be the case? It seems like it might make sense to treat everything after the image tag as an "attribute", and then to try to find an image that matches the set of attributes we have defined.
In that case, it may not even be necessary to specify all the attributes when updating an image. If after the code example above, we wrote:
It probably makes sense to show the eileen bikini mad image. There are some details as to how this would work with things like image prediction and backwards compatibility, but those are (probably) resolvable.
Treating 'eileen happy bikini' and 'eileen bikini happy' as the same image is probably a good thing, but automagically resolving incomplete attribute lists will break games in unexpected ways - if you add 'image eileen spacesuit mad = "esm.png"' near the end of development, all of a sudden 'show eileen mad' *might* make her put on a spacesuit on the beach - or, worse, if the attribute resolver relies on helpful hints like what image tags were shown before, result in one path to the same scene leading to her wearing a spacesuit on the beach while the one the developer tests most often doesn't.
PyTom wrote:Once few-to-no people use the software renderer, I'd like to eliminate it entirely, and begin taking advantage of OpenGL/DirectX accelerated rendering. Also, not having to deal with the software renderer, and the bugs in it and its scaling mechanism would make my life easier.
Eek! The software renderer is a major feature for me - there seem to be a fair number of systems out there where the 3D drivers are subtly broken, and I couldn't find any pure open source drivers that supported hardware acceleration on nVidia or ATI cards the last time I looked.
Falling back to software when the hardware renderer isn't working right for whatever reason offers a much better gameplay experience than telling the user to upgrade their drivers (and/or video card) does, IMO.
The software renderer seems reasonably self-contained - how practical would offloading maintenance on someone else be? (As, if you drop software support, I'd likely wind up maintaining my own fork anyhow.)
Juxtaposition wrote:I don't know if this would be possible to do, but what if Renpy offered support for implicit show statements? As it stands now, you have to write a show statement every time a character changes expression. There are things one can do to speed up or automate the process, but it's still a lot of work, especially if your VN happens to be very long.
Hmm. This does seem interesting. Possibly a little too magical, but rather tempting. And it would bring the good bits of automagic image resolution in without the ambiguity.
Code: Select all
label beach_scene:
$ e.image = 'eileen'
$ e.tags = 'bikini'
# Equivalent to 'show eileen bikini happy'
e(happy) "Ah, there's nothing like a warm ocean breeze."
# Equivalent to 'show eileen bikini sand annoyed'
$ e.tags = ('bikini','sand')
e(annoyed) "It would be better if Weather Control hadn't set it to 'sandstorm', though."
Samu-kun wrote:
-A "set default transition for all character sprites" function. Do I really have to write "with dissolve" at the end of all 90000 character show commands in my game?
-An ATL command that combines xpos with xanchor 0.5. In 99% of the cases, xanchor is always going to be 0.5 anyways, so it's a waste of time to have to set xanchor to 0.5 whenever you want to use xpos. e.g. xshow 0.3 automatically sets xpos 0.3 and xanchor 0.5.
You can set a default transition in an image's on show event up in the init block. (Though, IIRC, it will then ALWAYS use that image's on show event when the image is shown.) I think ATL properties other than events inherit, so
Code: Select all
image ornithopter:
'images/ornithopher.png'
xanchor .5
yanchor .5
show image ornithopter:
xpos 400
ypos 310
would wind up centered at 400,310.
And now for my wishlist:
Development headers (and binaries, if applicable) for the 6.12.0 renpy-deps, to make it easier to (cross-)compile add-ons without having to get all the dependencies to build successfully on my machine first. Or an equivalent to 6.11's tegl so I can get into GL from Python.
ATL blocks in hide statements, so
Code: Select all
show virginia normal at discenter
# some stuff
hide virginia:
linear .5 alpha 0.0
works as might be expected - I can get the same effect by specifying an on hide block up in the show statement, but for complicated scenes it can wind up being confusing.
- but the nVidia drivers that ship with Win2K and the (ATI, I think it was?) drivers that Hanako's 10.4 laptop was using (at least as of mid-2010) both showed bugs in 6.11.
you only need to pay the yearly tribute to Mr. Job to have a "new" (LOL) Os with same features as before, less speed and "bugfixes" 