Multi Sprite Question

[sidcrazy]

Hi, I downloaded the new version of Batari Basic, and I can’t get multiple versions of player sprites to work. I noticed that a sample program called ‘Ms.bas’ had a statement at the beginning titles “Set Kernel Multisprite.” I tried adding this, and nada.

 

I also tried searching the forums for any sample code that may address this, and couldn’t find anything. I have been able to program and create some simple programs, but I want to expand and have multiple sprites in game.

 

I appreciate any help, and I hope you this isn’t too stupid of a question.

[+batari]

Hi, I downloaded the new version of Batari Basic, and I can’t get multiple versions of player sprites to work. I noticed that a sample program called ‘Ms.bas’ had a statement at the beginning titles “Set Kernel Multisprite.” I tried adding this, and nada.

 

I also tried searching the forums for any sample code that may address this, and couldn’t find anything. I have been able to program and create some simple programs, but I want to expand and have multiple sprites in game.

 

I appreciate any help, and I hope you this isn’t too stupid of a question.

The latest official release was 0.35, which does not support the multisprite kernel. You need one of the bleeding edge builds (see pinned topics in bB forum.) Or if you are using a bleeding edge build then maybe it didn't work because the statement was capitalized? bB commands are case-sensitive.

[sidcrazy]

Oh man thank you Batari for addressing my question. I am using the bleeding edge version, but I may have used some caps. I'll try that.

 

Thank you for your help, and thanks for creating Batari basic. Having a high level language to make my own Atari 2600 games is like a dream come true for me.

 

EDIT

I tried making sure it was in lowercase, and it still didn't work. Here is my program, its terrible I know, but maybe someone can point out where I messed up.

castle.bas

Edited January 21, 2007 by sidcrazy

[Dragnerok X]

Oh man thank you Batari for addressing my question. I am using the bleeding edge version, but I may have used some caps. I'll try that.

 

Thank you for your help, and thanks for creating Batari basic. Having a high level language to make my own Atari 2600 games is like a dream come true for me.

 

EDIT

I tried making sure it was in lowercase, and it still didn't work. Here is my program, its terrible I know, but maybe someone can point out where I messed up.

 

Hmm...tricky. I've tried my best to "decypher" your coding style, and cleaned it up a bit. I got the multisprite problem fixed by adding a "1" in front of the statement. Perhaps this might help you?

 

castle.bas

[+batari]

Oh man thank you Batari for addressing my question. I am using the bleeding edge version, but I may have used some caps. I'll try that.

 

Thank you for your help, and thanks for creating Batari basic. Having a high level language to make my own Atari 2600 games is like a dream come true for me.

 

EDIT

I tried making sure it was in lowercase, and it still didn't work. Here is my program, its terrible I know, but maybe someone can point out where I messed up.

 

Hmm...tricky. I've tried my best to "decypher" your coding style, and cleaned it up a bit. I got the multisprite problem fixed by adding a "1" in front of the statement. Perhaps this might help you?

 

castle.bas

The above will work, though the 1 isn't necessary - the problem was that the statement wasn't indented. If a statement isn't indented, bB will think the first keyword is a label and try to evaluate the second keyword as the first, and will probably say something like "Unknown keyword: kernel."

[+atari2600land]

So how many extra players can you have with multisprite? Just one (player2) or more?

[Dragnerok X]

So how many extra players can you have with multisprite? Just one (player2) or more?

 

