agbrs / agb Goto Github PK

Should take absolute values of x and y, just a note for myself to fix this.

As the title says. Based on CI and my testing, nightlies past 2023-12-01 cause the issue.

Looking at the commits between nightly-2023-12-01 and nightly-2023-12-02, there are a few changes around compiler-builtins, which is to be expected.

Commits of note:

• rust-lang/rust@8d69a1e
• rust-lang/rust@b592f29
• rust-lang/rust@a6f7596
• rust-lang/rust@5200817

Ill admit that I don't know enough about LTO to debug this further.

This may instead be an issue with the gba crate, but I was able to build an empty gba project without throwing errors. That said, I'm not entirely sure that empty project even did any memory access so it may not have hit this.

Linker errors

warning: memset changed binding to STB_WEAK

error: symbol 'memset' is already defined

warning: __aeabi_memclr4 changed binding to STB_WEAK

error: symbol '__aeabi_memclr4' is already defined

warning: __aeabi_memclr8 changed binding to STB_WEAK

error: symbol '__aeabi_memclr8' is already defined

warning: memcpy changed binding to STB_WEAK

error: symbol 'memcpy' is already defined

warning: __aeabi_memcpy changed binding to STB_WEAK

error: symbol '__aeabi_memcpy' is already defined

warning: __aeabi_memcpy8 changed binding to STB_WEAK

error: symbol '__aeabi_memcpy8' is already defined

warning: __aeabi_memset changed binding to STB_WEAK

error: symbol '__aeabi_memset' is already defined

warning: __aeabi_memset8 changed binding to STB_WEAK

error: symbol '__aeabi_memset8' is already defined

warning: __aeabi_memclr changed binding to STB_WEAK

error: symbol '__aeabi_memclr' is already defined

warning: __aeabi_memcpy4 changed binding to STB_WEAK

warning: __aeabi_memset4 changed binding to STB_WEAK

Title basically, wasn't sure if anyone else had checked/noticed yet.

I'm new around here, but just from a brief attempt at running cargo doc it seems to be caused by 5 warnings. One is related to SaveData::new which (I assume) would now be SaveManager::access. Similar situation with the remaining 4 after that, SaveAccess needs to be replaced (again, assuming) with SaveData.

Feel free to close this if another solution/documentation pass is already in the works but just wasn't finished yet for the release.

Steps to reproduce:

1. Clone repo master at 95721e2.
2. cd to template/
3. Run cargo build

Result:

