It is currently Wed Jan 17, 2018 11:03 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 1389 posts ]  Go to page Previous  1 ... 18, 19, 20, 21, 22, 23, 24 ... 93  Next
Author Message
 Post subject:
PostPosted: Thu Sep 08, 2011 10:32 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Thu Sep 08, 2011 10:48 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
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:
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 09, 2011 5:41 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10229
Location: Rio de Janeiro - Brazil
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).


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 09, 2011 7:37 am 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 09, 2011 1:55 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 09, 2011 2:07 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
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. :)


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 09, 2011 6:26 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 09, 2011 7:34 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
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. :)


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 09, 2011 9:00 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 09, 2011 9:22 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 10, 2011 1:23 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Sat Sep 10, 2011 1:44 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
Yep, I dunno about that, but if you believe so you can do it. :) :P


Top
 Profile  
 
 Post subject:
PostPosted: Sun Sep 11, 2011 9:46 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Sun Sep 11, 2011 9:49 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
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. :)


Top
 Profile  
 
 Post subject:
PostPosted: Mon Sep 12, 2011 12:50 pm 
Offline
User avatar

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

Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1389 posts ]  Go to page Previous  1 ... 18, 19, 20, 21, 22, 23, 24 ... 93  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 0 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