This list may change as more information is gathered.

Misc:

• Internal ROM header
• SNES↔PC address conversions
• ASM code
• Objects

Graphics:

• Level palettes
• Overworld palettes
• Tiles
• GFX files

Levels:

• Primary header
• Secondary header
• Layer 1
• Layer 2
• Backgrounds
• Sprites
• Entrances

Overworld:

• Layer 1
• Layer 1 events
• Layer 2
• Layer 2 events
• Sprites
• Silent events
• Warps
• Paths

Audio:

• SFX
• Samples
• Music

I am so sorry that I can't figure this out myself. No matter which smw rom I use (even if it is a verified clean ROMs) anytime I run the program, I just get the flowing errors. I am really sorry to bother with this, probably simple issue. I just feel stuck after trying everything I can think of.
2024-04-08T23:22:40.809797700-04:00 INFO smw_editor - Opening ROM from path defined in ROM_PATH
2024-04-08T23:22:40.814219-04:00 INFO smwe_rom - Reading ROM from file: C:\Users*****\source\repos\smw-editor\smwe-rom\roms\Super_Mario_World\Super_Mario_World.smc
2024-04-08T23:22:40.816262100-04:00 INFO smwe_rom - Parsing internal ROM header
2024-04-08T23:22:40.819434100-04:00 INFO smwe_rom::internal_header - Internal ROM header found at LoROM location: PC 0x7FC0
2024-04-08T23:22:40.819924700-04:00 INFO smwe_rom - Creating disassembly map
2024-04-08T23:22:40.822067300-04:00 WARN smwe_rom::disassembler - Wrong address of next target: SNES $7F8000
2024-04-08T23:22:40.822385900-04:00 WARN smwe_rom::disassembler - Wrong address of next target: SNES $7F8000
2024-04-08T23:22:40.822544600-04:00 WARN smwe_rom::disassembler - Wrong address of next target: SNES $7F8000
2024-04-08T23:22:40.822961500-04:00 WARN smwe_rom::disassembler - Wrong address of next target: SNES $7F8000
2024-04-08T23:22:40.823579300-04:00 WARN smwe_rom::disassembler - Wrong address of next target: SNES $7F8000
2024-04-08T23:22:40.826311100-04:00 WARN smwe_rom::disassembler - Wrong address of next target: SNES $7F8000
2024-04-08T23:22:40.828407500-04:00 WARN smwe_rom::disassembler - Wrong address of next target: SNES $7F8000
2024-04-08T23:22:40.829899900-04:00 WARN smwe_rom::disassembler - Wrong address of next target: SNES $7F8000
2024-04-08T23:22:40.831377800-04:00 WARN smwe_rom::disassembler - Wrong address of next target: SNES $7F8000
2024-04-08T23:22:40.831535800-04:00 WARN smwe_rom::disassembler - Wrong address of next target: SNES $7F8000
2024-04-08T23:22:40.837583300-04:00 WARN smwe_rom::disassembler - Wrong address of next target: SNES $7F812E
2024-04-08T23:22:40.872398100-04:00 WARN smwe_rom::disassembler - Wrong address of next target: SNES $7F8000
2024-04-08T23:22:40.885176900-04:00 ERROR smwe_rom::disassembler::processor - Stack underflow at 0x1589A [-> SNES $2D89A] (DisplayInstruction(Instruction { offset: AddrPc(0x1589A) [-> SNES $2D89A], opcode: Opcode { mnemonic: PLP, mode: Implied }, m_flag: true, x_flag: true, operands: [0, 0, 0, 0] }))
2024-04-08T23:22:40.904281400-04:00 INFO smwe_rom - Parsing level data
2024-04-08T23:22:41.176442500-04:00 INFO smwe_rom - Parsing secondary entrances
2024-04-08T23:22:41.177779900-04:00 INFO smwe_rom - Parsing GFX files
2024-04-08T23:22:41.206679700-04:00 INFO smwe_rom - Parsing Map16 tilesets
2024-04-08T23:22:41.210592400-04:00 INFO smwe_rom - Success parsing ROM
error: process didn't exit successfully: target\release\smw-editor.exe (exit code: 0xc0000374, STATUS_HEAP_CORRUPTION)

Also this is a very cool project. I don't have very much experience with anything like this, but if there are any simple boring tasks, I would love to help out with a project like this!
Thanks!

A friend and I wanted to start a smw editor in rust with egui until we bumped into this more progressed project destroying our plans 😅

There are some issues that got my attention in the LZ2 decompression code:

Repeat command implementation

