8x16 and whatever else unreg wants to know
Moderator: Moderators
I don't know why you absolutely need the wall to be 8 pixels thick, but I guess there are ways to work around this. Maybe you can find some other way to define the default collision type, so that instead of air it's water in this case.
Maybe you could have the default collision type be water or air depending on the index of the metatile, or the index of the palette used for the metatile, something like that.
Maybe you could have the default collision type be water or air depending on the index of the metatile, or the index of the palette used for the metatile, something like that.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Ah, that is a ggrand (edit: I kind of had thought of something like that too. Thank you tokumaru for your challenges! ) idea tokumaru! Ok this is what we decided... after much talking... that we would set bit 3 to 1 for default water and leave it at 0 for default air. And that will bring our total collision blocks down from 16 to 8... 8 is all we (edit: I remember saying this about the 4) need for this game. It's twice as much as 4! We realize we are throwing away 8... but my sister is estatic we can use 5! That leaves 3 more! Thank you tepples and tokumaru so much!!
Heh, I was gonna suggest that but I thought you wouldn't want to give up half the collision types for this... Guess I was wrong! =)
This is what you are planning to do, right?
This is what you are planning to do, right?
Code: Select all
76543210
||||||||
|||||+++- Secondary collision type (solid, platform, danger, etc.);
||||+---- Primary collision type (0 = air, 1 = water);
|||+----- Primary or secondary collision for the top left tile;
||+------ Primary or secondary collision for the top right tile;
|+------- Primary or secondary collision for the bottom left tile;
+-------- Primary or secondary collision for the bottom right tile;
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Well, we talked for anothger extended time, cause I think that I'd have to set each metatile and, oooh foood is for eating now, no... I'd have to set each metatile and that would be crazy and would be much better for it to be set in the .chr file cause she is in charge of the graphics... and so it would be less work for me and we'd have a quicker game... that would be good. Food would be goood too! I'll reply to the rest of your reply in a bit.tokumaru wrote:Heh, I was gonna suggest that but I thought you wouldn't want to give up half the collision types for this... Guess I was wrong! =)
Ok, yes that is what we are planning to do, iftokumaru wrote:This is what you are planning to do, right?
Code: Select all
76543210 |||||||| |||||+++- Secondary collision type (solid, platform, danger, etc.); ||||+---- Primary collision type (0 = air, 1 = water); |||+----- Primary or secondary collision for the top left tile; ||+------ Primary or secondary collision for the top right tile; |+------- Primary or secondary collision for the bottom left tile; +-------- Primary or secondary collision for the bottom right tile;
- "Primary or Secondary collision" can be false.
- Our efforts (below) don't make sense and cant work.
Yup, I suggested something like that. I'm usually against hardcoding logic decisions to visuals, but if done carefully it isn't necessarily bad.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...)
Do you have only 1 water tile though? What about the water surface?
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
In SMB1 maps, look at 2-2. The top row of water tiles uses a different tile from the rest. Then look at 3-1 and see the bridge about a third of the way through: the top tile is different. And any x-4 level uses that same top-of-water-area tile for its boiling Kool-Aid. This tile is used at the water surface.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
This question is about if, elseif, else, and endif from asm6
This is from my listing file .lst.
I have tried these statements with $0F hex numbers and then changed the hex to decimal. Only the middle lda #11b has hex codes on the left side. Why? My problem is that I tried to use assembler directives as c++ statements... I think.?
Code: Select all
0C2E6 B1 10 -- lda ($10),y
0C2E8 8D D0 C2 sta currenttile
0C2EB if ((currenttile > 15) && (currenttile < 32)) ; is solid
0C2EB lda #00000001b
0C2EB
0C2EB elseif (currenttile > 239) ; is water
0C2EB A9 03 lda #11b
0C2ED
0C2ED else ;(a) is empty
0C2ED lda #00000000b
0C2ED endif
0C2ED
0C2ED AE CF C2 ldx rowPointer
0C2F0 9D 8E C2 sta firstRow,x
0C2F3
0C2F3
0C2F3 E8 inx ;increment pointer used with firstRow
0C2F4 8E CF C2 stx rowPointer
0C2F7 C8 iny
0C2F8 D0 EC bne --
I have tried these statements with $0F hex numbers and then changed the hex to decimal. Only the middle lda #11b has hex codes on the left side. Why? My problem is that I tried to use assembler directives as c++ statements... I think.?
Assembler directives can't be used for game logic. These expressions are evaluated when the program is assembled, not when the program runs.
EDIT: Let me try to explain what happened there: currenttile is a label that points to a RAM location, and this location is probably after address 239, which is why lda #11b got assembled.
EDIT: Let me try to explain what happened there: currenttile is a label that points to a RAM location, and this location is probably after address 239, which is why lda #11b got assembled.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
([url=http://www.6502.org/tutorials/compare_beyond.html][color=green]from this page[/color][/url]) wrote:A useful property of CMP is that it performs an equality comparison and an unsigned comparison. After a CMP, the Z flag contains the equality comparison result and the C flag contains the unsigned comparison result, specifically:
So if A < NUM then BCS will not branch, right?If the Z flag is 0, then A <> NUM and BNE will branch
If the Z flag is 1, then A = NUM and BEQ will branch
If the C flag is 0, then A (unsigned) < NUM (unsigned) and BCC will branch
If the C flag is 1, then A (unsigned) >= NUM (unsigned) and BCS will branch
I want to branch if A is not < NUM. I'm kindof confused about this; could you help?
In fact, many 6502 assemblers will allow BLT (Branch on Less Than) and BGE (Branch on Greater than or Equal) to be used as synonyms for BCC and BCS, respectively.
http://www.obelisk.demon.co.uk/6502/reference.html#CMP
If A<ComparedTo, then C=0, BCC taken.
If A>=ComparedTo, then C=1, BCS taken.
And yeah, the opposite branches for each taken will not be taken.
And to branch if a number is greater than A, do:
If A<ComparedTo, then C=0, BCC taken.
If A>=ComparedTo, then C=1, BCS taken.
And yeah, the opposite branches for each taken will not be taken.
And to branch if a number is greater than A, do:
Code: Select all
CMP #$20
BCS Somewhere ;BCS is taken because A is bigger or equal to #$20.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas