Well the test only had one pattern, which lasts about 6 seconds .

I'm reconsidering the whole idea of sharing this code... It's became a rather convoluted mess of things. It's all became rather idiosyncratic with a lot of work-arounds and hoops you have to jump through - documenting all of it would be a rather lengthy process. I also don't want to spend a lot of time making it easily reusable outside my audio framework, to which module playback is heavily bound...

Well, I've promised to share it, so here goes - if you figure it out, good for you . Attached what I have to this post. It's not entirely finished, but it's working.

How to make it play something:
1) Prepare a .src file using mod2.src as a template, along with all the needed .wav's in the same directory
2) Compile it with modconvert.py (requires Python)
3) Play it back (AYTest.cpp is an example program that does that, and one we will be using to write the music).

The whole thing is in C++, and the text->binary format converter is in Python. The archive contains all needed source-files, just link all *.cpp files in both directories with Allegro.

Oh, not commented at all. And there be dragons in that code .

EDIT: Remember, it only works properly with RH 1.0 under Windows.

As currently drafted, that'd be against the rules. But if you send me the code, I'll try to incorporate it as an option in the coming v1.1 of the library.

Re: all that:

• I'm not making very good progress with the AY file format. The format itself is a horrid mess, but the problem seems to be my z80 code — I think I've stripped it from its previous project quite poorly and probably broken something. But I'll keep trying.

• I've pretty much decided I'm going to give up on the sound fixes. As the only affected platform seems to be Linux, I'll just make buffer size a compile time option. Especially as I want to get the RT_MIX palette and C++ #include fixes 'out there'

EDIT: partial update. I have fixed my AY file format music player, and uploaded it to the website. Here's a direct file link. Some documentation and a demo program are included in that archive.

