8 point collision , what I know

Having trouble compiling code? Getting an unexpected error? Player not appearing on screen? Seeking answers on how to do a particular thing? This is the forum you're looking for, to ask other NESmaker users for assistance.
User avatar
jorotroid
Posts: 152
Joined: Wed Aug 08, 2018 7:48 pm
Location: California
Contact:

Re: 6 point collision , what I know

Post by jorotroid » Thu Oct 11, 2018 1:23 am

Weird, I thought I posted a reply last night before going to bed. Those forum threads you shared are out of date. The first one was started during the beta. The second one was started by me when version 4.0.0 was the latest version. As of 4.0.11, 6 point collision is in. I'm using it in my game, I have a 2x4 sprite. I think I know what your problem is. Your falling through the floor, not passing through them from the side like my character was in my thread, right? 6 point collision is meant to fix tall characters from going through 1 tile thick platform on the side. For a character with the dimensions you have, you will need 8 point collision to do additional checks below and above the character. Or you can try to cheat a bit and make your bounding box small enough that you don't need to do that.

The code that you pasted is correct for 6 point collision, but it looks like the comments haven't been updated. You can tell that there was some copying and pasting with collision points 4 and 5 because the comments for those and point 3 all say ";;; === handles bottom left corner." I don't think I have the time to write out the code for you at the moment, but I can probably point you in the right direction if your feeling adventurous. I think you'll need to do at least 3 things:
-Add two more copies of the collision code like the ones I pointed out. Then modify them to check for the center bottom and center top of the bounding box. You can divide a number by 2 by using LSR (look in the code you pasted for an example).
-Near the bottom of the code, add ORA collisionPoint6 and 7 for your new collision points.
-Define collisionPoint6 and 7 in ZP_and_vars.asm. Look for the other collision points in there and just add in 6 and 7 right after them.
User avatar
fearspork
Posts: 35
Joined: Tue Aug 14, 2018 6:59 pm

Re: 6 point collision , what I know

Post by fearspork » Thu Oct 11, 2018 2:32 pm

