With the new examples page on the website, I thought it was probably
time to update the logo we use there to a nicer one.
I've also added a basic one to make the background colour change example
nicer, and sometimes you might want the less busy one.
- [x] Changelog updated
![image](https://github.com/agbrs/agb/assets/460842/062bb473-1b2f-4db0-a712-6d264240be9a)
Adds support for the effect EDx (note delay) although it isn't
completely correct. And envelopes were too short so I've fixed that too.
- [x] no changelog update needed
Versions of xmrs below 0.4.1 (unreleased, 0.4.2 is on crates.io but
0.4.1 is in the repo) have a bug where they swap linear and amiga
frequencies. This caused all old versions of agb (which were using
version 0.3) to use the amiga frequency table rather than the linear
one. Technically it sounds slightly wrong but it is kinda hard to tell.
Since agb 0.20.0, we are now using xmrs 0.5, which correctly reports the
frequency type for the XM file. That pointed out an error in the
note_to_speed method for linear frequencies (since those are now being
used). It turns out that the formula for calculating the frequency
expects a 0 based index for the note, but we were passing a 1 based
index for the note. Moving this down a note fixes the issue where things
were being played at the wrong frequency.
- [x] Changelog updated
We should release 0.20.1 to fix this issue pretty soon.
Versions of xmrs below 0.4.1 (unreleased, 0.4.2 is on crates.io but
0.4.1 is in the repo) have a bug where they swap linear and amiga
frequencies. This caused all old versions of agb (which were using
version 0.3) to use the amiga frequency table rather than the linear
one. Technically it sounds slightly wrong but it is kinda hard to tell.
Since agb 0.20.0, we are now using xmrs 0.5, which correctly reports the
frequency type for the XM file. That pointed out an error in the
note_to_speed method for linear frequencies (since those are now being
used). It turns out that the formula for calculating the frequency
expects a 0 based index for the note, but we were passing a 1 based
index for the note. Moving this down a note fixes the issue where things
were being played at the wrong frequency.
If the allocation for the working space and the result of the QR code
fails, then we don't want to panic but just not render the QR code.
- [x] no changelog update needed
Double panics could produce some interesting results, so we should
probably avoid them to avoid breaking the state too much :)
- [x] no changelog update needed