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.
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!
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.
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:
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).
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! Thank you.
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.
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).
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?
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.
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.
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!
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.
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.