Hively Tracker

Posted: 2008-10-13 14:59:56

Just looking around
Posts: 7

Member since:
2008-10-13 14:50:31

Just wanted to post some fixes for the sawtooth generation.
Os I guess I post here instead ;)
void hvl_GenSawtooth( int8 *buf, uint32 len )
{
uint32 i;
int32 val, add;

add = 0xFFFF / (len-1);
val = 0x8000;

for( i=0; i<len; i++, val += add )
*buf++ = (int8)(val>>8);
}

Just added better resolution to the calculation so all waves end at the same value (0x7F) instead of 0x7F, 0x7C and 0x78.

And the creation of the panning tables should probably have a +0.5f so that the maximum value is 0xFF instead of 0xFE.

0x5AB07A6E

Posted: 2008-10-14 19:54:08

Supreme Being
Posts: 448

Member since:
2006-12-13 11:34:00

The thing is, i'm 99% sure all the "GenXYZ" routines are converted from the original 68k code, so any improvement would actually just be straying from the AHX "standard". So, unless the 68k waves all end at 0x7f, i'm reluctant to change that.

As for the panning tables, the difference between 0xFE and 0xFF is compensated for by the mix gain functionality. If theres anything i've learnt during the development of HT is "don't mess with the volume". I don't want to do anything to change the mix, even subtly, especially anything that makes stuff louder; lots of existing HVL mods are preset to mix at the maximum level (via autogain), and anything that makes the mix louder will just make those mods clip.

AHX forever!

Posted: 2008-10-15 07:53:05

Just looking around
Posts: 7

Member since:
2008-10-13 14:50:31

Wow O_o
what about the noise generator? How is that supposed to work?

    if( ays & 0x100 )
    {
      s = 0x80;

      if( (LONG)(ays & 0xffff) >= 0 )
        s = 0x7f;
    }

What is the last IF checking for? As you can figure out, there are no values of 0x80 in the noise table.

0x5AB07A6E

Posted: 2008-10-15 11:28:00

Supreme Being
Posts: 448

Member since:
2006-12-13 11:34:00

Yeah, that looks wrong.

I think when they wrote WinAHX, they converted something like:

    move.b #$80,d0
    ext.l  d1
    tst.l  d1
    bmi    .nope
    move.b #$7f,d0
.nope

into that code. Of course, the C version doesn't work because C won't do a signed extension from the 16 bit value.

If my suspicions are true, it should actually be "if( (ays&0x8000) == 0 )".

But is this something that should be fixed? What do you think?

AHX forever!

Posted: 2008-10-15 13:36:37

Just looking around
Posts: 7

Member since:
2008-10-13 14:50:31

Well you can cast it to signed short...

if( (signed short)(ays & 0xffff) >= 0 )

Or you can

if( ays & 0x8000 )

Is the original 68k code available somewhere? Or is the C code done by dissasseblying the old executables.

0x5AB07A6E

Posted: 2008-10-15 15:12:50

Supreme Being
Posts: 448

Member since:
2006-12-13 11:34:00

The 68k code is not available anywhere. The C code was done by abyss, who also wrote the 68k code :-)

AHX forever!

Posted: 2008-10-15 16:04:37

Moderator
Posts: 197

Member since:
2006-12-15 18:06:32

the 68k replayer should be available?
isn't the replayer included with the tracker?

http://www.uprough.net

Posted: 2008-10-15 16:06:06

Moderator
Posts: 197

Member since:
2006-12-15 18:06:32

