Need help with drawing player to the screen

[EchoNotation]

Hey, I'm working on my first 2600 game, but have a glitch where the top part of the player gets cut off. I thought it was because my drawing routine was too slow, as it only happens if the player is too far to the left. However, if I step through that section of the code in the Stella debugger, there is still plenty of time left over. What am I doing wrong?

 

The relevant code starts at line 83.

blindfire.asm blindfire.bin

[JetSetIlly]

You're performing the HMOVE on scanline 178 which is the same line you start drawing the player on. Move the HMOVE to another line (during the VBLANK is a good time) and you should be fine.

[EchoNotation]

Thanks! Didn't know the HMOVE took too long to update.

[+SpiceWare]

1 hour ago, EchoNotation said:

Thanks! Didn't know the HMOVE took too long to update.

 

Scanlines where HMOVE is strobed will hide the leftmost 8 pixels behind a black bar.  You can see it occur in many games like Ms. Pac-Man and Missile Command:

 

 

 

 

If the screen is black like yours it's not immediately obvious.  Use the Developer Key ALT + . or CMD + . (on a Mac) to turn on Stella's Fixed Debug Colors mode and the display will be draw using specific colors for each object:

 

 

Backbground is grey and HMOVE lines are white when using this mode:

 

 

 

 

And your game:

 

 

[EchoNotation]

Thanks for the examples, are there any workarounds for this behavior or is it just a quirk of the 2600?

[+SpiceWare]

It's a quirk of the 2600, but there is a workaround - hit HMOVE on cycle 73 or 74:

 

 

It does change how the values written to the HMxx registers will move the objects, see the HMOVE Timing information on MiniDig's Tricks page.

 

It's also not compatible with all Atari consoles, as noted here:

 

 

 

[Dionoid]

On 1/27/2021 at 6:03 AM, SpiceWare said:

It's also not compatible with all Atari consoles, as noted here:

Was that ever confirmed? I use early HMOVEs on cycle 73 all the time, and never experienced issues on any of my late PAL 2600 Jr. consoles or PAL 7800's.

I think a lot of other homebrews also use early HMOVEs.

Edited January 28, 2021 by Dionoid

[+SpiceWare]

2 hours ago, Dionoid said:

Was that ever confirmed?

 

Maybe - in the screenshot below is the special code in the 128 Pixel Bus Stuffing demo that was added to accommodate two of @alex_79's consoles that behaved differently. It does a cycle 73 HMOVE, followed by a cycle 0 RESP0, then tests player/playfield collision to decide which HMxx value needs to be used to create the 128 pixel display on his systems.

 

Quote

I use early HMOVEs on cycle 73 all the time, and never experienced issues on any of my late PAL 2600 Jr. consoles or PAL 7800's.

I think a lot of other homebrews also use early HMOVEs.

 

I've used it as well, in Stay Frosty 2. I think it just results in the fireballs and other objects being shifted by 1 pixel. Game should play OK, though the sprite masking to hide left/right wrap-around of the players would be off.