Vertical scrolling through a playfield that won't fit the screen

[jbs30000]

This might be of some interest to some of you, unless this topic was done before

 

The program simply demonstrates scrolling through a playfield that's taller than what can be displayed (I drew a playfield 24 pixels high using the standard kernel and the 32x24 pixel playfield).

 

I was going to explain a few things, but then realized I might telling people what they already know, and I hate it when people do that to me, so I'll just post the program and source code and if you have any questions I'll answer them.

 

When you start the program, you'll see 1 displayed on the screen. Push the joystick up, and the one will scroll off screen while the number 2 scrolls onscreen. Of course pressing the joystick down will have the opposite effect. Boring, I know, but again, it's just a scrolling demo. It's pretty fast, so if you decide to use this technique I'd advise adding code to slow things down.

 

Although I've programmed as a hobby for a long time I'm not always good at optimizing my code. If you think I'm using too many commands, or my coding looks sloppy, or if you can think of any way to optimize it, I'd love to hear about it.

default.basdefault.bas.bin

[jbs30000]

I made a triple high screen, put three houses and a road, like in Paperboy....well, the actual house graphics turned out to be crap even though they looked good in the batari visual basic playfield editor, but it's a little bit better demo than just two numbers. I also now realize I should have made pushing up scroll up and pushing down scroll down. Oh well.

 

Scroll3.bas scroll3.bas.bin

[+Random Terrain]

Can't wait to play with your code.

 

 

Thanks.

[jrok]

I made a triple high screen, put three houses and a road, like in Paperboy....well, the actual house graphics turned out to be crap even though they looked good in the batari visual basic playfield editor, but it's a little bit better demo than just two numbers. I also now realize I should have made pushing up scroll up and pushing down scroll down. Oh well.

 

Scroll3.bas scroll3.bas.bin

 

Neat!

 

Hmm... curious why the below doesn't seem to compile. I was trying to modify your houses to loop when reaching either data limit, but DASM throws an error that it doesn't recognize "Data_Start." In fact, no operation of any kind seems to work in that if-then statement... only a return.

 

Can anyone suss out why?

 

Up_Scroll
rem  if Data_Start >= 144 then return
if Data_Start >= 144 then Data_Start=0
Data_Start = Data_Start + 4
for temp1 = 0 to 47
temp2 = Data_Start + temp1
playfield[temp1] = PF_data0[temp2]
next
return

Down_Scroll
rem  if Data_Start = 0 then return
if Data_Start = 0 then Data_Start=144
Data_Start = Data_Start - 4
for temp1 = 0 to 47
temp2 = Data_Start + temp1
playfield[temp1] = PF_data0[temp2]
next
return

[CurtisP]

Added four lines of code to do smooth scrolling.

 

Since indexes are limited to a single byte (0-255), the most lines you can have in your playfield is 64.

Scroll3A.bas

Scroll3A.bin

[jbs30000]

I made a triple high screen, put three houses and a road, like in Paperboy....well, the actual house graphics turned out to be crap even though they looked good in the batari visual basic playfield editor, but it's a little bit better demo than just two numbers. I also now realize I should have made pushing up scroll up and pushing down scroll down. Oh well.

 

Scroll3.bas scroll3.bas.bin

 

Neat!

 

Hmm... curious why the below doesn't seem to compile. I was trying to modify your houses to loop when reaching either data limit, but DASM throws an error that it doesn't recognize "Data_Start." In fact, no operation of any kind seems to work in that if-then statement... only a return.

 

Can anyone suss out why?

 

Up_Scroll
rem  if Data_Start >= 144 then return
if Data_Start >= 144 then Data_Start=0
Data_Start = Data_Start + 4
for temp1 = 0 to 47
temp2 = Data_Start + temp1
playfield[temp1] = PF_data0[temp2]
next
return

Down_Scroll
rem  if Data_Start = 0 then return
if Data_Start = 0 then Data_Start=144
Data_Start = Data_Start - 4
for temp1 = 0 to 47
temp2 = Data_Start + temp1
playfield[temp1] = PF_data0[temp2]
next
return

Strange, I put dim Data_Start=a at the beginning of the program so I don't know why Dasm isn't recognizing it. The only thing I can think of right now without trying the changes you made is that the error is actually something else but it's telling you that it's with the variable.

 

Also, one minor thing. You probably want to make pressing the joystick up do this:

if Data_Start >= 144 then Data_Start=0 else Data_Start = Data_Start + 4

 

And pressing the joystick down go:

if Data_Start = 0 then Data_Start=144 else Data_Start = Data_Start - 4

 

Because right now, if you reach the end and start over, if you're pressing up you reset to 0, and then immediately jump to the second row, or if you're pressing down you reset to the last 12 rows, and then immediately jump up a row.

 