oh... bins only :(

http://www.uprough.net

Posted: 2008-10-15 16:16:49

Just looking around
Posts: 7

Member since:
2008-10-13 14:50:31

hmm, so I guess we'll have to find a memory wiever for the Amiga then... :P
Ok, I'm having some problems with getting this to run on the GBA as well... ARM CPUs doesn't like unaligned 32bit reads or writes, the structs for the tunes have it everywhere, can this be changed? I know I can change this for the GBA version only but do you think others can benefit from this too or does it mess up the source too much do you think?
Also the hvl_tune.ht_Tracks takes something like 96kB and a complete tune around 200kB, isn't that pushing it a bit?

0x5AB07A6E

Posted: 2008-10-15 19:30:01

Supreme Being
Posts: 448

Member since:
2006-12-13 11:34:00

The replayer converts from the HVL and AHX files into structures. I'm pretty sure it treats the raw HVL and AHX files as a pure byte array, and the structures should be properly aligned by the compiler.

WinAHX and older hively replay versions had a "clr_l" routine that caused alignment problems on some CPUs, but that should be swapped for memclr.

BTW, there are other fixes to the replayer that you'll need, but i need some test files from skope before i finalise them.

AHX forever!

Posted: 2008-10-15 19:35:48

Supreme Being
Posts: 448

Member since:
2006-12-13 11:34:00

FluBBa said:
Also the hvl_tune.ht_Tracks takes something like 96kB and a complete tune around 200kB, isn't that pushing it a bit?

ht_Tracks is only a static array for convenience. Theres no reason why it couldn't make it a pointer to hvl_step and malloc the required size for the module.

Also, ht_Voices could be a pointer to hvl_voice, and you then only have to allocate enough voices for the currently loaded module as well.

Another way to save space is to set a lower maximum instrument name length.

AHX forever!

Posted: 2008-10-15 21:07:15

Just looking around
Posts: 7

Member since:
2008-10-13 14:50:31

I guess I saw the result from the "clr_l" and the compiler actually fixes the alignment.
I had an idea that maybe you only need to initialise one track at a time? When you run "hvl_InitSubsong" you fill in the track data for that song only? =)

0x5AB07A6E

Posted: 2008-10-16 11:29:04

Moderator
Posts: 197

Member since:
2006-12-15 18:06:32

If you ask me, it's time to move on. And start adding cool stuff to Hively.
Why not make a compatibility mode in HivelyTracker where you keep things as they are, and use the AHX replayer as it is now, to make the tunes sound just like in AHX, and you limit the editing mode to make it AHX compatible. Then we could have the new standard Hively editing mode, with these fixes implemented, and also new stuff could be added, like new waveforms and stuff. Lately we have been discussing ideas... Yoki came up with an interesting idea, real resonance filter could be added, to make it purr like a real C64.

http://www.uprough.net

Posted: 2008-10-16 11:31:40

Moderator
Posts: 197

Member since:
2006-12-15 18:06:32

My point is, if we separate the two, it shouldn't be dangerous to add stuff and change stuff to the HVL part of the replayer. Let's future, now!

http://www.uprough.net

Posted: 2008-10-16 16:53:32

Supreme Being
Posts: 448

Member since:
2006-12-13 11:34:00

The thing is, aside from the white noise fix, the fixes FluBBa suggested aren't really an improvement of the kind you are talking about. You'd be straying from the AHX standard for not much gain.

Actual enhancements are a different thing.

AHX forever!

Posted: 2008-10-22 08:14:49

Supreme Being
Posts: 448

Member since:
2006-12-13 11:34:00

FluBBa said:
I guess I saw the result from the "clr_l" and the compiler actually fixes the alignment.
I had an idea that maybe you only need to initialise one track at a time? When you run "hvl_InitSubsong" you fill in the track data for that song only? =)

Thats not really possible. Since subsongs can actually overlap on the position editor, its impossible to know where a subsong actually ends, so you'd have to load from the start of the subsong to the end of the song; so for subsong 0 you'd load the whole song anyway!

AHX forever!

Posted: 2008-12-01 14:55:42

Just looking around
Posts: 7

Member since:
2008-10-13 14:50:31

In the function hvl_DedcodeFrame it adds samples*4, why is it 4?
Shouldn't it be bufmod or something more descriptive?

0x5AB07A6E

Posted: 2008-12-01 14:59:31

Supreme Being
Posts: 448

Member since:
2006-12-13 11:34:00

Ahhh crap.

I thought i'd fixed this. Basically, yes, it should be bufmod. I spotted it before and was sure i had changed it, but apparently not. So far everyone is using 16bit interleaved streams, so it hasn't caused a problem for most people.

I don't know where the *4 came from.

AHX forever!