I've been watching many videos of BASIC programs and many of them actually have scrolling backgrounds. How is this achieved? Would it have to coded in assembly or is there a technique in BASIC? This is popular in space-shooter programs.
Where are these videos?
I could conceive of a way to do "choppy" scrolling without ASM, but not smooth scrolling (without wasting all of your sprites).
Search Youtube for "family basic nnd". These are videos taken from Nico Nico Douga and there are over a hundred sample videos of BASIC programs. And yes, this is pixel-level scrolling. Using sprites and PRINT CHR$ would be impossible. This is smooth pixel-level scrolling using 2 BG screens. I would assume it has to be in V3 because in V3 you can have 2 BG screens in memory.
I've seen lots of those NND compilations but I don't remember any of them scrolling. Do you remember which one it is?
I'm not sure how to do it in assembly though. V3 seems to use SCREEN to switch between the two nametables. Syntax is:
SCREEN display,active
where "display" is screen number (0 or 1) used to choose which screen to display and "active" is which screen (0 or 1 again) the cursor is placed on (you can type stuff on the screen you can't see). If you get stuck you can press CTR+D to restore both to screen 0.
But the question is if V3 keeps it's scroll position buffered somewhere in memory so it can be controlled at will. Else it will keep resetting the scroll position to the beginning of either screen 0 or 1 every frame. Also scroll position must be set in a vertical blanking.
Here's a good example showing 2 layers of scrolling: https://www.youtube.com/watch?v=iis_xxyw6xs at 32:40
(as a bonus, check out the awesome little game at 21:08. It's the best and most original BASIC game I've ever seen!)
Most of the space-shooter games I've seen have scrolling backgrounds.
Ah parallax scrolling even. :) I think auto scrolling shmups like this (especially if it's just a starry background) can get away with "fake" scrolling by simply moving the BG tiles (the stars). But it does look really smooth!
"Real" scrolling basically means moving the scroll position into the second screen, then redraw the first screen before it wraps around into the first one again. Family BASIC is hardwired to a horizontal-scroll setting (AKA vertical mirroring), which means the two screens are aligned horizontally and if you try to scroll vertically instead you will just wrap around the current screen (a mirror).
Edit: But the stars moves very smoothly. BG tiles can't be moved pixel by pixel like that on a Famicom, and the stars can't be sprites either. Maybe he does use the scroll register somehow?
It has to be the scroll register. I don't know why you wouldn't be able to manipulate it. I can't explain the paralax stars (the upper layer). I don't know how you'd do that without using sprites.
You don't need two screens to do smooth vertical scrolling if you hide the topmost and bottom-most rows of tiles (which are often cut-off by TVs anyway). You move the first screen down smoothly for a single row, then redefine your name tables so that the every row shifts up by one and the top row gets wrapped around to the bottom, and then you reset your scroll register so it's at the very top again. RPGs do this for world maps often.
I'm having fun with these videos, though (when I have the time). A bunch of them apparently are from a magazine called マイコンBASICマガジン. I'm trying to find scans of the magazine, but have only found one so far: April 1988 (https://ia802604.us.archive.org/10/items/mycom-basic-magazine-1988-04/BasicMagazine1988-04.pdf). It has three FB listings in it (two sports and one action), although I haven't typed up any of them. I did find a nice resource site that indexes the names of the programs found in each issue: link (http://www.north-wind.ne.jp/~yoshino/bmpg/search.php?sY=1988&sM=04). Has page numbers, too, which helped me find the program listings in that one scan.
The game we're talking about is called "Metal Arms" and was published in the January 1990 edition of the magazine.
Oh thanks for those links! We should post programs that we have typed up in the forum, so that they can just be copy-pasted in the future.
Quote from: UglyJoe on August 22, 2015, 05:46:42 am
It has to be the scroll register. I don't know why you wouldn't be able to manipulate it.
You just have to figure out where Famibe keeps its scroll coordinates I guess. Writing to &H2005 directly wouldn't work.
Quote from: UglyJoe on August 22, 2015, 05:46:42 am
You don't need two screens to do smooth vertical scrolling if you hide the topmost and bottom-most rows of tiles (which are often cut-off by TVs anyway). You move the first screen down smoothly for a single row, then redefine your name tables so that the every row shifts up by one and the top row gets wrapped around to the bottom, and then you reset your scroll register so it's at the very top again. RPGs do this for world maps often.
Yeah I was just explaining the basics of scrolling.
Edit:It seems zero page variable &H00E4 holds the Y-scroll position in V3. Poking it changes the vertical scroll position but I couldn't do any loops that scrolls, kept getting IL-errors.
POKE &HE4,50
But for vertical scrolling... It seems to just write zero to it (since it never needs to scroll vertically), it doesn't seem to use a place in RAM for the X-position.
Edit: Family BASIC V2.1 has both Y and X scroll positions in RAM! They are in $009D and $0069 respectively.
10 A=0
20 FOR I=0 TO 100
30 A=A+1
40 POKE &H9D,A
50 POKE &H69,A
60 PAUSE
70 NEXT
Scrolls diagonally as you hold down a key.
Wow you're a genius, P! Thanks for digging this up. Although the code doesn't work in V3, I'm eagerly awaiting to see the V3 version. ;D I feel like these techniques, as well as other assembly techniques, should have been mentioned in Family BASIC documentation. I'm sure NES Dev people would already know stuff like this, but the beginners like myself would never know about stuff like this.
I knew that they must write the current desired scroll position to $2005 (the scroll register) every frame or else the screen would jump around randomly (because other things affect the scroll register). So I just looked in the ROM what they wrote to it and it turned out to be the contents of the RAM addresses $009D and $0069 (later I realized that Enri had it all documented (http://www43.tok2.com/home/cmpslv/Famic/Fambas.htm) :-[).
V3 seems to write to $2005 on several occasions though so it might need to be looked at. But try the same code but use only one poke (for Y-scroll) and see if you can scroll vertically (also change Y-scroll variable to $E4 in V3):
10 A=0
20 A=A+1
40 POKE &HE4,A
50 PAUSE
60 GOTO 20
This code isn't tested but see if it works for you. Hold a key to scroll down.
Woah! It worked P! This is awesome! What a cool effect! Where did you learn stuff like this? That link you provided won't open for me.
I modified the code to show the status of A:
10 A=0
20 A=A+1
30 POKE &HE4
40 PAUSE:LOCATE 10,10:PRINT A
50 GOTO 20
After A is 255, the screen has wrapped around in a full cycle. Also what's interesting is that the print of A only stays on the same line 8 counts, then takes another line even though the location specified is 10,10.
EDIT: I understand why the number takes a new line every 8 counts - it's because it moves the entire screen 1 pixel at a time and once 8 pixels have been moved, a new line has been made. 8 pixels is the height of a line. So the location 10,10 is correct.
I tried the examples but found that they didn't work when I removed the PAUSE statement. I got around this by poking the scroll registers directly. Here's my v2.1a code listing for generating a star field and then scrolling it vertically indefinitely:
10 CLS
20 FOR I=1 TO 30
30 RX=RND(27):RY=RND(24)
40 IF SCR$(RX,RY)<>" " GOTO 30
50 LOCATE RX,RY:PRINT CHR$(205)
60 NEXT
150 A=0
200 REM PAUSE 1
250 POKE &H2005,0
300 POKE &H2005,A
500 A=A+1
600 IF A>239 THEN A=0
650 GOTO 200
You can unREM line 200 to make the stars scroll a bit more slowly. I stole the starfield code from a book, but will have to rewrite it at some point since you can't use LOCATE to draw onto all portions of the background (hence the big black gap you see between the bottom and top of the starfield when scrolling).
I just tried this in V3 and it works well. Very impressive. So is horizontal scrolling possible? I noticed that when I REM line 250, it scrolls diagonally.
Quote from: zmaster18 on August 23, 2015, 09:27:11 am
I just tried this in V3 and it works well. Very impressive. So is horizontal scrolling possible? I noticed that when I REM line 250, it scrolls diagonally.
Horizontal scrolling is possible (I've seen it done in a video). The two POKEs to 2005 set the horizontal and vertical scroll positions (respectively). Because FB uses vertical mirroring, you can scroll vertically and the nametable will appear to wrap around. When scrolling horizontally (basically, swap 250 and 300), you'll see the stars move off the left of the screen into a blank screen. The screen is blank because it's not a mirror of the first page. If I can figure out a better starfield routine (one that fills the whole screen), then I'll probably also have a way of writing to that blank page. (I suspect this is easier to do in V3, since it supports two backgrounds, but I haven't looked up those details, nor do I own a V3 cart).
Quote from: UglyJoe on August 23, 2015, 09:08:51 am
I got around this by poking the scroll registers directly.
I didn't think that was possible since I couldn't get it to work. I must had done something wrong.
This is much better than messing with those RAM registers anyway. Good job!
I figured out a really hacky way of filling the whole nametable with stars. It's hilariously bad, but it gets the job done. All it does is spam the PPU write register with the "star" tile in a loop. It ends up being semi-random since I can't control the timing, but I threw some modulo logic in there to try and keep the stars from clustering together.
I'll probably have to get back into ASM stuff in order to do it properly, given the precise timing needed to write data to the PPU.
Anyway, here's the updated code listing:
5 CLS
10 FOR I=0 TO 300
15 IF I MOD 3 = 0 THEN PAUSE 1
20 POKE &H2007, &HCD
30 NEXT
150 A=0
200 REM PAUSE 1
250 POKE &H2005,0
300 POKE &H2005,A
500 A=A+1
600 IF A>239 THEN A=0
650 GOTO 200
UPDATE: tried this on real hardware (v2.1a) and it spams the screen with random characters instead of the "star" character. I guess Nestopia is not as accurate as I thought. Nintendulator seems to match the real hardware better.
I just tried it in V3 and I also got a screen of random characters as well as some pallet changes. While the characters were being drawn, the screen was shaking.
Post Merge: August 23, 2015, 06:41:18 pm
Here's an example of horizontal scrolling using 2 screens: https://www.youtube.com/watch?v=PFCYHfTKvqI at 34:23 (I must say, this game has good presentation. There is music during gameplay and ending story!)
I don't see any scrolling though?
At the very end of the game, where there is story being displayed. It's actually at 35:40 in the video.
Post Merge: August 24, 2015, 09:09:48 am
I know how this technique was done in V3. In order for one screen to scroll horizontally to the next screen, you need to first create 2 screens of background graphics:
SCREEN 0
PRINT"THIS IS SCREEN 0"
SCREEN 1
PRINT"THIS IS SCREEN 1"
Then type SCREEN 0 to go back to the first screen.
Next, use the code to write the x value to &H2005:
10 A=0
20 PAUSE 1
30 POKE &H2005,A
40 POKE &H2005,0
50 A=A+1
60 IF A>255 THEN SCREEN 1
70 GOTO 20
This is pretty cool. You can use this for transitioning from a title screen to game screen or use this technique to have a 2 screen playing field for your gameplay. What a handy technique!! :o
I think that would work with V2.1a if you have a background loaded (via the BG editor). The saved BG (the one you'd see by typing VIEW) is in the other non-mirrored section of the nametable.
Quote from: P on August 20, 2015, 04:05:51 pm
I've seen lots of those NND compilations but I don't remember any of them scrolling. Do you remember which one it is?
I'm not sure how to do it in assembly though. V3 seems to use SCREEN to switch between the two nametables. Syntax is:
SCREEN display,active
where "display" is screen number (0 or 1) used to choose which screen to display and "active" is which screen (0 or 1 again) the cursor is placed on (you can type stuff on the screen you can't see). If you get stuck you can press CTR+D to restore both to screen 0.
But the question is if V3 keeps it's scroll position buffered somewhere in memory so it can be controlled at will. Else it will keep resetting the scroll position to the beginning of either screen 0 or 1 every frame. Also scroll position must be set in a vertical blanking.
I've been playing around with VIEW, SCREEN, and the BGTOOL and it looks like the 3 interact with each other. I accidentally erased my BG screen when using the SCREEN command. It actually overwrites the BG screen with the SCREEN 1 screen. I'm going to keep playing with these commands and I will figure out what's going on here. I will update you guys with my findings.
Edit: The nametable for SCREEN 1 is shared with BGTOOL screen. Damn, I was hoping to use the SCREEN command for something but now I don't think it's possible.
I have a title screen that uses the BGTOOL nametable. I wanted to use SCREEN 1 to draw to while displaying SCREEN 0, then display SCREEN 1 after drawing was complete.
I'm trying to create a method where you can have a screen displayed completely without having to see every individual tile being drawn. I have to find a way!!!!!
That's the very the purpose of having two screens as I understands it. So you can draw on the one not displaying and then swapping or scrolling it in when you are done drawing.
SCREEN x,y - Here x controls the scroll position: 0 = &H2000 (screen0), 1 = &H2400 (screen1). While y controls which of the two screens the cursor is on. I think you can use it to to control where LOCATE and such things are drawing, on the screen you are not displaying.
VIEW simply copies the contents of screen1 to screen0 without touching the contents of screen1. So if you just want to swap in the new screen you use VIEW.
I'm in a tough situation... My game's title screen uses the BGTOOL memory because it is the most complicated screen in my game. There is no pattern to how it is made, so I can't use loops to draw it piece by piece. I would have to use a bunch of LOCATEs and PRINTs and even COLORs! I think if I had to draw the title screen with code, it would be at least 500-1000 bytes. I need this title screen because it has all the gameplay options.
So using the BGTOOL for the title screen won't take any program memory space.
Now I can only use one screen to draw my score screen and gameplay screen. My score screen is very simple and just prints a few lines in a repetitive pattern and should only be about 200 bytes. This score screen between levels should also draw pretty fast as well.
My gameplay screen has to be drawn tile by tile. I would have liked to use the 2 screen method to do this, but then I would erase my title screen.
Here's the dilemma:
-Use BGTOOL for title screen, but redraw everything slowly for gameplay
-code title screen, waste program space, but have quick transitions to gameplay screen. But you would actually have to reload the entire program and BG screen from tape just to go back to the title screen.
Actually, the first option sounds much better. Less program space wasted and more playable for the user when going back to the title screen after game over. Drawing the gameplay screen tile by tile isn't too bad. It would probably take about 10 seconds to do it though...
So the classic speed vs space problem? If it affects gameplay it sounds better with the speed solution, but you say the user needs to reload it from tape so the first option is much better even if gameplay is a bit slower.
Quote from: P on August 26, 2015, 10:24:40 am
So the classic speed vs space problem? If it affects gameplay it sounds better with the speed solution, but you say the user needs to reload it from tape so the first option is much better even if gameplay is a bit slower.
Once the level is drawn, it won't affect speed during the gameplay. The user is just going to have to watch the level load piece by piece. It's actually not too big of an issue. It was really more of a presentation/design issue.
My game will use DATA statements to load meta-tiles into the game screen. One number in the data statement will represent a meta-tile of 4 characters in a 2x2 block. Each row will be 12 meta-tiles, or 24 characters wide. The value of the piece of data will tell the level-loading function what type of meta tile it is as well as the color. Once the full game screen is drawn, the in-gameplay functions will use the SCR$ to determine what the properties of the tiles are.
My levels are going to be 12 x 9 meta tiles. Each DATA statement will look like this:
1000 DATA1,2,3,4,5,6,7,8,9,A,B,C
1001 DATA1,2,3,4,5,6,7,8,9,A,B,C
etc...
each DATA line is only 28 bytes with this integer-based method. I can also have the data type to be a string and have it like this:
1000 DATA"123456789ABC"
With this method, I would use the string functions to pick out 1 character at a time. This method eliminates the commas and is only 19bytes.
Each piece of data could be hex (&H0 to &HF) or I could use the alphabet and then get the ASCII value for each letter(A=65,B=66,C=67). With hex, I can have 16 different types of meta tiles. With the alphabet, as well as katakana, I can have so much more types of meta tiles.
So my level would be 12 meta tiles wide by 9 meta tiles long. I want 9 levels. (19x9)x9=1539bytes for all my level DATA. The rest of my memory is for gameplay functions, printing,data for other stuff in the game, and music/sound effects. I'm confident that I will have enough memory to make this game! :redcart:
Post Merge: August 28, 2015, 09:41:58 pm
Here's an example of a text screen on top of a scrolling space background:
https://www.youtube.com/watch?v=XrBDmuy9QMA at 1:41:30
After looking at the V3 manual, I noticed that BGGET and BGPUT will allow you to use screen 0 and screen 1 as well as have your BGTOOL screen to be saved in memory. Now you can have your title screen made with BGTOOL and then do your gameplay screens drawn with the 2 screen method for smooth transitions between game screens.
After you are done displaying your title screen, use BGGET to get the title screen from VRAM and put it in program RAM. Now you can use SCREEN 0 and SCREEN 1 to do drawing.
When you want to return to the title screen, use BGPUT to get your BG screen from program RAM into the VRAM. So now you have 3 screens you can work with.
Yeah as long as BGPUT and BGGET can be included in a program it should work I think. Some commands intended to be used in direct mode, refuses to work if they are used in a program.
I just tired it and confirmed that BGGET and BGPUT can be used in program mode. BGPUT actually doubles as a VIEW command when it is run. The BG screen will automatically be dispalyed after running the BGPUT.
Are you sure about that? I switched to BG-screen1 using SCREEN, typed "MARIO" and some random stuff, switched back (CTR+D) and saved it to program memory with BGGET. Then I switched to BG-screen1 again, cleared it and typed "LUIGI". Then I used BGPUT which changed BG-screen1 back to MARIO but nothing happened to BG-screen0 until I entered VIEW.