Anyway, I'll make the changes on my computer later and see if I get the same error.

[jbs30000]

Added four lines of code to do smooth scrolling.

 

Since indexes are limited to a single byte (0-255), the most lines you can have in your playfield is 64.

Yeah, slowing down the scrolling is easy, I was just being lazy

 

I do find your code interesting. It looks like something I can learn from.

 

 

Oh, and since the "houses" are unrecognizable, here's a picture of how they showed up on the Visual Batari Basic playfield editor. They still don't look that great, but they look a lot better than what the program displays.

 

[jbs30000]

Oh, and jrok, I just changed my code to loop, and it works for me

 

Up_Scroll

rem if Data_Start >= 144 then return

rem Data_Start = Data_Start + 4

if Data_Start >= 144 then Data_Start = 0 else Data_Start = Data_Start + 4

for temp1 = 0 to 47

temp2 = Data_Start + temp1

playfield[temp1] = PF_data0[temp2]

next

return

 

 

Down_Scroll

rem if Data_Start = 0 then return

rem Data_Start = Data_Start - 4

if Data_Start = 0 then Data_Start = 144 else Data_Start = Data_Start - 4

for temp1 = 0 to 47

temp2 = Data_Start + temp1

playfield[temp1] = PF_data0[temp2]

next

return

 

And of course, if you can get it to work, adding CurtisP's code to smooth the scrolling would make it look nicer still.

[jrok]

Also, one minor thing. You probably want to make pressing the joystick up do this:

if Data_Start >= 144 then Data_Start=0 else Data_Start = Data_Start + 4

 

And pressing the joystick down go:

if Data_Start = 0 then Data_Start=144 else Data_Start = Data_Start - 4

 

Because right now, if you reach the end and start over, if you're pressing up you reset to 0, and then immediately jump to the second row, or if you're pressing down you reset to the last 12 rows, and then immediately jump up a row.

 

 

Ah, right. Good point.

 

Anyway, I'll make the changes on my computer later and see if I get the same error.

 

For me, it's throwing exactly the same sort of error I'd expect if Data_Start was an undefined variable or Jump Label. But it doesn't seem to be a problem with the named variable itself. In fact, you could put anything in that statement (like "if Data_Start = 0 then b=5") and it wouldn't be able to resolve "b" either.

[jbs30000]

For me, it's throwing exactly the same sort of error I'd expect if Data_Start was an undefined variable or Jump Label. But it doesn't seem to be a problem with the named variable itself. In fact, you could put anything in that statement (like "if Data_Start = 0 then b=5") and it wouldn't be able to resolve "b" either.

I hesitate to ask, but have you made sure that there's a space before "if"? That's the only things that springs to mind.

[bongomeno]

holycrap!

that looks like zaxxon!

maby I should make a zaxxon clone!

[SeaGtGruff]

You know, if you create two playfields, use two different playfield colors, use two different as well as two different background colors, and flicker between them, you could get four colors in all, which could make it possible to have green grass, red brick houses, and two other colors-- maybe brown for the roofs, and gray for the pavement. It would depend on how you picked your colors. And there would definitely be flickering-- although, depending on the colors you pick (as well as the TV used), it might not be *too* bad!

 

You might also be able to create a scrolling pfcolors table (or two of them) to go with the scrolling playfield.

 

Michael

Edited August 5, 2009 by SeaGtGruff

[jbs30000]

holycrap!

that looks like zaxxon!

maby I should make a zaxxon clone!

There you go. I'm glad my contribution may help people create good games.

 

Some info for anybody who wants to use this method.

 

Since a variable can only hold a value up to 255 then you can only create a single playfield that's 72 pixels high, or 6 times the height that can be displayed on the screen (for a standard 32x12 playfield display). I'll show some numbers below to show what I mean.

 

A single standard 32x12 screen (only 11 pixels high are visible, I know) is 48 bytes; 4 bytes per row, 12 rows per screen.

1X Rows 0 - 12 start at offset 0, so Data_Start (or whatever you name your variable) starts at 0.

2X Rows 13 - 24 Data_Start = 48

3X Rows 25 - 36 Data_Start = 96

4X Rows 37 - 48 Data_Start = 144

5X Rows 49 - 60 Data_Start = 192

6X Rows 61 - 72 Data_Start = 250

 

So if you want a playfield over 6X high, just simply do another playfield: statement and remember this if you don't already know it. The first playfield: statement creates a label in asm PF_data0, which is why you see that variable in my program. The second playfield: statement creates PF_data1, and so on.

[Animan]

You, sir, have quite possibly may have become a reason many more batari games come out. Thanks you, it will be a help to us all.

[jbs30000]

You, sir, have quite possibly may have become a reason many more batari games come out. Thanks you, it will be a help to us all.

