Hey Everyone,

I just wanted to share a horizontal background scrolling engine I've been working on.  I've noticed a lot of other noobs besides myself asking about how to do this, so wanted to post this to hopefully help out.  It's probably not the most effective way to handle background scrolling and buffering, it's just simply how I got it to work.  I'm sure there are improvements that can be made, and if anyone has them to suggest it would be awesome.

One area where I know improvements can be made is incorporating metatiles and data compression.  The backgrounds are loaded in byte by byte and it can be a bit time-consuming making them and then re-arranging them to work with the buffer.  Also, since I don't know how to use compression and each background takes up about 1K of memory, that only gives you about 31 backgrounds you can load in using this engine.  Eh, who needs worlds 1-2 through 8-4 of Super Mario Bros, anyway?  :-)

So think of it as "beginner's" scrolling engine, one that would hopefully be easier to understand by noobs such as myself.  I was simply focused on getting something up and running, and then figuring out the more complicated stuff later.  I'm going to start studying said complicated stuff very shortly. 

In the mean time, if anyone needs to look at something more advanced, you might check out Cadaver's more sophisticated scrolling engine that handles vertical and horizontal scrolling.  It's excellent and can be found at nesdev (http://parodius.com/scroll.zip).&...; I've been looking at it a little bit but haven't delved too deeply into the code, yet.

--Edit: Forgot to mention: hit left and right to scroll.  Sorry.  It'll stop you from scrolling any farther when you've hit the left edge of first background or right edge of last background.

--Further Edit 5-19-10:  I just noticed this has been posted to the Programming Resources sticky.  Just so I don't confuse anyone who might be looking, I've removed all earlier versions of this demo.  It's gone through a lot of changes and the first few versions were not at all ideal.  I will keep the most current, updated version posted at the top of the thread here to make it easier for people to find.

Something is wrong with the scroll.zip link. It doesn't seem to be working. I've been doing a bit of research in the scrolling department myself (although I only need 1 directional horizontal scrolling). Any methods and source is always worth a good look through.

Hey WhatULive4, see if this link works at mediafire:

http://www.mediafire.com/?n5mfiomknxi

Let me know if you're still having problems downloading or have any questions about the code.

Hey Folks,

Here's a newer version that's quite a bit better.  It makes use of 2x2 tile metatiles (16x16 pixel) and also the RLE compression that ProgrammingAce descibes in his article here.   Again, for demo purposes this uses the SMB1 chr file since it's readily available.

By condensing everything down to metatiles and using the RLE method, backgrounds in the background.i file are roughly 80% their original size.  Also, the backgrounds are a hell of a lot easier to load in once the initial time investment of getting the metatiles.i set up is completed.  The RLE has three major flags in the background.i file that trigger in the dbuffersubs.asm.

$FD is used to draw a repetition of metatiles where all four tiles are the same.  In this demo I use it to draw the sky, but you can use it for anything just as long as all four tiles making up the metatile are similar (though you'd obviously need to change the code in dbuffersubs.asm to the tile you want).  In background.i, simply code it by typing $FD, and the number of times you wish to draw the sky metatile.  Ex. .db $FD,$05 in background.i draws the sky metatile five times on the current column.

$FE is used to draw a repetition of metatiles made up of different tiles.  With this you have to code the flag, then the number of times you want it to load, then the metatile number.  Ex. .db $FE,$07,$19 would draw the question block seven times on the current column.

$FF is used to terminate the load loop in dbuffersubs.asm, and must be placed at the end of each column you're coding in background.i.

If you find bugs or if I've done a really good job making this confusing as hell, please IM me.  Also, I didn't really take a lot of time looking over my comments so hopefully they make sense.  If not, let me know.

Just in case the attachment doesn't work, here's the link at mediafire.

This is pretty cool. I can't wait to check it out in depth. I've been toying with scrolling, but I think that it will interfear with my other stuff. There's only so much time in V-Blank. Maybe on a later level.

Thanks dude. This will be most helpful.

Cool, hopefully it is of some use to somebody. It's always good to hook up the Right Nut. :-) I'm not even really sure what I'm going to use it for, to be honest. I'm just having fun playing around with stuff like this. Oh, and don't forget about that scrolling demo I found at nesdev, too. I listed it above and it might be helpful. I just haven't opened it up and studied it too deeply to see what's in it, yet.

Hey, I haven't seen any updates on your game in awhile. How's it coming along?

This link " (http://parodius.com/scroll.zip...). " isn't working.

My game is comming along. I haven't made too much progress recently due to the minor inconvinence of a certain test that I just got through. But now I'm getting back to it. I have spent some substantial time reoragnizing, rewriting stuff OUT of NMI, making my own compression scheme, and implimenting CHR-RAM stuff. After all that, I got a bug into one of my sprites somehow that is being really fucking irratating...I need to figure out what's wrong before I move on. Then music/sfx and then onto levels!

Oh, I see.

I wasn't paying enough attention when WhatULive4 told me about it above and thought he was talking about my link.

Here I've just re-attached Cadaver's scroller if anyone wants to see it.  It can also be found at the nesdev wiki.

Why are you moving the code out of NMI?   I assume because the code extends beyond the time period of a single frame?

I was planning ahead. As I had it before, I had to turn NMI off to load a room as it was extending well out of v-blank, and maybe into the next frame. This would cause the music to skip...maybe. I haven't got that far, but I think that it will work better without having to make the music wait for the room to load (and theoritically an entire new bank of CHR-RAM).

I tried it before, but couldn't get the scroll not to jump around when it skipped back to NMI in the middle of loading stuff. I saw MetalSlime's "sleeping" code in his sound NN tutorials and thought I'd try it. It made the main code run once per frame and a simple BNE and a variable (loading-background-don't-fuck-with-the-PPU) made it run nice. It actually made the black flash when the PPU is turned off almost so fast you can't see it any more. I'd imagine that is because before it would run into the next frame, than have a waitforvblank, then turn the graphics on, then continue on. Now it is only off for one frame.

So far I like it. (And it forces me to seperate my "do-shit" code from my "write to the background" code.)

Another good thing to check out (though it sounds like you already might have) is the drawing buffer in Metalslime's skeleton.asm file. It took me awhile to get it, but it's a really good, easy-to-read implementation of what Disch discusses in his "Frame and NMI" document about preparing a string of data during rendering and then loading it in once NMI fires.

Anymore I don't put anything in NMI unless it's strictly a drawing load/store function or something I'm told is absolutely necessary to be there. There are some healthy debates on nesdev over the whether or not you really need to strip down your NMI code like that, but from what I've read I just don't see the need to put anything there that isn't a write to the PPU.

Pretty cool!  I saw this thread a few days ago but didn't have time to look through the code until today.  Now that I've looked through it I want to throw some ideas your way.  BTW, what you wrote is just fine and you don't have to change anything.  These are just ideas so feel free to ignore them if they don't work for you .  Just some tips that could improve performance:

1) You can save some more bytes on your background data by removing the $FF terminator on all columns.  Usually terminators are used when you have data of variable length, where you don't have any idea when it's going to end (dialogue text, for example).  Since all your columns are the same size, you can know when you reach the end by keeping a count of how many tiles you've processed.  I'd load the column size into an index register (or a temp variable if X and Y are both being used) and then decrement it every time you write a tile to the buffer.  Column is finished when your counter reaches 0.  Cutting the terminator will save you 16 bytes per screen, which makes a significant difference if you have a bunch of screens.

