Brian's Man Cave Posted September 14, 2021 Share Posted September 14, 2021 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted September 14, 2021 Share Posted September 14, 2021 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Brian's Man Cave Posted September 14, 2021 Author Share Posted September 14, 2021 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 Quote Link to comment Share on other sites More sharing options...
carlsson Posted September 15, 2021 Share Posted September 15, 2021 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? Quote Link to comment Share on other sites More sharing options...
+nanochess Posted September 15, 2021 Share Posted September 15, 2021 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
Brian's Man Cave Posted September 15, 2021 Author Share Posted September 15, 2021 Thank you Nanochess!! I had a feeling I was suppose to advance something by 19 but couldn't figure out what. Quote Link to comment Share on other sites More sharing options...
Brian's Man Cave Posted September 15, 2021 Author Share Posted September 15, 2021 (edited) 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 Quote Link to comment Share on other sites More sharing options...
skywaffle Posted September 15, 2021 Share Posted September 15, 2021 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. Quote Link to comment Share on other sites More sharing options...
skywaffle Posted September 15, 2021 Share Posted September 15, 2021 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. Quote Link to comment Share on other sites More sharing options...
carlsson Posted September 15, 2021 Share Posted September 15, 2021 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. Quote Link to comment Share on other sites More sharing options...
+nanochess Posted September 16, 2021 Share Posted September 16, 2021 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. Quote Link to comment Share on other sites More sharing options...
Brian's Man Cave Posted September 16, 2021 Author Share Posted September 16, 2021 So how does that work? are there any examples anywhere of how to do that? Quote Link to comment Share on other sites More sharing options...
carlsson Posted September 16, 2021 Share Posted September 16, 2021 (edited) 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 Quote Link to comment Share on other sites More sharing options...
carlsson Posted September 16, 2021 Share Posted September 16, 2021 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 Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted September 16, 2021 Share Posted September 16, 2021 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Zendocon Posted September 16, 2021 Share Posted September 16, 2021 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.