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

[SeaGtGruff]

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.

For one thing, you need to take the bank 2 out at the end, because you don't have any bankswitching selected. I was able to get it to compile and run by putting spaces around the equal signs, less thans, and greater thans everywhere you didn't have spaces. Apparently there are times when spacing is required, or the compiler has trouble parsing.

 

Michael

 

Ha, you beat me to it!

Edited August 7, 2009 by SeaGtGruff

[jbs30000]

I discovered a limitation. You can only make a playfield 48 pixels high, or 4 X the standard playfield height. If you go more than that your program won't compile.

[SeaGtGruff]

I discovered a limitation. You can only make a playfield 48 pixels high, or 4 X the standard playfield height. If you go more than that your program won't compile.

I wonder if you could insert the appropriate code yourself-- using either inline assembly or a data statement, and setting the PF variables yourself-- rather than trying to use the playfield command?

 

Michael

[jbs30000]

I'm reading data statements into ram as it is, so it doesn't matter if those data statements are asm generated or bB generated. It's just easier to let bB interpret dots and X's since every other byte is reversed. Or, in other words, since X.......X....... would come out to 1000000000000001 and not 1000000010000000.

[SeaGtGruff]

I'm reading data statements into ram as it is, so it doesn't matter if those data statements are asm generated or bB generated. It's just easier to let bB interpret dots and X's since every other byte is reversed. Or, in other words, since X.......X....... would come out to 1000000000000001 and not 1000000010000000.

Well if that's the case, how about breaking it up into two separate playfield statements for an initial version, then after you compile it, grab the compiled code for the two different playfield statements and paste the data together so it's like it came from a single playfield statement, and recompile it again?

 

Michael

[jbs30000]

I'm confused by what you're trying to say.

[jbs30000]

I just realized that you can use sdata to make a playfield as big as you want. Granted you could only scroll down, and after initially filling the screen, you would need to move all the playfield blocks up by one, and then read the next line of data, but still.

 

Something like

sdata myplayfield=a

-insert data here

end

 

for temp1=0 to 47

playfield[temp1]=sread(myplayfield)

next

 

for the initial screen, and then

 

SUP_Loop

temp1=4

for temp2=0 to 3

temp3=(temp1-4)+temp2

temp4=temp1+temp2

playfield[temp3]=playfield[temp4]

next

if temp1<12 then temp1=temp1+4: goto SUP_Loop

 

for scrolling the screen up, and then finally

 

for temp1=47 to 47

playfield[temp1]=sread(myplayfield)

next

to read the new bottom line of the screen.

 

Note: I actually haven't tried this myself, it's an educated guess, but it should work.

[bogax]

I just realized that you can use sdata to make a playfield as big as you want. Granted you could only scroll down, and after initially filling the screen, you would need to move all the playfield blocks up by one, and then read the next line of data, but still.

 

 

I haven't tryed any of this (except to see that it compiles)

 

You can make a data statement with more than 256 bytes,

you just can't address more than the first 256 from bB

in the usual way. Though you can with some tricks.

 

It appears that bB just tacks on "_begin" to the sdata name.

so

sdata mydata = a

is like

data mydata_begin

you should be able to work with the sdata pointer as an 8.8

format variable.

for the above sdata statement you'd define the variable thusly

dim mydatapointer = b.a

To move down or up a line you'd do something like this

rem down

mydatapointer = mydatapointer + 0.016



rem up

mydatapointer = mydatapointer - 0.016

.016 is more than 4/256 but less than 5/256 in decimal

bB truncates to 4/256 in binary

 

You could define constants for bB for the begining of

the sdata

 

const beginlo = <mydata_begin

const begin_hi = >mydata_begin

rem reset pointer to beginning of the data

a = beginlo : b = beginhi

or you could assign the begin constants to an 8.8 variable

so that you could work with a relative pointer

 

If you set the noinlinedata optimization you can

make a data statement and an sdata statement with

the same data (and different names) by defining

an empty sdata statement immediately followed by

a data statement with the data.

 

set optimization noinline data



sdata mydata = a

end



data mydata_

0, 1, 2, 3, 4

end

I think I'd define a bunch of functions or macros

to do stuff like increment the pointer with wrapping

or do comparisons (for eg determining when to wrap)

 

[+Gemintronic]

I wonder if 4 way scrolling would work if you had to switch banks to get a gynourmous sdata powered level..

[+atari2600land]

I was wondering how I would introduce the King Rabbit in the Celery movie I'm making, and something reminded me of this thread. So I tried to put the code in, and it just produces a bunch of garbage as the playfield and not the intended playfield I put in there. Why? The code for this scene starts at line 2,046 in my code I'm posting. What am I doing wrong here?

 

celerymovie20.bas

[+atari2600land]

In order to solve this problem, I had to increase the rom size to 32k (from 16k.) Does anyone have a reason why?

celerymovie20.bas

[+Random Terrain]

In order to solve this problem, I had to increase the rom size to 32k (from 16k.) Does anyone have a reason why?

 

I don't know anything about it.

[+atari2600land]

I noticed the previous bas file was 39.99k. Perhaps there's a limit to 40k for a 16k rom?

[+Random Terrain]

I noticed the previous bas file was 39.99k. Perhaps there's a limit to 40k for a 16k rom?

Would it care how large the .bas file is?

[+atari2600land]

When I tried to compile the 39.99k file, it had an issue with a line that just defined the background color and nothing else on it. Since I increased the size to 32k, the bas file is now 40.7k, so that line that defined the bg color is right around the 40k mark.

[+Gemintronic]

Y'all know I posted a more advanced engine that can do four way scrolling partially based on this stuff, right?

 

http://atariage.com/forums/topic/218190-smooth-vertical-scrolling-from-data-want-4-way/

[+atari2600land]

I don't need left or right scrolling, so this is good enough for me.

Except I've run into a problem.

The code example only seems to work if it's at the beginning of a bank. I tried to put it in the middle of a bank, but it doesn't like it. The thing back in February worked only because it was at the beginning of a bank, I discovered. Does anyone know why? For this version to work, I had to put scene 12 at the beginning of bank 3 because it wouldn't work otherwise. It just gave me a scrambled playfield with seemingly random blocks on or off. I put it at the beginning of bank 3 (line 1,349 in the code example attached), and it works OK.

celerytwo13.bas