Then I decided, I don’t care. I’m sure there is something missing, but I won’t be sure until one of you lucky individuals finds it. So here’s your chance to make PyWright better! Download 0.975 today, kick it and poke it until it breaks, then let me know about it! If there is anything either A) serious or B) easy, I’ll probably work it in to another release pretty quick.

The update is in the usual places, download service, or downloads page; and all of the binaries for platforms have been updated as well. The Pezman complained at how infrequently I update the binaries, and he was totally right. I plan on updating the binaries every time. It’s a pain, but oh well.

Full changelog in the update, here’s a quick rundown:

• List of saves to load
• More save control for game devs and users
• “Sticky” cross examination arrows
• Object priorities revamped to allow timers while interfaces are open
• The ability to include file extensions or leave them off almost everywhere rather than having some commands need them and some commands need them to be left off
• More support for spaces in games

And here’s my plan of features for the version after next (the next one being reserved for bug fixes)

• Tools included with pywright to aid casemakers
• Add hotkey to gui Buttons
• Buttons that repeat if you hold them down
• User controls config
• More control over file layout (being able to use fg on files in art/bg for instance)

Most likely some of that will be pushed into the next next next version, but who knows. Let me know what you guys think.

(The full binaries are not yet updated, so if you don’t have PyWright yet, you’ll have to grab 0.973 first)

The changelog has a detailed list of the fixes, but here are the most important:

• Preliminary gamepad support
• Easier window scaling
• Autosaves, multiple save files
• Expressions to aid coding and eventually help in the AAO converter
• Some protection against easy to make coding mistakes
• More fixes to the downloader

For the future I am thinking of adding more flexible input support and maybe tackling the settings dialog again. That’s the kind of stuff a 1.0 release needs. Other than that, I’ve been working on various tools like the gif2sheet program, something to help find overhanging words on speech bubbles, and the aao converter of course. I’m trying to figure out the best way to bundle this stuff so that others can use them. I have some ideas but haven’t really tackled it as of yet.

My goal is to finish 1.0 this summer. Here’s hoping I make it

This idea of branching out in the game world, and seeing where things can go, has led me to look for another popular series of DS games to start with. I think I have found the perfect series. This series is so different from Phoenix Wright, that it will be a great test for the engine. There is no courtroom, no court record, no focus on textboxes, none of the things that make the “ace law” games what they are. And there are quite a lot of these games too, and I’m sure many fans (although I don’t know any).

A limited beta release of 1.0 has been making the rounds, and received great feedback! “I’ve never seen anything like it before”, said one beta tester. “It was so, I mean, wow. It made my eyes bleed,” said another. Some random guy on the court records forum who managed to beg the beta from me informed me that “I didn’t try it for very long, I am done with it.” I think he means it is really fast to get things done with it! It’s quite simply unique in the case maker world.

Screenshot is below, and once the beta testing period has ensured that there are no last minute bugs which will need updates and patch nonsense (ha ha ha), you will all get to try out this grand new vision for my engine. Enter PyMagine:

It will let you create games based on the “imagine” series of games for the Nintendo Ds!

I hope you will enjoy the new changes!

Anyway, the feature that kind of floored me today, is one of the last features I have to implement in order to convert games from AAO to PyWright with 99% accuracy. (I say 99%, as that last 1% of compatibility may or may not be there – it’s hard to know without testing every single AAO game in existence) This feature is expressions. Expressions in AAO allow a developer to have almost a mini scripting engine, interacting with variables and doing math on them. You can increment variables with “set x = x + 1″, you can do booleans with & and |, and you can do very complex math such as the “%” operator. It also follows the general order of operations like most programming languages with expressions engines do. Not what I expected from an easy-to-use, true casemaker.

PyWright has no expression engine.This doesn’t prevent developers from doing mathematics or accomplishing the same goals that you would use an expression for in AAO. Sometimes it will take several operations in PyWright instead of just one. For example:

x = (x + 1) * 12

could be translated as

addvar x 1
mulvar x 12

It takes more steps, but this kind of math is generally not that useful in this style of game. It is important for creating custom code, making animation work in a different way, or showing some specified interface. But when I am writing this stuff I don’t miss expressions that much.

