Forums

I've looked at the scrolling stuff some more, here are my observations:

Depending on the lower 3 bits of the H scroll register, some 'junk' graphics are scrolled in on the leftmost edge (instead of the last column in the name table wrapping to this location)
The junk pixels use these values: (shown as if register #8 = $07)

0x0F, 0x00, 0x0F, 0x00, 0x00, 0x00, 0x00

... all taken from the background palette. Register #7 has no effect on the colors displayed.

As for the rendering 'bug' in Master Gear, it probably draws things like SMS Plus used to.
My code ended up treating the partially drawn leftmost column as column 0, which made it count 24 columns one column too early, hence the scrolling was offset by one.
This doesn't show up in Golvelius since the lower 3 bits of the H scroll value are zero, and Gauntlet masks the edge of the right 8 columns with sprites. So it's fairly hard to notice.

The problem fixed itself when I added in the code for drawing in the junk at the left edge, since the loop for tile drawing always started at zero.

My Homepage

Quote

> I've looked at the scrolling stuff some more, here are my observations:
> Depending on the lower 3 bits of the H scroll register, some 'junk' graphics are scrolled in on the leftmost edge (instead of the last column in the name table wrapping to this location)
> The junk pixels use these values: (shown as if register #8 = $07)
>
> 0x0F, 0x00, 0x0F, 0x00, 0x00, 0x00, 0x00
> ... all taken from the background palette. Register #7 has no effect on the colors displayed.

I hacked Ghost House not to hide that columns and:

1.
You can see sprites getting out from the right on the left column.

2.
The rest are various garbage lines with patterns, but not the same one as yours. So we can assume this depends on various memory state.
However something weird is that some different tile lines (in the left columns) moves along with the sprites on that full line.

Exemple:



 Left most -  Others colums ...


 xxxxxxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx


 xxxxx-xx   xxxxxxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx


 xx.xxxxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx


 xxxxxoxx   xxxxxxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx


 xxxxxxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx


 ooooooo   xxxxxxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx   xx----xxx


 xxxxxxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx   x--------xx


 xxx_xxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx   xxxxxxxx   xx-x-xxxx


 ^^^                                                                                            ^^^^ sprite


 semi garbage

If the sprite moves up (jump, etc..) the ooooooo line on the left columns usually moves as well.
That is for all sprites, so we can represent sprites y position with that.

Useless to know, so pretty cool.

Quote

> 1.
> You can see sprites getting out from the right on the left column.

You mean sprites with an X position close to 0xFF wrap to the left edge?
I'm pretty sure I couldn't see this in my Interactive Sprite Test demo.
(maybe having the screen partially scrolled would have shown something)

Quote

> However something weird is that some different tile lines (in the left columns) moves along with the sprites on that full line.

This makes perfect sense - on the Genesis, if you hack a SMS game to use the 320x192 display, the 'extra' 8 columns are filled with the same repeating sprites, that seem to match the real sprites on-screen.
An interesting glitch is that this adds up to the # of sprites per line, so you usually get bad flicker.

Quote

> If the sprite moves up (jump, etc..) the ooooooo line on the left columns usually moves as well.
> That is for all sprites, so we can represent sprites y position with that.

Ok, I think I see what you mean. I'll check this out too, just to make sure I am doing things right.
Given the overhead of drawing sprites, I probably won't emulate this but will add it to my VDP docs.

Quote

> Useless to know, so pretty cool.

Agreed. ;)

My Homepage

Quote

> You mean sprites with an X position close to 0xFF wrap to the left edge?
> I'm pretty sure I couldn't see this in my Interactive Sprite Test demo.
> (maybe having the screen partially scrolled would have shown something)

Yes. I noticed that with Ghost House bats.

Author	Message
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	More scrolling Posted: Fri Aug 03, 2001 12:05 am
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	I've looked at the scrolling stuff some more, here are my observations: Depending on the lower 3 bits of the H scroll register, some 'junk' graphics are scrolled in on the leftmost edge (instead of the last column in the name table wrapping to this location) The junk pixels use these values: (shown as if register #8 = $07) 0x0F, 0x00, 0x0F, 0x00, 0x00, 0x00, 0x00 ... all taken from the background palette. Register #7 has no effect on the colors displayed. As for the rendering 'bug' in Master Gear, it probably draws things like SMS Plus used to. My code ended up treating the partially drawn leftmost column as column 0, which made it count 24 columns one column too early, hence the scrolling was offset by one. This doesn't show up in Golvelius since the lower 3 bits of the H scroll value are zero, and Gauntlet masks the edge of the right 8 columns with sprites. So it's fairly hard to notice. The problem fixed itself when I added in the code for drawing in the junk at the left edge, since the loop for tile drawing always started at zero. My Homepage

Bock Site Admin Joined: 08 Jul 2001 Posts: 8661 Location: Paris, France	Posted: Fri Aug 03, 2001 1:29 pm
	Quote > I've looked at the scrolling stuff some more, here are my observations: > Depending on the lower 3 bits of the H scroll register, some 'junk' graphics are scrolled in on the leftmost edge (instead of the last column in the name table wrapping to this location) > The junk pixels use these values: (shown as if register #8 = $07) > > 0x0F, 0x00, 0x0F, 0x00, 0x00, 0x00, 0x00 > ... all taken from the background palette. Register #7 has no effect on the colors displayed. I hacked Ghost House not to hide that columns and: 1. You can see sprites getting out from the right on the left column. 2. The rest are various garbage lines with patterns, but not the same one as yours. So we can assume this depends on various memory state. However something weird is that some different tile lines (in the left columns) moves along with the sprites on that full line. Exemple: Left most - Others colums ... xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxx-xx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xx.xxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxoxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx ooooooo xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xx----xxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx x--------xx xxx_xxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xx-x-xxxx ^^^ ^^^^ sprite semi garbage If the sprite moves up (jump, etc..) the ooooooo line on the left columns usually moves as well. That is for all sprites, so we can represent sprites y position with that. Useless to know, so pretty cool.

Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Posted: Fri Aug 03, 2001 4:43 pm
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Quote > 1. > You can see sprites getting out from the right on the left column. You mean sprites with an X position close to 0xFF wrap to the left edge? I'm pretty sure I couldn't see this in my Interactive Sprite Test demo. (maybe having the screen partially scrolled would have shown something) Quote > However something weird is that some different tile lines (in the left columns) moves along with the sprites on that full line. This makes perfect sense - on the Genesis, if you hack a SMS game to use the 320x192 display, the 'extra' 8 columns are filled with the same repeating sprites, that seem to match the real sprites on-screen. An interesting glitch is that this adds up to the # of sprites per line, so you usually get bad flicker. Quote > If the sprite moves up (jump, etc..) the ooooooo line on the left columns usually moves as well. > That is for all sprites, so we can represent sprites y position with that. Ok, I think I see what you mean. I'll check this out too, just to make sure I am doing things right. Given the overhead of drawing sprites, I probably won't emulate this but will add it to my VDP docs. Quote > Useless to know, so pretty cool. Agreed. ;) My Homepage

Bock Site Admin Joined: 08 Jul 2001 Posts: 8661 Location: Paris, France	Posted: Fri Aug 03, 2001 4:53 pm
	Quote > You mean sprites with an X position close to 0xFF wrap to the left edge? > I'm pretty sure I couldn't see this in my Interactive Sprite Test demo. > (maybe having the screen partially scrolled would have shown something) Yes. I noticed that with Ghost House bats.

Forums

View topic - More scrolling