Help With bounds Handler glitch during scrolling?

[Raftronaut]

here's another idea for you though.
since if this glitch only occurs when you actually touch the edge, you could simply make your input script not allow you to touch it.

i use this code on my wall grab tile to prevent wallgrab from ever happening on the top 16 pixels and bottom 16 pixels of the screen.

; Bounds checker to not tilt the game when wallgrabbing on nametable edge.
; not used on 4-way scroller.

    ; CLC
    ; ADC Object_y_hi,x           ; are we in map bounds ?
    ; CMP #$10
    ; BCC dontMessWithGravity
    ; CMP #$D6
    ; BCS dontMessWithGravity

as imilar check could be implemented into your "move left" script that checks if you're in the first.... say 4 pixels of the screen, you could not move left anymore, thus far never touching the edge.

for a check against left, it would be something along the lines of:

LDX player1_object
LDA Object_h_speed_hi,x
CLC
ADC Object_x_hi,x
CMP #$08
BCC + ; try BCS instead of BCC if this doesnt work, i always mix this stuff up lol
RTS

tack that to the beginning of your "move left" script and it should disallow you to ever move to the first 8 pixels of the left edge of a screen.

(im not sure but you might have to factor in scroll for this and deal with the xscroll offsetting of nametables, but the basic idea is the same.)
this also would have the added benefit of that with this, you could just leave the edge code in place to kill the player when the edge is touched.
that way you could never touch it by driving into the edge, but if a solid object would push you, it would still push you all the way to the edge and then kill you by touching it.

Wow! This is an excellent solution Mugi! I previously had thought limiting the players ability to move into that left area would prevent the screen wrap, even 4-8 pixels even. I hadn't thought to actually add this into my input left code. That is really really smart! I hadn't thought to add anything into the left input script, Even after I had implemented Dale's code fix for disabling inputs during cutscenes (when player is under cuttercross's dissapear tile) into my actual input scripts (including your pause function, which works great btw mugi). I will have a chance to try this out tonight, I hope to report back with some good news.

Dale, thank you for the insight on this. Yes, it is true under all conditions that the player would never need to cross left into a new screen. The player would only ever cross the threshold to the right in order to continue progress. I will give your script a shot when I get home as well, before messing with Mugi's input suggestions so I can confirm this would do the trick. It should fix the underlying problem with the shooter module itself, at least, for 98% of the examples of licensed era nes shooters, the player would never pass backwards like that. At least not in the Gradius/TwinBee school of one-directional scrolling.

I am getting really close to releasing version 2.0 of the demo, hopefully by the end of the month. I am really looking forward to sharing all these great changes i've made in the past few months! Both the gameplay and presentation have been greatly improved.

 

[Raftronaut]

here's another idea for you though.
since if this glitch only occurs when you actually touch the edge, you could simply make your input script not allow you to touch it.

i use this code on my wall grab tile to prevent wallgrab from ever happening on the top 16 pixels and bottom 16 pixels of the screen.

; Bounds checker to not tilt the game when wallgrabbing on nametable edge.
; not used on 4-way scroller.

    ; CLC
    ; ADC Object_y_hi,x           ; are we in map bounds ?
    ; CMP #$10
    ; BCC dontMessWithGravity
    ; CMP #$D6
    ; BCS dontMessWithGravity

as imilar check could be implemented into your "move left" script that checks if you're in the first.... say 4 pixels of the screen, you could not move left anymore, thus far never touching the edge.

for a check against left, it would be something along the lines of:

LDX player1_object
LDA Object_h_speed_hi,x
CLC
ADC Object_x_hi,x
CMP #$08
BCC + ; try BCS instead of BCC if this doesnt work, i always mix this stuff up lol
RTS

tack that to the beginning of your "move left" script and it should disallow you to ever move to the first 8 pixels of the left edge of a screen.

(im not sure but you might have to factor in scroll for this and deal with the xscroll offsetting of nametables, but the basic idea is the same.)
this also would have the added benefit of that with this, you could just leave the edge code in place to kill the player when the edge is touched.
that way you could never touch it by driving into the edge, but if a solid object would push you, it would still push you all the way to the edge and then kill you by touching it.

