File parsing, bug fixes, and 0.6.4

Joe Wreschnig piman at debian.org
Mon May 26 22:57:03 EDT 2003


Okay, just another heads up on what I've been working on for the past
week while Brendan's been away.

The file parsers have been rewritten and we're using something called
'.dance' internally now. the docs/dance-spec.txt gives an outline of
this format. However, it should be noted that we don't actually read
files of it yet, we just translate .step into it internally.

What does using .dance internally mean? It means instead of a Song
object, we now have three objects - a SongItem object, which contains
all the information about the song; a Steps object, generated from the
SongItem, which contains the event times for a particular set of steps;
and SongData, also made from SongItem, which is the player-independent
data (song title/name, filename). Between Steps and SongData we cover
everything Song used to do.

One of the effects of splitting Steps off from SongItem is that the two
players can have different BPMs and BPM changes now (not in theory; I
tested it yesterday and it works).

The next step (no pun intended) is to read .dance files, and have a
.step to .dance convertor. We can probably do this in the pyDDR program
itself (pyddr --convert foo.step), and reuse all the code in the
existing fileparsers.py. Once we can read .dance, I'll get started on a
.dwi reader (and therefore, as a consequence, a DWI to dance convertor).

Instructions on how to write a file parser (if someone wants to tackle
.sm or something crazy) are available as docs/fileparsers.txt in CVS.

I also hacked on ArrowSprite, HoldArrowSprite, and the BPM changing
loop. We have fully working BPM change and arrow freeze rendering now,
even across hold arrows, and with low scrollspeed settings; although, we
still drop arrow events from Judge on a BPM change. The downside is,
this seems to have slowed down pyDDR by about 10-15%. On the other hand,
I don't see an "easy" solution for that; we need to rewrite the way
event queues are handled.

So, I'm thinking we can manage 0.6.4 "on schedule" by this Thursday. The
new parsers have gotten a lot of testing so they should be mature enough
to release; the stuff I want to do in the immediate future is too big to
accomplish before then. Anyone else got thoughts on this?

(As for what I want to do in the immediate future - rewriting the event
loop to use a Python list instead of a linked list is the number one
item, and I think Brendan, John, and I all want to rewrite Judge soon.)
-- 
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-devel/attachments/20030526/53153511/attachment.pgp>


More information about the pyddr-devel mailing list