2) Not quite sure why you have a special case for the sky metatile.   My guess is that you were trying to save a byte by not having to declare the sky metatile id in the case of a normal RLE, ie for a run of 8 you save a byte like this: $FE, sky_metatile_id, $08 -> $FD, $08.

It makes some sense since sky is used a lot, but you use a lot of bytes hardcoding the subroutine to handle the special sky case and if you change the ordering of your tiles in the pattern tables, you have to hunt down the hardcoded special cases and change the codes manually.

Another way to do RLE is to have a bit (say, bit7) signify RLE mode instead of a whole byte.  Then you can pack the RLE indicator in with the metatile ids.  So instead of:

.byte $01, $02          ;2 metatiles
.byte $FE, $10, $04,   ;a run of 4 metatiles
.byte $FE, $07, $06   ;a run of 6 metatiles

you could have:

.byte $01, $02      ;2 metatiles
.byte $90, $04      ;a run of 4 (metatile id $10, with the RLE bit set)
.byte $87, $06      ;a run of 6 (metatile id $07, with the RLE bit set)

This way every run is 2 bytes and its generic so nothing needs to be hardcoded.

3) Your drawing buffer appears to draw every frame, even if there is no movement/change.  In other words, when the player isn't moving, you keep drawing the same offscreen columns over and over again.  This is ok for a demo, but in a game it wastes some drawing time that you might need to do other PPU updates.  One way to solve this is to put a cap on the drawing buffer (say a $00).  After you draw a column, put the cap at the beginning of your buffer.  Then in your buffer->ppu subroutine, skip to RTS if the first byte is $00.

