NES Screen Tool

A place for your artistic side. Discuss techniques and tools for pixel art on the NES, GBC, or similar platforms.

Moderator: Moderators

Diskover
Posts: 213
Joined: Thu Nov 24, 2011 7:16 am
Contact:

Re: NES Screen Tool

Post by Diskover » Wed Nov 23, 2016 7:47 am

na_th_an wrote:Are you using RLE? Maybe the problem is in the vram_unrle function?
Both Shiru and dougeff, which are practically the same.

Code: Select all

_UnRLE:
	tay
	stx <RLE_HIGH
	lda #0
	sta <RLE_LOW

	lda (RLE_LOW),y
	sta <RLE_TAG
	iny
	bne @1
	inc <RLE_HIGH
@1:
	lda (RLE_LOW),y
	iny
	bne @11
	inc <RLE_HIGH
@11:
	cmp <RLE_TAG
	beq @2
	sta $2007
	sta <RLE_BYTE
	bne @1
@2:
	lda (RLE_LOW),y
	beq @4
	iny
	bne @21
	inc <RLE_HIGH
@21:
	tax
	lda <RLE_BYTE
@3:
	sta $2007
	dex
	bne @3
	beq @1
@4:
	rts

User avatar
dougeff
Posts: 2616
Joined: Fri May 08, 2015 7:17 pm
Location: DIGDUG
Contact:

Re: NES Screen Tool

Post by dougeff » Wed Nov 23, 2016 8:07 am

I can confirm that the bug exists. But not in the asm. The tool itself is (sometimes) omitting the last byte of the attribute table, when writing an RLE. It's always the last byte. And it seems to happen if the last byte is different from the previous byte.

I made 4 different nametables (different only in the last attribute table byte). And, 3 of the RLE's were identical (and missing the final byte). The other one only included it because it was part of the 'repeat' from a previous byte.
nesdoug.com -- blog/tutorial on programming for the NES

User avatar
tokumaru
Posts: 11466
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: NES Screen Tool

Post by tokumaru » Wed Nov 23, 2016 8:19 am

So this is likely a problem in the RLE encoder, then? I'm surprised it took this long for a bug like this to be noticed, considering how long NST has been around.

User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2032
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: NES Screen Tool

Post by FrankenGraphics » Wed Nov 23, 2016 8:24 am

I suppose the to down-rightmost attribute cells tend to be the same in most cases?
http://www.frankengraphics.com - personal NES blog

User avatar
dougeff
Posts: 2616
Joined: Fri May 08, 2015 7:17 pm
Location: DIGDUG
Contact:

Re: NES Screen Tool

Post by dougeff » Wed Nov 23, 2016 8:27 am

BTW, you can easily hand edit the RLE to fix this....

The first byte of the RLE = the special 'repeat' code.

0x01,0x00,0x01,0xfe =

0x01, get special code
0x00, print 0 on screen
0x01, 0xfe, and then repeat that '0' 0xfe more times

The RLE ends when repeats are zero...

0x01,0x00, repeat the last byte zero times = exit

I was getting this as the last bytes of 3 RLE's

0x0f,0x01,0x06,0x01,0x00 =

0x0f, print 0x0f on screen
0x01, 0x06 repeat that '0x0f' 6 more times
(missing byte)
0x01,0x00 exit

Insert the last attribute byte there, before the 0x01,0x00

0x0f,0x01,0x06,0x03,0x01,0x00 (version 1 should have been this)

0x0f,0x01,0x06,0x07,0x01,0x00 (version 2 should have been this)

0x0f,0x01,0x06,0x0b,0x01,0x00 (version 3 should have been this)

0x0f,0x01,0x07,0x01,0x00 (version 4 was this, with 0x0f repeated 7 more times)

