Vertical Scrolling Questions

[MausBoy]

Since the vertical scrolling in bB happens a pixel at a time vs a "playfield block" at a time with horizontal scrolling, I'm having a couple issues with it.

 

does anyone have any suggestions on how to build a routine that can scroll the playfield up, deleting the playfield line that scrolls off the top, and adding one to the bottom? I can't seem to get it timed right so that the lines don't dissapear or appear on-screen. I know I'm supposed to be able to use playfield pfhline 11 for this but I can't get it worked out so that it happens right at pfhline 11 jumps back down to being invisible, ie when pfhline 0 becomes pfhline 11.

 

I'm guessing once I get this worked out I'll have a way to reset the scrolling too. Right now for instance if a character dies in a vertical scrolling game and I switch to a game over screen, pfhline 0 is sometimes half on, half off the top of the screen, pfhline 11 is half on, etc.

Edited November 14, 2006 by MausBoy

[jbanes]

I'm guessing once I get this worked out I'll have a way to reset the scrolling too. Right now for instance if a character dies in a vertical scrolling game and I switch to a game over screen, pfhline 0 is sometimes half on, half off the top of the screen, pfhline 11 is half on, etc.

This appears to be a bug in bBASIC. A single (half) line from row 11 seems to bleed through. I always turn off row 11 to prevent this.

[MausBoy]

I'm guessing once I get this worked out I'll have a way to reset the scrolling too. Right now for instance if a character dies in a vertical scrolling game and I switch to a game over screen, pfhline 0 is sometimes half on, half off the top of the screen, pfhline 11 is half on, etc.

This appears to be a bug in bBASIC. A single (half) line from row 11 seems to bleed through. I always turn off row 11 to prevent this.

 

I was aware of this bug, I've actually been able to use it to my advantage to create things like really thin health bars in side/non-scrolling games, but that isn't what I mean.

 

I'm referring to what happens when you use the pfscroll up/down commands. If you scroll the screen up, say 3 pixels, then every playfield drawn after that has the top 3 pixels missing.

 

What I really need is to figure out how to delete pfhline 11 and replace it right as pfhline 0 becomes pfhline 11. It's just a matter of simple timing i'm sure, but I can't seem to get it right for anything.

[MausBoy]

I figured it out, not sure why this gave me so much trouble. I just had to create a scrolling routine from scratch instead of trying to build one into an ongoing project. For the issue with resetting the scroll, I just have to use a variable counter to keep track of how many pfscrolls were called before the screens were switched out, then pfscroll the remaining amount of times needed to line it back up.

 

Now I just wish I could find a decent way to use arrays for the playfield information. I can't do it because some lines only have one phline, some have up to five. I've got it set up like this:

 

pfhline 0 11 31 off

s = s + 1

if s = 1 then pfhline 0 11 12 on : pfhline 18 28 on

if s = 2 then pfhline 3 11 7 on : pfhline 9 11 15 on : pfhline 19 28 on

 

etc. blah! It's at least a fun project though, i'll go ahead and post a couple screenshots.

 

[jbanes]

etc. blah! It's at least a fun project though, i'll go ahead and post a couple screenshots.

 

Inverted playfield/background? Very nice.

[MausBoy]

Thanks! After a while all the bB projects start looking more and more alike. Your Deimos Lander and s0c7's F-4 stand out most to me as unique in looks.

 

I think that'll change a little though if Batari gets everything going together at once, like pfheights and pfcolors together, and both working well with scrolling, etc. As-is the blocky playfield and only two sprites is looking a little extra dull to me after a lot of playing NES games, especially with that making me want to create NES-style games even more.

 

I didn't use an inverted playfield for this project, but I've tried that. It would be a lot more useful though if the playfield extended to the edges of the screen, or if you could at least specify at which scanline PF0 gets turned on.

[jbanes]

Thanks! After a while all the bB projects start looking more and more alike. Your Deimos Lander and s0c7's F-4 stand out most to me as unique in looks.

We all try. I think your Space Shooter that you were looking on looked very unique. So it's somewhat in the eye of the beholder.

 

I didn't use an inverted playfield for this project, but I've tried that. It would be a lot more useful though if the playfield extended to the edges of the screen, or if you could at least specify at which scanline PF0 gets turned on.

I take it you cut out the edges from the screenshot then? Otherwise, I have no idea how you managed to fill the screen!

[SeaGtGruff]

I figured it out, not sure why this gave me so much trouble. I just had to create a scrolling routine from scratch instead of trying to build one into an ongoing project. For the issue with resetting the scroll, I just have to use a variable counter to keep track of how many pfscrolls were called before the screens were switched out, then pfscroll the remaining amount of times needed to line it back up.

There's an easier way. As you might imagine, bB has to have a way of telling itself what the vertical scroll value is, so it will know how much to offset the playfield rows. And if you look in 2600basic.h (the file that defines all of bB's zero-page "system variables" and the 26 "user variables"), you'll see that the most likely-looking variable name is playfieldpos. And if you look in pf_scrolling.asm, you'll see that it does use the playfieldpos variable. So the only thing left to do is to set playfieldpos to different values and see what happens.

 