4) Your drawing buffer could be set up to draw strings of bytes instead of just individual bytes.  Right now, you set the target PPU address via $2006 for each byte.  But really you only need to write an address to $2006 once per column.  The PPU supports column drawing (bit2 of $2000 toggles row/column drawing).  So instead of your drawing buffer looking like this:

hi_address, lo_address, tile, hi_address, lo_address, tile, hi_address, lo_address, tile, etc ;3 PPU writes per tile!

you could have:

count, hi_address, lo_address, tile, tile, tile, tile, tile, tile ;set address once, and then 1 PPU write per tile

The key is to set the PPU to increment by 32 via bit2 in $2000 so that consecutive writes draws a column instead of a row (see http://wiki.nesdev.com/w/index.ph... ).

Oops, gotta go to class.  No time to edit.  Hope that made some sense   Good job, btw.  Your code is starting to look slick!

Metalslime, as always, you sir are the man! Thanks for the suggestions, especially number 3. I noticed in skeleton.asm and a lot of other stuff I've been looking at that drawing buffers are typically turned on and off in case there's other stuff that needs to be drawn.  I was wondering how to do that. Now I know, so thanks!

I didn't even consider number one, but now I get exactly what terminators are to be used for. Very nifty! Number two took me a minute but I started plugging in the numbers to my programming calc and see how it works now. I haven't played around too much yet with using flag bits instead of flag bytes, but am gradually seeing how they work. Basically what it seems I need to do is add a BIT test in the part where it's reading from background.i and use an AND to read from bit 7. If bit 7 is one, jump to RLE, if it's 0, write the matatile into RAM and jump to next byte. That's pretty cool! Obviously this means you can't have any more than 128 metatiles on any one list, because after $7F (decimal 127) the test bit for RLE would always be set and you'd always jump to RLE. How do you usually get around this? Actually, have you ever needed to in the first place? Upon thinking about it it seems that's a lot of metatiles, but then this demo is pretty simple and it uses 25, so I'm guessing the number can add up pretty quick. Do you simply jump to different metatile indexes if the number gets too high?

And OMG, number 4! I'm slamming my head into my desk right now! You know I actually spent time writing a block of code to increment by 32 for the addresses? It didn't work, so I came up with that hi_address, lo_address etc scheme. If I'd just looked at Deskin's technical doc and realized what you said here earlier I would have saved myself so much time. It's right there in Appendix B in the table for register $2000 "Bit 2 - Specifies amount to increment address by, either 1 if this is 0 or 32 if this is 1." It's undoubtedly been written in the other tuts too but I foolishly ignored it. Raarrggghh!!! Oh well, painful lesson learned. :-)

So anyway, yeah, I'm going to work these suggestions in.  Thanks again for the help!  As always, it's much appreciated.

I'm not sure how you have it set up, but I don't think you can have more than 128 metatiles in a tileset cause you have to multiply it by two to use a look up table.

