Multisprite playfield mirroring problem. What am I not seeing?

[Snider-man]

OK, I'm missing something incredibly basic (no pun intended) with the playfield settings with the mulktisprite kernel, and it's about to drive me nuts.

 

OK, here's a simple playfield of boxes using the "normal" kernal:

 rem boxes normal kernel

set kernel_options no_blank_lines

COLUPF=4
playfield:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
X..............................X
X..XXXXXXXXXXXXXXXXXXXXXXXXXX..X
X..X........................X..X
X..X..XXXXXXXXXXXXXXXXXXXX..X..X
X..X..X..................X..X..X
X..X..XXXXXXXXXXXXXXXXXXXX..X..X
X..X........................X..X
X..XXXXXXXXXXXXXXXXXXXXXXXXXX..X
X..............................X
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

mainloop
drawscreen
goto mainloop

 

Which gives me the desired image:

 

But the multisprite kernel, which should mirror the playfield down the center, is way off. Here's the code:

 rem boxes using multisprite

set kernel_options no_blank_lines
set kernel multisprite

COLUPF=4
playfield:
XXXXXXXXXXXXXXXX
X...............
X..XXXXXXXXXXXXX
X..X............
X..X..XXXXXXXXXX
X..X..X.........
X..X..XXXXXXXXXX
X..X............
X..XXXXXXXXXXXXX
X...............
XXXXXXXXXXXXXXXX
end

mainloop
drawscreen
goto mainloop

 

And here's the resulting image:

 

So what am I missing? I've read over the manual and several of the successfully running programs and I just can't place my finger on what I'm missing. I'm sure it's something obvious, so....a little help?

[SeaGtGruff]

So what am I missing? I've read over the manual and several of the successfully running programs and I just can't place my finger on what I'm missing. I'm sure it's something obvious, so....a little help?

There are two issues with your second program, but the first issue isn't causing any errors.

 

There are no kernel options available for the multisprite kernel, so take out the "set kernel_options" statement. It doesn't have anything to do with your problem, but it doesn't do anything at all.

 

Your real problem is that you need to use the "pfheight" statement to tell bB how tall to make your playfield pixels. You should set it to 1 less than the desired height, but not just any values are okay. The bB help manual says that acceptable values are 0, 1, 3, 7, 15, and 31. Since these numbers have been reduced by 1, they will give playfield pixels that are 1, 2, 4, 8, 16, and 32 lines high, respectively. Since there are 88 lines on bB's screen, these values will give the following number of playfield rows:

 

88 / 1 = 88 rows (pfheight = 0)

88 / 2 = 44 rows (pfheight = 1)

88 / 4 = 22 rows (pfheight = 3)

88 / 8 = 11 rows (pfheight = 7)

88 / 16 = 5.5 rows (pfheight = 15)

88 / 32 = 2.75 rows (pfheight = 31)

 

