It is currently Wed Dec 13, 2017 7:38 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 112 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7, 8  Next
Author Message
 Post subject:
PostPosted: Sat Jul 30, 2005 10:32 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2142
Location: Minneapolis, Minnesota, United States
Oh, well i didn't know that it hid unavoidable stuff, but since you put it that way, I guess I'm rather Pro-clipping.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 30, 2005 10:42 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19342
Location: NE Indiana, USA (NTSC)
Under the official specification for the NTSC TV signal, the scanline is 280 NES pixel clocks wide including horizontal overscan. Thus, perfect aspect ratio correction involves rendering to a 280x240 pixel buffer (leaving four pixels blank on each side), drawing "SAMSUNG" over whatever isn't visible on your TV (which may not be a perfect rectangle; many SDTVs have more bezel at the corners than at the center of each side), and then stretching the result to fill the screen (e.g. 320x240, 640x480, or on a PC or HDTV monitor 960x720).

EDIT: fixed scanline width


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 30, 2005 10:56 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2142
Location: Minneapolis, Minnesota, United States
Okay, my BG making method isn't reliable due to one thing. THE X AND Y REGISTERS CAN'T GO ABOVE $FF! So in order to load a screen, I have to do dumb tedious methods a couple times to fill the Name Table, so I think I'll just try and make a level editor. I don't know how to make it output code that the NES can use, though! Is there a good example of this anywhere?


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 31, 2005 2:16 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7314
Location: Chexbres, VD, Switzerland
Celius wrote:
Okay, my BG making method isn't reliable due to one thing. THE X AND Y REGISTERS CAN'T GO ABOVE $FF! So in order to load a screen, I have to do dumb tedious methods a couple times to fill the Name Table, so I think I'll just try and make a level editor. I don't know how to make it output code that the NES can use, though! Is there a good example of this anywhere?

Use Zero-Page pointers with the instruction lda [$xx],Y and so on. You'll need it anyway.
Edit :
About designing levels, the usual way to encode a map is to separe it with small portions of graphics, that can be assembled like a puzzle, and they'll point to the tiles that you have to write to the name table. You can do just one encoding level, like I think Final Fantasy does (at least the first one), but you can also do two or even more level of "small portions of graphics". I'm now writting a game that works with two levels of this, i.e. a map is composed with big blocks, that'll point to small blocks, that'll point to tiles. While scooling, I write one "big block" at once, but it would be a two high portion of graphics to scroll in the direction that is mirrored, so this only works for 2 directionnal scrooling (like Megaman 1/2, CastleVania, LifeForce and many others).
FF uses some smaller 2x2 tiles blocks to encode its maps, and I think it's a good method, but at least RLE compression is needed to decode it.
Of course use .nam files suck for levels, but it can be usefull for title screens or so on (I like using another format for my title screens personally).
But the .incbin directive is needed if you make your level with an hex editor, and that's easier thant just input lots of .db

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 31, 2005 12:17 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2142
Location: Minneapolis, Minnesota, United States
Okay, am I the only one that thinks .nam files suck in general, because the camera always shows name table 1.5? It shows the bottom half of the upper name table, and the top half of the lower name table.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 31, 2005 12:46 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2142
Location: Minneapolis, Minnesota, United States
Okay, how are you supposed to do RLE compression with NESASM? Is it possible? Because you can't just do

.db $7,$8*15,$9

because it just show $8 times $F, which is 15 in decimal, which comes out to be 78, and displays the letter x instead of 15 $8s. So yeah, what method does NESASM use?


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 31, 2005 1:30 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
.db just puts a byte in your assembled binary. How you interpret those byte depends on your decompression code -- not on how the assembler works.

If you want to put 15 8's in a row (which i'd assume is what you were trying to do) -- that wouldn't even be compressing it =P

If your code is just reading one byte at a time, then you're code isn't decompressing... it's just using the raw data.


A common format for RLE compression is kind of like the following:

if high bit is on, this is a run and low 7 bits are the length of the run. Next byte is the byte to run.

If high bit is off, this is not a run and the low 7 bits are the length of the non-run. Next X bytes are the non run (X being the length)

Therefore the following:

23 23 23 23 64 78 64 12 78 35 35 35 35 18 18 18 18 18 23 23 23 23

Could compress to:

84 23 05 64 78 64 12 78 84 35 85 18 84 23


To make that a little clearer:

