More scrolling issues

[Brian's Man Cave]

Still working on scrolling… i started this new game based on a C64 game. It has a person walking on a street. My scrolling seems to work fine when I go in one direction, but when I turn the other direction, the background breaks up. Any idea why? 

 

Edited September 14, 2021 by Brian's Man Cave

[+DZ-Jay]

It looks like you are reading the wrong part of the screen data to update the new column.

 

Perhaps you are still advancing the pointer instead of moving backwards when you change directions ... ?

Edited September 14, 2021 by DZ-Jay

[Brian's Man Cave]

Here is the code I am using:

 

LANDSCAPE_WIDTH = 100 'increase x 20

muv =  80 'increase x 20

wait
SCREEN screen_0, muv, 0, BACKGROUND_COLUMNS, BACKGROUND_ROWS, LANDSCAPE_WIDTH

 

game_loop:

if cont1.left then 
wait
wait
wait
scroll 1,1,1
muv = muv - 1
SCREEN screen_0, muv, 0, 1, BACKGROUND_ROWS, LANDSCAPE_WIDTH
'wait
end if

if cont1.right then 
wait
wait
wait
scroll 1,1,2
muv = muv + 1
if muv >= 99 then muv = 80 'increase x 20

SCREEN screen_0, muv, 19, 1, BACKGROUND_ROWS, LANDSCAPE_WIDTH
'wait
end if

wait

goto game_loop

[carlsson]

Do you need a corresponding IF statement for the case muv =< 1 or similar? Would it make any difference if muv is declared as SIGNED in case it ever goes below 0?

[+nanochess]

The third SCREEN statement (the one for going right) should have origin offset as muv + 19 instead of only muv.

 

This is because when going to the right you are inserting the right column, so the correct offset for SCREEN is muv + 19.

 

And when going to left you are inserting the left column, so the correct offset for SCREEN is muv (so this one is correct).

 

BTW the first two numbers for SCROLL should be zero, as you aren't doing any pixel scrolling.

 

Edited September 15, 2021 by nanochess

[Brian's Man Cave]

Thank you Nanochess!! I had a feeling I was suppose to advance something by 19 but couldn't figure out what.

[Brian's Man Cave]

I forgot to ask... is it possible to only scroll the top half the screen? The bottom half will have game stats that I don't want to scroll

 

Edited September 15, 2021 by Brian's Man Cave

[skywaffle]

Unfortunately SCROLL ,,X shifts the entire screen.  If you plan on pixel based scrolling instead of 8 pixel increments this would also offset your game stats as well.

[skywaffle]

You could possibly come up with a work around, such as displaying the stats if the screen is stationary for a length of time, and then blanking them out once the screen begins to scroll again.  Maybe not though if there is a lot of continual scrolling.

[carlsson]

Isn't the coarse scrolling done by loops of copying cards? I'm thinking if the assembly code generated by the SCROLL command can be copied and manually inserted into the program, altered for number of rows to copy cards. If no soft scrolling is desired, the routine probably can be simplified further. While this would break the traditional rules in the contests so far, a game developed outside of those would not have any restrictions.

 

But yes, normally you probably want smooth scrolling and then the pixel offset applies to the entire screen whether or not you scroll all the content or not. If you don't scroll the content, the remaining part will be jagged and move back to its original position every 8 frames. Perhaps there is a game where this really could be used, part of the screen scrolls along smoothly and part of it is stuck in a jagging motion.

[+nanochess]

5 hours ago, Brian's Man Cave said:

I forgot to ask... is it possible to only scroll the top half the screen? The bottom half will have game stats that I don't want to scroll

 

Carlsson is right.

 

As you aren't using pixel-by-pixel scrolling, but scrolling per card, you can use the SCREEN statement to copy (and scroll) only half of the screen.

[Brian's Man Cave]

So how does that work? are there any examples anywhere of how to do that?

[carlsson]

Can you use SCREEN to copy what's already on BACKTAB or does that command only work to copy from ROM to BACKTAB? As long as you don't manually plot or change items on the BACKTAB, I suppose it would yield the same result but if something would change along the way, I would imagine a modified SCROLL command would be better suited.

 

I suppose if you use SCREEN you could set the origin pointer +/- one decle (word) in order to read from a different area in ROM but I've never done that.

 

Then again I looked into the epilogue and figured out that even the coarse scrolling is carefully timed and divided into two passes for top 6 rows and bottom 6 rows in order to be ahead of the STIC, which means that any custom extension you would develop would have to go here, like adding a parameter to the SCROLL command to handle less than 6 rows per sweep or perhaps only do the top half. It probably is doable but not trivial.

 

I made a brief test trying to copy an area from BACKTAB to BACKTAB. After a few tries, I managed to get it to work!

  MODE 1

  SCREEN screen_cards,0,110,5,5,5

  WHILE CONT.button=0:WEND
  WHILE CONT.button<>0:WEND

  REM  SCREEN $026E,0,21,5,5,20
  REM Note that 21 is translated to $0200 (base addr of BACKTAB) + decimal 21
  REM Also note that the BACKTAB is 20 columns, not 5 like the source data

 ASM MVII #$026E,R0 
 ASM PSHR R0
 ASM MVII #$215,R0
 ASM PSHR R0
 ASM MVII #5,R0
 ASM PSHR R0
 ASM MVII #5,R0
 ASM PSHR R0
 ASM MVII #20,R0
 ASM CALL CPYBLK2

loop:  GOTO loop

screen_cards:
  DATA $2608,$2610,$2608,$2618,$2620
  DATA $2610,$2608,$2608,$2618,$2620
  DATA $2608,$2618,$2608,$2610,$2628
  DATA $2618,$2608,$2610,$2610,$2610
  DATA $2620,$2610,$2608,$2618,$2608

Edited September 16, 2021 by carlsson

[carlsson]

Ok, here is a variant of the above program which moves a block 5x5 across the screen. Note that the simulated SCREEN command copies 19 columns and 5 rows from BACKTAB position 1 to position 0, and that the BACKTAB contains 20 columns. The second loop is to clear the rightmost position and is where you'd copy in new data from ROM.

 

There may be a method to do this using the SCREEN command itself, but I didn't find the syntax to insert anything else but a ROM label which is why I copied and modified the ASM output for a custom function. It isn't meant to be universal or perfect, but perhaps a nod in the right direction.

 

scroll-backtab.bas

[+DZ-Jay]

3 hours ago, carlsson said:

Can you use SCREEN to copy what's already on BACKTAB or does that command only work to copy from ROM to BACKTAB? As long as you don't manually plot or change items on the BACKTAB, I suppose it would yield the same result but if something would change along the way, I would imagine a modified SCROLL command would be better suited.

 

I suppose if you use SCREEN you could set the origin pointer +/- one decle (word) in order to read from a different area in ROM but I've never done that.

 

Then again I looked into the epilogue and figured out that even the coarse scrolling is carefully timed and divided into two passes for top 6 rows and bottom 6 rows in order to be ahead of the STIC, which means that any custom extension you would develop would have to go here, like adding a parameter to the SCROLL command to handle less than 6 rows per sweep or perhaps only do the top half. It probably is doable but not trivial.

 

I made a brief test trying to copy an area from BACKTAB to BACKTAB. After a few tries, I managed to get it to work!

  MODE 1

  SCREEN screen_cards,0,110,5,5,5

  WHILE CONT.button=0:WEND
  WHILE CONT.button<>0:WEND

  REM  SCREEN $026E,0,21,5,5,20
  REM Note that 21 is translated to $0200 (base addr of BACKTAB) + decimal 21
  REM Also note that the BACKTAB is 20 columns, not 5 like the source data

 ASM MVII #$026E,R0 
 ASM PSHR R0
 ASM MVII #$215,R0
 ASM PSHR R0
 ASM MVII #5,R0
 ASM PSHR R0
 ASM MVII #5,R0
 ASM PSHR R0
 ASM MVII #20,R0
 ASM CALL CPYBLK2

loop:  GOTO loop

screen_cards:
  DATA $2608,$2610,$2608,$2618,$2620
  DATA $2610,$2608,$2608,$2618,$2620
  DATA $2608,$2618,$2608,$2610,$2628
  DATA $2618,$2608,$2610,$2610,$2610
  DATA $2620,$2610,$2608,$2618,$2608

 

The timing is critical.  The important point is to start as early as possible, and try to copy from left-to-right, top-to-bottom, to keep ahead of the STIC fetching data to build its frame buffer.  One should be able to do this in pure IntyBASIC with a very tight loop.  You could also leverage the SCREEN statement, which allows you to issue a window (i.e., a block or region smaller than the full area) of either the source or the destination.  That's what the additional origin and offsets are for.

 

The SCREEN statement is optimized for copying a block of memory.  It's only drawback is that it has a significant overhead in setting itself up for the copy loop.  The copy loop itself is very fast, but the initialization is a drag, making repeated use of the SCREEN statement within the same frame a bit fraught.  For that you'll have to come up with a way to copy the multiple blocks progressively  -- that is, ensuing that you are always copying the the rows from left-to-right, top-to-bottom, leading the raster scan.  (I did some work on this for another project that required copying multiple regions of the screen at once, but it's all in Assembly.)

 

However, for cases such as @Brian's Man Cave, where he only wants to copy one single block (i.e., the top portion of the screen, without the bottom rows), it should be perfectly adequate.

 

    -dZ.

Edited September 16, 2021 by DZ-Jay

[Zendocon]

12 hours ago, Brian's Man Cave said:

So how does that work? are there any examples anywhere of how to do that?

In @nanochess Advanced Game Programming book, there's the example posted on pages 270-271, if you're not allergic to Assembly Language.  I'm panning the whole screen upward, one whole card at a time, barring the top two rows.