Yeah, Something is certainly wrong when scrolling, the following code prevented the player from moving left while scrolling. When the scrolling stopped the movement went back to normal. Another odd effect, pressing left would intermittently fire a projectile. when I changed the part in your instructions: " BCS instead of BCC " to try it out, pressing left invariably fires a projectile. The StartMoving player1_object, MOVE_LEFT macro must have some other function needed to move left while scrolling. Here is the Move left script:

    LDX player1_object
    LDA Object_h_speed_hi,x
	CLC
    ADC Object_x_hi,x
    CMP #$08
    BCC + ; try BCS instead of BCC if this doesnt work, i always mix this stuff up lol
    RTS
 

 StartMoving player1_object, MOVE_LEFT
  RTS

 

[Raftronaut]

The Move left script appears to be pointing to this Macro:

MACRO StartMoving arg0, arg1
	; arg0 object to move
	; arg1 direction
	
	;; This macro uses the built in physics found in default physics scripts.
	;; Which observes acceleratoin and deceleration as long as bounds and tile collision.
	;; It is not a direct movement, but rather turns on a check for whether or not
	;; the object should move.
	
	;; Keep in mind, this does not alter the facing-direction of the object, just
	;; the actual motion.
	
	;constant definitions for direction are:
		;MOVE_RIGHT	= #%11000000
		;MOVE_LEFT 	= #%10000000

 

[Mugi]

the example code was meant to be more like a quideline for the idea than an actual code (im unsure if it works like that with horizontal movement, as mine is meant for vertical, where you dont have moving nametable issues due to lack of vertical scroll) anyway, put a + after the RTS, that was missing from the example i posted, which should cause your movement script to not execute properly.

and yeah, i was prettysure that the scroll will mess it up because the code simply checks if you're in the leftmost 8 pixels of a nametable (not screen) so without factoring in the xscroll position, it will just not work.
in plain words, you will have to make the code compare against the leftmost 8 pixels of the camera position, not the current nametable.

i'll have to see if i have time to actually toy with this and come up with a functional code (assuming dale doesnt jump into it while im sleeping ) but no promises really, im drowning in work with DS as it is.

that said, i do believe it's an idea worth pursuing until someone actually figures out what's going on in the edge code, because getting this script to work would in theory solve all the issues you have, in excange of losing few pixels worth of movement
space on the play area. Which honestly, i dont think is a bad tradeoff

 

[Raftronaut]

I see, I guess I misunderstood

I need to go back and try to finish nerdy nights so I can understand this stuff better. Player coordinates, x and y axis stuff is outside of my pedantic JMP commands. I haven’t even successfully written my first addition or substraction code, or written any compare code.

Learning this stuff is an incredibly slow process for me. It’s worth it though! I just hope sometime I can be as helpful to others get through their growing pains in NESmaker. Ha, sometimes I feel bad as far as having anything to offer the community, the only thing I’ve been able to assist other with this far is diagnosing famitracker issues or offering tips on sound design. I’ve got Aspect under control!

My favorite game of all time is Gradius, so at least I hope through my persistance plowing through this issue I will be helping other nesmakers make more games similar to the one I love.

Ok I’m rambling here. Working my second shift of the day and wasting time waxing nes. Hahaha. I really do love spending my mental energy on making nes games!!

 

[Raftronaut]

hmmmmmmmm,


lines 143 to 166 in TileCollisions.asm has some logical shift right commands that could be sending the bounds value out of range:

HandleSolidCollision:
	LDA screenFlags
	AND #%00000100 ;; is it autoscrolling?
	BEQ + ;; not autoscrolling
	;;; is auto scrolling
	CPX player1_object
	BNE +
	JSR CheckAutoScrollLeftEdge
	RTS 
+ ;; not auto scrolling.

	LDA xPrev
	STA xHold_hi
	LDA yPrev
	STA yHold_hi
    TYA
    STA tempy
    LDA Object_edge_action,x
    LSR
    LSR
    LSR
    LSR
    BEQ doNothingAtSolid
    TAY

I could be way off, but here may be a key to finding where the overflow happens at the edge..