[pyddr-discuss] pyDDR 0.6.5 observations (long)

[Joe Wreschnig]

On Sat, 2003-05-31 at 09:58, dododge at smart.net wrote:
> Now onto the bad stuff... :-)
> 
> 
> Play problems:
> 
> The stock code won't load any of the converted step files. This was
> not a problem in 0.6.3. The issue here is that the step files do not
> include the filenames of the associated mp3 files, and 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")):

(Not supporting MP3s isn't a bug, it's a feature. :)

> The program crashes on the song selection screen. It only seems to do
> this in full-screen mode, and I can't force it to happen. It usually
> occurs if I've been playing full-screen for 10-20 minutes. I think
> it always occurs right when I move in the song list. On the command
> line I don't see much useful information:
> 
>   Audio: Skipping 45.000000 seconds...
>   Pygame Parachute Traceback:
>   Segmentation fault
> 
> The crash wouldn't be a big problem except that it leaves the screen
> resolution changed and the mouse disabled. The keyboard does work,
> so to fix it I do something like switch to another virtual console
> and briefly run frozen bubble full-screen. After that the mouse is
> working again, and I can do ctrl-alt-kp+ to switch back to my normal
> resolution.

This is a bug in Pygame/SDL/Python. pyDDR cannot cause a segmentation
fault because we can't access memory.

> 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. For all I know this
> might have to do with the step data. The arrows do at least seem to get
> back in sync with the music after the stop ("Max300" might be an
> exception, but I don't play that well enough to be sure).

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 other issue with stops is that sometimes the arrows at the top of
> the screen light up during the stop for no apparent reason. It's
> really obvious if you usually watch the top of the screen to gauge
> your progress. "So Fabulous, So Fierce" definitely shows the problem
> when it hits its six stops in a row.

Yeah, we know about this... There's a lot of arrow queuing problems.

> Documentation issues:
> 
> The manpage pyddr(6) references instep(1), but there's no such
> manpage and the "instep" program does not get installed anyway.

Thanks, I'll remove this.

> pyddr(6) references "stepfile.txt", which is not installed.

`-piman at sanctus:~% ls /usr/share/doc/pyddr/stepfile*
/usr/share/doc/pyddr/stepfile.txt.gz

Talk to your OS distributor to get this fixed.

> 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.

(If you're your own OS distributor, you have the source, and thus the
files.)

> 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.

> Interface issues/wishlist:

Please read the TODO file before posting this stuff. I've snipped
everything that's already in it.

> I don't see any way to toggle autofail interactively.

Game Options->Handicaps->Autofail

> It sometimes takes 2-3 seconds to get a visual response after
> hitting the start button on the song selection screen. It would
> be nice if there was "something" that happened instantly to let
> you know that the start button was noticed; perhaps an audio
> response of some sort.

If you have the announcer on, it plays something here. The real problem
is that we lack a good announcer...

> The song music is not looping on the song selection screen. I don't
> know if this is intentional or not.

This is intentional.

> After a song, the grading display takes something like 4 seconds to
> fade in. That's way too long for an impatient player :-). It would be
> nice if you could hit the start button while the data is appearing
> and skip the rest of the fade-in.

I'll look into this.

> The left/right cursor keys do work in the song selection screen,
> but the up/down do not. Is that intentional? Personally I'd like
> them to work everywhere in the interface that ijkl also work, since
> I don't like the ijkl keys at all :-)

RTFM. Up/down are second player's controls, you can remap them.

> The drawing order for arrows seems to shift occasionally. For example
> if two arrows overlap, then sometimes they swap which one is "on top"
> while they're scrolling up the screen. It's not really a gameplay
> problem, but can be distracting. I'm not sure exactly what triggers it.
> It seems to happen near the top of the screen, and I think I've seen
> it with both freeze and regular arrows. "Secret Rendezvous" didn't
> seem to have the problem despite having plenty of overlapping arrows,
> but "Twilight Zone" and "Never Gonna Make" did show it.

Arrows are drawn in pretty random order at this point. We'll probably do
something about this eventually, but it's a difficult problem since
spritegroups are unordered.

> ... snip stuff about install system...
> 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.
-- 
Joe Wreschnig <piman at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://icculus.org/pipermail/pyddr-discuss/attachments/20030531/de238acc/attachment.pgp>