DMA Masking - an alternative to modifying CHARBASE when vertically scrolling

[RevEng]

No worries. I didn't realize you were modifying the DLL pointers to DLs, instead of the character object addresses.

 

You can add the 4 objects to all of the DLs, but then point past them with the DLL pointers for all zones except the last.

[PacManPlus]

8 hours ago, RevEng said:

No worries. I didn't realize you were modifying the DLL pointers to DLs, instead of the character object addresses.

Yeah - I have to preserve the palettes each line is using as well as they change depending on the terrain, so I would have had to move the object addresses and the Palette/Length byte.  It seemed to be just easier to move the pointers (If I'm doing something wrong, let me know).

 

8 hours ago, RevEng said:

You can add the 4 objects to all of the DLs, but then point past them with the DLL pointers for all zones except the last.

That's actually an interesting idea... I like that

Thank you; I'm going to give that a shot.

 

[RevEng]

2 hours ago, PacManPlus said:

 (If I'm doing something wrong, let me know).

Entirely right. The approach of what gets updated just depends on the game design.

 

2 hours ago, PacManPlus said:

That's actually an interesting idea... I like that

Thank you; I'm going to give that a shot.

[+bsteux]

On 3/13/2024 at 1:36 PM, RevEng said:

Entirely right. The approach of what gets updated just depends on the game design.

 

Hi,

Just to share my experience on the subject : In the multisprite.h header of cc7800, I've implemented exactly what you've been talking about : a "scrolling DLL pointers to DLs" vertical scrolling with DMA masking. As prepending the DLs with 20 additional bytes was too expensive from my point of view (It takes 20 x 16 DLs x 2 (double buffering) = 640 bytes of precious 4KB RAM just for this), I've finally decided to manually "insert" the 17 bytes in front of the last line on every "coarse" scroll, which happened not to be so expensive. It's another option depending on your memory usage. Apparently, only 17 bytes are necessary (1 5 bytes header of width 32 + 3 x 4 bytes header of width 31), drawn in mode 1 at position 160 (out of screen, so any garbage can be used).

[PacManPlus]

Ok, so someone just gave me this idea in a passing thought:

 

Do what Atari/GCC did with Xevious: Just run the display off the bottom of the screen.  THIS is the one that actually works for me.  I've already applied it, and it seems to work wonderfully!  I've added extra 'null' scanlines at the top (as I see they did the same thing), so I have 216 display lines that run *just* beyond the bottom visual area of the screen.  No worrying about adjusting the bottom zone, no overrunning Maria (which I couldn't get to work  )... 

 

I *love* this idea.  If it ends up working well (and someone doesn't think of any "gotchas"), this is what I'm going with.

 

Just wanted to put that here as another alternative.

Thanks guys!

Edited March 19 by PacManPlus

[RevEng]

Yep, that works. The wrinkle there is you need to run the visible DLL all the way to the bottom of the PAL overscan area (or have a specific PAL version that does that) so you wind up with a different amount of play area between regions. Even with the NTSC version, you need to go a lot deeper than usual, to look right with TVs that have more visible area.

[+bsteux]

20 hours ago, PacManPlus said:

Ok, so someone just gave me this idea in a passing thought:

 

Do what Atari/GCC did with Xevious: Just run the display off the bottom of the screen.  THIS is the one that actually works for me.  I've already applied it, and it seems to work wonderfully!  I've added extra 'null' scanlines at the top (as I see they did the same thing), so I have 216 display lines that run *just* beyond the bottom visual area of the screen.  No worrying about adjusting the bottom zone, no overrunning Maria (which I couldn't get to work  )... 

 

I *love* this idea.  If it ends up working well (and someone doesn't think of any "gotchas"), this is what I'm going with.

 

Just wanted to put that here as another alternative.

Thanks guys!

Yes. Excellent point. Good compromise in the end. Needs a lot of DLLs to cover the long PAL screen, but definitely the clean and lean solution.

[PacManPlus]

22 hours ago, RevEng said:

Yep, that works. The wrinkle there is you need to run the visible DLL all the way to the bottom of the PAL overscan area (or have a specific PAL version that does that) so you wind up with a different amount of play area between regions. Even with the NTSC version, you need to go a lot deeper than usual, to look right with TVs that have more visible area.

Good point, and thank you for the reminder.  It looks like the PAL version of Xevious moves the screen further down, and introduces more space between the score and the playfield.  I will do the same.