I don't know if my discovery is THAT big, but thank you for the praise.

[Animan]

You, sir, have quite possibly may have become a reason many more batari games come out. Thanks you, it will be a help to us all.

I don't know if my discovery is THAT big, but thank you for the praise.

You welcome.

[yuppicide]

This looks amazing!

 

I feel bad when I come out with a puzzle game based on colored squares moving around, and you guys come out with all the cool looking stuff..

[+Allan]

It reminds me of Paperboy.

 

Allan

[jbs30000]

You know, if you create two playfields, use two different playfield colors, use two different as well as two different background colors, and flicker between them, you could get four colors in all, which could make it possible to have green grass, red brick houses, and two other colors-- maybe brown for the roofs, and gray for the pavement. It would depend on how you picked your colors. And there would definitely be flickering-- although, depending on the colors you pick (as well as the TV used), it might not be *too* bad!

 

You might also be able to create a scrolling pfcolors table (or two of them) to go with the scrolling playfield.

 

Michael

I've tried switching between two playfields and the flicker was absolutely horrible. Although maybe manually filling the playfield ram with the value of data statements might work. And as for scrolling colors, I don't know how coloring the screen works. You probably do, so if you could show me that would be great. Otherwise, I guess I'll need to study asm output.

 

OK, as I'm typing this, I have decided to try two screens. I took my first example of a playfield with 1 and a playfield of 2 and flicker between them. Since I think that pfcolor might be slower than COLUPF, I'm using COLUPF. The 1 is red, and the 2 is green. I'm using the playfield[offset] variable to draw the screen. Apparently green and red overlapping make orange. And it seems that the flicker isn't as bad as I remember.

 

Flicker.basFlicker.bas.bin

Edited August 6, 2009 by jbs30000

[jbs30000]

2X Rows 13 - 24 Data_Start = 48

3X Rows 25 - 36 Data_Start = 96

4X Rows 37 - 48 Data_Start = 144

5X Rows 49 - 60 Data_Start = 192

6X Rows 61 - 72 Data_Start = 250

Oops, that should be

2X Rows 12 - 23 Data_Start = 48

3X Rows 24 - 35 Data_Start = 96

4X Rows 36 - 47 Data_Start = 144

5X Rows 48 - 50 Data_Start = 192

6X Rows 60 - 71 Data_Start = 250

[jrok]

You know, if you create two playfields, use two different playfield colors, use two different as well as two different background colors, and flicker between them, you could get four colors in all, which could make it possible to have green grass, red brick houses, and two other colors-- maybe brown for the roofs, and gray for the pavement. It would depend on how you picked your colors. And there would definitely be flickering-- although, depending on the colors you pick (as well as the TV used), it might not be *too* bad!

 

You might also be able to create a scrolling pfcolors table (or two of them) to go with the scrolling playfield.

 

Michael

I've tried switching between two playfields and the flicker was absolutely horrible. Although maybe manually filling the playfield ram with the value of data statements might work. And as for scrolling colors, I don't know how coloring the screen works. You probably do, so if you could show me that would be great. Otherwise, I guess I'll need to study asm output.

 

OK, as I'm typing this, I have decided to try two screens. I took my first example of a playfield with 1 and a playfield of 2 and flicker between them. Since I think that pfcolor might be slower than COLUPF, I'm using COLUPF. The 1 is red, and the 2 is green. I'm using the playfield[offset] variable to draw the screen. Apparently green and red overlapping make orange. And it seems that the flicker isn't as bad as I remember.

 

Flicker.basFlicker.bas.bin

 

I think the flicker here is totally acceptable, especially with brighter colors. I'm looking at it in z26 with 77 phosphor and it looks quite good. Experimenting with pfheights and pfcolors now, and with a bit of planning it seems like you could create some very detailed and interesting pictures.

[+Propane13]

It reminds me of Paperboy.

 

Allan

 

Me too!

 

-John

[jbs30000]

It reminds me of Paperboy.

 

Allan

 

Me too!

 

-John

That's what I was going for.

[+atari2600land]

Will someone tell me why this won't work? I'm trying to create a Mario-type level where a character falls down (like H.E.R.O.), but it keeps saying it doesn't like COLUP0 for some reason.

drop.bas

[jwierer]

Will someone tell me why this won't work? I'm trying to create a Mario-type level where a character falls down (like H.E.R.O.), but it keeps saying it doesn't like COLUP0 for some reason.

I am using batari Basic v1.01 ©2005-2007 and it is reporting (83): Error: Unknown keyword: COLUP0=68. Putting spaces between before and after the = fixes it, but then complains for all the other instances. Once those are fixed, then it doesn't like the bank statement at the end.

 

This compiles, but just shows a circle on the screen.

drop.bas

-Jeff