However, to convert from AAO, it can’t be avoided. So the thing to decide, is how to automatically do the above conversion. I also have to choose whether to integrate the expression solver into PyWright itself, or do the translation in the converter. Most likely it will go in the converter, however I don’t think it’s crazy to think that expressions will be a standard language feature at some point. The reason I avoided it was out of simplicity, but even the most “simple” casemaker seems to have it!

Anyway, this is not a trivial task, so it is going to delay AAO -> PyWright a bit more.

The binaries on the download page have been updated to 0.960, or you can update by going to the download section from PyWright’s main screen. If you update from the engine, don’t forget to close and restart the engine after the update.

Note: If you have a version of PyWright prior to 0.95, you may have been confused when I said 0.95 was out, as your engine didn’t automatically update to it. I might not have made this clear, but 0.95 uses new binaries, so the only way to update is to download the full package again. If you haven’t updated PyWright yet, and are still using beta 10.94, head there and grab the shiny new 0.960.

Some other changes in 0.960 are related to the Ace Attorney Online converter. For those paying attention, I put a version of DramaticaXIV2’s hilarious AAO case, Ace Attorney Online: The Game, on PyWright’s game download section. It’s still very buggy, but mostly works. Download it and play around, if you dare.

I already have a load of new fixes for 0.970 planned, most of which are related to the scary 0.95 in which I allowed feature creep to roll me over. I added so many things I was bound to leave bugs and irritations in my wake! There are also some things which AAO games need, such as the password control, in order to be more accurately converted, so that kind of stuff will be there as well.

Finally, I am working on the test game which was supposed to come out closer to 0.95’s release, but isn’t out yet. It will have some examples of how to emulate AAI in PyWright, as well as demonstrate how to use all of the new features. Note that, emulating AAI is not going to be that close to the real game at this time. Version 2.0 may be able to handle it better, but for now it’s just an emulation. If you want true AAI support, pwlib is probably going to be a better choice, if version 1.2 of that ever comes out.

Yep so that’s my progress in a nutshell. 2.0 is still on the shelf, looking at me forlornly with it’s extreme features, but I am not ready to tame the beast. I hope that somewhere I will find a good way to transition smoothly into that.

Things like label none conflicts, menus forcing you to split your scripts a certain way, and there being no way to load a script at any other line then the first, forced game coders to do things in a certain clunky way. Many of those kinds of limitations are now gone.

There were still a few areas where PyWright could not easily be customized. There were hacky ways to do things, and it was MUCH more flexible than some people gave it credit for, but it still had a long way to go. In fact it still does. However, being able to put graphics on your buttons, and some more variables to customize other core components, makes this the most customizable version ever.

So to sum up, I’m really happy with how this version came out. When I started working on 0.95 (which was then called beta10.95), I didn’t expect to get into it as much as I did. But with all of the great feedback from users, the help I’ve gotten with various things, testers finding new ways to break it, and some epiphanies on how to fix long-standing issues; it has culminated into something I’m actually proud of.

It’s a long way from 2.0, but I am happy to finish 1.0 before going there. One step at a time.

Downloads here, as usual. I hope you enjoy it. If something breaks, that is good too, because there is so much more to be done.

Don’t forget to read the changelog, especially the part about regressions. While there is mostly just a bunch of new features, some things have changed that may or may not be detrimental to your project. beta 10.94 won’t force upgrade to 0.95, so you are safe to stick with the old version if you must.
And with that, I’m going to have a nap!

Yeah, releasing is HARD.

Until all of the files are uploaded things will be kind of broken. Downloads on the download page will not work.

0.95 will NOT download automatically by running PyWright, the full packages for your system will need to be fetched again.

I am not too upset that I didn’t make February, considering it’s a day difference.

I can’t wait for you guys to see what I’ve been working on!

In a typical music player, it is always only playing one music/sound at a time. Because of this, it can shape the music player to fit the rate of whatever is loaded. Music can have different sample rates, which is similar to a framerate. It says how many samples per second are stored in the file. When your music player loads a file, it adjust it’s playing rate based on what rate the file says.

Now, with a game engine, it’s not so simple. You have many sound effects and different music playing at different times. Because of the way the hardware works, you can only run things at one speed at a time. If you try to play music stored at one rate, and a sound effect stored at another rate, you either have to stop the music to change the settings and play the sound; or resample each file to the settings of the hardware. Resampling means analyzing the sound file and either cutting out frames to make it a slower rate, or adding frames to make it a higher rate.

