Talk:Tile compression

Citing external sources for format details

On 2016-05-02, Bisqwit made this edit to "Spell out the format. Depending on external links for textual content is bad wiki practice." But I seem to remember about a year earlier, when I was making these edits about LZSS as used in GBA/DS BIOS, that someone was confused about the scope of this page, whether I was making a complete format reference or not, especially for formats not used on NES. This "someone" may have been on forums.nesdev.org or in #nesdev on EFnet; I don't remember exactly. --Tepples (talk) 07:24, 4 May 2016 (MDT)

I think it was me, and I believe my confusion was that comprehending the stuff on the wiki page depended on information behind the link (which already fully described it), which I felt made the wiki material either useless or redundant (depending on whether you'd read the linked page). I believe I was in favour of just linking it with a brief summary instead, but revising it to have fully formed ideas was an acceptable alternative. - Rainwarrior (talk) 12:21, 4 May 2016 (MDT)

Non-NES compression algorithms

Details about compression used in commercial games for another platform other than NES has nothing to do there, in my opinion. Only designs which are useful for either homebrew development or romhacking existing games or using them as inspiration for homebrew is useful. 178.196.73.155 14:25, 20 August 2016 (MDT)

Why would explaining how a compression format for another CPU of comparable computational ability not belong here? We're not describing LZMA. —Lidnariq (talk) 18:12, 20 August 2016 (MDT)

Compression formats are separated from the CPU encoding or decoding them, so there is no problem describing any format. However, explaining the details how a particular game compress its data do, in my opinion, not belong here, but to the data crystal romhacking wiki.

Bregalad (talk) 13:31, 22 August 2016 (MDT)

I should think that the note about GBA/DS video memory doesn't really belong here, because it is not applicable to NES/Famicom, even if the same format may be used. --Zzo38 (talk) 16:22, 22 August 2016 (MDT)

NES Stripe Image RLE

Do games use NES Stripe Image RLE to update CHR RAM? If so, how do they distinguish $0000-$00FF (tiles 0-15 of the first pattern table) from an end marker? Do they use the mirror at $4000-$40FF? --Tepples (talk) 15:07, 4 September 2016 (MDT)

The End Marker in the NES version is zero because that is the simplest approach to do it in 6502, using $FF would require a gigantic hack, and even then there is no DMA except for sprites on NES, so you may have to rewrite the Stripe Image Uploader to use the $FF value

The SNES version uses the 65816, and it is more complex than the 6502, but comes from the same family, just 16-bit.

The Stripe Image Uploader only goes to VRAM $0000-$3FFF on NES, unless you want glitching.

The only time CHR-RAM is rendered from the Stripe Image Format is during the ending of Doki Doki Panic (FDS).

Super Mario Bros 2 (USA) replaces that with OAM animation instead since it is using CHR-ROM, And is easier to implent with CHR-RAM being not an option.

--Hamtaro126 (talk) 04:08, 5 September 2016 (MDT)

Or simply put, Make a NES test ROM for CA65, CHR contents can be...

.dbyt $1000 ;Address of CHR RAM 
.byte $10   ;Length is 16, or 1 tile
.word %0011110000000000
.word %0101101000100100
.word %1111111100100100
.word %1111111100000000
.word %1111111100000000
.word %1100001100111100
.word %0111111000011000
.word %0011110000000000
.byte $00 ;end of tile

--Hamtaro126 (talk) 04:18, 5 September 2016 (MDT)

Given that VRAM addresses range from $0000 to $3FFF, I don't see how it'd be a "gigantic hack" for a decoder to use bpl instead of bne to tell the difference between the high byte of a VRAM address and the $FF terminator. --Tepples (talk) 09:25, 5 September 2016 (MDT)