nesdev.com

You are so right. Glad I asked; thanks!
In your code you used bit FrameReady

What is bit for?
I spent a long while today trying to understand bit.
I know that bits 7 and 6 of the memory are transfered to the status register's bits 7 and 6. Then I think there was an AND that changes the Z flag. And so I understand how bit works for bpl because it branches when the N flag isn't set... and N flag is bit 7. Why did they make bit? What is the point of bit? I tried searching the forum for bit but I failed, sorry.

BIT takes a value from memory. Whatever that memories bit 7 is the new Negative value. Overflow bit becomes the value of bit 6 from that too. And then it's AND'd with A. If equal or not equal to 0 afterwords, sets the zero flag accordingly.

http://www.obelisk.demon.co.uk/6502/reference.html#BIT

That site has a great reference to instructions and how they work, I'd advise you to bookmark it.

And it's made AFAIK to do bit tests easy. To test one bit of a certain location, it's pretty simple and you don't have to even LDA with anything to test the top 2 bits:




Sucks you can't do it indirectly and with lots of addressing modes, though.

I believe that the main purpose of BIT is to test whether bits in memory are set or clear. You load your bit mask into the accumulator and BIT it with the value you want to test, if the Z flag is set, the bits you tested are clear.

But to me, the fact that bits 6 and 7 are copied to the V and N flags is what makes it actually useful. Whenever I want to test one of those 2 bits I use BIT. In my example code I was checking bit 7, which is clear when the flag is false ($00) and set when the flag is true ($ff).

3gengames, thank you for this site!

Ah yes, that is a great point! Thank you.

Thank you tokumaru for sharing your wisdom.

Yes, I agree.

I remember searching the nesdev wiki for "table." I have reread all 4 of your links to threads where you've talked about collision. I'm excited to finally try to make my own! But, I dont understand how tables work. Is a table kind of like a 2dimentional matrix?

Yep, 2D usually table of data. Or one way and reads data in strips to the screen, or you could have 16 "tables" and read them all horizontally. Many ways to do it. RPG's is probably a 2D array, but for a horizontal scrolling game that doesn't scroll up and down wuld maybe do better with 16 tables to build 1 screen, or the vertical method. There's probably more as I haven't messed with data much, but those seem the most obvious to me.

So if I divide the screen into 16 rows, using a 16x16 grid size, that's quite a large grid size. Compared to an 8x8 grid size... that's what tokumaru used... but that would be twice as much; I would hae to divide the screen into 32 rows. That's twice as much memory used and... ugg. Start at the beginning , is the screen 256 scanlines tall?

240 scanline tall, 15 data pointers for each row of the screen that are built into 2x2 tiles and then made into a column as they move over. All going horizontally compressed would take very little room. IIRC, SMB is like 4KB for levels out of the 32KB ROM. Not sure if that's what they used, but it in the end won't come out big at all if you use compression.

Compression may not be to good.... how many different background tiles can be created when using compression?

edit: Well we turned on Ninja Gaiden and saw its many MANY background tiles. Did Ninja Gaiden use compression?

Not sure. But since probably all of your tiles will be 2x2 tiles, you only need 64 combinations of data and you build them from there. Check out how RLE compression works below. It basically tells it how many times one byte of data is repeated. So you can condense up to about 255 bytes of data to two bytes. It's a great thing to use, and needed in most games to fit them all in.

RLE on Wikipedia:

http://en.wikipedia.org/wiki/Run-length_encoding

And I'm pretty sure it's safe to say nearly every game uses some compression for probably all big stuff in their gams. Levels probably the main thing.

So ok, thank you for RLE and all your help; I can use RLE compression for my collision tables because each of the background tiles can be represented by a zero. That seems to work in my head!

Yep, I dunno about that, but if you believe so you can do it.

Thinking about alot of things... and I have a few questions. 1.)Would it be notgood to store the level-nametables without RLE compression and then spend more space to store pre-made RLE compressed collision notes? 2.) Or would it be better to store the level-nametables RLE compressed and then create collision info at the drawing nametable faze like tokumaru explained?

I'm confused about all of this right now... trying to see what would be good.

If there's lots of different data, you'd probably be farther ahead to not do RLE, or maybe any compression. If there's lots of the same data in a row, then sure. You just gotta decide. And you don't have to implement this now, you can always go back if you need to and add it once you get more gritty with your games levels data and stuff. Just make sure you program it so that it wouldn't be ridiculous to add it later.

Are the collision tables created on the fly while reading for drawing? Or are they susposed to be created separately ahead of time? Or should I reread the nametables and create the cllision table as i am rereading the nametable?