8x16 and whatever else unreg wants to know

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

tokumaru wrote:
unregistered wrote:I'm keeping jsr react_to_input in the video updates because the video may be changed by the controller. Is that right? : )
I think it makes more sense to put it at the start of the main loop. After all, the way your game reacts to input is part of the game logic. In a way, EVERYTHING in the game affects the video, and that's why you run all the game logic first, to prepare everything for the video updates that will follow.
You are so right. Glad I asked; thanks! :D
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. :(
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames »

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:

Code: Select all

LDA #$02
BIT SomeFlags
BEQ FlatNotSet ;Bit #%00000010 is set?
;Flag is set if it makes it here.
Sucks you can't do it indirectly and with lots of addressing modes, though.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

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).
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

3gengames wrote: 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. ;)
3gengames, thank you for this site! :)
3gengames wrote: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
Ah yes, that is a great point! :D Thank you. :D
tokumaru wrote: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.
Thank you tokumaru for sharing your wisdom. :D :)
tokumaru wrote: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).
Yes, I agree. :)
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

tokumaru wrote:How are your levels stored? Just like you read them in order to draw to the nametables, you have to read them to check for collisions. Each block in the level must have its own solidity information (you can use a table for that).
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?
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames »

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. :)
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

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?
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames »

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. :)
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

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 :D background tiles. Did Ninja Gaiden use compression?
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames »

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.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

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! :)
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames »

Yep, I dunno about that, but if you believe so you can do it. :) :P
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

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.
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames »

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. :)
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

tokumaru wrote:Just like you read them in order to draw to the nametables, you have to read them to check for collisions.
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?
Last edited by unregistered on Mon Sep 12, 2011 12:52 pm, edited 1 time in total.
Post Reply