However, "pfheight = 0" can cause the display to act funny if sprites are on the screen (if I remember correctly, the playfield rows may shift up and down slightly as the sprites are moving around, creating a sort of "ripple" effect), so the lowest "good" value for most purposes is 1 (which gives . Since you want 11 rows of playfield pixels, the value you want to use is "pfheight = 7."

 

  rem boxes using multisprite

 rem set kernel_options no_blank_lines : rem <------ remove this line
 set kernel multisprite

 pfheight=7 : rem <------ but here is your real poblem, add this line
 COLUPF=4
 playfield:
 XXXXXXXXXXXXXXXX
 X...............
 X..XXXXXXXXXXXXX
 X..X............
 X..X..XXXXXXXXXX
 X..X..X.........
 X..X..XXXXXXXXXX
 X..X............
 X..XXXXXXXXXXXXX
 X...............
 XXXXXXXXXXXXXXXX
end

mainloop
 drawscreen
 goto mainloop

 

Michael

Edited August 26, 2007 by SeaGtGruff

[Snider-man]

Aha! Thanks for that. I figured I was missing a command or something similar.

 

While I "have you on the phone" so to speak, the nuances of the multisprite kernel have me up against the wall again. Trying to get player1 sprite to show up on a static non-moving screen.

 

Once again, here's the program in the standard kernel:

rem boxes normal kernel

set kernel_options no_blank_lines

COLUPF=4
playfield:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
X..............................X
X..............................X
X..............................X
X..............................X
X..............................X
X..............................X
X..............................X
X..............................X
X..............................X
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end
player0x=76:player0y=48
player1x=60:player1y=48


mainloop
COLUP0=50
COLUP1=20

player0:
111110
111110
%01111111
%01111111
%01111111
111110
111110
end


player1: 
111110
111110
%01111111
%01111111
%01111111
111110
111110
end
drawscreen
goto mainloop

Here's the effect I'm shooting for:

 

However, same effect attempted with the MS kernel:

 rem boxes using multisprite

 set kernel multisprite

COLUPF=4
pfheight=7
playfield:
XXXXXXXXXXXXXXXX
X...............
X...............
X...............
X...............
X...............
X...............
X...............
X...............
X...............
XXXXXXXXXXXXXXXX
end

player0x=76:player0y=48
player1x=60:player1y=48


mainloop
COLUP0=50
COLUP1=20

player0:
111110
111110
%01111111
%01111111
%01111111
111110
111110
end


player1: 
111110
111110
%01111111
%01111111
%01111111
111110
111110
end

drawscreen
goto mainloop

 

And player1 disappears...

 

I'm fairly certain that I need to define NUSIZ1, but everytime I do, I crash the program somehow.

 

It's funny - I have no problems with the standard kernel, but just trying to get a basic static non-moving image in the multisprite is giving me headaches.

[SeaGtGruff]

While I "have you on the phone" so to speak, the nuances of the multisprite kernel have me up against the wall again. Trying to get player1 sprite to show up on a static non-moving screen.

I'm fairly certain that I need to define NUSIZ1, but everytime I do, I crash the program somehow.

Your last remark is the key. Since the multisprite kernel multiplexes player1 to get player1 through player5, each of them has to have its own special set of variables, such as for their colors, x and y positions, and number/sizes. The variables for player2 through player5 can be named just like the "normal" ones, such as COLUP2 through COLUP5, or NUSIZ2 through NUSIZ5, which are actually RAM variables instead of TIA registers. But that doesn't work with "player1" anymore, because we need it to have RAM variables (so we can save the values), and we can't let the RAM variables get confused with the TIA registers. So for player1 we have things like _COLUP1 (notice the underline character at the beginning, to make it distinct from TIA register COLUP1). If I remember correctly, the NUSIZ variable is the same-- it would be _NUSIZ1, rather than NUSIZ1. However, there's one (minor) difference between the TIA registers for NUSIZ and the RAM variables-- the RAM variables also include the REFP values, since we can squeeze the on/off bit for the REFP variables in between the number/size bits of the NUSIZ variables, thereby saving a few bytes of precious RAM.

 

Anyway, try changing COLUP1 to _COLUP1 in your program; that should do it. (If you want to get technical, the reason you aren't seeing player1 is because the background is black, and so is player1-- since you didn't set _COLUP1, so it has a value of 0 (since bB clears out all of page zero during start up. If you were to change COLUBK to something other than black, without setting _COLUP1, then you'd see that player1 is there, but it's black.)

 

It's funny - I have no problems with the standard kernel, but just trying to get a basic static non-moving image in the multisprite is giving me headaches.

The multisprite kernel does have a few quirks (as you'll find out as you continue using it), as well as differences from the standard kernel, so it can take a little longer to learn all of the little detais that you need to know about it just to get a simple screen display. But it isn't difficult once you get over the initial stumbling blocks.

 

Michael

Edited August 27, 2007 by SeaGtGruff

[SeaGtGruff]

It's funny - I have no problems with the standard kernel, but just trying to get a basic static non-moving image in the multisprite is giving me headaches.

The multisprite kernel does have a few quirks (as you'll find out as you continue using it), as well as differences from the standard kernel, so it can take a little longer to learn all of the little detais that you need to know about it just to get a simple screen display. But it isn't difficult once you get over the initial stumbling blocks.

 

Michael

By the way, you might want to check out Robert M's Blog, because he's just starting to use batari Basic, and has posted a few entries in his blog about it, including notes like "lessons learned."

 

Michael

Edited August 27, 2007 by SeaGtGruff

[Snider-man]

If you want to get technical, the reason you aren't seeing player1 is because the background is black, and so is player1...

Ah, earlier when I was fighting with the coding, I accidentally had player1 overlapping the playfield and I saw part of the sprite image there. That makes a ton of sense. Thanks for the advice. I'll try it out when I get off work.