DPC+ scroll left or right?

[+hloberg]

can you scroll the playfield left or right with DPC+? If so, how?

Edited August 29, 2016 by hloberg

[+Random Terrain]

There is no built-in command to scroll the DPC+ screen horizontally. At one time, we couldn't even scroll vertically, so who knows what might happen one day if a friendly assembly language master dives in and starts making new improvements to bB.

[+hloberg]

Arggh. well there is always the brute force method of redrawing the screen to give the illusion of scrolling.

Here's what I'm trying to do, make a 2600 version of TI99 Parsec. All I need is the ground to scroll to the left to give the illusion of movement.

I really don't want to draw 32 different playfield screen to scroll through. anyone got idea how i can do that more efficiently?

[+Random Terrain]

You could try something with pfpixel.

[Mr SQL]

Arggh. well there is always the brute force method of redrawing the screen to give the illusion of scrolling.

Here's what I'm trying to do, make a 2600 version of TI99 Parsec. All I need is the ground to scroll to the left to give the illusion of movement.

I really don't want to draw 32 different playfield screen to scroll through. anyone got idea how i can do that more efficiently?

 

You might like Virtual World BASIC, it has a playfield CAM.

[+hloberg]

You could try something with pfpixel.

I get a compiler error in DLC+ or multisprite kernel if I try to compile using pfpixel. it seems to only work in the default kernel.

[iesposta]

Make sure you have RevEng version 37 of batari Basic. He added and fixed many things.

 

You could use the background color to make the ground, and then set one of the virtual players (1-9) to quadruple wide, then it is 8 playfield sized pixels that you could have the same color as background, but place it on top of the ground and move it slowly or quickly from right to left?

That would look like a flat plain and hills or blocky mountains whizzing by.

I get a compiler error in DLC+ or multisprite kernel if I try to compile using pfpixel. it seems to only work in the default kernel.

[+Random Terrain]

I get a compiler error in DLC+ or multisprite kernel if I try to compile using pfpixel. it seems to only work in the default kernel.

 

Did you do what it says here:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#gettingstarted

 

And here:

 

randomterrain.com/atari-2600-memories-batari-basic-vbb.html#install_vbb

[+hloberg]

Make sure you have RevEng version 37 of batari Basic. He added and fixed many things.

 

You could use the background color to make the ground, and then set one of the virtual players (1-9) to quadruple wide, then it is 8 playfield sized pixels that you could have the same color as background, but place it on top of the ground and move it slowly or quickly from right to left?

That would look like a flat plain and hills or blocky mountains whizzing by.

yup, that's the version I have.

moving one of the sprites across the ground was my plan B. A little trick I learned with sprites on the TI-99.

[iesposta]

I should try a demo of two low horizontal strips with Playfield Pixes on top of Background Color, using pfpixel off /on for the parallax effect.

The thing is, using too many pfpixel commands, even with the ARM assisting & the DPC+ Playtield is in RAM, you may over-cycle on just that effect.

Byte Knight managed to get the DK Elevators going up and down using pfpixel on/off, which I guessed would be too many processor cycles, so I guessed wrong there!

[+hloberg]

this will compile in DLC+

:

for d=1 to 32

if pfread(d,9) then goto _main

c=d-1 : if b=0 then pfpixel d 9 off else pfpixel c 9 on


next

this will not. Error (unresolved symbol list)

 

for d=1 to 32

if pfread(d,9) then b=1

c=d-1 : if b=0 then pfpixel d 9 off else pfpixel c 9 on


next

? just changed 'goto _main' to b=1 in if-then statement

Edited September 1, 2016 by hloberg

[+Random Terrain]

After getting rid of the goto, it compiles for me in a little test program with no errors. Maybe you should make a little test program and attach the .bas file. Maybe something is getting lost because of the forum software.

[+hloberg]

if i take the for - next out I get no errors. If I use the for - next loop I get inconsistent compiler errors if I have pfread or pfpixel in the loop.

I'm thinking it's something to so with for - next loops.

 

see the example below which compiles:

 

_fr
d=d+1 : if d<32 then _nx else _outloop
rem for d=1 to 32

if pfread(d,9) then b=1

c=d-1 : if b=0 then pfpixel d 9 off else pfpixel c 9 on


rem next
_nx
goto _fr

_outloop

 

here is the whole test program.

the original program was just testing switching between playfields with a joystick.

un-REM the loop and see if you get weird errors too then try it without.

-------------------------------------------------------------

 

set kernel DPC+

goto __Bank_2 bank2

bank 2

temp1=temp1

