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

3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames »

Yes :)
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

In subtractions, the carry flag acts as a "borrow flag". Setting it before a subtraction is like putting a 1 in position to be borrowed, just in case. When the subtraction takes place, and the result is less than 0, the carry is borrowed and becomes 0. So you just have to peek at the carry afterward: if it's set, the result was equal to or greater than 0 (no need to borrow), if it's clear, the result was less than 0.

A CMP is exactly like a SBC, except that you don't have to set the carry before using it and it doesn't store the result, but all the other rules of subtraction apply to CMP.
unregistered wrote:I want to branch if A is not < NUM.
If you subtract NUM from A, a borrow will only happen if A < NUM.

Code: Select all

cmp #NUM
bcs Whatever
	;A is less than NUM
	jmp Skip
Whatever:
	;A is equal to or larger than NUM
Skip:
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

Code: Select all

	
--	lda ($10),y
    sta currenttile
	;  if ((currenttile >= 15) && (currenttile < 32)) ; is solid 
	;	  lda #01b
	cmp #15 ;if (currenttile >= 15)
	bcc +
	cmp #32 ;if (currenttile < 32)
	bcs +
	  lda #01b          ;a is solid
	  jmp ++done 
 
+ 
Is my logic here ^ good? I am useing the inverse (bcc instead of bcs, bcs instead of bcc) because !0 == 1 and !1 == 0. Does this make any sense? I do understand what you, tokumaru, just explained very detailed and well; thank you so much!! :D (Except your last comment; I'm still attempting to work that one out in my head. :)) And thank you 3gengames for continuing to offer me help. :)
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

Looks correct to me. Does it work?
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

tokumaru wrote:Looks correct to me.
8) 8) 8) 8) 8) 8) :D :D
tokumaru wrote: Does it work?
:) it is not ready for testing yet... getting close. :)
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

Getting a bit closer. :) I am at the point, now, where I'm susposed to write the code that creates the screenArray .dsb 240. I've thought about this and have tried to make firstRow .dsb 32 and secondRow .dsb 32 contain the contents of the first and second row of tiles. Then I get really lost... somehow I'm susposed to change firstRow and secondRow into the first row of screenArray... there is the two types of collision tiles... tokumaru typed "primary" and "secondary" to me in an earlier post.

I dont understand how these pieces of the puzzle fit together... it's really far far away from me now. If you could help with a helpful arrow that could guide me closer to this task ahread of me... that would be amazing! :D Going tosleep now, love yall. :) Maybe after sleep I'll be able to make more sense with ...these ideas... maybe reread this thread again... . :)
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames »

Well, you use x amount of bits per tile, and then each are flags. Like one would be a solid/not solid, the next for for not solid if it was a certain type, then other bits would mean different things too like if it's sloped or something.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

tokumaru wrote:
unregistered wrote:Could the last row of each .chr file determine if the default collision would be water? (Moving all water tiles to row F) so if the tile is F3 then it's water? Could that work? (I don't know what "index of the metatile" means. That was my guess...)
Yup, I suggested something like that. I'm usually against hardcoding logic decisions to visuals, but if done carefully it isn't necessarily bad.
When I'm trying to read this compressed data to create the level how can I tell if the 0s mean water? I drew this all on paper trying to figure it out. :?
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

^Zeros mean water if the tile number is on the last row. This is the collision detection info... not the level map. :?
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

If I ran into these eight tiles:

Code: Select all

+---+---+ 
|S S|S W| 
|A A|S W|
+---+---+

A = Air; 
W = Water; 
S = Solid; thanks tokumaru
They would be translated like:

Code: Select all

+---+---+ 
|1 1|1 0| 
|0 0|1 0|
+---+---+
and then, tepples will leave me with 11000001 and 10100001.
And so after this point I should store each of those bytes in my screenArray.
When I've completed screenArray and add gravity I will check after each move if the girl has collided with something. If that something is a solid 0001 I will have to pull her out of the solid. If that something is water.... How do I know if the something IS water? :? How do I check the tile number?
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

unregistered wrote:How do I know if the something IS water? :? How do I check the tile number?
One of the ideas we had consisted in using 1 bit to select between water or air for the empty tiles, and 3 bits for the type of the solid tiles. In this case it would be easy to know if something is water, but since you decided to use the tile index...

Well, your screenArray only has the basic collision info, it doesn't say which tiles each block uses. The only way is to make screenArray hold the index of the metatiles instead of the collision info. That way, whenever you wanted to test for collisions, you'd have to get the metatile index at the position you want and use that to fetch the collision info from a table. With the same index you can easily access the tile indexes too. It's a bit more indirect, but that's not too bad.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

tokumaru wrote:Well, your screenArray only has the basic collision info, it doesn't say which tiles each block uses. The only way is to make screenArray hold the index of the metatiles instead of the collision info. That way, whenever you wanted to test for collisions, you'd have to get the metatile index at the position you want and use that to fetch the collision info from a table. With the same index you can easily access the tile indexes too. It's a bit more indirect, but that's not too bad.
sooooo, thank you for helpfull words :D ,

Code: Select all

+---+---+
|S S|S W|
|A A|S W|
+---+---+
will translate into

Code: Select all

+---+---+
|?  |?+1|
|   |   |
+---+---+
The index of the metatiles will be stored in screenArray. Would it look like this^? I'm going to guess no. I don't understand what you mean by the index of the metatiles; I'm sorry. :( edit: Though it is nice to remember there is an easier way to do this, thanks. :)
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

You are using metatiles to build your maps, right? Each metatile has some info attached to it: the index of the 4 tiles it uses, its collision information and the palette it uses. If you have that index, you can access any of that information.

So, by keeping an array of metatile indexes in RAM you can access their collision information as well as the tiles that make them up, in order to decide whether the empty tiles are air or water.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

I don't know how to view the info attached to each metatile. But, after asking my sister (artist who does the graphics), I remember that each name table has a metatile map of 16 columns by 15 rows. So are the metatile indexes like $1A and $00 and $EF? :) If so, then should I create an array something like (00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 0A, 0B, 0C, 0D, 0E, 0F, 10, 11, 12... ...EC, ED, EE, EF)?
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

You could arrange the metatiles in ROM kinda like this:

Code: Select all

MetatileTile0:
	.db $00, $04, $08

MetatileTile1:
	.db $01, $05, $09

MetatileTile2:
	.db $02, $06, $0a

MetatileTile3:
	.db $03, $07, $0b

MetatileCollision:
	.db %00001010, %01001100, $00011010

MetatilePalette:
	.db %10101010, %00000000, %01010101
Here I have 3 metatiles, each using 6 bytes. If I want to get the collision info for any given tile, I can just put its index in X or Y and read it from the MetatileCollision table.

So, if your screenArray is an array of 16x15 metatile indexes, you can do something like this to read the collision info of any metatile:

Code: Select all

	;use 2 4-bit coordinates to calculate
	;how far in the array the metatile is
	lda metatileY
	asl
	asl
	asl
	asl
	ora metatileX
	tax

	;get the index of the metatile
	lda screenArray, x
	tax

	;get its collision information
	lda MetatileCollision, x
Just as easily you now can use lda MetatileTile0, x to read the index of its top left tile, and the other tables to find out anything you want about the metatile in that position.
Post Reply