A look in the assembly of the Repeat command (at the address 00B966) (stolen from https://github.com/IsoFrieze/SMWDisX)

    JSR ReadByte
    XBA
    JSR ReadByte
 if ver_has_rev_gfx(!_VER)                    ;\==================== J & E1 ===================
    XBA                                       ;! ThinkingFace
 endif                                        ;/===============================================
    TAX
LOOP:
    PHY
    TXY
    LDA.B [_TMP],Y
    TYX
    PLY
    STA.B [_TMP],Y
    INY
    INX
    REP #$20                                  ; A->16
    DEC.B GraphicsUncompPtr
    SEP #$20                                  ; A->8
    BNE LOOP
    JMP NEXT_COMMAND

reveals the behaviour of this routine to always copy length bytes (length is stored in the Y register).
So if our currently compressed data would be for example [1, 2, 3, 4] and we got a
repeat command to copy 6 bytes starting from address 2 your code would result in
[1, 2, 3, 4, 3, 4, 0, 0]
But the assembly would do following steps:

1. [1, 2, 3, 4, 3]
2. [1, 2, 3, 4, 3, 4]
3. [1, 2, 3, 4, 3, 4, 3]
4. [1, 2, 3, 4, 3, 4, 3, 4]

I wrote a small test to check for this behaviour

#[test]
fn test_slice_repeat() {
    let compressed = [
        // Insert [1, 2, 3, 4]
        (0b011 << 5) | (4 - 1),
        1,
        // Repeat 7 bytes from address 1
        (0b100 << 5) | (7 - 1),
        0,
        1,
    ];
    let res = super::decompress(&compressed);
    const EXPECTED: &'static [u8] = &[1, 2, 3, 4, 2, 3, 4, 2, 3, 4, 2];
    match res.as_ref().map(Vec::as_slice) {
        Err(err) => panic!("decompression failed unexpectedly ({err})"),
        Ok(EXPECTED) => (),
        Ok(res) => panic!("decompression gave wrong results (got: {res:?}, expected: {EXPECTED:?})"),
    }
}

thread 'compression::lc_lz2::tests::test_slice_repeat' panicked at
'decompression gave wrong results (got: [1, 2, 3, 4, 2, 3, 4, 0, 0, 0, 0],
expected: [1, 2, 3, 4, 2, 3, 4, 2, 3, 4, 2])', smwe_rom/src/compression/lc_lz2.rs

I also decompressed the original rom data with your code and a (maybe buggy) "fixed" version of your code and got 613 bytes differing in the result, so this actually changes something!

Endianness

The disassembly from SMWDisX also shows different endianness in the repeat command. While your implementation does big endian and thus supports the U version, but at least the J & E1 versions (if I correctly interpret the assembly) do little endian, so this wouldn't work.

All following will never occur on the original ROM,
so it is up to you to decide if these are bugs

Multiple possible values for the Repeat command

Technically the assembly (see disassembly code starting from address 00B8FF) will only check
for the MSB in the command to be 1, so the commands 101, 110, 111 would also address the repeat command in the original ROM (e.g. 11111100 00000000 would be a (long) repeat command with length = 1).

16-bit overflow

Technically the output data could be larger than 2^16 bytes, but in the SNES it is addressed by 16-bit and an 16-bit overflow in the output buffer would result in overwriting values from its beginning. This would also require a different handling of the Repeat command.

However, I am not sure if a 16-bit overflow (which could only occur in a hacked version of the game) in the output buffer would break the game anyway, making 16-bit overflow handling obsolete.

A few weeks ago I discovered this project and wanted to get involved. I both attempted to message this Discord ID and email the address from the readme, but ran into the following issues:

1. The Discord user doesn't accept messages from people not in the server, so Clyde auto-blocked me.
2. The email seems to be invalid, as the mail system it's a part of autoreplied saying that the email doesn't exist in the system.

As neither of the ways of contact expressed are usable, I am creating an issue proposing that a discord server or some equivalent system of communication is implemented, as there is at present little information available about this project, what has been completed, its design goals, or anything else, really.

Personally I have experience with UI design and wish to learn Rust, and I was contacted by someone on Twitter earlier who also expressed an interest in assisting with this project after I directed them here. They found a post of mine on the SMWCentral forums and messaged me on Twitter before finding this project because there is very little footprint. I and many others would be happy to help, we just need direction, and communication is vital for that.

Hey, stumbled upon this, seeing as it's fairly new, and wanted to ask some questions! So, uh:

1. What operating systems will you be building for?
2. What all are you planning for this?
3. On how big of a scale will this be?
4. What all is currently implemented?

I use Linux, and was frustrated at the lack of a native alternative to Lunar Magic, and my search led me here, looking around for anything remotely close to it. Anyways, thanks in advance!

Description

When I open SMWE, create a new project, open Tools -> 16x16 tiles, click + on level number until it's 0060 and click + again, it creates a panic like this:

thread 'main' panicked at smwe-rom\src\graphics\mod.rs:110:82:
called `Result::unwrap()` on an `Err` value: TileFromWramError(AddrSnes(0x7EB440))
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `target\debug\smw-editor.exe` (exit code: 101)

Screen recording