So I did just that, and found that the legal values are 1 through 8. Basically, the value of playfieldpos indicates how many pixels (or double-scan lines) of pfrow 0 are visible at the top of the screen. For example, if you set playfieldpos to 4, then 4 double-scan lines (or half) of pfrow 0 will be visible at the top of the screen, and 4 double-scan lines (or half) of pfrow 11 will be visible at the bottom of the screen. If you want to reset the playfield to an unscrolled state, in which pfrow 0 is fully visible and pfrow 11 is completely hidden behind the score, then you must set playfieldpos to 8.

 

The problem where the first scan line of pfrow 11 is visible above the score, even before any vertical scrolling, is caused by the no_blank_lines option. To get rid of it, just use pfhline to erase pfrow 11 (i.e., pfhline 0 11 31 off). I see you already know about that, so I'm just mentioning it to be sure everyone else understands.

 

Now I just wish I could find a decent way to use arrays for the playfield information. I can't do it because some lines only have one phline, some have up to five. I've got it set up like this:

 

pfhline 0 11 31 off

s = s + 1

if s = 1 then pfhline 0 11 12 on : pfhline 18 28 on

if s = 2 then pfhline 3 11 7 on : pfhline 9 11 15 on : pfhline 19 28 on

 

etc. blah! It's at least a fun project though, i'll go ahead and post a couple screenshots.

 

You should be able to use arrays for the playfield if you store an entire PF register at once-- i.e., 4 bytes per pfrow (left PF1, left PF2, right PF2, and right PF1). For example, you could define a left_pf1 array with 100 elements (or bytes) in it, a 100-byte left_pf2 array, a 100-byte right_pf2 array, and a 100-byte right_pf1 array. Then you can copy the desired values into bB's playfield array based on how far up or down you are-- e.g., if row 20 is at the top of the screen, copy left_pf1[20] through left_pf1[31] into the left PF1 bytes, copy left_pf2[20] through left_pf2[31] into the left PF2 bytes, etc.

 

I know sometimes I say "you can do such-and-such to do this-or-that," as if everyone will be able to follow what I mean, so if you aren't too clear on anything I said, just let me know, and I'll try to post an example.

 

This looks like a neat game, by the way!

 

MR

[SeaGtGruff]

I take it you cut out the edges from the screenshot then? Otherwise, I have no idea how you managed to fill the screen!

He set PF0 to get a playfield border on the left and right sides of the screen! It looks good, doesn't it?

 

MR

[SeaGtGruff]

Since the vertical scrolling in bB happens a pixel at a time vs a "playfield block" at a time with horizontal scrolling,

Since the pfpixels are about twice as tall as they are wide, the optimum "same amount of scroll in all directions" would be 4 scan lines at once, or half of a pfrow. You could do that manually by changing the playfieldpos variable between 8 and 4. Of course, you would also need a routine to manually shift the pfrows up or down. As I mentioned in another post, you could define four arrays to store the left and right PF1 and PF2 values, so your manual vertical scrolling routine would simply need to start at the appropriate location within the four arrays when copying the ROM playfield bytes into RAM.

 

MR

[jbanes]

He set PF0 to get a playfield border on the left and right sides of the screen! It looks good, doesn't it?

*smacks forehead* Why didn't I think of that?

 

The result does look great!

[MausBoy]

If only no_blank_lines worked with vertical scrolling, I'd definately be using it!

 

I enjoy this project, but as usual the lack of sprites is hurting me.

 

For some crazy reason I decided a Tales-inspired "sidekick" sounded fun, so both sprites are used on the player! I'll take a minute to explain the game I guess:

 

You (the pink guy) are leading your friend (the little green guy) down a giant hole to wipe out the monsters that have been killing off his kind. He's kind of slow and dopey though so it's hard to keep him with you. If he or you fall off the bottom of the screen or get squished at the top, you die. He's really rubbery too, so if he walks up behind you he can easily shove you right off a ledge. You can't jump either so you have to be careful not to let him get in front of where you need to go. There are so far 9 levels with a boss at the end of each. There are also four weapon powerups for each player.

 

I have lots of monster sprites, but they obviously require flicker. Should I go ahead and flicker both sprites to allow for two sprite enemies, or should I just flicker missile1 and have two square enemies? Or both, for four? I'm kind of torn...

[MausBoy]

Since the vertical scrolling in bB happens a pixel at a time vs a "playfield block" at a time with horizontal scrolling,

Since the pfpixels are about twice as tall as they are wide, the optimum "same amount of scroll in all directions" would be 4 scan lines at once, or half of a pfrow. You could do that manually by changing the playfieldpos variable between 8 and 4. Of course, you would also need a routine to manually shift the pfrows up or down. As I mentioned in another post, you could define four arrays to store the left and right PF1 and PF2 values, so your manual vertical scrolling routine would simply need to start at the appropriate location within the four arrays when copying the ROM playfield bytes into RAM.

 

MR

 

I appreciate this approach and could probably accomplish some new things with a manual scroll routine, but that's a hell of a lot of work for me to save some space, and the levels aren't that large anyway. I'll test out your suggestions though for future uses, so thank you.

 