user@computer:~/workspace/rust/agb-upgrade/template$ cargo build
    Updating crates.io index
   Compiling autocfg v1.1.0
   Compiling version_check v0.9.4
   Compiling proc-macro2 v1.0.69
   Compiling unicode-ident v1.0.12
   Compiling compiler_builtins v0.1.91
   Compiling core v0.0.0 (/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
   Compiling cfg-if v1.0.0
   Compiling crc32fast v1.3.2
   Compiling num-traits v0.2.17
   Compiling quote v1.0.33
   Compiling num-integer v0.1.45
   Compiling syn v2.0.38
   Compiling adler32 v1.2.0
   Compiling num-rational v0.3.2
   Compiling num-iter v0.1.43
   Compiling ahash v0.8.6
   Compiling proc-macro-error-attr v1.0.4
   Compiling byteorder v1.5.0
   Compiling deflate v0.8.6
   Compiling miniz_oxide v0.3.7
   Compiling proc-macro-error v1.0.4
   Compiling zerocopy v0.7.18
   Compiling bitflags v1.3.2
   Compiling adler v1.0.2
   Compiling once_cell v1.18.0
   Compiling miniz_oxide v0.7.1
   Compiling png v0.16.8
   Compiling bytemuck v1.14.0
   Compiling color_quant v1.1.0
   Compiling either v1.9.0
   Compiling itertools v0.11.0
   Compiling image v0.23.14
   Compiling flate2 v1.0.28
   Compiling rustc-std-workspace-core v1.99.0 (/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
   Compiling hashbrown v0.13.2
   Compiling log v0.4.20
   Compiling alloc v0.0.0 (/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc)
   Compiling ttf-parser v0.15.2
   Compiling nohash v0.2.0
   Compiling asefile v0.3.6
   Compiling fontdue v0.7.3
   Compiling rustc-hash v1.1.0
   Compiling arbitrary-int v1.2.6
   Compiling agb_macros v0.17.1
   Compiling bilge-impl v0.2.0
   Compiling agb v0.17.1
   Compiling hound v3.5.1
   Compiling agb_fixnum v0.17.1
   Compiling agb_sound_converter v0.17.1
   Compiling agb_image_converter v0.17.1
error[E0658]: use of unstable library feature 'build_hasher_simple_hash_one'
   --> /home/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/agb_image_converter-0.17.1/src/deduplicator.rs:113:36
    |
113 |             let tile_hash = hasher.hash_one(&tile);
    |                                    ^^^^^^^^
    |
    = note: see issue #86161 <https://github.com/rust-lang/rust/issues/86161> for more information
    = help: add `#![feature(build_hasher_simple_hash_one)]` to the crate attributes to enable

error[E0658]: use of unstable library feature 'build_hasher_simple_hash_one'
   --> /home/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/agb_image_converter-0.17.1/src/deduplicator.rs:114:40
    |
114 |             let vflipped_hash = hasher.hash_one(&vflipped);
    |                                        ^^^^^^^^
    |
    = note: see issue #86161 <https://github.com/rust-lang/rust/issues/86161> for more information
    = help: add `#![feature(build_hasher_simple_hash_one)]` to the crate attributes to enable

error[E0658]: use of unstable library feature 'build_hasher_simple_hash_one'
   --> /home/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/agb_image_converter-0.17.1/src/deduplicator.rs:115:40
    |
115 |             let hflipped_hash = hasher.hash_one(&hflipped);
    |                                        ^^^^^^^^
    |
    = note: see issue #86161 <https://github.com/rust-lang/rust/issues/86161> for more information
    = help: add `#![feature(build_hasher_simple_hash_one)]` to the crate attributes to enable

error[E0658]: use of unstable library feature 'build_hasher_simple_hash_one'
   --> /home/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/agb_image_converter-0.17.1/src/deduplicator.rs:116:41
    |
116 |             let vhflipped_hash = hasher.hash_one(&vhflipped);
    |                                         ^^^^^^^^
    |
    = note: see issue #86161 <https://github.com/rust-lang/rust/issues/86161> for more information
    = help: add `#![feature(build_hasher_simple_hash_one)]` to the crate attributes to enable

For more information about this error, try `rustc --explain E0658`.
error: could not compile `agb_image_converter` (lib) due to 4 previous errors
warning: build failed, waiting for other jobs to finish...

Operating System: Ubuntu 12
Kernel Version: 6.5.0-10-generic (64-bit)
Processors: 4 × Intel® Core™ i7-5500U CPU @ 2.40GHz
Memory: 7,5 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 5500

Last version I used of the library was 0.13.0, which compiled fine.

Will be useful in libraries (eg. The long project) that are independent of gba but can work with it. Vectors, fixed point, etc.

Create 2 mutexes, cause mutex 1 to be dropped.
Now have a mutex and interrupts are enabled.

I ran into this bug while porting some code from 8 to 16 and 24 bit precision Fixnum.
Dividing a Fixnum by a second Fixnum breaks when using 16 and 24 bit precision (some other precision values work, some break as well, I didn't test all the possible values).
This is specific to Fixnum / Fixnum and does not happen with Fixnum / i32.

Here is the test I ran:

let a: FixedNum<8> = num!(4.0);
let b: FixedNum<8> = num!(2.0);
let c: FixedNum<8> = num!(3.0);

agb::println!("8 bits");
agb::println!("A: {} B: {} C: {}", a, b, c);
agb::println!("A * B = {}", a * b);
agb::println!("A * C = {}", a * c);
agb::println!("A / B = {}", a / b);
agb::println!("A / C = {}", a / c);
agb::println!("A / B.floor() = {}", a / b.floor());
agb::println!("A / C.floor() = {}", a / c.floor());

let a: FixedNum<16> = num!(4.0);
let b: FixedNum<16> = num!(2.0);
let c: FixedNum<16> = num!(3.0);

agb::println!("16 bits");
agb::println!("A: {} B: {} C: {}", a, b, c);
agb::println!("A * B = {}", a * b);
agb::println!("A * C = {}", a * c);
agb::println!("A / B = {}", a / b);
agb::println!("A / C = {}", a / c);
agb::println!("A / B.floor() = {}", a / b.floor());
agb::println!("A / C.floor() = {}", a / c.floor());

let a: FixedNum<24> = num!(4.0);
let b: FixedNum<24> = num!(2.0);
let c: FixedNum<24> = num!(3.0);

agb::println!("24 bits");
agb::println!("A: {} B: {} C: {}", a, b, c);
agb::println!("A * B = {}", a * b);
agb::println!("A * C = {}", a * c);
agb::println!("A / B = {}", a / b);
agb::println!("A / C = {}", a / c);
agb::println!("A / B.floor() = {}", a / b.floor());
agb::println!("A / C.floor() = {}", a / c.floor());

This is the output:

8 bits
A: 4 B: 2 C: 3
A * B = 8
A * C = 12
A / B = 2
A / C = 1.33203125
A / B.floor() = 2
A / C.floor() = 1.33203125
16 bits
A: 4 B: 2 C: 3
A * B = 8
A * C = 12
A / B = 0
A / C = 0
A / B.floor() = 2
A / C.floor() = 1.3333282470703125
24 bits
A: 4 B: 2 C: 3
A * B = 8
A * C = 12
A / B = 0
A / C = 0
A / B.floor() = 2
A / C.floor() = 1.333333313465118408203125

1.0 List:

• Sane backgrounds - @gwilymk
• Dynamic background tiles - probably @gwilymk
• Commit for all display related things - @corwinkuiper and @gwilymk
• Remove the new interrupt handler - @corwinkuiper
• Dynamic sprite allocation - @corwinkuiper
• Different sound frequency options? - @gwilymk
• agb entry should accept a gba struct as its only argument to save the user having to create it - @gwilymk
• Dynamic allocator? - @gwilymk
• Start maintaining a changelog
• Go through every single public function API
  • Decide if it should be public / documented
  • Rename it if it isn't internally consistent or rust consistent
  • Document it

Not on the list for 1.0, but shouldn't break things:

• DMA - how to give access with sound dma being used elsewhere. Do we bother? Only give DMA3? - anyone
• Link cable - anyone
• Mod tracker support - @gwilymk
• Finish the book - @gwilymk

2.0 list:

• [ ]

Previous games are hard to compile the jam versions because we have changed a lot since then and didn't release something specifically for it. Should just be able to checkout the archived jam repo and compile it.

Think we should have a readme for each crate we have for.
The smaller ones, especially agb-entry, don't need to be very long.
If the readme is displayed externaly (eg: crates.io) then they should probably say it's for agb.

Maybe should discuss these in the main repo readme too?

Hey there! Trying to install mgba-test-runner by means the next command as written in README:

$ cargo install --path mgba-test-runner

As the result, I get the next error:

= note: ld: library not found for -lelf
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

I tried to find out an answer in a book, but there is nothing about installing elf.

Does anybody know how to solve this issue?

Discussed in #296

This appears to be a rustc bug. See: rust-lang/rust#100619

When compiling on nightly-2022-08-13 or later, the following happens:

+ cargo build --release --target thumbv4t-none-eabi
   Compiling the-purple-night v0.1.0 (/home/aino/data/projects/crates/agb/examples/the-purple-night)
error: linking with `arm-none-eabi-ld` failed: exit status: 1
  |
  = note: "arm-none-eabi-ld" "/tmp/rustconD6i5/symbols.o" "/home/aino/data/projects/crates/agb/target/thumbv4t-none-eabi/release/deps/the_purple_night-b8ba75b4faeb98b5.the_purple_night.62ef94b1-cgu.0.rcgu.o" "--as-needed" "-L" "/home/aino/data/projects/crates/agb/target/thumbv4t-none-eabi/release/deps" "-L" "/home/aino/data/projects/crates/agb/target/release/deps" "-L" "/home/aino/data/projects/crates/agb/target/thumbv4t-none-eabi/release/build/agb-5ac9222d9e5ae2ce/out" "-L" "/home/aino/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/thumbv4t-none-eabi/lib" "--start-group" "--end-group" "-Bstatic" "/home/aino/data/projects/crates/agb/target/thumbv4t-none-eabi/release/deps/libcompiler_builtins-3b5407e0191965f8.rlib" "-Bdynamic" "--eh-frame-hdr" "-znoexecstack" "-L" "/home/aino/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/thumbv4t-none-eabi/lib" "-o" "/home/aino/data/projects/crates/agb/target/thumbv4t-none-eabi/release/deps/the_purple_night-b8ba75b4faeb98b5" "--gc-sections" "-O1" "-Tgba.ld"
  = note: arm-none-eabi-ld: /home/aino/data/projects/crates/agb/target/thumbv4t-none-eabi/release/deps/libcompiler_builtins-3b5407e0191965f8.rlib(compiler_builtins-3b5407e0191965f8.compiler_builtins.01837706-cgu.0.rcgu.o): in function `compiler_builtins::mem::memmove':
          compiler_builtins.01837706-cgu.0:(.text._ZN17compiler_builtins3mem7memmove17h382c238f4a6131d3E+0x66): undefined reference to `__atomic_load_4'
          arm-none-eabi-ld: compiler_builtins.01837706-cgu.0:(.text._ZN17compiler_builtins3mem7memmove17h382c238f4a6131d3E+0xe8): undefined reference to `__atomic_load_4'
          
  = help: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
  = note: use the `-l` flag to specify native libraries to link
  = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)

error: could not compile `the-purple-night` due to previous error
error: Recipe `_build-rom` failed with exit code 101
error: Recipe `build-roms` failed on line 51 with exit code 101

Nothing seems to prevent the user from creating and using multiple (and conflicting versions) of the same peripheral.

From the documentation ("The video struct controls access to the video hardware. It ensures that only one video mode is active at a time.") and the presence of BlendDist/WindowDist structs I believe that this used to work, but has been broken on nightly (and in my testing, possibly stable too?) for some time.

#![no_std]
#![no_main]
#![cfg_attr(test, feature(custom_test_frameworks))]
#![cfg_attr(test, reexport_test_harness_main = "test_main")]
#![cfg_attr(test, test_runner(agb::test_runner::test_runner))]

use agb::syscall;

#[agb::entry]
fn main(mut gba: agb::Gba) -> ! {
    let mut bitmap = gba.display.video.bitmap3();
    let mut bitmap2 = gba.display.video.bitmap4();

    bitmap.draw_point(120, 80, 0x001F);
    bitmap2.draw_point(120, 80, 0);

    loop {
        syscall::halt();
    }
}

This seems to generate a 16 colours palette:

version = "1.0"

transparent_colour = "FF0066"

[image.background]
filename = "land.png"
tile_size = "8x8"
colours = 256

Hey! I Love the project and have been having a blast making little GBA games. I had some trouble getting logs at first but found I could view them in mgba via UI. But that was cumbersome. Then, after a while, I found I could add in .cargo/config.toml to what is below, set up the runner and it logs out to the console I run cargo run in. It is way better and beginner friendly and did not see this pointed out anywhere. What do y'all think about a PR to enable this by default or at least mentioning it in the readme? I have a PR ready to set it to default, but I saw y'all asked for an issue for discussion first.

[target.thumbv4t-none-eabi]
rustflags = ["-Clink-arg=-Tgba.ld", "-Ctarget-cpu=arm7tdmi"]
runner = ["mgba-qt", "-C", "logToStdout=1", "--log-level", "8"]

I'm trying to figure out how to use affine backgrounds and in the process of that I tried out the affine_background.rs example from the agb/agb/examples folder. I first cloned the template repo at 4a7c8437e2a4958d46fc95e3ac1e2a44e37b751b and then copied over affine_background.rs and the examples/water_tiles.png files. This compiled and ran, showing the following rendering:

However, I then changed line 18 from let (gfx, mut vram) = gba.display.video.tiled2(); to let (gfx, mut vram) = gba.display.video.tiled1(); and line 25 from let mut bg = gfx.background(Priority::P0, AffineBackgroundSize::Background32x32); to let mut bg = gfx.affine(Priority::P0, AffineBackgroundSize::Background32x32); and ran again. This surprisingly led to the following rendering:

Is this expected behavior? Does tiled1 and tiled2 handle palettes differently?

include_aseprite appears to miss some colours from the palette.

   = help: message: Can't get a colour index without it existing, looking for Colour { r: 238, g: 85, b: 49, a: 255 }, got [Colour { r: 255, g: 0, b: 255, a: 0 }, Colour { r: 65, g: 64, b: 68, a: 255 }, Colour { r: 228, g: 147, b: 116, a: 255 }, Colour { r: 57, g: 86, b: 67, a: 255 }, Colour { r: 102, g: 164, b: 145, a: 255 }, Colour { r: 127, g: 197, b: 175, a: 255 }, Colour { r: 84, g: 119, b: 96, a: 255 }, Colour { r: 202, g: 177, b: 150, a: 255 }, Colour { r: 124, g: 142, b: 255, a: 255 }, Colour { r: 255, g: 255, b: 255, a: 255 }, Colour { r: 255, g: 108, b: 73, a: 255 }, Colour { r: 228, g: 212, b: 187, a: 255 }, Colour { r: 0, g: 0, b: 0, a: 255 }]
   = note: this error originates in the macro `include_aseprite` (in Nightly builds, run with -Z macro-backtrace for more info)

Colour { r: 238, g: 85, b: 49, a: 255 } does exist in the palette at index 6, but doesn't get listed:

the list also only contains 13 colours, but the palette contains 17.

Would it be possible to add support for a MIDI sequencer and import (or bindings for the one built into the GBA's BIOS) in order to save on ROM space and CPU time?

I don't like how objects are shown in the top left even if you don't immediately give them a position. It's an insane default! Would break everything though. I constantly have objects flash in the top left for a frame, and I wrote this!

Probably worth mentioning that the reason it's shown by default is because the default 0 value is Normal sprite mode (as opposed to Affine, AffineDouble, and hidden). Clearly (to me) the default should be hidden.

This is very breaking!

I just cloned the template repo and ran cargo build, which failed with the following output:

$ cargo build
    Blocking waiting for file lock on build directory
    Blocking waiting for file lock on build directory
   Compiling static_assertions v1.1.0
   Compiling agb_fixnum v0.13.0
   Compiling bare-metal v1.0.0
   Compiling bitflags v1.3.2
   Compiling modular-bitfield v0.11.2
   Compiling rustc-hash v1.1.0
   Compiling agb v0.13.0
   Compiling agb_template v0.1.0 (/home/ola/workspace/rust/gba-test)
error: linking with `rust-lld` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/home/ola/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:[redacted]" VSLANG="1033" "rust-lld" "-flavor" "gnu" "/tmp/rustck8NFtf/symbols.o" "/home/ola/workspace/rust/gba-test/target/thumbv4t-none-eabi/debug/deps/agb_template-c3ddefb80895f55b.3s7n5y0b26xixcjj.rcgu.o" "/home/ola/workspace/rust/gba-test/target/thumbv4t-none-eabi/debug/deps/agb_template-c3ddefb80895f55b.5dl3x2lc62831ojw.rcgu.o" "/home/ola/workspace/rust/gba-test/target/thumbv4t-none-eabi/debug/deps/agb_template-c3ddefb80895f55b.wxt0yv8hr1usa6m.rcgu.o" "/home/ola/workspace/rust/gba-test/target/thumbv4t-none-eabi/debug/deps/agb_template-c3ddefb80895f55b.2nsj30ru3u47jmv9.rcgu.o" "--as-needed" "-L" "/home/ola/workspace/rust/gba-test/target/thumbv4t-none-eabi/debug/deps" "-L" "/home/ola/workspace/rust/gba-test/target/debug/deps" "-L" "/home/ola/workspace/rust/gba-test/target/thumbv4t-none-eabi/debug/build/agb-3d648a867a903604/out" "-L" "/home/ola/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/thumbv4t-none-eabi/lib" "-Bstatic" "/home/ola/workspace/rust/gba-test/target/thumbv4t-none-eabi/debug/deps/libagb-5853c62502597fc0.rlib" "/home/ola/workspace/rust/gba-test/target/thumbv4t-none-eabi/debug/deps/librustc_hash-147cb32e4252cc4a.rlib" "/home/ola/workspace/rust/gba-test/target/thumbv4t-none-eabi/debug/deps/libagb_fixnum-284de78f06c09a67.rlib" "/home/ola/workspace/rust/gba-test/target/thumbv4t-none-eabi/debug/deps/libmodular_bitfield-b103e43816e60c59.rlib" "/home/ola/workspace/rust/gba-test/target/thumbv4t-none-eabi/debug/deps/libstatic_assertions-8105e70dd6bfac25.rlib" "/home/ola/workspace/rust/gba-test/target/thumbv4t-none-eabi/debug/deps/libbitflags-bd9809da6ece37c5.rlib" "/home/ola/workspace/rust/gba-test/target/thumbv4t-none-eabi/debug/deps/libbare_metal-2e56136f22cdc20b.rlib" "/home/ola/workspace/rust/gba-test/target/thumbv4t-none-eabi/debug/deps/liballoc-c70275d345cd94f6.rlib" "/home/ola/workspace/rust/gba-test/target/thumbv4t-none-eabi/debug/deps/librustc_std_workspace_core-1c1de9d4e5303440.rlib" "/home/ola/workspace/rust/gba-test/target/thumbv4t-none-eabi/debug/deps/libcore-c73038591cd58e9b.rlib" "/home/ola/workspace/rust/gba-test/target/thumbv4t-none-eabi/debug/deps/libcompiler_builtins-3e37334e6fec237e.rlib" "-Bdynamic" "--eh-frame-hdr" "-z" "noexecstack" "-L" "/home/ola/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/thumbv4t-none-eabi/lib" "-o" "/home/ola/workspace/rust/gba-test/target/thumbv4t-none-eabi/debug/deps/agb_template-c3ddefb80895f55b" "--gc-sections" "-O1" "-Tgba.ld"
  = note: rust-lld: error: discarding .shstrtab section is not allowed
          

error: could not compile `agb_template` (bin "agb_template") due to previous error

Tool versions:

$ cargo --version
cargo 1.70.0-nightly (0e474cfd7 2023-03-31)
$ rustup --version
rustup 1.25.2 (17db695f1 2023-02-01)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.70.0-nightly (23ee2af2f 2023-04-07)`

Commit hash for the template repo is 9231b93c837bbe7f5e549a35a94409447edfdb1c.

Hey there!

Looks like setting volume to 0 doesn't actually mute audio, just makes it quieter and hissy?
Is this a bug, or some fundamental issue with gba sound?

Thanks.

In below code for me in mgba, audio still can be heard at 0 volume.

#![no_std]
#![no_main]

use core::cmp::max;
use core::num;

use agb::fixnum::Num;
use agb::input::{Button, ButtonController, Tri};
use agb::println;
use agb::sound::mixer::{Frequency, SoundChannel};
use agb::{fixnum::num, include_wav, Gba};

// Music - "Dead Code" by Josh Woodward, free download at http://joshwoodward.com
const DEAD_CODE: &[u8] = include_wav!("examples/JoshWoodward-DeadCode.wav");

#[agb::entry]
fn main(mut gba: Gba) -> ! {
    let mut input = ButtonController::new();
    let vblank_provider = agb::interrupt::VBlank::get();

    let mut mixer = gba.mixer.mixer(Frequency::Hz10512);
    mixer.enable();

    let mut channel = SoundChannel::new(DEAD_CODE);
    channel.should_loop();
    let channel_id = mixer.play_sound(channel).unwrap();
    let mut vol = num!(0.);
    loop {
        input.update();

        let channel = mixer.channel(&channel_id).unwrap();

        if input.is_just_pressed(Button::A) {
            agb::println!("{} volume", vol);
            vol += num!(0.1);
        }
        if input.is_just_pressed(Button::B) {
            agb::println!("{} volume", vol);
            vol = max(vol - num!(0.1), num!(0.));
        }
        channel.volume(vol);
        mixer.frame();
        vblank_provider.wait_for_vblank();
        mixer.after_vblank();
    }
}

The trait should possibly be renamed.

Currently fails ci due to rustc regression, JSON needs updating and later use the in built one that currently cannot be used, see rust-lang/rust#100641

Should get this working at some point. Currently, it complains that it doesn't have rust-src.
Can always do what gba-console does and use a different target for docs.rs.

The map system is good if you want a managed map that infinitely scrolls
It's not good for HUD.
In the cases of HUD, just let the user write what they want to the actual screen space memory in a safe way (as in manage handing an unused screen to the user and manage a lot of the other parts of a background for them).

The main 1.0 project is the book. Might want to outline chapters / topics to cover to see what's interesting to cover for the book.
Want to start this sooner rather than later so that APIs can change if (read: when) we think they're rubbish.

Could also use the project tab for this?

Nightly releases contain some bugs that mean agb doesn't compile.

• rust-lang/rust#108893
• rust-lang/rust#109730
• rust-lang/rust#111225
• rust-lang/rust#111320

We will keep track of these failures. If you are using a released agb version, instead you can use the nightly version as of the day it was released. If you're using master, we will mitigate issues where possible, check the nightly action build for the most recent working nightly build.

In order to use a different Rust version, you can change the version in the rust-toolchain.toml file to explicitly state the nightly version, for example

[toolchain]
channel = "nightly-2023-05-04"

If in test mode, it calls agb::test_runner::agb_start_tests. Two issues:

• I can define something called agb myself and break this.
• test_runner is only defined with the testing feature (in test mode dependencies are not compiled in test mode), so this macro fails to work with rust analyzer on projects that don't use the testing feature (eg. Hyperspace Roll) as rust analyzer does use test.

A const is compiler pasted, therefore multiple uses of one const could cause the data to be duplicated in the ROM. A static avoids this issue. Therefore we should use statics rather than consts for music, sprites, background data, etc.

Very breaking change.

Bitmap modes give access to vram, where allocators store state. This is bad.

Also, I don't think objects can be used in bitmap modes, and besides they share vram so allocation gets clobbered.

The fix:

• Initialise allocators on acquiring the resource.
• Objects and backgrounds come together, I think.

The current difficulty:

• I've used sprite allocation without resource acquisition a lot. Can be fixed but will make things more awkward.

It's a small detail I guess, but it's UB for non-rust to call rust ABI functions.

I think I'm following the setup instructions correctly but:

...
just _fmt-check tools
(cd "tools" && cargo fmt --all -- --check)
just _test-debug agb
just _build-debug agb
(cd "agb" && cargo build --examples --tests)
    Finished dev [optimized + debuginfo] target(s) in 0.07s
(cd "agb" && cargo test)
    Finished test [optimized + debuginfo] target(s) in 0.04s
     Running unittests src/lib.rs (/home/ers/projects/agb/target/thumbv4t-none-eabi/debug/deps/agb-8160f244a446c0d7)
error: test failed, to rerun pass `--lib`

Caused by:
  could not execute process `mgba-test-runner /home/ers/projects/agb/target/thumbv4t-none-eabi/debug/deps/agb-8160f244a446c0d7` (never executed)

Caused by:
  No such file or directory (os error 2)
error: Recipe `_test-debug` failed on line 145 with exit code 101
error: Recipe `test` failed on line 17 with exit code 101

Same result on nightly and stable:

include_background_gfx!(
    backgrounds,
    title => 256 "gfx/example.png"
);

results in

// ...
const PALETTE_ASSIGNMENT: &[u8] = &[];
// ...

Apologies if I've just missed something out that's causing this, I don't understand macros too well. Leaving it to the default 16 seems to work fine (title => "gfx/example.png")

This is on version 0.15.0

I've attached the image I've used (it's just a grey square, 240x160)

Example:

let a: Num<i32, 8> = num!(-1.0);
let b: Num<i32, 8> = num!(-0.5);
let c: Num<i32, 8> = num!(0.5);
let d: Num<i32, 8> = num!(1.0);
println!("{} {} {} {}", a, b, c, d);

In mGBA:

[INFO] GBA Debug:	-1 0.5 0.5 1

(Originally, I thought I'd found an issue with Num::cos() while debugging, but I eventually realized it was an issue with fmt().)

Anyway, thanks for the cool project! I plan to submit a fix shortly.

For a game library, to me it has a bit too complex license:/ First time for me to see MPL version 2.0, I am mostly used to MIT. Please clear this up:

If I don't make changes to agb is it possible to distribute closed-sourced gba file? Without distributing the full source code of the game.
And if some changes to agb are made, then those has to be published as a public source code, but the gba blob file still do not have to be distributed with public source code.

I think personally that MPL makes much more sense with dynamic libraries, with singular gba file, or even worse gba cart its not clear...

Hi, I've been using Nvim (AstroNvim + Treesitter + LSP) with agb and noticed that my lsp doesn't work properly if i have:

...
#[agb::entry]
fn main(mut gba: Gba) -> ! {
...

Instead I've added this to Cargo.toml

[features]
default = ["entry"]
entry = []

and now my main function looks like this:

...
#[cfg_attr(feature = "entry", agb::entry)]
fn main(mut gba: Gba) -> ! {
...

and with that I have LSP as usual and i am able to cargo run | build --release and it works.

is there a way to do this auto-magically?

I've been trying to build for release but only debug builds are passing. When I try to use --release I see this as ouput:
ERRATA: I've been trying the same with agb/examples/... and get the same output.

   Compiling game v0.1.0 (/home/rootster/Documents/gba-rust-game)
warning: memcpy changed binding to STB_WEAK

error: symbol 'memcpy' is already defined

warning: memset changed binding to STB_WEAK

error: symbol 'memset' is already defined

warning: __aeabi_memclr8 changed binding to STB_WEAK

error: symbol '__aeabi_memclr8' is already defined

warning: __aeabi_memcpy changed binding to STB_WEAK

error: symbol '__aeabi_memcpy' is already defined

warning: __aeabi_memcpy8 changed binding to STB_WEAK

error: symbol '__aeabi_memcpy8' is already defined

warning: __aeabi_memset8 changed binding to STB_WEAK

error: symbol '__aeabi_memset8' is already defined

warning: __aeabi_memclr4 changed binding to STB_WEAK

error: symbol '__aeabi_memclr4' is already defined

warning: __aeabi_memset changed binding to STB_WEAK

error: symbol '__aeabi_memset' is already defined

warning: __aeabi_memclr changed binding to STB_WEAK

error: symbol '__aeabi_memclr' is already defined

warning: __aeabi_memcpy4 changed binding to STB_WEAK

warning: __aeabi_memset4 changed binding to STB_WEAK

warning: `game` (bin "game") generated 11 warnings
error: could not compile `game` (bin "game") due to 9 previous errors; 11 warnings emitted

Anybody know why?

Os: Linux (Arch)
rustc 1.76.0-nightly (0e2dac837 2023-12-04)

I've only found tiled0, bitmap3 and bitmap4 in the documentation.

When building with latest nightly, you may see

error[E0635]: unknown feature `stdsimd`

   |
99 | #![cfg_attr(feature = "stdsimd", feature(stdsimd))]
   |

Is due to: tkaitchuck/aHash#200 which looks like it'll be resolved soon

if there's a repository entry, the docs.rs documentation will provide a link back to this github repo.

An interrupt that refers to local stuff can be forgotten and it will still run and refer to now non existant local stuff.

Use after free.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency @types/node to v20.14.14
• Update dependency eslint to v9

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• Update Rust crate image to 0.25
• Update Rust crate rustc-hash to v2

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

For some reason, Vector2D requires a long list of traits to be used, meaning it doesn't work for integers or custom types. Instead, I think each trait implementation should only require the traits it needs, like this:

impl<T: Add<Output = T>> Add<Vector2D<T>> for Vector2D<T> {
	type Output = Vector2D<T>;
	fn add(self, rhs: Vector2D<T>) -> Self::Output {
		Vector2D {
			x: self.x + rhs.x,
			y: self.y + rhs.y,
		}
	}
}

impl<T: AddAssign> AddAssign<Self> for Vector2D<T> {
	fn add_assign(&mut self, rhs: Self) {
		self.x += rhs.x;
		self.y += rhs.y;
	}
}

Not something I think we should bother with, they were added at the start to get going, but I don't think we have a use case here.

After upgrading the rust compiler to the latest nightly as per instructions in #510 , I tried to compile the template project again and got a new error:

user@computer:~/workspace/rust/agb-upgrade/template$ cargo clean
     Removed 496 files, 367.4MiB total
user@computer:~/workspace/rust/agb-upgrade/template$ cargo build
   Compiling autocfg v1.1.0
   Compiling version_check v0.9.4
   Compiling proc-macro2 v1.0.69
   Compiling compiler_builtins v0.1.101
   Compiling unicode-ident v1.0.12
   Compiling core v0.0.0 (/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
   Compiling cfg-if v1.0.0
   Compiling num-traits v0.2.17
   Compiling num-integer v0.1.45
   Compiling crc32fast v1.3.2
   Compiling quote v1.0.33
   Compiling syn v2.0.38
   Compiling adler32 v1.2.0
   Compiling num-iter v0.1.43
   Compiling num-rational v0.3.2
   Compiling proc-macro-error-attr v1.0.4
   Compiling ahash v0.8.6
   Compiling byteorder v1.5.0
   Compiling deflate v0.8.6
   Compiling miniz_oxide v0.3.7
   Compiling proc-macro-error v1.0.4
   Compiling bitflags v1.3.2
   Compiling zerocopy v0.7.18
   Compiling adler v1.0.2
   Compiling once_cell v1.18.0
   Compiling miniz_oxide v0.7.1
   Compiling png v0.16.8
   Compiling either v1.9.0
   Compiling bytemuck v1.14.0
   Compiling color_quant v1.1.0
   Compiling image v0.23.14
   Compiling itertools v0.11.0
   Compiling flate2 v1.0.28
   Compiling hashbrown v0.13.2
   Compiling ttf-parser v0.15.2
   Compiling log v0.4.20
   Compiling nohash v0.2.0
   Compiling asefile v0.3.6
   Compiling bilge-impl v0.2.0
   Compiling rustc-std-workspace-core v1.99.0 (/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
   Compiling alloc v0.0.0 (/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc)
   Compiling agb_macros v0.17.1
   Compiling fontdue v0.7.3
   Compiling hound v3.5.1
   Compiling agb v0.17.1
   Compiling agb_image_converter v0.17.1
   Compiling agb_sound_converter v0.17.1
   Compiling arbitrary-int v1.2.6
   Compiling rustc-hash v1.1.0
   Compiling agb_hashmap v0.17.1
   Compiling bilge v0.2.0
   Compiling bare-metal v1.0.0
   Compiling agb_fixnum v0.17.1
   Compiling bitflags v2.4.1
   Compiling agb_template v0.1.0 (/home/user/workspace/rust/agb-upgrade/template)
error: linking with `rust-lld` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:..." VSLANG="1033" "rust-lld" "-flavor" "gnu" "/tmp/rustcMkCwiK/symbols.o" "/home/user/workspace/rust/agb-upgrade/template/target/thumbv4t-none-eabi/debug/deps/agb_template-cf765e6b5b522ef3.eexwh9us7hycapc.rcgu.o" "/home/user/workspace/rust/agb-upgrade/template/target/thumbv4t-none-eabi/debug/deps/agb_template-cf765e6b5b522ef3.4rs8bl3kk9mhgw4y.rcgu.o" "--as-needed" "-L" "/home/user/workspace/rust/agb-upgrade/template/target/thumbv4t-none-eabi/debug/deps" "-L" "/home/user/workspace/rust/agb-upgrade/template/target/debug/deps" "-L" "/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/thumbv4t-none-eabi/lib" "-Bstatic" "/home/user/workspace/rust/agb-upgrade/template/target/thumbv4t-none-eabi/debug/deps/libagb-d1c13f189e82b0a1.rlib" "/home/user/workspace/rust/agb-upgrade/template/target/thumbv4t-none-eabi/debug/deps/libagb_hashmap-25c93ac22a2fa653.rlib" "/home/user/workspace/rust/agb-upgrade/template/target/thumbv4t-none-eabi/debug/deps/librustc_hash-10432759800aeffa.rlib" "/home/user/workspace/rust/agb-upgrade/template/target/thumbv4t-none-eabi/debug/deps/libagb_fixnum-371963521602ed3b.rlib" "/home/user/workspace/rust/agb-upgrade/template/target/thumbv4t-none-eabi/debug/deps/libbitflags-a2542ca9b809883f.rlib" "/home/user/workspace/rust/agb-upgrade/template/target/thumbv4t-none-eabi/debug/deps/libbilge-4df4e0475682a325.rlib" "/home/user/workspace/rust/agb-upgrade/template/target/thumbv4t-none-eabi/debug/deps/libarbitrary_int-449ad486286196a3.rlib" "/home/user/workspace/rust/agb-upgrade/template/target/thumbv4t-none-eabi/debug/deps/libbare_metal-23c419b1a9cce4a6.rlib" "/home/user/workspace/rust/agb-upgrade/template/target/thumbv4t-none-eabi/debug/deps/liballoc-869a4f3baa3b7e8b.rlib" "/home/user/workspace/rust/agb-upgrade/template/target/thumbv4t-none-eabi/debug/deps/librustc_std_workspace_core-b2e480bf307b1459.rlib" "/home/user/workspace/rust/agb-upgrade/template/target/thumbv4t-none-eabi/debug/deps/libcore-c7174505d708ec52.rlib" "/home/user/workspace/rust/agb-upgrade/template/target/thumbv4t-none-eabi/debug/deps/libcompiler_builtins-2dcd1eb3a5ce4f75.rlib" "-Bdynamic" "--eh-frame-hdr" "-z" "noexecstack" "-L" "/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/thumbv4t-none-eabi/lib" "-o" "/home/user/workspace/rust/agb-upgrade/template/target/thumbv4t-none-eabi/debug/deps/agb_template-cf765e6b5b522ef3" "--gc-sections" "-O1" "-Tgba.ld"
  = note: rust-lld: error: cannot find linker script gba.ld
          

error: could not compile `agb_template` (bin "agb_template") due to previous error

https://github.com/pksunkara/cargo-workspaces

The implementation of cosine used in the agb_fixnum crate has a bug. This line uses an integer division (9/40), which always evaluates to zero, making that line a no-op.

Looking at the referenced algorithm, this should read (Self::new(1) / 40). However, unfortunately that actually breaks the accuracy of the algorithm. For example:

let one_on_32 = Num<i32, 16>::new(1) / 32;
println!("{:?}", one_on_32.cos());

shows a result of around 0.7559, where it should be about 0.9808. Omitting the last line of the algorithm gives a much more accurate result in this case, and in other cases the errors are much much worse.

I think I've identified this as a bug in the multiplication code. I'm not exactly sure of the bug, but here's a more precise example (numerically close to where this manifests for (1/32).cos():

type Nm = Num::<i32, 16>;
let a = Nm::new(-15) / 1000;  // c. -0.015
let b = Nm::new(49) / 50; // c. 0.98
assert_eq!((a * b).to_raw(), 0b1111111111111110_1111110000111100);  // c. -1.0147

The result is close to the desired result of -0.0147, but with an extra -1 in the integer part.

I'm pretty noobish when it comes to linker scripts, but there are a couple of things that concern me about the one currently in the template directory.

1. I see nothing about stacks. From GBATek, I understand that there is the "user stack" (for when the CPU is in system mode) at 0x03007f00 in iwram, and the IRQ stack (for when the CPU is in IRQ mode) from 0x03007fa0 to 0x03007f00.
2. Further the BIOS expects all of 0x03007f00 to the end of iwram to be reserved for its usage
3. I don't see where BSS is zeroed out anywhere, is the BIOS guaranteed to zero out iwram for us?

Again, I don't fully understand linker scripts, but shouldn't there be some way of "reserving" iwram space for this? Clearly any custom iwram allocator would have to avoid the bottom of IWRAM, but also don't we need to tell the linker not to put anything from .bss there?

I'm a little confused about include_gfx and include_aseprite. I'd like to create a mod the same way include_gfx does, but with a aseprite file.

Is it possible?