[pyddr-discuss] pyDDR 0.6.5 observations (long)

[dododge at smart.net]

Joe Wreschnig <piman at debian.org> writes:
> On Sat, 2003-05-31 at 09:58, dododge at smart.net wrote:
> > the StepFile code only seems to look for ".ogg" files
> > automatically. Here's a workaround:
>
> Here's a better one:
>                ("bg", "-bg.png"), ("file", ".ogg"),
> -              ("filename", ".mp3"), ("movie", ".mpg")):
> +              ("file", ".mp3"), ("movie", ".mpg")):

Thanks. I figured that was the better solution but it wasn't obvious
whether "filename" was supposed to be recognized by the step format or
not so I left it alone.

> > The program crashes on the song selection screen.
> >
> >   Audio: Skipping 45.000000 seconds...
> >   Pygame Parachute Traceback:
> >   Segmentation fault
>
> This is a bug in Pygame/SDL/Python. pyDDR cannot cause a segmentation
> fault because we can't access memory.

Okay. If you know of something I can do to pygame at compile/runtime
to make it more verbose let me know and I could try to repeat the
problem.

> > While stops are working better, there still seems to be some timing
> > issues. There sometimes looks like an adjustment period where the
> > arrows might drag a bit after or during the stop, rather than the stop
> > being an instant stop and start operation.
>
> I'm not seeing this. For me the stop is instantaneous (assuming my
> system isn't going all slow). Can you describe this a little better?

The best example so far seems to be the stop in Maxx Unlimited
maniac, which occurs at the end of a variable-speed freeze. What I see
in pyddr is that the arrows stop moving before the freeze arrows are
completely exhausted, and when things start moving again the arrows
briefly move slower (faster?) than full speed. This might leave
things a little bit out of sync, but I just don't know Maxx well
enough to be sure. For comparison I've got a video of DWI running Maxx
and in that case the stop/start is very smooth and precise. However:

  - I haven't unlocked Maxx in the PS2 version of Max2 yet, and I've
    never played it in the arcade, so I don't know what it's actually
    supposed to look like.

  - it could be a problem with the machine. I'll try to run the song
    this week on a faster CPU with more memory and faster video board
    and see if it makes a difference.

  - it could be the step file itself, since I don't know that the dwi
    file running in that movie is the same one that I converted to
    step format.

Here's the dwi and step file if it's any help:

  http://smart.net/~dododge/pyddr/Maxx-Unlimited.dwi.gz
  http://smart.net/~dododge/pyddr/Maxx-Unlimited.step.gz

I got this from the DWI archive at www.bemanistyle.com.

Healing Vision Angelic manic seems to do its stop okay, though I'm
still not sure about the sync because I never seem to hit the last
two arrows successfully. I've played that one on console versions
many times and I'm used to being able to get those last two arrows based
on the music. Again, it might just be a problem with the step file.

> > pyddr(6) references "stepfile.txt", which is not installed.
[...]
> > The steps.py code references "docs/fileparsers.txt" and
> > "docs/dance-spec.txt", neither of which are installed.
>
> Talk to your OS distributor to get this fixed.

Yes, that would be me :-). Or at least I do build my applications
from source rather than using binary packages.

> > Most of this stuff can be found in the source tarfile, but I'm looking
> > at what's left on the system after doing a "make install" and removing
> > the source tree.
>
> 'make install' installs pyDDR and all data files required to play pyDDR.
> Like every other program, it is up to your distributor to install the
> README and other documentation.

I'm not too concerned about fileparsers.txt and dance-spec.txt since
they're referenced directly from sourcecode.

But if stepfile.txt is going to be mentioned in a manpage then IMO it
ought be installed automatically by the Makefile when the manpage is
installed. Or at least make some suggestion about it in the INSTALL
file.  Ideally it would be a manpage as well, such as step(5), but of
course it's much easier for me to suggest such things than it is for
someone to do them :-)

Or maybe I'm just too sensitive about this. A long history of dealing
with Solaris manpages that say "see also: some manual not on your
system" has made me a bit touchy about uninstalled manuals from a user
point of view.

