15 replies to this topic

[PacManPlus]

Hi Guys:

I started what I thought was a 'quick' project a few days ago, but I think at this point I have to let it go.
I am using 320 mode for this, and the game requires scrolling.

I cannot use ROM for the level layout (like I did with FailSafe) because the levels here expand out to 33K alone. This means I need RAM for the screen data, and that also means I need to 'shift' the screen characters left every 4 frames. Unfortunately, moving 30 characters left for 24 zones (i.e. 720 chars) takes too much time within one frame, and that leaves no time to move the 'horizontal position' back to zero within the same frame so you now 'see' the shifting of the screen. I spent the last two days (of the four) trying to get this going.

I wish there was a way to use pointers instead of actually physically moving the data, but the problem there is 'wraparound'. I can't just increment the screen RAM indefinitely so at some point each zone has to wrap around back to the starting place.

I had planned on using this as a 'Happy New Year' surprise, and I got pretty far with it, but as you will see from the attachment it's not very pleasing.

Thanks,
Bob

NOTE - BTW it looks like MESS does not show the issue. ProSystem is more accurate in this case in that you can see the issue clearly. The same thing happens on actual 7800 hardware.

Attached Files

•  Test.A78   32.13K   64 downloads

Edited by PacManPlus, Wed Dec 28, 2011 10:22 AM.

[Rybags]

Could you split the screen to 4 areas and use a different offset on each (but obviously with 4/8/whatever pixel alignment) to reduce the workload of the moves ?

[PacManPlus]

You would see each section move on different frames. The 'shift' has to occur on one frame, unfortunately.

Thank you for the input, though.

Edited by PacManPlus, Wed Dec 28, 2011 10:33 AM.

[Rybags]

But wouldn't you be using masking objects to hide the fine scroll ?

What I mean is - have the screen width more than needs to be visible by say, 32 hires pixels.

Have the 4 areas offset at 0, 8, 16, 24 pixels. So then you only have a quarter of the screen hit the left boundary at one time instead of all of the screen.

[Propane13]

Hi Bob,

I hit this sort of snag once on "another project"
Remember this? http://www.atariage....ng-6-years-ago/
I had hit a few issues when writing up the original scroll code for that guy as well.

There may be a few things you can do here.

First question-- are you updating a character map constantly, or are you using a full set of DL's?
In my scrolling demo, I had originally done a full character map, but I decided that it was more economical to just build out a set of DL's per zone, since updating a character map is very time-consuming.
Instead, I set it up such that each zone has a set of 16 DL's that each contain 8 double-pixels worth of data.
That meant that every 8 double-pixels, I had to scroll.

Now that I think about it, since I think mine is 160 mode, and yours is 320, that may mean you have to do double the work.

But, actually, the principle could still be the same-- just have more data put into the DL's.
This means that if your DL has 8 double-pixels of data, then every frame where you scroll, you just have to go through the RAM and update the HPOS.
When you get to a wrap-around, that's when things suck, but if you minimize the number of DL's, you can catch up.
It all depends on how much stuff you want to pack into a DL (maybe using character maps to make them have more data).

Another approach that I would try is to do some optimizations where you set a flag for zones that have the same data across themselves horizontally.
By this, what I mean is, there are many, many frames where you have a long string of dirt that spas the whole screen, or a long string of empty space that spans the screen.
In these instances, there is no need to do the full "barrel roll" of data. You can leave things as is. This means, only update zones that need to be updated.

Just some ideas off the top of my head-- I hope I'm not speaking gibberish.

-John

[PacManPlus]

Hi:

Thanks for the suggestions... I think the actual issue may not be clear - this is what is going on:

• I am using 8 x 8 characters, which make up the 24 zone by 30 column screen. (the extra two columns are the 'scroll areas' that are supposed to be hidden by black bars on either side - the actual game has 28 columns)
  
• Every other frame I push the horizontal starting position of each line left one pixel (I used every other frame because the 7800's 320 mode character placement is still made up of 2 pixel boundaries, so I have to move every other frame to get the same 'single pixel per frame' movement to the left that the arcade does)
  
• After 4 movements (i.e. 8 pixels) I copy all characters left one position and reset the horizontal starting position to zero.
  
• During the first horizontal starting position shift, I get the next two columns from the data (I'm using the actual arcade data for the level, and it contains two columns' worth of data at a time)
  
• During the second horizontal starting position shift, I 'decode' the data read into two rows of temporary RAM
  
• During the third horizontal starting position shift, I copy the temporary RAM into the screen RAM
  
• Finally, during the forth horizontal starting position shift, I reset it back to zero, and copy all of the characters left one position. This is where the issue happens. It takes too long to copy the data (all 720 characters)... also, this has to get done in one frame, otherwise you will see part of the screen moved and another part not at the same time.

I separate all of these steps into four frames ironically enough so I didn't run out of CPU time. :-/

The issue isn't the extreme ends (that should be covered by a black bar, but there isn't enough Maria time for that), but on the main playfield you can see the jump left one char and back again while it scrolls across the screen.

Is there any way to make the screen RAM for character mode wrap around, say, every 32 bytes? That way I don't have to physically shift any data but just update the RAM pointer for each DL.

Short of that, I don't think there is much that can be done here.
Bob

Edited by PacManPlus, Wed Dec 28, 2011 4:50 PM.

[PAC-MAN-RED]

Just my 2 cents(all I have left after the holidays), but could a RAM buffer be programmed to help with handling the data?

Illya

[Rybags]