I've pretty much settled on a method, using if-then's like I stated above. Except now I have a set number of them, various configurations of horizontal playfield lines, then I set up a data array for each level.

 

so my subroutine goes:

if s = 1 then pfhline 0 11 12 on : pfhline 18 28 on

if s = 2 then pfhline 3 11 7 on : pfhline 9 11 15 on : pfhline 19 28 on

etc

 

where the order of the values of s are stored in an array for each level. At least this way I don't have to have a seperate line of code for each horizontal line of each level.

 

The real ongoing challenge is creating something fun out of this and having enemy AI that dosn't suck. Thank God for your superchip mod MR!!! If you figure out how to use it to allow multiple instances of pfcolors and pfheights, or to add a couple extra sprites, or anything else cool please post asap because those could definately be used in this project.

 

BTW Thanks MR for the information about the playfieldpos variable, I really appreciate it!

Edited November 14, 2006 by MausBoy

[+atari2600land]

This game looks really cool! When will we see a playable ROM preview?

[MausBoy]

So instead of the mess I used, how would you pop a new line onto pfhline 11 right as it lines back up?

 

Would it be:

 

pfscroll up

If playfieldpos = 0 then gosub newline11

 

for example?

 

ps - thanks 2600l! Unforunately there isn't a lot to the game yet, so it might be a bit before there is a preview.

Edited November 15, 2006 by MausBoy

[+batari]

I'm guessing once I get this worked out I'll have a way to reset the scrolling too. Right now for instance if a character dies in a vertical scrolling game and I switch to a game over screen, pfhline 0 is sometimes half on, half off the top of the screen, pfhline 11 is half on, etc.

This appears to be a bug in bBASIC. A single (half) line from row 11 seems to bleed through. I always turn off row 11 to prevent this.

I recall finding a serious problem with the kernel a while back, and I think I might have fixed this bug in the process.

Thanks! After a while all the bB projects start looking more and more alike. Your Deimos Lander and s0c7's F-4 stand out most to me as unique in looks.

 

I think that'll change a little though if Batari gets everything going together at once, like pfheights and pfcolors together, and both working well with scrolling, etc. As-is the blocky playfield and only two sprites is looking a little extra dull to me after a lot of playing NES games, especially with that making me want to create NES-style games even more.

 

I didn't use an inverted playfield for this project, but I've tried that. It would be a lot more useful though if the playfield extended to the edges of the screen, or if you could at least specify at which scanline PF0 gets turned on.

I am not sure how to get pfheights working with scrolling without doing some major tweaking to the kernel. The problem is that the kernel knows when to stop running when it's counted through all of the playfield rows. I'd need another way to check if the kernel is done, and allow for the kernel to exit when fewer than 11 playfield lines if necessary. It's probably not impossible, I just haven't figured out a good way to do it yet.

 

But you have requested pfheights and pfcolors together a number of times (with the ability to change them throughout the game.) I investigated last night, and I think that can be done if you are willing to give up the ball.

 

As for no_blank_lines and scrolling, I *think* that was the serious kernel problem I talked about above. Regardless, I found a kernel problem that would crash the game under certain circumstances, and this was fixed.

[MausBoy]

Well that's all really good news. With those changes and the fix that allows graphics to be in every bank, I can even finish Project Eden. I just really hope the superchip support will add the ability to have at least a couple extra sprites in the new standard kernel, then bB will be a lot more fun. All these games I keep almost finishing will be too.

 

I won't mind trading the ball for a better playfield at all.

Edited November 22, 2006 by MausBoy

[+batari]

I just really hope the superchip support will add the ability to have at least a couple extra sprites in the new standard kernel

The two-sprite limitation is imposed by the 2600's hardware itself. "Multiple" sprites are implemented by repositioning the same sprite more than once in the middle of the kernel, and this takes an entire scanline to do. Unfortunately, asymmetric playfields need to be drawn on every scanline. I can't conceive of any way to do both with just extra RAM. The Chimera cart looks more promising, however, as it is designed to give more kernel time. It is actively being developed but a release date is not set.

[MausBoy]

That's really sad to hear. The Chimera does sound promising, but I guess it will be a while before it's available, and probably quite a bit longer before there is integrated support for it in bB.

 

I'm still definately looking forward to the next bB update though. With fixed pfcolors/nblines+scrolling, graphics in every bank, and the multiple instances of pfheights/pfcolors, it'll definately be a huge step up. Those changes along with superchip support give plenty of options for creating great games, extra sprites or not.

[mos6507]

I'd definitely like to see bB support for Chimera. But I think people will be surprised how easy it is to utilize these features from straight assembly. I think maybe the biggest deal for bB support for Chimera would be the memory model, because of magic writes and the 128K of memory to work with. Zero page becomes much less important with magic writes.

 

Delicon is working hard on the revision 10 board with the new ARM. Assuming that is successful, I would estimate we should send out developer boards to interested parties soon after and have a sellable product a couple months later depending on how far we want to go with the packaging.

Edited November 25, 2006 by mos6507

[gambler172]

Hi

Cannot wait to see a playable bin.The screens look nice

greetings gambler172