In theory, at least, the Atari is more than capable of displaying 2 8-pixel sprites per line. However, many tricks have been ployed to exceed that number and even make bigger sprites (around 48 pixel with unlimited (a.k.a. height of screen) height, I think that's about as big as it gets). Now to your question, batari basic 99a and up should be able to do 2 8-pixel sprites per scanline natively. Any more and you'll need asm.

[supercat]

Now to your question, batari basic 99a and up should be able to do 2 8-pixel sprites per scanline natively. Any more and you'll need asm.

 

Most multi-sprite kernels use one player sprite to show a single object that can (at least as far as the kernel is concerned) move anywhere on screen, while the other player sprite shows one object in each of a number of "zones". I would expect bB to work that way. It's possible to multiplex both player sprites, and some games do, but it generally makes things much more complicated unless the sprites act as a "tethered pair". I don't think bB offers any such option.

[+batari]

I'm going to be lazy here and just post the entry on the MSK that is in the current draft of the docs for the next release:

 

 

Multisprite Kernel

 

This is an entirely new kernel written from scratch that provides significant features that should be suitable for a wide variety of games.

 

Instead of two player sprites, you get six. Five of the six sprites are subject to certain limitations, however. These limitations are due to the fact that the 2600's hardware can only display two sprites on any given horizontal line (or y-value).

 

The player0 sprite works much how it did in the standard kernel. Player1-player5 sprites are "virtual" sprites, and are displayed by repositioning the 2600's second hardware sprite several times during the visible screen.

 

One limitation is that the virtual sprites may flicker if one or more of them overlap or don't have enough vertical separation between them. Most people don't mind the flicker, and on a real television, it isn't always terribly noticeable if used sparingly. If you prefer to write a game with no flicker, just ensure that there is sufficient vertical separation between sprites. The kernel will automatically detect if two or more sprites are overlapping and will automatically flicker them, so you don't need to do this yourself.

 

The virtual sprites also are given their own virtual color and NUSIZ registers. COLUP2-COLUP5 and NUSIZ2-NUSIZ5 correspond to sprites 2-5. For sprite 1, use _COLUP1 and _NUSIZ1. Although these look like TIA registers, they are not; they point to the 2600's RAM. The actual TIA registers COLUP1 and NUSIZ1 can be set but they will probably have no effect in the multisprite kernel.

 

Also, although the multisprite kernel doesn't have special variables for REFPx, you can set the reflection bit for each individual sprite by using bit 3 of _NUSIZ1 or NUSIZ2-NUSIZ5, as this bit is unused by the TIA register NUSIZx.

 

Note that missile 1 may be affected by any of sprite 1-5's NUSIZx and COLUPx values depending on where it is located.

 

Other limitations/considerations:

- playfield is mirrored and located in ROM (see below)

- no kernel options (yet)

- missiles and ball are fixed at one unit high

- Y-values are inverted as compared with the standard kernel (i.e. bottom of the screen is zero and top is around 88)

 

One major difference between the standard kernel and this kernel is that the playfield is mirrored and located in ROM. This has several implications:

- the right half of the playfield if always the same as the left

- there are no playfield plotting commands

- horizontal scrolling is essentially impossible

- vertical scrolling isn't implemented (yet)

- The only way to draw the playfield is via the playfield: command

- this means you must specify the entire playfield at once

 

Although the playfield is limited in many ways, the fact that it is stored in ROM is advantageous in one way. Unlike the standard kernel, you are not limited to just 11 rows - you can use up to 44 rows, and you can set the vertical resolution to suit your needs.

 

pfheight is a special variable that specifies the height of playfield blocks, minus one. Acceptable values are 31, 15, 7, 3, 1, and 0.

 

A pfheight of zero will actually give a vertical resolution of around 88 rows. However, it doesn't work properly when sprites are on the screen, so it's probably only useful for static displays like title screens. The setting that will give the highest resolution for general-purpose use is pfheight=1.

[+atari2600land]

So why won't this work? I'm using the bleeding edge even:

10 set kernel multisprite
90 player1x=30 : player1y=30 : player0x=60 : player0y=30 : player2x=90 : player2y=80
100 NUSIZ0=$06 : NUSIZ1=$06 : COLUP0=2 : COLUP1=2 : COLUP2=14
110 player0:
 %01011010
 %00100100
 %00111100
 %01111110
 %11011011
 %10011101
 %00011000
end
111 player1:
 %01011010
 %00100100
 %00111100
 %01111110
 %11011011
 %10011101
 %00011000
end
112 player2:
 %11111
 %01010
 %01010
 %01010
 %01010
 %01110
 %00100
end
130 drawscreen
140 goto 90

[Dan Iacovelli]

can you give us an example on how to use the multi-sprite kernal(along with an example)?

I too would to use it for my game and it's not working out.

am I correct though that I will have use the new playfield command

to draw a playfield if I use the multi-sprite.

(I currently use pfpixel and pfhline to draw a playfield)

nevermind: I noticed you do a set command to have the multisprite to work.

Edited February 19, 2007 by Dan Iacovelli

[Dan Iacovelli]

can you give us an example on how to use the multi-sprite kernal(along with an example)?

I too would to use it for my game and it's not working out.

am I correct though that I will have use the new playfield command

to draw a playfield if I use the multi-sprite.

(I currently use pfpixel and pfhline to draw a playfield)

nevermind: I noticed you do a set command to have the multisprite to work.

I did try using the multisprite kernel but I can't get it working.

[+Atarius Maximus]

I did try using the multisprite kernel but I can't get it working.

 

Here's a quick demo of the multisprite kernel that works. If I remember right, you have to define all the sprites, even if they are left blank. You can also check out my 'Jumper' game, which also uses the multisprite kernel.

 

Steve

DEMO1.TXT

demo1.txt.bin

Edited February 23, 2007 by Atarius Maximus

[+Atarius Maximus]

Here's another demo that actually displays more than one sprite on the screen.

frenzy.txt

frenzy.txT.bin

[+batari]

If I remember right, you have to define all the sprites, even if they are left blank.

This was true, but the bug has been fixed for version 1.0.

[Dan Iacovelli]

can you give us an example(in bBasic) how the multisprites kernel works.

the instructions online are vague (I do know that the playfield is reflected and shrank down to 16 characters instead of standard 32,and sprite positons y are reversed from the standard)

it doesn't say how to do multi sprites(I can get one showing up but that player0 I need at least player1 - 4.

[+batari]

can you give us an example(in bBasic) how the multisprites kernel works.

the instructions online are vague (I do know that the playfield is reflected and shrank down to 16 characters instead of standard 32,and sprite positons y are reversed from the standard)

it doesn't say how to do multi sprites(I can get one showing up but that player0 I need at least player1 - 4.

Here's an example that was included (in a slightly different form) in another release. Press the joystick button to select the sprite to control.

 

I added a few lines with a rem in front that you can remove if you want to use bankswitching (the set romsize and includesfile commands.) Also added is a const command with rem in front if you want to make the screen a little smaller.

 

Also, when trying this example out, I found a bug in the kernel It was a small bug so I fixed it and attached a working version of the kernel. Replace the old multisprite_kernel.asm with this one.

ms.zip

[Dan Iacovelli]

can you give us an example(in bBasic) how the multisprites kernel works.

the instructions online are vague (I do know that the playfield is reflected and shrank down to 16 characters instead of standard 32,and sprite positons y are reversed from the standard)

it doesn't say how to do multi sprites(I can get one showing up but that player0 I need at least player1 - 4.

Here's an example that was included (in a slightly different form) in another release. Press the joystick button to select the sprite to control.

 

I added a few lines with a rem in front that you can remove if you want to use bankswitching (the set romsize and includesfile commands.) Also added is a const command with rem in front if you want to make the screen a little smaller.

 

Also, when trying this example out, I found a bug in the kernel It was a small bug so I fixed it and attached a working version of the kernel. Replace the old multisprite_kernel.asm with this one.

thanks that worked, and the sample you did explain a lot in how to do it(the online intrustions wasn't clear enough

basicly)

now my only problem is doing the playfield(before I used the plotting commands, but you can't use it with multisprites)

[+Random Terrain]

Also, when trying this example out, I found a bug in the kernel It was a small bug so I fixed it and attached a working version of the kernel. Replace the old multisprite_kernel.asm with this one.

Does the download on your web site now have this fixed version and example? If so, I'll just re-download the whole thing in case you fixed any other problems that might have popped up.

 

 

thanks that worked, and the sample you did explain a lot in how to do it (the online instructions wasn't clear enough basically)

I'll take a look at the example and see if I can update the two versions of the help page when I get a chance.

[+batari]

Also, when trying this example out, I found a bug in the kernel It was a small bug so I fixed it and attached a working version of the kernel. Replace the old multisprite_kernel.asm with this one.

Does the download on your web site now have this fixed version and example? If so, I'll just re-download the whole thing in case you fixed any other problems that might have popped up.

No, not yet. I'm wondering if I should just post a patch instead of a whole new version. There is another bug in std_kernel.asm, so it would be just the two files. Overall the changes have been minor and don't affect everyone, so I'm thinking of posting the two files in a zip and users can just download it if they need to.

[Dan Iacovelli]

Also, when trying this example out, I found a bug in the kernel It was a small bug so I fixed it and attached a working version of the kernel. Replace the old multisprite_kernel.asm with this one.

Does the download on your web site now have this fixed version and example? If so, I'll just re-download the whole thing in case you fixed any other problems that might have popped up.

No, not yet. I'm wondering if I should just post a patch instead of a whole new version. There is another bug in std_kernel.asm, so it would be just the two files. Overall the changes have been minor and don't affect everyone, so I'm thinking of posting the two files in a zip and users can just download it if they need to.

I think it is best to post the patch(the kernels) since it's only minor changes.

[SeaGtGruff]

Also, when trying this example out, I found a bug in the kernel It was a small bug so I fixed it and attached a working version of the kernel. Replace the old multisprite_kernel.asm with this one.

Does the download on your web site now have this fixed version and example? If so, I'll just re-download the whole thing in case you fixed any other problems that might have popped up.

No, not yet. I'm wondering if I should just post a patch instead of a whole new version. There is another bug in std_kernel.asm, so it would be just the two files. Overall the changes have been minor and don't affect everyone, so I'm thinking of posting the two files in a zip and users can just download it if they need to.

I think it is best to post the patch(the kernels) since it's only minor changes.

I disagree, at least to an extent. A patch is okay for anyone who already has version 1.0 installed, if that means posting the updated files by themselves instead of reposting everything-- BUT THE PATCH SHOULD HAVE A DIFFERENT NAME.

 

And even if there's just a patch, it would be good to post an updated ZIP that has everything in it, for people who are installing bB for the first time, because I think it's a pain to install a version of something and then have to apply a bunch of patches to bring it up to the "truly current" version.

 

As far as the name, if you don't want to give it a new number (like 1.01), then give it a letter (1.0a). Either way, the important thing is that it have a different name, so there is no confusion about which version (or patched version) is the latest/greatest one.

 

So the ideal situation would be (1) post a named patch with just the updated files, for people who just need to update their 1.0 installation to the 1.0a patch; and (2) post a complete 1.0a install file for new users.

 

Just my $0.02.

 

Michael

[SeaGtGruff]

One more penny for my thoughts.

 

With programs that have their own windows and such, there's usually a "Help | About" menu option that will tell you exactly which version you're using. bB doesn't have any windows of its own, since it can be used with just about any editor, but perhaps it would be a good idea to have a tiny readme text file in the main bB directory-- maybe with a really obvious name, like "version.txt" or whatever. It wouldn't have a description of the history of changes, since that sort of thing is already in another file, but it would simply contain a line that said "bB version 1.0a" or whatever. Then, whether you're releasing just a patch with only one or two updated files, or a new full installation, you could include a new "version.txt" to replace any older one, so the user can quickly and easily identify the version they're using by seeing what that file says in it.

 

Michael

[supercat]

- Y-values are inverted as compared with the standard kernel (i.e. bottom of the screen is zero and top is around 88)

 

I would suggest that it might be useful to have an kernel option for normal or inverted Y coordinates (for compatibility, if the option isn't specified, default to the present way of doing things). It would be simple to invert sprite coordinates on entry to the kernel and invert them again on exit. Allowing programmers to switch kernels while keeping things like sprite behavior constant would seem a definite plus.

[Dan Iacovelli]

got the sprites working good, question is how do check for collision on the virtual sprites since you can use the collision statement on them

(the best way Ifigured is to have it check the position of y and x of the two)