> > Interface issues/wishlist:
>
> Please read the TODO file before posting this stuff.

Sorry about that. I'd been taking notes as I played around and just
dumped all of it to the list without checking for a TODO in the source
tree. You're right, much of my wishlist is in there.

> Game Options->Handicaps->Autofail

Ah, thanks. I guess the reason I didn't notice that is because I kept
glancing past "Handicaps" as if it were a menu title rather than
something I could follow for more options.

Something else about the menus I noticed: handling of E_RIGHT is
a little inconsistent. For example moving right from Play Game, Game
Options, and Handicaps takes you to the submenus, but from Regular
it doesn't continue on to the song selector. Also, if E_RIGHT can go
to a submenu then perhaps E_LEFT should move back up? Then again
I probably wouldn't want E_LEFT to do that _within_ the song selector,
so I don't know what the best approach would be.

> > It sometimes takes 2-3 seconds to get a visual response after
> > hitting the start button on the song selection screen.
>
> If you have the announcer on, it plays something here.

I've had the announcer shut off since some much earlier version because
(as I recall) it waited for the voice clip to complete before starting the
song, and some clips were long enough that I became too impatient :-)
In 0.6.5 I see that it doesn't wait for the clip to complete, but it
cuts the announcer off after a second which probably isn't good either.

> > The left/right cursor keys do work in the song selection screen,
> > but the up/down do not.
>
> RTFM. Up/down are second player's controls, you can remap them.

Okay, thanks. I set "keyboard" to "rqwerty" and that did the trick.
Just FYI the "change difficulty" and "change song" help info don't
seem to take this into account and still indicate IJKL.

> > I realize you're following the FHS/LSB. I can keep
> > doing code changes as necessary for my own freaky requirements, but
> > figured I'd mention this as something that did come up.
>
> If you want to send in patches to do this, great, but non-FHS system
> support is not something we can reasonably do, and the install system is
> really uninteresting work.

As I said they're somewhat strange requirements and I can keep doing
workarounds on my end as needed. I've already got the entire build
from Python and SDL up through pyddr automated (including my code
adjustments), so it's not like I have to touch the files by hand each
time.

Frankly I don't know how to best handle it in the source tree. Most of
the packages I've dealt with just assume PREFIX gets applied to
everything, but that would probably break your FHS compliance. Two
similar cases that come to mind are OpenSSH and XFree86. XFree86 has a
"NothingOutsideProjectRoot" switch which causes it to relocate things
that aren't normally relocatable, and I think OpenSSH has a special
option to its configure script.

Part of it is easy -- I could just do something like this and then
set CONFIGDIR alongside PREFIX when I run "make install":

   PREFIX ?= /usr/local
  +CONFIGDIR ?= /etc

  -	install -D -m 644 pyddr.cfg $(DESTDIR)/etc/pyddr.cfg
  +	install -D -m 644 pyddr.cfg $(DESTDIR)$(CONFIGDIR)/pyddr.cfg

The problem is that "constants.py" also has to be adjusted. I
currently do that with a perl one-liner, which is probably not
the best way if it's going to be in a generic Makefile. Perhaps
something like this in constants.py:

  -mainconfig.load("/etc/pyddr.cfg", True)
  +mainconfig.load(configfile, True)         <-- or some uch variable

and then have the Makefile generate a small .py file in
"$(DESTDIR)$(PREFIX)/share/games/pyddr" that defines the variable
using "$(CONFIGPATH)/pyddr.cfg". I don't know Python well enough to
even suggest a proper way of doing that.

BTW: I just noticed that constants.py still has VERSION="0.6.4".

The other install issue I mentioned had to do with the songdir
setting in pyddr.posix.cfg not using the PREFIX setting. This one
probably should be fixed, or at least more strongly documented in the
INSTALL file ("If you set PREFIX you will need to adjust the
default configuration file accordingly"). The way I currently have
this automated is sort of messy: I egrep the songdir line out of the
file and then echo/append a completely new one to it. Some code
in the Makefile to generate the default config file from scratch would
be cleaner, but admittedly harder to maintain.

                                        -Dave Dodge/dododge at smart.net