AGABlaster - New CDXL Player Released

[movec]

Originally Posted by emiespo

As I said, I'm writing my own CDXL engine to both understand how it works, and make games out of it. Once it will be in a decent state, I plan to release it as open-source, so other people can possibly make / port more games to the Amiga. There's a Java UI that allows to define the boring bits of logic / moves, etc.

Sounds great. I already have a new version 1.1.0 almost ready that will generate standard CDXL files by default. Padding will still be available as an additional option.

AGABlaster is optimized for AGA systems because I was curious how well the original AGA architecture would support video display with its 64bit graphics access mode. However, the most distinctive feature is probably that AGABlaster skips graphics data on disk, if it is displaying a video on an Amiga that has not enough i/O bandwidth. In this case it only reads the frame header and the audio data, but skips in some frames the graphics data to maintain a smooth video display rate. Hence, the audio should always be perfect, only the frame rate is reduced to the bandwidth of the system. And for 32bit disk controllers it turned out that 32-bit alignment is important otherwise the driver realigns the data which reduces the framerate. That's where the padding comes from, because this was an easy way to make this work. However, the audio chunk can also be 32-bit aligned by adjusting the frequency and that's what the next version 1.1 will do by default.

Originally Posted by emiespo

So I can certainly cope with custom CDXLs, although initially to be sure my player was behaving correctly I was also testing with standard CDXLs found online.

The were 2 reasons for 'custom' mode: one was the alignment, the other was the 24-bit graphics mode. However, with version 1.1 AGABlaster will simply use by default full color palettes according to the number of planes, and then it is either a multiple of 2 or 3, depending whether it is 12 or 24 bit colors. So there is no extension necessary.

Originally Posted by emiespo

My ultimate goal is to also add some RLE compression to the format, as with good quality and 12fps, it goes well beyond the DMA capacity of a CDTV (or even a CD32, but on a 68020 the CPU should be able to compensate). I think using optimised asm, a 68000 with fast-ram should be able to cope with it.

I am looking forward whether you get a better framerate - you gain in I/O speed but you have an overhead because of the decompression, so this will be interesting. Originally AGAConv was called animedit because it added audio to anim files (supporting delta encoding).

Originally Posted by emiespo

Second topic: in order to compile Agaconv on MacOS, I had to add a OSLayer class for it + fix a couple of minor things (compiler on MacOS was complaining about missing includes). Will try to make a patch / bug / merge request next week if I got time.

Sounds great! I was hoping that people would pick up the OSLayer design and add the respective I/O features for their favorite system.

cheers!

[emiespo]

I'll start with a further question, and reply to the previous points below.

Question: I'm converting from `.mkv` videos to `.cdxl`. Conversion works very well, except the audio always pops loudly before the end of the clip, as if some random bytes were added for some reason. The same issue is not present in the source files. This is very annoying and I am afraid it would even damage my audio equipment in the long run.

Any ideas on what could be happening here?

Now quoting the previous message:

Originally Posted by movec

[...] However, the most distinctive feature is probably that AGABlaster skips graphics data on disk, if it is displaying a video on an Amiga that has not enough i/O bandwidth. In this case it only reads the frame header and the audio data, but skips in some frames the graphics data to maintain a smooth video display rate. Hence, the audio should always be perfect, only the frame rate is reduced to the bandwidth of the system. And for 32bit disk controllers it turned out that 32-bit alignment is important otherwise the driver realigns the data which reduces the framerate. That's where the padding comes from, because this was an easy way to make this work. However, the audio chunk can also be 32-bit aligned by adjusting the frequency and that's what the next version 1.1 will do by default.

Gotcha. This is indeed an interesting feature, but it has less to do with the format and more to do with the player. Wouldn't it be enough to have the destination buffer aligned to 32bit, or even the original file has to keep padding?

Originally Posted by movec

The were 2 reasons for 'custom' mode: one was the alignment, the other was the 24-bit graphics mode. However, with version 1.1 AGABlaster will simply use by default full color palettes according to the number of planes, and then it is either a multiple of 2 or 3, depending whether it is 12 or 24 bit colors. So there is no extension necessary.

So if I understand correctly, standard CDXL on the CD32 would support HAM8, but use a 12bit palette? Another thing half-baked in a hurry to release the CD32 it seems...

Originally Posted by movec

I am looking forward whether you get a better framerate - you gain in I/O speed but you have an overhead because of the decompression, so this will be interesting. Originally AGAConv was called animedit because it added audio to anim files (supporting delta encoding).

Sure, this is very low pri at the moment, I still struggle to find the time to finish the engine

Sounds great! I was hoping that people would pick up the OSLayer design and add the respective I/O features for their favorite system.

cheers!

I'll try to add a diff with the changes I have on my Mac Mini asap.

EDIT: finally found the time to clean up my local changes and create a pull-request to add official support for MacOs to agaconv... although the changes are really minimal, this is my first-ever pull-request on Github, please let me know if anything looks wrong!