Code:
23 23 23 23|64 78 64 12 78|35 35 35 35|18 18 18 18 18|23 23 23 23|
|      ___/              /     ______/ _____________/  _________/
|     /                 /     /     __/   ____________/
|    |                 |     |     |     /
84 23|05 64 78 64 12 78|84 35|85 18|84 23|


So if you want it to be compressed in your file you'd do:

.db $84, $23, $05, $64, $78, $64, etc

However it would be MUCH easier to keep that in a binary file and .incbin it. That way whatever editor your using will have a much easier time reading/writing to it and it won't clutter up your code source.


Rembember -- if you want to decompress it you will have to actually write the code to decompress it. nesasm will not automatically decompress your data.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 31, 2005 2:25 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2142
Location: Minneapolis, Minnesota, United States
Okay I got most of that, and thank you for telling me that. But I was confused about one thing. Why is there a $05 in there?


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 31, 2005 2:32 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
It's the first byte in the set which specifies the length. '05' means 'the next 5 bytes are not compressed. Whereas '85' means 'repeat the next byte 5 times'

But this is just one way of implimenting RLE -- you can do it however you want.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 31, 2005 2:46 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2142
Location: Minneapolis, Minnesota, United States
Oh, I get it. That's handy. So does 86 mean repeat the next byte 6 more times, where as 06, means the next 6 bytes are not compressed?


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 31, 2005 4:09 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1393
As we've already mentioned several times, you can use whatever RLE format you want (you could switch around the meaning of $86 and $06 if you wanted to, or you could store the 'repeat' bit in the bottom bit and LSR to get the count), but you'll ALSO have to write 6502 code to 'decompress' the data.

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 31, 2005 5:57 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2142
Location: Minneapolis, Minnesota, United States
I wasn't sure how to decompress it, so I googled "6502 RLE decompression" and the first result was this http://gavin.panicus.org/doc/6502%20RLE%20Decompression.txt. Do you think this is reliable?


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 31, 2005 6:06 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2142
Location: Minneapolis, Minnesota, United States
Okay, how are you supposed to compress the Raw data with 6502? I really want to know so I can just get this over with and not carry this forum out to be 8 pages long. It's unfortunately 6 pages already, which is the longest forum here I've ever seen. I'm sorry, I know you all think I know NOTHING about the 6502, but could someone give me an example of compression in 6502? I know Disch, that you gave the example up there, but how are you supposed to actually compress it?


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 31, 2005 6:14 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
He uses asbolute indexed mode -- so you will be limited to smaller sizes (compressed/decompressed data can't be larger than 256 bytes). He also doesn't check for a decompressed size -- it looks like he processes 256 bytes of data and then stops -- so if you only have 64 bytes or something it won't work.


Something like this you should write yourself -- since your needs may be more specific than a general purpose function.

Decompression logic is very simple:
1) Take a byte

2) Look at high bit -- if on:
-a) turn off high bit and use low bits as length
-b) Take another byte
-c) Use that byte X times (where X is the length)
-d) Repeat from step 1 until done

3) If high bit is off:
-a) use byte as length
-b) Take X bytes and use them as-is (where X is the length)
-c) Repeat from step 1 until done


And actually -- this might be a good learning experience, since it involves several concepts like looping, branching, possibly indirection and other areas which you'll need to be familiar with if you're going to program a game.


edit:

Compression is significantly more difficult (especially on a 6502), as it involves looking ahead and finding patterns. For now I'd just compress by hand and get a decompression routine working. Once you have it decompressing then worry about making a compression routine.

Your game won't have to compress data anyway -- so you could (and probably should) write it in some other language -- which ever one you're making you're editor in.

And if you are concerned about thread size, perhaps you should edit posts instead of double-posting?


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 31, 2005 6:23 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
That RLE decompressor doesn't look to be general (it seems to only allow output data of 7 bits) and isn't documented well.

You seem to be in way over your head. This means you are wasting time trying to figure out whether a problem you're having is due to a lack of foundation or specific to what you're trying at the moment. It's the same as making many changes to a program and then encountering a new bug -- every change is a possible cause.

You've probably been damaged by public schooling in the US (and perhaps elsewhere) where real learning is shunned and only rote learning (memorization) is practiced. This means you probably have little experience with actual learning, which involves lots of experimentation, a desire for clarity, and development of the ability to recognize mastery.

Run-length data compression can be considered in the abstract, without reference to computers. Think about ways of transforming a sequence of bytes into a shorter sequence such that the original sequence can be recovered. One thing you'll encounter is the concept of meta-data: data embedded within the actual data, and ways of reliably recognizing this.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 112 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7, 8  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: LocalH and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group