[on a side note, NES ST changes the value of the 'special' byte, so it can be any value 0-ff, but it will always be the first byte of the RLE. It's called 'RLE_TAG' in the asm.]
nesdoug.com -- blog/tutorial on programming for the NES

User avatar
tokumaru
Posts: 11466
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: NES Screen Tool

Post by tokumaru » Wed Nov 23, 2016 8:39 am

dougeff wrote:[on a side note, NES ST changes the value of the 'special' byte, so it can be any value 0-ff, but it will always be the first byte of the RLE. It's called 'RLE_TAG' in the asm.]
It makes sense to try and minimize the expansion by using the least common tile index to trigger RLE sequences... Hopefully there'll even be a tile that's never used.

The encoder probably buffers a byte before deciding whether it's uncompressed data or the beginning of a run, something it'll only know after looking at next byte, but doesn't have a special case for when there's no next byte to make the decision, so the buffered value gets forgotten. Just guessing.

tepples
Posts: 21752
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NES Screen Tool

Post by tepples » Wed Nov 23, 2016 9:46 am

One workaround is to save the uncompressed nametable as your "source" and compress it during the build process.

calima
Posts: 1018
Joined: Tue Oct 06, 2015 10:16 am

Re: NES Screen Tool

Post by calima » Wed Nov 23, 2016 9:51 am

So, someone emailed Shiru, right?

Diskover
Posts: 213
Joined: Thu Nov 24, 2011 7:16 am
Contact:

Re: NES Screen Tool

Post by Diskover » Wed Nov 23, 2016 10:10 am

tokumaru wrote:So this is likely a problem in the RLE encoder, then? I'm surprised it took this long for a bug like this to be noticed, considering how long NST has been around.
Maybe no one gave it importance or the tool is not being used as much as we thought.

I'm almost at the end of the development of my homebrew and I'm in that phase of fixing bugs. I've been observing that failure with the colors of the corner from the beginning, but I did not give it importance until yesterday I was given to investigate.
tepples wrote:One workaround is to save the uncompressed nametable as your "source" and compress it during the build process.
How can I compress while composing? How do I write that?

User avatar
rainwarrior
Posts: 7677
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NES Screen Tool

Post by rainwarrior » Wed Nov 23, 2016 10:33 am

tokumaru wrote:So this is likely a problem in the RLE encoder, then? I'm surprised it took this long for a bug like this to be noticed, considering how long NST has been around.
The latest version introduced some new bugs (especially to do with saving and loading NSS files), that have been outstanding for 2 years now.

I personally have used NESST a lot, but I've never touched its RLE feature before. (I have also been using version 2.03 much more than 2.04 because of the save/load bugs.)

Edit: the ZIP on his website has finally been updated! There's a version 2.3 now.
calima wrote:So, someone emailed Shiru, right?
It could be you!
Last edited by rainwarrior on Wed Dec 07, 2016 1:48 pm, edited 1 time in total.

tepples
Posts: 21752
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NES Screen Tool

Post by tepples » Wed Nov 23, 2016 11:04 am

Diskover wrote:
tepples wrote:One workaround is to save the uncompressed nametable as your "source" and compress it during the build process.
How can I compress while composing? How do I write that?
In general, you'd use a command-line program that turns an uncompressed nametable into a compressed nametable, and have your source depend on the compressed nametable, and have each compressed nametable depend on the corresponding uncompressed nametable.

The details of how to express that depend on what you're using to build your program. Do you use makefiles? Batch files for CMD, Bash, or PowerShell? Tup? It also depends to a lesser extent on what assembler you're using, in particular whether it uses object files linked together later (e.g. ca65/ld65) or expects other source files to be added with an include command (e.g. ASM6). For example, if you're using a makefile and object files, it might look like this:

Code: Select all

# Tell how to compress nametables
obj/nes/%.nam.pb53: screens/%.nam
	tools/pb53.py $< $@

# Rebuild title.o every time a compressed nametable changes
obj/nes/title.o: obj/nes/title.nam.pb53

User avatar
dougeff
Posts: 2616
Joined: Fri May 08, 2015 7:17 pm
Location: DIGDUG
Contact:

Re: NES Screen Tool

Post by dougeff » Wed Nov 23, 2016 12:02 pm

Is this the PB53 you (tepples) were talking about?

viewtopic.php?f=22&t=13686
Last edited by dougeff on Wed Nov 23, 2016 12:04 pm, edited 1 time in total.
nesdoug.com -- blog/tutorial on programming for the NES

tepples
Posts: 21752
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NES Screen Tool

Post by tepples » Wed Nov 23, 2016 12:04 pm

There are several RLE-like formats. PB53 is just the one I used in the Action 53 menu and RHDE.

User avatar
dougeff
Posts: 2616
Joined: Fri May 08, 2015 7:17 pm
Location: DIGDUG
Contact:

Re: NES Screen Tool

Post by dougeff » Wed Nov 23, 2016 12:06 pm

I (and Diskover, I think) am asking for a specific link to specific code. Is this the code you referenced?
nesdoug.com -- blog/tutorial on programming for the NES

tepples
Posts: 21752
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NES Screen Tool

Post by tepples » Wed Nov 23, 2016 1:58 pm

Yes, the PB53 mentioned in the PBJ topic is the PB53 I was referring to, which is the same as the PB53 described on the wiki. No, PB53 is not identical to PBJ, but PB53's primary compression mode (unary RLE) is reused in PBJ.

Assuming that you are using ca65, GNU Make, and Python (if not, see the README for my NROM project template for how to install them), all needed code is in the Git repository for RHDE.

Post Reply