Rough representation of my idea.

Logically split the screen into multiple horizontal strips. Each strip has more characters than actually needed for display.

The strips finely move R->L in unison but hit their boundaries and require the move operation at different times. The move operation is reduced to 25% of a full-screen operation.

If that much reduction is insufficient, then more divisions could be done.

Edited by Rybags, Wed Dec 28, 2011 6:43 PM.

[kenfused]

PacManPlus, on Wed Dec 28, 2011 4:44 PM, said:

Is there any way to make the screen RAM for character mode wrap around, say, every 32 bytes? That way I don't have to physically shift any data but just update the RAM pointer for each DL.

Short of that, I don't think there is much that can be done here.
Bob

Do you have enough RAM to hold two copies of the screen? Make each line 64 bytes in memory. When you update a position, also update a position 32 bytes ahead mod 64(wrapping around after 64). Once you have reached the end, reset to the beginning (which should already hold a copy of what was on the right 32 bytes of the screen).

Is the reason you need to move the whole screen at once because you can't mask the edges?

--Ken

edit: I would usually do it like Rybags suggestion in the prior post. I kind of dismissed it because you said you had to move the whole screen at once. But even though you are not moving it all in memory at once it should appear the same when viewed.

Edited by kenfused, Wed Dec 28, 2011 7:10 PM.

[godzillajoe]

What am I not seeing? Looks good to me.

[PacManPlus]

Rybags, on Wed Dec 28, 2011 6:41 PM, said:

Scroll1.JPG


Rough representation of my idea.

Logically split the screen into multiple horizontal strips. Each strip has more characters than actually needed for display.

The strips finely move R->L in unison but hit their boundaries and require the move operation at different times. The move operation is reduced to 25% of a full-screen operation.

If that much reduction is insufficient, then more divisions could be done.

The problem there is that If I did that (stagger the layout) the terrain wouldn't line up with each other (all four sections would be a pixel off). It would be more noticeable in the later parts of the maze where the 'buildings' go almost all the way up to the top of the screen.

@godzillajoe: MESS doesn't show the issue properly. ProSystem does exactly what the actual hardware does in this case, which is stutter the movement of the entire playfield. It's very noticeable.

@ ken: I will see if I can re-arrange memory to give this a try.

Thanks,
Bob

[NRV]

PacManPlus, on Thu Dec 29, 2011 1:50 PM, said:

Rybags, on Wed Dec 28, 2011 6:41 PM, said:

Scroll1.JPG


Rough representation of my idea.

Logically split the screen into multiple horizontal strips. Each strip has more characters than actually needed for display.

The strips finely move R->L in unison but hit their boundaries and require the move operation at different times. The move operation is reduced to 25% of a full-screen operation.

If that much reduction is insufficient, then more divisions could be done.

The problem there is that If I did that (stagger the layout) the terrain wouldn't line up with each other (all four sections would be a pixel off). It would be more noticeable in the later parts of the maze where the 'buildings' go almost all the way up to the top of the screen.

@godzillajoe: MESS doesn't show the issue properly. ProSystem does exactly what the actual hardware does in this case, which is stutter the movement of the entire playfield. It's very noticeable.

@ ken: I will see if I can re-arrange memory to give this a try.

Thanks,
Bob

I try, but I don't see a problem with Rybag's idea, but maybe that is because my background is mostly for the A8, not the 7800 . I don't get why all four sections would be a pixel off.. I could understand a char/byte.. but one pixel?

I also tested your test file in prosystem and it looks really nice (from one that played scramble at the arcades).. I had a hard time finding the "stutter" and I believe many people will be happy to overlook it, if they can have this on a 7800

Anyway the method from Ken is like the standard for horizontal scrolling, a circular or ring buffer.. like in this classic image:



Regards.

[Rybags]

The alignment shouldn't be a problem.

The "hard" part would be the fact that you're introducing new data to each section from a different offset within the level.

Also my diagram has a slight error - the strips don't need to be so large, you can truncate them on both sides.
But their "logical width" is a few characters more than whatever screen width you use.

I think with clever programming, the hurdles can be overcome. Possibly the new data can be introduced at the same time, it'd just that it gets stored in different offsets for each strip.

[kenfused]

NRV, on Thu Dec 29, 2011 4:47 PM, said:

I try, but I don't see a problem with Rybag's idea, but maybe that is because my background is mostly for the A8, not the 7800 . I don't get why all four sections would be a pixel off.. I could understand a char/byte.. but one pixel?
Regards.

yes, you stagger them by the character not pixel. You need one extra character on the end per zones you divide the moves up into. If you have 4 zones, you only move the characters in each zone every 4th time but move them 4 character positions. The more zones you use, the more memory you need and the more bytes you have to move per line.

[PacManPlus]

Ok - I got it - I understand now. Not a pixel off, but a whole character.
Sorry for being so stupid about this, guys... I should have thought of this.

BTW, I like the idea of the circular buffer, but unfortunately I don't have the extra memory.

I will split the screen into two, being that I am doing this every other frame. I will set it up to do this work every frame, but using two different counters/horizontal offsets.

Again, sorry about being dense.
Bob

Well, I guess you guys know that I'm working on 'Scramble'. I hope to have it done in a few days (barring any RL issues); this was the only thing holding me up.

Thank you all,
Bob

[PacManPlus]

Thanks guys... Scrolling issue solved.

I will be starting a separate thread now which is more descriptive of what I started.
(We can lock this, please if possible)

Thanks,
Bob