EDIT: n2, I discovered that Audacity can actually display audio in a CDXL file (I presume because it either has hidden CDXL support, or because it has heuristics to detect raw audio), and this is how the sample looks towards the end. I'll see if I can find the root cause of it and fix it! (see attachment).

N.B.: the extracted raw PCM from ffmpeg does not have this issue, so this must be where the conversion happens (padding of non-zero values maybe?).

EDIT n3: I think I fixed it! The audio-encoder would read past eof when the audio length has to be adjusted, and then +128 is added to make it unsigned. This produces a spike 0-128 if EOF is reached (0 is returned by istream::get()).

EDIT n4: Added commit with audio fix to my existing pr.

Now I can get back to finishing my game engine... I stopped as I feared it would ruin my speakers in the long run.

[movec]

Originally Posted by emiespo

Gotcha. This is indeed an interesting feature, but it has less to do with the format and more to do with the player. Wouldn't it be enough to have the destination buffer aligned to 32bit, or even the original file has to keep padding?

The target buffer that AGABlaster uses is 64Bit aligned to make use of the 64Bit AGA graphics mode. The 32bit alignment on disk is about the IO device driver (I use a 32bit IO controller, so on older systems it might not make a difference), but with my Amiga I was able to produce a 2x slowdown when not using a 32bit alignment on disk (AGABlaster reads the chunks separately, when loading a file as a whole this is not an issue, only if you seek around and read chunks as AGABlaster does).

Originally Posted by emiespo

So if I understand correctly, standard CDXL on the CD32 would support HAM8, but use a 12bit palette? Another thing half-baked in a hurry to release the CD32 it seems...

There were several games that used CDXL videos with AGA8 but only 12-bit color range. I once tested this with one game and AGABLaster did indeed play those cutscenes (it was some space ship scene). But it was only 12bit color palette because the CDTV used CDXL videos with 12bit color palette.
Now, adding 3-byte colors instead of 2-byte colors in the color palette section is straight-forward, but this was a custom change.

Originally Posted by emiespo

EDIT: finally found the time to clean up my local changes and create a pull-request to add official support for MacOs to agaconv... although the changes are really minimal, this is my first-ever pull-request on Github, please let me know if anything looks wrong!


N.B.: the extracted raw PCM from ffmpeg does not have this issue, so this must be where the conversion happens (padding of non-zero values maybe?).

That's interesting. Your fix does fix it, but I will look into this more. It shouldn't read more bytes than the PCM has (the frequency is adjusted before and then the PCM file is extracted)



Anyways, I am looking into the patches!

[emiespo]

Originally Posted by movec

The target buffer that AGABlaster uses is 64Bit aligned to make use of the 64Bit AGA graphics mode. The 32bit alignment on disk is about the IO device driver (I use a 32bit IO controller, so on older systems it might not make a difference), but with my Amiga I was able to produce a 2x slowdown when not using a 32bit alignment on disk (AGABlaster reads the chunks separately, when loading a file as a whole this is not an issue, only if you seek around and read chunks as AGABlaster does).

Makes sense, I presume the dos devices might be doing something silly to align a 32 bit source to 64.

There were several games that used CDXL videos with AGA8 but only 12-bit color range. I once tested this with one game and AGABLaster did indeed play those cutscenes (it was some space ship scene). But it was only 12bit color palette because the CDTV used CDXL videos with 12bit color palette.
Now, adding 3-byte colors instead of 2-byte colors in the color palette section is straight-forward, but this was a custom change.

In an ideal world the CD32 would’ve ditched CDXL for something better suited, if not mpeg (except the mpeg module came months later and was too expensive). I know of at least one game that has a custom anim format, progressive decoding (so it can skip by reducing the resolution), and it’s Soccer Kid. It has full-screen FMV, but it really struggles on a basic CD32, with a TF3xx it is a lot more fluid.

That's interesting. Your fix does fix it, but I will look into this more. It shouldn't read more bytes than the PCM has (the frequency is adjusted before and then the PCM file is extracted)

Anyways, I am looking into the patches!

Yeah my main goal was to add MacOS support, then I realised there was this issue too. Rather than diving into the logic and math of audio chunks and sizes, I thought: code that prevents steep jumps is simple, it should be there anyway and won’t hurt, especially expensive audio equipment (maybe it should also throw some warnings…).

Surely there’s a more involved (and much better) way of fixing it!

Thanks to that, I also resumed working on my game engine. Once it looks decently good, I’ll post a preview somewhere.

[lionagony]

Originally Posted by emiespo

In an ideal world the CD32 would’ve ditched CDXL for something better suited, if not mpeg (except the mpeg module came months later and was too expensive). I know of at least one game that has a custom anim format, progressive decoding (so it can skip by reducing the resolution), and it’s Soccer Kid. It has full-screen FMV, but it really struggles on a basic CD32, with a TF3xx it is a lot more fluid.

Do you know what format Microcosm used because I thought the intro anim looked really good?