__Bank_2

drawscreen

set tv ntsc

a=1
b=0
dim _Frame = a


pfcolors:
$87
end



DF0FRACINC = _Frame + 32
DF1FRACINC = _Frame + 32
DF2FRACINC = _Frame + 32
DF3FRACINC = _Frame + 32



player0:
%00000111
%11100000
%11111000
%01000110
%01111011
%00101100
%11111000
%11111111
end


player1-3:
%00000111
%00000011
%00101100
%11111010
%00111111
%11111010
%00101100
%00000011
%00000111
end

player0color:
$08
$0C
$06
$0C
$08
end

gosub _ds2

player0y=50
player0x=15

player2x = 130
player2y = 40

player3x = 130
player3y = 60

a=0
c=4
rem main loop

_main

NUSIZ0 = $37

_fr
d=d+1 : if d<32 then _nx else _outloop
rem for d=1 to 32

if pfread(d,9) then b=1

c=d-1 : if b=0 then pfpixel d 9 off else pfpixel c 9 on


rem next
_nx
goto _fr

_outloop



DF0FRACINC = _Frame + 32
DF1FRACINC = _Frame + 32
DF2FRACINC = _Frame + 32
DF3FRACINC = _Frame + 32

if joy0up then gosub _ds1
if joy0down then gosub _ds2

drawscreen

goto _main


_ds1

playfield:
...............................
...............................
...............................
...............................
...............................
...............................
...............................
...............................
...............................
..............................
...............................
...............................
...............................
...............................
...............................
...............................
...............................
...............................
...............................
..X.......X.......XX.....X.....
XXXX...X.XXX..X..XXXX...XXX..X.
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

return
_ds2


playfield:
...............................
...............................
...............................
...............................
...............................
...............................
...............................
...............................
...............................
..............................
...............................
...............................
...............................
...............................
...............................
...............................
..........................X....
....X........X.................
....X..........................
....X.......X.......XX.....X...
..XXXX...X.XXX..X..XXXX...XXX..
.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

return

Edited September 2, 2016 by hloberg

[+Random Terrain]

You're missing banks 3 through 6. That might be causing problems:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpc_harmony

[+hloberg]

didn't make a difference.

here's what i found over multiple test.

if: if pfread(x,y) then (a variable a.k.a. b=1 OR a goto to a spot inside loop you get a compile error)

but: if pfread(x,y) then goto a point outside the loop you don't get an error (not something you would want to do in most cases)

 

loops and pfread don't seem to like each other. so i'm just going to continue my test with if then and goto as a work around.

[+Random Terrain]

Weird that it compiles for me and not for you. One time, a few years ago, I thought I made VbB use the newest version of bB, but I somehow overlooked it and was having some kind of problem with my code. RevEng had me double check and he was right. I was using an older version of bB. After pointing VbB to the newest version, the problem went away.

[iesposta]

Horizontal scrolling.

I can push a byte to the screen.

You would need 4 variables, and that would only give you 1 playfield line. Eight variables for 2 lines.

Eight variables is 1/4 of your total RAM variables.

To use extra RAM means using The Stack which lets you Push and Pull additional 128 bytes in DPC, again at a cost of cycles.

Then it is just bit shifting data through the variables and a DFxWRITE for each, and one or some of the registers need the byte reversed, something that bB takes care of when we make our Playfield data, but acting directly we need to flip it.

Again, theory. I don't know what kind of cycles that will cost your program.

Kinda intermediate stuff, setting the hi/low and then a Data Fetcher write, which is what pfpixel ends up when the .bas is compiled to .asm.

[+hloberg]

Weird that it compiles for me and not for you. One time, a few years ago, I thought I made VbB use the newest version of bB, but I somehow overlooked it and was having some kind of problem with my code. RevEng had me double check and he was right. I was using an older version of bB. After pointing VbB to the newest version, the problem went away.

found the error of my ways. I left out the set smartbranching command. added that all the problems went away.

now to look at the logic suggested above and move on. thx

[+hloberg]

Horizontal scrolling.

I can push a byte to the screen.

You would need 4 variables, and that would only give you 1 playfield line. Eight variables for 2 lines.

Eight variables is 1/4 of your total RAM variables.

To use extra RAM means using The Stack which lets you Push and Pull additional 128 bytes in DPC, again at a cost of cycles.

Then it is just bit shifting data through the variables and a DFxWRITE for each, and one or some of the registers need the byte reversed, something that bB takes care of when we make our Playfield data, but acting directly we need to flip it.

Again, theory. I don't know what kind of cycles that will cost your program.