Yeah, you're right. I didn't think about that. So moot point on my part. You couldn't list any higher than $7F anyway because anymore would spill over into another byte when multiplying by two. I guess I'll cross that bridge if I ever come to it where I need more than 128 entries. For now I'm guessing you'd just need to use different metatile indexes for the different levels and whatnot.

if you put your high bit on the repeat number rather than the tile number, that might help. Then you could use bit 6 for the metatile set flag and have the other bits for other info.

Don't feel too bad about how you have the meta-tiles setup. My first implementation was *awful*. I would draw a tile, jump ahead 32 tiles to draw the second, jump back 31 tiles to draw the 3rd, then jump ahead another 32 to draw the 4th. The only reason it didn't bring the game to a screeching halt is because buffered the writes into ram...

Your code is looking pretty good.

It's worthwhile to learn bit testing. It can save you a lot of space.  To do it, you use AND.  AND works like this on a bit level:

0 AND 0 = 0
1 AND 0 = 0
0 AND 1 = 0
1 AND 1 = 1

To bit test, you use AND to clear all of the bits except the one you are checking.  If the result is 0, your bit was off.  If the result is non-zero, your bit is on.  To check bit7 you'd AND with #%10000000.  To check bit0 you'd AND with #%00000001.  For bit4:

lda some_number
and #%00010000  ;check bit4
bne bit_was_on    ;if non-zero, the bit was on (1 AND 1 gives you a 1, everything else is 0'ed)

so if you had an RLE flag in bit 7:

    lda [ptr], y   ;read a byte from buffer
    and #%10000000  ;check bit7
    bne @rle         ;if non-zero, we have rle
...;snip
@rle:
   lda [ptr], y  ;re-read byte
   and #%01111111 ;cut off the rle bit to get the metatile #.

And yes, stealing a bit would limit you to 127 (128?) metatiles.  You could have different sets for different levels to get around this though.

I agree, bit testing rocks. For each room in my overworld there are four possibilities for the location of doors and I need 4 bit bank info for each room. So I used bits 7654 for the doors (yes/no in each direction) and then 3210 for the bank number. From 5 bytes to 1 for each room. Poweryay.

Cool, thanks guys. I'm working on this right now, actually. Got the code re-written to jump 32 tiles by setting bit 2 of $2000 to one. Just got that part done. Now I'll start re-writing it by incorporating the bit tests. Hopefully work stays nice and slow all day (knock on wood) so I can make some good progress. You never know when my company and its clients will get annoying and actually expect me to be productive, though. ;-)

I know how you feel.  What a bunch of bastards. 

Hey folks, here's the latest iteration, new and improved (as opposed to old and shitty).  It incorporates most of Metalslime's suggestions.  Thanks again, sir!

For whatever reason I couldn't implement the concept of capping the buffer to keep it from drawing every frame.  At first I thought I got it, but then when I started trying to do it in code I just couldn't get it.  What I settled on was a quick test in the main asm called drawTest that basically tests if the player moves and then sets a flag so that the code in the game loop loads up the buffer and the appropriate loading subs in the NMI section run.  I'm not sure if that's a huge improvement.  Now it only draws if the player moves, but it's still drawing quite a bit.  Tried working with it so it only drew if the player moved more than eight pixels right or left, but that led to some bugs.

Still, a lot of fat was trimmed thanks to everyone's input, so I appreciate it.

Could someone explain the Offscreen_buffer_tables.i to me? When I try and implement my own metatiles, and leave the file alone, it causes the assembler to freak out and throw a bunch of errors.

Not sure this is what you are looking for, but maybe this could help:

 http://www.nintendoage.com/forum/...

Cheers!

It may not have anything to do with the buffer file, but I've been attempting to modify the engine to work with my graphics. I replaced the Mario chr file with my own chr file, and reprogrammed my own metatiles and levels, but when I assemble the program it says it doesn't recognize any of the variables (leftright, sleeping, soft_2000, etc. And even all the .word's and .db's, they all say something like "UNDEFINED". I don't know why this is but I thought it may have something to do with the buffer file since that's the only thing I didn't change, and I don't really know how it works.