What I did Last Week #2 (week ending 1/23/2011)
Posted: Mon Jan 24, 2011 1:54 am
As a suggestion for this thread, let's post it on Late Sunday/Early Monday, and cover the week leading up to the Sunday. This way, everyone posts at about the same time - while the weekend's tasks are done. Of course, it's no big deal to post late - you rebel, you.
As a reminder to everyone, the motto here is Be Specific. We want to know what's going on, not just raw counts.
Ren'Py
Last week was spent finishing up some of the last if the 6.12 TODO list, and getting ready to begin the release campaign. This mostly meant going through the list of minor bugs, both ones reported here in the forum, and ones reported in the bug tracker, and either fixing them, or realizing that they've been fixed already. Right now, there aren't any outstanding reported "little" bugs - bugs that I can fix without a rewrite of _something_.
I put together a new build system, so that I can now type one command (./build_all.py) and have Ren'Py built for Windows, Mac, and Linux. This involves three computers (all on my desk, but still), and a bit of networking. It would have been easier if Windows had a halfway decent ssh server - but that doesn't seem to be the case. (The problem I encountered was that when I log in with a key, Windows doesn't get a password - and so the process doesn't have access to network drives, despite my being logged in on the console.)
I merged renpy-dev with renpy-mainline, so 6.12 is now the "official" Ren'Py. I'm going to try to work in feature branches in the future, rather than having one development branch that's hard to reconcile with mainline.
I added the missing "spacing" property to sides and grids.
I tweaked the order in which the per_interact method on displayables called. This method (which isn't part of a public API) is called to set up displayables to be displayed. For example, this ensures that a DynamicDisplayable is run at least once per interaction, in case the function returns a different result due to the data being changed. Previously, a parent's per_interact was called before the child's - which means that we could have a problem where the parent didn't update itself to reflect the child's change. Now, the method is called in the other order, and so works more sensibly.
Ren'Py now treats filenames as case-insensitive. While it irks me, I think that this will lead to more games runnable on Linux, which is a good thing. Probably the real motivation was that it wound up being nearly as easy to correct the problem as it would have been to report it in lint.
Found out that mugenjohncel hid a message in the flags in the concert image on the demo game. I haven't fixed that yet, so it still irks me, as it's one more thing on my todo list. And now I have to audit the rest of the art he's done for me.
Started off the release campaign. The first step here is to test Ren'Py on the various platforms. Linux worked without major problems, which is a good sign, given that large portions of the graphics code were rewritten. At the same time, it's to be expected, as I'd been using -dev to play games for a few months.
Android had a couple of problems with the more complex game. The first was that the fast implementation of dissolve produced terrible results on complex scenes. The usual method of rendering (glCopyTex2D) was too slow on Android, probably due to format conversion. Using framebuffer objects speeds things up substantially, and I think that using larger textures for RTT should put this one to rest.
The other big android issue was a texture glitch, where one could see older images. It turned out that it was caused by a render-to-texture image (which is RGB) being re-used as a texture loaded from memory (which is RGBA). Fixed it, and the glitch went away.
Misc
Announced the Ren'Py Facebook Page. For better or for worse, social media is where some people are, so it makes sense to engage with it to the extent it doesn't take too much of my time. I've been using ping.fm to post updates to Twitter and the Facebook Page, which means I don't have to do it twice.
As a reminder to everyone, the motto here is Be Specific. We want to know what's going on, not just raw counts.
Ren'Py
Last week was spent finishing up some of the last if the 6.12 TODO list, and getting ready to begin the release campaign. This mostly meant going through the list of minor bugs, both ones reported here in the forum, and ones reported in the bug tracker, and either fixing them, or realizing that they've been fixed already. Right now, there aren't any outstanding reported "little" bugs - bugs that I can fix without a rewrite of _something_.
I put together a new build system, so that I can now type one command (./build_all.py) and have Ren'Py built for Windows, Mac, and Linux. This involves three computers (all on my desk, but still), and a bit of networking. It would have been easier if Windows had a halfway decent ssh server - but that doesn't seem to be the case. (The problem I encountered was that when I log in with a key, Windows doesn't get a password - and so the process doesn't have access to network drives, despite my being logged in on the console.)
I merged renpy-dev with renpy-mainline, so 6.12 is now the "official" Ren'Py. I'm going to try to work in feature branches in the future, rather than having one development branch that's hard to reconcile with mainline.
I added the missing "spacing" property to sides and grids.
I tweaked the order in which the per_interact method on displayables called. This method (which isn't part of a public API) is called to set up displayables to be displayed. For example, this ensures that a DynamicDisplayable is run at least once per interaction, in case the function returns a different result due to the data being changed. Previously, a parent's per_interact was called before the child's - which means that we could have a problem where the parent didn't update itself to reflect the child's change. Now, the method is called in the other order, and so works more sensibly.
Ren'Py now treats filenames as case-insensitive. While it irks me, I think that this will lead to more games runnable on Linux, which is a good thing. Probably the real motivation was that it wound up being nearly as easy to correct the problem as it would have been to report it in lint.
Found out that mugenjohncel hid a message in the flags in the concert image on the demo game. I haven't fixed that yet, so it still irks me, as it's one more thing on my todo list. And now I have to audit the rest of the art he's done for me.
Started off the release campaign. The first step here is to test Ren'Py on the various platforms. Linux worked without major problems, which is a good sign, given that large portions of the graphics code were rewritten. At the same time, it's to be expected, as I'd been using -dev to play games for a few months.
Android had a couple of problems with the more complex game. The first was that the fast implementation of dissolve produced terrible results on complex scenes. The usual method of rendering (glCopyTex2D) was too slow on Android, probably due to format conversion. Using framebuffer objects speeds things up substantially, and I think that using larger textures for RTT should put this one to rest.
The other big android issue was a texture glitch, where one could see older images. It turned out that it was caused by a render-to-texture image (which is RGB) being re-used as a texture loaded from memory (which is RGBA). Fixed it, and the glitch went away.
Misc
Announced the Ren'Py Facebook Page. For better or for worse, social media is where some people are, so it makes sense to engage with it to the extent it doesn't take too much of my time. I've been using ping.fm to post updates to Twitter and the Facebook Page, which means I don't have to do it twice.