4 replies to this topic

[Primordial Ooze]

I am having a small problem with my code. When i move my player graphic, if i move it towards the far left, there is a "cover" of sorts that causes my player sprite to become hidden. I can't seem to figure out the problem. I have attached my code for reference. Any help in this matter would be appreciated.

Sincerely,

Primordial Ooze

[attachment=157830:MazeGame.zip]

[Nukey Shay]

What you are seeing is the timing difference between erasing the sprite (which happens on every scanline), and drawing the sprite (which happens only where the current coordinates are). Notice how when other things are present in the scanline, like drawing the black object, that the "invisible" area increases. There's nothing blocking the view...it's just not being drawn quick enough. The electron beam on the display has already passed that point. A simple adjustment keeps the sprite from being erased on scanlines where it IS visible...

SkipActivatePlayer

	lda #0

	ldx visibleplayerline		; if the visibleplayerline is zero

	beq FinishPlayer		; don't draw the player
    
	lda PlayerSprite-1,x		;otherwise, load the correct line from PlayerSprite
					; section below... it's off by 1 though, since at zero
					; we stop drawing

	dec visibleplayerline		; and decrement the visibleplayerline by 1

FinishPlayer
	sta GRP0			; put that line as player graphic

That gets you part of the way there...but you'll notice a slight "ripple" effect. That ripple is exactly where the decision to draw or not draw is being made. To avoid it, you need to optimise so that decisions are being made sooner within the given scanline...such as making all of them and THEN performing a WSYNC & drawing the objects.

[Nukey Shay]

BTW multiple reads done to SWCHA are generally a bad idea (since the state is allowed to change between them). Another quick fix would be to LDA SWCHA, and then use ASL's and check the carry status for each of the 4 directions.

[supercat]

Nukey Shay, on Mon Jun 7, 2010 12:29 PM, said:

What you are seeing is the timing difference between erasing the sprite (which happens on every scanline), and drawing the sprite (which happens only where the current coordinates are).

Note that this sort of 'cover' may sometimes be a useful effect, especially with games that allow sprites to wrap the screen. If HMOVE is hit every scan line, single-width sprites that wrap aren't really a problem in any case, but if one is hiding HMOVE bars, or if one is using wider sprites, having the sprite shape set at one edge of the screen and zeroed at the other may be useful.

[Nukey Shay]

I forgot to mention that another way to correct the problem would be to vertically-delay drawing the sprite...so that writes to the GR register don't take effect until the next encounter (so it doesn't matter what cycle on a scanline it is written to).
But IMO it's easier just to delay calling WSYNC until you have all relevant sprite info ready for the registers for that scanline...IF there are only a couple of objects anyway.

Without changing much of the existing program, the ripple can be avoided by doing this:

Remove the store to WSYNC at the top of Scanloop.
Remove the store to ENAM1 at the top of Finishball.
Just above SkipActivatePlayer, use the X register to load and store instead of A.
Just below SkipActivatePlayer, write A to WSYNC and ENAM1.
Also skip erasing the GRP0 on every line as mentioned previously.

That ensures that GRP0 is updated before the electron beam gets too far into drawing the current scanline No ripple unless PLAYERLEFTBOUNDRY is less than 2.

If you want to lower PLAYERLEFTBOUNDRY, you can set it to 1...then remove the LDA #0 when deciding when to draw the player and just use LAX on the next line instead. Movement or repositioning logic would need editing if you wanted the player to be able to move right to the edge (PLAYERLEFTBOUNDRY=0).

Edited by Nukey Shay, Mon Jun 7, 2010 9:07 PM.