{"name":"593618","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/7\/777a600c4e59720821347fc11f93833b.png","w":640,"h":480,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/7\/777a600c4e59720821347fc11f93833b"}
What am I doing wrong here? Both blits are drawn to 160/120 (the center). The one in the lower right corner works just as expected. But when I flip the y scaling - why do I get this shifted and enlarged blit above it? And in case that's the intended behavior, how would I get just a vertically flipped version?

(EDIT)
Ah, figured it out now by glancing at retrohack.c, you have a special case there for when the y scale is < 0.. still, it's weird - the Atari Lynx did not do any such position/size adjustments just because you used flipped drawing.

A cursory look would suggest you messed up the signs. Y2 should have sin+cos, not sin-cos. Oh, and I would suggest using the Programming Questions forum for general questions not related to RH, there is no need to clutter this thread.

Well, since I'm already making a post here, I might brag a little.

A few minutes ago, I finally managed to merge my blitter code with the tracker playback code without one farking up the other, and I'm really happy about it . I ended up counting every single expended cycle, including peculiarities such as the AY bus having a different clock resulting in additional cycles for synchronization, and even the single cycle cost for reading the keyboard.

Well, at least now I have a cycle-perfect blitter + sound playback. It probably crashes if the amount of blits needed overloads the blitter for a given frame, but that's something to be solved tomorrow .

Nothing, it's a RetroHack bug. It'll be fixed in V1.1 of the library, which I hope to release tonight. In the meantime, you can fix it yourself by going into retrohack.c, finding the segment that starts at like 449 and looks like this:

  else
  {
    srcy = (g->images[0]->h << 22) - 1; // start at the bottom, draw upward

    y += scaley*g->images[0]->h; // move up the required number of pixels
    x -= skew*g->images[0]->h;
    scalex -= scalechange*g->images[0]->h;
  }

And replacing it with:

  else
  {
    int yadd = scaley*g->images[0]->h;

    srcy = (g->images[0]->h << 22) - 1; /* start at the bottom, draw upward */

    y += yadd; /* move up the required number of pixels */
    x -= fixmul(yadd, skew); skew = -skew;
    scalex -= fixmul(yadd, scalechange); scalechange = -scalechange;
  }

Sorry about this!

EDIT: new screenshot:

http://www.allegro.cc/files/attachment/593636

Grrr. Lost my first post to a login timeout. So, very briefly:

Version 1.1 of the library is now available, with fixes to RT_MIX palettes, vertically flipped sprites with non-zero ScaleChange and/or Skew and C++ #inclusion. Sound code is reverted to the version 1.0 version rather than the various realtime fixes that weren't working under Windows. BUFFER_SIZE may now be set on the compiler command line so that it can be chosen at build time. I think that's fine for now, as the only problems have been with the latency under Linux, where people will tend to build for themselves.

Also, to clarify — the competition ends on the 18th of November (as per the website and posts here), not the 11th as per the scroller in Tetrominoes. That text was sadly left in place from before the competition start was put back by a week.

Comments and feedback are welcome.

One pixel uses only half a byte. I do this here:

rt_UploadGraphic(mode, data, 1, w, h, 0);
mem_used += w * h;
printf("%d/64 KB used", mem_used / 2048);

Hi guys. I've been out of this scene entirely since I've been working full-time, and popped onto a.cc to show someone, and I see there's a RetroHack. I wished I'd found out earlier - the one week Back2Hack of 2002 was a good one even though only Elias & I made anything (or were there any others?)

In the Back2Hack I spent day one making the system play MIDI files, probably the best feature of my entry, and I'm thinking about trying to do the same thing here, for the benefit of anyone who wants to use such a feature. Would that be helpful to anyone? I haven't tried the code out yet, so I don't know how doable that would be. I'll look more at it tonight.

Don't forget the caveat that pixel scan lines have to begin on byte boundaries, so if your sprite is an odd number of pixels wide then storage is allocated for a spare pixel at the end of every scanline, and then not used. So the correct formula to work out memory usage for a single sprite of size w × h is ((w + 1) >> 1) * h.

Oh, good spot. In that case the compiler is effectively being told "here's some C++ code which you should expect to link to from a pure-C file" which obviously doesn't make any sense. I'll fix that and reupload version 1.1 tonight. I think it's acceptable in this case not to increment the library version because this is a mere linking problem and definitely either doesn't change the functionality of the library or makes it work.

No, it was just you two. Which is partly why I've not exactly been pushing the Back2Hack angle.

EDIT:
I also think it's time to become certain about the categories that prizes will be considered part of. I'm going to come up with some specific proposals tonight. In the meantime, I've decided to clarify the rules concerning library modifications, for the benefit of Jeff Bernard. Entries with some modifications are acceptable, but in that case both a version with the modified library and a version without will be circulated in the judging pack to provide a means of verification that the modifications don't fundamentally subvert the purpose of the competition, e.g. by increasing the amount of drawing that's allowed to be done each frame.

I tried displaying the sound output, and couldn't find the problem I get yet, but I'm wondering about something else now. This code

produces this when recording back from ALSA's output: {"name":"593678","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/b\/5b5d47136d0d8cc13766169aee23918b.png","w":1234,"h":393,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/b\/5b5d47136d0d8cc13766169aee23918b"}

So, is the distortion of the square wave over time supposed to happen? (I assume it simulates the AY..)

And also, why is the audio stream only played at half volume?

Yes. I just tried again with only 1 channel now, and then, the effect is gone. I get a perfect square wave, just not centered.

It seems that the sound effects (Win32) are playing a good 1/2 second later than when they are triggered. This kind of sucks for connecting actions to sounds!

Is there something I may be doing wrong to cause this?

Has anyone see that under linux/OSX? If not, its deff a bug in the windows driver.

I don't remember having this problem last time I played with allegro's AUDIOSTREAMS.

edit: IF it is a problem in all platforms, I think its a bug, it should not wait till all buffers are empty. And I'm postive it didn't for me a couple years ago (in linux). So I'd be willing to help fix allegro in that case. even if its just for the compo.