Kinda intermediate stuff, setting the hi/low and then a Data Fetcher write, which is what pfpixel ends up when the .bas is compiled to .asm.

i think i can do it with just 3 variables for two lines by creative reuse.

since i move the bottom playfield slowly, cycles should be a concern. At least i hope not. scrolling the whole playfield in the standard kernel didn't impact the limited test game.

funny, i have wrote most of the game play with little issue. this scrolling of the playfield has been the toughest part to get to work right and it's not even necessary. I just want to make tHE look of the game as close as the 2600 can get to the TI-99 Parsec.

Edited September 3, 2016 by hloberg

[+hloberg]

Success!

was able to scroll, rather quickly, 2 PF lines with 4 variables in DLC+ after I added SET SMARTBRANCH.

here is the code:

 

_main

NUSIZ0 = $37
if pfread(0,19) then e=1 else e=0
for d=1 to 32


if pfread(d ,19) then b=1 else b=0
c=d-1 : if b=0 then pfpixel c 19 off else pfpixel c 19 on

next

if e=0 then pfpixel 31 19 off else pfpixel 31 19 on



if pfread(0,20) then e=1 else e=0

for d=1 to 32


if pfread(d ,20) then b=1 else b=0
c=d-1 : if b=0 then pfpixel c 20 off else pfpixel c 20 on

next

if e=0 then pfpixel 31 20 off else pfpixel 31 20 on


DF0FRACINC = _Frame + 32
DF1FRACINC = _Frame + 32
DF2FRACINC = _Frame + 32
DF3FRACINC = _Frame + 32

drawscreen

goto _main

[wallaby]

Why not use temp1 - temp4 for those variables since you don't need them to persist across frames?

 

I haven't tried this, but could you bit-shift PF_DATA0, etc?

 

It would be great to be able to manipulate the playfield without having to define it. For example, use a few frames "LOADING..." to create the playfield on the fly. Then you could procedurally generate it, or whatever, and save that precious graphics bank in DPC+

[iesposta]

Why not use temp1 - temp4 for those variables since you don't need them to persist across frames?

 

I haven't tried this, but could you bit-shift PF_DATA0, etc?

 

It would be great to be able to manipulate the playfield without having to define it. For example, use a few frames "LOADING..." to create the playfield on the fly. Then you could procedurally generate it, or whatever, and save that precious graphics bank in DPC+

Using temp1-4 would work. Great idea.

I don't know about PF_DATA0, but my previous suggestion can push data to the 4 playfield 8-bits segments.

Also instead of burning variables, a data set of preset values for the playfield segments to push would work better.

 

You can manipulate the playfield by procedurally generating it. We use it for Level 2 and Level 4 in DK Arcade 2600. I came up with that, bogax improved the "loops within loops", and then I rewrote that to just push a byte at a time through the whole playfield. That was the only way to get 4 single line playfields which just those would be larger than the 4K DPC+ Graphic Bank which is needed for all the sprites too.

[+hloberg]

Using temp1-4 would work. Great idea.

I don't know about PF_DATA0, but my previous suggestion can push data to the 4 playfield 8-bits segments.

Also instead of burning variables, a data set of preset values for the playfield segments to push would work better.

 

You can manipulate the playfield by procedurally generating it. We use it for Level 2 and Level 4 in DK Arcade 2600. I came up with that, bogax improved the "loops within loops", and then I rewrote that to just push a byte at a time through the whole playfield. That was the only way to get 4 single line playfields which just those would be larger than the 4K DPC+ Graphic Bank which is needed for all the sprites too.

could you show me a bit if that code. i don't quite understand what you mean by procedurally generating it.

and i plan to clean up my variables, which are a bit sloppy now, with DIM commands. and also add lots of comments.

 

question: the DLC+ sprites are only 8 lines high. in standard kernel they are much thicker. is way to adjust that?

[+Random Terrain]

question: the DLC+ sprites are only 8 lines high. in standard kernel they are much thicker. is way to adjust that?

A sprite can be up to 256 lines high, whether you are using DPC+ or the standard kernel. Before the DPC+ kernel was added, all bB sprites had double-thick rows, so they weren't as pretty as the sprites that assembly language programmers could make. Thanks to the DPC+ kernel, bB users can create single-height sprites that are as detailed as the ones made by Imagic and Activision. If you want DPC+ sprites to have the uglier double-thick standard kernel look, just make two lines instead of one. For example, if you have a standard kernel sprite that is 10 lines high, it will have to be 20 lines high using the DPC+ kernel if you want it to look the same.