i won't be home for hours but this is the missing peice, the file with the point address, so let me run through in my head how to do this
in the collision detection file I need to cut and paste the code for points 4 and 5
change the numbers to 6 and 7 ( label them something like middlerightB or something so I know what it is)
change the code where it says max points 6 to 8 ( I think that's in there twice)
then I need to jump to the variable file
cut and paste the code for collision point variable 4 and 5 (what ever that looks like)
change that to 6 and 7( and probably label that something to match the collision detection file)
and then change the code to define the 2 new addresses

I may need to plot my sprite out on a paper graph, and then alter the size of the bounding box in nesmaker to see how the other points change to get the locations of the other points for the paper graph, if you follow

have I got that about right?
User avatar
fearspork
Posts: 35
Joined: Tue Aug 14, 2018 6:59 pm

Re: 8 point collision , what I know

Post by fearspork » Fri Oct 12, 2018 3:50 am

this is most of the code from TileCollision_platform_simple_alt.asm the code i added 2 more points and changed the max points to 8

Code: Select all

[color=#00FF00];; uses collisionPoint0,1,2,and 3
	;; makes use of left+bbox_left, top+bbox_top, width and height of an object to form bounding box.
	;; gets collision data for each point.

	;LDA ObjectFlags,y
	;AND #%10000000 ;; ignore background collisions?
	;BEQ dontIgnoreBackgroundCollisions
	;LDA Object_flags,x
	;AND #%01000000
	;BEQ dontIgnoreBackgroundCollisions

	;RTS 
dontIgnoreBackgroundCollisions:

	;;;=== HANDLES TOP LEFT CORNER
	LDA xHold_hi
	CLC
	ADC ObjectBboxLeft,y ;; y is still loaded with object type, so this reads from lut table.
	STA tileX
	LDA yHold_hi
	CLC
	ADC ObjectBboxTop,y
	STA tileY
	JSR GetTileAtPosition
	LDA collisionTable,y
	;; y is now loaded with tile type
	STA collisionPoint0
	;;; if it is solid, disregard the other collisions, this should *stop us*.
	LDY Object_type,x
	
	;;; === handles top right corner
	LDA tileX
	CLC
	ADC ObjectWidth,y
	STA tileX
	JSR GetTileAtPosition
	;; y is now loaded with tile type
	LDA collisionTable,y
	STA collisionPoint1

	LDY Object_type,x
	
	;;; === handles bottom right corner
	LDA tileY
	CLC
	ADC ObjectHeight,y
	STA tileY
	JSR GetTileAtPosition
	LDA collisionTable,y
	;; y is now loaded with tile type
	STA collisionPoint2

	LDY Object_type,x
	
	;;; === handles bottom left corner
	LDA tileX
	SEC
	SBC ObjectWidth,y
	STA tileX
	JSR GetTileAtPosition
	LDA collisionTable,y
	;; y is now loaded with tile type
	STA collisionPoint3

;;;;;;;;;;;;;;;;;;six point collision
	LDY Object_type,x
	
	;;; === handles bottom left corner
	LDA ObjectHeight,y
	LSR
	STA temp
	LDA tileY
	SEC 
	SBC temp
	STA tileY
	JSR GetTileAtPosition
	LDA collisionTable,y
	;; y is now loaded with tile type
	STA collisionPoint4

	LDY Object_type,x
	
	;;; === handles bottom left corner
	LDA tileX
	clc 
	adc ObjectWidth,y
	STA tileX
	JSR GetTileAtPosition
	LDA collisionTable,y
	;; y is now loaded with tile type
	STA collisionPoint5

        LDY Object_type,x  
	
	;;; === handles bottom left corner
	LDA ObjectHeight,y
	LSR
	STA temp
	LDA tileY
	SEC 
	SBC temp
	STA tileY
	JSR GetTileAtPosition
	LDA collisionTable,y
	;; y is now loaded with tile type
	STA collisionPoint6

	LDY Object_type,x
	
	;;; === handles bottom left corner
	LDA tileX
	clc 
	adc ObjectWidth,y
	STA tileX
	JSR GetTileAtPosition
	LDA collisionTable,y
	;; y is now loaded with tile type
	STA collisionPoint7

	LDY Object_type,x ;; final restoring corrupted y value
	

	
	
	LDA collisionPoint0
	ORA collisionPoint1
	ORA collisionPoint2
	ORA collisionPoint3
	ORA collisionPoint4
	ORA collisionPoint5
	ORA collisionPoint6
	ORA collisionPoint7
;	;;; all collision points were zero.
	BEQ noCollisionHappened
	
	JMP collisionHappened

noCollisionHappened:	
	RTS ;; no collision happened.
	
collisionHappened:


	LDA currentBank
	STA prevBank
	LDY #DATABANK1
	JSR bankswitchY
	
	TXA 
	STA currentObject
	
	LDA #$00
	STA tempCol
	
DoCheckPointsLoop:
	LDY tempCol
	LDA collisionPoint0,y
	BEQ DontCheckTileType0
	TAY
	LDA tileTypeBehaviorLo,y
	STA temp16
	LDA tileTypeBehaviorHi,y
	STA temp16+1
	JSR UseTileTypeTrampoline
	JMP pastTileTypeTrampoline
UseTileTypeTrampoline:
	JMP (temp16)
pastTileTypeTrampoline
	
DontCheckTileType0:
	INC tempCol
	LDA tempCol
	CMP #$08 ;; max number of collision points. 
	BNE DoCheckPointsLoop     
in file ZP_and_VARS.ams i changed this code

Code: Select all

[color=#00FF00];************************************
;;Object collision checking variables
;;************************************
	selfLeft 		.dsb 1				
	selfRight		.dsb 1				
	selfTop			.dsb 1				
	selfBottom		.dsb 1				
	
	otherLeft		.dsb 1				
	otherRight		.dsb 1					
	otherTop		.dsb 1			
	otherBottom		.dsb 1			

	selfCenterX 	.dsb 1				
	selfCenterY		.dsb 1	
					
	otherCenterX	.dsb 1				
	otherCenterY	.dsb 1	
	
	xHold_lo		.dsb 1
	xHold_hi		.dsb 1
	yHold_lo		.dsb 1
	yHold_hi		.dsb 1

	collisionPoint0 .dsb 1
	collisionPoint1 .dsb 1	
	collisionPoint2 .dsb 1
	collisionPoint3 .dsb 1
	collisionPoint4	.dsb 1
	collisionPoint5 .dsb 1
	collisionPoint6	.dsb 1
	collisionPoint7 .dsb 1[
	
	tileX					.dsb 1		
	tileY					.dsb 1	
	tile_solidity		.dsb 1[/color]
this code worked in that it did not error out and the game played but the problem of sliding sideways into one way platforms is still happening, theres still something i'm missing, i have not seen specific defines for points of the bounding box, im thinking now they're not stored in an .ASM file but are held with the specific sprites in a .DAT file... i really dont know though i'm just guessing and its not worth going any further until 4.1 comes out
User avatar
jorotroid
Posts: 152
Joined: Wed Aug 08, 2018 7:48 pm
Location: California
Contact:

Re: 8 point collision , what I know

Post by jorotroid » Sat Oct 13, 2018 9:03 am

Sorry for taking a while to respond. I had a busy last couple of days. I haven't completely figured out how the one way platforms work, but so far in my opinion, getting caught on them doesn't have anything to do with n points collision. The one way platform code is a little hard to track down, it was hard coded into a different file than the one that is labelled as one way platfrom. I think it was in the tile collision file where it checks to see if you if a tile has attribute 8, then performs some code there.
User avatar
fearspork
Posts: 35
Joined: Tue Aug 14, 2018 6:59 pm

Re: 8 point collision , what I know

Post by fearspork » Sat Oct 13, 2018 6:48 pm

jorotroid no worries take the time you like , so my wife actually had the same idea last night to alter the one way platform code in some way but when you open onewayplatform.asm it just says canPenetrate: thats it im kinda at a loss, again i dont know code but my guess is canpenetrate is a command of some sort and the actual code is held in bounds_platform_simple.asm, but that looks like some one spilled scrabble on the floor to me , i'm really pulling this from my ass at this point, this might be the end of the road for me until 4.1 comes out
User avatar
jorotroid
Posts: 152
Joined: Wed Aug 08, 2018 7:48 pm
Location: California
Contact:

Re: 8 point collision , what I know

Post by jorotroid » Sat Oct 13, 2018 7:26 pm

That canPenetrate: doesn't do anything. I don't know why it's there. It's a label that you can jump to from elsewhere in the code. The compiler essentially ignores those. Also it's the only place in the code where that appears, so in other words, nothing is ever jumping to that. If you were to make that file blank, the one way platforms would still work.

The actual one way code appears to be in Physics_Platform_Simple.asm in a few different spots. If you search for CMP #$08 you will probably find a section of code that has to do with one way platforms. Here is one example:

Code: Select all

AboveIsNotSolid:
	;; check other potentiall solid types here
	;; monsters may see other types as solid/not solid - do you want them to respect or ignore here?
	CMP #$08
	BNE AboveIsNotSolid_a
	TYA
	AND #%11110000
	CMP tileY
	BCC AboveIsNotSolid_a
	JMP AboveIsSolid
My best guess on how this works without studying it too hard is that when the player is moving up, if it collides with a one way platform, then that collision gets ignored. On the way, down it registers as solid. So the getting stuck thing probably only happens at the peak of the jump arc such that the one way tile is in the middle of the player so it goes from being free in one frame where the player is moving up, then stuck in the next frame when the player is moving down. Hopefully some one can read this and maybe figure out a fix. I'll look into it if I end up wanting one way platforms in my game, but it looks like a decent time sink at the moment.
User avatar
fearspork
Posts: 35
Joined: Tue Aug 14, 2018 6:59 pm

Re: 8 point collision , what I know

Post by fearspork » Mon Oct 15, 2018 2:44 am

if this is a problem with the one way platform, would it be possible to make right and left end caps that would have solid right and left leading edges that are solid bu still be null from the bottom and solid on top?
User avatar
jorotroid
Posts: 152
Joined: Wed Aug 08, 2018 7:48 pm
Location: California
Contact:

Re: 8 point collision , what I know

Post by jorotroid » Mon Oct 15, 2018 6:53 am

Maybe, but I have some doubts that it would be the fix you are looking for. For one thing in my tests with one way platform, I've noticed that the problem is not limited to the ends of the one way platforms as you can see in this screen I threw together in my game. It seems like maybe the variable jump script might have something to do with this because I can only seem to get stuck when I release the jump button at just the right time.

Image

Also interesting to note is that other times that I release the button, the character moves up higher than a normal jump. I think others here have posted an alternate variable jump. It might be worth checking out to see if it happens to also fix the one ways.

Another reason end caps you might just end up with the same problem with horizontal movement through those caps where the player will suddenly stop moving side to side.
User avatar
fearspork
Posts: 35
Joined: Tue Aug 14, 2018 6:59 pm

Re: 8 point collision , what I know

Post by fearspork » Mon Oct 15, 2018 1:33 pm

jorotroid, i know less now then when i started and i ran out of ideas 3 posts ago, well at least now we really honed in on the problem , specifically jump collisions with one way platforms, there must be a solution. my memory of the early 80's is fuzzy but i do remember several player characters of that size but now i'm not remembering if those games actually had one-way platforms. even wider sprites like mine existed for instance megaman was super wide to allow for a different palates to be used on the face and for different animations. 4.1 will come out soon and we can start on a whole new batch of work arounds
User avatar
jorotroid
Posts: 152
Joined: Wed Aug 08, 2018 7:48 pm
Location: California
Contact:

Re: 8 point collision , what I know

Post by jorotroid » Sat Oct 20, 2018 9:39 am

So I have been running into issues trying to add a tile type that is solid to the player, but null to monsters. I lead me to take a deeper dive into understanding how tile collisions work. I now understand more. I now understand less. In the platform module with the Physics_Platform_Simple.asm file, collision checks when an object is moving horizontally function differently than when an object is moving vertically. When an object collides with a tile horizontally in the platform module (or horizontally and vertically in the adventure module) this eventually jumps to HandleTileCollision in the TileCollision_Platform_Simple_alt.asm file. There it checks all points and if there is a collision, it runs the code in the associated tile behavior file.

With vertical movement, however, there is never a jump to HandleTileCollision so those tile behavior scripts never get called. Instead it appears that each collision point is checked one by one and the behavior of the tile is hard-coded there. I think one of the main reasons it was set up this way was to make it easier to distinguish when an object lands on the ground. At least, that is what I think is going on so far. I need to examine this more after sleep.
Post Reply