Some kinds of resampling are very easy. To double the rate, you just have to read two frames at a time; while to half the rate, you can skip a frame. If you are not doubling or halving the frame rate of the sound though, you have to do deeper analysis of the frames.

The libraries PyWright depends on, namely SDL_Mixer, can do the cheap resampling for free. It doesn’t know anything about more advanced resampling however.

When you check the PyWright sound settings, there are a couple different sample formats to choose. These are all compatible with each other because they are either half or double the frame rate of the next one. If the sample rate of 22050 is chosen, and you try to play a sound that has a sample size of 11025, it will convert that sound into a rate of 22050 in real time, and sound the same as it is supposed to. If you play a sound that is set to 44100 Hz, it will convert it down, and play at the right speed.

Where things get interesting, is if you try to play music that is set at a Hz that can’t be double or halved from the system rate. Most common is 48000. 48000 hz doesn’t half or double to any of the values the system is set to by PyWright. So what happens, is it just pretends that the framerate of that 48000 file is 44100 (if 44100 is your setting). If you change the settings down to 11025, I’m not positive, but I think it does a simple resample down to 12000 (48000/2/2), and then treats it like it is 11025.

How to solve this? If there were an option for it, you could actually set the sound player to have a framerate of 48000, just like the music file you are trying to play. There is just one problem – all of the standard PyWright sounds have a framerate of 44100 or 22050. If you change the settings to match the music, all of the sounds will now sound like they are on helium!

One way to solve this in code, would be to have a smart resampler that resamples the music if it sees that the rate doesn’t fit. This would add two things that I don’t like: much longer loading time for music files as it reads the entire file to convert it; and also making the PyWright installation bigger and harder to package. So I am not going to do this

SOLUTION

Resample your files to either 22050 or 44100. Yes, not only do you have to make sure to use .ogg and not .mp3, you also have to be aware of the sample rate. Such is game development! Of course the other solution is to just let the music play that 20% slower. It’s most likely not that noticeable to most people.

If you are going to resample, make sure to use as your source track the oldest version of the track. If you have an mp3 file, which you converted to ogg, don’t do anything to the ogg. Resample the mp3 and export to ogg in one step if you can. Each operation to a sound file will have some quality lost. wav->mp3 has loss, mp3->ogg has loss, ogg->resample has loss. wav->resample/ogg will have the best outcome.

Here’s how to change the rate in audacity:
Open audacity
Drag source file (wav, mp3, ogg if you have to – use the best quality source you can) into audacity
EDIT: Change the project sample rate in the lower left corner (previously I thought you change sample rate on track itself, but that was wrong)
Click file, export as ogg vorbis, and name the output

Most other converters will also have a field letting you input what you want the output quality to be. They may be like “cd quality”, “better than cd quality” etc. You usually will want cd quality or 44100.

Hope this helps!

One of the features had to do with zooming, which had already been implemented but not hooked up to wrightscript; and the other had to do with being able to do collision detection with wrightscript alone.

Now I am not trying to compete with pwlib, I don’t intend to fully replicate the edgeworth walkabout code. But I was interested in whether implementing that was possible without too many changes to the engine.

After implementing a few things, each change led to another, and beta 10.95 is turning out to be one of the biggest updates PyWright has ever had. Most of the updates are small, but quite a few of them are meaningful enough to really have an effect. Being able to add graphics to buttons, rock-solid saving capabilities, and more control over where code jumps (label none is being deprecated) can make workarounds the exception rather than the norm.

It’s such a big set of fixes in fact, that I am starting to think that the “beta 10.95″ moniker isn’t really fitting. PyWright for the most part has been pretty stable. Each release brings issues along with it that can break games, but the amount of changes needed to update games to be compatible has been low. I would have liked to break old games less than I have, but it was beta right? Well now it’s not. I’m not going to hide behind the beta name any longer. The internet has enough betas on it’s hand.

Henceforth, the next version of PyWright is going to be named version 0.95, and it is the series of releases that will eventually (and soon) be 1.0. I will still keep tweaking things as I always do, I’m sure 0.95 will break something, but I am aiming for more stability from this series. Changing the name is part of that. 0.95 will be out this February for sure. It will require new binaries for those of you using the binary releases.

Currently I am methodically testing the save feature in every possible situation I can come up with to ensure that it is crash-free.

Oh, and the mythical beta 11? Besides being somewhat on hold, it’s new name is going to be version 2.0.